Modelos de calidad. Técnicas de prueba del software Estrategias de prueba del software. Calidad del software. Factores de Calidad. producto.

Transcripción

1 Técnicas de prueba del software Estrategias de prueba del software 1 Modelos de calidad Calidad del software Factores de Calidad Criterios de calidad del proceso producto Métricas del proceso producto Criterios de calidad del Métricas del 2 1

2 Modelo de calidad de McCall Corrección, hasta que punto se cumplen los objetivos del usuario Fiabilidad: En que punto se puede confiar en el funcionamiento sin errores del programa Eficiencia: en cuanto a la cantidad de código y recursos informaticos Integridad: hasta que punto se controlan los accesos ilegales al sistema Facilidad de uso Facilidad de mantenimiento Facilidad de prueba Flexibilidad: el coste de modificar el producto Portabilidad Reusabilidad: hasta que punto se puede transferir un modulo a otra aplicación Interoperatbilidad: el costo de conectar dos productos entre si 3 Modelos de calidad Hay que tener en cuenta que algunos de estos factores pueden estar en conflicto entre si, por ejemplo la eficiencia. Una vez seleccionados los factores de calidad, es necesarios darles un orden de importancia. Cada uno de los factores se dividen en un conjunto de atributos de calidad por ejemplo: FIABILIDAD TOLERANCIA DE ERRORES CONSISTENCIA PRECISION SIMPLICIDAD Se aplica una métrica para cada uno de los criterios de calidad. FIABILIDAD Numero de errores en el programa Numero de errores en la documentación Numero de problemas que han aparecido/mes uso Porcentaje de usuarios con problemas 4 2

3 Actividades del control de calidad ANALISIS ESTÁTICO Auditorias Revisiones Es una reunión formal donde se presenta el estado actual de los resultados de un proyecto a un usuario, es el método más eficaz para analizar las primeras etapas del desarrollo. Las revisiones técnicas más comunes son: revisión de las especificaciones de requisitos. revisión de diseño revisión de códigos. revisión de las pruebas revisión del manual del usuario 5 Revisiones Revisión de diseño Se suele diferenciar entre la revisión del diseño preliminar y el detallado, el objetivo es evaluar el estado en que se encuentra esta etapa. Un ejemplo de lista de comprobación en esta revisión sería: Hay uniformidad en el diseño? Se han definido correctamente las interfaces entre módulos.? Se han definido correctamente las interfaces externas.? Cubre el diseño todos los requisitos.? Cumple el diseño todos los requisitos no funcionales.? Resulta ambigua la documentación? Se han aplicado notaciones de diseño correctas.? El diseño es lo suficientemente detallado para que se pueda pasar a la etapa de programación? 6 3

4 PRUEBAS DINAMICAS Contenido Conceptos. Objetivos. Casos de prueba Pruebas de caja blanca Pruebas de caja negra 7 Pruebas: concepto y objetivos Comprobación del software Demostración : 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 8 4

5 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 9 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 10 5

6 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, (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 11 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 12 6

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

8 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 15 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 ) 16 8

9 Otras pruebas Pruebas de aceptación Prueba de stress Prueba de carga maxima DEFINICION DEL ENTORNO DE PRUEBAS Herramientas de seguimiento de errores Mantis Trac 17 Estrategias de prueba del software Contenido Pruebas de unidades Pruebas de integración Pruebas de regresión Pruebas de validación Pruebas de carga máxima Pruebas de stress 18 9

10 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 19 Actividades de prueba de software Actividades de desarrollo Doc. Requisitos Análisis P. validación Diseño P. integración Doc. Diseño Codificación P. unidades Cod. Módulos Integración Cód. Completo Mantenimiento 20 10

11 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 21 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) 22 11