Plan de Pruebas Maestro

PROCESO
Ciclo de Desarrollo de Software

Ingeniería de Software
Documento Plan Maestro de pruebas (PMP)
PLAN MAESTRO DE PRUEBAS

INGENIERÍA DE SOFTWARE
VERSIÓN 1.0
399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

Página 1 de 33
PROCESO
HOJA RESUMEN DE MODIFICACIONES
VERSIÓ FECHA PUNTO CAMBIOS RESPECTO DE PREPARADO APROBADO

N LA VERSIÓN ANTERIOR POR POR
1.0 18/06/2017 Versión Inicial Yaranga Quispe
Alexander
1.1 24/07/2017 Versión Secundaria Yaranga Quispe
Alexander

Página 2 de 33
PROCESO
INDICE
HOJA RESUMEN DE MODIFICACIONES.....................................................................................2
1. INTRODUCCIÓN.........................................................................................................................4
1.1. OBJETIVOS DEL PLAN DE PRUEBAS..............................................................................4
1.2. DOCUMENTOS RELACIONADOS.....................................................................................5
2. ALCANCE DE LAS PRUEBAS..................................................................................................5
2.1. CUADRO RESUMEN DE LAS PRUEBAS..........................................................................5
2.2. CASOS DE PRUEBAS INCLUIDOS....................................................................................6
3. ENTORNO Y CONFIGURACIÓN DE LAS PRUEBAS..........................................................6
3.1. CRITERIOS DE INICIO........................................................................................................7
3.2. BASES DE DATOS DE PRUEBAS.......................................................................................7
3.3. CRITERIOS DE APROBACION / RECHAZO.....................................................................7
4. ESTRATEGIA DE PRUEBAS.....................................................................................................8
4.1. ESCENARIO DE LAS PRUEBAS........................................................................................8
4.2. ORDEN DE EJECUCIÓN DE PRUEBAS.............................................................................9
4.3. EQUIPO DE PRUEBAS Y RESPONSABILIDADES.........................................................10
5 REGISTRO DE LOS RESULTADOS DE LAS PRUEBAS.........................................................10
5.2 PRUEBAS DE SISTEMAS..................................................................................................18
5.2.1 PRUEBAS FUNCIONALES..............................................................................................18
5.2.2 PRUEBAS DE INTEGRACIÓN........................................................................................18
5.3 PRUEBAS DE ACEPTACIÓN.............................................................................................19
5.3.1 PRUEBAS DE USABILIDAD...........................................................................................19
5.3.2 PRUEBAS ALFA...............................................................................................................21
7. RESTRICCIONES QUE AFECTAN EL PROCESO DE PRUEBAS....................................24
8. ANEXOS......................................................................................................................................25

Página 3 de 33
PROCESO
1. INTRODUCCIÓN
Proyecto(s) Tipo de Proyecto
Sistema de información Web para Proyecto de Desarrollo de Software

generar compras de materiales. Administracioó n de Almaceó n.
Documentos Evaluación relacionados

SRS-Especificaciones de Requerimientos de Software.doc
Equipo de Proyecto
Jefe de Yaranga Arquitecto de Donado Gaspar de la
Equipo Quispe,Alexander Producto Cruz
1.1. OBJETIVOS DEL PLAN DE PRUEBAS
El documento tiene como finalidad entregar las pautas y definir la estrategia que
se seguiraó para llevar a cabo la certificacioó n del software, Sistema de información Web
para generar compras de materiales.
El objetivo general del plan es establecer la cronologíóa y condiciones para la

aplicacioó n de las pruebas de manera de obtener, un sistema que pueda ser completado con
una recepcioó n total de los interesados y entrar en operacioó n con la totalidad de las
funciones requeridas para su funcionamiento.
Las Fases en las que se realizarán las pruebas son:
1. Planificación de las pruebas: Identificar los requisitos para las pruebas.

Desarrollar la estrategia de pruebas. Identificar los recursos necesarios para
realizar las pruebas. Generar el Plan de pruebas.
2. Diseño de las pruebas: Desarrollo de las pruebas. Identificar y describir los

casos de prueba.
3. Implementación de las pruebas: Establecer el entorno de prueba. Desarrollar

las clases de prueba, los componentes de prueba y los datos de prueba.
4. Ejecución de las pruebas: Ejecutar los casos de prueba. Evaluar la ejecucioó n del
proceso de prueba. Verificar los resultados. Investigar los resultados no
esperados. Registrar los defectos.

Página 4 de 33
PROCESO
5. Evaluación de las pruebas: Evaluar la cobertura de los casos de prueba. Evaluar

la cobertura del coó digo. Analizar los defectos. Determinar si se han alcanzado los
criterios de las pruebas. Crear los informes de evaluacioó n de las pruebas.
1.2. DOCUMENTOS RELACIONADOS
Nombre Descripción Fecha
Informe de Especificaciones de
requisitos de Junio 2017
Requisitos
software (SRS)
Informe teó cnico que
describe la
Informe metodologíóa de Julio 2017
Teó cnico desarrollo y el
anaó lisis de los
procesos.
2. ALCANCE DE LAS PRUEBAS
Contar con una guíóa debidamente organizada para la aplicacioó n del plan de pruebas, la cual
seraó de suma importancia en la culminacioó n exitosa del Sistema de información Web para
generar compras de materiales.
Mediante los siguientes cuadros se describen los requerimientos de pruebas del

sistema, incluidos y excluidos en la presente certificacioó n del mismo.
2.1. CUADRO RESUMEN DE LAS PRUEBAS
Módulos del Sistema de

información Web para Módulo de Autenticación de Usuario:
generar compras de
materiales. - Sub. Moó dulo: Autenticacioó n (Iniciar Sesioó n)
.a ser probados: - Sub. Moó dulo: Recuperacioó n (¿Olvido su Contrasenñ a?)
Modulo para la búsqueda de Materiales
- Buó squeda de materiales faltantes y existente
Módulo de Registro:
- Sub. Moó dulo: Registrar los datos de los usuario

Página 5 de 33
PROCESO
cuando no estaó n registrados (Registrar Datos)

- Registrar los materiales que se estaó n registrando
para la compra (Registrar Materiales).
Módulo de Procesos:
- Sub. Moó dulo: Consulta de Productos(Consultar )
En estos Módulos se realizarán pruebas para validar:
La visualizacioó n de los datos, ingresados o modificados.

La respuesta y realizacioó n de los procesos de cada
Objetivos de las Pruebas moó dulo.
Que los estados de las actividades y documentos
generados en el sistema se reflejen de acuerdo a la
secuencia loó gica requerida por el usuario.
Los módulos se deben ejecutar en forma

independiente, pero consecutivos en el orden
siguiente:
- Iniciar Sesioó n
Detalle del orden de - Olvido contrasenñ a
ejecución de los módulos
- Registrar Datos
- Registro de Buó squeda
- Registro de Materiales
- Consulta de Productos
Las pruebas son responsabilidad del equipo de proyecto,
Responsabilidad de la
quien en conjunto con el usuario deben seleccionar las
Prueba
pruebas que aseguren la efectividad del sistema.
2.2. CASOS DE PRUEBAS INCLUIDOS

Página 6 de 33
PROCESO
# Casos # Estimado Casos Tipo Modulo Total de

Disponibles Nuevos Casos
14 N/A Funciona Informativo 5
5
3. ENTORNO Y CONFIGURACIÓN DE LAS PRUEBAS
Para el proceso de pruebas del proyecto se requiere de la disponibilidad de los

siguientes entornos:
a. Equipos Cliente: Equipos de Prueba.
 Equipo marca DEL, 1.80 GHz Windows Server 2008 2 GB RAM Pentium 5
b. Base de Datos de servidor local XAMPP que reside en equipo de servidor de Pruebas.
Todos ellos configurados por el equipo de proyecto.
3.1. CRITERIOS DE INICIO
Aceptación del plan de pruebas: Revisioó n y aceptacioó n del documento que contiene los
casos de pruebas para la certificacioó n del proyecto.
Aceptación de paquetes: Revisioó n y aceptacioó n de los paquetes de desarrollo, y que
este cumpla con las condiciones de aceptacioó n.
Aceptación de ambiente: Revisioó n y aceptacioó n del ambiente de certificacioó n, y que
este cumpla con las condiciones de aceptacioó n.
3.2. BASES DE DATOS DE PRUEBAS
Base de Datos : Compras
Servidor BD : MySQL
Datos : Aleatorios

Página 7 de 33
PROCESO
3.3. CRITERIOS DE APROBACION / RECHAZO
Errores Graves: Informacioó n críótica presentada erroó neamente o incompleta, informacioó n

mal registrada en la base de datos, caíódas de programas, incumplimiento de objetivos en
funciones principales.
Errores Medios (comunes): Errores en documentos impresos que se entregan a

personas ajenas a la organizacioó n, errores en presentacioó n de datos, incumplimiento de
objetivos, caíódas de programas auxiliares como el servidor.
Errores Leves: Errores en presentacioó n de datos, comportamientos correctos pero

diferentes en situaciones similares, dificultades de operacioó n.
Nombre Descripción
El proyecto se implementara con un 100% de las
aprobaciones de las pruebas ejecutadas, este
sistema podraó ser implantado con un 90% de
competicioó n teniendo asíó un 10% de errores
1 leves,
Estos errores no perjudican la integracioó n del
sistema, en caso de que el sistema no cumpla con
las funciones requeridas se realizaran las
pruebas de cada moó dulo.
4. ESTRATEGIA DE PRUEBAS
Se requiere certificar por parte del equipo de desarrollo y por parte del usuario el
Sistema de información Web para generar compras de materiales, en dos etapas,
que administre y gestione los procesos establecidos. Por ende se debe verificar:
 1ra. Etapa: Que las funcionalidades de los moó dulos de Anaó lisis, Disenñ o y
Desarrollo sean cumplidos.
 2da. Etapa: Que las funcionalidades integradas de los moó dulos de Anaó lisis, Disenñ o
y Desarrollo sean cumplidas.
 Conjuntamente los sub-objetivos para los cuatro moó dulos se resumen de la
siguiente forma:
o El anaó lisis de propuestas teó cnicas y sus procesos asociados.
o La integracioó n de los diversos sistema para el componente de informacioó n.

Página 8 de 33
PROCESO
o La creacioó n, modificacioó n y eliminacioó n de tareas (actividades) del sistema.

o La revisioó n y aprobacioó n de los procesos de cada moó dulo.
o Que los documentos y actividades se generen con su estado
correspondiente en el sistema.
Seraó necesario indicar como objetivo realizar las pruebas de los moó dulos para la gestioó n
y administracioó n del sistema. Esto se refiere a verificar y validar los resultados o salidas
generados.
4.1. ESCENARIO DE LAS PRUEBAS
Para cumplir con los objetivos planteados deben existir tres escenarios, que son,
Pruebas de Instalacioó n, Pruebas de Componentes, Pruebas de Interfaz y Pruebas de
Operacioó n o Funcionales.
Para las Pruebas de Instalación se debe comprobar que:

 Aplicacioó n no presenta anomalíóas o errores.
 Que apunta al servidor y base de datos definidos.
Para las pruebas de Componentes se debe:

 Verificar el Moó dulo de Autenticacioó n de Usuario, Sub.Moó dulo: Autenticacioó n
(Iniciar Sesioó n), para lo que se introducen los datos aleatoriamente.
 Verificar el Moó dulo de Autenticacioó n de Usuario, Sub. Moó dulo: Recuperacioó n

(¿Olvido su contrasenñ a?), para lo que se hacen peticiones para distintos
usuarios registrados y no registrados.
 Verificar el Moó dulo de Nuevo Usuario, Sub Modulo: Ingresar (Nuevo Usuario),
para el ingreso de un nuevo usuario.
 Verificar el Modulo de la Buó squeda de Productos: Buscar(Buscar el Producto

Faltante), para buscar un producto y luego generar la compra.
 Verificar el Moó dulo Registro, Sub. Moó dulo: Inclusioó n (Registrar los datos de
materiales ingresados), para lo que se introducen los materiales de datos
ingresados aleatoriamente.
 Verificar el Moó dulo Procesos, Sub. Moó dulo: Consulta de Productos (Consultar
Productos), para que realice una consulta a los proveedores.
Para las pruebas de interfaz se debe comprobar:

Página 9 de 33
PROCESO
 Comportamiento de la aplicacioó n con diversos navegadores, verificacioó n de

imaó genes en el sistema y de los enlaces principales.
 Carga, despliegue, foco, modalidad, navegabilidad y usabilidad de la interfaz del
Sistema y sus elementos. Donde las meó tricas y Heuríósticas de usabilidad y
funcionalidad a utilizar son las siguientes:
o Comprensioó n Global del Sitio.
o Aspectos de Interfaces y Esteó ticos.
o Meó tricas de confiabilidad.
o Navegacioó n y Exploracioó n.
Para las pruebas de Operacioó n o Funcionales se debe comprobar:

 El comportamiento de aplicacioó n con casos invaó lidos y vaó lidos, de flujo completo
del proceso de las propuestas y proyectos.
 El comportamiento de aplicacioó n con casos invaó lidos y vaó lidos, de flujo completo
del proceso de los documentos generados por el usuario.
 El comportamiento de la aplicacioó n para el moó dulo de Anaó lisis.
 El comportamiento de la aplicacioó n para el moó dulo de Disenñ o y desarrollo.
 El comportamiento de la aplicacioó n para el moó dulo de Implementacioó n.
4.2. ORDEN DE EJECUCIÓN DE PRUEBAS
Las pruebas se llevaraó n a cabo de la siguiente forma:
a. Secuencias de pasos para la Configuración

Configuracioó n de los Equipos Cliente y del Servidor de Aplicacioó n Web y de Base de
Datos.
b. Secuencias de pasos para la generación de archivos para los tres
módulos.
Ejecucioó n de proceso de entrada y de salida del sistema para su aprobacioó n.
c. Secuencias de pasos para la generación de datos para los tres módulos.

Ejecucioó n del procesos de generacioó n de datos, para las pruebas de almacenamiento
de la misma.

Página 10 de 33
PROCESO
4.3. EQUIPO DE PRUEBAS Y RESPONSABILIDADES
Nombre Responsabilidad
Alexander Arquitecto de sistema, responsable de evaluar las
condiciones de teó rmino para el proceso de pruebas junto al
Jefe de Proyectos.
Smith Jefe de Proyecto, responsable de evaluar las condiciones de
teó rmino para el proceso de pruebas junto al Arquitecto de
Producto.
Carlos Analista funcional, responsable de la resolucioó n de las
incidencias de certificacioó n para los moó dulos de Anaó lisis,
Disenñ o y Desarrollo y aprobacioó n.
Alexander
Smith Responsable de la generacioó n del plan de pruebas.
Carlos
5 REGISTRO DE LOS RESULTADOS DE LAS PRUEBAS.
En esta seccioó n se muestran rigurosa y sistemaó ticamente los resultados arrojados por cada
prueba. Para ello, ya se han definido los escenarios en el punto 4.1. En tal sentido, los
resultados obtenidos se clasifican seguó n:
5.1. PRUEBAS DE COMPONENTES
Cuadro Nº 1. Módulo de Autenticación de Usuario, Sub. Módulo: Iniciar Sesión

Página 11 de 33
PROCESO
Casos de prueba Formato de casos de pruebas
Tipo de prueba: Unitaria (Caja Blanca)
Objetivo: Validar los datos de un usuario para accesar a

la aplicación
Caso No. 1
Descripcioó n: Datos incorrectos: Nombre de Usuario con

caracteres no permitidos.
Entradas: Nombre de Usuario: ¿”0001/yoselin

Contrasenñ a: “…….. ”
Coó digo de salidas esperadas: defined (‘Resricted

access’)=El nombre de usuario y contrasenñ a no coinciden o
usted no tiene cuenta auó n
Resultados Todos los casos de pruebas planificados se han ejecutado.

Todos los defectos identificados se han considerado.
Observaciones El resto de los casos de prueba para eó ste componente se

presenta en el anexo Nº 1
Cuadro Nº 2. Módulo de Registro, Sub. Módulo: Inclusión (Registrar

Usuario)
Objetivo de la prueba Comprobar el modulo de Registro, Sub. Módulo:

Inclusión (Registrar Usuario)
Técnica Realizar registros de equipos con campos vacíóo y erroó neos.
Coó digo involucrado <?php
//conectamos Con el servidor
$conectar=@mysql_connect('localhost','root','');
//verificamos la conexion
if(!$conectar){
echo"No Se Pudo Conectar Con El Servidor";
}else{

Página 12 de 33
PROCESO
$base=mysql_select_db('web_triage');
if(!$base){
echo"No Se Encontro La Base De Datos";
}
}
//recuperar las variables
$dni=$_POST['dni'];
$Nombre=$_POST['Nombre'];
$Apellido=$_POST['Apellido'];
$Edad=$_POST['Especialidad'];
$Sexo=$_POST['Turno'];
$Peso=$_POST['Dia'];
$Talla=$_POST['Comentario'];
//hacemos la sentencia de sql

$sql="INSERT INTO medico VALUES('$dni',
'$Nombre',
'$Apellido',
'$Especialidad',
'$Turno',
'$Dia',
'$Comentario')";
//ejecutamos la sentencia de sql
$ejecutar=mysql_query($sql);
//verificamos la ejecucion
if(!$ejecutar){
echo"Hubo Algun Error";
}else{
echo"Datos Guardados Correctamente<br><a
href='generic.html'>Volver</a>";
}

Página 13 de 33
PROCESO
?>
Caso de prueba Formato de casos de pruebas
Objetivo: Validar los datos para el registro de

equipo
Caso No. 1
Descripcioó n: Datos incorrectos: Campos vacíóos o

erroó neos
Entradas: “ Registrar DNI, Nombre, Apellido, Fecha de

Nacimiento, Departamento, Correo”
Coó digo de salidas esperadas: <?php

if(!isset($_GET['res'])){
}else{
if($_GET['res']==1){?>
<script>
alert("Registro Exitoso");
</script>
<?php
}else if ($_GET['res']==2){?>
<script>
alert("A Ocurrido un Error al Regitrar La
Herramienta");
</script>
<?php
}
}
?>
Mensaje de error: Ha ocurrido un error al registrar la
herramienta
Resultado Todos los casos de pruebas planificados se han ejecutado.
Observaciones
Cuadro Nº 3. Modulo para la búsqueda de Materiales (Búsqueda de

materiales faltantes y existente)

Página 14 de 33
PROCESO
Objetivo: Validar los datos de una búsqueda de

productos para accesar a la aplicación
Caso No. 1
Descripcioó n: Datos incorrectos: Nombre y coó digo de los

Productos.
Entradas: Nombre de Producto: ”Leche “

Coó digo:”f102d ”
Coó digo de salidas esperadas: defined (‘Resricted

access’)=El coó digo y nombre del producto no coinciden o
usted no tiene lo tiene guardado.
Resultados Todos los casos de pruebas planificados se han ejecutado.

Observaciones
Cuadro N° 4. Módulo de proceso, Sub. Módulo: Consulta los

productos existente (Consultar los productos)
Objetivo de prueba Comprobar el Módulo de proceso, Sub. Módulo:

Consulta (Consultar equipo)
Técnica Solicitar reportes con o sin registros realizados
Código involucrado <!DOCTYPE html>
<html lang="es">
<head>
<title> validacion de Formulario</title>
<style media="screen">
form
{
width: 25%;

Página 15 de 33
PROCESO
margin: 0 auto;
}
form label
{
display: block;
}
body
{
background:url(bg.png) #AF94AE;
background-position:center;
}
form textarea
{
width: 100%;
height: 80px;
}
form input[type="submit"]
{
float: right;
}
</style>
<script>
function validacion (id) {
var
elem=document.getElementById(id);
if(elem.checkValidity())
elem.style.borderColor="blue";
else
elem.style.borderColor="red"
}
function enviado()

Página 16 de 33
PROCESO
{
var nombreValido=
document.getElementById('nombre').checkValidity();
var emailValido=
document.getElementById('email').checkValidity();
var ApellidoPaternoyMaternoValido=
document.getElementById('Appellidos').checkValidity();
var ProductosValido=
document.getElementById('Productos').checkValidity();
var CantidadValido=
document.getElementById('Cantidad').checkValidity();
if (nombreValido && emailValido
&ApellidoPaternoyMaternoValido &&ProductosValido
&&CantidadValido)
alert("LA INFORMACION FUE
ENVIADO CON EXITO ...")
else
alert("por favor revise sus
campos")
}
</script>
</head>
<body>
<form name="contactenos" method="post"
action="#">
<fieldset>
<p>
</p>
<legend>Ingrese los Datos</legend>
<section>
<label for="nombre">Nombre*</label>
<input type="text" name="nombre"
placeholder="escriba su nombre"
oninput="validacion('nombre')" required pattern="([A-Z ]
{5, 20})" maxlength="20" />
</section>

Página 17 de 33
PROCESO
<section>
<label for="Apellido Paterno y Materno
">Apellido Paterno y Materno*</label>
<input type="text" name="Apellido Paterno y
Materno" placeholder="escriba su Apellido"
oninput="validacion('Apellidos')" required pattern="([A-Z ]
{5, 20})" maxlength="20" />
</section>
<section>
<label for="Producto">Producto*</label>
<input type="text" name="Producto"
placeholder="escriba el producto"
oninput="validacion('Producto')" required pattern="([A-Z ]
{5, 20})" maxlength="20" />
</section>
<section>
<label for="Cantidad">Cantidad*</label>
<input type="text" name="Producto"
placeholder="123" oninput="validacion('Cantidad')"
required maxlength="20" />
</section>
<section>
<label for="email">Email*</label>
<input type="email" name="email" id="email"
placeholder="example@example.com"
oninput="validacion('email')" required maxlength="20" />
</section>
<section>
<label for="comentario">Comentario</label>
<textarea name="comentario"></textarea>
</section>
<section>
<input type="submit" name="" value="Enviar
Comentario" onclick("enviado()")/>
</section>
</fieldset>

Página 18 de 33
PROCESO
</form>
</body
Objetivo: Validar las consultas
Caso No. 1
Descripcioó n: Campos vacíóos
Entradas: “Ingresar Nombre, coó digo, cantidad, email,

comentario”.
Coó digo de salidas esperadas: <?php
}
else
{
$fila=mysql_fetch_array($resultado);
if (!$fila)
{
echo "Datos No Existentes";
}
else
{?>Mensaje de error: Datos No Existentes
Resultado Todos los casos de pruebas planificados se han ejecutado.
Observaciones

Página 19 de 33
PROCESO
4.4. PRUEBAS DE SISTEMAS
5.2.1 PRUEBAS FUNCIONALES
Cuadro N° 5. Módulo de Registro, Sub. Módulo:

Inclusión (Registrar Equipo)

Página 20 de 33
PROCESO
Objetivos de la Asegurar la navegacioó n correcta de la aplicacioó n, la entrada

prueba de datos, y su procesamiento.
Técnicas Ejecutar cada caso de uso y flujo del caso de uso con datos
vaó lidos e invaó lidos para verificar lo siguiente:
 Cuando se utilizan datos correctos se obtienen los
resultados esperados.
 Cuando se utilizan datos incorrectos se obtienen los
mensajes de error o advertencias adecuadas.
 Cuando se haga una solicitud sin datos registrador se
obtienen mensajes de error.
Cada regla de negocio se ha aplicado correctamente.
Caso de uso Caso de uso Registro equipos
involucrado
Resultados Todas las pruebas planificadas se han ejecutado.

Todos los defectos identificados se han considerado
5.2.2 PRUEBAS DE INTEGRACIÓN
Cuadro N°6 . Módulo de Autenticación de Usuario, Sub.

Módulo: Iniciar Sesión
Objetivo de prueba  Identificar todos los posibles esquemas de llamadas

entre los componentes (Sub. Moó dulos objetos de las

Página 21 de 33
PROCESO
pruebas unitarias) y ejercitarlos para lograr una buena

cobertura de la funcionalidad del Moó dulo Completo.
Técnica Describir los esquemas loó gicos de llamadas entre

componentes en forma ascendente para verificar la
funcionalidad del moó dulo.
Interfaz Asociada
Resultado Todas las llamadas entre componentes han sido ejecutadas

con eó xito.
Cuadro N° 7. Módulo de proceso, Sub. Módulo: Consulta de

Productos existente (Consultar de producto)
Objetivo de Verificar los siguientes objetivos:

prueba
 Identificar todos los posibles esquemas de llamadas entre los
componentes (Sub. Moó dulos objetos de las pruebas unitarias)
y ejercitarlos para lograr una buena cobertura de la
funcionalidad del Moó dulo.
Técnica Describir los esquemas loó gicos de llamadas entre componentes
en forma ascendente para verificar la funcionalidad del moó dulo
de consulta

Página 22 de 33
PROCESO
Interfaz Asociada
Resultado Todas las llamadas entre componentes han sido ejecutadas con
eó xito.
4.5. PRUEBAS DE ACEPTACIÓN
5.2.3 PRUEBAS DE USABILIDAD
Cuadro N° 8. Módulo de Autenticación de Usuario, Sub.


prueba
La navegacioó n a traveó s de la aplicacioó n refleja adecuadamente las
reglas de negocio y los requisitos incluyendo ventana a ventana,
campo a campo y meó todos de acceso (tabulador, movimientos del
ratoó n y teclas de
Técnicas Crear o modificar pruebas para cada ventana con el objetivo de
verificar la correcta navegacioó n y su estado. Utilizando las Heuríósticas
de Nielsen.
Interfaz
Asociada

Página 23 de 33
PROCESO
Resultado Cada ventana se ha verificado con eó xito y es consistente con la

esperado versioó n de referencia o con los estaó ndares utilizados.
Cuadro N° 9. Módulo de Registro, Sub. Módulo:

Inclusión (Registrar Datos de Usuario)
Verificar los siguientes objetivos:

 La navegacioó n a traveó s de la aplicacioó n refleja adecuadamente las reglas
Objetivos de negocio y los requisitos incluyendo ventana a ventana, campo a
de la campo y meó todos de acceso (tabulador, movimientos del ratoó n y teclas
prueba
de funcioó n).
 Las ventanas y sus caracteríósticas, como menuó s, tamanñ o, posicioó n y
estado cumplen los estaó ndares.
Crear o modificar pruebas para cada ventana con el objetivo de verificar
Técnica
la correcta navegacioó n y su estado. Utilizando las Heuríósticas de Nielsen.

Página 24 de 33
PROCESO
Interfaz
asociada
Resultado Cada ventana se ha verificado con eó xito y es consistente con la versioó n

esperado de referencia o con los estaó ndares utilizados.
Cuadro N°10. Módulo de proceso, Sub. Módulo: Consulta

de producto existente (Consultar Producto)

prueba
 La navegacioó n a traveó s de la aplicacioó n refleja adecuadamente las
reglas de negocio y los requisitos incluyendo ventana a ventana,
campo a campo y meó todos de acceso (tabulador, movimientos del
ratoó n y teclas de funcioó n).
 Las ventanas y sus caracteríósticas, como menuó s, tamanñ o, posicioó n
y estado cumplen los estaó ndares
Técnica Crear o modificar pruebas para cada ventana con el objetivo de
verificar la correcta navegacioó n y su estado. Utilizando las
Heuríósticas de Nielsen.
Interfaz
Asociada

Página 25 de 33
PROCESO
Resultado Cada ventana se ha verificado con eó xito y es consistente con la

esperado versioó n de referencia o con los estaó ndares utilizados.
5.2.4 PRUEBAS ALFA
Cuadro N°11. Módulo de Autenticación de Usuario, Sub.

Objetivo de Asegurar la navegacioó n correcta de la aplicacioó n, y la consulta de los datos.

prueba
Técnica Ejecutar cada caso de uso y flujo del caso de uso con datos vaó lidos e invaó lido
para verificar lo siguiente:
 Cuando se utilizan datos correctos se obtienen los resultados esperados.
 Cuando se utilizan datos incorrectos se obtienen los mensajes de error
advertencias adecuadas.
 Cada regla de negocio se ha aplicado correctamente.
 Cada ventana se ha verificado con eó xito y es consistente con la versioó n d
referencia o con los estaó ndares utilizados.
Interfaz
Asociada

Página 26 de 33
PROCESO
Resultado Previsto para la versioó n 1.1 del plan de pruebas

Consideraciones Las pruebas seraó n ejecutadas en un servidor local.
Cuadro N°12 Módulo de Registro, Sub. Módulo: Inclusión

(Registrar Datos de Usuario)
Objetivo de Asegurar la navegacioó n correcta de la aplicacioó n, y la consulta de los

prueba datos.
Técnica Ejecutar cada caso de uso y flujo del caso de uso con datos vaó lidos e
invaó lidos para verificar lo siguiente:
 Cuando se utilizan datos correctos se obtienen los resultados
esperados.
 Cuando se utilizan datos incorrectos se obtienen los mensajes de error
o advertencias adecuadas.
 Cada ventana se ha verificado con eó xito y es consistente con la versioó n
de referencia o con los estaó ndares utilizados.

Página 27 de 33
PROCESO
Interfaz
Asociada

Cuadro N°13. Módulo de proceso, Sub. Módulo: Consulta

de productos existente (Consultar producto)
Objetivo de Asegurar la navegacioó n correcta de la aplicacioó n, y la consulta de los

prueba datos.
Técnica Ejecutar cada caso de uso y flujo del caso de uso con datos vaó lidos e
invaó lidos para verificar lo siguiente:
 Cuando se utilizan datos correctos se obtienen los resultados
esperados.
 Cuando se utilizan datos incorrectos se obtienen los mensajes de
error o advertencias adecuadas.
 Cada ventana se ha verificado con eó xito y es consistente con la
versioó n de referencia o con los estaó ndares utilizados.

Página 28 de 33
PROCESO
Interfaz
Asociada

6. ANÁLISIS DE LOS RESULTADOS DE LAS PRUEBAS

Los resultados a las pruebas disenñ adas para verificar y validar el producto de software
Sistema de informacioó n Web para generar compras de materiales. Se presentan tal como
ya se han definido los escenarios en el punto 4.1. En tal sentido, se elabora el siguiente
cuadro resumen, con los resultados de las pruebas y los criterios de aprobacioó n/rechazo
descritos en el apartado 3.3 de este documento..
Cuadro Nº 14 .Análisis para los resultados de las pruebas al Módulo

de Autenticación de Usuarios y Control de Citas (Componentes:
Inclusión, Autenticación, Recuperación y Consulta).
Tipo de Caso de prueba Resultado Criterio de

Pru Finalizació
eba n
Componentes Autenticacioó n
Caso 1
Caso 2
Componentes Registro
Caso 1
Caso 2

Página 29 de 33
PROCESO
Componentes Proceso
Caso 1
Caso 2
Funcionales Todos los CU han sido

probados
Integracioó n Todas las llamadas
entre componentes han
sido ejecutadas.
Interfaz de Todas las ventanas se
usuario han verificado.
(Usabilidad) Se ha verificado la
consistencia con los
estaó ndares utilizados
5. RESTRICCIONES QUE AFECTAN EL PROCESO DE PRUEBAS
El software pasaraó a las pruebas de integracioó n despueó s de que todos los errores
(Graves, Medios y Leves) han sido corregidos y el criterio de finalizacioó n resulte en:
Aprobado.
Una vez realizadas las pruebas de aceptacioó n despueó s de que todos los defectos sean
corregidos, pasaraó a las pruebas Alfa.
Finalmente, luego de conocer el criterio de aceptacioó n por parte de los usuarios
finales, el sistema podraó ser instalado en su versioó n Beta.
6. ANEXOS
Anexo N°1

Página 30 de 33
PROCESO
los expertos critican la interfaz confrontaó ndola con una guíóa de elementos
baó sicos de disenñ o elaborada previamente y, en este sentido, es una herramienta de
comparacioó n de objetivos explíócitamente estipulados. Tiene como objetivo determinar
los posibles problemas de usabilidad maó s comunes en el disenñ o de una interfaz, antes
que determinar en queó grado cumple eó sta o aquella funcioó n. Como resultado de este
tipo de evaluacioó n, se elaboran listas pormenorizadas de problemas de usabilidad, en
la que se detallan, esos problemas, la heuríóstica asociada al problema, la valoracioó n
del experto y la posible solucioó n
Para la evaluacioó n presentada se utilizaron las “10 Heuríósticas de Nielsen” y una

escala de valoracioó n para cada problema.
.Valoracioó n de los problemas y heuríósticas de Nielsen
Leyenda de
Heurísticas de Nilsen
valoración
H1: Diaó logo natural y simple
0 - No es un problema H2: Hablar el lenguaje del
de Usabilidad usuario
1 - Problema H3: Minimizar la carga
cosmeó tico cognitiva
2 - Problema menor H4: Consistencia
3 - Problema mayor de H5: Feedback
Usabilidad; importante H6: Proveer claramente las
fijar solucioó n salidas
4- Usabilidad H7: Proveer Shortcuts
catastroó fica,
Nombre del Evaluador:
imperativo fijar H8: Mensajes de Error
solucioó n descriptivos
Problema Heurística Valor Solución
H9: Prevencioó n de Errores
H10: Asistencia al Usuario

Página 31 de 33
PROCESO
Anexo 2:
Instrumento para validar el sistema.
VALORACIÓN
ASPECTOS A EVALUAR EN LA APLICACIÓN: SI MED NO
Incluye informacioó n relevante, necesaria y sencilla
Almacena exitosamente los datos registrados
Utiliza palabras, frases y conceptos familiares.
Sigue convenciones del mundo real.
Usa objetos, acciones y/o opciones para evitar que el
usuario tenga que recordar informacioó n. Ejemplos: menuó s
desplegables, metaó foras.
Provee objetos visibles e intuitivos
La composicioó n de la pantalla es la misma en toda la
aplicacioó n. Cada control tiene asignado una uó nica funcioó n

Página 32 de 33
PROCESO
y siempre es la misma
Siempre informa acerca de lo que estaó ocurriendo
Permite deshacer y rehacer acciones realizadas
Incluye acciones para hacer maó s raó pida la interaccioó n
Incluye mensajes de error expresados en un lenguaje
comuó n y sencillo, indicando el problema y sugiriendo
soluciones de forma constructiva
Incluye acciones para prevenir la existencia de errores
Incluye ayuda para asistir al usuario
Provee informacioó n referente a los datos antes registrados
Existe legibilidad y claridad textual (tipo, color y tamanñ o
adecuado de la fuente utilizada)
Existe organizacioó n adecuada del contenido y los
elementos
Nombre del
Observaciones Firma
Testing

Página 33 de 33

Plan de Pruebas Maestro

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Plan de Pruebas Maestro

Cargado por

Copyright:

Formatos disponibles

PROCESO

Ciclo de Desarrollo de Software

PLAN MAESTRO DE PRUEBAS

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

HOJA RESUMEN DE MODIFICACIONES

VERSIÓ FECHA PUNTO CAMBIOS RESPECTO DE PREPARADO APROBADO

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

HOJA RESUMEN DE MODIFICACIONES.....................................................................................2

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

Proyecto(s) Tipo de Proyecto

Sistema de información Web para Proyecto de Desarrollo de Software

Documentos Evaluación relacionados

1.1. OBJETIVOS DEL PLAN DE PRUEBAS

El objetivo general del plan es establecer la cronologíóa y condiciones para la

Las Fases en las que se realizarán las pruebas son:

1. Planificación de las pruebas: Identificar los requisitos para las pruebas.

2. Diseño de las pruebas: Desarrollo de las pruebas. Identificar y describir los

3. Implementación de las pruebas: Establecer el entorno de prueba. Desarrollar

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

5. Evaluación de las pruebas: Evaluar la cobertura de los casos de prueba. Evaluar

1.2. DOCUMENTOS RELACIONADOS

Nombre Descripción Fecha

2. ALCANCE DE LAS PRUEBAS

Mediante los siguientes cuadros se describen los requerimientos de pruebas del

2.1. CUADRO RESUMEN DE LAS PRUEBAS

Módulos del Sistema de

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

cuando no estaó n registrados (Registrar Datos)

En estos Módulos se realizarán pruebas para validar:

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

Los módulos se deben ejecutar en forma

2.2. CASOS DE PRUEBAS INCLUIDOS

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

# Casos # Estimado Casos Tipo Modulo Total de

3. ENTORNO Y CONFIGURACIÓN DE LAS PRUEBAS

Para el proceso de pruebas del proyecto se requiere de la disponibilidad de los

a. Equipos Cliente: Equipos de Prueba.

Todos ellos configurados por el equipo de proyecto.

3.1. CRITERIOS DE INICIO

3.2. BASES DE DATOS DE PRUEBAS

Base de Datos : Compras

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

3.3. CRITERIOS DE APROBACION / RECHAZO

Errores Graves: Informacioó n críótica presentada erroó neamente o incompleta, informacioó n

Errores Medios (comunes): Errores en documentos impresos que se entregan a

Errores Leves: Errores en presentacioó n de datos, comportamientos correctos pero

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

o La creacioó n, modificacioó n y eliminacioó n de tareas (actividades) del sistema.

4.1. ESCENARIO DE LAS PRUEBAS

Para las Pruebas de Instalación se debe comprobar que:

Para las pruebas de Componentes se debe:

 Verificar el Moó dulo de Autenticacioó n de Usuario, Sub. Moó dulo: Recuperacioó n

 Verificar el Modulo de la Buó squeda de Productos: Buscar(Buscar el Producto

Para las pruebas de interfaz se debe comprobar:

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

 Comportamiento de la aplicacioó n con diversos navegadores, verificacioó n de

Para las pruebas de Operacioó n o Funcionales se debe comprobar:

4.2. ORDEN DE EJECUCIÓN DE PRUEBAS

Las pruebas se llevaraó n a cabo de la siguiente forma:

a. Secuencias de pasos para la Configuración

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

399872207.doc Ingeniería de software Fecha Actualización:18/07/2017

4.3. EQUIPO DE PRUEBAS Y RESPONSABILIDADES