Prueba Unitaria

Objetivo de la Se focaliza en ejecutar cada mdulo (o unidad minima a ser probada,

Prueba: ej. = una clase) lo que provee un mejor modo de manejar la integracin
de las unidades en componentes mayores.

Busca asegurar que el cdigo funciona de acuerdo con las

especificaciones y que el mdulo lgico es vlido.
Descripcin de Particionar los mdulos en pruebas en unidades lgicas fciles
la Prueba: de probar.
Por cada unidad hay que definir los casos de prueba (pruebas
de caja blanca).
Para esto los casos de prueba deben disearse de forma tal que
se recorran todos los caminos de ejecucin posibles dentro del
cdigo bajo prueba; por lo tanto el diseador debe construirlos
con acceso al cdigo fuente de la unidad a probar.
Los aspectos a considerar son los siguientes: Rutinas de
excepcin, Rutinas de error, Manejo de parmetros,
Validaciones, Valores vlidos, Valores lmites, Rangos,
Mensajes posibles.

Tcnica: Comparar el resultado esperado con el resultado obtenido.

Si existen errores, reportarlos.

Criterio de Todas las pruebas planeadas han sido ejecutadas.

Completitud: Todos los defectos que se identificaron han sido tenidos en
cuenta.

Consideraciones Para la elaboracin de pruebas unitarias en java se puede utilizar el

Especiales: JUNIT y CACTUS.

PRUEBAS DE INTEGRACIN

Prueba de Integracin

Objetivo de la Identificar errores introducidos por la combinacin de programas

Prueba: probados unitariamente.

Determina cmo la base de datos de prueba ser cargada.

Verificar que las interfaces entre las entidades externas (usuarios) y las
aplicaciones funcionan correctamente.

Verificar que las especificaciones de diseo sean alcanzadas.

 Determina el enfoque para avanzar desde un nivel de integracin de
las componentes al siguiente.
Descripcin de Describe cmo verificar que las interfaces entre las componentes de
la Prueba: software funcionan correctamente.

Determina cmo la base de datos de prueba ser cargada.

Determina el enfoque para avanzar desde un nivel de integracin de

las componentes al siguiente.

Decide qu acciones tomar cuando se descubren problemas.

Por cada Caso de Prueba ejecutado:

Comparar el resultado esperado con el resultado obtenido.

Tcnica: Utilizar la tcnica top-Down. Se empieza con los mdulos de

nivel superior, y se verifica que los mdulos de nivel superior
llaman a los de nivel inferior de manera correcta, con los
parmetros correctos.
Utilizar la tcnica Down-top. Se empieza con los mdulos de
nivel inferior, y se verifica que los mdulos de nivel inferior
llaman a los de nivel superior de manera correcta, con los
parmetros correctos.

Criterio de Todas las pruebas planeadas han sido ejecutadas.

Completitud: Todos los defectos que se identificaron han sido tenidos en
cuenta.

Consideraciones Ninguna
Especiales:

Prueba de Regresin

Pruebas de Humo (Smoke Testing o Ad Hoc)

Objetivo de la Prueba: Los objetivos son los siguientes:


Descripcin de la Prueba:
Tcnica:
Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido
Consideraciones Especiales:
Detectar los errores en realeases tempranos y
de manera fcil
Probar el sistema constantemente
Garantizar poco esfuerzo en la integracin
final del sistema
Asegurar los resultados de las pruebas
unitarias
Se reducen los riesgos y a baja calidad.
Toma ste nombre debido a que su objetivo es probar
el sistema constantemente buscando que saque
humo o falle. En algunos proyectos este tipo de
prueba va junto con las pruebas funcionales. Permite
detectar problemas que por lo regular no son
detectados en las pruebas normales. Algunas veces,
si las Pruebas ocurren tarde en el ciclo de desarrollo
est ser una forma de garantizar el buen desarrollo.
Las pruebas de humo NO SON exhaustivas, pero van
de extremo a extremo de la aplicacin.
1. Realizar una integracin de todo el sistema
cada cierto periodo (se recomienda un da,
mximo una semana)
2. Realizar los casos de prueba asignados a los
casos de uso finalizados ese da ms los
realizados en das anteriores
3. Buscar eficientemente errores
tenidos en cuenta.
Cuando se encuentre un error en el relase
correspondiente al periodo elegido para hacer las
integraciones del sistema, se detiene el desarrollo
hasta que el error es corregido.
Este tipo de pruebas es til en la programacin
extrema (extremme programming) y de sistemas
complejos.
Es til el uso de programas de prueba automticas
que se encarguen de probar os casos de prueba ya
ejecutados en realeases anteriores.
Pruebas de Desempeo

Objetivo de la Prueba: Validar el tiempo de respuesta para las transacciones

o funciones de negocios bajo las siguientes dos
condiciones:

Volumen normal anticipado

Volumen mximo anticipado.

Descripcin de la Prueba: Las pruebas de desempeo miden tiempos de

respuesta, ndices de procesamiento de transacciones
y otros requisitos sensibles al tiempo. El objetivo de
las pruebas de desempeo es verificar y validar los
requisitos de desempeo que se han especificado (en
este caso, el desempeo ofrecido por el proponente).

Las pruebas de desempeo usualmente se ejecutan

varias veces, utilizando en cada una, carga diferente
en el sistema. La prueba inicial debe ser ejecutada
con una carga similar a la esperada en el sistema.
Una segunda prueba debe hacerse utilizando una
carga mxima.

Adicionalmente, las pruebas de desempeo pueden

ser utilizadas para perfilar y refinar el desempeo del
sistema como una funcin de condiciones tales como
carga o configuraciones de hardware

Las principales actividades son:

Comparar el desempeo del sistema actual

con los requisitos,
Poner a punto el sistema para mejorar las
mtricas de desempeo y proyectar la
capacidad futura de carga del sistema.

Los objetivos de nivel de servicio definidos deben

guiar la prueba de performance. Algunas
caractersticas que afectan el desempeo son:

Errores lgicos
Procesamiento ineficiente
Diseo pobre: muchas interfases,
instrucciones y entradas/salidas.
 Cuellos de botella en discos, CPU canales
de entrada/salida
Salidas del sistema
Tiempos de respuesta
Capacidad de almacenamiento
Tasa de entrada/salida de datos
Nmero de transacciones que pueden ser
manejadas simultneamente.

Las pruebas de desempeo utilizan las tcnicas de

caja blanca y caja negra.
Tcnica: Utilice los procedimientos de prueba
desarrollados para las pruebas del modelo del
negocio (Pruebas del Sistema).
Modifique archivos de datos (para
incrementar el nmero de transacciones) o
los scripts para incrementar el nmero de
veces que ocurre cada transaccin.
Los scripts deben ser ejecutados en una
mquina y deben ser repetidos con mltiples
clientes (virtuales o actuales). (Ver
consideraciones especiales).

Criterio de Completitud: Un Usuario / Una Transaccion. Se

completaron las pruebas sin ninguna falla y
dentro del tiempo esperado o requerido por
transaccin.
Mltiples transacciones, mltiples usuarios.
Se completaron las pruebas de los scripts sin
ninguna falla y dentro del tiempo esperado.

Consideraciones Especiales: Unas pruebas de desempeo integrales incluyen

tener una carga en background en el servidor.
Hay varios mtodos que pueden ser utilizados
para hacer sto:

o Transacciones dirigidas directamente al

servidor, usualmente en forma de
sentencias SQL.

o Creacin de usuarios virtuales para simular

muchos clientes (usualmente varios
cientos). Se utilizan herramientas de
Emulacin de Terminales Remotas para
obtener esta carga. Esta tcnica tambin
 puede ser utilizada para cargar de trfico
la red.

o Use mltiples clientes fsicos, cada uno

corriendo los scripts de prueba.

Las pruebas de desempeo deben ser ejecutadas en

una mquina dedicada o en un tiempo dedicado.
Esto permite control total y medidas precisas.

La Base de datos utilizada para pruebas de

desempeo debe ser de un tamao real o
proporcionalmente ms grande que la diseada.

Pruebas de Carga

Objetivo de la Prueba: Verificar el tiempo de respuesta del sistema para

transacciones o casos de uso de negocios, bajo
diferentes condiciones de carga.
Descripcin de la Prueba: Las pruebas de carga miden la capacidad del sistema
para continuar funcionando apropiadamente bajo
diferentes condiciones de carga.

La meta de las pruebas de carga es determinar y

asegurar que el sistema funciona apropiadamente
an ms all de la carga de trabajo mxima esperada.
Adicionalmente, las pruebas de carga evalan las
caractersticas de desempeo (tiempos de respuesta,
tasas de transacciones y otros aspectos sensibles al
tiempo).
Tcnica: Use los scripts desarrolladas para Pruebas del
Negocio.
Modifique archivos de datos (para
incrementar el nmero de transacciones o
veces que cada transaccin ocurre).

Criterio de Completitud: Mltiples transacciones, mltiples usuarios.

Se completaron las pruebas de los scripts sin
ninguna falla y dentro del tiempo esperado.

Consideraciones Especiales: Las pruebas de carga deben ser ejecutadas en

una mquina dedicada o en un tiempo
dedicado. Esto permite control total y
medidas precisas.
La Base de datos utilizada para pruebas de
desempeo debe ser de un tamao real o
 proporcionalmente ms grande que la
diseada.

Pruebas de Volumen

Objetivo de la Prueba: Verificar que la aplicacin funciona

adecuadamente bajo los siguientes escenarios de
volumen:

o Mximo (actual o fsicamente posible)

nmero de clientes conectados (o
simulados), todos ejecutando la misma
funcin (peor caso de desempeo) por un
perodo extendido.

o Mximo tamao de base de datos (actual o

escalado) y mltiples consultas
ejecutadas simultneamente
Descripcin de la Prueba: Las pruebas de volumen hacen referencia a grandes
cantidades de datos para determinar los lmites en
que se causa que el Sistema falle. Tambin
identifican la carga mxima o volumen que el
sistema puede manejar en un perodo dado. Por
ejemplo, si el sistema est procesando un conjunto
de registros de Base de datos para generar un reporte,
una prueba de volumen podra usar una Base de
datos de prueba grande y verificar que el sistema se
comporta normalmente y produce el reporte
correctamente.

El objetivo de esta prueba es someter al sistema a

grandes volmenes de datos para determinar si el
mismo puede manejar el volumen de datos
especificado en sus requisitos.

Algunos ejemplos de escenarios de prueba de

volmenes:

Un compilador puede ser alimentado por un

programa para compilar que sea absurdamente
grande.

Un editor de nexos puede recibir un programa que

contenga miles de mdulos.

Tcnica:
Criterio de Completitud:
Consideraciones Especiales:
Pruebas de Recuperacin y Tolerancia a fallas
Objetivo de la Prueba:
Un simulador de circuito electrnico puede recibir
un circuito diseado con miles de componentes.
Puesto que obviamente, la prueba de volumen es una
prueba costosa, tanto en tiempo de mquina como en
personal, se debe tratar de no exceder los lmites. Sin
embargo, todo programa debera ser expuesto, al
menos, a algunas pruebas de volumen.
Utilice los scripts diseados para las pruebas de
desempeo.
Deben usarse mltiples clientes, ya sea corriendo
las mismas pruebas o pruebas complementarias
para producir el peor caso de volumen (ver
pruebas de stress) por un perodo extendido.
Se utiliza un tamao mximo de Base de datos.
(actual, escalado o con datos representativos) y
mltiples clientes para correr consultas
simultneamente para perodos extendidos.
Todas las pruebas planeadas han sido ejecutadas y
los lmites especificados en el sistema se han
conseguido o excedido sin que el sistema falle.
Qu perodo de tiempo debera considerarse
como aceptable para condiciones de
volumen alto?
Verificar que los procesos de recuperacin (manual
o automtica) restauran apropiadamente la Base de
datos, aplicaciones y sistemas, y los llevan a un
estado conocido o deseado. Los siguientes tipos de
condiciones deben incluirse en la prueba:
Interrupcin de electricidad en el cliente.
Interrupcin de electricidad en el servidor
 Interrupcin en la comunicacin hacia el servidor
(cadas de red)

Interrupcin en la comunicacin con los

controladores de disco.

Ciclos incompletos (procesos de consultas

interrumpidos, procesos de sincronizacin de
datos interrumpidos)

Llaves o apuntadores de base de datos invlidos

Elementos corruptos o invlidos en la base de

datos.
Descripcin de la Prueba: Estas pruebas aseguran que una aplicacin o sistema
se recupere de una variedad de anomalas de
hardware, software o red con prdidas de datos o
fallas de integridad.

Las pruebas de tolerancia a fallas aseguran que, para

aquellos sistemas que deben mantenerse corriendo,
cuando una condicin de falla ocurre, los sistemas
alternos o de respaldo pueden tomar control del
sistema sin prdida de datos o transacciones.

Las pruebas de recuperacin son contrarias a las

pruebas en que la aplicacin o sistema es expuesto a
condiciones extremas (o condiciones simuladas),
tales como fallas en dispositivos en entrada/salida o
llaves o apuntadores invlidos de base de datos. Los
procesos de recuperacin se invocan y la aplicacin
es monitoreada y/o inspeccionada para verificar que
stos mecanismos se han ejecutado en forma
apropiada.

El objetivo de esta prueba es determinar la habilidad

del sistema para recuperarse de una falla de
hardware o software. Esta prueba evala las
caractersticas de contingencia construidas en el
sistema para procesar interrupciones y para volver a
puntos especficos en el ciclo de procesamiento del
sistema. La recuperacin debe ser considerada en el
 proceso de diseo. Errores de programacin o de
datos pueden ser incorporados ex profeso en un
sistema para determinar si se puede recuperar de
ellos. Las fallas de equipo (por ejemplo errores de
paridad en memoria, errores en dispositivos de
entrada/salida) pueden ser simuladas.
Tcnica: Se deben utilizar las pruebas creadas para la
Funcionalidad del sistema y Procesos de Negocios
para crear una serie de transacciones. Una vez se
alcanza el punto inicial de las pruebas de
recuperacin, se deben realizar o simular las
siguientes acciones:

Interrupcin de electricidad en el cliente.

Interrupcin de electricidad en el servidor: simular

o iniciar procedimientos de prdida de energa
para el servidor.

Interrupcin de la comunicacin en la red.

(desconectar fsicamente los cables o apagar los
hubs o routers)

Interrupcin de la comunicacin con los

controladores de disco: simular o eliminar
fsicamente la comunicacin con uno o mas
controladores o dispositivos.

Una vez se realizan estas acciones, se deben ejecutar

series de transacciones, y luego, una vez alcanzado
el segundo punto de pruebas, se deben invocar los
procedimientos de recuperacin.

Las pruebas para ciclos incompletos utilizan la

misma tcnica que se describe arriba, excepto que
los procesos de Base de datos deban ser abortados o
terminados prematuramente.

Criterio de Completitud:
Consideraciones Especiales:
Prueba de Compatibilidad y Conversin
Objetivo de la Prueba:
Descripcin de la Prueba: El propsito es demostrar que los objetivos de
Las pruebas para estas condiciones requieren que se
llegue a un estado conocido previamente en la Base
de datos. Algunos campos, apuntadores y llaves
deben ser modificados manualmente, valindose de
las herramientas que ofrezca la SSPD. Las
transacciones adicionales deben ser ejecutadas
utilizando las pruebas para Funcionalidad de la
aplicacin y para Procesos de Negocios.
En todos los casos mencionados, la Base de datos,
aplicacin y otros sistemas deben retornar a un
estado conocido y deseado, una vez se completan los
procedimientos de recuperacin. Este estado podra
incluir que el dao de datos se limite solamente a los
campos, llaves o apuntadores que se sabe que fueron
alterados, y reportes indicando los procesos o
transacciones que no fueron completadas debido a
las interrupciones producidas.
Las pruebas de recuperacin pueden llegar a ser
molestas. Los procedimientos para desconectar
cables o simular prdida de electricidad pueden
ser poco factibles o deseables. Podran llegar a
requerirse mtodos alternativos, como
herramientas de diagnstico.
Se requiere la participacin de personal de la red,
administradores de la base de datos y del sistema.
Estas pruebas deben ser ejecutadas en horas no
laborables o en mquinas aisladas.
Buscar problemas de compatibilidad y conversin en
los sistemas.
compatibilidad no han sido logrados y que los
procedimientos de conversin no funcionan.
 La mayora de los programas que se desarrollan no
son completamente nuevos; con frecuencia son
reemplazos de partes deficientes, ya sea de sistemas
de procesamiento de datos, o sistemas manuales.

Como tales, los programas tienen a menudo

objetivos especficos con respecto a su
compatibilidad y a sus procedimientos de conversin
con el sistema existente.
Tcnica: Desarrollar casos de prueba que permitan detectar
deficiencias con:

Compatibilidad entre programas

Conversin de datos
Criterio de Completitud: Todas las pruebas planeadas han sido
ejecutadas.
Todos los defectos que se identificaron han
sido tenidos en cuenta.

Consideraciones Especiales: Ninguna

Pruebas de Integridad de Datos y Base de Datos

Objetivo de la Prueba: Asegurar que los mtodos de acceso y procesos

funcionan adecuadamente y sin ocasionar
corrupcin de datos.
Descripcin de la Prueba: La Base de datos y los procesos de Base de datos
deben ser probados como sistemas separados del
proyecto . Estos sistemas deberan ser probados sin
usar interfaces de usuario (como las interfaces de
datos). Se necesita realizar investigacin adicional
en el DBMS para identificar las herramientas y
tcnicas que podran existir para soportar las pruebas
identificadas ms adelante.
Tcnica: Invoque cada mtodo de acceso y proceso de
la Base de datos, utilizando en cada uno datos
vlidos e invlidos.
Analice la Base de datos, para asegurar que
los datos han sido grabados apropiadamente,
que todos los eventos de Base de datos se
ejecutaron en forma correcta y revise los
datos retornados en diferentes consultas.
 Criterio de Completitud: Todos los mtodos de acceso y procesos de la Base
de datos funcionan como fueron diseados y sin
corrupcin de datos
Consideraciones Especiales: Las pruebas pueden requerir un ambiente de
DBMS o controladores para ingresar o
modificar datos directamente en la Base de
datos.
Se debe utilizar un conjunto pequeo de
datos para incrementar la visibilidad de
cualquier evento anormal o inesperado.
Los procesos pueden ser invocados
manualmente.

Pruebas de Seguridad y Control de Acceso