Las pruebas
Clasificado en Lengua y literatura
Escrito el en 
español con un tamaño de 662,59 KB
- Las pruebas constituyen un método mas para poder verificar y validar el software.
- Entendemos verificación y validación según Boehm, como:
VERIFICACION:¿Estamos construyendo correctamente el producto?
VALIDACION:¿Estamos construyendo el producto correcto?
Prueba (test): “Una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto”.Para Myers, es el “proceso de ejecutar un programa con el fin de encontrar errores”.
Caso de Prueba (test case): “Un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito
Defecto (defect, fault): “Un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa”.
Fallo (failure): “La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados”.
Error: Tiene varias acepciones:
- La diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o teóricamente correcto. Por ejemplo, una diferencia de dos centímetros entre el valor calculado y el real.
- Un defecto. Por ejemplo, una instrucción incorrecta de un programa.
- Un resultado incorrecto. Por ejemplo, un programa ofrece como resultado de la raíz cuadrada de 36 el valor 7 en vez de 6.
- Una acción humana que conduce a un resultado incorrecto (una metedura de pata). Por ejemplo, que el operador o el programador pulse una tecla equivocada.
Desechamos las acepciones 2 y 3, ya que coinciden con las definiciones de defecto y fallo.
Filosofía de las Pruebas de Software
Las especiales características del software (ausencia física, falta de leyes que rijan su comportamiento, gran complejidad, etc.) hacen aun mas difícil la tarea de probarlo en relación a otros productos industriales.La prueba exhaustiva del software es impracticable.
El objetivo de las pruebas es la detección de defectos en el software y que descubrir un defecto debería considerarse el éxito de la prueba.
El objetivo de las pruebas es la detección de defectos en el software y que descubrir un defecto debería considerarse el éxito de la prueba.Un defecto implica que somos malos profesionales y que debemos sentirnos culpables. Sin embargo, la realidad es muy distinta. Todo el mundo comete errores y es de sabios rectificar.
Los defectos no son siempre el resultado de la negligencia., sino que en su aparición influyen múltiples factores (por ejemplo, las comunicaciones entre miembros del equipo, etc.).
Técnicas de Diseño de Casos de Prueba
El diseño de casos de prueba esta totalmente mediatizado por la imposibilidad de probar exhaustivamente el software.
Pensemos en un programa muy sencillo que solo suma dos números enteros de dos cifras (del 0 al 99). Si quisiéramos probar, simplemente todos los valores validos que se pueden sumar deberíamos probar 10000 combinaciones distintas de 100 posibles números del 1er. sumando y 100 del 2do. Pensemos que aun quedaría por probar todas las posibilidades de error al introducir los datos (teclear una letra en vez de un numero). Si para un programa tan elemental debemos realizar tantas pruebas, podemos imaginar lo que supondría un programa medio.
Las técnicas de diseño de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectaran los defectos existentes sin que se necesite consumir una cantidad excesiva de recursos.
Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes.
Existen tres enfoques principales para el diseño de casos:
1.Estructural o de Caja Blanca: Consiste en centrase en la estructura interna (implementación) del programa para elegir los casos de prueba.
2. Funcional o de caja Negra: Consiste en estudiar la especificación de las funciones, la entrada y la salida para derivar los casos.
3. Aleatorio: Consiste en utilizar modelos (básicamente estadísticos) que representan las posibles entradas al programa para crear a partir de ellos los casos de prueba.
Los enfoques no son excluyentes entre si, ya que se pueden combinar para conseguir una detección de defectos mas eficaz.
Pruebas Estructurales o de Caja Blanca
El clásico ejemplo de Myers de un programa de 50 líneas con 25 sentencias IF en serie, en el que el numero total de caminos contiene 33,5 millones de secuencias potenciales (contando 2 posibles salidas para cada IF tenemos 225 posibles caminos). El diseño de casos de prueba tiene que basarse en la elección de caminos importantes que ofrezcan una seguridad aceptable en descubrir defectos. Se utiliza los llamados criterios de cobertura lógica para esto. Una clasificación de criterios de cobertura lógica, según Myers es:1. Cobertura de Sentencias: Se trata de generar casos de prueba necesarios para que cada sentencia o instrucción del programa se ejecute, al menos una vez.
2. Cobertura de Decisiones: Consiste en escribir caso suficientes para que cada decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. En general, una ejecución de pruebas que cumple la cobertura de decisión cumple también la cobertura de sentencia.
3. Cobertura de Condiciones: Se trata de diseñar tantos casos como sea necesario para que la condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez. No podemos asegurar que si se cumple la cobertura de condición se cumpla necesariamente la de decisión.
4. Criterio de Decisión/Condición: Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla también el criterio de decisiones.
5. Criterio de Condición Múltiple: En el caso de que se considere que la evaluación de las condiciones de cada decisión no se realiza de forma simultanea (por ejemplo, según se ejecuta en el procesador), se podría considerar que cada decisión multicondicional se descompone en varias decisiones uniconsicionales Es decir, una decisión IF (a=1) AND (c=4) THEN … se convierte en una concatenación de dos decisiones: IF (a=1) y IF (c=4), debemos conseguir que todas las combinaciones posibles de resultados (V / F) de cada condición en cada decisión se ejecute al menos una vez.
- La cobertura de caminos (secuencia de sentencias de inicio a fin del programa) es el criterio mas elevado: cada uno de los posibles caminos del programa se debe ejecutar, al menos, una vez.
- Estas técnicas no requieren el uso de ninguna representación grafica especifica del software, aunque es habitual tomar como base los llamados grafo de flujo.
- Notación del Grafo de flujo, se puede expresar en el siguiente figura.
Para ilustrar el uso de un grafo de flujo, a partir de la representación del diseño procedimental:- a) En Diagrama de Flujo
b) En Pseudocódigo
Para reducir el numero de caminos a probar, se habla del concepto de camino de prueba (test path): un camino del programa que atraviesa, como máximo, una vez el interior de cada bucle que encuentra.Si trabajamos con los caminos de prueba, existe la posibilidad de cuantificar el numero total de caminos utilizando la métrica llamada complejidad ciclomatica.La Complejidad Ciclomatica de McCabe - V(G) -, se define como un buen criterio de prueba la consecución de la ejecución de un conjunto de caminos independientes, lo que implica probar un numero de caminos igual al de la métrica.La Complejidad Ciclomatica de McCabe V(G) se puede calcular de las siguientes tres maneras a partir de un grafo de flujo G.
1. V (G) = a – n + 2, siendo a el numero de arcos o aristas del grafo y n el numero de nodos.
2. V (G) = r, siendo r el numero de regiones cerradas del grafo.
3. V (G) = c+1, siendo c el numero de nodos de condición.Veamos como se aplican estas formulas sobre el siguiente grafo de flujo.
1. V (G) = 14 – 11 + 2 = 5
2. V (G) = 5. Las regiones o áreascerradas (limitadas por aristas) del grafo.
3. V (G) = 4 + 1. Los nodos de condición son el 2, 4, el 5 y el 6.
b) En Pseudocódigo
- cA partir de los caminos encontrados, el diseñador de las pruebas debe analizar el código para saber los datos de entrada necesarios para forzar la ejecución por cada uno de ellos. Terminada la entrada deberá consultar la especificación para averiguar cual es la salida teóricamente correcta para cada caso.
Pruebas Funcionales o Caja Negra
- Estudia la especificación del software, las funciones que debe realizar, las entradas y las salidas.
- Busca tipos de errores diferentes a las pruebas de caja blanca:
¿es el sistema particularmente sensible a ciertos datos de entrada?
¿qué volumen de datos tolerará el sistema?
¿qué efectos tendrán determinadas combinaciones de datos sobre el funcionamiento del sistema?
- Un caso de prueba está bien elegido si:
reduce el nº de casos de prueba adicionales para alcanzar una prueba razonable nos dice algo sobre la presencia o ausencia de clases de errores.
Particiones o clases de equivalencia (Piattini et al. 96)
- Cada caso de prueba debe cubrir el máximo nº de entradas.
- Debe tratarse el dominio de valores de entrada dividido en un nº finito de clases de equivalencia
- => la prueba de un valor representativo de la clase permite suponer “razonablemente” que el resultado obtenido será el mismo que probando cualquier otro valor de la clase
- Método de diseño:
1. Identificación de clases de equivalencia.
2. Creación de los casos de prueba correspondientes.
PASO 1. IDENTIFICAR LAS CLASES DE EQUIVALENCIA
1.1. Identificar las condiciones de las entradas del programa
1.2. A partir de ellas, se identifican las clases de equivalencia:
De datos válidos
De datos no válidos
1.3. Algunas reglas para identificar clases:
- Por cada rango de valores, se especifica una clase válida y dos no válidas: (válida) 1 £ número £ 49; (no válidas) número < 1,="" número=""> 49
- Si se especifica un nº de valores, se creará una clase válida y dos no válidas: (válida) num propietarios = 3; (no válidas) num propietarios < 3,="" num="" propietarios=""> 3
- Si se especifica una situación del tipo “debe ser” o booleana, se identifica una clase válida y una no válida: (válida) “El primer carácter es una letra”; (no válida) “(...) no es una letra”(válida) “X es un número”; (no válida) “X no es un número”
- Si se especifica un conjunto de valores admitidos, y el programa trata de forma distinta cada uno de ellos, se crea una clase válida por cada valor, y una no válida
Tres tipos de inmuebles: (válidas) “pisos”, “chalets”, “locales comerciales”;
(no válida) “jkllñ” ; 5). Si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, debe dividirse en clases menores.
PASO 2. IDENTIFICAR LOS CASOS DE PRUEBA
2.1. Asignación de un número único a cada clase de equivalencia.
2.2. Hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba, se tratará de escribir un caso que cubra tantas clases válidas no incorporadas como sea posible.
2.3. Hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de prueba, escribir un caso para una ÚNICA clase no válida sin cubrir.
Análisis de Valores Límite (AVL)
Los casos de prueba que exploran las condiciones límite producen mejores resultados
- “Los defectos del software se acumulan en las situaciones límite”
Diferencias de AVL con particiones de equivalencia:
- No se elige “cualquier elemento” de la clase de equivalencia, sino uno o más de manera que los márgenes se sometan a prueba.
- Los casos de prueba se generan considerando también el espacio de salida.
Reglas para identificar casos (en AVL)
- Si una condición de entrada especifica un rango delimitado por los valores a y b, se deben generar casos para a y b y casos no válidos justo por debajo y justo por encima de a y b, respectivamente.
- Si una condición de entrada especifica un número de valores, se deben desarrollar casos de prueba que ejerciten los valores máximo y mínimo, uno más el máximo y uno menos el mínimo.
- Aplicar las directrices 1 y 2 a las condiciones de salida.
- Si las estructuras de datos internas tienen límites preestablecidos, hay que asegurarse de diseñar un caso de prueba que ejercite la estructura de datos en sus límites.
Ejemplo
Reglas para identificar casos (en AVL)
- Si una condición de entrada especifica un rango delimitado por los valores a y b, se deben generar casos para a y b y casos no válidos justo por debajo y justo por encima de a y b, respectivamente
- Rango de entrada: [-1.0, 1.0]
Casos de prueba para –1.0, +1.0, -1.001, +1.001 (si se admiten 3 decimales)
- Si una condición de entrada especifica un número de valores, se deben desarrollar casos de prueba que ejerciten los valores máximo y mínimo, uno más el máximo y uno menos el mínimo
- “El fichero de entrada tendrá de 1 a 255 registros”
- Casos para 0, 1, 254, 255 registros
- “El fichero de entrada tendrá de 1 a 255 registros”
- Aplicar las directrices 1 y 2 a las condiciones de salida
- “El programa podrá mostrar de 1 a 4 listados”
Para ventanas:
¿Se abrirán las ventanas mediante órdenes basadas en el teclado o en un menú?
¿Se puede ajustar el tamaño, mover y desplegar la ventana?
¿Se regenera adecuadamente cuando se escribe y se vuelve a abrir?
Entrada de datos:
¿Se repiten y son introducidos adecuadamente los datos alfanuméricos?
¿Funcionan adecuadamente los modos gráficos de entrada de datos? (p.e. barra deslizante)
¿Se reconocen adecuadamente los datos no válidos?
¿Son inteligibles los mensajes de entrada de datos?
Estrategias de prueba del software.
Niveles de prueba
1. Prueba de unidad: es la prueba de cada módulo, que normalmente realiza el propio personal de desarrollo en su entorno
2. Prueba de integración: con el esquema del diseño del software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto
3. Prueba de validación: el software totalmente ensamblado se prueba como un todo para comprobar si cumple los requisitos funcionales y de rendimiento, facilidad de mantenimiento, recuperación de errores, etc.
4. Prueba del sistema: el sw. ya validado se integra con el resto del sistema (rendimiento, seguridad, recuperación y resistencia)
5. Prueba de aceptación: el usuario comprueba en su propio entorno de explotación si lo acepta como está o no
Relación entre productos de desarrollo yniveles 