Está en la página 1de 17

LA PRUEBA DEL SOFTWARE

Objetivo:
Descubrir errores en el software

Es necesario crear buenos casos de prueba (aqul que tiene
una alta probabilidad de mostrar errores an no descubiertos)

Una prueba tiene xito si descubre un error no detectado hasta
entonces.
PRINCIPIOS DE LA PRUEBA
A todas las pruebas se les debera hacer un
seguimiento hasta los requisitos del cliente.

Las pruebas deberan planificarse mucho antes
de que empiecen.

El principio de Pareto es aplicable a la prueba
de software. (El 80% de los errores descubiertos
con las pruebas surgen de hacerle seguimiento
slo al 20% de todos los mdulos del programa).
El problema es aislar esos mdulos sospechosos y
probarlos concienzudamente.

PRINCIPIOS DE LA PRUEBA
Las pruebas empiezan por lo pequeo y
progresan hasta lo grande.

No son posibles las pruebas exhaustivas.

Para ser ms efectivas, las pruebas deberan ser
conducidas por un equipo independiente.

ENFOQUES DE PRUEBA
PRODUCTO

puede
probarse


1. PRUEBAS DE CAJA NEGRA
Conociendo la funcin para la que
fue diseado, se hacen pruebas
que demuestren que cada funcin
es operativa y al mismo tiempo se
buscan errorres en cada una.
Pruebas sobre la interfaz del
software
2. PRUEBAS DE CAJA BLANCA
Conociendo el funcionamiento del producto,
se desarrollan pruebas que aseguren que
todas las piezas encajan, que la operacin
interna se ajusta a las especificaciones y
que todos los componentes internos se han
comprobado adecuadamente.
Examen minucioso de detalles
procedimentales
PRUEBAS DE CAJA BLANCA
Casos de prueba que:

1. Garanticen que se ejercitan por lo menos una
vez TODOS los caminos, independientemente
de cada mdulo.
2. Ejerciten todas las decisiones lgicas por sus
vertientes Cierto y Falso.
3. Ejecuten todos los ciclos en sus lmites y lmites
operacionales.
4. Ejerciten las estructuras internas de datos para
asegurar su validez.
PRUEBAS DE CAJA NEGRA
Permiten obtener conjuntos de condiciones de
entrada que ejecuten todos los requisitos
funcionales de un programa.

Las pruebas de caja negra NO son una alternativa
a las tcnicas de prueba de caja blanca. Es un
enfoque complementario.

Las pruebas de caja negra intentan hallar errores
tales como:

PRUEBAS DE CAJA NEGRA
1. Funciones incorrectas o ausentes.

2. Errores de interfaz.

3. Errores en estructuras de datos o en accesos a
BD externas.

4. Errores de rendimiento.

5. Errores de inicializacin y de terminacin.
OTRAS PRUEBAS

Pruebas de GUI (Interfaces Grficas de Usuario).

Pruebas de Arquitectura Cliente/Servidor.

Pruebas de Documentacin y Ayudas.
TIPO DE PRUEBAS
Pruebas Unitarias

Hacen uso intensivo de tcnicas de prueba de caja
blanca.

Se prueba la interfaz del mdulo (Primero que todo, si no
funciona, NO seguir. Verificar que la informacin llega y
sale de manera correcta).

Estructuras de datos locales (datos se conservan ntegros
durante la ejecucin).
TIPO DE PRUEBAS
Pruebas Unitarias

Condiciones lmites. (Caminos de control para
asegurar que se ejecutan al menos una vez;
luego se prueban todos los caminos de manejo
de errores).

Validez Funcional.

TIPO DE PRUEBAS
Pruebas de integracin

Usa fundamentalmente tcnicas de caja negra.

Algunas veces usa tcnicas de prueba de caja
blanca para asegurar que se cubren los
principales caminos de control.
TIPO DE PRUEBAS
Pruebas de Alto Nivel

Sirven para comprobar si se cumplen los criterios
de validacin.

Prueba de Validacin

Se usa para verificar si se cumplen todos los
requerimientos funcionales, de comportamiento y
de rendimiento.

TIPO DE PRUEBAS
Prueba del Sistema

Operando en condiciones reales.

Pruebas de recuperacin
Pruebas de seguridad
Pruebas de resistencia (pruebas en situaciones
anormales)
Pruebas de rendimiento

ESPECIFICACIN DE LA PRUEBA
1. mbito de la Prueba.
(Caractersticas, funcionamiento, rendimiento y
diseo interno que se van a probar). Se
delimita el esfuerzo de la prueba, se describen
los criterios de terminacin de cada fase de
prueba.

2. Plan de Prueba
Describe la estrategia general para la
integracin. Se divide en fases y
construcciones que tratan caractersticas
funcionales y de comportamiento del software.
ESPECIFICACIN DE LA PRUEBA
3. Procedimiento de Prueba
Orden de integracin (propsito y mdulos a
probar).
Pruebas Unitarias (descripcin prueba mdulo n).
Entorno de la prueba (herramientas o tcnicas
especficas).
Datos de los casos de prueba.
Resultados esperados.
ESPECIFICACIN DE LA PRUEBA
4. Resultados de prueba obtenidos.

5. Referencias.

6. Apndices.
PRUEBAS ALFA Y BETA
Para descubrir errores que pareciera que slo el usuario
puede descubrir.

Prueba Alfa
Se hace en el lugar de desarrollo y con un cliente que la
realiza. El desarrollador es un observador del usuario y
registra errores y problemas de uso.
Pruebas Beta
La hacen los usuario finales. Se hacen despus de haber
acogido las pruebas del sistema y las pruebas alfa.

También podría gustarte