Las pruebas de

carga miden la La meta de las pruebas de carga es determinar y asegurar que el sistema funciona
Pruebas de capacidad del
apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las
Carga sistema para
continuar pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de
funcionando transacciones y otros aspectos sensibles al tiempo).
apropiadamente
bajo diferentes
condiciones de
carga.
Las pruebas de stress se proponen encontrar
errores debidos a recursos bajos o
completitud de recursos. Poca memoria o
Pruebas de espacio en disco puede revelar defectos en el El objetivo de esta prueba es investigar el comportamiento del sistema
Stress sistema que no son aparentes bajo bajo condiciones que sobrecargan sus recursos. No debe confundirse
condiciones normales. Otros defectos pueden con las pruebas de volumen: un esfuerzo grande es un pico de
resultar de incluir recursos compartidos, como volumen de datos que se presenta en un corto período de tiempo.
bloqueos de base de datos o ancho de banda
de la red. Las pruebas de stress identifican la
carga máxima que el sistema puede manejar.
Un compilador puede Un editor de nexos Un simulador de
ser alimentado por un puede recibir un circuito electrónico
Pruebas de programa para programa que puede recibir un
Volumen compilar que sea contenga miles de circuito diseñado con
absurdamente módulos. miles de
grande. componentes.
Estas pruebas Las pruebas de recuperación son contrarias a
aseguran que una las pruebas en que la aplicación o sistema es
aplicación o sistema Las pruebas de tolerancia a fallas aseguran expuesto a condiciones extremas (o
Pruebas de se recupere de una que, para aquellos sistemas que deben condiciones simuladas), tales como fallas en
Recuperación y variedad de mantenerse corriendo, cuando una condición dispositivos en entrada/salida o llaves o
anomalías de de falla ocurre, los sistemas alternos o de apuntadores inválidos de base de datos. Los
Tolerancia a hardware, software o respaldo pueden tomar control del sistema sin procesos de recuperación se invocan y la
fallas red con pérdidas de pérdida de datos o transacciones. aplicación es monitoreada y/o inspeccionada
datos o fallas de para verificar que éstos mecanismos se han
integridad. ejecutado en forma apropiada.
 Prueba de El propósito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en múltiples instalaciones.
Múltiples Sitios

La Base de datos y los procesos de Base

de datos deben ser probados como Invoque cada Analice la Base de datos, para asegurar
Pruebas de sistemas separados del proyecto. Estos método de acceso y que los datos han sido grabados
Integridad de sistemas deberían ser probados sin usar proceso de la Base apropiadamente, que todos los eventos de
Datos y Base interfaces de usuario (como las interfaces de datos, utilizando Base de datos se ejecutaron en forma
de datos). Se necesita realizar en cada uno datos correcta y revise los datos retornados en
de Datos investigación adicional en el DBMS para válidos e inválidos. diferentes consultas.
identificar las herramientas y técnicas que
podrían existir para soportar las pruebas
identificadas más adelante.
Controles manuales,
incluyendo aquellos
Pruebas de Acceso a estructuras Seguridad en sitios Existencia de datos para autorización y
Controles de acceso
Seguridad y físico
de datos específicas remotos confidenciales en aprobación,
Control de a través de los reportes y pantallas formularios,
programas de documentación
Acceso aplicación. numerada,
transmisión de datos,
balances y
conversión de datos.
Incremente el número Todas las fechas o
de veces en que una funciones que Todas las funciones
Pruebas del función es ejecutada involucren tiempos ocurren en un
Los resultados esperados ocurren cuando los
Ciclo del para simular serán probadas con periodo de tiempo
diferentes usuarios datos válidos e serán ejecutadas en datos válidos son usados.
Negocio
sobre un periodo inválidos de fechas o el tiempo apropiado.
especificado periodos de tiempo.
 Para esto los casos
de prueba deben Los aspectos a
diseñarse de forma considerar son los
tal que se recorran siguientes: Rutinas
todos los caminos de de excepción,
Particionar los Por cada unidad hay ejecución posibles Rutinas de error,
módulos en pruebas que definir los casos dentro del código Manejo de
Prueba Unitaria en unidades lógicas de prueba (pruebas bajo prueba; por lo parámetros,
fáciles de probar. de caja blanca). tanto, el diseñador Validaciones, Valores
debe construirlos válidos, Valores
con acceso al código límites, Rangos,
fuente de la unidad a Mensajes posibles.
probar.

Describe cómo Determina cómo la Determina el enfoque Decide qué acciones

verificar que las base de datos de para avanzar desde un tomar cuando se
Prueba de interfaces entre las prueba será cargada. nivel de integración de descubren problemas.
Integración componentes de las componentes al
software funcionan siguiente.
correctamente.
La prueba de regresión
Se requiere de es un buen candidato La prueba de viejas
políticas para ser para automatización. funcionalidades es
La prueba de regresión
Prueba de es una nueva corrida creada la prueba de Desde que estas más importante que la
Regresión regresión y decidir qué pruebas se repiten una de nuevas
de casos de prueba
casos de prueba y otra vez, las funcionalidades.
previos.
incluir, para probar herramientas para
eficientemente. minimizar el esfuerzo
del trabajo son útiles.

Pruebas de
Humo (Smoke Detectar los errores en Probar el sistema Garantizar poco Asegurar los
realeases tempranos y constantemente esfuerzo en la resultados de las
Testing o Ad de manera fácil integración final del pruebas unitarias
Hoc) sistema
   

Prueba funcionalidad Prueba de Seguridad y Prueba de Esfuerzo Prueba de

Controles (Stress) Prueba de múltiples Documentación y
Pruebas del sitios Procedimientos
Prueba de Usabilidad
Sistema Prueba de Volumen Prueba de
Prueba de recuperación
Performance

Errores lógicos Cuellos de botella en

discos, CPU ó canales
Pruebas de de entrada/salida
Procesamiento Capacidad de Número de
Desempeño ineficiente almacenamiento transacciones que
Salidas del sistema pueden ser manejadas
simultáneamente.
Diseño pobre: muchas Tasa de entrada/salida
interfases, Tiempos de respuesta de datos
instrucciones y
entradas/salidas.