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

 

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:

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.

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.

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?)

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.

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.

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:

 

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.

     

Queremos ejecutar todos los caminos y para ello queremos saber como máximo cuantos casos de prueba hay que diseñar. Para ello tenemos la complejidad ciclomática de McCabe, que es solo una herramienta para limitar el número de casos de prueba a diseñar.

Para aplicar McCabe hay que representar el programa en un grafo de flujo, con los siguientes elementos:

Luego se calcula la complejidad ciclomática.

     
  1. El número de regiones del grafo
  2. Complejidad V de un grafo G V(G) = Aristas – Nodos + 2
  3. V(G) = Nodos predicado + 1

Definición 1: Tres maneras de calcular la Complejidad Ciclomática

Pruebas de condiciones límite

Se representan de forma gráfica los bucles, para posteriormente validar su construcción. Pueden ser:

Para el caso de bucles simples, siendo n el máximo número de pasos, hay que realizar las siguientes iteraciones:

Cobertura de sentencias

Cobertura de sentencias. Se escriben casos de prueba suficientes para que cada sentencia en el programa se ejecute al menos una vez.

Cobertura de caminos

Cobertura de caminos. Se escriben casos de prueba suficientes para que se ejecuten todas los caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde la entrada del programa hasta su salida.

Pruebas de condición

Puede ser impracticable realizar una prueba exhaustiva de todos los caminos, por ello se han definido distintos criterios de cobertura lógica que permiten decidir qué sentencias o caminos se deben examinar con los casos de prueba. Vemos las que hay y nos centramos en cobertura de caminos:

 

 

Técnicas de caja negra

También conocidas como pruebas funcionales o pruebas de comportamiento. Se basan en la especificación o contrato del módulo a probar. Al igual que pasaba con las pruebas de caja blanca, para confeccionar los casos de prueba:

Particiones o clases de equivalencia

Cada caso de prueba debe cubrir el máximo número de entradas. Debe tratarse el dominio de valores de entrada dividido en un número finito de clases de equivalencia.

Se identifican las condiciones de las entradas del programa y a partir de ellas se identifican las clases de equivalencia:

Por ejemplo, por cada rango de valores se especifica una clase válida y dos no válidas -límites-, si se especifica un número de valores también una válida y dos no válidas; si se especifica una situación del tipo “deber ser” se creará una clase válida y otra no válida, etc.

Análisis de Valores Límite

Parecido a las clases de equivalencia, pero no se eligue “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.

Por ejemplo, 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.

Niveles de prueba

Las técnicas de prueba se pueden usar en los diferentes niveles de prueba, aunque hay algunos niveles de prueba que pueden estar más o menos orientados a la caja blanca o a la caja negra. Así que para las pruebas primero tenemos el nivel y luego complementar en cada nivel caja negra con caja blanca, según se necesite.

Prueba de unidad

Es la prueba de cada módulo, que normalmente realizar el propio personal de desarrollo en su entorno. El responsable de la codificación del software es siempre responsable de probar las unidades que ha escrito del programa, y muchas veces también se encarga de la prueba de integración.

A menudo se dice que está “orientada a caja blanca” por estar muy cerca del código, pero también se puede completar con pruebas de caja negra. Los casos de prueba están orientado a las técnicas y componentes:

Prueba de integración

Con el esquema del diseño software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto. Se prueban los interfaces entre módulos.

Prueba de regresión

Cada vez que se añade un nuevo módulo como parte de una prueba de integración, el software cambia. Estos cambios pueden producir errores en funciones que antes trabajaban correctamente.

Las pruebas de regresión consisten en volver a ejecutar un subconjunto de las pruebas realizadas anteriormente, con el fin de asegurarse de que los cambios no han propagado efectos laterales no deseados.

Aparte de en el contexto de las pruebas de integración, las pruebas de regresión se realizan cuando cambia la configuración del software (programa, documentación o datos), por ejemplo durante el mantenimiento correctivo.

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. Coincide con la de sistema cuando el software no forma parte de un sistema mayor. Hay que revisar si el sistema cumple con aquello para lo que fue diseñado.

También hay una participación del usuario. Constan de dos partes:

Es frecuente realizar una matriz de trazabilidad donde se ponen los requisitos en las filas y los módulos de los que se compone el sistema en las columnas.

Estas pruebas son realizadas por el usuario del sistema y diseñadas también, con ayuda del equipo de desarrollo. Son pruebas de caja negra en las que el usuario realiza casos de prueba que emulan las funciones que realizará luego el sistema.

Realmente “pruebas de validación” y “pruebas de aceptación” vienen a ser lo mismo pero cambia según los autores. Por ejemplo en el libro de Junit nos habla aquí de las pruebas alfa y las beta pero otros las ponen en las “pruebas de aceptación”.

Prueba de sistema

Se realizan sobre el sistema completo, normalmente para determinar el cumplimiento de requisitos no funcionales como comprobar la integración del mismo con otros subsistemas y también, algunos aspectos del mismo que solo se pueden comprobar de forma global. Algunas de ellas son:

En ocasiones validación y sistema de realizan conjuntamente

Prueba de aceptación

ATENCIÓN: algunos autores no distinguen “pruebas de aceptación” y lo ven como “pruebas de validación”.

El usuario comprueba en su propio entorno de explotación si lo acepta como está o no. La realiza el usuario. Las pruebas alfa en el lugar de desarrollo pero por un cliente y las pruebas beta en el entorno final de explotación.

En algunos sitios se ve como las pruebas de aceptación son un tipo de las pruebas de validación, a sumar a los tipos alfa y beta. El matiz es que las de aceptación las suelen poner ya en el entorno del usuario y pasadas las pruebas de sistema.

 

Nivel de prueba

Quien lo realiza

Dónde

Prueba unitaria

El programador

en la versión en desarrollo

Prueba de integración

Puede participar el programador pero a más complejidad debe entrar un grupo independiente de pruebas

en la versión en desarrollo

Prueba de regresión, como consecuencia de la integración o de cambios en la configuración software.

idem

idem

Prueba de sistema

El usuario.

 

Prueba de validación (coincide con la de sistema si no forma parte de un sistema mayor)

 

 

Prueba de aceptación

El usuario. Son pruebas de caja negra.

Entorno del usuario

 

 

 

Desarrollo guiado por pruebas

http://es.wikipedia.org/wiki/Tdd

Práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización. Para escribir las pruebas se utilizan las pruebas unitarias.

Productos software para pruebas

Dentro de las pruebas unitarias hay diverso software de apoyo http://es.wikipedia.org/wiki/Prueba_unitaria

JUnit

Un conjunto de bibliotecas para hacer pruebas unitarias en Java. En función de algún valor de entrada se evalúa el valor de retorno esperado.

También es un método de controlar las pruebas de regresión, necesarias cuando una parte del código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva modificación.

TestNG

Un framework para pruebas y testing basada en JUnit para Java y NUnit para .NET, pero introduciendo nuevas funcionalidades.

JMeter

JMeter es un proyecto de Apache Jakarta que puede ser utilizado como una herramienta de prueba de carga para analizar y medir el desempeño de una variedad de servicios, con énfasis en las aplicaciones web.

Es una aplicación de escritorio que en principio se diseñó para aplicaciones web, pero se ha ido extendiendo.

Puede ser usado como herramienta de pruebas unitarias para:

 

Cactus

Un framework de test para hacer test unitarios de código java en el lado del servidor (Servlets, EJBs, Librerías de tags, filtros, etc.).

Gradle

Es una herramienta de automatización de proyectos encima de Apache Ant y Apache Maven e introduce una DSL (domain specific language, una especie de lenguaje de propósito específico) basado en Groovy, en lugar de basarse en XML.

Está pensado para proyectos que puedan volverse bastante grandes.

El hecho de incluirlo aquí es que también puede usarse para pruebas, integrándose con JUnit, TestNG, Spock (mundo Grails).