Pruebas de Software. Ingeniería del Software I Universidad Rey Juan Carlos. Verificación de Software: Validación de Software:

Transcripción

1 Pruebas Software Universidad Rey Juan Carlos César Javier Acuña Introducción Verificación Software: Determinar si los productos una fase dada satisfacen las condiciones impuestas al inicio la fase Validación Software: Evaluación un sistema o uno sus componentes durante o al final su sarrollo para terminar si satisface los requisitos. 2 1

2 Introducción Verificación Estamos construyendo correctamente el producto? Validación Estamos construyendo el producto correcto? Las permiten validar y verificar el software 3 Introducción Pruebas (test): «una actividad en la cual un sistema o uno sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación algún aspecto» Caso Prueba (test case): «un conjunto entradas, condiciones ejecución y resultados esperados sarrollados para un objetivo particular» 4 2

3 Introducción Defecto (fect, fault, «bug»): «un fecto en el software como, por ejemplo, un proceso, una finición datos o un paso procesamiento incorrectos en un programa» Fallo (failure): «La incapacidad un sistema o alguno sus componentes para realizar las funciones requeridas ntro los requisitos rendimiento especificados» 5 Introducción Error (error): La diferencia entre un valor calculado, observado o medio y el valor verdaro, especificado o teóricamente correcto. Un fecto Un resultado incorrecto Una acción humana que conduce a un resultado incorrecto. 6 3

4 Introducción Error Equivocación l programador = 5 Sistema gestión aeropuerto Accinte (seguridad) Defecto (calidad) S.Aproximación Xyx//??? Fallo (fiabilidad) 7 Introducción Probar exhaustivamente el SW es imposible Es imposible evaluar todas las posibilidas Un proceso prueba será exitoso cuando encuentre errores Los errores no son siempre fruto la negligencia l programador 8 4

5 Introducción Recomendaciones Cada caso prueba be finir el resultado salida esperado El programador be evitar probar sus propios programas, ya que sea (consciente o inconscientemente) mostrar que funcionan sin problemas Se be inspeccionar a conciencia el resultado cada prueba, así, por scubrir posibles síntomas fectos 9 Introducción Recomendaciones Al generar casos prueba, se ben incluir tanto datos entrada válidos y esperados como no válidos e inesperados. Las ben centrarse en dos objetivos (es habitual olvidar el segundo): Probar si el software no hace lo que be hacer Probar si el software hace lo que no be hacer, es cir, si provoca efectos secundarios adversos 10 5

6 Introducción Recomendaciones Se ben evitar los casos sechables, es cir, los no documentados ni diseñados con cuidado No ben hacerse planes prueba suponiendo que, prácticamente, no hay fectos en los programas y, por lo tanto, dicando pocos recursos a las. 11 Introducción Recomendaciones La experiencia parece indicar que don hay un fecto hay otros, es cir, la probabilidad scubrir nuevos fectos en una parte l software es proporcional al número fectos ya scubierto. Las son una tarea tanto o más creativa que el sarrollo software. Siempre se han consirado las como una tarea structiva y rutinaria. 12 6

7 El Proceso Prueba Planear Planear Plan Diseñar Diseñar Configuración (casos y procedimientos) Ejecutar Ejecutar Información sobre proyecto Información sobre software (ERS, diseño, etc) Configuración Resultados software revisada Resultados esperados Correcciones DESARROLLO DESARROLLO Acciones preventivas (formación, mejora procesos, etc) Predicción fiabilidad Depuración Depuración Análisis Análisis errores errores Errores: histórico e informes Evaluar Evaluar Estadística errores 13 Técnicas Diseño Casos Prueba Utilizamos técnicas para conseguir una confianza aceptable en que se tectarán los fectos existentes Equilibrio entre los recursos empleados y la confiabilidad los casos prueba Elegir los casos prueba que puedan representar a los mas. La elección no be ser al azar 14 7

8 Técnicas Diseño Casos Prueba Existen tres enfoques para el diseño casos prueba: El enfoque estructural o caja blanca El enfoque funcional o caja negra El enfoque aleatorio consiste en utilizar molos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir ellos los casos prueba 15 Técnicas Diseño Casos Prueba Caja blanca Entrada Salida Caja negra Entrada Salida Funciones 16 8

9 Pruebas Estructurales El diseño los casos be basarse en la elección caminos importantes que ofrezcan una seguridad aceptable. Se utilizan criterios cobertura lógica Es conveniente construir un diagrama flujo control (flowchart) 17 Pruebas Estructurales Abrir archivos; Leer archivo ventas, al final indicar no más registros; 1 2 Limpiar línea impresión; WHILE (haya registros ventas) DO 3 Total nacional = 0; Total extranjero = 0; 4 WHILE (haya reg. ventas) y (mismo producto) IF (nacional) THEN Sumar venta nacional a total nacional ELSE Sumar venta extranjero a total extranjero ENDIF; Leer archivo ventas, al final indicar no más registros; ENDWHILE; Escribir línea listado; Limpiar área impresión; ENDWHILE; 7a 5 6 8,9 10,11 7b Cerrar archivos. 12,

10 Pruebas Estructurales Cómo dibujar un grafo flujo Señalar sobre el código cada condición cada cisión tanto en sentencias If-then y Case-of como en los bucles While o Until. Agrupar el resto las sentencias en secuencias situadas entre cada dos condiciones. Numerar tanto las condiciones como los grupos sentencias, manera que se les asigne un intificador único 19 Pruebas Estructurales Criterios Cobertura De Sentencias: Se trata generar los casos prueba necesarios para que cada sentencia o instrucción l programa se ejecute, al menos, una vez. De cisiones: Consiste en escribir casos suficientes para que cada cisión tenga, por lo menos una vez, un resultado verdaro y, al menos una vez, uno falso

11 Pruebas Estructurales De condiciones: Se trata diseñar tantos casos como sea necesario para que cada condición cada cisión adopte el valor verdaro al menos una vez y el falso al menos una vez. De cisión/condición. Consiste en exigir el criterio cobertura condiciones obligando a que se cumpla también el criterio cisiones. De condición múltiple. En el caso que se consire que la evaluación las condiciones cada cisión no se realiza forma simultánea. 21 Pruebas Estructurales La cobertura caminos es el criterio mas elevado Cada camino be ser probado Caminos prueba: ejecutar cada bucle por lo menos una vez Utilizando caminos prueba se pue cuantificar la cantidad caminos (permite asignar correctamente los recursos) 22 11

12 Pruebas Estructurales Complejidad Ciclomática McCabe (V(G)) Empleada para terminar el Nº caminos inpendientes. Valor la métrica es un buen criterio V(G) a-n+2, siendo a el número arcos y n el número nodos r, siendo r el número regiones cerradas c+1, sindo c el número nodos condición 23 Pruebas Estructurales 1 a1 a2 a3 2 a4 3 Región 1 a5 a6 a7 4 Región 2 a9 a8 5 Región 3 a10 a11 6 a12 Región a13 a Región

13 Pruebas Estructurales Para elegir los caminos inpendientes a probar se utiliza el método l camino básico Consiste en realizar variaciones sobre un camino prueba típico que llamamos básico Pruebas Funcionales Particiones o Clases Equivalencia Las cualidas que finen un buen caso prueba: Cada caso be cubrir el máximo número entradas Debe tratarse el dominio valores entrada dividido en un número finito clases equivalencia que cumplan la siguiente propiedad: la prueba un valor representativo una clase permite suponer «razonablemente» que el resultado obtenido (existan fectos o no) será el mismo que el obtenido probando cualquier otro valor la clase 26 13

14 Pruebas Funcionales El método consiste entonces en: Intificación las clases equivalencia Creación los casos prueba correspondientes Intificación las Clases Equivalencia Intificar las restricciones al formato y contenido los datos las entradas Intificar las clases equivalencia: De datos Válidos De Datos no Válidos o Erróneos 27 Pruebas Funcionales Existen algunas reglas que ayudan a intificar clase: Si se especifica un rango valores para los datos entrada, se creará una clase válida y dos clases no válidas Si se especifica un número valores, se creará una clase válida y dos no válidas Si se especifica una situación l tipo «be ser» o booleana (por ejemplo, «el primer carácter be ser una letra»), se intifican una clase válida («es una letra») y una no válida («no es una letra») 28 14

15 Pruebas Funcionales Si se especifica un conjunto valores admitidos y se sabe que el programa trata forma diferente cada uno ellos, se intifica una clase válida por cada valor y una no válida. En cualquier caso, si se sospecha que ciertos elementos una clase no se tratan igual que el resto la misma, ben dividirse en clases menores. Desarrollar los casos prueba Este proceso consta los siguientes pasos Asignación un número único a cada clase equivalencia 29 Pruebas Funcionales Hasta que todas las clases equivalencia hayan sido cubiertas por (incorporadas a) casos prueba, se tratará escribir un caso que cubra tantas clases válidas no incorporadas como sea posible Hasta que todas las clases equivalencia no válidas hayan sido cubiertas por casos prueba, escribir un caso para una única clase no válida sin cubrir

16 Pruebas Funcionales Ejemplo: Especificación Código área: número 3 dígitos que no empieza ni por 0, ni por 1. Nombre intificación: 6 caracteres. Ornes posibles: "cheque", "pósito", "pago factura", "retirada fondos". 31 Pruebas Funcionales Ejemplo: Condición entrada Clases válidas Clases inválidas Código área (1) 200 código 999 (2) código <200 (3) código >999 (4) no es número Nombre para intificar la operación Orn (8) «cheque» (9) «pósito» (10) «pago factura» (11) «retirada fondos» (5) seis caracteres (6) menos 6 caracteres (7) más 6 caracteres (12) ninguna orn válida 32 16

17 Pruebas Funcionales Casos válidos: 300 Nomina Depósito (1) (5) (9) 400 Viajes Cheque (1) (5) (8) 500 Coches Pago Factura (1) (5) (10) 600 Comida Retirada Fondos (1) (5) (11) Casos No Válidos 180 (2) 1032 (3) XY (4) <CR> (6) Regalos (7) Casa (12) 33 Pruebas Funcionales Análisis Valores Límites (AVL) Exploran las condiciones límites un programa. Técnica Complementaria a las Clases Equivalencia. Diferencias: Más que elegir «cualquier» elemento como representativo una clase equivalencia, se requiere la selección uno o más elementos tal que los márgenes se sometan a prueba

18 Pruebas Funcionales Más que elegir «cualquier» elemento como representativo una clase equivalencia, se requiere la selección uno o más elementos tal que los márgenes se sometan a prueba. Más que concentrarse únicamente en el dominio entrada (condiciones entrada), los casos prueba se generan consirando también el espacio salida Reglas: 1) Si una condición entrada especifica un rango valores, se ben generar casos para los extremos l rango y casos no válidos para situaciones justo más allá los extremos 35 Pruebas Funcionales 2) Si la condición entrada especifica un número valores, hay que escribir casos para los números máximo, mínimo, uno más l máximo y uno menos l mínimo valores 3) Usar la regla 1 para la condición salida 4) Usar la regla 2 para cada condición salida En esta regla 3 y 4, be recordarse que: los valores límite entrada no generan necesariamente los valores límite salida no siempre se puen generar resultados fuera l rango salida (pero es interesante consirarlo)

19 Pruebas Funcionales 5) Si la entrada o la salida un programa es un conjunto ornado (por ejemplo, una tabla, un archivo secuencial,...), los casos ben concentrarse en el primero y en el último elemento 37 Pruebas Funcionales Conjetura Errores Enumerar una lista errores comunes En función ella elaborar los casos prueba Es importante la intuición y la experiencia Ejemplos: El valor cero es una situación propensa a error tanto en la salida como en la entrada Cuando se introduce un número variable valores, centrarse en el caso no introducir ningún valor y en el un solo valor. También pue ser interesante un lista que tiene todos los valores iguales 38 19

20 Pruebas Funcionales Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificación También interesa imaginar lo que el usuario pue introducir como entrada a un programa 39 Pruebas Aleatorias Se simula la entrada datos habitual un programa. Se crean datos que sigan la frecuencia y la secuencia que tendrían en la práctica Se usan generadores : Descripción datos Secuencias entradas posibles Probabilidad ocurrencia 40 20

21 Enfoque práctico para generar los casos prueba Si la especificación contiene combinaciones condiciones entrada, comenzar formando sus grafos causa-efecto (ayudan a la comprensión dichas combinaciones). En todos los casos, usar el análisis valores-límites para añadir casos prueba: elegir límites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase equivalencia. 41 Enfoque práctico para generar los casos prueba Intificar las clases válidas y no válidas equivalencia para la entrada y la salida, y añadir los casos no incluidos anteriormente ( cada causa es una única clase equivalencia? Deben dividirse en clases?). Utilizar la técnica conjetura errores para añadir nuevos casos, referidos a valores especiales

22 Enfoque práctico para generar los casos prueba Ejecutar los casos generados hasta el momento ( caja negra) y analizar la cobertura obtenida (usar herramientas análisis cobertura) Examinar la lógica l programa para añadir los casos precisos ( caja blanca) para cumplir el criterio cobertura elegido. 43 Documentación l Diseño Pruebas Documentos relacionados con el diseño según IEEE std Plan Plan Especificación Especificación diseño diseño Especificación Especificación diseño diseño Especificación Especificación caso caso Especificación Especificación procedimiento procedimiento Ejecución Ejecución 44 Informes 22

23 Documentación l Diseño Pruebas Plan Pruebas Señalar: El enfoque Los recursos El esquema actividas prueba Los elementos a probar Las características Las actividas prueba El personal responsable Los riesgos asociados 45 Documentación l Diseño Pruebas Estructura Fijada en el estándar Intificador único l documento (para la gestión configuración). Introducción y resumen elementos y características a probar. Elementos software que se van a probar (p. ej., programas o módulos). Características que se van a probar. Características que no se prueban. Enfoque general la prueba (actividas, técnicas, herramientas, etc.). Criterios paso/fallo para cada elemento. Criterios suspensión y requisitos reanudación. Documentos a entregar (como mínimo, los scritos en el estándar)

24 Documentación l Diseño Pruebas Estructura Fijada en el estándar Actividas preparación y ejecución. Necesidas entorno. Responsabilidas en la organización y realización las. Necesidas personal y formación. Esquema tiempos (con tiempos estimados, hitos, etc.). Riesgos asumidos por el plan y planes contingencias para cada riesgo. Aprobaciones y firmas con nombre y puesto sempeñado. 47 Documentación l Diseño Pruebas Especificación l Diseño Pruebas Objetivo: Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e intificar las características que se ben probar con este diseño. Estructura Fijada por el estándar: Intificador (único) para la especificación. Proporcionar también una referencia l plan asociado (si existe). Características a probar los elementos software (y combinaciones características)

25 Documentación l Diseño Pruebas Estructura Fijada por el estándar: Detalles sobre el plan l que surge este diseño, incluyendo las técnicas prueba específica y los métodos análisis resultados. Intificación cada prueba: Intificador. Casos que se van a utilizar. Procedimientos que se van a seguir. Criterios paso/fallo la prueba (criterios para terminar si una característica o combinación características ha pasado con éxito la prueba o no). 49 Documentación l Diseño Pruebas Especificación un Caso Prueba Objetivo: finir uno los casos prueba intificado por una especificación l diseño las. Estructura Fijada por el estándar Intificador único la especificación. Elementos software (p. ej., módulos) que se van a probar: finir dichos elementos y las características que ejercitará este caso. Especificaciones cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; p. ej., la sincronización las mismas). Especificaciones todas las salidas y las características requeridas (p. ej., el tiempo respuesta) para los elementos que se van a probar

26 Documentación l Diseño Pruebas Estructura Fijada por el estándar Necesidas entorno (hardware, software y otras como, por ejemplo, el personal). Requisitos especiales procedimiento (o restricciones especiales en los procedimientos para ejecutar este caso). Depenncias entre casos (p. ej., listar los intificadores los casos que se van a ejecutar antes este caso prueba). 51 Documentación l Diseño Pruebas 52 Especificación un Procedimiento Prueba Objetivo: especificar los pasos para la ejecución un conjunto casos prueba o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito evaluar un conjunto características l mismo. Estructura Fijada por el estándar Intificador único la especificación y referencia a la correspondiente especificación diseño prueba. Objetivo l procedimiento y lista casos que se ejecutan con él. Requisitos especiales para la ejecución (p. ej., entorno especial o personal especial). 26

27 Documentación l Diseño Pruebas Estructura Fijada por el estándar Pasos en el procedimiento. Amás la manera registrar los resultados y los incintes la ejecución, se be especificar: La secuencia necesaria acciones para preparar la ejecución. Acciones necesarias para empezar la ejecución. Acciones necesarias durante la ejecución. Cómo se realizarán las medidas (p. ej., el tiempo respuesta). Acciones necesarias para suspenr la prueba (cuando los acontecimientos no previstos lo obliguen). Puntos para reinicio la ejecución y acciones necesarias para el reinicio en estos puntos. Acciones necesarias para tener ornadamente la ejecución. Acciones necesarias para restaurar el entorno y jarlo en la situación existente antes las. Acciones necesarias para tratar los acontecimientos anómalos 53 Ejecución las DEPURAR PRUEBAS EJECUTAR PRUEBAS EJECUTAR PRUEBAS DEPURAR CÓDIGO SÍ (DEFECTO DE PRUEBAS) ALGÚN FALLO? ALGÚN FALLO? NO SÍ (DEFECTO DEL SOFTWARE) PRUEBAS ADICIONALES COMPROBAR TERMINACIÓN COMPROBAR TERMINACIÓN NO CONDICIONES ANORMALES CONDICIONES ANORMALES SÍ PRUEBAS ADICIONALES? PRUEBAS ADICIONALES? CRITERIOS DE COMPLECIÓN DEL PLAN DE PRUEBAS SÍ TERMINACIÓN ANORMAL NO EVALUAR RESULTADOS EVALUAR RESULTADOS TERMINACIÓN NORMAL 54 27

28 Documentación la Ejecución las ESPECIFICACIÓN DE LAS PRUEBAS CASOS PROCEDIMIENTOS EJECUCIÓN EJECUCIÓN Histórico Histórico (test (test log) log) Informes Informes incintes incintes... Histórico Histórico (test (test log) log) Informes Informes incintes incintes Informe resumen Informe resumen las las 55 Documentación la Ejecución las Historico Pruebas Documenta todos los hechos relevantes ocurridos durante la ejecución las. Informe Incinte: Documenta cada incinte (p. ej., una interrupción en las bido a un corte electricidad, bloqueo l teclado, etc.) ocurrido en la prueba y que requiera una posterior investigación

29 Documentación la Ejecución las Informe resumen Resume los resultados las actividas prueba (las reseñadas en el propio informe) y aporta una evaluación l software, basada en dichos resultados. 57 Depuración Es proceso localizar, analizar y corregir los fectos que se sospecha que contiene el software. Suele ser la consecuencia una prueba con éxito. Consecuencias Encontrar la causa l error, analizarla y corregirla No encontrar la causa. (casos prueba para puración)

30 Depuración Etapas: Localización l Error (mayor esfuerzo) Corrección l fecto Casos Prueba Correción Causas Causas Sintomas Errores 59 Análisis errores o análisis causal Cuándo se cometió? Quién lo hizo Qué se hizo mal? Cómo se podría haber prevenido? Por qué no se tectó antes? Cómo se podría haber tectado antes? Cómo se encontró el error? 60 30

31 Ciclo Vida Pruebas (V) Contrato. Contrato. Requisitos Requisitos usuario usuario Prueba Prueba aceptación aceptación Planificar Tipos: Alfa Beta Especificación Especificación requisitos l requisitos l software software Prueba Prueba sistema sistema Requisitos no funcionales Documentación Documentación Documentación diseño y arquitectura diseño y arquitectura Prueba Prueba integración integración Interfaces Mezcla con prueba unidad Tipos integración Especificación Especificación módulos o módulos o elementos elementos Prueba Prueba unidad unidad Exhaustiva Enfoque recomendado: Caja negra Cobertura Código Código 61 Pruebas Unidad Pue abarcar s un módulo, a un grupo pocos módulos o un programa completo Las unidad suelen ser realizadas por personal sarrollo Utilizar el enfoque práctico ya visto

32 Pruebas Integración Ligadas a la forma prevista integrar los distintos componentes l software hasta contar con el producto global que be entregarse Tipos Integración Incremental (ascennte y scennte) Se combina el siguiente módulo que se be probar con el conjunto módulos que ya están probados No Incremental Se prueba cada módulo por separado y, luego, se integran todos una vez y se prueba el programa completo 63 Pruebas l Sistema Verifica: Cumplimiento todos los requisitos funcionales, consirando el producto software final al completo, en un entorno sistema. El funcionamiento y rendimiento en las interfaces hardware, software, usuario y operador. Acuación la documentación usuario. Ejecución y rendimiento en condiciones límite y sobrecarga

33 Pruebas Aceptación Objetivo Comprobar si el producto está listo para ser implantado para el uso operativo en el entorno l usuario. Características Participación l Usuario Está enfocada hacia la prueba los requisitos usuario especificados Está consirada como la fase final l proceso para crear una confianza en que el producto es el apropiado para su uso en explotación 65 33