Libro: Pruebas de Software y Junit

Bloque III. Tema 11. Pruebas. Planificación y Documentación. Pruebas de caja negra. Pruebas de caja blanca. Utilización de datos de prueba. Pruebas de software, hardware, procedimientos y datos.

Documento: Pruebas/Evaluación Dinámica.

Recurso: http://es.wikipedia.org/wiki/Pruebas_de_software

Libro: Pruebas de Software y Junit (Pta. Toledo)

Índice de contenido

Bloque III. Tema 11. Pruebas. Planificación y Documentación. Pruebas de caja negra. Pruebas de caja blanca. Utilización de datos de prueba. Pruebas de software, hardware, procedimientos y datos.        1

Pruebas        2

Técnicas de Prueba        2

Técnicas de caja blanca        2

Pruebas de interfaces entre módulos o clases        2

Prueba de estructuras de datos locales        3

Cobertura de caminos > Prueba del camino básico > Complejidad Ciclomática McCabe        3

Pruebas de condiciones límite        4

Cobertura de sentencias        4

Cobertura de caminos        4

Pruebas de condición        4

Técnicas de caja negra        5

Particiones o clases de equivalencia        5

Análisis de Valores Límite        5

Niveles de prueba        5

Prueba de unidad        6

Prueba de integración        6

Prueba de regresión        6

Prueba de validación        7

Prueba de sistema        7

Prueba de aceptación        7

Desarrollo guiado por pruebas        8

Productos software para pruebas        8

JUnit        8

TestNG        8

JMeter        8

Cactus        9

Gradle        9

1. Pruebas

El ISO/IEC 29119 Software Testing es el estándar aun por aprobar para las pruebas de software.

A la aplicación de técnicas de evaluación dinámicas se le denomina también prueba del software. Se puede definir como una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, registrándose los resultados obtenidos.

El objetivo no es asegurar la ausencia de defectos sino demostrar la existencia de defectos en un software. Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente al que realizó el software. Algunas características de una buena prueba son:

• Debe tener alta probabilidad de encontrar un fallo.
• Centrarse en probar si el software no hace lo que debe hacer y si hace lo que no debe.
• Debe tener la más alta probabilidad de descubrir una clase entera de errores.
• En general cada prueba debería realizarse separadamente.

Las fases son las siguientes:

1. Diseño de las pruebas. Identificación de la técnica o técnicas que se utilizarán para probar el software.
2. Generación de los casos de prueba.  Determinan un conjunto de entradas, condiciones de ejecución y resultados esperados para un objetivo particular. Cada técnica de pruebas proporciona unos criterios distintos para lo anterior.
3. Definición de los procedimientos de la prueba. Especificación de cómo se va a llevar a cabo el proceso, quién lo va a realizar, cuando...
4. Realización del informe de la prueba. Con el resultado de la ejecución de las pruebas y qué fallos se detectaron.

1. Técnicas de Prueba

Las técnicas de evaluación dinámica proporcionan distintos criterios para generar casos de prueba que provoquen fallos en los programas. Estas técnicas se agrupan en técnicas de caja blanca o estructurales y técnicas de caja negra o funcionales.

1. Técnicas de caja blanca

Se basan en un minucioso examen de los detalles procedimentales del código a evaluar, por lo que es necesario conocer la lógica del programa. También conocidas como  técnicas de caja transparente o de cristal.

El objetivo es diseñar casos de prueba para que se ejecuten, al menos una vez, todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como falsa.

(NOTA: Pensar en qué criterios engloban a otros porque puede ser una pregunta. Por ejemplo si hacemos cobertura de condiciones ¿hemos hecho cobertura de decisiones?)

1. Pruebas de interfaces entre módulos o clases

Analiza el flujo de datos que pasa a través de la interfaz. Se distingue entre interfaces internas y externas. Las pruebas de interfaces internas corresponden al conjunto de pruebas unitarias, que están enfocadas a verificar el correcto funcionamiento de un módulo o clase aisladamente del resto.

1. Prueba de estructuras de datos locales

Aseguran la integridad de los datos durante todos los pasos de la ejecución del módulo. Se comprueban las referencias de datos, la posible utilización de variables no inicializadas, no salirse del límite de matrices o vectores, la correcta declaración de datos y el hecho de no realizar comparaciones de variables de distinto tipo, con otros aspectos como overflow, underflow, división por cero, etc.

1. Cobertura de caminos > Prueba del camino básico > Complejidad Ciclomática McCabe

La aplicación de este criterio asegura que los casos de prueba diseñados permiten que todas las sentencias del programa sean ejecutadas al menos una vez y que las condiciones sean probadas tanto para su valor verdadero como falso.

Una de las técnicas empleadas para aplicar este criterio es la Prueba del camino básico. Definiciones:

• Camino: es una secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta sus sentencia final.
• Camino de prueba: Un camino que atraviesa como máximo una vez el interior de cada bucle que encuentra. Algunos autores hablan de pasar tres veces: una sin entrar, otra entrando una vez, otra entrando dos veces.
• Camino linealmente independiente de otros: Introduce por lo menos un nuevo conjunto de sentencias de proceso o una nueva condición. Visto en el grafo de flujo, introduce una nueva arista que no haya sido recorrida anteriormente a la definición del camino.

Esta técnica se basa en obtener una medida de la complejidad del diseño procedimental de un programa (o de la lógica de un programa). Esta medida es la complejidad ciclomática de McCabe y representa un límite superior o cota para el número de casos de prueba que se deben realizar para asegurar que se ejecuta cada camino del programa.

...