Upload
erika-castillo
View
17
Download
3
Embed Size (px)
Citation preview
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
Plan de test
Versión 1.0
Historial de RevisionesFecha Versión Descripción Autor
Página 1 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
Tabla de contenidos
1. Introducción 4
1.1 Propósito 41.2 Alcance 4
2. Técnicas y Tipos de Testing 4
2.1 Test de integridad de base de datos y datos 42.2 Test de funcionalidad 42.3 Test de Inferfaz de Usuario 52.4 Test de Performance 62.5 Test de Seguridad y de Control de Acceso 62.6 Test de Falla y Recuperación 7
3. Criterios de Entrada y Salida 8
3.1 Plan de Prueba 83.1.1 Criterio de Entrada para el Plan de Prueba 83.1.2 Criterio de Salida para el Plan de Prueba 8
4. Entregables 8
4.1 Resumen de los Resultados de las Pruebas 84.2 Clases JUnit. 94.3 Indicadores de Control 9
4.3.1 Evolución de la Prueba 94.3.2 Cobertura de los Casos de Prueba 9
5. Testing Workflow 9
6. Entorno Necesario 9
6.1 Software Base para el Entorno de Prueba 9
7. Roles 10
Página 2 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
Plan de test
1. Introducción
1.1 Propósito
El propósito del plan de test es recopilar la información necesaria para planificar y controlar el esfuerzo de test para el proyecto. Describe cómo se probará el software.
1.2 Alcance
Los niveles de testing serán por pruebas unitarias y por pruebas de integración.
Los tipos de test incluidos en el plan son de integridad de datos, funcionalidad, interfaz de usuario, performance, seguridad y control de acceso, falla y recuperación. No se incluye testing de configuración ni instalación, ni de ciclos de negocio.
2. Técnicas y Tipos de Testing
2.1 Test de integridad de base de datos y datos
La base de datos y los procesos de base de datos se prueban como un subsistema dentro del proyecto.
Objetivo: Asegurar que los métodos de acceso y los procesos funcionen correctamente y que no generen corrupción de información.
Técnica: Invocar cada método de acceso y procesos, alimentándolos con datos válidos e inválidos o consultando información.
Inspeccionar la base de datos para asegurar que los datos han sido cargados como se pretendía, todos los eventos ocurrieron correctamente, o que la información fue recabada correctamente
Herramientas: Scripts de carga de información
Herramientas para backup y restore de la base de datos
Utilidades para ejecutar scripts SQL
Herramientas de generación de información
Criterio de éxito: Todos los métodos de acceso a datos y los procesos funcionan como fueron diseñados y sin corrupción de información
Consideraciones especiales:
Puede requerirse un entorno de desarrollo que permita el acceso directo a la base de datos para poder modificar los datos directamente.
Los procesos deben invocarse manualmente
Debe utilizarse una cantidad minima o pequeña de datos para incrementar la visibilidad de cualquier evento no acceptable.
El ambiente de testing debe ser lo más parecido posible al de producción.
Página 3 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
2.2 Test de funcionalidad
El test de funcionalidad verifica la correcta aceptación de los datos, su procesamiento, acceso, búsqueda y la apropiada implementación de los requerimientos, utilizando datos válidos e inválidos para la aplicación que se está testeando. El testeo funcional se hará unicamente para los Casos de Uso identificados como de alta criticidad para el flujo de negocio y de alto riesgo para el éxito del desarrollo.
Objetivo: Asegurar la correcta funcionalidad de la aplicación, incluyendo la navegación, la entrada de datos, el procesamiento, la consulta de información, la actualización y la búsqueda.
Técnica: Ejecutar cada escenario de los casos de uso que incluyan una función critica y de alto riesgo en el flujo de negocio, utilizando datos válidos y no válidos, verificando lo siguiente:
Se obtienen los datos esperados cuando se ingresan datos válidos
Se muestran los mensajes de error adecuados cuando se ingresa datos no válidos.
Cada regla de negocio se aplica adecuadamente.
Herramientas: Casos de uso, Reglas de negocio, Requerimientos funcionales.
Criterio de éxito: Todos los test han corrido con éxito.
Todos los defectos detectados fueron resueltos o fueron suspendidos de acuerdo a lo especificado por el cliente.
Consideraciones especiales:
Se cuenta con los datos necesarios para testear
2.3 Test de Inferfaz de Usuario
El Test de Interfaz de Usuario (UI) verifica la interacción del usuario con el software. El objetivo de este test es asegurar que la UI provee el acceso y navegación apropiados a través de las funciones del objetivo del test. Además, el Test de UI asegura que los objetos gráficos funcionan como se esperaba y se ajusten a la conformidad del PMP o los estándares de la industria.
Objetivo: Verificar que:
La navegación a través de las aplicaciones reflejen las funciones pedidas por el usuario en la captura de los requerimientos, incluyendo la navegación de ventana a ventana, de campo a campo, y la utilización de métodos de acceso (teclas de tabulación, movimientos del mouse, hoy keys).
Los objetos de las ventanas y sus características puedan ser utilizados y funcionen con su correcto modo.
La ortografía y la gramática sea correcta (por lo menos en lo que respecta a la aplicación en castellano).
Técnica: Crear o modificar las pruebas de cada ventana para verificar la correcta navegación y el estado de los objetos gráficos para cada aplicación.
Herramientas: Especificaciones Suplementarias – GUI
Imagen Conceptual: Prototipo Ejecutable
Página 4 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
Criterios de éxito: Las pruebas con la interfaz han salido satifactorias y el usuario está satisfecho con las ventanas y la funcionalidad de los objetos de las mismas de ambas aplicaciones.
Consideraciones especiales:
No todas las propiedades de la GUI gráfica utilizada pueden ser accedidas con facilidad y por cuestión de tiempo se dedicará mucha mayor importancia a la interfaz de la aplicación Front, que la de la aplicación Back.
2.4 Test de Performance
El test de performance es una prueba de funcionamiento en que los tiempos de respuesta, las tasas de transacción, y otros requerimientos no funcionales de performance se miden y evalúan. El objetivo es verificar que los requisitos de rendimiento se han logrado; por ejemplo, que el procesamiento de resultado del exámen y cálculo de respuestas correctas no sea mayor a cinco segundos (requerimiento no funcional). El test de performance es implementado y ejecutado en función de las condiciones de trabajo como por ejemplo la configuración y velocidad del hardware.
Objetivo: El objetivo de las pruebas de performance es demostrar que las funciones del sistema estén alineadas con los requerimientos de performance pedidos por el cliente y cumpla con especificaciones estándares de tiempos de respuesta aceptables.
Técnica: Se controlará que el tiempo de respuesta a cualquier acción no sea mayor de 2 segundos, con un rango de tolerancia de hasta 3 segundos. O sea, que cualquier acción no demorará más de 2 a 5 segundos.
Herramientas: Especificación de los Casos de Uso
Script de carga de datos (para probar performance con una cantidad considerable)
Alguna herramienta de monitoreo de registro, disco rígido, CPU, memoria
Criterio de éxito: Ninguna acción superará los cinco segundos de respuesta, siendo preferible, en caso de contar con el tiempo suficiente, optimizar aquellas que demoren más de dos segundos.
Consideraciones especiales:
Por cuestiones de tiempo, no se harán pruebas masivas como de stress y de volumen, así que la idea es que este test se pruebe con una cantidad considerable, media, de datos cargados.
El test de performance no servirá para conocer cuál es el límite de registros que puede soportar la base de datos y manejar bien la aplicación.
2.5 Test de Seguridad y de Control de Acceso
Este test se enfoca en dos areas claves de la seguridad:
Seguridad a nivel de aplicación, como por ejemplo: el acceso a los datos o a las funciones del negocio
Seguridad a nivel de sistema, como por ejemplo: el acceso restringido a los usuarios por medio de la ventana de logging o no permitir que el aspirante, en caso de haber desaprobado el examen, pueda rendir nuevamente sino hasta transcurridos 3 meses desde aquella fecha de evaluación (ver Solicitud de Cambio de Requerimientos – 002.doc)
Página 5 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
Objetivo: A nivel de Aplicación: verificar que el usuario sólo puede acceder a las funciones del Front para rendir el examen, que no tenga la posibilidad de acceder a las respuestas del examen que está rindiendo o va a rendir, de que no pueda acceder a los datos de usuario y que no tenga los permisos del administrador.
A nivel de Sistema: Verificar que si el usuario o el administrador ingresaron mal el usuario y/o la clave, no puedan ingresar al sistema. Verificar que el aspirante que desaprobó un examen no pueda rendir sino hasta transcurridos los 3 meses desde la fecha de evaluación.
Técnica: A nivel de Aplicación: Identificar y listar cada tipo de usuario y el tipo de funciones y datos a los que tiene permiso consultar, modificar o borrar.
Se crearán casos de prueba para cada tipo de usuario y se probará que el usuario no puede acceder a ninguna funcionalidad o dato a los que no tenga permiso.
A nivel de Sistema: Se probará ingresar con claves erróneas, con usuarios erróneos. Se probará ingresar con caracteres raros y con demás set de pruebas erróneos e intencionalmente dañinos. También se reprobará un exámen y se controlará que no se pueda rendir de nuevo si la diferencia de fechas es mayor a tres meses.
Herramientas: Especificación de los Casos de uso, donde se especifica qué puede y qué no puede hacer cada uno de los actores.
Criterio de éxito: La funcionalidad y permisos de cada usuario está correctamente implementada. Las pruebas fueron exitosas. Las pruebas de logging fueron todas aceptadas.
Special Considerations: -
2.6 Test de Falla y Recuperación
El test de Falla y Recuperación asegura que los datos puedan recuperarse exitosamente tras alguna fallas de hardware o de software. Que los datos sean recuperados exitosamente significa que se pueden volver a consultar y modificar sin pérdida de datos ni inconsistencias.
Objetivo: Simular fallas y efectuar procesos de recuperación para restaurar la base de datos, las aplicaciones y el sistema a un estado conocido y deseable. Se incluirán las siguientes pruebas:
Interrupción de energía en la aplicación Front, mientras se están llenando los datos o mientras se está rindiendo el examen
Interrupción de energía en la aplicación Back, mientras se están cargando las preguntas o se está publicando un examen
Interrupción, incomunicación o apagado del servicio del SGBD, la base de datos
Interrupción de procesos: cierre de la aplicación Front durante la rendición de un examen, corte de la aplicación Back mientras se están cargando datos
Página 6 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
Technique: Para cada uno de los casos de prueba explicados en el Objetivo:
Interrupción de energía en la aplicación Front y Back: se apagará la PC en la que la aplicación se está ejecutando
Interrupción del servicio del SGBD: se simulará o se eliminará físicamente la comunicación con el controlador de la base de datos
Interrupción de procesos: se probará de cerrar la aplicación Front durante un examen, matando el proceso o con la cruz de cierre de la ventana de la GUI
Herramientas: Backups
Herramientas de monitoreo de registro, disco, CPU, memoria
Herramientas de configuración y/o de recuperación de datos
Criterios de éxito: Se considerarán aprobadas las pruebas de Falla y Recuperación cuando se efectúen los casos de prueba y se demuestre que no hubo corrupción de datos, ni pérdida. Con esto se asegurará que, tras una transacción interrupida, siempre se puede regresar al previo estado consistente.
Consideraciones especiales:
Las pruebas de fallas y recuperación son altamente intrusivas. Los procedimientos que implican desconectar el cable de energía o apagar la PC pueden ser no deseables, sobre todo en los sistemas operativos modernos de hoy en día. En cuyo caso, se pueden utilizar métodos alternativos, como el uso de una herramienta de diagnóstico de software o similar.
Para llevar a cabo estas pruebas son necesarios permisos de administrador sobre las PC y la base de datos que se vayan a llevar a cabo.
3. Criterios de Entrada y Salida
3.1 Plan de Prueba
3.1.1 Criterio de Entrada para el Plan de Prueba
El Plan de Prueba comenzará a ejecutarse a partir del desarrollo de la cuarta iteración, donde se comienza con la fase de Construcción. Cada caso de uso, o funcionalidad, estará asociada a un ticket. A medida que los Implementers vayan finalizando los casos de uso y las funcionalidades especificadas en la Especificación de Requerimientos de Software (SRS), estos tickets, pasaran al estado Ready To Test. Es allí donde los testers comenzarán con las pruebas.
Conclusión: el plan de prueba comienza a ejecutarse cuando el primer ticket pase al estado “Ready To Test”.
3.1.2 Criterio de Salida para el Plan de Prueba
El Plan de Prueba finalizará cuando todos los tickets estén cerrados como inválidos o fixed. Los defectos críticos (tickets de prioridad High (2) o Highest (1)) que vayan encontrándose a lo largo de la ejecución de este plan deberán arreglarse. Los defectos más leves, de prioridad Lowest o Low, pueden negociarse con el usuario y corregirse en la siguiente versión.
Página 7 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
4. Entregables
4.1 Resumen de los Resultados de las Pruebas
Artefacto de RUP.
4.2 Clases JUnit.
Como se explica en la sección 1.2, Alcance, hay dos niveles de testing: de integración y unitarios. Los tests de integración estarán explicados en los casos de prueba y el resultado de los mismos será arrojado en el Resumen de los Resultado de las Pruebas. Los test unitarios, en su mayoría, se realizarán con JUnit.
4.3 Indicadores de Control
4.3.1 Evolución de la Prueba
Los defectos (bugs) encontrados en las pruebas serán reportados como tickets, que tienen un estado. (Ver documento: Milestones en Assembla.) Los estados de estos tickets: New, Accepted, Invalid, Ready To Test y Fixed serán usados para armar este indicador, que será adjuntado en el Informe de Avance de cada entrega formal a partir de la cuarta iteración.
4.3.2 Cobertura de los Casos de Prueba
Este indicador muestra una estadística sobre los casos de prueba. La cobertura nos mostrará cuántos casos de prueba hay planificados, cuántos hay disponibles, cuántos ejecutados y cuántos ejecutados OK:
Planificados: Cantidad de Casos a Ejecutar.
Disponibles: Los entregados por los Implementers al Tester Manager.
Ejecutados: Lo que el equipo de prueba probó.
Ejecutados OK: Lo que funciona bien. Los casos de prueba que dieron positivos.
El indicador de la Cobertura de los Casos de Prueba será adjuntado, junto con el de Evolución de la Prueba, en el Informe de Avance de cada entrega formal a partir de la cuarta iteración del proyecto.
5. Testing Workflow Se harán pruebas unitarias para cada caso de uso o funcionalidad y se ejecutarán los casos de prueba a
medida que los Implementers vayan liberando builds para testear.
Los casos de prueba se diseñarán de forma incremental. Se presentarán los más importantes en la entrega formal de la tercera iteración y en las siguientes iteraciones se irán perfeccionando y planeando los necesarios para cada iteración.
Los resultados de las pruebas se irán anotando en el Resumen de los Resultados de las Pruebas. Los que vayan dando Ejecutados OK, se cerrarán como fixed; los que no, se reabrirán como Accepted o New.
Al final de cada iteración, a medida que se vaya estabilizando la entrega incremental, se comenzará con las pruebas de integración.
Página 8 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
6. Entorno Necesario
6.1 Software Base para el Entorno de Prueba
La siguiente tabla indica el software base que se requiere para ejecutar el Plan de Prueba.
Software Version Tipo de SW o Notas Adicionales
7. Roles
Rol Responsabilidad Específica o Comentarios
Test Manager Brinda la supervisación de la gestión.
Sus responsabilidades incluyen:
Planeamiento y logística
Lograr acuerdo en caso de conflicto
Identificar los motivadores
Adquirir recursos apropiados
Presentar reportes de administración
Defender los intereses de las pruebas
Evaluar la eficacia del esfuerzo aplicado a las pruebas
Test Analyst Identifica y define los tests específicos a ser realizados.
Sus responsabilidades incluyen:
Identificar ideas de Testing
Definir los detalles de las pruebas
Determinar los resultados de las pruebas
Documentar los pedidos de cambio
Evaluar la calidad del producto
Página 9 de 10
Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:
Rol Responsabilidad Específica o Comentarios
Test Designer Define el enfoque técnico de la implementación del esfuerzo de testing.
Sus responsabilidades incluyen:
Definir el enfoque de Test
Definir la arquitectura de la automatización de Test
Verificar las técnicas de Testing
Definir los elementos a ser testeados
Implementar la estructura de Testing
Tester Implementa y ejecuta las pruebas.
Sus responsabilidades incluyen:
Aplicar las pruebas
Ejecutar los casos de pruebas
Registrar los resultados
Analizar y recuperar pruebas fallidas
Documentar incidentes
Designer Identifica y define las operaciones, atributos, y asociaciones de las clases de prueba.
Sus responsabilidades incluyen:
Definir las clases de prueba requeridas para soportar los requerimientos de testing como los definió el equipo de QC
Implementer Implementar los casos de uso y escribir casos de prueba unitarios y paquetes de prueba.
Sus responsabilidades incluyen:
Crear pruebas unitarias y ejecutarlas para filtrar los defectos más notorios
Página 10 de 10