Array Development

Array Development

Plan de Pruebas de Aceptación

Versión 1.0

Historia de Revisión

Fecha Versión Descripción Autor

27/06/2007 1.0 Versión Final Array Development

Tabla de Contenidos

1. INTRODUCCIÓN 4

1.1 PROPÓSITO DEL PLAN 4

1.2 ALCANCE 4

1.3 DEFINICIONES Y ACRÓNIMOS 4

1.4 REFERENCIAS 4

1.5 VISIÓN GENERAL DEL PLAN 4

2. REQUERIMIENTOS DE PRUEBAS 5

2.1 INTRODUCCIÓN 5

2.2 FILOSOFÍA DE LA PRUEBA 5

2.2.1 Generalidades 5

2.2.2 Áreas funcionales 5

2.2.3 Categorías de resultados de prueba 5

2.3 ENTORNO DE LA PRUEBA 5

Generalidades 5

Hardware 6

Software 6

Datos de prueba 6

2.4 ROLES Y RESPONSABILIDADES DEL EQUIPO DE PRUEBAS 6

2.5 IDENTIFICACIÓN DE LA PRUEBA 7

Scripts de prueba 7

Reporte de resultados 7

Criterios de aceptación 7

Errores de prueba 8

Documentación de la prueba 8

2.6 PRUEBAS FUNCIONALES 8

3. ESTRATEGIA DE PRUEBAS 9

3.1 PRUEBAS POR CASO DE USO 9

3.1.1 Pruebas de integración 9

3.1.2 Pruebas del caso de uso 9

4. CASOS DE PRUEBA 9

4.1 CASO DE USO VALIDAD USUARIO. 9

4.2 CASO DE USO ACTUALIZAR PERSONAL. 10

4.3 CASO DE USO ACTUALIZAR SOCIO. 10

4.4 CASO DE USO ACTUALIZAR ACCESORIOS. 11

4.5 CASO DE USO ACTUALIZAR INSTALACIONES. 11

4.6 CASO DE USO ACTUALIZAR CURSO. 12

4.7 CASO DE USO ACTUALIZAR PAGOS. 12

4.8 CASOS DE USO ACTUALIZAR SOLICITUDES. 13

4.9 CASO DE USO BUSCAR INSTALACIÓN 13

4.10 CASO DE USO BUSCAR SOCIO. 13

4.11 CASO DE USO BUSCAR CURSO. 13

4.12 CASO DE USO CONSULTAR INFORMACIÓN DEL CLUB 14

4.13 CASO DE USO CONSULTAR MOVIMIENTOS DEL SOCIO 14

4.14 CASO DE USO INSCRIBIR CURSO. 14

4.15 CASO DE USO RESERVAR INSTALACIONES. 14

5. REQUERIMIENTOS DEL AMBIENTE DE PRUEBAS 15

5.1 HARDWARE 15

5.2 SISTEMA OPERATIVO 15

Plan de Pruebas

1. Introducción

1.1 Propósito del Plan

El propósito de este plan es planificar, estructurar y documentar la planificación de las pruebas de aceptación del sistema a realizar, así como la estrategia a utilizar para su ejecución.

1.2 Alcance

Luego de finalizar las pruebas de sistema, el programa se encuentra completamente ensamblado, y se han encontrado y corregido los errores entre los módulos, métodos, clases y objetos. En este punto se comienza con la etapa de las pruebas de validación de requerimientos más conocida como pruebas de aceptación. Éstas se enfocan en las acciones que realiza el usuario además de las salidas del sistema que puedan ser reconocidas por él; dichas acciones y salidas engloban las expectativas del usuario, y están definidas en las especificaciones de los requerimientos del software.

Las pruebas de aceptación, se realizan a los requerimientos funcionales, y a los no-funcionales como facilidad de uso, recuperación, eficiencia, entre otros; y se pretende lograr: corrección, vale decir, carencia de ambigüedad; completitud, es decir, especificación completa y clara del problema; y por último pero no menos importante, consistencia, quiere decir, que no haya requisitos contradictorios.

El plan que a continuación se detalla pretende dar una visión general sobre las actividades a realizar; sobre las pruebas consideradas; además de una explicación global que se consideró para la realización de los documentos a entregar, ya que darán una mayor información relacionada a la evaluación y reportes de este tipo de pruebas.

1.3 Definiciones y Acrónimos

No se utilizan en este plan.

1.4 Referencias

• Especificación de Requisitos de Software v1.0, 2007

1.5 Visión General del Plan

Este documento consta de las siguientes secciones: una introducción, los requerimientos de pruebas que son obtenidos del ERS y luego la estrategia de pruebas a seguir.

2. Requerimientos de Pruebas

2.1 Introducción

Este capítulo documenta los requerimientos de prueba durante la Fase de Pruebas del Sistema e Integración para el Sistema de Gestión de Club de Tenis.

2.2 Filosofía de la prueba

2.2.1 Generalidades

El objetivo principal de las pruebas unitarias del sistema será el de establecer un nivel de confianza que nos permitirá asegurar la aceptación del sistema por los usuarios (profesor, jefe de práctica) en las posteriores pruebas de aceptación.

Se probará que la aplicación cumpla con los requerimientos de alto nivel que fueron especificados previamente, verificando que se cumple satisfactoriamente con las funcionalidades y características necesarias para que los usuarios satisfagan estos.

2.2.2 Áreas funcionales

Esta sección describe las áreas funcionales generales que deberán ser probadas como parte de la fase de pruebas del sistema.

• Funcionalidad especificada en el ERS.

• Manejo de los datos y transacciones involucradas en las funcionalidades del punto anterior.

• Rendimiento al ejecutar las funcionalidades del primer punto.

2.2.3 Categorías de resultados de prueba

Esta sección describe las categorías que pueden ser asignadas los resultados de prueba en un Caso de Prueba.

1. Éxito: El resultado de la prueba es conforme al resultado esperado.

2. Aceptable: El resultado de la prueba indica que el sistema difiere de la especificación aceptada pero es aceptable, no son necesarios cambios en la aplicación, pero requiriendo un cambio en la Especificación Funcional.

3. Tolerable: El resultado de la prueba es incorrecto, la aplicación en prueba trabaja y podría ser aceptada, pero la falla deberá ser rectificada en el periodo de tiempo acordado.

4. Intolerable: El resultado de la prueba es incorrecto, y la falla debe ser corregida antes de concluir la fase de prueba.

5. Error: El resultado de la prueba observado es correcto, pero el resultado esperado de acuerdo a los scripts de prueba son incorrectos.

2.3 Entorno de la prueba

2.3.1 Generalidades

En esta sección se da una breve descripción del entorno de prueba:

• Las pruebas se realizarán principalmente en el laboratorio de Desarrollo de Programas 2 (V201).

• El número de computadoras con que se contará

...