Instituto Tecnológico Superior de Escárcega

- Ingeniería en Sistemas Computacionales -

Docente: Ing. Juan Carlos Díaz López

Materia: Ingeniería de software

Grupo: ISMA-6
Semestre: Sexto

Plan de pruebas

Alumnos:

- Johan Jared Chay Chin

- Silverio Arias López

- Darwin Jesús Zetina Centeno

- Danni Ezequiel Castillo López

- Monica Uicab Reyes

- Jesús Alfredo Garcia Chuc

- Araceli López Hernandez

- Johan David de la cruz Palmer

- Julissa Vidaura Mujica Flores

- Jerwin Ali Contreras Reyes

- Christian Alexis Solis Perez

HOJA RESUMEN DE MODIFICACIONES 3

1. INTRODUCCIÓN 3
1.1. OBJETIVOS DEL PLAN DE PRUEBAS 3
1.2. DOCUMENTOS RELACIONADOS 3

2. ALCANCE DE LAS PRUEBAS 3

2.1. CUADRO RESUMEN DE LAS PRUEBAS 3
2.2. REQUERIMIENTOS DE PRUEBAS EXCLUIDOS 3
2.3. CASOS DE PRUEBAS INCLUIDOS 3
2.4. CASOS DE PRUEBAS EXCLUIDOS 3

3. ENTORNO Y CONFIGURACIÓN DE LAS PRUEBAS 3

3.1. CRITERIOS DE INICIO 4
3.2. BASES DE DATOS DE PRUEBAS 4
3.3. CRITERIOS DE APROBACIÓN / RECHAZO 4

4. ESTRATEGIA DE PRUEBAS 4
4.1. ESCENARIO DE LAS PRUEBAS 5
4.2. ORDEN DE EJECUCIÓN DE PRUEBAS 5
4.3. EQUIPO DE PRUEBAS Y RESPONSABILIDADES 5
HOJA RESUMEN DE MODIFICACIONES
1. INTRODUCCIÓN
Proyecto(s) Tipo de Proyecto

Proyecto Sistema de Gestión de Inventario Proyecto de Desarrollo de Proyecto

para el Área de Energías Renovables. Integrador

Documentos Evaluación relacionados

● Informe Tecnico

Equipo de Proyecto

Jefe de Equipo Darwin Jesús Zetina Arquitecto de Johan Jared Chay

Centeno Producto Chin

1.1. OBJETIVOS DEL PLAN DE PRUEBAS

Este documento tiene como finalidad verificar la funcionalidad de cada uno de los módulos
desarrollados y monitorear que los préstamos que se realicen en el inventario sean
guardados correctamente en la base de datos y poder realizar modificaciones de cada una
de las herramientas y que los alumnos que deseen hacer el préstamo realicen
correctamente las indicaciones y puedan guardar su información sin errores.

El objetivo general es poder monitorear cada uno de los usuarios y sus préstamos y poder
observar que al momento de que los alumnos realicen un préstamo de herramienta pueda
guardarse en el inventario correctamente, donde el administrador monitorea y modifica los
préstamos y realizar observaciones de que cada apartado del inventario funcione y no tenga
errores.

1.2. DOCUMENTOS RELACIONADOS

Nombre Descripción Ruta en blog(URL)

Informe de Informe Técnico https://docs.google.com/document/d/1

Técnico Versión ArPM_bMaZnCk0hrk1a_mM37B-Bzcy
1.0 qd5l2RztN0sFaM/edit?usp=sharing

Informe de Informe de Análisis y

Análisis y Diseño Diseño
v.1.1

2. ALCANCE DE LAS PRUEBAS

Mediante los siguientes cuadros se describen los requerimientos de pruebas del sistema
para determinar qué funcionalidades del software serán probadas durante el transcurso de
la prueba.
Este listado de funcionalidades a probar se extrae con base a un análisis de riesgos
realizado de manera previa, que tienen en cuenta variables tales como el impacto que
podría ocasionar la falla de una funcionalidad ya que se cuenta con información adicional
que permite determinar además del alcance detallado del proceso de pruebas, la prioridad
con la que las funcionalidades deben probarse y la profundidad de las pruebas.

2.1. CUADRO RESUMEN DE LAS PRUEBAS

Módulos del sistema a ser probados Módulos:

Gestión de productos.
Gestión de usuarios.
Gestión de préstamos.
Gestión de reportes.

Objetivos de las pruebas En estos módulos se realizarán pruebas

para validar:
El objetivo general es poder monitorear
cada uno de los usuarios y sus préstamos
y poder observar que al momento de que
los alumnos realicen un préstamo de
herramienta pueda guardarse en el
inventario correctamente, donde el
administrador monitorea y modifica los
préstamos y realizar observaciones de que
cada apartado del inventario funcione y no
tenga errores.

Detalle del orden de ejecución de los Los módulos se deben ejecutar en forma
módulos independiente, pero consecutivos en el
orden siguiente:
Gestión de productos:
-Sección de productos
-Código interno
-Código institucional
-Foto
-Observaciones
Gestión de usuarios:
-Matricula
-Nombre
-Historial de préstamos
Gestión de préstamos:
-Código de producto
-Cantidad
-Artículo o material
-Fecha de devolución
Gestión de reportes:
-Usuarios
 -Productos
-Préstamos
-Fecha

Responsabilidad de la prueba Las pruebas son responsabilidad de los

integrantes, quienes en conjunto con el
usuario deben seleccionar las pruebas que
aseguren la efectividad del sistema.

2.2. REQUERIMIENTOS DE PRUEBAS EXCLUIDOS

Nombre Nivel Descripción Tipo Criticidad (Bajo, Medio, Alto)

N/A N/A N/A N/A

2.3. CASOS DE PRUEBAS INCLUIDOS

Casos Estimado casos Tipo Módulos Total de casos

disponibles nuevos

5 1 Funcional Gestión de 5
producto

4 1 Funcional Gestión de 4
usuarios

5 3 Funcional Gestión de 5
préstamos

4 2 Funcional Gestión de 4
usuarios

18

2.4. CASOS DE PRUEBAS EXCLUIDOS

N/A En la etapa de pruebas se llegó también a la parte de casos de pruebas excluidas, esto
con el fin de verificar el cumplimiento de los requisitos especificados, cuáles son las pruebas
que no han garantizado con éxito la correcta funcionalidad del proyecto.
En algunos casos sirve para validar al usuario si ha cumplido con las expectativas o
pruebas, para comenzar o reanudar el proceso de producción.
 # Casos # Estimado de Tipo Módulo
Disponibles Casos nuevos

N/A N/A N/A N/A

3. ENTORNO Y CONFIGURACIÓN DE LAS PRUEBAS

Para la etapa de pruebas del proyecto se requiere una lista de recursos que estén en toda
disponibilidad.

1.- Servidor Windows: recursos nivel software:

Equipo de cómputo: pc (3.80GHz) o laptop (1.60GHz), 4GB RAM, Windows 7 y posterior

2.- Servidor: phpMyAdmin - 2.10.0.2

3.1. CRITERIOS DE INICIO

Aceptación del plan de pruebas: Revisión y aceptación del documento que contiene los
casos de prueba 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.

Aceptación de ambiente: Revisión y aceptación del ambiente de certificación, y que este

cumpla con las condiciones de aceptación.

3.2. BASES DE DATOS DE PRUEBAS

Base de Datos: Login
Servidor BD: MySQL
Datos: Myadmin

3.3. CRITERIOS DE APROBACIÓN / 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.
 Criterio Descripción

Aprobado Se aprobará el proyecto con un 100% de

las pruebas ejecutadas pero con un 90%
de aceptación. Esto quiere decir que el
90% de las pruebas deben ser exitosas y
sin errores. El restante 10% pueden existir
errores medios o bajos, pero no graves.

Rechazado En caso de que el proyecto no cumpla con

los requisitos y módulos solicitados , el
proyecto se rechaza completo.

4. ESTRATEGIA DE PRUEBAS
Se requiere monitorear el sistema por parte del equipo de desarrolladores y por parte del
usuario al Sistema de Inventario Web para el Taller de Energías Renovables en dos etapas,
la primera en donde se va a implementar el software y los préstamos de las herramientas en
una etapa de testing y posteriormente la solución de los errores detectados. Por lo que se
debe verificar:

Primera etapa: Implementación del sistema de inventario web en el taller de energías

renovables, en donde se van a verificar la funcionalidad e igualmente se analizarán las
posibles soluciones.

Segunda etapa: Revisión y solución de los posibles hallazgos encontrados en el sistema de

inventario web para el taller de energías renovables en la etapa anterior aplicando las
posibles soluciones detectadas para el mejor funcionamiento del sistema.

Conjuntamente los sub-objetivos para los tres módulos se resumen de la siguiente forma:

● El ingreso seguro al sistema mediante un login propio tanto para el administrador

como para los usuarios.
● La creación, modificación y eliminación de registros de préstamos asociados al
proyecto en el módulo del administrador.
● La creación, modificación y eliminación de registros de herramientas asociados al
proyecto en el módulo del administrador.
● La creación, modificación y eliminación de reportes de préstamos asociados al
proyecto en el módulo del administrador.
● La gestión de préstamos de herramientas al taller de ing. energías renovables
asociadas al módulo de usuarios.

Será necesario indicar como objetivo realizar las pruebas de los módulos. Esto se refiere a
verificar y validar los resultados o salidas generadas.
4.1. ESCENARIO DE LAS PRUEBAS

Para verificar el cumplimiento de los objetivos planteados se deben de realizar por lo menos
tres escenarios existentes, los cuales son:
- Pruebas de instalación
- Pruebas de Interfaz
- Pruebas de Operación o funcionalidad

Para las pruebas de instalación se deberá de comprobar que la aplicación no presente

ningún tipo de anomalía, y que esté correctamente enlazado con el servidor y base de datos
definido.
Para las pruebas de Interfaz o GUI se debe comprobar que:
El comportamiento de la aplicación sea de manera correcta y válida, de no ser así notificar
los bordes inválidos, dando como resultado una verificación donde las pruebas de borde se
definan como pruebas cuyos datos de prueba a utilizar tengan valores límites.
- Verificar la carga, despliegue, foco, modalidad, navegabilidad, y usabilidad de
la interfaz o GUI del sistema, además de sus elementos, donde las métricas y
cálculos de usabilidad y funcionalidades utilizar tengan además:
- Comprensión global del sitio.
- Aspecto de interfaces y valor estético.
- Cálculos de confiabilidad.
- Navegación y exploración del sistema.
Para las pruebas de operación o funcionalidad se deberá de comprobar:
- El comportamiento de la aplicación en casos que sean válidos y además de casos
que sean inválidos para que estos sean excluidos del sistema por el proceso de
propuestas.
- El comportamiento de la aplicación en ambos casos, tanto válidos como inválidos,
para verificar el flujo del proceso de generación de la aplicación.
- El comportamiento de la aplicación en los casos en cuestion de actividades
relacionadas a las propuestas hechas en el proyecto.
- El comportamiento de la aplicación para el módulo de Proyectos.
- El comportamiento de la aplicación para el módulo de Revisión.
- El comportamiento de la aplicación para el módulo de Aprobación.

4.2. ORDEN DE EJECUCIÓN DE PRUEBAS

Las serán realizadas en el siguiente orden:

Secuencias de pasos para la configuración:

1.- Instalación en el equipo central que almacenará el sistema
2.- Configuración del servidor y sistema web
Secuencias de pasos para la generación de datos en los ocho módulos:

MÓDULOS DE ADMINISTRADOR
● Inicio
● Gestión de productos
● Gestion de usuarios
● Gestión de Reportes
● Préstamos

MODULOS DE USUARIO
● Inicio
● Gestion de prestamos
● Consultas de artículos

4.3. EQUIPO DE PRUEBAS Y RESPONSABILIDADES

Nombre Responsabilidad

Responsable de los criterios de aprobación y

Johan Jared Chay Chin rechazo.

Responsable del plan de pruebas.

Silverio Arias López

Darwin Jesús Zetina Centeno Jefe de proyecto, responsable de repartir

trabajos y evaluarlos.

Responsable de criterios de inicio y

Danni Ezequiel Castillo López estrategias de la prueba.

Monica Uicab Reyes Responsable de las pruebas y la elaboración

del resumen en cuadro.

Responsable de los casos de pruebas

Jesús Alfredo Garcia Chuc incluidos.

Araceli López Hernandez Responsable del entorno y configuración de

las pruebas y de la orden de ejecución de las
pruebas.

Responsable de investigar documentación

Johan David de la cruz Palmer relacionada.
Julissa Vidaura Mujica Flores Responsable de las pruebas de base de
datos y la elaboración del equipo de pruebas
y responsabilidades que se otorgan.

Responsable de la introducción y
Jerwin Ali Contreras Reyes requerimiento de pruebas excluidas.

Responsable de caso de pruebas excluidas y

Christian Alexis Solis Perez escenario de las pruebas que se realicen.