pruebas de software

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 23 Slide 1

Pruebas de software


Objetivos

Discutir las distinciones entre pruebas de validación y pruebas de defectos

Describir los principios del sistema y las pruebas de componentes

Describir las estrategias para generar casos de prueba de sistemas

Comprender las características esenciales de las herramientas utilizadas para la automatización de las pruebas.


Contenidos

Pruebas de sistema Pruebas de componentes Diseño de casos de prueba Automatización de las pruebas


El proceso de pruebas

Pruebas de componentes• Prueba de los componentes individuales del programa;• Normalmente es responsabilidad del desarrollador de

componentes (excepto a veces en sistemas críticos);• Las pruebas se derivan de la experiencia del

desarrollador. Pruebas del sistema

• Prueba de grupos de componentes integrados para crear un sistema o un subsistema;

• La responsabilidad es de un equipo de pruebas independiente;

• Las pruebas se basan en la especificación de un sistema.


Fases de pruebas

Pruebas del componente

Pruebas deintegración

Desarrollador de softwareEquipo de pruebas independiente


Pruebas de defectos

La meta de la prueba de defectos es descubrir defectos en los programas

Una prueba de defectos con éxito es aquella que causa que el programa se comporte de una manera anómala

Las pruebas muestran la presencia no la ausencia de defectos


Testing process goals

Pruebas de validación• Demostrar al desarrollador y el cliente del sistema que el

software cumple sus requerimientos;• Unas pruebas con éxito muestran que el sistema

funciona como se pretendía. Pruebas de defectos

• Descubrir fallos o defectos in el software donde su comportamiento es incorrecto o no se ajusta a su especificación;

• Una prueba con éxito es aquella que hace que el sistema no rinda de forma correcta y por tanto expone un defecto en el sistema.


Proceso de pruebas del software

Diseñar casos de pruebas

Preparar datos de prueba

Ejecutar el programa con los datos de prueba

Comparar resultados con los datos de prueba

Casos de pruebas

Datos de prueba

Resultados de la prueba

Informe de prueba


Sólo las pruebas exhaustivas pueden demostrar que un programa está libre de defectos. Sin embargo, las pruebas exhaustivas son imposibles.

Las políticas de pruebas definen la aproximación que debe usarse al seleccionar las pruebas del sistema:• Deberían ser probadas todas las funciones a las que se

ha accedido a través de menú;• Deberían comprobarse las combinaciones de funciones a

las que se ha accedido a través del mismo menú;• Donde se requiere la entrada del usuario, todas las

funciones deben ser comprobadas con entradas correctas e incorrectas.

Políticas de pruebas


Pruebas del sistema

Implica integrar componentes para crear un sistema o subsistema.

Puede implicar probar un incremento que va a entregarse al cliente.

Dos fases:• Pruebas de integración- El equipo de pruebas tiene

acceso al código fuente del sistema. El sistema es probado al tiempo que los componentes se integran en éste.

• Pruebas de entregas - El quipo de pruebas prueba el sistema completo que va a ser entregado como una «caja negra»


Pruebas de integración

Implica construir un sistema desde sus componentes y probarlo para encontrar problemas que pueden surgir de las interacciones de los componentes.

Integración descendente• Desarrollar el esqueleto del sistema y añadir

componentes. Integración ascendente

• Integrar los componentes de infraestructura y después añadir componentes funcionales.

Para simplificar la localización de errores, los sistemas deberían ser integrados incrementalmente.


Pruebas de integración incrementales

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Secuencia de prueba 1 Secuencia de prueba 2 Secuencia de prueba 3


Enfoque pruebas

Validación arquitectónica• Las pruebas de integración descendentes son mejores

para descubrir errores en la arquitectura del sistema. Demostración del sistema

• Las pruebas de integración descendente permiten una demostración limitada en una etapa temprana en el desarrollo.

Prueba de implementación• Normalmente es más fácil con pruebas de integración

ascendentes. Pruebas de observación

• Tiene problemas con varios enfoques. Puede requerirse código extra para observar las pruebas.


Pruebas de entrega

El proceso de probar la entrega de un sistema que será distribuido a los clientes

La meta principal es incrementar la confianza del proveedor en que el sistema cumplirá sus requerimientos.

La pruebas de entrega normalmente son pruebas de caja negra o funcionales• Están basadas sólo en la especificación del sistema;• Los probadores no tienen conocimientos de la

implementación del sistema;


Pruebas de caja negra

EeEntrada de datos de prueba

SeResultados de las pruebas

Sistema

Entradas que provocan comportamiento anómalo

Salidas que revelan la presencia de defectos


Pauta de pruebas

Las pautas de pruebas son pistas para ayudar al equipo de pruebas a elegir las pruebas que revelarán defectos en el sistema• Escoger entradas que fuercen al sistema a generar todos

los mensajes de error;• Diseñar entradas que hacen que los búferes de entrada

se desborden;• Repetir la misma entrada o serie de entradas varias

veces;• Forzar a que se generen las salidas inválidas;• Forzar los resultados de los cálculos para que sean

demasiado grandes o demasiado pequeños.


Escenario de pruebas

Una estudiante escocesa que estudia Historia Americana tiene que escribir un trabajo sobre «la mentalidad sobre las fronteras en el Este Americano desde 1840 a 1880». Para hacer esto, necesita encontrar documentación de varias bibliotecas. Se registra en el sistema LIBSYS y utiliza la facilidad de búsqueda para ver si puede acceder a los documentos originales de esa época. Descubre trabajos en varias bibliotecas universitarias de Estados Unidos y descarga copias de algunos de ellos. Sin embargo, para uno de los documentos , necesita tener confirmación de su Universidad de que ella en verdad es estudiante y de que el uso del documento es para fines no comerciales. La estudiante entonces utiliza la facilidad de LIBSYS que le permite solicitar dicho permiso y registrar su petición. Si ésta es aceptada, el documento podrá descargarse en el servidor de la biblioteca registrada y ser impreso. La estudiante recibe un mensaje de LIBSYS informándole de que recibirá un mensaje de correo electrónico cuando el documento impreso esté disponible para ser recogido.


Pruebas de sistemas


Casos de uso

Los casos de uso pueden ser la base de derivar las pruebas para un sistema. Ayudan a identificar las operaciones que van a probarse y ayuda a diseñar los casos de pruebas requeridos.

Desde un diagrama de secuencia asociado, pueden identificarse las entradas y salidas que deben crearse para las pruebas.


Diagrama de secuencia de recopilación de datos sobre el tiempo

:CommsController

request (report)

acknowledge ()report ()

summarise ()

reply (report)

acknowledge ()

send (report)

:WeatherStation :WeatherData


Pruebas de rendimiento

Parte de las pruebas de entrega puede implicar probar las propiedades emergentes de un sistema, como el rendimiento y la fiabilidad.

Las pruebas de rendimiento normalmente implican planificar una serie de pruebas donde la carga se incrementa a un ritmo constante hasta que el rendimiento del sistema llega a ser inaceptable.


Pruebas de estrés

Ejercita el sistema por encima de su carga máxima de diseño. Estresar el sistema a veces provoca que los defectos salgan a la luz.

Estresar el sistema prueba el comportamiento de fallos. Los sistemas no deberían fallar catastróficamente. Las pruebas de estrés comprueban las pérdidas inaceptables de servicio o datos.

Estresar el sistema es particularmente importante para sistemas distribuidos que pueden exhibir una degradación severa cuando una red de trabajo se sobrecarga.


Pruebas de componentes

Las pruebas de componentes o pruebas de unidad son los procesos de prueba de componentes individuales aislados.

Es un proceso de prueba de defectos. Los componentes pueden ser:

• funciones individuales o métodos dentro de un objeto;• clases de objetos con varios atributos y métodos;• Componentes compuestos con interfaces definidas

utilizadas para acceder a su funcionalidad.


Pruebas de clases de objetos

Completar la cobertura de pruebas de una clase implica• Probar todas las operaciones asociadas con un objeto;• establecer e interrogar todos los atributos de los objetos;• Ejercitar el objeto en todos los estados posibles.

La herencia hace que sea más difícil diseñar pruebas de clases de objetos ya que no se localiza la información que se va a probar.


Interfaz del objeto de la estación meteorológica

identifier

reportWeather ()calibrate (instruments)

test ()startup (instruments)

shutdown (instruments)

WeatherStation


Pruebas de una estación meteorológica

Necesita definir los casos de pruebas para reportWeather, calibrate, test, startup and shutdown.

Utilizando un modelo de estado, identifica secuencias de transiciones de estado que se van a probar y las secuencias de estado que causan estas transiciones

Por ejemplo:• Waiting -> Calibrating -> Testing -> Transmitting

-> Waiting


El objetivo es detectar fallos debidos a errores de la interfaz o suposiciones inválidas sobre las interfaces.

Es particularmente importante para el desarrollo orientado a objetos ya que los objetos se definen por sus interfaces.

Pruebas de interfaces


Pruebas de interfaces

B

C

Casos de pruebas

A


Tipos de interfaz

Interfaces de parámetro• Datos que pasan de un procedimiento a otro.

Interfaces de memoria compartidas• Se comparte un bloque de memoria entre procesos o

funciones Interfaces procedurales

• Un subsistema encapsula un conjunto de procedimientos que pueden ser llamados por otros componentes.

Interfaces de paso de mensajes• Los subsistemas piden servicios de otros subsistemas.


Errores de interfaz

Mal uso de la interfaz• Un componente llama a otro componente y comete un

error en la utilización de su interfaz. P.Ej.: parámetros en el orden incorrecto.

No comprensión de la interfaz• El componente que realiza la llamada hace suposiciones

incorrectas sobre el comportamiento del componente llamado que.

Errores temporales• El objeto que llama y el llamado operan a diferentes

velocidades y se accede a información no actualizada.


Pautas para la prueba de interfaces

Diseñar los parámetros de forma que los parámetros para un procedimiento al que se ha llamado estén en los extremos de sus rangos

Probar siempre los parámetros punteros con punteros nulos.

Diseñar pruebas que provoquen el fallo del componente.

Utilizar pruebas de estrés en los sistemas de paso de mensajes

En sistemas de memoria compartida, variar el orden en que se activan los componentes.


Diseño de casos de pruebas

Implica diseñar casos de pruebas (entradas y salidas) utilizadas para probar el sistema.

La meta del diseño de casos de pruebas es crear un conjunto de pruebas que sean efectivas en las pruebas de validación y defectos.

Diseñar aproximaciones:• Pruebas basadas en requerimientos;• Pruebas de particiones;• Pruebas estructurales.


Requerimientos basados en pruebas

Un principio general de la ingeniería de requerimientos es que los requerimientos deberían ser estables.

Las pruebas basadas en requerimientos son técnicas de pruebas de validación donde se considera cada requerimiento y se deriva un conjunto de pruebas para ese requerimiento.


Requerimientos LIBSYS


Pruebas LIBSYS

Iniciar búsquedas de usuario para elementos de los que se conoce que están presentes y para elementos que se sabe que no están presentes, en las que el conjunto de bases de datos incluye una base de datos

Iniciar búsquedas de usuario para elementos de los que se sabe que están presentes y para elementos de los que se sabe que no están presentes, en las que el conjunto de bases datos incluye dos bases de datos

Iniciar búsquedas de usuario para elementos de los que se sabe que están presentes y para elementos de los que se sabe que no están presentes, en las que el conjunto de bases datos incluye dos o más bases de datos.

Seleccionar una base de datos del conjunto de bases de datos e iniciar búsquedas de usuario para elementos que se sabe que están presentes y para elementos de los que se sabe que no están presentes

Seleccionar más de una base de datos del conjunto de bases de datos e iniciar búsquedas de usuario para elementos de los que se sabe que están presentes y para elementos de los que se sabe que no están presentes.


Pruebas de particiones

Los datos de entrada y los resultados de salida con frecuencia se dividen en diferentes clases en las que todos los miembros de una clase están relacionados.

Cada una de estas clases es una partición de equivalencia o dominio en la que el programa se comporta de forma equivalente para cada miembro de la clase.

Deberían escogerse casos de pruebas de cada partición.


Particiones de equivalencia

System

salidas

Entradas inválidas Salidas válidas

Sistema


Particiones de equivalencia

Entre10000 y 99999Menor que 10.000 Más de99999

999910000 50000

10000099999

Valores de entrada

Entre 4 y 10Menor que 4 Más de 10

34 7

1110

Número de valores de entrada


Especificación de rutina de búsqueda

procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

Pre-condition-- la secuencia tiene al menos un elementoT’FIRST <= T’LAST

Post-condition-- el elemento se encuentra y es referenciado por L( Found and T (L) = Key)

or -- el elemento no está en la secuencia( not Found and

not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))


Entradas que se ajustan a las precondiciones.

Entradas donde una precondición no encaja. Entradas en las que el elemento clave es un

miembro del vector. Entradas en las que el elemento clave no es

un miembro del vector.

Rutina de búsqueda– particiones de entradas


Pautas de pruebas (secuencias)

Probar el software con secuencias que tienen un único valor.

Utilizar secuencias de diferentes tamaños en diferentes pruebas.

Derivar pruebas para que se acceda a los elementos primero, intermedio y último de la secuencia.

Probar con secuencias de longitud cero.


Rutina de búsqueda– particiones de entrada


A veces también llamadas pruebas de caja blanca

Derivación de casos de pruebas de acuerdo a la estructura del programa. El conocimiento del programa se utiliza para identificar casos de pruebas adicionales.

El objetivo es ejercitar todas las sentencias del programa (no todas las combinaciones de caminos)

Pruebas estructurales


Pruebas estructurales

Código del componente

Salidas de prueba

Datos de prueba

Deriva enPruebas


Precondiciones satisfechas, elemento clave en vector

Precondiciones satisfechas, elemento clave no está en vector

Precondiciones insatisfechas, elemento clave en vector.

Precondiciones insatisfechas, elemento clave no está en vector.

Vector de entrada tiene un único valor. Vector de entrada tiene un número par de valores. Vector que tiene un número impar de valores.

Búsqueda binaria– particiones equivalentes


Particiones equivalentes de búsqueda binaria

Punto medio

Elementos < Mid Elementos > Mid

Límites de la clase de equivalenciav


Búsqueda binaria– casos de pruebas


Prueba de caminos

El objetivo de las pruebas de caminos es asegurar que el conjunto de casos de pruebas es tal que cada camino es ejecutado a través del programa al menos una vez.

El punto de comienzo para la prueba de caminos es un gráfico de flujo del programa que muestra los nódulos que representan las decisiones del programa y arcos que representan el flujo de control.

Las sentencias con condiciones son, por lo tanto, nódulos en el gráfico de flujo.


Gráfico de flujo para búsqueda binaria

elemArray [mid] != key

elemArray [mid] > key elemArray [mid] < key

1

2

3

4

5

6

7

8

9

14 10

11

12 13

bottom > top while bottom <= topbottom > top

elemArray[mid] = key


1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, … 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, … Los casos de pruebas deberían derivarse

para que todos estos caminos se ejecuten Puede usarse un analizador dinámico del

programa para comprobar los caminos que han sido ejecutados

Caminos independientes


Automatización de las pruebas

Probar es una fase del proceso cara. Probar bancos de trabajo proporciona cierta variedad de herramientas para reducir el tiempo necesario y los costes totales de las pruebas.

Sistemas como Junit soportan la ejecución automática de pruebas.

La mayoría de los bancos de trabajo son sistemas abiertos porque las necesidades de pruebas son específicas de la organización.

A veces es difícil integrar con un diseño cerrado y bancos de trabajo.


Un banco de trabajos de pruebas

Analizador dinámico

Programa en prueba

Resultado de la prueba

Predicciones de pruebas

Comparador de archivos

Informe de ejecución Simulador

Código fuente

Administrador de pruebas

Datos de prueba Oráculo

GeneradorDe datos de prueba

Especificación

Generador de informes

Informe de los resultados de la prueba


Adaptación de bancos de trabajo de pruebas

Se pueden desarrollar scripts para los simuladores de interfaz del usuario y patrones para los generadores de datos de pruebas.

Las salidas de pruebas pueden tener que estar preparadas manualmente para su comparación.

Podrían desarrollarse comparadores de archivos para un propósito especial.


Puntos clave

Las pruebas pueden demostrar la presencia de fallos en un sistema; no puede probar que no quedan fallos.

Los desarrolladores de un componente son responsables de las pruebas del componente; Las pruebas del sistema son responsabilidad de un equipo aparte.

La integración de pruebas es comprobar los incrementos del sistema; las pruebas a entregar implican probar que un sistema que va a ser entregado a un cliente.

Utilizar la experiencia y las pautas para diseñar casos de pruebas en pruebas de defectos.


Puntos clave

Las pruebas de interfaz están diseñadas para descubrir defectos en las interfaces de componentes compuestos.

La partición de equivalencia es una forma de descubrir casos de pruebas : todos los casos en una partición deberían comportarse del mismo modo.

El análisis estructural depende del análisis de un programa y las pruebas de derivación del análisis.

La automatización de pruebas reduce los costes de pruebas apoyando los procesos de pruebas con varias herramientas de software

pruebas de software

Documents