APLICACIÓN AL SOFTWARE JUEGO DE SCELULAS

DOCUMENTOS RELACIONADOS CON EL DISEÑO

DE LAS PRUEBAS SEGUN EL ESTANDAR IEEE std. 829

APLICACIÓN AL SOFTWARE

JUEGO DE SCELULAS

ESTÁNDAR IEEE 829

PLAN DE PRUEBAS

1.Identificador único del documento(para la gestión de configuración).

DOC-003

2.Introducción y resumen de elementos y características a probar.

El documento a continuacion describe el alcance, la aproximación, los recursos y la planificación y las actividades necesarias. Identifica elementos de prueba, las características que deben probarse, las tareas de prueba, lo que hará cada tarea.

Los elementos a ser probados son:

 Software

 Documentación

3.Elementos

3.1 software que se van a probar( por ejemplo, programas o módulos).

MODULO ENTRADA

sub. Modulo -Definición de Variables:

Define las variables de la matriz las cuales son fila, col, FILAS, COLS, etc.

sub. Modulo -Inicializa matriz y pone las células iniciales:

Se introducen los datos por defecto aleatoria mente

MODULO PROCESO

sub. Modulo -Imprime en pantalla la matriz de la población Elige un vecino aleatoria mente:

Se inicializa en la pantalla las celulas blancas y negras aleatoriamente y luego toma su vecino aleatorio y toma el valor para poder realizar el cambio de color.

sub. Modulo -Explora la matriz y averigua que habitante hay:

Registra la cantidad de habitantes e imprime en la pantalla (en un extremo) con el numero exacto de celulas blancas y negras.

MODULO SALIDA

sub. Modulo -Visualización en la matris

3.2 Documentos a probar

• Doc Diseño

• Doc Analisis

4.Características que se van a probar.

1. fluidez de datos

2. independencia de módulos

3. soporte del software

4. interfaz de usuario

5.Características que no se prueba.

• Errores relacionados con el tiempo.

• Condiciones de error no detectadas.

• Condiciones especiales de los datos.

• Invalidez de la información mostrada por pantalla.

• Interacción con tareas en background.

• Fallos de configuración/compatibilidad con software

• Incapacidad de soportar el volumen de carga o fallos hard.

6.Enfoque general de la prueba(actividades, técnicas, herramientas, etc).

PRUEBA DEL DISEÑO

• Las pruebas del diseño van encaminadas a asegurar que la arquitectura propuesta es coherente, consistente y completa.

PRUEBAS DE UNIDAD

• Pretenden probar que los fragmentos individuales (unidades) que forman el sistema cumplen las especificaciones y tienen el comportamiento esperado.

PRUEBA DE REQUISITOS

• Se validan los métodos y procesos para recolectar requisitos.

• Comprobación de la compleción y consistencia

• Eliminación de requisitos duplicados

PRUEBAS DE INTEGRACIÓN

• Se prueban las funcionalidades, rendimiento, fiabilidad, etc. del sistema, sus relaciones con el exterior, etc.

PRUEBAS DE REQUISITOS

• Diferentes técnicas de captura y análisis de requisitos (prototipos, casos de uso, etc.)

• El resultado es una descripción de las funciones del sistema

PRUEBAS DE DISEÑO

• Objetivo: generar especificaciones completas para la implementación de un sistema.

PRUEBA DE INTERFAZ

Parace que ya hemos logrado proporcionar a nuestros usuarios una interfaz gráfica bien organizada, similar a la de otras aplicaciones, utilizable con el teclado, con ayudas en toda la interfaz y en su idioma.

PRUEBA DE GRAFOS

Un criterio más riguroso se basa en la completitud ya no aplicado a las sentencias

sino a los arcos del grafo de flujo de control del programa.

Nuevamente, asumiremos un lenguaje estructurado a bloques para nuestro

análisis.

7.Criterios de paso/fallo para cada elemento.

8.Criterios de suspensión y requisitos de reanudación.

No existe

9.Documentos a entrega(como mínimo, los descritos en el estándar).

 Informe de Grafos

 Informe de Resistencia

 Informe de unidad

 Informe de integración

 Informe de interfaz grafica

 Informe de documentación y ayuda

10.Actividades de preparación y ejecución de pruebas.

Organización de Equipos

Jefe de equipo

SHIRLEY VELIZ BUSTILLOS

 Preparación de casos de pruebas

 Ejecución de pruebas

 Datos de la prueba

 Preparar informe

11.Necesidades de entorno.

En cuanto a:

SOFTWARE y HADWARE:

Sistema operativo MS-dos o Windows

Un computador con requerimiento mínimo de un microprocesador 486

DOCUMENTACION:

Absoluta comodidad, tranquilidad.

12.Responsabilidades en la organización y realización de las pruebas.

Pruebas de Documentación: Shirley Veliz Bustillos

Pruebas de software: Jorge Carlos Mendieta A.

13.Necesidades de personal y de formación.

Que sepa la utilización de sistemas operativos

(MS-dos) y lenguaje de programación (C++)

14.Esquema de tiempos(con tiempos estimados, hitos,etc.)

15.Riesgos asumidos por el plan y planes de contigencias para cada riesgo.

Copias de seguridad

Frecuencia

Periodicidad

Plan de contingencias

Prever fallos críticos

Procedimientos alternativos

Tratamiento de errores

Posibilidad de error recuperación

Planificación contenido mensajes de error

16.Aprobaciones y firmas con nombre y puesto desempeñado.

...