Testing

Testing
Tipos, Planificación y
Ejecución de Pruebas
Contenido
• Definiciones del Testing de Software
– Objetivos, conceptos
– Tipos de Test
• Testing a-la RUP
– Rol del Testing en el proceso
– Artefactos
– Trabajadores
– Flujo de Trabajo
Testing de Software
¿Qué es el Testing de Software?
• Realización de pruebas conducentes a
comprobar que el software implementado cumple
los requerimientos funcionales/operacionales
definidos.
• Existen diferentes tipos o niveles de pruebas, que
se realizan en diferentes momentos del tiempo y
por algunos actores diferentes.
• Se define un plan de pruebas (lista de tests a
realizar) y uno o más testers llevan a cabo las
pruebas, reportando el resultado.
Testing de Software
• ¿Por qué un software puede fallar luego de
ser desarrollado?
– Los usuarios ejecutaron código que no fue
probado.
– El orden de la secuencia de comandos
ejecutados fue diferente a lo probado.
– El usuario ingreso una serie de
datos no validados.
– El sistema está instalado en un
ambiente donde no fue probado.
Conceptos en Testing
• Caso de prueba: parte de una funcionalidad o uso de
funcionalidad a ser probado por un único test.
• Test Unitario: test de programador sobre componentes
desarrollados.
• Test de Integración: prueba que valida el funcionamiento
coordinado de dos o más módulos desarrollados por
separado.
• Test Funcional: test de usuario/cliente sobre
funcionalidades desarrolladas.
• Test de Cobertura: validación de que el código completo
está controlado y testeado.
• Test de Performance: pruebas orientadas a determinar la
capacidad de la solución de HW/SW en el escenario de
producción esperado.
Test Unitario
• Test diseñado, planificado y ejecutado por
el desarrollador para medir la correctitud de
un componente (por ej, una clase y sus
respectivos métodos).
• Hoy existe una metodología de desarrollo
que se basa en este tipo de test como
motor de la construcción: TDD (que se verá
en detalle más adelante en el curso).
Test de Integración
• Similar al test unitario, pero considerando
módulos independientemente desarrollados
que se unen para esta prueba.
• El test lo puede diseñar y ejecutar un
desarrollador, aunque comúnmente recae
en algún tester senior, un arquitecto, o un
encargado de deployment.
Test Funcional
• Literalmente, la prueba que se basa en lo que un
usuario cualquiera podría hacer.
• Estas pruebas, pese al nombre “test de usuario”,
NO las hacen los usuarios, sino que testers que
modelan y representan los intereses de los
usuarios.
• Se deben realizar en forma sistemática y se debe
registrar sus resultados (por ej, en una planilla).
• Es posible automatizarlos.
Test de Performance
• También llamado
“Test de Carga”.
• Simula varias
transacciones y/o
usuarios
simultáneos en
escenarios
promedio y peak.
Testing según RUP
Definiciones básicas
• La ejecución de pruebas es parte integral del
proceso de construcción, por lo que ya no se
considera una Fase independiente.
– Las pruebas se realizan a continuación del “término”
del desarrollo de un módulo.
– Las pruebas son independientes de otros módulos, por
lo que se realizan y concentran en módulos
específicos.
– Se pueden realizar pruebas a nivel de módulos,
submódulos o cualquier paquete construido que pueda
ser ejecutado y probado independientemente.
– Para realizar las pruebas, se definen Casos de Prueba,
que definen qué se quiere probar y demostrar que
funciona.
Objetivos del Testing
• Planificar pruebas necesarias en c/iteración
(pruebas integración y de sistema).
• Diseñar e implementar pruebas creando casos de
prueba, creando procedimientos de prueba (cómo
se hacen), e idealmente componentes de prueba
ejecutables (para automatización).
• Ejecutar las pruebas y manejar sistemáticamente
los resultados, entregando a desarrolladores el
feedback necesario para volver a realizar otro
ciclo de correcciones y pruebas.
El papel del Testing en el ciclo
• Los casos de prueba comienzan a gestarse en la
fase de elaboración, pero se ejecutan durante la
construcción y en transición se intensifican en
particular con tests de integración y de
performance.
Artefactos del Testing
• Modelo de Pruebas
• Caso de Prueba
• Procedimiento de Prueba: generales y
específicos.
• Componente de Prueba
• Plan de Prueba
• Defecto
• Evaluación de Prueba
Trabajadores
•
•
•
•
Diseñador de pruebas.
Ingeniero de componentes.
Ingeniero de pruebas de integración.
Ingeniero de pruebas de sistema.
Flujo de Trabajo
• Planificar prueba.
• Diseñar prueba.
–
–
–
–
Diseño de casos de uso de prueba de integración.
Diseño de los casos de prueba de sistema.
Diseño de los casos de prueba de regresión.
Identificación y estructuración de los procedimientos de
prueba.
• Implementar prueba.
• Realizar pruebas integración; sistema
• Evaluar prueba.
Definición del Plan de Pruebas
Describe estrategias, recursos y planificación
de la prueba: definición tipo de pruebas a realizar
en cada iteración y sus objetivos, nivel de
cobertura y de código necesario.
Especificación Req.
Modelo de Análisis
Crear Plan de Pruebas
Integrador de Sistemas
Tester
Modelo de Instalación
Arquitecto
PLAN DE PRUEBAS
Desarrollo del Modelo de Pruebas
Describe cómo se prueban los componentes
ejecutables en el modelo de implementación
con pruebas de integración y sistema.
Especificación
Requerimientos
Modelo de Componentes
Integrador de Sistemas
Tester
Desarrollar Modelo Pruebas
Modelo de BD
Arquitecto
Modelo de Instalación
MODELO DE PRUEBAS
Ejecución de las Pruebas
Plan de Pruebas
Modelo de Pruebas
Tester
Ejecutar Prueba de Funcionalidad
REPORTE DE PRUEBAS
Artefactos
• Plan de Pruebas:
– Introducción: propósito, ámbito (test
unitarios/funcionales), descripciones, referencias.
– Requerimientos para Test:
• Casos de Uso
• Requerimientos Funcionales (comp. comunes, compo1,
comp2).
–
–
–
–
Estrategia de Testing
Recursos: profesionales, ambiente pruebas.
Hitos
Entregables: modelo, resultados, reporte defectos
Asegurando la calidad
• Identificar funcionalidades que el sistema
está entregando.
• Definir cómo c/u de éstas puede ser
probada.
• Estructurar un
Plan de Pruebas.
Plan de Pruebas
• Para crear un plan de pruebas efectivo se deben
considerar múltiples aspectos relacionados con el sistema
que se está probando. Por ej. funcionalidades, ingreso de
datos, ambiente de ejecución, etc.
• Por eso, un Tester profesional debe tener conocimientos y
habilidades en múltiples áreas para poder diseñar un plan
de pruebas efectivo.
• El proceso de pruebas, al igual que las fases de desarrollo
de RUP, tiene 4 fases:
–
–
–
–
Modelar el ambiente del sistema
Elegir los escenarios de pruebas
Ejecutar y evaluar los escenarios de pruebas
Medir el progreso de las pruebas
Fase 1: Modelar el ambiente
• La primera tarea del Tester es simular cómo el sistema se
relaciona con su ambiente. Para esto se deben identificar
todas las interfaces del sistema y los datos que pasan por
las mismas.
• El siguiente paso que el Tester debe hacer es encontrar las
acciones que el usuario puede realizar y que harían que el
software deje de comportarse de manera consistente.
(Redundancia/inconsistencia de datos, errores de
conectividad/operación de elementos, etc.)
• Registrar valores de entrada y salida.
• Uso de expresiones regulares y gramaticales para expresar
los tests: Filemenu.Open filename* (ClickOpen | ClickCancel)
• Técnicas estocásticas y de algoritmos genéticos. Estos
modelos combinan los valores a ingresar y su secuencia
para producir palabras y oraciones sintácticamente
correctas
Fase 2: Elegir escenarios de prueba
• Dominios, grupos de variables, condiciones
de borde.
• Test de cobertura: todo el software
codificado debe haber sido probado.
• Considerar:
– Secuencia optimista.
– Secuencia de excepciones.
Fase 3: Ejecutar las pruebas
• Idealmente tenerlas automatizadas.
– Existen robots para test de interfaces.
– Scripts de BD para los datos.
– Test unitarios en código para las capas lógicas,
datos, y otras.
• Utilizar formalismos o pruebas de código
embebido.
• Pruebas de regresión: testear un módulo ya
probado y corregido.
Fase 4: Medir progreso de pruebas
• Completitud estructural:
– ¿Hemos probado los errores de programación comunes?
– ¿Hemos ejercitado todo el código fuente?
– ¿Hemos forzado todos los datos internos para que sean
inicializados y usados?
– ¿Hemos encontrado todos los errores sembrados?
• Completitud funcional:
– ¿Hemos pasado a través de las formas en que el
sistema puede fallar? ¿Hemos realizado todos los Test
que lo validan?
– ¿Hemos aplicado todas las entradas de datos?
– ¿Hemos explorado todos los estados del sistema?
– ¿Hemos ejecutado todos los escenarios que espero que
el usuario use?