CURSO DE TESTING

Lucia Argañaraz
HORARIOS DE
CLASES
Martes , miércoles y Jueves a las 9 AM
Consulta viernes a las 15h
Requisitos para aprobar el curso:
-80% de asistencia
-TP aprobados y entregados a tiempo.
-Trabajo Final.
¿QUÉ ES
UN
SISTEMA
?
Conjuntos de elementos
relacionados y organizados
entre sí para cumplir un
objetivo en común.
CICLO DE VIDA DE UN
SISTEMA
EQUIPO DE
DESARROL
LO DE
SOFTWARE
¿QUÉ ES LA CALIDAD?
La calidad es una propiedad
que tiene una cosa u objeto, y
que define su valor, así como la
satisfacción que provoca en un
sujeto.
CALIDAD DE SOFTWARE
Este modelo indica que la calidad de software se debe medir en base a 6
características:
Funcionalidad: cumplimiento de los requisitos funcionales.
Fiabilidad: cumplimiento de las prestaciones requeridas.
Usabilidad: esfuerzo requerido por el usuario para utilizar el producto
satisfactoriamente.
Eficiencia: relación entre las prestaciones del software y los requisitos necesarios para
su utilización.
Mantenibilidad: facilidad para adaptarse a las nuevas especificaciones.
Portabilidad: capacidad del software para poder portarse de un entorno a otro.
DIFERENCIAS ENTRE QA Y QC
Aseguramiento de la calidad (QA)
Se puede decir que el aseguramiento de la calidad (Quality Assurance – QA) es un
proceso dentro de la gestión de proyectos que monitoriza y verifica que el resto de
procesos, métodos y actividades usados para generar los entregables del proyecto
han sido seguidos y ejecutados correctamente .

Control de la calidad (Qc)

El control de la calidad (Quality Control – QC) es un proceso (dentro del ciclo de
vida de un proyecto) que se encarga de garantizar que los entregables del proyecto
cumplen con los estándares de calidad definidos .
RESPONSABILIDADES DE UN
TESTER
Conocer a los usuarios del sistema para comprender el alcance de los proyectos.
Trabajar con desarrolladores de software y equipos de soporte.
Identificar las necesidades comerciales.
Planificar proyectos de calidad.
Monitorear aplicaciones y sistemas de software.
Realizar pruebas de estrés, pruebas de rendimiento, pruebas funcionales y pruebas de
escalabilidad.
Realizar pruebas manuales y automatizadas.
RESPONSABILIDADES DE UN
TESTER
Realizar Pruebas en varios entornos, incluidos web y móvil.
Escribir informes de errores.
Realizar la planificación de recursos.
Revisar la documentación.
Trabajar para cumplir con los plazos de los departamentos y proyectos.
Proporcionar garantía de calidad.
Proporcionar información objetiva a los equipos de proyectos de desarrollo de
software.
RESPONSABILIDADES DE UN
TESTER
Detectar posibles fallas.
Diseñar pruebas para mitigar el riesgo.
Presentar los resultados a los equipos de desarrollo de software y al cliente.
Trabajar en varios proyectos al mismo tiempo.
Analizar documentación.
VALIDACIÓN Y VERIFICACIÓN
Verificación: conjunto de actividades que aseguran que el
software implementa correctamente una función
específica (¿estamos construyendo el producto
correctamente?).

Validación: son las actividades que buscan asegurar si el

software construido se ajusta a los requisitos del cliente
(¿estamos construyendo el producto correcto?).
VALIDACIÓN Y VERIFICACIÓN
La verificación y la validación a menudo se confunden.
La diferencia entre ellas puede plantearse en estas preguntas:
• «Validación: ¿Estamos construyendo el producto correcto?»
• «Verificación: ¿Estamos construyendo el producto correctamente?»
Verificación: implica comprobar que el software está de acuerdo con su
especificación. Si satisface sus requerimientos funcionales y no funcionales.
VERIFICACIÓN Y VALIDACIÓN
La validación es un proceso más general.
Objetivo => asegurar que el sistema satisface las expectativas del cliente.
Va más allá de comprobar que el sistema satisface su especificación (Análisis).
Procura demostrar que el software hace lo que el cliente espera que haga.
Pues, las especificaciones del sistema no siempre reflejan los deseos o necesidades
reales de los usuarios.
OBJETIVO DE V & V
Asegurar que el sistema sea lo suficientemente bueno para su uso pretendido.
El nivel de confianza requerido depende del propósito del sistema, las expectativas
de los usuarios y el entorno de mercado actual:
1. Propósito del Sistema. El nivel de confianza requerido depende de cuán crítico sea
el software para una organización.
El nivel de confianza para un software que controla un sistema de seguridad es más
alto que el requerido para un software de demostración.
OBJETIVO DE V & V
2. Expectativas del usuario. Muchos usuarios tienen pocas expectativas sobre su
software y no se sorprenden cuando éste falla.
Pueden aceptar estas fallas cuando los beneficios de su uso son mayores que sus
desventajas.
Sin embargo, la tolerancia de los usuarios a los fallos de los sistemas está
decreciendo desde los años 90.
Actualmente es menos aceptable entregar sistemas no fiables, por lo que las
compañías de software deben invertir más esfuerzo para verificar y validar.
¿QUÉ SON LAS PRUEBAS DE
SOFT?
La prueba de software es el proceso de evaluación y verificación de un producto o
aplicación de software para saber si hace lo que se supone que debe hacer. Los
beneficios de las pruebas incluyen la prevención de errores, la reducción de los
costos de desarrollo y la mejora del rendimiento.
MODELO V – MODELO
DE DESARROLLO
SECUENCIAL

El proceso de pruebas no es un proceso

aislado; las actividades de pruebas están
asociadas a actividades de desarrollo de
software. El desarrollo de distintos
modelos de ciclo de vida requiere
distintos enfoques de pruebas.
MODELO V – MODELO DE
DESARROLLO SECUENCIAL
Estrategia de aplicación de las pruebas.
Se comienza en la prueba de cada módulo, que normalmente la realiza el propio personal de
desarrollo en su entorno.
Con el esquema del diseño del software, los módulos probados se integran para comprobar sus
interfaces en el trabajo conjunto (prueba de integración).
El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no
tanto los requisitos funcionales como los requisitos de rendimientos, seguridad, etc (prueba
funcional o de validación).
El software ya validado se integra con el resto del sistema (por ejemplo, elementos mecánicos,
interfaces electrónicas, etc.) para probar su funcionamiento conjunto (Prueba del sistema).
Por último, el producto final se pasa a la prueba de aceptación para que el usuario compruebe en
su propio entorno de explotación si lo acepta como está o no (prueba de aceptación.).
 RELACIÓN ENTRE PRODUCTOS DE
DESARROLLO Y NIVELES DE PRUEBA.
PRUEBAS FUNCIONALES
Estas pruebas se definen a partir de funciones o características (como decimos, bien
descritas en documentos o bien interpretadas por los probadores) y su
interoperabilidad con sistemas específicos, pudiendo ejecutarse en todos los niveles
de pruebas (componentes, integración, sistema, etc).
PRINCIPIOS DE LAS PRUEBAS
1. Las pruebas muestran la presencia de defectos,
no su ausencia
Se puede demostrar la presencia de defectos en un software, sin embargo,
aunque se realice una cantidad considerable de pruebas no es posible asegurar
que un sistema se encuentra libre de defectos. Las pruebas simplemente ayudan
a reducir la cantidad de defectos que pueden ser hallados, lo cual minimiza el
riesgo de un mal funcionamiento en las operaciones del sistema.
PRINCIPIOS DE LAS PRUEBAS
2. Las pruebas exhaustivas son imposibles.
Probar todas las combinaciones de entradas y
precondiciones no es posible, excepto en casos
triviales. Debido a esta situación, lo correcto es
realizar un análisis de riesgo y así priorizar y
ejecutar los casos de prueba que tienen mayor
importancia.
PRINCIPIOS DE
LAS PRUEBAS
3. Las pruebas tempranas ahorran tiempo
y dinero
Encontrar defectos en etapas tempranas
del proyecto equivale a reducir costos de
tiempo y dinero, mientras más tarde se
encuentran los defectos, más costoso es
arreglarlos. Por esta razón las pruebas
tanto dinámicas como estáticas deben
empezar tan pronto como sean posibles
de realizar.
PRINCIPIOS DE LAS PRUEBAS
4. Agrupación de defectos
Por lo general, la mayoría de los defectos tienden a
concentrarse en un pequeño número de módulos,
existen distintas razones por lo que esto sucede, una
de ellas es que los cambios se hacen regularmente
en un solo módulo, o porque al arreglar un defecto,
es posible introducir otro.
PRINCIPIOS
DE LAS
PRUEBAS
5. Cuidado con la paradoja del pesticida
Cuando se ejecutan los mismos casos de
pruebas una y otra vez y sin ningún
cambio, eventualmente estos dejarán de
encontrar defectos nuevos. Es necesario
cambiar las pruebas y los datos de prueba
existentes para poder encontrar nuevos
defectos. La paradoja del pesticida solo
resulta beneficiosa en las pruebas de
regresión.

.
PRINCIPIO DE
LAS PRUEBAS
6. Las pruebas dependen del contexto
Es necesario adecuar las pruebas según el contexto del
objeto que se está probando, por ejemplo, no es igual
probar una aplicación web para uso médico, que una
aplicación móvil e-commerce.
7. La falacia de ausencia de errores
Es posible que la mayoría de los defectos críticos de
una aplicación hayan sido corregidos, pero esto no
asegura que el software sea exitoso. Se puede dar el
caso de que este no cumpla con las expectativas del
cliente o tal vez, que sea peor en comparación a
sistemas similares.
REQUERIMIENTO DE UN
SOFTWARE
Los requerimientos para un sistema son la descripción de los servicios
proporcionados por el sistema y sus restricciones operativas.:
1. Los requerimientos del usuario son declaraciones, en lenguaje natural y en
diagramas, de los servicios que se espera que el sistema proporcione y de las
restricciones bajo las cuales debe funcionar.
2. Los requerimientos del sistema establecen con detalle las funciones, servicios y
restricciones operativas del sistema. El documento de requerimientos del sistema
debe ser preciso. Debe definir exactamente qué es lo que se va a implementar.
REQUERIMIENTOS FUNCIONALES
Y NO FUNCIONALES
Los requerimientos de sistemas software se clasifican en funcionales y no
funcionales, o como requerimientos del dominio:
1. Requerimientos funcionales. Son declaraciones de los servicios que debe
proporcionar el sistema, de la manera en que éste debe reaccionar a entradas
particulares y de cómo se debe comportar en situaciones particulares. En algunos
casos, los requerimientos funcionales de los sistemas también pueden declarar
explícitamente lo que el sistema no debe hacer.
2. Requerimientos no funcionales. Son restricciones de los servicios o funciones
ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de
desarrollo y estándares.
REQUERIMIENTOS FUNCIONALES:

Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos
requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del
software y del enfoque general tomado por la organización al redactar requerimientos. Cuando
se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante
abstracta.
Estos requerimientos funcionales del usuario definen los recursos específicos que el sistema
debe proporcionar.
La especificación de requerimientos funcionales de un sistema debe estar completa y ser
consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar
definidos. La consistencia significa que los requerimientos no deben tener definiciones
contradictorias.
Es posible que los problemas surjan solamente después de un análisis más profundo o , a
veces, después de que se termine el desarrollo y el sistema se entregue al cliente.
REQUERIMIENTOS NO
FUNCIONALES:
Son aquellos requerimientos que no se refieren directamente a las funciones
específicas que proporciona el sistema, sino a las propiedades emergentes de éste
como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De
forma alternativa, definen las restricciones del sistema como la capacidad de los
dispositivos de entrada/salida y las representaciones de datos que se utilizan en las
interfaces del sistema.
Pueden especificar el rendimiento del sistema, la protección, la disponibilidad y
otras propiedades emergentes.
Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar
para desarrollar el sistema.
REQUERIMIENTOS NO
FUNCIONALES
Los requerimientos no funcionales surgen de las necesidades del usuario, debido a
las restricciones en el presupuesto, a las políticas de la organización, a la necesidad
de interoperabilidad con otros sistemas software o hardware, o a factores externos
como regulaciones de seguridad o legislaciones sobre privacidad.
Los tipos de requerimientos no funcionales son:
1. Requerimientos de producto.
2. Requerimientos organizacionales.
REQUERIMIENTO NO
FUNCIONALES
3. Requerimientos externos

Requerimientos del Usuario:

Los requerimientos del usuario para un sistema deben describir los requerimientos
funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del
sistema sin conocimiento técnico detallado. Únicamente deben especificar el
comportamiento externo del sistema y deben evitar, tanto como sea posible, las
características de diseño del sistema
EL DOCUMENTO DE
REQUERIMIENTO DE SOFTWARE
El nivel de detalle que se debe incluir en un documento de requerimientos depende
del tipo de sistema que se desarrolle y del proceso de desarrollo utilizado.
Los requerimientos deben ser escritos de manera clara y concisa, estos pueden ser
representados de diversas maneras y dependerá de la metodología de trabajo adoptada
como por ejemplo: especificación a través de plantilla ieee 830, casos de uso ,
historias de usuario, caso de uso 2.0, caso de uso real, etc.
CICLO
DE
PRUEBA
MODELO
DE
PROCES
O DE
PRUEBA
S DEL
SOFTWA
RE
PRUEBAS DE CAJA NEGRA
¿CÓMO SE REALIZAN LAS
PRUEBAS DE CAJA NEGRA?
Lo primero será un previo análisis de los requisitos y especificaciones del software.
Diseñar una batería de entradas validas, también llamado escenario de prueba positiva, para
verificar si el software las procesa correctamente. También se diseñan entradas no válidas
(llamado escenario de prueba negativa) para comprobar si el software que se está probando
es capaz de detectarlas y reaccionar antes estas entradas.
Basándose en las entradas, el tester determina para cada una de estas las salidas esperadas
correspondientes.
Una vez que se tienen las entrada y su correspondiente salida, se diseña los casos de prueba.
Se ejecutan esos casos de pruebas.
El tester comprueba la salida que ha emitido el software con la salida esperada de los casos
de prueba.
 ¿CÓMO SE REALIZAN LAS
PRUEBAS DE CAJA NEGRA?
Si la salida del software coincide con la salida esperada, el software hace lo que tiene que
hacer para esa entrada. Pero si la salida del software no coincide con la salida esperada, hemos
encontrado un defecto en el software. Lo que conllevará su posterior reparación.

Pruebas de caso de uso:

Estas pruebas de caja negra se basan en la representación de las interacciones entre actores
(usuarios o sistemas que interactúan con nuestro software). Basándose en estas interacciones
se pueden diseñar casos de prueba.
Suelen ir acompañadas de precondiciones que deben cumplirse para los actores funcionen de
forma adecuada.
Cada caso de uso termina con postcondiciones que serán los resultados analizados después de
la ejecución.
Se suelen usar para definir las pruebas de aceptación en la que participan usuarios o clientes.
 ¿CÓMO SE REALIZAN LAS
PRUEBAS DE CAJA NEGRA?
Pruebas de historias de usuario:
Prueba muy utilizada en metodologías Ágiles como puede ser el Scrum. Los requerimientos
de usuario son preparados como historias de usuario.
Estas historias de usuario describen una funcionalidad que puede ser desarrollada o probada
en una misma secuencia.
En estas descripciones en las historias de usuarios suelen aparecer funcionalidades a
implementar, requerimientos no funcionales y los criterios de aceptación.
Los criterios de aceptación abarcan la cobertura mínima requerida para la historia de usuario.
Los casos de pruebas se basan en estos criterios de aceptación.
METODOLOGÍAS AGILES
las metodologías ágiles son aquellas formas
que permiten adaptar el trabajo a las
condiciones del proyecto, consiguiendo
flexibilidad e inmediatez en la respuesta para
amoldar el proyecto y su desarrollo a las
circunstancias específicas del entorno.
LOS 12 PRINCIPIOS DE LA
METODOLOGÍA ÁGIL
El cliente en primer lugar a través de entregas tempranas y continuas: la entrega
temprana y continua aumenta la probabilidad de satisfacer las demandas de los
clientes y contribuye a la generación de un retorno de la inversión más rápido.
Estar siempre abierto a cambios: las solicitudes de cambio deben ser siempre
bienvenidas, incluso en las últimas etapas de la ejecución del proyecto. A diferencia
de la gestión de proyectos tradicional, en las metodologías ágiles, los equipos tienen
como objetivo aceptar la incertidumbre y reconocer que incluso un cambio tardío
puede tener mucho valor para el cliente final.
LOS 12 PRINCIPIOS DE LA
METODOLOGÍA ÁGIL
Entregas con valor: originalmente fue establecido para las metodologías ágiles
"entregar software que funcione con frecuencia, desde un par de semanas hasta un
par de meses, con una preferencia hacia la escala de tiempo más corta". Aquí el
principal objetivo es reducir el tamaño de los lotes que utilizas para procesar el
trabajo.
Eliminar silos organizacionales entre los equipos: en este punto el objetivo es crear
una sincronización entre las personas que crean valor y las que lo planifican o
venden. Sólo así lograrás una colaboración interna fluida, lo que mejorará el
rendimiento de tu proceso.
Motivación a los involucrados: al reducir la microgestión y potenciar a los
miembros del equipo motivados, los proyectos se completan más rápido y con mejor
calidad.
LOS 12 PRINCIPIOS DE
METODOLOGÍA ÁGIL
La comunicación, de preferencia, debe ocurrir cara a cara: la comunicación en
persona reduce el tiempo de respuesta. Pero, con el desarrollo de la tecnología y
equipos trabajando remotamente, podemos adaptar este principio ágil para:
comunicación directa. Es decir, cuando tengas una manera de llegar rápidamente a tu
equipo para discutir asuntos de trabajo, hazlo.
Un software de trabajo es la principal medida de progreso: no importa cuántas horas
de trabajo hayas invertido en tu proyecto: si el resultado no es lo que tu cliente
espera que sea, tienes problemas.
Mantén un ritmo de trabajo sostenible: al utilizar una metodología ágil, uno de los
objetivos es evitar sobrecargas y optimizar la forma de trabajo de tus equipos para
que puedas realizar entregas con frecuencia y responder a los cambios.
LOS 12 PRINCIPIOS DE
METODOLOGÍA ÁGIL
La excelencia continua mejora la agilidad: al mantener la excelencia operativa, tus
equipos tienen menos problemas para reaccionar a los cambios y mantienen la
agilidad.
La simpleza es importante: siempre que puedas hacer algo de manera sencilla, hazlo,
al final ¿por qué perder tiempo complicándote?. Ten esto en consideración al
implementar una metodología ágil y evita hacer algo por el simple hecho de hacerlo.
Equipos más libres generan más valor: equipos motivados generan el máximo valor
para el cliente. Fíjate: Si tienes que conducir hacia adelante a tus equipos, tal vez aún
no es el mejor momento para implementar una metodología ágil.
LOS 12
PRINCIPIOS
DE
METODOLO
GÍA ÁGIL
Reflexiona sobre tu forma de trabajar para aumentar la
productividad: tú y tus equipos deben reflexionar sobre cómo ser
más eficaces, discutan lo que salió mal y hagan los ajustes
necesarios para volver a empezar. Sólo así, serás capaz de
experimentar y mejorar tu rendimiento continuamente.
VENTAJAS DE
METODOLOGÍAS ÁGILES
Agilizar entregas rápidas y continuas: una de las principales y más importantes
características de las metodologías ágiles son sus entregas rápidas y continuas. Con el uso
de estas metodologías, es posible determinar un intervalo de tiempo donde todos los
equipos deben realizar sus entregas, que puede ser una vez a la semana o una vez a cada 15
días.
Mejorar la calidad del producto: a través de las metodologías ágiles, los equipos enfocan
sus trabajos en la búsqueda por la excelencia del producto, lo que mejora el producto final.
Aumentar la motivación de los trabajadores: los equipos de trabajo autogestionados,
facilitan el desarrollo de la capacidad creativa y de innovación entre sus miembros.
Estimular el trabajo colectivo: con las metodologías ágiles, distintos equipos y reuniones
frecuentes son necesarias. Esto permite una mejor organización del trabajo colaborativo
entre equipos de distintas áreas de la empresa.
BENEFICIOS PRINCIPALES DE
METODOLOGÍAS ÁGILES
Visibilidad de los detalles del proyecto
Mejora en eficiencia del equipo
Mejoras en la comunicación
Capacidad para adaptarse a los cambios
Capacidad de escalar
¿QUÉ ES
SCRUM?
Scrum es un marco que permite el trabajo
colaborativo entre equipos. Scrum anima a los
equipos a aprender a través de las experiencias,
a autoorganizarse mientras aborda un problema
y a reflexionar sobre sus victorias y derrotas
para mejorar continuamente.
sus principios y lecciones se pueden aplicar a
todo tipo de trabajo en equipo.
La metodología ágil constituye una serie de
principios y la metodología scrum es un marco
de trabajo para conseguir resultados.
¿Qué son los Sprint?
Un sprint es un período breve de tiempo fijo en el que un equipo de scrum trabaja para
completar una cantidad de trabajo establecida.

¿CÓMO
PLANIFICAR Y
EJECUTAR
SPRINT DE LA
METODOLOGÍA
SCRUM?
SPRINT PLANNING
Es un evento de colaboración donde el equipo responde a dos preguntas básicas: qué
trabajo se puede llevar a cabo en este sprint y cómo se realizará el trabajo escogido.
En la sprint planning comienza el Sprint.
el sprint es un periodo definido de tiempo en el que se hace todo el trabajo.
Se decide cuánto tiempo va a durar, el objetivo del sprint y por dónde vas a empezar.
La sesión de planificación de Sprints inicia el sprint definiendo el orden del día y el
punto de atención.
DAILY SCRUM
El Daily Scrum, conocido comúnmente sólo como “La Daily”, es una reunión diaria
de 15 minutos en la que participa exclusivamente el Development Team.
En esta reunión todas y cada una de las personas del Development Team responden a
las siguientes preguntas:
¿Qué hice ayer para contribuir al Sprint Goal?
¿Qué voy a hacer hoy para contribuir al Sprint Goal?
¿Tengo algún impedimento que me impida entregar?
SPRINT REVIEW
El Sprint Review es la reunión que ocurre al final del Sprint, generalmente el último
viernes del Sprint, donde el product owner y el Develpment Team presentan a los
stakeholders el incremento terminado para su inspección y adaptación
correspondientes. En esta reunión organizada por el product owner se estudia cuál es
la situación y se actualiza el Product Backlog con las nuevas condiciones que puedan
afectar al negocio.
SPRINT RETROSPECTIVE
La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En
algunos casos y por comodidad de los equipos, se realiza conjuntamente con el
Sprint Planning, siendo la retrospectiva la parte inicial de la reunión.
El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e
identificar posibles mejoras para el próximo. Aunque lo habitual es que el Scrum
Master sea el facilitador, es normal que distintos miembros del equipo Scrum vayan
rotando el rol de facilitador durante la retrospectiva.
ROLES
EN
SCRUM
HISTORIA DE USUARIO
HISTORIAS DE USUARIO
Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un
objetivo final, no una función, expresado desde la perspectiva del usuario del
software.
Una historia de usuario es una explicación general e informal de una función de
software escrita desde la perspectiva del usuario final o cliente.
El propósito de una historia de usuario es articular cómo un elemento de trabajo
entregará un valor particular al cliente.
Las historias de usuario son unas pocas frases en lenguaje sencillo que describen el
resultado deseado. No entran en detalles, ya que los requisitos se añaden más tarde,
una vez acordados por el equipo.
¿POR QUÉ CREAR HISTORIAS
DE USUARIO?
Las historias centran la atención en el usuario. Una lista de tareas pendientes
mantiene al equipo centrado en tareas que deben completarse, pero un conjunto de
historias lo mantiene centrado en solucionar problemas para usuarios reales.
Las historias permiten la colaboración. Con el objetivo definido, el equipo puede
colaborar para decidir cómo ofrecer un mejor servicio al usuario y cumplir con dicho
objetivo.
Las historias impulsan soluciones creativas. Las historias fomentan que el equipo
piense de forma crítica y creativa sobre cómo lograr mejor un objetivo.
Las historias motivan. Con cada historia el equipo de desarrollo disfruta de un
pequeño reto y una pequeña victoria, lo que aumenta la motivación.
HISTORIAS DE USUARIO
Definición de “Listo”: la historia suele estar “lista” cuando el usuario puede completar
la tarea descrita, pero debes asegurarte de definir lo que representa completarla.
Describe tareas o subtareas: decide qué pasos específicos deben completarse y quién es
responsable de cada uno de ellos.
Perfiles de usuario: ¿para quién? Si hay varios usuarios finales, considera crear varias
historias.
Pasos ordenados: escribe una historia para cada paso en un proceso más grande.
Escucha el feedback: habla con los usuarios y capta sus problemas o necesidades en lo
que dicen. No es necesario tener que estar adivinando las historias cuando puedes
obtenerlas de tus clientes.
HISTORIAS DE USUARIO
Tiempo: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar
sobre el tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado
que las historias deberían completarse en un sprint, aquellas que puedan necesitar
semanas o meses deberían dividirse en historias más pequeñas o considerarse un epic
independiente.
HISTORIAS DE USUARIOS
Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:
“Como [perfil], [quiero] [para].”
“Como [perfil]”: ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el
perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte
hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa y
cómo se siente. Sentimos empatía por Max.
“Quiere”: aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están
intentando lograr realmente? Esta descripción debería realizarse con independencia de las
implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás
cometiendo un error.
“Para”: ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el
beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?
HISTORIAS DE USUARIO
Ejemplos:
Como Max, quiero invitar a mis amigos, para que podamos disfrutar de este servicio
juntos.
Como Sascha, quiero organizar mi trabajo, para poder sentir que tengo un mayor
control.
Como gestor, quiero poder comprender el progreso de mis compañeros, para poder
informar sobre nuestros éxitos y fallos.
HISTORIAS DE USUARIOS
menudo las historias de usuario se expresan de la siguiente manera: perfil + necesidad
+ propósito.

Estimaciones: Story Points

-los Story Points o puntos de historia son una de las herramientas de Scrum preferidas
de los equipos de desarrollo. no se centra en una duración hipotética, sino en la
cantidad de esfuerzo que hay que realizar para lograr un objetivo o tarea.
-¿Qué son los Story Points?
-Los puntos de historia se definen como una unidad de medida utilizada principalmente
en la gestión de proyectos ágiles de la metodología Scrum. Se utilizan para estimar la
carga de trabajo global de los equipos, con el fin de planificar cada sprint o iteración.
HISTORIAS DE USUARIO
Se asigna un número o valor a cada user story (o historia de usuario) para evaluar el
esfuerzo total que debe asignarse a su realización. Por lo tanto, la estimación en Story
Points debe considerar todos los parámetros que afectarán a este esfuerzo:
La cantidad de trabajo a realizar,
la complejidad de las tareas,
cualquier riesgo o incertidumbre ,
las capacidades técnicas del equipo.
STORY POINTS VS HORAS DE
TRABAJO
Sencillamente porque esta fluctúa en función de las personas. Por ejemplo, un
desarrollador senior y un desarrollador junior no necesitarán la misma cantidad de
tiempo para completar una tarea similar. Los Story Points eliminan este problema
porque la estimación ya no depende de la persona encargada de la historia de
usuario, sino de todos los otros factores ya mencionados (complejidad, riesgo y
repetición).
En pocas palabras, se trata de asignar un puntaje a una actividad comparándola con
otras actividades que han sido previamente evaluadas y resultan más familiares.
¿CUÁNDO SE CALCULAN LOS
PUNTOS DE HISTORIA?
Los puntos de historia se asignan generalmente durante la definición de los
escenarios de usuario, más concretamente durante el backlog grooming.
Antes de cada sprint, el propietario del producto prioriza las futuras user story en las
que debe trabajar. A continuación, el equipo del proyecto realiza una estimación del
esfuerzo necesario para completarlos, ya que dispone de un tiempo limitado (un
sprint) para terminar las tareas seleccionadas.
Es importante que todo el equipo actúe conjuntamente para determinar los puntos de
la historia. De hecho, cada miembro tiene sus propios conocimientos y experiencia en
lo que respecta a las particularidades de cada desarrollo.
 HISTORIAS DE USUARIO
Puntos de historia → pasos para calcularlos
Los valores y significados de los puntos de historia son específicos de cada proyecto y cada
organización. Sin embargo, algunas reglas siguen siendo universales:
A cada historia, independientemente de su naturaleza, se le asigna un determinado número de
puntos.
La cuantificación del esfuerzo por punto de historia debe permanecer estable en cada sprint, y de
una historia a otra.
2 puntos de historia equivalen al doble del esfuerzo correspondiente a 1 punto de historia. 3
puntos de historia es 3 veces el esfuerzo de 1 punto de historia... Y así sucesivamente.
No importa el número de puntos que otorgue, lo que importa es la proporción.
Al final, los puntos de historia son una herramienta para demostrar el esfuerzo relativo entre cada
historia de usuario y cada sprint.
HISTORIAS DE USUARIO
Story Points → Fibonacci
Existen diferentes tipos de escala, sin embargo la más popular es la sucesión de
Fibonacci: una serie de números cuya suma de los dos últimos dará como resultado el
siguiente número y así sucesivamente:
j
HISTORIAS DE USUARIO
Analizar los Story Points
Una vez que se han determinado los valores asociados a los los puntos de historia, y
antes de hacer estimaciones concretas para los diferentes escenarios de usuario, se
debe analizar:
La naturaleza de las futuras tareas a realizar,
su complejidad,
los riesgos e incertidumbres que el equipo puede encontrar en el camino.
 DEFINITIONS OF DONE
La Definición de Listo es un conjunto acordado de elementos que deben completarse antes de que un
proyecto o una historia de usuario puedan considerarse completos. Se aplica consistentemente y sirve
como una puerta oficial que separa las cosas de "en progreso" a "terminadas".
una definición típica de hecho consiste en una lista de verificación que contiene elementos como:
El código es revisado por pares
El código está registrado
El código se implementa en el entorno de prueba.
El código/función supera las pruebas de regresión
El código/función pasa la prueba de humo
El código está documentado
La documentación de ayuda está actualizada.
La función está aprobada por las partes interesadas
KANBAN
KANBAN
Kanban es una de las metodologías de desarrollo de software más populares
adaptadas por los equipos ágiles en la actualidad. Kanban presenta varias ventajas
adicionales en la planificación de tareas y el rendimiento de equipos de todos los
tamaños.
 ERROR DE SOFTWARE
Un error de software, error o simplemente fallo (también conocido por el inglés, bug) es un
problema en un programa de computador o sistema de software que desencadena un
resultado indeseado. Los programas que ayudan a la detección y eliminación de errores de
software son denominados depuradores (en inglés, debuggers).
 DIFERENCIA ENTRE SEVERIDAD Y
PRIORIDAD EN LAS PRUEBAS
Severidad: la severidad se define como la medida en que un defecto en particular puede crear
un impacto en el software. La severidad es un parámetro para denotar la implicación y el
impacto del defecto en la funcionalidad del software.
Prioridad: La prioridad se define como el parámetro que decide el orden en el que se debe
corregir un defecto. El defecto que tiene la prioridad más alta debe corregirse primero.
DIFERENCIA ENTRE SEVERIDAD Y
PRIORIDAD EN LAS PRUEBAS:
GRAVEDAD PRIORIDAD
La severidad es un parámetro para La prioridad es un parámetro para
denotar el impacto de un defecto decidir el orden en el que se deben
particular en el software. corregir los defectos.
Severidad significa la gravedad del Prioridad significa la rapidez con la
defecto que afecta la funcionalidad. que se debe corregir el defecto.
La prioridad está relacionada con la
La severidad está relacionada con el
programación para resolver el
estándar de calidad.
problema.
El ingeniero de pruebas decide el nivel El gerente de producto decide las
de gravedad del defecto. prioridades de los defectos.
Su valor es objetivo. Su valor es subjetivo.
Su valor no cambia de vez en cuando. Su valor cambia de vez en cuando.
La gravedad es de 5 tipos: crítica, La prioridad es de 3 tipos: baja, media
mayor, moderada, menor y cosmética. y alta.
SEVERIDAD DE UN DEFECTO
La gravedad del defecto es la clasificación de un defecto en función de su nivel de
impacto destructivo en la especificación de requisitos del Software.
Crítico -
un defecto que obstruye por completo la ejecución de una función / característica
central del software se clasifica como defecto crítico. Este defecto afecta las
funcionalidades y los datos críticos y dificulta la prueba del software
 SEVERIDAD
Mayor: un defecto que hace que una funcionalidad / característica principal se comporte de
manera muy diferente a lo que se especifica en la especificación de requisitos del software
se clasifica como un defecto mayor. Este defecto afecta a las principales funcionalidades y
datos
Menor: un defecto que ocurre cuando una funcionalidad / característica no se comporta
como se esperaba o exhibe un comportamiento antinatural, sin embargo, la funcionalidad /
característica en su conjunto no se ve muy afectada se clasifica como un defecto menor.
Trivial: cualquier defecto cosmético, como imágenes extraviadas, errores de ortografía o
problemas de alineación o la carcasa de la fuente, se clasifica como un defecto trivial. Este
defecto no afecta a las funcionalidades ni a los datos.
MEJORA DE PROCESOS EN EL PROCESO
DE GESTIÓN DE DEFECTOS (DMP)
En el proceso de gestión de defectos (DMP) , los defectos identificados se priorizan
en primer lugar de acuerdo con su gravedad y luego se corrigen

Objetivos del proceso de gestión de defectos (DMP):

1. El grupo de alta dirección debe comprender la gravedad del defecto y cómo
puede afectar al sistema, para que puedan apoyar a los miembros del equipo y ser
parte de DMP.
2. Para mejorar el proceso, DMP debe realizarse en cada etapa y durante todo el
ciclo de vida del desarrollo de software (SDLC) .Cada equipo debe usar DMP
porque este proceso es muy efectivo para mejorar el proceso.
MEJORA DE PROCESOS EN EL PROCESO
DE GESTIÓN DE DEFECTOS (DMP)
3 Los diferentes proyectos tienen diferentes objetivos, por lo que en función del objetivo del
proyecto, se deben elegir enfoques de
4 desarrollo y deben integrarse en el proceso de desarrollo de software.
5 El proceso debe revisarse con regularidad para identificar defectos en las primeras etapas
del proceso, lo que también será menos costoso.
6 Se debe hacer un esfuerzo para reducir la aparición de defectos de las siguientes maneras:
Revisar escenarios de prueba y casos de prueba
Revisar e integrar requisitos funcionales y no funcionales.
Revisar los requisitos técnicos
Líneas de base ambientales
CRITERIOS DE ACEPTACIÓN
los criterios de aceptación como “las condiciones que un producto de software debe
satisfacer para ser aceptado por un usuario, cliente o stakeholder. Son estándares
preestablecidos o requerimiento que un producto o proyecto debe satisfacer.
Concretamente y yendo al mundo de las metodologías ágiles, en se los define como
un conjunto de sentencias redactadas de tal manera que conduzcan a una respuesta
clara de “aceptado/rechazado”. Deben especificar tanto requerimientos funcionales
como no funcionales. Un hecho importante es que una US bajo un dado criterio de
aceptación, es un comportamiento binario: lo cumple o no lo cumple.
Los criterios de aceptación limita el alcance de una US le permite al equipo de
desarrollo tener una noción más tangible de la funcionalidad detrás de cada US.
 BENEFICIOS DE CA
Remueve ambigüedades de los requerimientos.
Promueve la calidad del desarrollo desde el momento en que el equipo realiza las
entregas de los requerimientos adhiriendo a los criterios de aceptación
Constituirán la base para los casos de prueba que confirmarán si una dada
funcionalidad está completa y se comporta como era esperado.
las US usualmente se anotan en tarjetas o stickers, las cuales contienen detalles
adicionales, como los criterios de aceptación.
conversar sobre detalles del alcance de la US que surgirán de la interacción con el
Product Owner.
los criterios de aceptación confirmarán la funcionalidad de una US.
EJEMPLOS DE CA

Un usuario no puede enviar un formulario sin completar todos los campos obligatorios.
La información del formulario se almacena en la base de datos de participantes.
Está funcionando el filtro Anti-SPAM.
El pago puede efectuarse con tarjeta de crédito.
Se envía un mensaje de “Registración recibida” luego de recibir la información del
formulario.
Un usuario no puede registrarse con la misma información de otro usuario.
Se deberá chequear por dirección de mail.
Se podrá acceder con el login de Facebook o Google+.
¿QUÉ SON LAS PRUEBAS?
Las pruebas de software (Software Testing) comprenden el conjunto de actividades
que se realizan para identificar posibles fallos de funcionamiento, configuración o
usabilidad de un programa o aplicación, por medio de pruebas sobre el
comportamiento del mismo.

¿Qué es un test case?

un caso de prueba o test case es un conjunto de condiciones o variables bajo las
cuales un analista determinará si una aplicación, un sistema de software (software
system), o una característica de éstos es parcial o completamente satisfactoria. Es
decir, un caso de prueba es un conjunto de pasos y resultados esperados que se crean
a partir de los requisitos del software que se va a probar.
 CASOS DE PRUEBA
los casos de pruebas deben ser escritos de manera clara y compresibles. Además de permitir
que se ejecuten para revisar nuevas funcionalidades
Cuando un caso de prueba finaliza su estado podrá ser:
Pasado: si todos los pasos a ejecutar han sido correctos.
Fallado: si uno o varios pasos han sido erróneos.
Bloqueado: si un caso de prueba anterior bloquea las funciones de los posteriores casos de
prueba.
N/A: si un caso de prueba definido ya no aplica al haber habido cambios en la funcionalidad
o requisitos.
CASOS DE PRUEBA
Pasos que debes tener en cuenta.
1) Identificar los requerimientos a probar y nombrar o numerarlos casos de prueba por cada
requisito (establecer un identificador para cada caso de prueba).
2) Realizar un matriz de trazabilidad para vincularlos requerimientos y los casos de prueba entre sí.
3) Escribir una descripción general breve del caso de prueba, que permita a cualquier persona sin
conocimientos previos, comprender de qué trata el caso de prueba.
4) Conocer cuál es la configuración no los prerrequisitos(los datos, el hardware, el software, etc.) a
tener en cuenta para poder ejecutar la prueba.:
A. Definir la prioridad de ejecución de cada caso de prueba (alta, media o baja).
B. Describir los pasos necesarios para poder realizar cada caso de prueba.
C. Describir el resultado esperado y evidenciar el resultado obtenido (si la ejecución fue exitosa o
no).
PROTOCOLOS
TCP/IP

Los protocolos son conjuntos de normas para

formatos de mensaje y procedimientos que
permiten a las máquinas y los programas de
aplicación intercambiar información. Cada
máquina implicada en la comunicación debe
seguir estas normas para que el sistema
principal de recepción pueda interpretar el
mensaje. El conjunto de protocolos TCP/IP
puede interpretarse en términos de capas (o
niveles).

Esta figura muestra las capas del

protocolo TCP/IP. Empezando por la parte
superior son: capa de aplicación, capa de
transporte, capa de red, capa de interfaz de red
y hardware.
TCP/IP define cuidadosamente cómo se mueve la información
desde el remitente hasta el destinatario. En primer lugar, los
programas de aplicación envían mensajes o corrientes de datos a
uno de los protocolos de la capa de transporte de
Internet, UDP (User Datagram Protocol) o TCP (Transmission
Control Protocolo). Estos protocolos reciben los datos de la
aplicación, los dividen en partes más pequeñas llamadas paquetes,
añaden una dirección de destino y, a continuación, pasan los
paquetes a la siguiente capa de protocolo, la capa de red de
Internet.
MODELO
TCP/IP
La capa de red de Internet pone el
paquete en un datagrama
de IP (Internet Protocol), pone la
cabecera y la cola de datagrama,
decide dónde enviar el datagrama
(directamente a un destino o a una
pasarela) y pasa el datagrama a la
capa de interfaz de red.
La capa de interfaz de red acepta
los datagramas IP y los transmite
como tramas a través de un
hardware de red específico, por
ejemplo redes Ethernet o de Red en
anillo.
MODELO TCP/IP
TCP/IP proporciona recursos que convierten el sistema en un
sistema principal de Internet, que se puede conectar a una red y
comunicar con otros sistemas principales de
Internet. TCP/IP incluye mandatos y recursos que permiten:
• Transferir archivos entre sistemas
• Iniciar sesiones en sistemas remotos
• Ejecutar mandatos en sistemas remotos
• Imprimir archivos en sistemas remotos
• Enviar correo electrónico a usuarios remotos
• Conversar de forma interactiva con usuarios remotos
• Gestionar una red
¿QUÉ SON LOS WS?
Una pieza de software que utiliza un conjunto de protocolos y standares que sirven
para intercambiar datos entre aplicaciones que pueden ser desarrolladas en diferentes
lenguajes de programación y pueden ser ejecutada sobre cualquier plataforma todo
esto sobre internet.
Para el desarrollo de servicios web existen dos tecnologías que son fundamentales
SOAP y REST.
¿QUÉ ES UNA API?

La palabra API es un acrónimo que

significa Interfaz de Programación de
Aplicaciones (Application
Programming Interface). Es un
sistema que funciona como
intermediario entre diferentes
aplicaciones de software y su función
es permitir que estas aplicaciones
puedan comunicarse entre sí. Cada
vez que usas una app como
WhatsApp, Instagram o Facebook,
estás usando una API sin saberlo.
¿QUÉ ES REST?
Qué es REST
REST es un estilo de arquitectura de software enfocado en el intercambio de
recursos y basado en HTTP. Le agrega una capa muy delgada de complejidad y
abstracción a HTTP. Mientras que HTTP es transferencia de archivos, REST se basa
en la transferencia de recursos.
¿ que es una Api Rest full?
Api: application programming interface(interfaz de programación de aplicaciones)
Rest: Representation State transfer (Transferencia de estado representacional)
API REST: interfaz de aplicaciones para transferir datos
¿QUÉ ES UNA API REST O API
RESTFUL?
Una API RESTful es una interfaz que utiliza los principios de REST para comunicarse hacia y desde un
servidor. El principio más importante en las APIs RESTful es el uso de los métodos HTTP:

GET

POST

PUT

DELETE

Estos métodos son empleados por los clientes para crear, manipular y eliminar datos en los servidores,
respectivamente.
CÓMO
FUNCIONA
REST
REST es un conjunto de principios que
definen la forma en que se deben crear,
leer, actualizar y eliminar los datos. Es
una arquitectura conocida como
cliente-servidor, en la que el servidor y
el cliente actúan de forma
independiente, siempre y cuando la
interfaz sea la misma al procesar una
solicitud y una respuesta, que son los
elementos esenciales.
El servidor expone la API REST y el
cliente hace uso de ella. El servidor
almacena la información y la pone a
disposición del usuario, mientras que
el cliente toma la información y la
muestra al usuario o la utiliza para
realizar posteriores peticiones de más
información.
INFRAESTRUCTURA
DE LA API DE REST

La API de REST forma parte de la

infraestructura de integración y
maneja las solicitudes de los
clientes externos.
El diagrama siguiente proporciona
una visión general de cómo la API
de REST maneja las solicitudes.
MANEJADORES DE RECURSOS
Y URI
La API de REST proporciona acceso a objetos de negocio y estructuras de objeto de
integración. Se registra una clase de manejador para cada recurso en una región propiedad
del sistema./
Las clases de manejador para los recursos de objeto de negocio y de estructura de objeto se
registran en las propiedades del sistema mxe.rest.handler.mbo y mxe.rest.handler.os.
Puede ampliar manejadores para proceso personalizado. Puede crear manejadores para
otros tipos de recurso y para instancias individuales de recursos de objeto de negocio o de
estructura de objeto.
Los recursos de la API de REST se direccionan utilizando los identificadores de recurso
que forman parte del URI (identificador universal de recursos). Los URI se utilizan para
direccionar las entidades que se representan como recursos REST.
LOS Los métodos son usados para manipular los diferentes recursos
que conforman la API. Los principales métodos soportados por

VERBOS
HTTP y por ello usados por una API REST son:

HTTP POST: crear un recurso nuevo.

INVOLUCRA
DOS EN UN
PUT: modificar un recurso existente.

SISTEMA GET: consultar información de un recurso.

REST SON
GET, POST, DELETE: eliminar un recurso determinado.

PUT, PATCH
Y DELETE. PATCH: modificar solamente un atributo de un recurso.
SERVICIOS REST
Estos métodos junto con la URI, nos proporciona una interfaz
uniforme que nos permite la transferencia de datos en el sistema REST
aplicando operaciones concretas sobre un recurso determinado. Aunque la
mayoría de las operaciones que componen una API REST podrían llevarse a
cabo mediante métodos GET y POST, el abuso de ellos para operaciones
que nada tienen que ver con el propósito con el que se concibieron, puede
provocar un mal uso del protocolo alejado del estándar o la construcción
de URIs con nomenclatura errónea mediante el uso de verbos.
Cuando se realiza una petición determinada, es de vital importancia
conocer si dicha operación se ha llevado a cabo de manera satisfactoria o
por el contrario se ha producido algún tipo de error. Para ello, HTTP
dispone de un amplio número de códigos de error/éxito.
SERVICIOS REST
200 OK. Respuesta estándar para peticiones correctas.

201 Created. La petición ha sido completada y ha resultado en la creación de un nuevo recurso.

202 Accepted. La petición ha sido aceptada para procesamiento, pero este no ha sido completado.

400 Bad Request. La solicitud contiene sintaxis errónea.

403 Forbidden. La solicitud fue legal, pero el servidor rehúsa responder dado que el cliente no tiene los privilegios para hacerla.

404 Not Found. Recurso no encontrado. Se utiliza cuando el servidor web no encuentra la página o recurso solicitado.

500 Internal Server Error. Es un código comúnmente emitido por aplicaciones empotradas en servidores web, cuando se encuentran
con situaciones de error ajenas a la naturaleza del servidor web.
¿CUÁL ES LA PRINCIPAL
VENTAJA DE UNA API REST?
La principal ventaja del uso de una API REST reside en la independencia que
proporciona frente a cualquier consumidor, sin importar el lenguaje o plataforma con
el que se acceda a ella. Esto permite que una misma API REST sea consumida por
infinidad de clientes sea cual sea la naturaleza de estos y que el cambio a cualquier
otro tipo de consumidor no provoque impacto alguno en ella. Esta característica
proporciona fiabilidad, escalabilidad y una fácil portabilidad a cualquier otra
plataforma, ya que aisla por completo al cliente del servidor. Sólo se requiere que el
intercambio de información de las respuestas se haga en un formato soportado, por
lo general JSON o XML. Dicha separación entre el cliente y el servidor hace que se
pueda migrar a otros servidores o bases de datos de manera transparente, siempre y
cuando los datos se sigan enviado de manera correcta. Esto convierte a las APIs
REST en una de las arquitecturas web más utilizadas por la flexibilidad que aportan
a cualquier entorno de trabajo sea cual sea su naturaleza.
PRUEBAS ¿Que miden las pruebas de performance?

DE La prueba de rendimiento es una técnica de prueba de

software no funcional que determina cómo la
PERFORM estabilidad, la velocidad, la escalabilidad y la
capacidad de respuesta de una aplicación se mantiene
ANCE bajo una determinada carga de trabajo.
 LOAD ¿Que miden las pruebas de carga?
Las pruebas de carga y rendimiento son los procesos
TEST - en los cuales introducimos cargas de trabajo a un
sistema para determinar su comportamiento en
JMETER condiciones de carga normal o carga máxima.
 JMETER
¿Qué es JMETER?
JMeter es una herramienta de testing cuyas funcionalidades se pueden resumir en tres:
1. Diseñar un testplan, esto es, generar un fichero .jmx
2. ejecutar un testplan
3. Ver de distintas formas los resultados de la ejecución de un testplan (vía
listeners)Para diseñar un testplan, JMeter dispone de una interfaz GUI a modo de
diseñador, en la que el tester puede ir agregando componentes de manera visual, y
ejecutar los componentes agregados, viendo el resultado. Una vez finalizado el
diseño del testplan, la herramienta permite grabar este como un fichero .jmx.
¿QUÉ ES JMETER?
La propia herramienta permite ejecutar un fichero .jmx previamente generado, vía
línea de comandos o vía la propia interfaz GUI. La ejecución de un fichero .jmx
realiza peticiones contra la aplicación objetivo a testear (peticiones del tipo que se
hayan especificado al generar el fichero .jmx, JMeter dispone de la posibilidad de
generar muchos tipos de peticiones: HTTP, FTP, LDAP, ...). Para cada petición
ejecutada, JMeter recopila ciertos datos. Además, en el fichero .jmx se puede
especificar que número de usuarios de cada tipo ejecuta las peticiones contra la
aplicación, es decir, el .jmx simula una o mas comunidades de usuarios (roles)
trabajando contra la aplicación objetivo
¿QUÉ ES JMETER?
Los datos generados por la herramienta para cada petición se procesan o bien con un
tipo de componente que proporciona la interfaz GUI llamados listeners, o bien con
herramientas externas. Los listeners permiten ver los resultados de una o mas
ejecuciones de múltiples maneras (cada listener de una manera).
Este manual es una introducción al uso de la herramienta JMeter. Explica los
conceptos básicos que es necesario conocer para entender la herramienta, y las
posibles formas de utilizar ésta.
Es adecuado tanto para personas con un perfil técnico sin conocimientos previos que
deseen iniciarse en el uso de la herramienta, como para diretores, jefes de proyecto y
analistas que deseen conocer las posibilidades de la herramienta en la ejecución de
tests.
INSTALACIÓN,
CONFIGURACIÓN, Y ACCESO A
LA DOCUMENTACIÓN
Descargar el software de http://jakarta.apache.org/jmeter/
Documentación:
La documentación online de la última versión del producto puede consultarse en
http://jakarta.apache.org/jmeter/usermanual. Los apartados del manual 18.
Component reference y 19. Functions se utilizan muy frecuentemente como
referencia durante la construcción de un testplan.
 Los listeners son uno de los tipos de componentes de un tesplan (más sobre los tipos de
componentes de un testplan en Interfaz GUI y Tipos de componentes de un testplan, ámbito y orden
de ejecución).

La importancia que tienen los listeners respecto a los otros tipos de componentes es que procesan las
peticiones realizadas a la aplicación objetivo por los samplers del testplan, y muestran el resultado
del procesamiento de diferentes formas según el tipo de listener de que se trate.

¿QUÉ SON
Se pueden usar los listeners de dos formas:

Si el testplan se ejecuta desde la interfaz GUI, muestran en tiempo real el procesamiento de las
peticiones que realizan los samplers. Así por ejemplo, el listener View Results Tree muestra los

LOS
samplers en el orden en que se ejecutan, y para cada uno de ellos se puede visualizar los datos de la
petición realizada y la respuesta de la aplicación (muy util para depurar un testplan mientras se
construye). Otro ejemplo: el listener Graph Results muestra en forma de gráfica los tiempos de

LISTENER
respuesta de la aplicación objetivo.

Una vez ejecutado el testplan, si se ha generado el fichero sample result, este se puede cargar en el
campo Filename: de un listener (por ejemplo creando un plan vacío que solo contenga el listener

S?
que nos interesa, o creando el componente listener que nos interesa en el componente Workbench de
la interfaz GUI). Al hacer esto, el listener mostrará el resultado de procesar el fichero en un
determinado formato.

Nota: Esta última es la forma como se recomienda trabajar en la ejecución de pruebas de

rendimiento. Resumiendo,

Generar el fichero sample result en formato CSV, vía opción -l de la línea de comando o vía un
listener global del tipo Simple Data Writer.

Una vez ejecutada la prueba de rendimiento, cargar el fichero result sample generado en uno o
varios de los listeners que nos muestren las medidas de rendimiento que queremos obtener.
DESCOMPRIMIR E INGRESAR
ENTRAMOS EN LA CARPETA
BIN
EJECUTAR JMETER.BAT
CREAR UN NUEVO TEST PLAN