Diseño de Pruebas de Software

1. Completar Especificaciones del Sistema

El desarrollo de sistemas software implica la realización de una serie de actividades predispuestas a incorporar errores en todas las etapas (definición de requerimientos, diseño, desarrollo…), por lo que se debe incorporar una actividad que garantice la calidad del software.

A lo largo de toda la planificación y desarrollo del sistema hay que incluir requisitos relacionados con los aspectos de seguridad, rendimiento, recuperación de errores, prueba, calidad, etc.

1.1. Seguridad y Control

La política de seguridad exige seleccionar, junto con el cliente, los niveles de seguridad e integridad que se desea implantar:

• En el caso de definir controles de acceso, habrá que crear los grupos de usuarios y características individuales de cada uno de ellos.
• La integridad de transacciones exige que se completen todos los datos necesarios para ejecutar cualquier acción.
• Los procedimientos o rutinas críticas pueden realizar determinadas comprobaciones sobre los parámetros que reciben para bien devolver un error o dar respuesta a su función.

1.2. Copias de Seguridad y Recuperación de Errores

Hay tres tipos de copias de seguridad:

• Las más habituales y de mayor periodicidad contienen los datos que cambian frecuentemente.
• Datos con poca variación, para los que habrá una periodicidad o volumen mucho menor.
• Las copias del sistema sin datos, que se harán con cada nueva versión del producto.

Es interesante descargar de los ficheros de datos aquella información que no se utilice por haber quedado obsoleta.

También se deben establecer mecanismos para cuando se produzca un fallo crítico del sistema.

En general, el catálogo de requisitos del sistema debe recoger las especificaciones que se refieran a procedimientos de tratamiento de errores, procedimientos de recuperación, contenidos de los mensajes de error que sean claros para los usuarios, etc.

1.3. Requisitos de Rendimiento

Para cubrir estos requisitos de rendimiento y eficiencia del sistema, hay que especificar los siguientes parámetros:

• Tiempos de respuesta requeridos.
• Situaciones y períodos de altos volúmenes de ocupación del sistema.
• Circunstancias especiales de sobreexplotación y máxima carga.

2. Desarrollar y Probar Componentes del Sistema

El objetivo es diseñar casos de prueba que, sistemáticamente, saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.

2.1. Tipos de Errores

Los principales tipos de errores son los siguientes:

• Los primeros errores que se producen se encuentran en las especificaciones del sistema.
• El segundo tipo de error se produce durante la fase de diseño, debido a que la lógica implementada para solucionar una tarea no se adecua a las especificaciones.
• Hay un tercer tipo de error causado por una mala codificación de los componentes del sistema.
• Por último, los errores más difíciles de detectar son los que se producen en tiempo de ejecución del sistema, ya que los algoritmos y la codificación están ya considerados correctos.

2.2. Técnicas de Pruebas

2.3. Pruebas de Caja Blanca

Las pruebas de caja blanca se basan en la comprobación lo más exhaustiva posible del diseño del código y de las estructuras de control.

Para la definición de esas vías, se emplean principalmente los criterios de prueba siguientes:

• De instrucción: Se crean las pruebas necesarias para que cada instrucción se ejecute al menos una vez.
• De condición simple y múltiple: Se crean las pruebas necesarias para que cada alternativa se ejecute al menos una vez.
• Camino básico o independiente: Es el conjunto de instrucciones de un programa, desde las instrucciones de inicio hasta las de fin, pasando una vez por las secuencias interiores a las estructuras alternativas y repetitivas.
• De cobertura de bucles: Los bucles no son más que segmentos controlados por decisiones.

2.3.1. Grafos de Flujo

Los grafos de flujo se crean a partir del código, o pseudocódigo, y ayudan a la realización de las pruebas de camino básico.

Para obtener un grafo, se transforma cada una de las estructuras del pseudocódigo o código del que se parte, en su correspondiente estructura de grafo.

2.3.2. Prueba del Camino Básico

El criterio de prueba de McCabe consiste en elegir un caso de prueba para cada camino independiente. Los pasos del diseño de pruebas mediante el camino básico serían pues los siguientes:

1. Obtener el grafo de flujo, a partir del diseño o del código del módulo.
2. Obtener la complejidad ciclomática del grafo de flujo.
3. Definir el conjunto básico de caminos independientes.
4. Determinar los casos de prueba que permitan la ejecución de cada uno de los caminos anteriores.
5. Ejecutar cada caso de prueba y comprobar que los resultados son los esperados.

2.3.3. Prueba de Bucles

Para bucles de tipo “While”, hay que pasar 3 casos de pruebas (0 ejecuciones, 1 ejecución, y más de 1 ejecución). Para un bucle de tipo “Repeat”, serían 2 casos de pruebas. Los bucles “For” son, en principio, más seguros, pues en su cabecera está definido el número de veces que se va a ejecutar. En una descripción de pruebas más rigurosa, se pueden definir cuatro situaciones de bucles diferentes:

• A los bucles simples (de n iteraciones), se les tiene que aplicar pruebas para saltar el bucle.
• Los bucles concatenados se prueban mediante las técnicas de prueba para bucles simples, considerándolos como bucles independientes.
• A los bucles anidados, no se les puede practicar una extensión de las pruebas para bucles simples porque el número de pruebas crecería geométricamente.
• Los bucles con rupturas o alteraciones de la variable de control se deben rediseñar estos bucles para que se ajusten a las construcciones de la programación estructurada.

2.4. Pruebas de Caja Negra

Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa. Los objetivos de las pruebas de caja negra son obtener errores referentes a funciones incorrectas, errores de interfaz, errores de estructuras de datos o de acceso a los mismos, errores de inicio o fin del sistema.

2.4.1. Prueba de Partición Equivalente

Esta técnica divide la entrada de datos de un programa en clases o grupos de datos, de forma que, si se realiza una prueba con uno de los valores contenidos en la clase…

2.4.2. Análisis de Valores Límite

En esta técnica, se comprueba la validez de los límites internos y externos de los rangos de las condiciones de las clases de equivalencia.

2.4.3. Pruebas de Comparación

En sistemas donde la fiabilidad y corrección del software es un aspecto crítico, las pruebas deben ser más exhaustivas.

2.4.4. Pruebas de Regresión

Al realizar cambios en el código o al añadir un nuevo módulo, pueden aparecer problemas con módulos que antes iban bien o errores sobre trozos de código que ya habían superado las pruebas.