La importancia de la prueba del software y sus implicaciones con la calidad del software no se pueden sobrevalorar.
El desarrollo de sistemas de software envuelve una serie de actividades de producción en que las posibilidades de que aparezca la fiabilidad humana son enormes. Los errores pueden empezar a darse desde el primer momento del proceso en el que los objetivos.
FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE
La prueba presente una interesante anomalía para el ingeniero de software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un control abstracto y llegando a una implementación tangible.
Objetivos de la prueba
En un excelente libro sobre la prueba del software, Glen Myers [MYE79] establece una serie de reglas que sirven acertadamente como objetivos de prueba:
- La prueba es un proceso de ejecución de un programa con la intención de descubrir un error.
- 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.
Los objetivos anteriores suponen un cambio dramático del punto de vista. Nos quitan la idea que normalmente se tiene de que una prueba tiene éxito si no descubre errores. El objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
Diseño de casos de prueba
El diseño de pruebas para el software o para otros productos de ingeniería puede requerir tanto esfuerzo como el propio diseño inicial del producto.
PRUEBA DE LA CAJA BLANCA
La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba. Mediante los métodos de prueba de la caja blanca, el ingeniero del software puede derivar casos de prueba que: 1) Garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada módulo, 2) Se ejercitan todas las decisiones lógicas en sus caras verdadera y falsa; 3) Se ejecutan todos los bucles en sus límites y con sus límites operacionales. Y 4) Se ejercitan las estructuras de datos internas para asegurar su validez.
PRUEBA DEL CAMINO BASICO
La prueba del camino básico es una técnica de prueba de la caja blanca propuesta inicialmente por Tom McCabe [MCC76]. El método del camino básico permite al diseñador de casos de prueba derivar una medida de complejidad lógica de un diseño procesado y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución.
Derivación de casos de prueba
El método de prueba del camino básico se puede aplicar a un diseño prosado detallado o a un código fuente. En esta sección, presentaremos la prueba del camino básico como una serie de pasos.
Matrices de grafos
El procedimiento de obtención del grafo de flujo e incluso la determinación de un conjunto básico de caminos es susceptible de ser mecanizado. Para desarrollar una herramienta software que ayude en la prueba del camino básico, puede ser bastante útil una estructura de datos denominada matriz de grafo.
Una matriz de grafo es una matriz cuadrada cuyo tamaño (o sea, el número de filas y de columnas) es igual al número de nodos del grafo de flujo.
PRUEBA DE BUCLES
Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software. Y por ello debemos prestarles normalmente un poco de atención cuando llevamos a cabo la prueba del software.
La prueba de bucles es una técnica de prueba de la caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles [BEI83]: bucles simples, bucles concatenados, bucles anidados, y bucles no estructurados.
BUCLES SIMPLES. A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos por el bucle.
BUCLES ANIDADOS. Si extendiéramos el enfoque de prueba d ellos bucles simples a los bucles anidados, el Nero de posibles pruebas crecería geométricamente a medida que aumentara el nivel de anidamiento. Esto nos llevaría a un número impracticable de pruebas.
BUCLES CONCATENADOS. Los bucles concatenados se puede probar mediante el enfoque anteriormente definido para los bucles simples, mientras que cada uno de los bucles sea independiente del resto.
PRUEBA DE LA CAJA NEGRA
Los métodos de prueba d ella caja negra se centra en los requerimientos funciónales del software. O sea, la prueba de la caja negra permite al ingeniero del software derivar conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales de un programa. La prueba de la caja negra no es una alternativa a las técnicas de prueba de la caja blanca. Más bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los métodos de la caja blanca.
Partición Equivalente
La partición equivalente es un método de prueba de la caja negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.
PRUEBA DE CORRECCION
Hemos visto que la prueba se puede usar perfectamente para descubrir errores, pero no se puede usar para demostrar la corrección de un programa.
HERRAMIENTAS AUTOMATICAS DE PRUEBA
Dado que la prueba de software a menudo se lleva hasta el 40 por ciento del esfuerzo total de un proyecto de desarrollo de software, las herramientas que reduzcan el tiempo de prueba (sin reducir la exhaustividad) son muy valiosas. Teniendo en cuenta los posibles beneficios.
0 comentarios