quicksoft6.files.wordpress.com€¦ · Web viewLa necesidad de comprobar el correcto funcionamiento del producto hace que sea imprescindible un plan de pruebas, con el cual se procederá

Documento de Pruebas

Revision: 3

Ultimo cambio: 14/11/2009

Autores: Andrés Mauricio tapias/Julián David Romero / Wilson Andrés Arguello/ David Toca Ávila/Ricardo Silva Gómez/Pedro Antonio Moncada

Cliente: Gilberto PedrazaRespondable del

documento: Julián David Romero

Enviar comentarios a: [email protected] del Documento Documento de Prueba

Localización del Documento: http: www.quicksoftcol.tk

Plan de Diseño de software QuickSoft

TABLA DE CONTENIDO

1. PROPÓSITO

2. ALCANCE

3. DETALLE DE LAS ACTIVIDADES DEL PROCEDIMIENTO

3.1 Análisis de los requerimientos del proyecto

3.2 Diseño de pruebas y sus casos de pruebas

3.3 Validación y ejecución mediante la aprobación del diseño de los casos de prueba

4. CUADRO RESUMEN DE LAS PRUEBAS

5. BASES DE DATOS DE PRUEBAS

6. EQUIPO DE PRUEBAS Y RESPONSABILIDADES

7-ANEXO


INTRODUCCIÓN

La necesidad de comprobar el correcto funcionamiento del producto hace que sea imprescindible un plan de pruebas, con el cual se procederá a realizar una serie de ensayos que permitan obtener resultados correctos y erróneos con el fin de analizar el proceso de ejecución. Con este conjunto de pruebas seremos capaces de determinar si nuestro programa es erróneo sobre todo en casos extremos y particulares, tanto si estos fallos se producen por la una mala implementación del programa o bien por un uso especifico que realiza el usuario. El aspecto más importante para realizar la planificación de este conjunto de pruebas en abarcar con ellas todos los requisitos que debe cumplir el programa y que por tanto responda correctamente a las funcionalidades que se le solicitan inicialmente. Puesto que en el documento de especificación de requisitos software ya se ha realizado una evaluación de las funcionalidades que debe incluir el programa, tomaremos este documento de referencia para desarrollar el plan de pruebas de sistema.

OBJETIVO

La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica:

Verificar la interacción de componentes.

Verificar la integración adecuada de los componentes.

Verificar que todos los requisitos se han implementado correctamente.

Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.

Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.


DOCUMENTOS RELACIONADOS

Nombre Descripción

Informe de diseño El diseño que se

implementoInforme de requerimientos y casos de uso

Informe de A el informe que contiene los requisitos del programa

ESTRATEGIA DE PRUEBAS DE SOFTWARE

Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.

Más concretamente, los objetivos de la estrategia de prueba son:

Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.

Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.

Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.

Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:

Planificación de las pruebas.

Diseño de las pruebas.


Implementación de las pruebas.

Ejecución de las pruebas.

Evaluación de las pruebas.

Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:

Plan de Pruebas.

Casos de Prueba.

Informe de evaluación de Pruebas.

Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.

1-PROPÓSITO

Garantizar el cumplimiento de los requerimientos planteados en el marco del proyecto.

Asegurar que se tengan en cuenta todos los casos de pruebas posibles para validar la solución informática a un requerimiento o solicitud de cambio, garantizando que en el momento de entregar el producto a pruebas de usuario éste cuente con un nivel de calidad apropiado.

Definir todas las actividades relacionadas con la ejecución de las pruebas unitarias, las responsabilidades individuales para cada tarea, los recursos y los prerrequisitos que deben ser considerados en el esfuerzo de pruebas.

2-ALCANCE


Aplica para el diseño y la elaboración de los planes de pruebas unitarias que son ejecutadas por los desarrolladores antes de realizar la entrega de una versión estable del producto para que le sean aplicadas las pruebas de usuario. Estas pruebas son realizadas a nivel de capa de negocio en los productos y servicios comprendidos dentro del sistema de calidad. Su diseño y ejecución se apoyan en la herramienta JUnit.

3-DETALLE DE LAS ACTIVIDADES DEL PROCEDIMIENTO

3.1 Análisis de los requerimientos del proyecto

Nos basamos en todos los documentos que nos pueden ayudarle a definir las pruebas unitarias que se realizarán en la capa de presentación de cada uno de los componentes que se desean probar. De esta manera se garantiza la completitud de las pruebas definidas y el desarrollo de un proceso de calidad que realmente apoye la detección temprana de errores dentro del grupo de desarrollo y promueva el desarrollo de software de alta calidad.

Los documentos en los cuáles nos apoyamos son:

- Levantamiento de requerimientos - Análisis del requerimientos - Diseño (Diseño de plataforma Java, Diseño PLSQL- ORACLE)- Diseño Detallado (Diagramas de Secuencia CU, Modelo de Datos)


3.2 Diseño de pruebas y sus casos de pruebas

Para realizar el diseño y ejecución de pruebas unitarias sobre los componentes del negocio, se utilizará la herramienta JUnit, con esta herramienta es posible diseñar y ejecutar diferentes Casos de Prueba de una manera sencilla y rápida. Estos casos de prueba pueden ser ejecutados repetidamente cuando sea necesario, optimizando el tiempo requerido para efectuar pruebas de regresión.

Las pruebas de regresión es la actividad que ayuda a asegurar que los cambios (debido a pruebas u otros motivos) no introduzcan un comportamiento no deseado o errores adicionales, por ello prueban nuevamente componentes evaluados anteriormente, asegurando que los cambios introducidos en el software no han afectado su funcionamiento.Utilizando JUnit se deben realizar las siguientes pruebas sobre cada uno de los componentes del negocio, teniendo en cuenta en cada uno de ellos condiciones de ejecuciones válidas e inválidas de acuerdo a las reglas del negocio establecidas:

- Funcionamiento adecuado del ciclo de vida- Métodos del negocio- Manejo adecuado de las reglas del negocio

Se tiene la concepción de realizar a futuro un documento de Configuración del Ambiente de Pruebas en donde describa detalladamente las configuraciones que deben efectuarse previamente para poder diseñar y ejecutar adecuadamente las pruebas unitarias. Si se van a realizar pruebas unitarias que involucren la interacción con otros sistemas presentes en el proyecto, es fundamental describir en el documento de Configuración del Ambiente de Pruebas, cómo se comunican los sistemas involucrados, la información de


entrada y salida que se maneja, y las configuraciones previas que deben realizarse en cada uno de los sistemas para la ejecución de las pruebas unitarias.

3.3 Validación y ejecución mediante la aprobación del diseño de los casos de prueba

Es importante validar y efectuar los casos de prueba definidos, verificando que se han contemplado todas las pruebas necesarias, que no existen pruebas duplicadas o implícitas en otras y que el tiempo estimado no sobrepasa la fecha límite de ejecución.Como lo expresa nuestro cliente es necesario que la inspección de los casos de prueba la efectúe una persona diferente a quien diseño los casos de prueba inicialmente.

7. CUADRO RESUMEN DE LAS PRUEBAS

Módulos del Sistema a ser probados:

Módulos:

- Presentación

- Persistencia

- Controlador

Objetivos de las Pruebas En estos Módulos se realizarán pruebas para validar:

La visualización de los datos, ingresados o modificados.

La operación de los servicios en relación a la arquitectura para dar respuesta a los productos del sistema.

La respuesta y realización de las transacciones de cada módulo.

Que las actividades y requerimientos generados en el sistema se reflejen de acuerdo a la necesidad del usuario.

La secuencia lógica de las funcionalidades y transacciones.Detalle del orden de ejecución de los módulos

Los módulos se deben ejecutar en forma independiente, pero consecutivos en el orden siguiente:

- Persistencia

- Presentación

- Controlador

Responsabilidad de la Prueba Las pruebas son responsabilidad del Testing Operacional del equipo de proyecto en este caso el Líder de Desarrollo encabeza este trabajo, quien en conjunto con los demás Lideres de Equipo y el usuario final deben seleccionar las pruebas que


aseguren la efectividad del sistema.


CRITERIOS DE INICIO

Aceptación del plan de pruebas. Revisión y aceptación del documento que contiene los casos de pruebas para la certificación del proyecto.

Aceptación de paquetes. Revisión y aceptación de los paquetes de desarrollo, y que este cumpla con las condiciones de aceptación dadas por el cliente.

Aceptación de ambiente. Revisión y aceptación del ambiente de certificación, y que este cumpla con las condiciones planteadas en la arquitectura.

8. BASES DE DATOS DE PRUEBAS

Base de Datos : ORACLE

Servidor BD : Oracle

Datos : Tablas

9. CRITERIOS DE APROBACION / RECHAZO

Errores Graves: información crítica presentada erróneamente, información mal registrada en la base de datos, caídas de programas, incumplimiento de objetivos en funciones principales, etc.

Errores Medios (comunes): errores en documentos impresos que se entregan a personas ajenas a la organización, errores en presentación de datos, incumplimiento de objetivos en funciones secundarias, caídas de programas auxiliares, etc.

Errores Leves: errores en presentación de datos secundarios, no adecuación a estándares, comportamientos correctos pero diferentes en situaciones similares, dificultades de operación, etc.


Las pruebas se llevarán a cabo de la siguiente forma:

1. Secuencias de pasos para la Configuración

Configuración de los Equipos Cliente y del Servidor de Aplicación Web (Servlet) y de Base de Datos.

2. Secuencias de pasos para la generación de datos para los módulos.

Ejecución del proceso (manual) de generación de datos, donde las tablas y campos a utilizar serán llenados manualmente.


PRUEBA DE INTEGRACIÓN

INTRODUCCION

La necesidad de realizar las pruebas de integración viene dada por el hecho de que los módulos que forman un programa suelen fallar cuando trabajan de forma conjunta, aunque previamente se haya demostrado que funcionan correctamente de manera individual. Por ello realizamos este tipo de pruebas, asegurándonos que los módulos que están relacionados ejecuten correctamente. Con el uso de estas pruebas conseguimos ir formando el programa global a medida que se comprueba como los distintos componentes interaccionan y se comunican libres de errores.

PROPÓSITO

Garantizar el cumplimiento de los requerimientos planteados en el marco del proyecto en cuanto a la integración de aplicaciones.

Asegurar que se tengan en cuenta todos los casos de pruebas posibles para validar la solución informática a un requerimiento o solicitud de cambio, garantizando que en el momento de entregar el producto a pruebas de usuario éste cuente con un nivel de calidad apropiado.

Definir todas las actividades relacionadas con la ejecución de las pruebas de integración, las responsabilidades individuales para cada tarea, los recursos y los prerrequisitos que deben ser considerados en el esfuerzo de pruebas.

Garantizar el funcionamiento adecuado de las reglas de negocio que involucran la integración de aplicaciones.

Garantizar el buen funcionamiento de la infraestructura de integración utilizada.

ALCANCE

Aplica para el diseño y la elaboración de los planes de pruebas de integración que son ejecutadas por los desarrolladores antes de realizar la entrega de una versión estable del producto para que le sean aplicadas las pruebas de usuario. Estas pruebas son realizadas a nivel de capa de negocio en los productos y servicios comprendidos dentro del sistema de calidad. Su diseño y ejecución se apoyan en la herramienta Junit.

En este caso particular las pruebas de integración están enfocadas en verificar el correcto funcionamiento de las reglas de negocio de integración sobre la infraestructura


DIAGRAMA DE ACTIVIDADES DEL PROCEDIMIENTO


DIAGRAMA DE INTEGRACION DEL SISTEMA

Para realizar la integración del sistema se ha tomado la decisión de poner en práctica la integración ascendente, es decir, comenzar por los módulos más bajos hasta el programa principal. Siguiendo la especificación del diseño de alto nivel, podemos ver que solo hay dos niveles, la clase “Ejecutar operación” estará en el nivel más alto y el resto de las clases en el más bajo, puesto que es la clase Ejecutar operación la que llama al resto. Par desarrollar el diagrama supondremos que las pruebas unitarias de cada una de las clases han sido superadas correctamente y por tanto no se van a representar de forma grafica.

La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté deacuerdo con el que dicta el diseño.


TIPOS DE INTEGRACIÓN

Integración descendente, es una estrategia de integración incremental a la construcción de la estructura de programas, en el cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía comenzando por el control principal (Programa principal). Los módulos subordinados de control principal se incorporan en la estructura en la estructura, bien, de forma primero-en-profundidad, bien primero-en-anchura.

Integración ascendente, es donde la construcción del diseño empieza desde los módulos más bajos hacia arriba (módulo principal), el procesamiento requerido de los módulos subordinados siempre esta disponible y elimina la necesidad de resguardo.La sección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede


Pruebas de Integración

Estas pruebas se desarrollan versus a los Casos de Uso

1. Ingresar integrante:

Caso exitoso: se ingresa el integrante

Caso de prueba: que el que ingresa no se sepa los datos del integrante.

Error Falla en la base de datos

Identificador: PR-01

Proyecto: Defect Zero

Referencias: CU –1.

Nombre: Ingresar Integrante

Responsable: David Toca

Estado: Inspeccionada

Dependencias: Ninguna

Identificador: CPR-01

Identificador de Prueba:

PR-01


Usuario y Fecha de Creación:

David Mora – 9 de Noviembre de 2009

Usuario y Fecha de Última Modificación:

David Toca – 9 de noviembre de 2009

Descripción: Este caso de prueba tiene el objetivo la verificación del ingreso del integrante


Prioridad: 1


2. Ingresar un defecto (integrante):

Caso exitoso: se ingresa el defecto

Caso de prueba: el que ingresa tiene todos los datos del defecto.





Nombre: Ingresarr un defecto (Integrante)

Responsable: Ricardo Silva


Dependencias: PR-01



PR-02

Nombre: Ingresar un defecto (Integrante) y producir una respuesta


Ricardo Silva – 12 de Noviembre


Ricardo Silva – 12 de Nov 2009

Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema lo ingrese correctamente

Dependencias: PR-01

Prioridad: 1


3. ingresar un defecto

(administrador):

Caso exitoso:

Caso de prueba: el que ingresa tiene todos los datos del defecto.





Nombre: Ingresar un defecto (Administrador)



Dependencias: PR-02



PR-03

Nombre: Ingresar un defecto (Administrador) y producir una respuesta





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema lo ingrese correctamente por parte del administrador

Dependencias: PR-02

Prioridad: 2


4. Crear un proyecto (administrador):

Caso exitoso: se creo el proyecto

Caso de prueba: el administrador ingresa datos validos del proyecto




Referencias: CU –4

Nombre: Crear un proyecto (Administrador)

Responsable: Julián Romero


Dependencias: PR-03



PR-04



Julián Romero – 12 de Noviembre


Julián Romero – 12 de Nov 2009

Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema ingrese un proyecto correctamente administrador

Dependencias: PR-03

Prioridad: 4


5. Iniciar sesión (integrante):

1. Caso exitoso: el integrante ingresa al Sistema

2. Caso de Prueba: usuario y contraseña de un integrante existente

Error: Falla de conexión Servidor




Nombre: Iniciar Sesión (Integrante)



Dependencias: PR-04



PR-05





Julián Romero – 11 de Noviembre 2009

Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema inicie sesión correctamente

Dependencias: PR-04

Prioridad: 5

6. iniciar sesión (administrador):


1. Caso exitoso: el administrador ingresa al Sistema

2. Caso de Prueba: usuario y contraseña de un administrador existente





Nombre: Iniciar Sesión (Administrador)



Dependencias: PR-05



PR-06



Julián Romero – 12de Noviembre



Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema inicie sesión correctamente administrador

Dependencias: PR-05

Prioridad: 6


7. modificar un integrante:

Caso exitoso: los datos del integrante han sido modificados

Caso de prueba: los datos nuevos son compatibles en los campos y son validos





Nombre: modificar un integrante



Dependencias: PR-04



PR-07

Nombre: modificar un integrante


David Toca – 13de Noviembre


David Toca – 13 de Noviembre 2009

Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema modifique un integrante correctamente

Dependencias: PR-06

Prioridad: 7

8. modificar un proyecto:

Caso exitoso: los datos del proyecto han sido modificados







Nombre: modificar un proyecto



Dependencias: PR-05



PR-08

Nombre: modificar un proyecto





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema modifique un proyecto correctamente

Dependencias: PR-06

Prioridad: 7

9. eliminar un proyecto:

Caso exitoso: el proyecto es eliminado


Caso de prueba: el proyecto no tiene ningún defecto




Nombre: Eliminar un proyecto



Dependencias: PR-08



PR-09






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema elimine un proyecto correctamente

Dependencias: PR-08

Prioridad: 8

10. Eliminar un integrante:

Caso exitoso: el integrante es eliminado

Caso de prueba: el integrante no tiene ningún defecto





Nombre: Eliminar un integrante



Dependencias: PR-08



PR-09



Julian Romero – 14de Noviembre


Julian Romero – 14 de Noviembre 2009

Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema elimine un integrante correctamente

Dependencias: PR-09

Prioridad: 9

11. cerrar sesión:

Caso exitoso: la sesión del usuario se cierra con éxito

Caso de prueba: el usuario presiona el botón cerrar sesión





Nombre: Cerrar sesión



Dependencias: PR-10



PR-11

Nombre: Cerrar sesion





Descripción: Este caso de prueba tiene el objetivo de cerrar sesión correctamente

Dependencias: PR-10

Prioridad: 9

12. ver defectos (administrador)

Caso exitoso: el administrador observa correctamente los defectos del proyecto

Caso de prueba: el administrador inicia sesión y accede a la funcionalidad ver defectos





Nombre: Ver defectos



Dependencias: PR-11



PR-12

Nombre: Ver defectos





Descripción: Este caso de prueba tiene el objetivo de ver los defectos del líder

Dependencias: PR-11

Prioridad: 10

13. ver defectos (integrante)

Caso exitoso: el integrante observa correctamente los defectos que tiene asignados

Caso de prueba: el integrante inicia sesión y accede a la funcionalidad ver defectos





Nombre: Ver defectos (integrante)



Dependencias: PR-12



PR-13

Nombre: Ver defectos (integrante)





Descripción: Este caso de prueba tiene el objetivo de ver los defectos del integrantes

Dependencias: PR-12

Prioridad: 11

14. asignar defecto

Caso exitoso: el administrador asigno correctamente un defecto a un integrante

Caso de prueba: el administrador inicia sesión y accede a la funcionalidad asignar defectos, a continuación asigna un defecto a un integrante





Nombre: Asignar defecto



Dependencias: PR-13



PR-14

Nombre: Asignar defectos





Descripción: Este caso de prueba tiene el objetivo de asignar el defecto encontrado

Dependencias: PR-13

Prioridad: 12

15. filtrar defectos por fecha ascendente

Caso exitoso: la lista de defectos fue mostrada según el orden ascendente

Caso de prueba: el integrante selección el filtro ascendente





Nombre: filtrar defectos por fecha ascendente



Dependencias: PR-14



PR-15






Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos por fecha de forma ascendente

Dependencias: PR-14

Prioridad: 13

16. filtrar defectos por fecha descendente

Caso exitoso: la lista de defectos fue mostrada según el orden descendente

Caso de prueba: el integrante selección el filtro descendente





Nombre: filtrar defectos por fecha descendente



Dependencias: PR-14



PR-16






Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos por fecha de forma descendente

Dependencias: PR-15

Prioridad: 13

17. filtrar defectos sin asignar

Caso exitoso: la lista de defectos fue mostrada según el orden sin asignar

Caso de prueba: el integrante selección el filtro sin asignar





Nombre: filtrar defectos sin asignar



Dependencias: PR-16



PR-17

Nombre: filtrar defectos sin asignar


David Toca – 14 de Noviembre



Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos no asignados

Dependencias: PR-16

Prioridad: 15

18. filtrar defectos asignados

Caso exitoso: la lista de defectos fue mostrada según el orden asignados

Caso de prueba: el integrante selección el filtro asignados





Nombre: filtrar defectos asignados



Dependencias: PR-17



PR-18

Nombre: filtrar defectos asignados





Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos asignados

Dependencias: PR-17

Prioridad: 16

19. filtrar defectos no resueltos

Caso exitoso: la lista de defectos fue mostrada según el orden no resuelto

Caso de prueba: el integrante selección el filtro no resuelto





Nombre: filtrar defectos no resueltos



Dependencias: PR-18



PR-19

Nombre: filtrar defectos no resueltos





Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos no resueltos

Dependencias: PR-18

Prioridad: 17

20. filtrar defectos resueltos

Caso exitoso: la lista de defectos fue mostrada según el orden resuelto

Caso de prueba: el integrante selección el filtro resuelto





Nombre: filtrar defectos resueltos



Dependencias: PR-18



PR-20

Nombre: filtrar defectos resueltos





Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos no resueltos

Dependencias: PR-18

Prioridad: 17


21. Resolver defecto

Caso exitoso: el defecto fue resuelto

Caso de prueba: el integrante selección el defecto a resolver




Nombre: Resolver defecto



Dependencias: PR-18



PR-21






Descripción: Este caso de prueba tiene el objetivo de resolver un defecto

Dependencias: PR-18

Prioridad: 10


22. Métrica defectos solucionados

Caso exitoso: la métrica fue visualizada correctamente

Caso de prueba: el administrador trata de mirar la métrica de defectos solucionados




Nombre: Métrica defectos solucionados



Dependencias: PR-18



PR-22






Descripción: Este caso de prueba tiene el objetivo de mirar las métricas de defecto solucionados

Dependencias: PR-18

Prioridad: 10


23. Métrica fase inyección de defectos


Caso de prueba: el administrador trata de mirar la métrica de fase inyección de defectos




Nombre: métrica de fase inyección de defectos



Dependencias: PR-18



PR-23

Nombre: métrica de fase inyección de defectos





Descripción: Este caso de prueba tiene el objetivo de mirar las métrica de fase inyección de defectos

Dependencias: PR-18

Prioridad: 10


24. Métrica tiempo de detección de defectos


Caso de prueba: el administrador trata de mirar la métrica tiempo de detección de defectos




Nombre: métrica tiempo de detección de defectos



Dependencias: PR-18



PR-24

Nombre: métrica tiempo de detección de defectos





Descripción: Este caso de prueba tiene el objetivo de mirar las métrica de tiempo de detección de defectos

Dependencias: PR-18

Prioridad: 10


Casos de Prueba Fracaso

25. Ingresar Integrante:

Caso exitoso: Mensaje de Error

Caso de Prueba: Datos Inválidos al ingresar un Integrante


Identificador: PR Fracaso -01







Identificador: CPR Fracaso -01


PR-01



David Toca – 9 de Noviembre de 2009


David Toca – 9 de noviembre de 2009

Descripción: Este caso de prueba tiene el objetivo de que el sistema no ingrese in Integrante si los Datos son Inválidos


Prioridad: 1


26. Ingresar un Defecto (integrante):

Caso Éxito: Mensaje de Error

Caso de prueba: El que ingresa un defecto tiene Datos Inválidos


Identificador: PR Fracaso-02



Nombre: Ingresar un defecto (Integrante)



Dependencias: PR-01

Identificador: CPR Fracaso-02


PR-02

Nombre: Ingresar un defecto (Integrante) y producir una respuesta




Ricardo Silva – 12 de Noviembre 2009

Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no ingrese el defecto si los Datos son Inválidos

Dependencias: PR-01

Prioridad: 2


27. Ingresar un Defecto (administrador):

Caso exitoso: Mensaje de Error

Caso de prueba: Ingreso de un defecto (Administrador) tiene Datos Inválidos





Nombre: Ingresar un defecto (Administrador)



Dependencias: PR-02



PR-03

Nombre: Ingresar un defecto (Administrador) y producir una respuesta.





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no ingrese correctamente un defecto por parte del administrador si los datos son inválidos


Prioridad: 2


28.Crear un proyecto (Administrador):

Caso exitoso: Mensaje de Error No se Puede Crear un Proyecto

Caso de prueba: El Administrador ingresa datos invalidos del proyecto








Dependencias: PR-03



PR-04






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no permita ingresar un proyecto correctamente administrador si los datos son inválidos.

Dependencias: PR-03

Prioridad: 4


29. Iniciar sesión (Integrante):

1. Caso exitoso: Mensaje de Error Iniciar Sesión

2. Caso de Prueba: Usuario y Contraseña de un integrante existente








Dependencias: PR-04



PR-05






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no inicie sesión correctamente si los datos de usuario y contraseña don inválidos.

Dependencias: PR-04

Prioridad: 5


30. Iniciar Sesión (Administrador):

1. Caso exitoso: Mensaje de Error Administrador no puede Ingresa al Sistema

2. Caso de Prueba: Usuario y Contraseña de un administrador existente








Dependencias: PR-05



PR-06






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no inicie sesión correctamente administrador si los datos de usuario y contraseña don inválidos.

Dependencias: PR-05

Prioridad: 6


31.Modificar un Integrante:

Caso exitoso: Mensaje de Error los datos del integrante no han sido modificados






Nombre: Modificar un Integrante



Dependencias: PR-04



PR-07

Nombre: Modificar un Integrante





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no modifique un integrante si los campos son inválisdos.

Dependencias: PR-06

Prioridad: 7


32. Modificar un Proyecto:

Caso exitoso: Mensaje de Error los datos del proyecto no han sido modificados






Nombre: Modificar un Proyecto



Dependencias: PR-05



PR-08

Nombre: Modificar un Proyecto





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no modifique un proyecto si los datos son inválidos.

Dependencias: PR-06

Prioridad: 7


33.Eliminar un Proyecto:

Caso exitoso: Mensaje de Error el proyecto no puede ser eliminado

Caso de prueba: El proyecto no tiene ningún defecto







Dependencias: PR-08



PR-09






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no permita eliminar un proyecto si a el no se le han asignado defectos.

Dependencias: PR-08

Prioridad: 8


34. Eliminar un Integrante:

Caso exitoso: Mensaje de Error el integrante no puede ser eliminado

Caso de prueba: el integrante no tiene ningún defecto







Dependencias: PR-08



PR-09






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no elimine un integrante a el no se le han asignado defectos.

Dependencias: PR-09

Prioridad: 9


35. Cerrar Sesión:




Nombre: cerrar sesión



Dependencias: PR-01



PR-35

Nombre: cerrar sesión





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no cierre sesión si no se cumplen ciertas condiciones

Dependencias: PR-01

Prioridad: 1


36. Ver Defectos

(Administrador)




Nombre: ver defectos (administrador)



Dependencias: PR-01



PR-36

Nombre: ver defectos y producir una respuesta





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no vea defectos (administrador) si los Datos son Inválidos

Dependencias: PR-01

Prioridad: 1





Nombre: ver defectos (integrante)



Dependencias: PR-01



PR-37

Nombre: ver defectos y producir una respuesta





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no vea defectos (integrante) si los Datos son Inválidos

Dependencias: PR-01

Prioridad: 1


38. Asignar Defecto




Nombre: asignar defecto



Dependencias: PR-01



PR-38

Nombre: asignar defecto





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no asigne un defecto si los Datos son Inválidos

Dependencias: PR-01

Prioridad: 1


39. Filtrar defectos por fecha ascendente







Dependencias: PR-01



PR-39

Nombre: filtrar defectos por fecha ascendente y producir una respuesta





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no filtrar defectos por fecha ascendente si no existen Datos

Dependencias: PR-01

Prioridad: 1


40. Filtrar defectos por fecha descendente







Dependencias: PR-01



PR-40

Nombre: filtrar defectos por fecha ascendente y producir una respuesta





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no filtrar defectos por fecha descendente si no existen Datos

Dependencias: PR-01

Prioridad: 1





Nombre: defectos sin asignar



Dependencias: PR-01



PR-41

Nombre: defectos sin asignar y producir una respuesta





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos sin asignar si no existen Datos

Dependencias: PR-01

Prioridad: 1





Nombre: defectos asignados



Dependencias: PR-01



PR-02

Nombre: defectos asignados y producir una respuesta





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos asignados si no existen Datos

Dependencias: PR-01

Prioridad: 1





Nombre: defectos no resueltos



Dependencias: PR-01



PR-02

Nombre: defectos no resueltos





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos no resueltos si no existen Datos

Dependencias: PR-01

Prioridad: 1





Nombre: defectos resueltos



Dependencias: PR-01



PR-02

Nombre: defectos resueltos





Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos resueltos si no existen Datos

Dependencias: PR-01

Prioridad: 1








Dependencias: PR-01



PR-02






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no resuelva defectos si no existen defectos

Dependencias: PR-01

Prioridad: 1








Dependencias: PR-01



PR-02






Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no produzca la métrica defectos solucionados si no existen defectos solucionados

Dependencias: PR-01

Prioridad: 1



47. Métrica Fase Inyección de Defectos

Caso exitoso: Mensaje de Error la métrica no fue visualizada correctamente

Caso de Prueba: el administrador trata de mirar la métrica de fase inyección de defectos




Nombre: Métrica de fase inyección de defectos






PR-23

Nombre: Métrica de fase inyección de defectos





Descripción: Este caso de prueba tiene el objetivo el no visualizar las métrica de fase inyección de defectos


Prioridad: 10


48. Métrica Tiempo de Detección de Defectos

Caso exitoso: Mensaje de Error la métrica no fue visualizada correctamente

Caso de prueba: El Administrador trata de mirar la métrica tiempo de detección de defectos




Nombre: Métrica tiempo de detección de defectos






PR-24

Nombre: Métrica tiempo de detección de defectos





Descripción: Este caso de prueba tiene el objetivo el no visualizar las métrica de tiempo de detección de defectos


Prioridad: 10


RESULTADOS

1. ingresar integrante:Superado

2. ingresar un defecto (integrante):Superado

3. ingresar un defecto (administrador):Superado

4. crear un proyecto (administrador):Superado

5. iniciar sesión (integrante):Superado

6. iniciar sesión (administrador):Superado

7. modificar un integrante:No superado

8. modificar un proyecto:No superado

9. eliminar un proyecto:No superado

10. eliminar un integrante:No superado

11. cerrar sesión:Superado

12. ver defectos (administrador)Superado

13. ver defectos (integrante)Superado

14. asignar defectoNo superado

15. filtrar defectos por fecha ascendenteSuperado

16. filtrar defectos por fecha descendenteSuperado

17. filtrar defectos sin asignarSuperado

18. filtrar defectos asignadosSuperado

19. filtrar defectos no resueltosSuperado

20. filtrar defectos resueltosSuperado


12- RESULTADOS

El componente de persistencia esta libre de defectos

1 Partes tienen fallos en compilación

Se presentaron fallos en la mayoría de los métodos de eliminación y modificación


ANEXO

VERSION 1.1

CAMBIO de- pruebas de integración

Se agregaron varios casos

TIPO DE CAMBIO ADICCION

MOTIVO

Debido a los nuevos casos de uso

CAMBIO de resultados

Se agregaron varios resultados

TIPO DE CAMBIO MODIFICACION

MOTIVO

Debido a los nuevos casos de prueba, se originaron nuevos resultados

MOTIVO

No estaban especificadas anteriormente



Documents

quicksoft6.files.wordpress.com€¦ · Web viewLa necesidad de comprobar el correcto funcionamiento del producto hace que sea imprescindible un plan de pruebas, con el cual se procederá