Prueba de aplicaciones convencionales Capítulo 18 Pressman

Tabla de Contenido Fundamentos de las pruebas de software. Pruebas de caja negra y caja blanca. Pruebas de caja blanca. Prueba de la ruta básica. Prueba de estructura de control Prueba de caja negra. Métodos de pruebas orientadas a objetos. Métodos de prueba aplicables al nivel de clase. Diseño de caso de prueba de interclase. Pruebas de entornos especializados: arquitectura y aplicaciones. Patrones de prueba.

Importancia de las pruebas Las pruebas del software son un elemento crítico para la garantía de calidad del software. El costo asociado a un fallo del sistema es el principal aliciente para realizar pruebas. Antes de iniciar las pruebas se deben establecer los criterios de aceptación, para demostrar que se satisfacen las necesidades de la organización. Si no se tienen, la evaluación puede ser subjetiva y el resultado puede fallar

Definiciones Probar NO ES demostrar que no existen errores en un programa. Prueba ES el proceso de ejecutar un programa con el fin de encontrar errores. (√) Caso de prueba (test case): «es un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»

Objetivos de las pruebas El principal es sacar a la luz diferentes clases de errores, minimizando la cantidad de tiempo y esfuerzo invertido Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Principios de las pruebas A todas las pruebas se les debe poder dar seguimiento hasta los requerimientos Las pruebas se deben planificar mucho antes de que empiecen (antes de generar código) El principio de Pareto (80/20) es aplicable a las pruebas (80% de los errores se encuentra en un 20% de todos los módulos del programa) Deben comenzar por lo pequeño y progresar hacia lo grande. No son posibles pruebas exhaustivas Para ser más eficaces, deben ser realizadas por un equipo independiente

Fundamentos de las pruebas de software Comprobabilidad es la facilidad con que se puede probar un software. Las siguientes características conducen a que el software sea comprobable: Operatividad: “Mientras mejor funcione, más eficientemente se puede probar” Esto permite trabajar sin interrupciones Observabilidad: “Lo que ves es lo que pruebas”. Los estados y variables son visibles, se pueden consultar durante la ejecución. La salida incorrecta se identifica fácilmente. Controlabilidad: “Mientras más se pueda controlar, más se puede automatizar y optimizar las pruebas “ Se pueden generar posibles salidas a través de combinaciones de entradas y los formatos de entrada/salida son consistentes. Las pruebas se pueden reproducir y automatizar

Fundamentos de las pruebas(cont) Descomponibilidad: El sistema se construye a partir de módulos independientes que se pueden probar de manera independiente Simplicidad: El software debe tener simplicidad funcional ( características mínimas necesarias para satisfacer los requerimientos), simplicidad estructural (arquitectura modular para evitar propagación de fallos), simplicidad de código (adoptar estándar de codificación para facilitar inspección y mantenimiento) Estabilidad: Pocos cambios deben solicitarse durante las pruebas. “Cuanto menos cambios, menos interrupciones a las pruebas” Comprensibilidad: “Cuanto más información tengamos, más inteligentes serán las pruebas” Comprensión y acceso a la documentación del diseño.

Probando el software Visión interna Método Caja blanca Caja negra (visión externa) Métodos Estrategias

Diseño de casos de prueba “Existe una sola regla para el diseño de casos de prueba, cubrir todas las posibilidades, sin hacer demasiados casos de prueba.” Tsuneo Yamaura Hay dos enfoques: Caja Blanca : Centrarse en la estructura de control del programa. Caja Negra: Centrarse en el comportamiento del programa.

Diseño de casos de prueba: enfoques Funcional Estructural Tomado de [2]

Diseño de casos de prueba: enfoques Caja negra Se conoce la función específica para la que fue diseñado el producto Se llevan a cabo pruebas que demuestran que cada función es completamente operativa y al mismo tiempo busca errores en cada función Caja blanca Conociendo el funcionamiento del producto se desarrollan pruebas que aseguren que todo encaja, que la operación interna se ajusta a las operaciones y que todos los componentes internos se han probado adecuadamente

Enfoque: Pruebas de Caja-Blanca Se examinan los detalles procedimentales Se comprueban los caminos lógicos proponiendo casos de pruebas que ejerciten conjuntos específicos de condiciones y/o bucles …la meta es asegurar que todas las sentencias y condiciones se hayan ejecutado al menos una vez

Enfoque: Pruebas tipo Caja Blanca (cont.) Mediante los casos de prueba de Caja Blanca se logra: Garantizar que todos los caminos independientes de cada módulo se revisaron al menos una vez. Ejercitar todas las decisiones lógicas en sus lados verdaderos y falsos. Ejecutar todos los ciclos en sus límites y dentro de sus límites operativos. Revisar las estructuras internas de datos para asegurar su validez.

Enfoque: Pruebas de Caja-Blanca Pruebas Exhaustivas Loop < 20 X 14 Hay 10 posibles caminos! Si ejecutamos un caso de prueba por milisegundo, podría tomar 3,170 años probar este programa!!

Enfoque: Pruebas de Caja-Blanca Pruebas Selectivas Camino seleccionado Loop < 20 X Las pruebas de caja blanca no se deben desechar como poco prácticas. Se pueden elegir y ejercitar una serie de caminos lógicos importantes

Notación de gráfico o grafo de flujo: Pasos a seguir Crear grafo de flujo a partir del código a probar: Cada nodo representa una o más sentencias procedimentales. Las aristas representan el flujo de control y deben terminar siempre en un nodo. Determinar la complejidad ciclomática V(G) utilizando la siguiente fórmula: V(G)= A-N+2. El resultado es el número de caminos independientes de la estructura de control del programa. A = # de aristas del grafo de flujo N = # de nodos del grafo de flujo

Notación de gráfico o grafo de flujo: Pasos a seguir Ejemplo de Creación de Grafo tomando como base el procedimiento Media

Notación de gráfico o grafo de flujo: Pasos a seguir total, entrada = total, valido=0; Do while Grafo correspondiente al código del procedimiento Media 1 2 Valor[i] <> -999 3 total entrada < 100 Incrementar totalentrada en 1 4 If total valido > 0 10 5 If valor[i] >= minimo Then media = suma/total.valido; Else media = -999 12 11 Valor[i] <= maximo 6 13 Then incrementar total.valido en 1 suma=suma+valor[i] Else ignorar 7 endif 8 Endif Incrementar I en 1 9 ENDDO

Notación de gráfico o grafo de flujo: Pasos a seguir Determinar un conjunto básico de caminos independientes: Camino 1: 1-2-10-11-13 Camino 2: 1-2-10-12-13 Camino 3: 1-2-3-10-11-13 Camino 4: 1-2-3-4-5-8-2-2… Camino 5: 1-2-3-4-5-6-8-9-2… Camino 6: 1-2-3-4-5-6-7-8-9-2…

Notación de gráfico o grafo de flujo: Pasos a seguir Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico: Camino 1: Valor (k) = entrada válida, donde k < i definida a continuación: Valor (i) = -999, donde 2 <= i <= 100 Resultados esperado: media correcta sobre los k valores y totales adecuados.

Matrices de gráficas El procedimiento para determina r el gráfico de flujo o determinar las rutas básicas es sensible a la automatización Una matriz cuadrada cuyo tamaño (# de filas y columnas) es igual al número de nodos en la gráfica de flujo. Cada fila y columna corresponde a un nodo identificado, y las entradas de la matriz corresponden a las conexiones (una arista) entre nodos. La matriz es solo una representación tabular de un gráfico, pero al agregar un enlace ponderado a cada entrada de matriz, la matriz se convierte en una herramienta poderosa para evaluar la estructura de control del programa durante las pruebas. En su forma más simple el enlace puede ser 1 o 0 (si existe o no) pero se les puede asignar valores más interesantes como: Probabilidad de que un enlace se ejecutará, tiempo de procesamiento que se emplea durante el recorrido de un enlace, memoria requerida durante el recorrido de un enlace, recursos requeridos durante el recorrido de un enlace

Matrices de gráficas (cont.) Conectado al nodo 1 Nodo 1 2 3 4 5 a a d b c f g e 1 2 3 4 5 3 e b 5 4 d f c g 2 Gráfica de flujo Matriz de gráfica

Otras pruebas tipo Caja Blanca Prueba de condición Ejercita cada una de las condiciones lógicas del programa. Los tipos de errores de una condición pueden ser: Error en operador, Error en variable, Error en paréntesis, Error en expresión aritmética Se han propuesto una serie de estrategias de pruebas de condiciones: Prueba de ramificaciones Prueba del dominio Prueba del operador relacional y de ramificación

Otras pruebas tipo Caja Blanca Prueba del flujo de datos Selecciona caminos de prueba de acuerdo a la ubicación de las definiciones y los usos de las variables. Prueba de bucles Se centra en la validez de las construcciones de bucles: simples, anidados, concatenados y no estructurados

Prueba de Bucles Bucle Simple Bucle Anidado Bucle Concatenado Bucle No estructurado

Prueba de Bucles (cont.) Bucle simple (donde n es el número máximo de pasos permitidos por el bucle) Pasar por alto totalmente el bucle Pasar una sola vez por el bucle Pasar dos veces por el bucle Hacer m pasos por el bucle, con m < n Hacer n-1, n, y n+1 pasos por el bucle Bucles anidados: Comenzar por el bucle más interior Realizar pruebas de bucles simples para el bucle más interno mientras mantiene los bucles externos en sus valores mínimos de parámetro de iteración Procesar hacia fuera, manteniendo los bucles externos en sus valores mínimos, y probar los valores min+1, min-1, y los valores típicos. .

Prueba de Bucles (cont.) Bucles concatenados: Si los bucles son independientes se utiliza el enfoque de los bucles simples, sino se usa el enfoque de los bucles anidados. Bucles no estructurados: Se deben de evitar, y en caso de que aparezcan es necesario rediseñarlos.

Pruebas de Caja Negra Requerimientos Salidas Entradas Eventos

Pruebas Caja Negra No son una alternativa, complementan las de Caja Blanca Intenta encontrar errores en: Funciones incorrectas o faltantes Errores de interfaz Errores en las estructuras de datos o en el acceso a BD externas Errores de comportamiento o rendimiento Errores de inicialización y terminación

Pruebas Caja Negra Las pruebas se diseñan para responder a preguntas como: Cómo se prueba la validez funcional? Cómo se prueba el comportamiento y rendimiento? Qué clases de entrada harán buenos casos de prueba? El sistema es particularmente sensible a ciertos valores de entrada? Cómo se aislan las fronteras de una clase de datos? Qué tasas y volúmen de datos puede tolerar el sistema? Qué efecto tendrá sobre la operación algunas combinaciones de datos?

Pruebas tipo Caja Negra (cont.) Hay diversas técnicas: Métodos gráficos de prueba Partición de equivalencia Análisis de valores de límite Prueba de la tabla ortogonal

1. Métodos gráficos de prueba Se modelan los objetos del sistema y las relaciones entre ellos mediante un grafo. El siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen las relaciones esperadas entre ellos Se ejercitan todos los objetos y sus relaciones para descubrir errores

1. Métodos gráficos de prueba (cont.) Enlace dirigido Peso del enlace Objeto 2 Objeto 1 Peso del nodo Enlace no dirigido Enlaces paralelos Objeto 3 Representación del grafo

1. Métodos gráficos de prueba(cont.) Ejemplo: Creación de un nuevo archivo en un procesador de texto. La selección del menú genera (tiempo de generación <1.0 seg) Atributos: Dimensiones de inicio: Configuración o preferencias predeterminadas. Color de fondo: blanco Color de texto: color o preferencias predeterminadas Ventana Documento Nuevo Archivo Permite la edición de Se reperesenta como Contiene Texto de documento Una selección del menú en Nuevo Archivo genera una ventana del documento. El peso del nodo de Ventana Documento proporciona una lista de atributos de la Ventana, que se esperan cuando se genera una ventana. El peso del enlace indica que la ventana se tiene que generar en menos de 1.0 segundos.

1. Métodos gráficos de prueba(cont.) Métodos de prueba de comportamiento que usan gráficas: Modelado del flujo de transacción: nodos representan pasos y los enlaces conexiones lógicas Modelado de estado finito: nodos representan estados y los enlaces transiciones. Modelado de flujo de datos: nodos representan objetos de datos y los enlaces transformaciones Modelado relacionado con el tiempo: nodos representan objetos del programa y los enlaces conexiones secuenciales

2. Método de Partición equivalente Divide las entradas de un programa en clases de datos (clases equivalentes) de los que se pueden derivar casos de prueba y en donde cada caso de prueba permite descubrir una clase de errores, lo que reduce el número total de casos de prueba que hay que desarrollar. Las clases equivalentes representan un conjunto de estados válidos o no válidos para la condición de entrada.

2. Ejemplo de particiones equivalentes Tomado de [2]

2. Ejemplo de particiones equivalentes Tomado de [2] “Estimación de inflación entre 15% Y 20%”, “capital entre $65M y $100M” y “tasa de interés entre 0% y 5%”

3. Método de Análisis de valores límite Es un complemento de la técnica de partición equivalente. En general se llega a Particiones equivalentes mediante la investigación de Valores límite que limitan las variables dentro de la aplicación Toma el conjunto de datos de entrada y examina solo en los límites, ya que ahí es donde es más probable que se produzcan los errores Es decir, se eligen casos de prueba para ejercitar los valores límite. En lugar de centrarse solo en las condiciones de entrada, se obtienen también casos de prueba para el campo de salida

3. Método de Análisis de valores límite Intervalo Dentro del intervalo En lo límites del intervalo Fuera del intervalo Tomado de Braude pág. 400 41 41

3. Directrices Análisis de valores límite (cont.) Si una entrada tiene un rango entre a y b, se diseñan casos de prueba para lo valores a y b, y para los que están por debajo y por encima de a y b. Si una entrada especifica un número de valores, diseñar casos de prueba que ejerciten los valores máximo y mínimo y para los que están por debajo y por encima de ellos. Aplicar las directrices 1 y 2 a los datos de salida. Si hay estructuras de datos con límites preestablecidos diseñar casos de prueba que ejerciten la estructura de datos en sus límites

4. Método de Prueba de Tabla Ortogonal Se aplica en problemas donde el dominio de entrada (número de parámetros) y la cantidad de valores que pueden tomar dichas entradas es relativamente pequeño, pero demasiado grande para posibilitar pruebas exhaustivas. Detecta: Fallas de Modalidad Simple Fallas de Modalidad Doble Fallas Multimodales Es útil para encontrar errores asociados a fallos localizados (errores asociados con defectos de lógica dentro de un componente de software) causado por un parámetro o la interacción de 2 o más.

4. Método de Prueba de Tabla Ortogonal Por ej: Programa con 3 parámetros de entrada tomando 4 valores diferentes. Se pueden considerar todas las permutaciones (34 = 81) pero el esfuerzo requerido es relativamente alto. Solución: Crear tabla ortogonal L9 Los casos de prueba están uniformemente dispersos por todo el dominio de prueba.

4. Método de Prueba de Tabla Ortogonal (Cont.) Caso de prueba Parámetros de prueba P1 P2 P3 P4 1 2 3 4 5 6 7 8 9 Tabla ortogonal L9

Pruebas basadas en modelo Técnica de caja negra que usa la información del modelo de requerimientos (diagramas de estados) para generar casos de pruebas: Analiza un modelo de comportamiento existente (evalúa casos de uso para entender interacción, identifica eventos, crea una secuencia y construye diagrama de estados) Recorre el modelo de comportamiento y especifica entradas que forzarán a realizar la transición de estados Revisa el modelo y observa las salidas esperadas Ejecuta los casos de pruebas Compara resultados

Prueba de Entornos Especializados: Arquitecturas y Aplicaciones Pruebas de interfaces gráficas de usuario Como los componente reutilizables son parte del desarrollo GUI el trabajo de diseño es más fáciles, pero la complejidad de las GUI ha crecido lo que conduce a más dificultad en el diseño y la ejecución de los casos de prueba Debido a que muchas GUI tienen la misma apariencia pueden derivarse una serie de pruebas estándar. Es posible usar gráficas de modelado de estado finito (ver filmina anterior) En la actualidad se hacen por medio de herramientas automatizadas

Prueba de Entornos Especializados: Arquitecturas y Aplicaciones (cont Prueba de arquitectura cliente/servidor Desempeño durante la transacción, presencia de distintas plataformas, complejidad de comunicación en red, entre otras, complica probar el software La prueba se da en 3 niveles: Cliente se prueba en modalidad “desconectada” Cliente y servidor se prueban juntas, pero operaciones de red no se ejercitan de manera explícita Se prueba todo, incluso operación y desempeño de la red

Prueba de Entornos Especializados: Arquitecturas y Aplicaciones (cont Suelen usarse los siguientes enfoques de prueba: Pruebas de funcionalidad de la aplicación Pruebas de servidor Pruebas de base de datos Pruebas de transacción Pruebas de comunicación de red

Prueba de Entornos Especializados: Arquitecturas y Aplicaciones (cont Prueba de la documentación y las funciones de ayuda Se aborda en 2 fases: revisión e inspección: examina claridad del documento Prueba en vivo: se emplea la documentación junto al programa

Prueba de Entornos Especializados: Arquitecturas y Aplicaciones (cont Prueba de sistemas de tiempo real Se deben tomar en cuenta casos de prueba de manejo de eventos (procesamiento de interrupciones), temporización de datos y paralelismo entre tareas Se recomienda seguir los siguientes pasos: Prueba de tareas: Se prueba cada tarea de manera independiente. Prueba de comportamiento: Simula el comportamiento del sistema en tiempo real Prueba de intertareas: Se prueban las tareas asíncrónicas, las que se comunican por medio de la cola de mensajes o el almacén de datos. Prueba del sistema: Trata de descubrir errores en la interfaz software/hardware aplicando un rango completo de pruebas del sistema.

Patrones de Prueba Describen bloques de construcción o situaciones frecuentes y que los responsables de probar el software pueden reutilizar al afrontar la prueba de un sistema nuevo o revisado Proporcionan además: Terminología a los encargados de la resolución de problemas Concentran la atención en las fuerzas que se encuentran detrás del problema Estimulan el razonamiento iterativo

Referencias [1] Pressman, Roger S. “Ingeniería de Software: Un enfoque práctico”, sexta edición, McGraw-Hill, 2005. [2] Braud, Eric.”Ingeniería de Software – Una perspectiva Orientada a Objetos”, Alfaomega, 2003.