Testing. Tipos, Planificación y Ejecución de Pruebas

Transcripción

1 Testing Tipos, Planificación y Ejecución de Pruebas

2 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

3 Testing de Software

4 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.

5 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.

6 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.

7 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).

8 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.

9 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.

10 Test de Performance También llamado Test de Carga. Simula varias transacciones y/o usuarios simultáneos en escenarios promedio y peak.

11 Testing según RUP

12 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.

13 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.

14 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.

15 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

16 Trabajadores Diseñador de pruebas. Ingeniero de componentes. Ingeniero de pruebas de integración. Ingeniero de pruebas de sistema.

17 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.

18 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 Integrador de Sistemas Tester Crear Plan de Pruebas Modelo de Instalación Arquitecto PLAN DE PRUEBAS

19 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 PRUEBAS Modelo de Instalación

20 Ejecución de las Pruebas Plan de Pruebas Modelo de Pruebas Tester Ejecutar Prueba de Funcionalidad REPORTE DE PRUEBAS

21 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

22 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.

23 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

24 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

25 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.

26 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.

27 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?