Plan De Pruebas

SENA

SGPF

1.0

Historial de Revisiones

Fecha Descripción Responsable Versión

31/12/2011 Revisión de interfaz grafica Gary Joven (Diseñador) 1.0

31/01/2011 Entregable beta

Del sistema Gary Joven

(Desarrollador) 1.0 Beta

Tabla de Contenido

1. Introducción

1.1. Propósito

1.2. Alcance

1.3. A quien va dirigido

1.4. Documento, terminología y acrónimos

1.5. Identificación del Proyecto

2. Requerimientos de Pruebas

3. Estrategia de Pruebas

3.1. Tipos de Pruebas

3.1.1. Pruebas de Integridad de Datos y Base de Datos

3.1.2. Pruebas del Sistema

3.1.3. Pruebas de Procesos de Negocios

3.1.4. Pruebas de Interfaz de Usuario

3.1.5. Pruebas de Desempeño

3.1.6. Pruebas de Carga

3.1.7. Pruebas de Stress

3.1.8. Pruebas de Volumen

3.1.9. Pruebas de Seguridad y Control de Acceso

3.1.10. Pruebas de Recuperación y Tolerancia a fallas

3.1.11. Pruebas de Configuración

3.1.12. Pruebas de Instalación

3.2. Herramientas

4. Recursos

4.1. Trabajadores

4.2. Sistema

5. Hitos del Proyecto

6. Entregables

6.1. Modelo de Pruebas

6.2. Logs de Pruebas

6.3. Reporte de Defectos

7. Base del sistema de hardware

8. Elementos de Base de software en el entorno de prueba

9. De productividad y herramientas de soporte técnico

10. Configuraciones de entorno de prueba

11. Las responsabilidades, el personal y necesidades de capacitación

11.1 Las personas y roles

Plan Maestro de prueba

1. Introducción

Este documento contempla el plan de pruebas a realizar al sistema de gestión de pruebas físicas, un software creado en el CIMI de Girón , por los aprendices de adsi, el cual es una herramienta de gestión de información a respecto de pruebas físicas realizadas a estudiantes de la institución, el plan de pruebas a realizar se enfatiza fundamentalmente en la funcionalidad de dicho sistema con respecto a los requerimientos del usuario.

1.1 Propósito

Proporcionar un artefacto para la planificación y el control del esfuerzo de la prueba. Se define el enfoque general que se emplea para probar el software y evaluar los resultados de esa prueba.

Este plan de pruebas maestro también es compatible con los siguientes objetivos específicos:

OBJETIVOS

1. Garantizar una excelente funcionalidad de la aplicación conforme a los requerimientos planteados.

2. Verificar la sumisión de desarrolladores y diseñadores a estándares de calidad en la ingeniería de software.

3. Se requiere para realizar esta prueba un software específico, ya que es una aplicación web.

RECURSOS

Los recursos necesarios para este plan de pruebas a nivel de personal son:

1. Administrador de pruebas

2. Analista de pruebas

3. Probador

ENTREGABLES

Los elementos entregables del proyecto SGPF son:

1. Plan de pruebas

2. Casos de Pruebas

3. Script pruebas

4. Resultados de Prueba

5. Solicitud de cambio

1.2 Alcance

En Estas pruebas se tendrá presente lo siguiente:

- Probar todos y cada uno de los requerimientos funcionales del sistema conforme a los requisitos del cliente del cliente.

- Hallar el mayor número de errores en la aplicación, buscando minimizar al máximo riesgos futuros.

- Entregar informes oportunos de los errores hallados, dando sugerencias de solución a los mismos y especificando el tipo de excepciones, permitiendo de esta manera a los desarrolladores tener ayuda para la solución de los mismos.

- Enfocar las pruebas de calidad en base a estándares internacionales de calidad de software como son ISO 9001.

-

1.3 Este plan de pruebas es redactado para ser recibido y verificado , además para servir de punto de referencia a los siguientes actores del proyecto:

- Desarrolladores

- Director de proyecto

- Clientes

- Probadores

- Analista de pruebas

-

1.4 terminología y acrónimos

SGPF: Sistema de Gestión de Pruebas Físicas

CIMI: Centro Industrial de Mantenimiento Integral

1.5 Identificación del Proyecto

Versión y Fecha Documento Creado Recibido Autor Observación

V1.0 31/12/2011 Requerimientos Funcionales si si Gary Joven

Requerimientos no Funcionales ¬¬si ¬¬si Gary Joven

Especificación de Casos de Uso ¬¬si ¬¬si Gary Joven

Plan del Proyecto ¬¬si ¬¬si Gary Joven

Descripciones de Diseño ¬¬si ¬¬si Gary Joven

Manuales de Usuario ¬¬si ¬¬si Gary Joven

Modelo de Datos ¬¬si ¬¬si Gary Joven

Análisis de Riesgos del Proyecto ¬¬si ¬¬si Gary Joven

2. Requerimientos de pruebas

Para realizar las pruebas a SGPF necesitamos:

- Informe de requerimientos del sistema

- Personal para realizar las pruebas

- Casos de pruebas

- Versión del producto a probar

3. Estrategia de pruebas

La estrategia básicamente consiste en tomar los casos de uso y diagramas UML del sistema y realizar pruebas de funcionabilidad, conforme esta diagramación, también es muy importante contar con la opinión del cliente y hacerlo participe de las pruebas que se están llevando a cabo.

3.1 Tipos de Pruebas

Los tipos de pruebas a realizar son los siguientes:

- Pruebas de estrés

- Calidad de desarrollo

- Pruebas funcionales

- Pruebas no funcionales

- Pruebas de carga

- Pruebas de seguridad

3.1.1 Pruebas de Integridad de Datos y Base de Datos

Objetivo Acción Consideraciones Especiales

Verificar que la base de datos este correctamente creada conforme los requerimientos y el modelado de la misma • Verificar todos las tablas y campos

• Analizar los tipos de datos conforme la funcionalidad que va a tener el sistema.

• Verificar los procedimiento y triggers conforme la necesidad de manejo de información y eventos transaccionales • Las pruebas pueden requerir un ambiente de DBMS o controladores para ingresar o modificar datos directamente en la base de datos

• Los procesos deben ser invocados manualmente.

• Se debe utilizar un conjunto pequeño de datos para incrementar la visibilidad de cualquier evento anormal o inesperado.

3.1.2 Pruebas del Sistema

Se efectuaran 3 tipos de pruebas a SGPF las cuales son las siguientes:

1. revisión de interfaz gráfica:

- el diseño debe ser agradable, los colores deben ser aprobados por el usuario, si no están contemplados los colores en el informe de requerimientos debe hacerse una solicitud de cambio y añadir este punto.

2. funcionalidad de la aplicación

- la aplicación debe ser fácil de interpretar y manejar inclusive por un usuario inexperto en informática

- no deben haber botones que invoquen funciones que no hallan sido requeridas por el cliente en el informe de requerimientos

- serán probadas todas y cada una de las inserciones, consultas, modificaciones y transacciones con la base de datos, probando con valores nulos, tipos de datos diferentes a los habilitados en las tablas en búsqueda de excepciones.

- se medirá el tiempo de respuesta de todas y cada una de las funciones del sistema en búsqueda de, tiempos de respuesta sospechosamente demorados.

- se realizaran pruebas de caja negra al encontrar cualquier tipo de excepción que interrumpa la ejecución normal de eventos programados en el sistema, con el fin de localizar la línea de código correspondiente al error y l tipo de error.

- se efectuaran pruebas de carga y de estrés para ver como responde el sistema a una alta concurrencia de usuarios.

Objetivo de la prueba: Asegurar la apropiada navegación de la aplicación, ingreso de datos, procesamiento y recuperación.

Técnica: Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que:

• Los resultados esperados ocurren cuando se utiliza un dato válido.

• Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido.

• Cada regla de negocios es aplicada adecuadamente.

Criterio de Completitud: • Todas las pruebas planeadas han sido ejecutadas.

• Todos los defectos que se identificaron han sido tenidos en cuenta y agregados a la matrix de bugs.

Consideraciones Especiales

3.1.3 Pruebas de Procesos de Negocios

Las pruebas de procesos de negocios deben emular las actividades realizadas en el <Nombre del Proyecto> en el tiempo. Se debe identificar un período específico (un año, un mes, etc.) y las actividades

...