FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE
FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE
Las técnicas facilitan una guía sistemática para diseñar pruebas que complementen la lógica interna de los componentes de software y verifiquen los dominios de entrada y salida del programa para descubrir errores en la funcionalidad, el comportamiento y el rendimiento.
Objetivos de las pruebas:
1. La prueba es el proceso de ejecución de un programa con la intención de descubrir u error.2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.
Principios de las pruebas:
• A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente.
• Las pruebas deberían de planificarse mucho antes de que empiecen.
• El principio de Pareto es aplicable a la prueba de software (el 80% de los errores se encuentra en un 20% del programa).
• Las pruebas deberían de comenzar con lo pequeño y progresar hacia lo grande.
• No son posibles las pruebas exhaustivas.
• Para ser más eficaces, las pruebas deberían de ser realizadas por un equipo independiente.
Facilidad de Prueba del software.- es simplemente la facilidad con la que se puede probar el programa de computadora. Se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto.
La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.
Operabilidad.- cuanto mejor funcione, mas eficientemente se puede probar.
Obserbabilidad.- lo que ves es lo que pruebas.
Controlabilidad.- cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.
Capacidad de descomposición.- Controlado el ámbito de las pruebas, podemos aislar mas rápido los problemas y llevara a cabo mejores pruebas de regresión.
Simplicidad.- Cuanto menos haya que probar, mas rápido podemos probarlo.Estabilidad.- Cuanto menos cambios, menos interrupciones a las pruebas.
Facilidad de comprensión.- Cuanta más información tengamos, mas inteligente serán las pruebas.
Una buena prueba debe de tener los siguientes atributos:
1. Debe de tener una alta probabilidad de encontrar un error.
2. No debe de ser redundante.
3. debería de ser de la mejor cosecha.
4. No debería de ser ni demasiado sencilla ni demasiado compleja.
DISEÑO DE CASOS DE PRUEBA
Debemos diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo posible.
Cualquier producto de ingeniería puede probarse de una de estas dos formas:
1. Conociendo la función especifica para la que fue diseñado el producto (Caja Negra)2. Conociendo el funcionamiento del producto. (Caja Blanca)
Cuando se considera el software de computadora la prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lógica interna del software.La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles.
PRUEBA DE CAJA BLANCA
A veces denominada prueba de caja de cristal es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para obtener los casos de prueba. Los casos de prueba que se obtienen:
1. Garantizan que se ejercita por lo menos una vez todos los caminos independientes de cada modulo.
2. Que se ejerciten todas las decisiones lógicas en sus vertientes verdaderas y falsa.
3. Que se ejecuten todos los bucles en sus límites y con sus limites operacionales.
4. Que se ejerciten las estructuras internas de datos para asegurar su validez.
PRUEBA DEL CAMINO BASICO
Es una técnica de prueba de caja blanca. Permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución y garantizan que se ejecute por lo menos una vez cada sentencia del programa.
Grafo de Flujo.- Representa el flujo de control lógico mediante el uso de un diagrama de flujo para representar la estructura de control del programa.
Cada circulo se denomina NODO y representa una o mas sentencias procedimentales. Las flechas se denominan ARISTAS o ENLACES que representan el flujo de control. Las áreas delimitadas por aristas o nodos se denominan REGIONES. Cada nodo que contiene una condición se denomina NODO PREDICADO y se caracteriza porque dos o mas aristas emergen de el.
Complejidad Ciclomatica.-Es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica del programa. Cuando se usa en el contexto del método de prueba del camino básico el valor calculado como complejidad ciclomatica define el numero de caminos independientes del conjunto básico de un programa y nos da un limite superior para el numero de pruebas que se deben de realizar para asegurar que se ejecuta cada sentencia por lo menos una vez.
Camino independiente.- Es cualquier camino que el programa produce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condición.
La complejidad se puede calcular de tres formas.
1. El numero de regiones del grafo de flujo coincide con la complejidad ciclomatica.
2. La complejidad ciclomatica, V(G), de un grafo de flujo se define como:V(G)=A-N+2Donde A es el numero de aristas del grafo y N es el numero de nodos.
3. La complejidad ciclomatica, V(G), de un grafo de flujo también se define como:V(G)=P+2Donde P es el numero de nodos predicado contenidos en grafo de flujo (G).
Matriz de grafos.- Matriz cuadrada cuyo tamaño (numero de filas y columnas) es igual al numero de nodos del grafo de flujo. Cada fila y cada columna corresponde a un nodo especifico y las entradas de la matriz corresponden alas aristas entre los nodos.
PRUEBA DE LA ESTRUCTURA DE CONTROL
Prueba de condición.- método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el modulo de un programa.
Una condición simple es una variable lógica o una expresión relacional precedida por un operador NOT.
La expresión condicional toma esta forma E1
Una condición compuesta esta formada por dos o mas condiciones simples, operadores lógicos y paréntesis.
Método de la prueba de condiciones.- Se centra en la prueba de cada una de las condiciones del programa.
Este método tiene dos ventajas: Que la cobertura de la prueba de una condición es sencilla; y que la cobertura de la prueba de las condiciones de un programa de una orientación para generar pruebas adicionales del programa.
Prueba de ramificaciones.- Es la estrategia de prueba de condiciones más sencilla.
Prueba del dominio [WHI80] requiere la realización de tres o cuatro pruebas para una expresión relacional.
Prueba de flujo de datos.- Selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.
PRUEBA DE BUCLES
Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software.
La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles.
Se pueden definir los siguientes tipos de bucles:
1) Bucles simples: A estos se les debe de aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos por el bucle.
a) Pasar por alto totalmente el bucle
b) Pasar una sola vez por el bucle
c) Pasar dos veces por el bucled) Hacer m pasos por el bucle con m2) Bucles anidados: Aquí el número de posibles pruebas aumentaría geométricamente a medida que aumenta el nivel de anidamiento. Con lo que se llevaría a un número impracticable de pruebas.
Beizer sugiere un enfoque que ayuda a reducir el número de pruebas.
a) Comenzar por el bucle más inferior
a) Comenzar por el bucle más inferior
b) Llevar a cabo las pruebas de bucles simples para el bucle más interior, mientras se mantienen los parámetros de iteración de los bucles externos en sus valores mínimos.
c) Progresas hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mínimos y los demás bucles anidados en sus valores típicos.
d) Continuar hasta que se hayan probado todos los bucles
3) Bucles concatenados: Se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto.
4) Bucles no estructurados: Este tipo de bucles cuando es posible se deben de rediseñar para que se ajusten a las construcciones de programación estructurada.
PRUEBA DE CAJA NEGRA
Pruebas de caja negra: También denominadas pruebas de comportamiento, se centran en los requisitos funcionales del software. Esta prueba permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. Esta prueba no se considera como una alternativa a las técnicas de prueba de caja blanca.
La prueba de caja negra intenta encontrar errores de las siguientes categorías:
a) Funciones incorrectas o ausentes
b) Errores de interfaz
c) Errores en estructuras de datos o en accesos a base de datos externas
d) Errores de rendimiento
e) Errores de inicialización y de terminación
MÉTODOS DE PRUEBA BASADOS EN GRAFOS:
La prueba de caja negra se realiza inicialmente con entender los objetivos que se modelan en el software y las relaciones que conectan a estos objetos. Después se definen una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas.
La prueba del software empieza creando un grafo de objetos importantes y sus relaciones, y después diseñando una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para describir los errores.
Se le llama grafo a una colección de nodos que representan objetos, enlaces que representan lasa relaciones entre los objetos, pesos de nodos que describen las propiedades de un nodo y pesos de enlace que describen alguna característica de un enlace.
Un enlace dirigido.- Se representa por una flecha y es el que indica que una relación se mueve sólo en una dirección.
Un enlace bidireccional.- También se denomina enlace simétrico, indica que la relación se aplica en ambos sentidos.
Partición equivalente.- Es un método de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.
Clase de equivalencia.- Representa un conjunto de estados válidos o no válidos para condiciones de entrada.
Análisis de valores límites (AVL).- Es una técnica de prueba, que se utiliza cuñado los errores tienden a darse más en los límites del campo de entrada. Esta prueba complementa a la partición equivalente; en lugar de seleccionar cualquier elemento de una clase de equivalencia, esta técnica lleva a la elección de casos de prueba en los extremos de la clase.
Prueba de la tabla ortogonal.- Se aplica a problemas en que el dominio de entrada es relativamente pequeño pero demasiado grande para posibilitar pruebas exhaustas. Este método es particularmente útil al encontrar errores asociados con fallos localizados.
Los métodos de prueba de caja negra y de caja blanca son aplicables a todos los entornos, arquitecturas y aplicaciones pero a veces se necesitan unas directrices y enfoques únicos para las pruebas.
