Pruebas Funcionales o Caja Negra

Estudia la especificacin del software, las funciones que debe realizar, las entradas y las salidas. Busca tipos de errores diferentes a las pruebas de caja blanca:
es el sistema particularmente sensible a ciertos datos de entrada? qu volumen de datos tolerar el sistema? qu efectos tendrn determinadas combinaciones de datos sobre el funcionamiento del sistema?

Un caso de prueba est bien elegido si: reduce el n de casos de prueba adicionales para alcanzar una prueba razonable nos dice algo sobre la presencia o ausencia de clases de errores.

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 18 -

Particiones o clases de equivalencia (Piattini et al. 96)

Cada caso de prueba debe cubrir el mximo n de entradas. Debe tratarse el dominio de valores de entrada dividido en un n finito de clases de equivalencia la prueba de un valor representativo de la clase permite suponer
razonablemente que el resultado obtenido ser el mismo que probando cualquier otro valor de la clase

Mtodo de diseo:
1. Identificacin de clases de equivalencia. 2. Creacin de los casos de prueba correspondientes.

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 19 -

Paso 1. Identificar las clases de equivalencia

1.1. Identificar las condiciones de las entradas del programa 1.2. A partir de ellas, se identifican las clases de equivalencia:
1. 2. 3. 4. 5. De datos vlidos De datos no vlidos Por cada rango de valores, se especifica una clase vlida y dos no vlidas. Si se especifica un n de valores, se crear una clase vlida y dos no vlidas. Si se especifica una situacin del tipo debe ser o booleana, se identifica una clase vlida y una no vlida. Si se especifica un conjunto de valores admitidos, y el programa trata de forma distinta cada uno de ellos, se crea una clase vlida por cada valor, y una no vlida. Si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, debe dividirse en clases menores.

1.3. Algunas reglas para identificar clases:

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 20 -

1.3. Algunas reglas para identificar clases:

1. 2. Por cada rango de valores, se especifica una clase vlida y dos no vlidas
(vlida) 1 nmero 49; (no vlidas) nmero < 1, nmero > 49 (vlida) num propietarios = 3; (no vlidas) num propietarios < 3, num propietarios > 3

Si se especifica un n de valores, se crear una clase vlida y dos no vlidas

3.

Si se especifica una situacin del tipo debe ser o booleana, se identifica una clase vlida y una no vlida
(vlida) El primer carcter es una letra; (no vlida) (...) no es una letra (vlida) X es un nmero; (no vlida) X no es un nmero

4.

Si se especifica un conjunto de valores admitidos, y el programa trata de forma distinta cada uno de ellos, se crea una clase vlida por cada valor, y una no vlida
Tres tipos de inmuebles: (vlidas) pisos, chalets, locales comerciales; (no vlida) jkll

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 21 -

Paso 2. Identificar los casos de prueba

2.1. Asignacin de un nmero nico a cada clase de equivalencia. 2.2. Hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba, se tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible. 2.3. Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, escribir un caso para una NICA clase no vlida sin cubrir.

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 22 -

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 23 -

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 24 -

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 25 -

Anlisis de Valores Lmite (AVL)

Los casos de prueba que exploran las condiciones lmite producen mejores resultados Los defectos del software se acumulan en las situaciones lmite Diferencias de AVL con particiones de equivalencia:
No se elige cualquier elemento de la clase de equivalencia, sino uno o ms de manera que los mrgenes se sometan a prueba. Los casos de prueba se generan considerando tambin el espacio de salida.
Ing. Christian Araujo Gonzlez Mtodos de Prueba de Software - 26 -

Reglas para identificar casos (en AVL)

1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben generar casos para a y b y casos no vlidos justo por debajo y justo por encima de a y b, respectivamente. Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo, uno ms el mximo y uno menos el mnimo. Aplicar las directrices 1 y 2 a las condiciones de salida. Si las estructuras de datos internas tienen lmites preestablecidos, hay que asegurarse de disear un caso de prueba que ejercite la estructura de datos en sus lmites.

2.

3. 4.

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 27 -

Ejemplo Reglas para identificar casos (en AVL)

1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben generar casos para a y b y casos no vlidos justo por debajo y justo por encima de a y b, respectivamente

Rango de entrada: [-1.0, 1.0]

2.

Casos de prueba para 1.0, +1.0, -1.001, +1.001 (si se admiten 3 decimales) Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo, uno ms el mximo y uno menos el mnimo

3.

El fichero de entrada tendr de 1 a 255 registros

Casos para 0, 1, 254, 255 registros Aplicar las directrices 1 y 2 a las condiciones de salida

El programa podr mostrar de 1 a 4 listados

Casos para intentar generar 0, 1, 4 y 5 listados
- 28 -

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 29 -

Prueba de Interfaces Grficas de Usuario

(GUI, Graphical User Interface)
Uso de una lista de chequeo preestablecida (ver (Pressman 98), p.319): Para ventanas:
Se abrirn las ventanas mediante rdenes basadas en el teclado o en un men? Se puede ajustar el tamao, mover y desplegar la ventana? Se regenera adecuadamente cuando se escribe y se vuelve a abrir? ... Se muestra la barra de men apropiada en el contexto apropiado? Es correcto el tipo, tamao y formato del texto? Si el ratn tiene varios botones, estn apropiadamente reconocidos en el contexto? ...

Para mens emergentes y operaciones con el ratn:

Entrada de datos:
Se repiten y son introducidos adecuadamente los datos alfanumricos? Funcionan adecuadamente los modos grficos de entrada de datos? (p.e. barra deslizante) Se reconocen adecuadamente los datos no vlidos? Son inteligibles los mensajes de entrada de datos?

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 30 -

Estrategias de prueba del software. Niveles de prueba

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

2. Prueba de integracin: con el esquema del diseo del software, los mdulos
probados se integran para comprobar sus interfaces en el trabajo conjunto

3. Prueba de validacin: el software totalmente ensamblado se prueba como un

todo para comprobar si cumple los requisitos funcionales y de rendimiento, facilidad de mantenimiento, recuperacin de errores, etc.

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

5. Prueba de aceptacin: el usuario comprueba en su propio entorno de explotacin

si lo acepta como est o no

Ing. Christian Araujo Gonzlez

Mtodos de Prueba de Software

- 31 -

Relacin entre productos de desarrollo y niveles de prueba

Requisitos de usuario Especificacin de requisitos Diseo modular Especificacin lgica del mdulo Pruebas de aceptacin

Pruebas de sistema

Pruebas de integracin Pruebas de unidad

(Piattini et al. 96)

Ing. Christian Araujo Gonzlez

Cdigo
Mtodos de Prueba de Software - 32 -