PLAN DE PRUEBAS

HISTORIAL DE VERSIONES
Hecha Revisada Aprobada
Versión Fecha Motivo
por por por
1.0 BJM BJM AB 30-11-2012 Versión Original

CONTROL DE VERSIONES
Hecha Revisada Aprobada
Versión Fecha Motivo
por por por
1.0 BJM BJM AB 30-11-2012 Versión Original

Confidencial Página 1
1. Propósito:

Este documento describe el plan para probar las funcionalidades y

características del sistema SREC. Este documento está basado sobre los
siguientes objetivos:

 Identificar que la información existente del proyecto y los componentes de

software sean probados.

 Listar los requerimientos recomendados de prueba (de alto nivel).

 Recomendar y describir las estrategias a ser empleadas.

 Identificar los recursos requeridos y estimar los esfuerzos de las pruebas.

 Listar los elementos a entregar de las actividades de pruebas.

2. Alcances

Este plan de pruebas aplica para la integración y las pruebas de sistema que
serán conducidos en el lanzamiento de la versión 1.0 del sistema SREC.

Se asume que pruebas unitarias previas han debido proveer de pruebas de caja
negra totales a través de una extensiva cobertura del código fuente y pruebas de
todas las interfaces de los módulos.

Este plan de pruebas aplica para todos los requerimientos definidos en el

documento de Visión.

3. Requerimientos de pruebas

Confidencial Página 2
 La lista que prosigue este párrafo identifica aquellos elementos (requerimientos
funcionales, no funcionales) que han sido identificados como objetivos de las
pruebas. Esta lista representa el qué será probado. Los detalles de cada prueba
serán determinados posteriormente mientras los casos de prueba sean
identificados y los scripts sean desarrollados.

3.1 Pruebas de integridad de datos y BD

 Verificar el acceso a la BD de SREC.

 Verificar el acceso simultáneo en la lectura de registro de las distintas tablas.
 Verificar el bloqueo realizado durante actualizaciones de registros de las tablas
transaccionales (Atención, Persona, Usuario, Exámenes, entre otras).
 Verificar la correcta obtención de data actualizada.

3.2 Pruebas del sistema

 Verificar el CU Ingreso a Sistema

 Verificar el CU Consultar Atención
 Verificar el CU Registrar Atención
 Verificar el CU Registrar Examen Preventivo
 Verificar el CU Registrar Resultado de Examen Preventivo
 Verificar el CU Visualizar Informes

3.3 Pruebas de la interfaz de usuario

 Verificar que las interfaces cumplan estándares de GUI.

Confidencial Página 3
3.4 Pruebas de desempeño

 Verificar el tiempo de respuesta para acceder remotamente a la aplicación (fuera

de la red del HMA)
 Verificar el tiempo de respuesta para registrar un grupo de atenciones.
 Verificar el tiempo de respuesta para registrar un grupo de exámenes a realizar.
 Verificar el tiempo de respuesta para registrar un grupo de exámenes de
prevención a realizar.

3.5 Pruebas de carga

 Verificar la respuesta del sistema cuando tiene más de 5 usuarios accediendo a

la tabla de atención.

3.6 Pruebas de stress

 Verificar la respuesta del sistema cuando tiene 20 sesiones de usuario activas.

3.7 Pruebas de volumen

 Verificar el tiempo de respuesta cuando la tabla Atención está en el 90% de su

capacidad.

4. Estrategia de pruebas

Confidencial Página 4
 La estrategia de pruebas presenta el alcance recomendado para la prueba de
aplicaciones de software. La sección previa a los requerimientos de pruebas
describen qué será probado; ésta describirá cómo será probado.

4.1. Tipo de Prueba

Las consideraciones principales para la estrategia de pruebas son las técnicas a

usarse y los criterios para determinar si la prueba fue completada.

Además de las consideraciones provistas para cada prueba mencionada, las

pruebas deberían ser únicamente ejecutadas usando bases de datos conocidas
y controladas en entornos seguros.

La siguiente estrategia de pruebas es genérica en su naturaleza y está dirigida a

aplicarse sobre los requerimientos listados en la sección 3 de este documento.

4.1.1 Pruebas de integridad de datos y BD

La base de datos y los procesos de bases de datos deberían ser probadas en

sistemas separados. Estos sistemas deberían ser probados sin la aplicación
SREC (como interface a la data). Revisión exhaustiva sobre el gestor de base de
datos a usarse necesita ser realizada para identificar las herramientas y técnicas
que puedan existir para soportar las pruebas a realizarse.

4.1.1.1 Objetivo
Asegurar que los métodos de acceso y los procesos funcionen apropiadamente
y sin corrupción de datos

Confidencial Página 5
4.1.1.2 Técnicas
Invocar cada método de acceso a la BD, intentando con datos válidos e
inválidos.

Inspeccionar la base de datos para asegurar que la data ha sido poblada como
se esperaba, que todos los eventos ocurran apropiadamente, o revisar la data
retornada para asegurar que la data correcta fue obtenida (por las razones
correctas).

4.1.1.3 Criterio de cumplimiento

Todos los métodos de acceso a la base de datos y procesos funcionan como
fueron diseñados y sin corrupción de datos.

4.1.2 Pruebas del sistema

Las pruebas sobre la aplicación deberían enfocarse en requerimientos que

puedan ser asociados directamente a casos de uso (o funciones de negocio), y
reglas del negocio. Las metas de estas pruebas son verificar la aceptación, el
procesamiento y obtención de data apropiada, así como la apropiada
implementación de reglas del negocio. Este tipo de pruebas está basado en las
técnicas de caja negra, utilizando para ello la GUI y analizando los resultados.

Confidencial Página 6
4.1.2.1 Objetivo

Asegurar la navegación apropiada en la aplicación; el correcto ingreso de datos,

procesamiento y obtención.

4.1.2.2 Técnicas

Ejecutar cada CU, cada flujo de CU o función, usando data válida e inválida,
para verificar: a) que los resultados ocurran cuando la data sea válida.; b) que se
muestren apropiados mensajes de error o alerta cuando data inválida sea
empleada.

Cada regla de negocio es apropiadamente aplicada.

4.1.2.3 Criterio de cumplimiento

Todas las pruebas planificadas fueron ejecutadas.

Todos los defectos de pruebas han sido manejados.

4.1.3 Pruebas de la interfaz de usuario (IU)

Verifica la interacción del usuario con el software. La meta de las pruebas de IU

es asegurar que la interfaz de usuario provea al usuario el acceso apropiado
para acceder y navegar por las funciones de la aplicación. Además, las pruebas
IU asegura que los objetivos dentro de la IU funcionen como se esperaba y
conforme a los estándares de la compañía.

4.1.3.1 Objetivo
Verificar: a) la navegación por la aplicación refleje propiamente las funciones y
requerimientos de negocio; b) los objetos de ventanas y sus características,
como menús medidas posición, estado y foco sea conforme a los estándares.

Confidencial Página 7
4.1.3.2 Técnicas
Crear modificar las pruebas para cada ventana para verificar apropiadamente la
navegación y los estados de los objetos para cada ventana y objeto de la
aplicación.

4.1.3.3 Criterio de cumplimiento

Cada ventana fue verificada exitosamente para comparar si se sigue el estándar
o no.

4.1.4 Pruebas de desempeño

Realizar las pruebas que miden los tiempos de respuesta, las tasas de
transacción y otros requerimientos sensibles al tiempo. La meta de las pruebas
de desempeño es verificar y validar que los requerimientos de desempeño han
sido alcanzados. Este tipo de pruebas es ejecutado muchas veces, y cada
ejecución emplea una carga subrepticia (background load) en el sistema.

4.1.4.1 Objetivo
Validar el tiempo de respuesta para transacciones diseñadas o funciones de
negocio bajo las siguientes condiciones: a) volumen normal anticipado, b)
volumen de caso mal anticipado.

4.1.4.2 Técnicas
Usar scripts de prueba desarrollados por pruebas de modelo de negocio
(pruebas de sistema).

Modificar archivos de datos (para incrementar el número de transacciones) o

modificar los scripts para incrementar el número de iteraciones en que cada
transacción ocurre.

Confidencial Página 8
 Lo scripts deben correr en una sola máquina (en el mejor de los casos simular
un usuario único, una única transacción) y ser repetido en múltiples clientes
(virtuales o actuales).

4.1.4.3 Criterio de cumplimiento

Una transacción / un único usuario. El cumplimiento exitoso de estas pruebas, es
cuando no se encuentran fallas en los tiempos esperados o requerido (en cada
transacción).

Múltiples transacciones / múltiples usuarios. El cumplimiento exitoso de estas

pruebas, es cuando no se encuentran fallas en los tiempos aceptables.

4.1.5 Pruebas de carga

Las pruebas de carga miden las situaciones en las que el sistema se somete a
variaciones en su carga de trabajo para evaluar la habilidad del sistema para
continuar funcionando adecuadamente, más allá de la carga de trabajo
esperada. Adicionalmente, las pruebas evalúan las características de
desempeño (tiempos de respuestas, tasas de transacción y otros problemas
sensibles a tiempos).

4.1.5.1 Objetivo
Verificar el tiempo de respuesta del sistema para transacciones diseñada o
casos de negocio bajo condiciones de carga de trabajo variada.

4.1.5.2 Técnicas
Pruebas de uso desarrolladas para ciclos de prueba de negocio.

Modificar archivos de datos (incrementando el número de transacciones) o las

pruebas para incrementar el número de veces en que una transacción ocurre.

4.1.5.3 Criterio de cumplimiento

Múltiples transacciones / múltiples usuarios. El cumplimiento exitoso de estas
pruebas, es cuando no se encuentran fallas en los tiempos aceptables.
Confidencial Página 9
4.1.6 Pruebas de stress

Las pruebas de stress intentan encontrar errores debido a bajos recursos o

competencia por recursos. La baja memoria o espacio del disco pueden revelar
defectos en el software que no aparecen bajo condiciones normales.

4.1.6.1 Objetivo

 Verificar que el sistema y el software funcionen apropiadamente y sin errores

bajo las siguientes condiciones de stress:
 Poca o sin memoria disponible en el servidor.
 Máximo (actual o físicamente capaz) número de clientes conectados o
simulados.
 Múltiples usuarios realizando las mismas transacciones contra los mismos datos
o cuentas.

4.1.6.2 Técnicas
Pruebas de uso desarrolladas para las pruebas de desempeño.

4.1.6.3 Criterio de cumplimiento

Probar recursos limitados, las pruebas debería correr sobre una sola maquina, y
la memoria RAM en el servidor debería ser la mínima (o limitada).

El espacio en el disco duro usado por el sistema debería ser temporalmente

reducido para restringir el espacio disponible para que la base d datos crezca.

4.1.7 Pruebas de volumen

Determina si el sistema puede trabajar con grandes cantidades de datos,

indicando cuando los límites son alcanzados lo que causaría que el software
Confidencial Página 10
 falle. Las pruebas de volumen además identifican las cargas continuas de carga
o el volumen que el sistema puede manejar por un tiempo dado.

4.1.7.1 Objetivo
Verificar que la aplicación funcione exitosamente bajo los siguientes escenarios
de gran volumen:

Máximo número de clientes conectados, todos realizando la misma funcionalidad

de negocio con el peor caso (de desempeño) por un periodo largo de tiempo.

Tamaño máximo de la BD ha sido alcanzado y múltiples transacciones de

consultas y reportes son ejecutados simultáneamente.

4.1.7.2 Técnicas
Las pruebas de uso desarrolladas para las pruebas de desempeño.

Múltiples clientes deberían ser usados, bien corriendo las mismas pruebas o
pruebas complementarias para producir la transacción del peor caso de volumen
por un periodo extendido.

Máximo tamaño de la base de datos es creado y múltiples clientes lo usan para

ejecutar consultas y reportes simultáneamente por un periodo extendido.

4.1.7.3 Criterio de cumplimiento

Todas las pruebas han sido ejecutadas y los límites del sistema son
alcanzados/excedidos sin que el software falle.

4.2 Herramientas
Las siguientes herramientas serán empleadas para las pruebas:

Prueba Herramienta

De integridad de datos y BD JMeter

Del sistema Aplicación propia en Visual 2005 con

Confidencial Página 11
 Framework 2.5

De la interfaz de usuario Aplicación propia en Visual 2005 con

Framework 2.5

De desempeño JMeter

De carga JMeter

De stress JMeter

De volumen JMeter

5. Recursos

5.1 Trabajadores
La siguiente tabla muestra las personas asignadas para el equipo de pruebas:

Rol Responsables

Test Manager Brenda Miranda

Diseñador de pruebas Annia Laura, Brenda Miranda

Tester Annia Laura, Brenda Miranda

Desarrollador de pruebas Annia Laura

Administrador del sistema de pruebas Brenda Miranda

Administrador BD Annia Laura

BD Brenda Miranda

5.2 Sistema
Se requieren la siguiente configuración del sistema:

 Dos computadoras virtuales (con el software PC Vrtual 2007 de Microsoft), una

simulando servidores y la restante una máquina cliente. Las dos con Windows
XP SP3.
Los servidores tendrán lo siguiente:
Confidencial Página 12
  Memoria RAM 1 GB
 Disco duro de .., GB con espacio disponible de …MB
 Acceso externo restringido por el firewall del SO, excepto en los puertos 3306,
80 y 8080

ANNIA LO QUE ESTA EN AMARILLO NO SE SI LO PUEDAS MODIFICAR!!

Confidencial Página 13