You are on page 1of 24

PLAN DE PRUEBAS

CURRIER SPRESS SOFTWARE

Mayo 2016

HISTRICO DE CAMBIOS
Fecha

Versin

07/05/2016

CURRIER SPRESS SOFTWARE

1.1

Descripcin
creacin

Autor
Anyerina paola
cabarcas Diaz

ndice
1.1.

Objetivos y tareas

1.1.1.

Objetivos

1.1.2.

Tareas

1.2.

Audiencia prevista

1.3.

Referencias

2.1.

tems a probar (funciones) 5

2.2.

Cuestiones de riesgo5

2.3.

Caractersticas a probar

2.4.

Caractersticas que no se van a probar

2.5.

Enfoque (estrategia) 5

3.1.

Criterios de entrada 6

3.2.

Criterios de salida

3.3.

Criterios de suspensin

3.4.

Criterios de reanudacin

3.5.

Criterios de xito y fallo

5.1.

Planificacin 8

5.2.

Recursos

5.2.1.

Hardware 8

5.2.2.

Software

5.2.2.1. Herramientas
5.2.3.

Dotacin de personal

5.2.3.1. Responsabilidades

5.2.3.2. Formacin

CURRIER SPRESS SOFTWARE

1.

INTRODUCCIN

El plan de pruebas refleja el enfoque y la programacin de todas las pruebas del


proyecto. Esta seccin expondr un breve resumen del producto que se va a probar.
Resume todas las funciones a alto nivel.
1.1.
1.1.1.

OBJETIVOS Y TAREAS
Objetivos

El documento a continuacin describe el alcance, la aproximacin, los recursos y la


planificacin y las actividades necesarias. Identifica elementos de prueba, las
caractersticas que deben probarse, las tareas de prueba, lo que har cada tarea.
Los elementos a ser probados son:

1.1.2.

Software
Documentacin

Tareas

Lista todas las tareas identificadas en este plan de pruebas, informes de pruebas,
informes de problemas, etc.
1.2.
1.3.

AUDIENCIA PREVISTA
Equipo de pruebas
Equipo de desarrollo
Jefe de proyecto
REFERENCIAS

Lista todos los documentos que se han utilizado para crear este plan, los que se
usarn en el desarrollo de casos de pruebas o durante la ejecucin de pruebas.
Estos se pueden listar en una tabla como la siguiente:
Documento
informe de
especificacin de
requerimientos del
proyecto

Autor
Anyerina cabarcas 1.1
Diaz

CURRIER SPRESS SOFTWARE

Versin

Localizacin
carpeta

CURRIER SPRESS SOFTWARE

2.

ALCANCE Y ENFOQUE

2.1.

TEMS A PROBAR (FUNCIONES)

Los elementos a ser probados son:

2.2.

Software
Documentacin

CUESTIONES DE RIESGO

Identifica qu software se ha de probar y cules son las reas crticas, tales como:
-

Entregable de un producto desarrollado por terceros.


Capacidad de usar y entender una nueva herramientas
Funciones extremadamente complejas
Modificaciones de componentes con un histrico pasado de fallos
Mdulos o peticiones de cambio mal documentados
Copias de seguridad
Frecuencia
Periodicidad
Plan de contingencias
Prever fallos crticos
Procedimientos alternativos
Tratamiento de errores
Posibilidad de error recuperacin
Planificacin contenido mensajes de error

2.3.

CARACTERSTICAS A PROBAR
1.
2.
3.
4.

fluidez de datos
independencia de mdulos
soporte del software
interfaz de usuario

CURRIER SPRESS SOFTWARE

2.4.

CARACTERSTICAS QUE NO SE VAN A PROBAR

2.5.

Errores relacionados con el tiempo.


Condiciones de error no detectadas.
Condiciones especiales de los datos.
Invalidez de la informacin mostrada por pantalla.
Interaccin con tareas en background.
Fallos de configuracin/compatibilidad con software
Incapacidad de soportar el volumen de carga o fallos hard.

ENFOQUE (ESTRATEGIA)

Descripcin de la estrategia de pruebas general para este plan de pruebas. Se han


de identificar las reglas y procesos asociados.
PRUEBA DEL DISEO
Las pruebas del diseo 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 mtodos y procesos para recolectar requisitos.
Comprobacin de la complecin y consistencia
Eliminacin de requisitos duplicados
PRUEBAS DE INTEGRACIN
Se prueban las funcionalidades, rendimiento, fiabilidad, etc. del sistema, sus
relaciones con el exterior, etc.
PRUEBAS DE REQUISITOS
Diferentes tcnicas de captura y anlisis de requisitos (prototipos, casos de uso,
etc.)

CURRIER SPRESS SOFTWARE

El resultado es una descripcin de las funciones del sistema


PRUEBAS DE DISEO
Objetivo: generar especificaciones completas para la implementacin de un
sistema.
PRUEBA DE INTERFAZ
Parace que ya hemos logrado proporcionar a nuestros usuarios una interfaz grfica
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 ms 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
anlisis.

CURRIER SPRESS SOFTWARE

3.

CRITERIOS DE TRANSICIN

A continuacin se describen los criterios requeridos para las pruebas para poder
pasar de un estado a otro.
3.1.
3.2.
3.3.

CRITERIOS DE ENTRADA
Aprobacin del plan de pruebas
Entorno de pruebas estable y preparado
Casos de pruebas escritos y aprobados
Herramientas de pruebas preparadas
Recursos para las pruebas disponibles
CRITERIOS DE SALIDA
Completitud de los casos de pruebas
Nmeros y severidad de los defectos abiertos
Paso de los objetivos de pruebas
CRITERIOS DE SUSPENSIN

-Software inconcluso.

3.4.

CRITERIOS DE REANUDACIN

-Software terminado.
3.5.

CRITERIOS DE XITO Y FALLO

Especificacin de los criterios que se han de usar para determinar si cada una de las
pruebas ha tenido xito o ha fallado.

CURRIER SPRESS SOFTWARE

CURRIER SPRESS SOFTWARE

10

4.

ESTRATEGIA DE PRUEBAS

Describe el enfoque general de las pruebas. Para cada grupo o combinacin de


caractersticas hay que especificar el enfoque que asegurar que ese grupo de
caractersticas se va a probar adecuadamente. Hay que especificar las actividades,
tcnicas y herramientas principales que se van a usar para cada uno de los grupos
de pruebas diseados.
PRUEBA DEL DISEO
Las pruebas del diseo 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 mtodos y procesos para recolectar requisitos.
Comprobacin de la complecin y consistencia
Eliminacin de requisitos duplicados
PRUEBAS DE INTEGRACIN
Se prueban las funcionalidades, rendimiento, fiabilidad, etc. del sistema, sus
relaciones con el exterior, etc.
PRUEBAS DE REQUISITOS
Diferentes tcnicas de captura y anlisis de requisitos (prototipos, casos de uso,
etc.)
El resultado es una descripcin de las funciones del sistema
PRUEBAS DE DISEO
Objetivo: generar especificaciones completas para la implementacin de un
sistema.

CURRIER SPRESS SOFTWARE

11

PRUEBA DE INTERFAZ
Parace que ya hemos logrado proporcionar a nuestros usuarios una interfaz grfica
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 ms 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
anlisis.

CURRIER SPRESS SOFTWARE

12

5.

PLANIFICACIN Y RECURSOS

5.1.

PLANIFICACIN

5.2.

RECURSOS

5.2.1.

Hardware

Lista todos los requisitos de hardware.


5.2.2.

Software

Lista todos los requisitos de software: sistemas operativos primarios y secundarios.


5.2.2.1.

Herramientas

En cuanto a:
SOFTWARE y HADWARE:
Sistema operativo MS-dos o Windows
Un
computador
con
microprocesador 486

5.2.3.

requerimiento

mnimo

de

un

Dotacin de personal
5.2.3.1.

Responsabilidades

Lista de los miembros del equipo de aseguramiento de la calidad y sus


responsabilidades.
Pruebas de Documentacin: ANYERINA PAOLA CABARCAS DIAZ
Pruebas de software: ANYERINA PAOLA CABARCAS DIAZ
Organizacin de Equipos
Jefe de equipo
ANYERINA PAOLA CABARCAS DIAZ

Preparacin de casos de pruebas

CURRIER SPRESS SOFTWARE

13

5.2.3.2.

Ejecucin de pruebas
Datos de la prueba
Preparar informe
Formacin

Que sepa la utilizacin de sistemas operativos


(MS-dos) y lenguaje de programacin (C++)
Revisin del plan de pruebas
Esta seccin incluye planes para la revisin de este plan de pruebas. Se identifican
los grupos para revisar y aprobar el documento.
Hay que cerciorarse de que el plan de pruebas satisface los requisitos de
desarrolladores y clientes.
ESPECIFICACIN DEL DISEO DE PRUEBAS
1.Identificador(nico) para la especificacin. Proporcionar tambin una
referencia del plan asociado(si existe).
No existe
2.Caractersticas a probar de los elementos software (y combinaciones de
caractersticas).

fluidez de datos
independencia de mdulos
soporte del software
interfaz de usuario

3. Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las
tcnicas de
Prueba especfica y los mtodos de anlisis de resultados.
4. Identificacin de cada prueba:
*Identificador.
*Casos que se van a utilizar.
*Procedimientos que se van a seguir.
5. Criterios de paso/fallo de la prueba(criterios para determinar si una
caracterstica o combinacin de caractersticas ha pasado con xito la prueba o no).

CURRIER SPRESS SOFTWARE

14

HISTORICO DE PRUEBAS
El histrico de pruebas (test log) documenta todos los hechos relevantes ocurridos
durante la ejecucin de las pruebas
HISTORICO DE PRUEBAS
Identificador
Descripcin de la prueba: elementos probados y entorno de la prueba Anotacin de
datos sobre cada hecho
ocurrido (incluido el comienzo y el final de la
prueba)

Fecha y hora
Identificador de informe de incidente

Otras informaciones

CURRIER SPRESS SOFTWARE

15

INFORME DE INCIDENTE
El informe de incidente (test incident report) documenta cada incidente (por ejemplo,
una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del
teclado, etc.) ocurrido en la prueba y que requiera una posterior investigacin.
INFORME DE INCIDENTE
Identificador
Resumen del incidente
Descripcin de datos objetivos (fecha/hora, entradas,resultados esperados, etc)
Impacto que tendr sobre las pruebas
INFORME RESUMEN DE PRUEBAS
El informe resumen (test summary report) resume los resultados de las actividades
de prueba (las sealadas en el propio informe) y aporta una evaluacin del software
basada en dichos resultados
INFORME RESUMEN DE LAS PRUEBAS
Identificador
Resumen de la evaluacin de los elementos probados
Variaciones del software respecto a su especificacin de diseo, as como las
variaciones en las pruebas
Valoracin de la extensin de la prueba (cobertura lgica, funcional, de requisitos,
etc.)
Resumen de los resultados obtenidos en las pruebas
Evaluacin de cada elemento software sometido a prueba (evaluacin general del
software incluyendo las limitaciones del mismo)
Firmas y aprobaciones de quienes deban supervisar el informe

CURRIER SPRESS SOFTWARE

16

2
,
3

PRUEBA DE GRAFOS
NOTACION DE GRAFO FLUJO

3
5

7
1

6
1

9
1
1
1

8
1
1
0

1
2
1
3
1
4
1
5

CURRIER SPRESS SOFTWARE

17

COMPLEJIDAD CICLOMATICA
Camino 1:

1- 2 - 3 - 4 - 15

Camino 2:

1- 2 - 3 - 5 6 14 - 15

Camino 3:

1- 2 - 3 - 5 7 8 13 - 14 - 15

Camino 4:

1- 2 - 3 - 5 7 9 10 - 12 13 14 - 15

Camino 5:

1- 2 - 3 - 5 7 9 11 - 12 13 14 - 15

LA COMPLEJIDAD CICLOMATICA
V(G)= A N + 2
V(G)= 18 15 + 2
V(G)= 5
A = ARISTAS

CURRIER SPRESS SOFTWARE

18

N = NODOS
V(G) = 4 NODOS PREDICADO + 1
V(G) = 5

2
,
3

NOTACION DE GRAFO FLUJO

4
5
1
6
2
,
3
7
9
9
1

9
1

1
0

1
1
1
2

CURRIER SPRESS SOFTWARE

19

1
3

8
7
9
1
0

COMPLEJIDAD CICLOMATICA
Camino 1:

1- 2 - 3 - 4 5 6 7 8 - 10 11 12 - 13

Camino 2:

1- 2 - 3 - 4 5 6 7 9 - 10 11 12 - 13

LA COMPLEJIDAD CICLOMATICA
V(G)= A N + 2
V(G)= 15 13 + 2
V(G)= 4
A = ARISTAS
N = NODOS
V(G) = 3 NODOS PREDICADO + 1
V(G) = 4

CURRIER SPRESS SOFTWARE

20

PRUEBA DE UNIDAD
Hablamos de una unidad de prueba para referirnos a uno o ms mdulos que
cumplen las siguientes condiciones [IEEE, 1986a]:
Todos son del mismo programa
Al menos uno de ellos no ha sido probado
El conjunto de mdulos es el objeto de un proceso de prueba
PRUEBAS DE INTEGRACION
Factores

La forma de preparar casos


Las herramientas necesarias
El orden de codificar y probar los mdulos
El coste de la depuracin
El coste de preparacin de casos

1
PROGRAMA
CURIER SPRESS SOFTWARE

1.1.1

1.1

1.2

1.3

ENTRADA

PROCESO

SALIDA

1.1.2

Se ingresan
Se asocia el
los datos del
documento
remitente y de
guardado a un
la
funcionario
corresponden
cia CURRIER SPRESS SOFTWARE
21

1.2.1

1.2.2

Se genera un
consecutivo

Se genera un
informe

1.2.3
Se enva al
correo
electrnico del
funcionario
encargado una
alerta para que
responda

PRUEBA DEL SISTEMA PRUEBA DEL SISTEMA

Cumplimiento de todos los requisitos funcionales, considerando el producto


software final al completo en un entorno de sistema
El funcionamiento y rendimiento en las interfaces hardware, software, de
usuario y de operador
Adecuacin de la documentacin de usuario
Ejecucin y rendimiento en condiciones lmite y de sobrecarga

FUENTES DE DISEO DE CASOS DE PRUEBA

Casos basados en los requisitos gracias a tcnicas de caja negra aplicadas a


las especificaciones
Casos necesarios para probar el rendimiento del sistema y de su capacidad
funcional (pruebas de volumen de datos, de lmites de procesamiento, etc.).
Este tipo de pruebas suelen llamarse pruebas de sobrecarga (stress testing)
Casos basados en el diseo de alto nivel aplicando tcnicas de caja blanca a
los flujos de datos de alto nivel (por ejemplo, de los diagramas de flujo de
datos)

CURRIER SPRESS SOFTWARE

22

Los elementos a ser probados son:


Pruebas de caja negra:
reas de prueba ms importantes en el plan:

Grafos
Resistencia
unidad
integracin
interfaz grafica
documentacin y ayuda
Tiempo real

CURRIER SPRESS SOFTWARE

23

6.

ANEXOS

CURRIER SPRESS SOFTWARE

24

You might also like