Pruebas: concepto y objetivos

Objetivos de las pruebas

                Encontrar defectos en el software

              Una prueba tiene éxito si descubre un defecto

              Una prueba fracasa si hay defectos pero no los descubre

Pruebas de Verificación

 Ver si cumple las especificaciones de diseño

Pruebas de Validación

 Ver si cumple los requisitos del análisis

Pruebas del Software

El proceso de pruebas del software tiene dos objetivos:

1. Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.

Para el software a medida, significa que debe haber al menos una prueba para cada requerimiento del sistema y del usuario.

Para software genérico, significa que debe haber pruebas para todas las características del sistema que se incorporarán en la entrega del producto.

Este objetivo conduce a las pruebas de validación => se espera que el sistema funcione correctamente usando un conjunto determinado de casos de prueba que reflejan el uso esperado de aquél.

2. Descubrir defectos en el software: que su comportamiento es incorrecto, no deseable o no cumple su especificación.

La prueba de defectos está relacionada con la eliminación de todos los comportamientos no deseables.

Ej: caídas del sistema, interacciones no permitidas con otros sistemas, cálculos incorrectos y corrupción de datos.

Este objetivo conduce a la prueba de defectos, cuando los casos de prueba se diseñan para exponer los defectos.

Modelo del Proceso de Pruebas del Software

img

Pruebas de “caja blanca”

Concepto y terminología

  Pruebas en que se conoce el código a probar

  Caja blanca (clear box: caja clara o transparente)

  Se procura ejercitar cada elemento del código

Algunas clases de pruebas

  Pruebas de cubrimiento

  Pruebas de condiciones

  Pruebas de bucles

Pruebas de cubrimiento

Ejecutar al menos una vez cada sentencia

Se necesitan varios casos de prueba

  Determinar posibles “caminos” independientes

  Cada condición debe cumplirse en un caso y en otro no. En general, se necesitan tantos casos como condiciones, más uno (número ciclomático)

Puede ser imposible cubrir el 100%

  Código que nunca se ejecuta: condiciones imposibles

  Ejemplo: detección y notificación de errores internos en un código sin errores

Pruebas de condiciones

Cumplir o no cada parte de cada condición

Se necesitan varios casos de prueba

  Determinar expresiones simples en las condiciones

  Una por cada operando lógico o comparación

  Cada expresión simple debe cumplirse en un caso y en otro no, siendo decisiva en el resultado

Puede ser imposible cubrir el 100%

  Expresiones simples no independientes

Pruebas de bucles

Conseguir números de repeticiones especiales

Bucles simples

  Repetir cero, una y dos veces

  Repetir un número medio (típico) de veces

  Repetir el máximo-1, máximo y ¡máximo +1!

Bucles anidados

  Repetir un número medio (típico) los bucles internos, el mínimo los externos, y variar las repeticiones del bucle intermedio ensayado.

  Ensayarlo con cada nivel de anidamiento

Pruebas de “caja negra”

Concepto y terminología

  Pruebas en que se conoce sólo la interfaz

  Caja negra (black box: caja opaca)

  Se procura ejercitar cada elemento de la interfaz

Algunas clases de pruebas

  Cubrimiento ® invocar todas las funciones (100%)

  Clases de equivalencia de datos

  Pruebas de valores límite

Pruebas de valores límite

Complemento a las particiones de equivalencia

Varios casos de prueba por cada partición

  Valores típicos, intermedios

  Valores primero y segundo del rango

  Valores penúltimo y último

  Valores vecinos fuera del rango (en otra partición)

Motivación

l  Los programadores se equivocan con más frecuencia al tratar los valores en la frontera (Ej: > en vez de ³)

Estrategias de prueba del software

Contenido

  Pruebas de unidades

  Pruebas de integración

  Pruebas de regresión

  Pruebas de validación

Pruebas sin estrategia

Motivación

  Las pruebas son incómodas

  La pruebas son aburridas

  “Estoy seguro de que lo he codificado bien”

Probar todo junto, al final - Big-Bang

  Falla por todas partes

  Muy difícil diagnosticar las causas de los fallos

  Muy costoso de arreglar

  Resultado ® productos finales defectuosos

Actividades de prueba de software

img

Pruebas de Unidad

Se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño del software: el componente o módulo del software.

Las pruebas de unidad se concentran en la lógica del procesamiento interno.

Este tipo de prueba se puede aplicar en paralelo a varios componentes.

Pruebas de Integración

“Si todo funciona bien individualmente, ¿por qué dudan que funcione cuando se une?

La prueba de integración es una técnica sistemática para construir la arquitectura del software, mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz.

El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa que determine el diseño.

A menudo se tiende a intentar una integración que no sea incremental (enfoque “big bang”), se combinan todos los componentes por anticipado, se prueba todo el programa como un todo.

La principal dificultad que surge en las pruebas de integración es localizar los errores.

Hay interacciones complejas entre los componentes del sistema, y cuando se descubre una salida anómala, es difícil identificar dónde ha ocurrido el error.

Para facilitar la localización de errores, debería utilizarse una aproximación incremental para la integración y pruebas del sistema.

Inicialmente, debería integrarse una configuración del sistema mínima y probar este sistema.

A continuación, deberían añadirse componentes a esta configuración mínima y probar después de añadir cada incremento.

Pruebas de regresión

Repetir las pruebas tras cada modificación

             Repetir sólo pruebas de verificación

       Pruebas de unidades

       Pruebas de integración

            Conservar y actualizar los programas de prueba

            Usar herramientas de ejecución automática de las pruebas

Cuando se integra un nuevo incremento, hay que  volver a ejecutar las pruebas para incrementos previos, así como las nuevas pruebas requeridas para verificar la nueva funcionalidad del sistema.

Volver a ejecutar un conjunto existente de pruebas se denomina pruebas de regresión.

Si las pruebas de regresión nos muestran problemas, entonces hay que verificar si éstos son problemas en el incremento previo o si son debidos al incremento añadido de funcionalidad.

Pruebas de Validación

Las pruebas de validación empiezan tras la culminación de la prueba de integración, cuando se han ejercitado los componentes individuales. Se ha terminado de ensamblar el software como paquete y se han descubierto y corregido los errores de interfaz.

La prueba se concentra en las acciones visibles para el usuario y en la salida del sistema que éste puede reconocer.

La validación se define de una forma simple en que se alcanza cuando el software funciona de tal manera que satisface las expectativas razonables del cliente (especificación de requisitos-criterios de validación.

Comprobar que se satisfacen los requisitos

  Se usan la mismas técnicas, pero con otro objetivo

  No hay programas de prueba, sino sólo el código final de la aplicación

  Se prueba el programa completo

  Uno o varios casos de prueba por cada requisito o caso de uso especificado

  Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos)

  Pruebas alfa (desarrolladores) y beta (usuarios).

Pruebas del Sistema

Al final del desarrollo el software se incorpora a otros elementos del sistema (hardware, personas, información) y se realiza una serie de pruebas de integración del sistema y de validación.

Estas pruebas están más allá del alcance del proceso del software y no las realizan únicamente los ingenieros de software.

Sin embargo, los pasos dados durante el diseño y la prueba del software mejorarán en gran medida la probabilidad de tener éxito en la integración del software del sistema mayor.

Prueba de seguridad

La interrupción abarca un amplio rango de actividades: hackers

La prueba de seguridad comprueba que los mecanismos de protección integrados en el sistema realmente lo protejan de irrupciones inapropiadas.

Durante la prueba de seguridad quién la aplica desempeña el papel del individuo que desea entrar en el sistema.

Prueba de resistencia

Las pruebas de resistencia están diseñadas para confrontar los programas con situaciones anormales.

La prueba de resistencia ejecuta un sistema de tal manera que requiera una frecuencia o un volumen anormal de recursos

La persona que aplica la prueba tratará de sobrecargar el programa.

Una variante de la prueba de resistencia es una técnica denominada prueba de sensibilidad.

Las pruebas de sensibilidad tratan de descubrir combinaciones de datos dentro de las clases de entrada válidas que causen inestabilidad o procesamiento inapropiado.

Prueba de desempeño

La prueba de desempeño está diseñada para probar el desempeño del software en tiempo de ejecución dentro del contexto de un sistema integrado.

La prueba de desempeño se aplica en todos los pasos del proceso de la prueba, incluso al nivel de la unidad, el desempeño de un módulo individual debe evaluarse mientras se realizan las pruebas.

Sin embargo no es sino hasta que se encuentren totalmente integrados todos los elementos del sistema que es posible asegurar el verdadero desempeño del sistema.

Diseño de casos de prueba

El diseño de casos de prueba es parte de las pruebas de componentes y sistemas.

Consiste en diseñar los casos de prueba (entradas y salidas esperadas) para probar el sistema.

El objetivo es crear un conjunto de casos de prueba que sean efectivos descubriendo defectos en los programas y muestren que el sistema satisface sus requerimientos.

Para diseñar un caso de prueba, se selecciona una característica del sistema o componente que se está probando.

Pruebas basadas en requerimientos

Un principio general es que los requerimientos deben poder probarse.

Los requerimientos deberían ser escritos para que se pueda diseñar una prueba y un observador pueda comprobar que los mismos se satisfacen.

En las pruebas basadas en requerimientos el usuario considera cada requerimiento y deriva un conjunto de pruebas para cada uno de ellos.

Automatización de las Pruebas

Las pruebas son una fase cara y laboriosa del proceso del software.

Estas herramientas ofrecen una serie de facilidades y pueden reducir mucho los costos de las pruebas.

Ya vimos las pruebas de regresión.

Cada prueba individual se puede implementar como un objeto y un ejecutador de pruebas ejecuta todas las pruebas.

Las pruebas deben escribirse para que indiquen si el sistema probado funciona como se esperaba.

1. Gestor de pruebas. Gestiona la ejecución de las pruebas del programa.

Mantiene un registro de los datos de las pruebas, resultados esperados y facilidades probadas del programa.

2. Generador de datos de prueba. Genera datos de prueba para el programa a probar.

Se logra seleccionando datos de una base de datos o utilizando patrones para generar datos aleatorios.

3. Oráculo. Predice  resultados esperados de las pruebas.

Pueden ser versiones previas del programa o sistemas de prototipos.

Las pruebas back-to-back implican ejecutar el oráculo y el programa a probar, en paralelo.

Las diferencias entre sus salidas son resaltadas.

4. Comparador de ficheros. Compara los resultados de las pruebas del programa con los resultados de pruebas previas e informa de las diferencias entre ellos.

Se utilizan en pruebas de regresión, donde se comparan los resultados de ejecutar diferentes versiones.

5. Generador de informes. Proporciona informes y facilidades de generación para los resultados de las pruebas.

6. Analizador dinámico. Añade código a un programa para contar el número de veces que se ha ejecutado cada sentencia.

Después de las pruebas, se genera un perfil de ejecución que muestra cuántas veces se ha ejecutado cada sentencia del programa.

7. Simulador. Hay varios tipos de simuladores.

Los simuladores de la máquina objetivo simulan la máquina sobre la que se ejecuta el programa

Resumen

  1. Prueba de unidad: es la prueba de cada módulo, que normalmente realiza el propio personal de desarrollo en su entorno

  2. Prueba de integración: con el esquema del diseño del software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto

  3. 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.

  4. Prueba del sistema: el sw. ya validado se integra con el resto del sistema (rendimiento, seguridad, recuperación y resistencia)

  5. Prueba de aceptación: el usuario comprueba en su propio entorno de explotación si lo acepta como está o no.

Pruebas de Caja Negra y Caja Blanca

Hay dos maneras de probar cualquier producto construido:

        1. Si se conoce la función específica para la que se diseño el producto, se aplican pruebas, que demuestren que cada función es plenamente operacional, mientras se buscan los errores de cada función. (Prueba de Caja Negra)

        2. Si se conoce el funcionamiento interno del producto, se aplican pruebas para asegurarse de que todas las “piezas encajan”, es decir, que las operaciones internas se realizan de acuerdo a las especificaciones, y que se han probado