DISEÑO Y REALIZACION DE PRUEBA

Puede estar orientado a:

Orientadas al usuario (tiempo de respuesta...)

Orientada al sistema (uso de la CPU, tiempo de retorno, capacidad de ejecución, la carga de trabajo...)

Pruebas principales

Pruebas de carga: Se realizan sobre el sistema simulando una serie de peticiones, evaluando los tiempos de respuestas de las transacciones

Prueba de estrés: Se expone la aplicación a un numero de usuario y transacciones extremas para ver como se maneja

Prueba de estabilidad: Se somete al programa a una carga determinada donde la carga va cambiando

Factores de calidad

Tolerancia a errores

Facilidad de expansion

Independencia de la plataforma del hardware

Medularidad

Estandarizacion de los datos

a tomarse como ejemplo JUnit, un framework que permite realizar test repetibles (pruebas de regresión), es decir, que puede diseñarse un test para un programa o clase conetera y ejecutarlo tantas veces como sea necesario. La ventaja es que puede (o mejor, debe) ejecutarse el test cada vez que se modifique o cambie algo del código y verificar si el programa sigue funcionando correctamente tras los cambios.

PRUEBAS UNITARIAS

Suelen realizarse durante las primeras
fases de diseño y desarrollo. Se realizan
pruebas a nivel objeto y luego a nivel de paquete

AUTOMATIZACION

Puede ser necesario automatizar las pruebas o repetir las mismas pruebas tras realizar mantenimiento, modificaciones o correcciones de software

PRUEBAS DE INTEGRACION

Se realiza al final de la fase de diseño y al final de la fase de codificación. El objetivo es probar que el sistema en conjunto funcione correctamente

PRUEBAS DE ACEPTACION

Trata de probar el sistema al completo, comprueba que se cumplan los requisitos uno por uno, así como si técnicamente es estable y no tiene fallos

CASOS DE PRUEBA

En esta fase de prueba, se diseñan y
preparan los casos de prueba, se crean
con el objetivo de encontrar fallos.

PROCEDIMIENTO

ASPECTOS GENERALES

1. Introduccion

2. Modulos o partes del software por probar

3. Caracteristicas del software por probar

4. Caracteristicas del software que no lia de probarse

5. Enfoque de prueba

6. Criterio de validez

7. Proceso de prueba

8. Requirimiento del entorno

9. Homologación

TIPOS PRINCIPALES DE PRUEBA

CAJA BLANCA

Se tiene en cuenta el codigo que quiere probarse

PRUEBA DE CONDICIONES

PRUEBA DE ENCUBRIMIENTO

PRUEBA DE BUCLE

CAJA NEGRA

Se prueban en la interfaz sin tener en cuenta el codigo

PRUEBA DE EQUIVALENCIA DE DATOS

PRUEBA DE INTERFACES

PRUEBA DE VALORES LIMITE

TIPOS

ESTRUCTURALES

Esta forma examina de forma mas detallada
la arquitectura de la aplicacion

REGRESION

Trata de descrubir si existe algun
error en el software tras relaizar una
modificacion en este

FUNCIONALES

Busca que los componentes de software
diseñados cumplan la funcion con las que
fueron diseñaods y desarrolado