<Universidad Técnica del Norte>

FACULTAD DE INGENIERIA EN CIENCIAS

APLICADAS
CARRERA DE INGENIERIA EN SOFTWARE

Plan de pruebas unitarias de software

Desarrollo de la Plataforma para el Sistema

de Gestión de Riesgos Zona 1 del Ecuador
Fecha: 24-01-2022

IBARRA -2022
Tabla de contenido
Historial de versiones ......................................................................................... 5

Información del proyecto .................................................................................... 5

Aprobaciones ..................................................................................................... 5

Resumen Ejecutivo ............................................................................................ 6

Alcance de las Pruebas ......................................................................................

7

Elementos de Pruebas .................................................................................... 7

Nuevas Funcionalidades a Probar .................................................................. 9

Pruebas de Regresión .................................................................................. 10

Funcionalidades a no probar .........................................................................

11

Enfoque de pruebas (estrategia) ...................... ¡Error! Marcador no definido.

Criterios de aceptación o rechazo .................................................................... 11

Criterios de aceptación o rechazo .................................................................

11

CRITERIO ..................................................................................................... 11

DECRIPCIÓN ............................................................................................... 11

ACEPTACIÓN ............................................................................................... 11

% ................................................................................................................... 11

1 .................................................................................................................... 11

Comprobación de los sistemas que se utilizaran para el desarrollo del

proyecto ........................................................................................................ 11

CORREGIDO ................................................................................................ 11

80 .................................................................................................................. 11

2 .................................................................................................................... 11
Revisión del diseño de base de datos e implementación de modelo entidad
relación que se manejará empleará en este proyecto................................... 11
CORREGIDO ................................................................................................ 11

80% ............................................................................................................... 11

3 .................................................................................................................... 11

Asignación de módulos a los desarrolladores. ..............................................

11

CORREGIDO ................................................................................................ 11

100% ............................................................................................................. 11

4 .................................................................................................................... 11

Realizar los CRUD de las tablas establecidas para este primer esprint. ...... 11

CORREGIDO ................................................................................................ 11

100% ............................................................................................................. 11

5 .................................................................................................................... 12

Realizar la verificación y funcionamiento del mapeo de tablas mediante

eclipse y la base de datos, el mapeo contiene errores de codificación de las
llaves foráneas. ............................................................................................. 12

CORREGIDO ................................................................................................ 12

100% ............................................................................................................. 12

6 .................................................................................................................... 12

Realizar la configuración del archivo persistencia.xml en el proyecto para su

respectiva conexión a la base de dato. ......................................................... 12

CORREGIDO ................................................................................................ 12

100% ............................................................................................................. 12

7 .................................................................................................................... 12

Verificar si las librerías necesarias para el proyecto como: postgresql.jar para

la base de datos, Prime faces para el Frontend. ...........................................
12 CORREGIDO ................................................................................................
12
 100% ............................................................................................................. 12

8 .................................................................................................................... 12

Comits en el proyecto, se presentó errores para unir los proyectos desde el

sistema Linux. ............................................................................................... 12

CORREGIDO ................................................................................................ 12

100% ............................................................................................................. 12
9 .................................................................................................................... 12

Problemas de servidor Wildfly .......................................................................

12

CORREGIDO ................................................................................................ 12

80% ............................................................................................................... 12

Criterios de suspensión .................................................................................

12

Criterios de reanudación ............................................................................... 12

Entregables ...................................................................................................... 12

Recursos .......................................................................................................... 13

Requerimientos de entornos – Hardware ......................................................

13

Requerimientos de entornos – Software ....................................................... 14

Herramientas de pruebas requeridas ............... ¡Error! Marcador no

definido.

Personal ........................................................................................................ 14

Entrenamiento .................................................. ¡Error! Marcador no

definido.

Planificación y organización ............................................................................. 15

Procedimientos para las pruebas ..................... ¡Error! Marcador no

definido. Matriz de responsabilidades ............................ ¡Error! Marcador no

definido.
 Cronograma .................................................................................................. 15

Premisas .......................................................... ¡Error! Marcador no

definido.

Dependencias y Riesgos .............................................................................. 16

Referencias ...................................................................................................... 16

Glosario .............................................................................................................. 6

Historial de versiones
Fecha Versión Autor Organización Descripción
24 V1 Diego Carlosama UTN SGRE
Luis Diaz
Aguirre Guido
Patricio Vásquez

Información del proyecto

Empresa / Organización UTN
Proyecto Sistema de Gestión de Riesgos Zona 1
Fecha de preparación 24/01/2022
Cliente Coordinación Zonal 1 - Servicio Nacional de
Gestión de Riesgos y Emergencias
Patrocinador principal UTN
Gerente / Líder de proyecto Diego Carlosama

Gerente / Líder de pruebas Patricio Vásquez

de software
Aprobaciones
Nombre y Cargo Departamento u Fecha Firma
Apellido organización
Diego Carlosama Responsable UTN 07/02/2022
de proyecto

Luis Diaz Director de UTN 07/02/2022

Desarrollo
Tecnológico e
Informático
Aguirre Guido Administrador UTN 07/02/2022
de la Base de
Datos

Patricio Vásquez Desarrollador UTN 07/02/2022

Web Full
Stack.

Glosario de términos
Usuario La persona (s) que operan o actúan recíprocamente directamente
con el producto. El usuario (s) y el cliente (s) no es (son) a menudo
las mismas personas(s).

Atópico Desastres causados por el hombre en la

naturaleza/entorno donde habitan.

IEEE El Instituto de Ingenieros Eléctricos y Electrónicos

SGRE Sistema de Gestión de Riesgos

backend  Programación web en el lado del servidor (codificación).

frontend  Programación web en el lado del cliente (visualización)

CRUD Proceso de eliminado, actualizado, creado y listado de una base

de datos

ERS Especificación de Requisitos de Software

PostgreSQL También llamado PostgreSQL, es un sistema de gestión de bases

de datos relacional orientado a objetos y de código abierto,
publicado bajo la licencia PostgreSQL

UTN Universidad Técnica del Norte.

GitHub Plataforma de versionamiento de código online.

 Prime Faces Librería para el manejo de vistas.

XML Archivos/librerías que sirven para el funcionamiento de los

programas.

Wildfly Servidor para ejecutar programas web.

Heroku Servidor de bases de datos y archivado de programas online.

Comit Función de relacionar códigos en el repositorio de GitHub.

Resumen Ejecutivo
El proyecto ha sido considerado para garantizar la protección de personas y
colectividades de los efectos negativos de desastres de origen natural o
antrópico, mediante la generación de políticas, estrategias y normas que
promuevan capacidades orientadas a identificar, analizar, prevenir y mitigar
riesgos para enfrentar y manejar eventos de desastre; así como para recuperar
y reconstruir las condiciones sociales, económicas y ambientales afectadas por
eventuales emergencias o desastres.

El propósito del Plan de Desarrollo del Proyecto es proporcionar la información

necesaria para controlar el proyecto. En él se describe el enfoque de desarrollo
de la Plataforma SGRE

Los usuarios del Plan del Proyecto son:

El jefe del proyecto lo utiliza para organizar la agenda y necesidades de

recursos, y para realizar su seguimiento.

Los miembros del equipo de desarrollo lo usan para entender lo qué deben
hacer, cuándo deben hacerlo y qué otras actividades dependen de ello.

Este plan de desarrollo del proyecto identificará el propósito, el alcance y los

objetivos del proyecto, de igual manera definirá los roles del equipo de trabajo
que formarán parte en el desarrollo del proyecto, además proporciona los
entregables de cada una de las fases de la metodología aplicada y tiempos de
entrega. Para de esta manera facilitar la visión del jefe o líder del proyecto,
donde se asegura un adecuado seguimiento de este.

Alcance de las Pruebas

Elementos de Pruebas

El propósito principal es organizar las actividades necesarias para encontrar

errores y defectos (Pruebas Unitarias); es necesario un plan para coordinarlas,
a fin de asegurar la calidad del producto. Durante el ciclo de vida del proyecto,
se escogió como ámbito de las pruebas, todas las ventanas involucradas en los
Casos de Uso del sistema, teniendo como base los Casos de Uso, los cuales
se desarrollaron los Casos de Pruebas para comprobar el funcionamiento del
software. Con ello se verifica el cumplimiento de las especificaciones de
diseño, los requisitos del análisis, y a su vez se esperan encontrar los
problemas y determinar los riesgos percibidos del sistema, con la finalidad de
entregar un software que sea útil al usuario.

Rol Administrador

Áreas Funcionales Responsable Estado

1. Acceso a todas las Carlosama Diego 70%

funcionalidades del
sistema.
2. Parametrizar los Luis Diaz 100%
diferentes recursos del
sistema

Rol Técnico

Áreas Funcionales Responsable Estado

1. Visualizar los registros Aguirre Guido 100%

existentes
2. Asignar el origen de riesgo Patricio Vásquez 75%
a los registros

3. Asignar el nivel de riesgo a Diego Carlosama 75%

los registros

4. Asignar el riesgo a un área Luis Diaz 80%

(unidad de riesgo)

Rol Usuario

Áreas Funcionales Responsable Estado

1. Registro de los datos Patricio Vásquez

de riesgos
 Sistema

Áreas Funcionales Responsable Estado

1. Asignar estados a los Diego Carlosama 75%

registros

2. Guardar las fechas de Aguirre Guido 75%

todos los estados de los
registros de riesgos

3. Permitir al administrador el Patricio Vásquez 100%

acceso a la
parametrización de todos
los recursos del sistema.

4. Permitir a los usuarios el Aguirre Guido 100%

acceso al registro de
riesgos

5. Permitir a los técnicos el Patricio Vásquez 75%

acceso a la visualización
de los registros existentes

6. Generar un código único Diego Carlosama 75%

con la nomenclatura

SGRE-N-000-secuencial
para el origen natural

7. Generar un código único Luis Diaz 75%

con la nomenclatura
SGRE-A-000-secuencial
para el origen antrópico.

Rol Unidad Responsable

Áreas Funcionales Responsable Estado

1. Visualizar las asignaciones Diego Carlosama 75%

de los riesgos registrados
Nuevas Funcionalidades a Probar
Rol Administrador

Áreas Funcionales Responsable Estado

1. Parametrizar los diferentes Carlosama Diego

recursos del sistema 100%

Rol Técnico

Áreas Funcionales Responsable Estado

1. Asignar el origen de riesgo Aguirre Guido 100%

a los registros
2. Asignar el nivel de riesgo a Patricio Vásquez 75%
los registros

3. Asignar el riesgo a un área Diego Carlosama 75%

(unidad de riesgo)

Rol Usuario

Áreas Funcionales Responsable Estado

1. Registro de los datos de Patricio Vásquez 75%

riesgos

Sistema

Áreas Funcionales Responsable Estado

1. Asignar estados a los Diego Carlosama 75%

registros

2. Guardar las fechas de Aguirre Guido 80%

todos los estados de los
registros de riesgos
3. Generar un código único Patricio Vásquez 50%
con la nomenclatura
SGRE-N-000-secuencial
para el origen natural
4. Generar un código único Aguirre Guido 50%
con la nomenclatura
SGRE-A-000-secuencial
para el origen antrópico.
 Rol Unidad Responsable

Áreas Funcionales Responsable Estado

1. Visualizar las Diego Carlosama 100%

asignaciones de los
riesgos registrados

Pruebas de Regresión
Rol Unidad Responsable

Áreas Funcionales Responsable Estado

1. Levantamiento de Diego Carlosama Luis 100%

componentes para Diaz
conexión a base de datos Patricio Vásquez Guido
Aguirre

2. Levantamiento de Diego Carlosama Luis 100%

componentes para Diaz
ejecución de sistema Patricio Vásquez Guido
Aguirre
3. Cruds De tablas de Diego Carlosama 100%
recopilación de datos Luis Diaz

4. Funciones básicas: Diego Carlosama 100%

Agregar, Actualizar, Patricio Vásquez
Eliminar
5. Desarrollo de tablas Diego Carlosama 100%
parametrizables Luis Diaz
Patricio Vásquez
Guido Aguirre

Funcionalidades a no probar
Áreas Funcionales Descripción de excepción

1. Ingresar Datos por el Los datos ingresados por el usuario se asumen que son
usuario verídicos y por tal motivo no se analizaran.
2. Funcionamiento de El módulo de creación de usuarios es un módulo que ya se
 Modulo Usuarios había implementado y cumple con las necesidades del
sistema por tal motivo no es necesario analizar su
funcionamiento.
3. Funcionamiento de El modulo al igual que Usuarios es un modulo ya
Modulo Bitácora implementado y cumple con las funciones básicas requeridas
por tal motivo no se van a analizar.
4. Módulo de Talento El modulo de talento humano no esta adecuado al sistema
Humano actual por motivos de tiempo de desarrollo y también por que
no es un requerimiento funcional.

Criterios de aceptación o rechazo

Criterios de aceptación o rechazo

Son los criterios que serán considerados para dar por completado el plan de
pruebas de software del primer sprint a desarrollar.

CRITERIO DECRIPCIÓN ACEPTACIÓN %

1 Comprobación de los sistemas que se CORREGIDO 80

utilizaran para el desarrollo del proyecto

2 Revisión del diseño de base de datos e CORREGIDO 80%

implementación de modelo entidad relación
que se manejará empleará en este proyecto

3 Asignación de módulos a los desarrolladores. CORREGIDO 100%

4 Realizar los CRUD de las tablas CORREGIDO 100%

establecidas para este primer esprint.

5 Realizar la verificación y funcionamiento del CORREGIDO 100%

mapeo de tablas mediante eclipse y la base
de datos, el mapeo contiene errores de
codificación de las llaves foráneas.

6 Realizar la configuración del archivo CORREGIDO 100%

persistencia.xml en el proyecto para su
respectiva conexión a la base de dato.

7 Verificar si las librerías necesarias para el CORREGIDO 100%

proyecto como: postgresql.jar para la base de
datos, Prime faces para el Frontend.
 8 Comits en el proyecto, se presentó errores CORREGIDO 100%
para unir los proyectos desde el sistema
Linux.

9 Problemas de servidor Wildfly CORREGIDO 80%

Criterios de suspensión

1. En este esprint 1 se considera la suspensión del avance del proyecto

solo si se presenta fallas al unir las líneas de código en GitHub o si fuera
el caso, la perdida de la base de datos alojada en Heroku.
2. Si al momento de realizar la asignación de roles para el usuario y el
técnico del sistema falla, este se deberá realizar una corrección en las
líneas de código, ya que los roles deben distribuidos correctamente para
evitar pérdida de información y seguridad del sistema.
3. Si los CRUDs de las tablas no funcionan correctamente.
4. Si los datos multimedia no son cargados correctamente a la base de
datos.

Criterios de reanudación

1. La base de datos y los repositorios en GitHub están respaldadas en SQL

para el data base y ramas para el repositorio, por lo tanto, se utilizaría el
versiona miento de código y otra conexión para reanudar el proyecto.
2. Revisar las líneas de código en el módulo seguridades del proyecto, es
donde se genera los roles y las asignaciones.
3. Realizar la corrección de los CRUDs en las clases manejadas como
managers, y vistas en Prime Faces.
4. Verificar la variable que guarda los archivos multimedia.

Entregables
A continuación, se describen los entregables del plan de pruebas y las fechas
en las que se iniciaron y las fechas en las que se prevé se entregarán.

DESCRIPCION FECHA INICIO FECHA FIN

Documento de Plan de Pruebas 17/01/2022 25/01/2022

Casos de Pruebas 24/01/2022 31/01/2022

Evidencias de Pruebas 24/01/2022 31/01/2022

Reporte JMeter 26/01/2022 31/01/2022

Sistema Gestor de Riesgos (Software) 17/01/2022 01/02/2022

Recursos
Recurso Humano

El recurso humano que debe estar disponible para la ejecución de las pruebas
y varía de acuerdo con el tipo de prueba. En el siguiente cuadro se especifica el
tipo de perfil necesario por tipo de prueba y sus respectivas asignaciones con el
personal encargado.
TIPO DE PRUEBAS PERFIL DEL RECURSO HUMANO

Pruebas de funcionalidad EDGAR DIEGO CARLOSAMA

CARLOSAMA
Pruebas de Usabilidad
LUIS PEDRO DIAZ DIAZ
Pruebas de Seguridad
AGUIRRE GOMEZ GUIDO RAUL
Pruebas de ejecución
VÁSQUEZ CALERO PATRICIO ESTEBAN

Requerimientos de entornos – Hardware

Las pruebas se realizarán en un ambiente controlado y administrado por el

equipo de trabajo mencionado en el apartado de recurso humano; a
continuación, se describen las características de la infraestructura de hardware
del ambiente de pruebas.
DESCRIPCION FUNCIONALIDAD CANTIDAD

Servidor: (Estación de Trabajo) 75% 1

Estaciones de Trabajo: (Características 50% 4

mínimas) CPU core i5, 6gb RAM,
256gb SSD o 500gb HD.

El equipo que funcionará como servidor de pruebas será adecuado con cada
una de las estaciones de trabajo administradas por los encargados de cada una
de las pruebas y se espera tener una disponibilidad y funcionalidad mayor al
momento de actuar como servidor.

Requerimientos de entornos – Software

A continuación, se describen las características de la infraestructura de

software necesaria para el ambiente de pruebas.

DESCRIPCION PESO CANTIDAD

Servidor de Aplicaciones: WildFly 22. 85% 1

Sistema Operativo: Fedora Linux. 50% 4

IDE: Eclipse 2021 80% 4

 Servidor de Bases de Datos: 95% 4
PostgreSQL.

Sistema Gestor de Base de Datos: 25% 4

PgAdmin.

Librería para Pruebas Unitarias: Junit. 55% 1

Librería para Pruebas de Rendimiento: 50% 1

JMeter.

Personal

Participantes en el Proyecto

Nominación Perfil Nombre

Jefe de Proyecto, Encargado Estudiante en Ingeniería de Software. Diego Carlosama
de Pruebas del sistema
Conocimientos en arquitecturas y gestión
de software
Conocimientos en Bases de datos
Conocimientos en gestión de procesos
Desarrollador, Encargado de Estudiante en Ingeniería de Software. Guido Aguirre
Pruebas del sistema
Conocimientos en Bases de Datos
Programador
Conocimiento sobre diseño JSF
Desarrollador, Encargado de Estudiante en Ingeniería de Software. Luis Diaz
Pruebas del sistema
Conocimientos en Bases de Datos
Planificación y organización
Cronograma

Dependencias y Riesgos

Los riesgos asociados con el proceso de pruebas de software del primer sprint
se detallan a continuación:
 • Dependencias con desarrollos.
• Dependencias con otros proyectos.
• Disponibilidad de recursos.
• Restricciones de tiempo.
• Premisas que resulten no ser ciertas.
• Falta de recursos y baja competencia en pruebas
• Falta de los recursos necesarios para ejecutar las pruebas según el plan
• Tiempo reducido asignado a la fase de pruebas
• Cambios frecuentes en la definición de los objetivos y alcance del plan
de pruebas
• Falta de coordinación entre los equipos de desarrollo y Testing
• Falta de experiencia con nuevas tecnologías, herramientas, lenguajes de
programación

Los riesgos presentados en este sprint se pueden clasificar en función de su

probabilidad e impacto, cada uno contemplara un plan de mitigación para evitar
que ocurra o plan de contingencia cuando el riesgo no puede mitigarse y tiene
que aceptarse.

Referencias
Se listó todos los documentos que sirvieron como apoyo o para ampliar el
contenido del plan de pruebas. Lo que se puede hacer referencia aquí son:

• Plan de proyecto.
• Especificaciones de requerimientos.
• Diseño general de modelos entidad relación.
• Procedimientos y estándares de desarrollo IEEE.
• Procedimientos y estándares de pruebas V&V.
• Metodologías, procedimientos y estándares corporativos.
• Platillas de gestión de matriz de responsabilidades.
• Tablero para desarrollo de software ágil Monday.
• Documentación de prime faces online para guía de desarrollo Frontend.
Evidencia de Actividades completadas
CRUD e Interfaz de Geolocalización
CRUD Área de Apoyo
CRUD Tipo de Riesgo

CRUD Nivel de Riesgo

CRUD de Riesgos:

Read:
Create:

Edit:
Delete:

View:

Bean:
Manager:

Ventana de Registros. Donde el usuario puede ingresar sus datos para así poder
registrarse y continuamente poder ingresar al sistema.
s
Login de Usuario: Menú de ingreso al sistema con las credenciales de acceso.
Menu De Usuario: Registro de Riesgos. En esta ventana se observa el modulo que se ha
asignado a cada usuario.
Menú Registro Técnico. Se puede visualizar los diferentes tipos de registros que se ha
realizado por el usuario.

Menú Edición, donde se muestra la opción de edición de los distintos datos guardados en
la base de datos.