Pruebas de software

Pruebas de software Técnicas de prueba del software Estrategias de prueba del software Autor: Manuel Collado Fecha: Marzo 2003 Revisado: Marzo 2005

Técnicas de prueba del software • Contenido • Conceptos. Objetivos. Casos de prueba • Pruebas de caja blanca • Pruebas de caja negra

Pruebas: concepto y objetivos • Comprobación del software • Demostración (proof): manual o semiautomática • Inspección manual del código • Prueba o ensayo (testing): ejecutar y ver resultados • Caso de prueba: ensayo individual • Imposibilidad de pruebas exhaustivas • Impracticable, demasiado costoso • Imposible garantizar la ausencia de defectos • Si se provocan fallos, seguro que hay defectos • Si no aparecen fallos, puede que haya defectos, o no

Pruebas: concepto y objetivos • Objetivos de las pruebas • Encontrar defectos en el software • Una prueba tiene éxito si descubre un defecto • Una prueba fracasa si hay defectos pero no los descubre • Pruebas de Verificación • Ver si cumple las especificaciones de diseño • Pruebas de Validación • Ver si cumple los requisitos del análisis

Pruebas de “caja blanca” • Concepto y terminología • Pruebas en que se conoce el código a probar • Caja blanca (clear box: caja clara o transparente) • Se procura ejercitar cada elemento del código • Algunas clases de pruebas • Pruebas de cubrimiento • Pruebas de condiciones • Pruebas de bucles

Pruebas de cubrimiento • Ejecutar al menos una vez cada sentencia • Se necesitan varios casos de prueba • Determinar posibles “caminos” independientes • Cada condición debe cumplirse en un caso y en otro no. En general, se necesitan tantos casos como condiciones, más uno (número ciclomático) • Puede ser imposible cubrir el 100% • Código que nunca se ejecuta: condiciones imposibles • Ejemplo: detección y notificación de errores internos en un código sin errores

Pruebas de condiciones • Cumplir o no cada parte de cada condición • Se necesitan varios casos de prueba • Determinar expresiones simples en las condiciones • Una por cada operando lógico o comparación • Cada expresión simple debe cumplirse en un caso y en otro no, siendo decisiva en el resultado • Puede ser imposible cubrir el 100% • Expresiones simples no independientes

Pruebas de bucles • Conseguir números de repeticiones especiales • Bucles simples • Repetir cero, una y dos veces • Repetir un número medio (típico) de veces • Repetir el máximo-1, máximo y ¡máximo +1! • Bucles anidados • Repetir un número medio (típico) los bucles internos, el mínimo los externos, y variar las repeticiones del bucle intermedio ensayado. • Ensayarlo con cada nivel de anidamiento

Pruebas de “caja negra” • Concepto y terminología • Pruebas en que se conoce sólo la interfaz • Caja negra (black box: caja opaca) • Se procura ejercitar cada elemento de la interfaz • Algunas clases de pruebas • Cubrimiento  invocar todas las funciones (100%) • Clases de equivalencia de datos • Pruebas de valores límite

Pruebas de clases de equivalencia • Particiones de equivalencia • Los datos se clasifican según las distinciones visibles en la interfaz del programa. • Ejemplo: EsPrimo: Entero  Booleano • Clase 1: primo  2 (2, 3, 5, 7, 11, ...) • Clase 2: no_primo  2 (4, 6, 8, 9, 10, ...) • Clase 3: valores singulares (0, 1) • Clase 4: no definido (-1, -2, ...) • Casos de ensayo con datos de cada clase

Pruebas de valores límite • Complemento a las particiones de equivalencia • Varios casos de prueba por cada partición • Valores típicos, intermedios • Valores primero y segundo del rango • Valores penúltimo y último • Valores vecinos fuera del rango (en otra partición) • Motivación • Los programadores se equivocan con más frecuencia al tratar los valores en la frontera (Ej: > en vez de )

Estrategias de prueba del software • Contenido • Pruebas de unidades • Pruebas de integración • Pruebas de regresión • Pruebas de validación

Pruebas sin estrategia • Motivación • Las pruebas son incómodas • La pruebas son aburridas • “Estoy seguro de que lo he codificado bien” • Probar todo junto, al final - Big-Bang • Falla por todas partes • Muy difícil diagnosticar las causas de los fallos • Muy costoso de arreglar • Resultado  productos finales defectuosos

Doc. Requisitos P. validación P. integración Doc. Diseño P. unidades Cod. Módulos Cód. Completo Actividades de prueba de software • Actividades de desarrollo Análisis Diseño Codificación Integración Mantenimiento

Pruebas de unidades • Se prueba cada módulo, por separado Programa de prueba Módulo en pruebas Reales o simulados (stubs) Otros módulos Otros módulos

Pruebas de integración • Integración ascendente Programa de prueba Otros módulos Módulo en pruebas Reales, ya probados Otros módulos Otros módulos

Pruebas de integración • Integración descendente Otros módulos Reales, ya probados Módulo en pruebas simulados (stubs) Otros módulos Otros módulos

Prueba unidades + integración ascendente • Ejemplo Dibujar Curva_C Pluma Papel

Prueba unidades + integración ascendente • Paso 1 P_Papel Papel

Prueba unidades + integración ascendente • Paso 2 P_Pluma P_Papel Pluma Papel

Prueba unidades + integración ascendente • Paso 3 P_Curva_C Curva_C P_Pluma P_Papel Pluma Papel

Prueba unidades + integración ascendente • Paso 4 P_Curva_C Dibujar Curva_C P_Pluma P_Papel Pluma Papel

Pruebas de regresión • Repetir las pruebas tras cada modificación • Repetir sólo pruebas de verificación • Pruebas de unidades • Pruebas de integración • Conservar y actualizar los programas de prueba • Usar herramientas de ejecución automática de las pruebas

Pruebas de validación • Comprobar que se satisfacen los requisitos • Se usan la mismas técnicas, pero con otro objetivo • No hay programas de prueba, sino sólo el código final de la aplicación • Se prueba el programa completo • Uno o varios casos de prueba por cada requisito o caso de uso especificado • Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos) • Pruebas alfa (desarrolladores) y beta (usuarios)

Pruebas de software