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

...