Documentos de Académico
Documentos de Profesional
Documentos de Cultura
06 DPR DocumentoDePruebas
06 DPR DocumentoDePruebas
<Nombre de Proyecto>
Versión 1.0
Empresa:
Fecha:
Jefe Proyecto:
Teléfono:
Email:
Unidad Gobierno:
Contacto:
Teléfono:
Email:
Área de Informática
Jefe de proyecto:
Teléfono:
Email:
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
CONTROL DE VERSIONES
LISTA DE DISTRIBUCIÓN
Página 2 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
Índice
Página 3 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
La segunda parte del documento contiene los resultados obtenidos de la realización de las pruebas
2. DOCUMENTOS RELACIONADOS
< En esta sección se enumeran los documentos relacionados con la implantación del sistema. Siempre se
hará referencia como mínimo al Análisis Funcional, peticiones de cambio (que impliquen ampliaciones
funcionales) y al Procedimiento de Planificación, diseño y ejecución de pruebas que aplique. >.
Nombre Descripción
Página 4 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
Sección
I
PLAN DE PRUEBAS
Página 5 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
<En este apartado se definen las dependencias y otras consideraciones de entorno relacionadas con las
prueba>
3.2. RESPONSABILIDADES
<La siguiente tabla resume cada una de las pruebas que se detallarán posteriormente así como su tipo y
quien debe realizar las pruebas >
<En este apartado se define el alcance de las pruebas unitarias que va a realizar el equipo de de sarrollo, así
como las herramientas que, en su caso, se utilicen para el diseño y/o ejecución de las mismas. Estas pruebas
pueden ser de caja negra o de caja blanca y se suelen enfocar en comprobar el funcionamiento correcto de
pantallas y métodos
Las pruebas unitarias se ejecutarán durante la codificación del sistema para verificar, principalmente:
Mantenimientos de entidades de negocio.
Generación de informes.
Pantallas.
Autenticación.
Autorización.
>
<En este apartado se describen las herramientas que se usarán en el proyecto para las pruebas unitarias:
hojas excel, etc.>
El Alcance de las Pruebas Funcionales que se van a realizar (en casos de uso).
Página 6 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
Planificación de las iteraciones en las que se diseñan y ejecutan las pruebas, así como el grado de
criticidad para dimensionar el esfuerzo de diseño y ejecución de pruebas.
Las tareas que realizará el Grupo de Pruebas.
Las condiciones que se deben cumplir para el comienzo y finalización de las pruebas.
Las herramientas de gestión y técnicas utilizadas para diseño y ejecución de las pruebas.
>
<En este apartado se identifica el alcance de las Pruebas Funcionales a partir del esfuerzo de pruebas
inicialmente previsto. A partir de este alcance, el Equipo de Desarrollo o el Grupo de Pruebas diseñará los
casos de pruebas que guiarán la ejecución de las pruebas. El alcance de las pruebas hará referencia a los
casos de uso especificados en el Análisis Funcional. Para equilibrar el esfuerzo de las pruebas, se indicará una
criticidad para cada caso de uso: Alta, Media, Baja, en función de la cual, se diseñarán más o menos casos de
prueba. Las criticidades por defecto serán Medias>.
<Este apartado podrá modificarse cada vez que se comience una iteración y se planifiquen pruebas
funcionales en la misma>.
Iteración Nº 1
Caso de Uso Descripción Criticidad
Iteración Nº 2
Caso de Uso Descripción Criticidad
Iteración Nº n
Caso de Uso Descripción Criticidad
5.2. HERRAMIENTAS
<En este apartado se identifican las herramientas de gestión y técnicas que se utilizarán en las pruebas
funcionales (p.e. TestLink, Bugzilla, etc.)>
Página 7 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
Las pruebas estructurales de integración son similares a las pruebas de caja blanca; pero trabajan a un nivel
conceptual superior. En lugar de referirnos a sentencias del lenguaje, nos referiremos a llamadas entre
módulos. Se trata pues de identificar todos los posibles esquemas de llamadas y ejercitarlos para lograr una
buena cobertura de segmentos o de ramas.
<En este apartado se identifica el alcance de las pruebas de integración. Deberán definirse sobre todos los
modulos que componen el sistema teniendo en consideración el entorno en el que finalmente serán
desplegados >.
6.4. HERRAMIENTAS
<En este apartado se identifican las herramientas de gestión y técnicas que se utilizarán en las pruebas de
rendimiento, carga y stress (p.e. JMeter,)>
<un test de carga se ejecuta para comprender el comportamiento deun sistema ante una carga determinada.
Esta carga puede ser el número de usuarios esperado en producción o un número de transacciones durante un
tiempo determinado. El resultado de esta prueba nos dará el tiempo de respuesta de todas las transacciones
críticas. Se debén identificar los cuellos de botella que pudieran existir >.
<Estas pruebas son utilizadas normalmente para someter a la aplicación al límite de su funcionamiento
mediante la ejecución de un número de usuarios muy superior al esperado, o bien median la substracción de
recursos (también conocidas como pruebas negativas donde se simula por ejemplo el fallo de un servidor en
cluster). Este "test de stress" tiene como finalidad el determinar la robustez de una aplicación cuando la carga
es extrema y ayuda a administradores a determinar los humerales de configuración de las alarmas de sistema
entre otras cosas. En este tipo de pruebas los tiempos de respuesta de la aplicación no son importantes y
Página 8 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
tienden a ser ignorados. Otro posible objetivo de este tipo de pruebas es determinar el límite real de la
aplicación en cuanto a número de usuarios concurrentes, numero de transacciones por segundo, etc...>.
<Este test se realiza con el fin de determinar si la aplicación puede mantener la carga esperada de manera
contínua y durante un largo tiempo. El objetivo principal de este tipo de pruebas es verificar que no existen
fugas de memoria o procesos que pierdan rendimiento tras un cierto periodo de tiempo.>.
< Este tipo de pruebas se realizan insertando la carga en el sistema en forma de “picos” que se irán lanzando
en distintos momentos de la prueba y que permitirán comprender el comportamiento de la aplicación ante
cambios bruscos de carga>.
7.5. HERRAMIENTAS
<En este apartado se identifican las herramientas que se utilizarán en los diferentes tipos de prueba de
rendimiento (p.e. JMeter,)>
<En este apartado se identifica el alcance de las pruebas de seguridad. Se tendrá en cuenta el entorno en el
que finalmente serán desplegados y los estandares de seguridad del gobierno. Consultese el aapartado de
diagrama de arquitectura amap.cantabria.es>.
8.2. HERRAMIENTAS
<En este apartado se identifican las herramientas que se utilizarán para la gestión y realización de las
pruebas de seguridad>
<En este apartado se identifica el alcance de las pruebas de usabilidad el plan incluirá como mínimo:
Exactitud: Número de errores cometidos por los sujetos de prueba y si estos fueron recuperables o no al usar
los datos o procedimientos adecuados.
Tiempo requerido para concluir la actividad.
Respuesta emocional: Cómo se siente el usuario al terminar la tarea (bajo tensión, satisfecho, molesto,
etcétera).>
Página 9 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
9.2. HERRAMIENTAS
<En este apartado se identifican las herramientas que se utilizarán para la gestión y realización de las
pruebas de usabilidad>
10.2. HERRAMIENTAS
<En este apartado se identifican las herramientas que se utilizarán para la gestión y realización de las
pruebas de usabilidad
Se deberán utilizar las herramientas proporcionadas por la WAI del W3C para la detección de problemas de
accesiblidad para poder detectar y corregir las deficiencias de accesibilidad detectadas:
http://www.w3.org/WAI/ER/tools/
El informe del resultado será adjuntado al apartado de resultados de las pruebas de la sección II/>
Página 10 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
Sección
II
RESULTADOS DEL PLAN DE PRUEBAS
Página 11 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
PROCEDIMIENTO DE PRUEBA
Actor Sistema
<Describir paso a paso las instrucciones para
<Respuesta esperada del sistema>
ejecutar el caso de prueba.>
RESULTADO OBTENIDO
Cumple Comentario
Si No <Se describe el resultado esperado, adjuntando pantallazos si es necesario>
Página 12 de 13
Fecha: Versión:
Autor:
Documento: DPR Documento de pruebas.
Proyecto:
Página 13 de 13