G05 - Plan de Pruebas de SRA-ejm

SISTEMA DE REGISTRO DE ASISTENCIA - ANÁLISIS DE
REQUERIMIENTOS
Plan de Pruebas del Sistema de Registro de Asistencia

Página 1
Contenido
INTRODUCCIÓN 6
PARTE I: EMPRESA 6
PROPÓSITO 6
DESCRIPCIÓN DE LA EMPRESA 6
GIRO DEL NEGOCIO 6
MISIÓN 8
VISIÓN 8
OBJETIVOS EMPRESARIALES 8
PROCESOS PRINCIPALES DE LA EMPRESA 8
PLANEAMIENTO ESTRATÉGICO DE TECNOLOGÍAS DE INFORMACIÓN: 10
PARTE II: PLAN DE GESTIÓN DE PROYECTO DE PRUEBAS DEL SRA. 13
INFORMACIÓN DEL PROYECTO 13
APROBACIONES 13
RESUMEN EJECUTIVO 14
1 ALCANCE 14
Personal involucrado 15
Definiciones, acrónimos y abreviaturas 16
Resumen 17
1.1 DESCRIPCIÓN GENERAL 17
1.1.1 Perspectiva del producto 17
1.1.2 Funcionalidad del producto 18
1.1.3 Modelamiento de Casos de uso de SRA: 18
1.1.4 Características de los usuarios 21
1.1.5 Restricciones 22
1.1.6 Suposiciones y dependencias 22
1.1.7 Evolución previsible del sistema 22
1.2 REQUISITOS ESPECÍFICOS 22

Página 2
1.2.1 REQUISITOS COMUNES DE LAS INTERFACES 22
1.2.1.1 Interfaces de usuario 22
1.2.1.2 Interfaces de hardware 22
1.2.1.3 Interfaces de software 23
1.2.1.4 Interfaces de comunicación 23
1.2.2 REQUISITOS FUNCIONALES 23
1.2.2.1 Ingreso a la aplicación 23
1.2.2.2 Administración de asistencia 24
1.2.2.3 Administración de reporte 24
1.2.3 REQUISITOS NO FUNCIONALES 25
1.2.3.1 Requisitos de rendimiento 25
1.2.3.2 Seguridad 25
1.2.3.3 Fiabilidad 25
1.2.3.4 Disponibilidad 25
1.2.3.5 Mantenibilidad 25
1.2.3.6 Portabilidad 26
1.2.4 Otros requisitos 26
2 PLAN DE GESTIÓN DE CALIDAD 26
2.1 ALCANCE DE LAS PRUEBAS 26
2.1.1 Elementos de pruebas 26
2.1.2 Nuevas funcionalidades a probar. 26
2.1.3 Pruebas de regresión 28
2.1.4 Funcionalidades a no probar 29
2.2 PROCEDIMIENTOS PARA LAS PRUEBAS 29
2.2.1 Criterios de aceptación o rechazo 30
2.2.2 Criterios de suspensión 31
2.2.3 Criterios de reanudación 33
2.2.4 Roles del personal: 33
2.2.5 Matriz de responsabilidades: 34

Página 3
2.2.6 Cronograma: 35
2.2.7 Premisas: 36
2.2.8 Dependencias y Riesgos: 37
2.3 RECURSOS Y HERRAMIENTAS DE PRUEBAS 37
2.3.1 Requerimientos de Entornos – Hardware 37
2.3.2 Requerimientos de Entornos – Software 37
2.3.3 Herramientas de Pruebas Requeridas 38
2.3.3.1 SONARQUBE: 38
2.3.3.2 PHPUnit: 39
PARTE III: DESARROLLO CON HERRAMIENTA DE MEDICIÓN 40
1 PLAN DE PRUEBAS DE SOFTWARE: 40
1.1 Enfoque de pruebas 40
2 HERRAMIENTA DE CALIDAD DEL PRODUCTO (SonarQube) 41
2.1 Instalación y descripción de uso del SonarQube: 41
3.2 Leyenda de la herramienta: 46
2.3 Gravedad del problema: 47
3 HERRAMIENTA DE PRUEBAS UNITARIAS (PHPUnit) 49
3.1 Instalación y descripción de uso del PHPUnit: 49
3.2 Leyenda de herramienta: 55
3.3 Gravedad del Problema: 55
4 PRUEBAS UNITARIAS A 2 PROCESOS: Evaluación 56
4.1 PHPUnit ejemplo 56
4.2 SonarQube ejemplo sra: 61
5 Benchmarking: 64
3 Entregables de pruebas 65
CONCLUSIONES Y RECOMENDACIONES 65
BIBLIOGRAFÍA: 65
1.3 Referencia 65
ANEXOS SUGERIDOS: 66

Página 4
1 PROJECT CHARTER 66
2 ESTRUCTURA DE DESGLOSE DE TRABAJO: EDT 71
3 JMeter 72
Historial de versiones
Fecha Versión Autores Organización Descripción
16/04/21 SRA001 Grupo 05 Sistema de Registro Especificación de Requisitos
de Asistencia. del Software ERS
09/05/21 SRA002 Grupo 05 Sistema de Registro Plan de pruebas de SRA con
de Asistencia. SonarQube - SonarLint
16/05/21 SRA003 Grupo 05 Sistema de Registro Plan de pruebas de SRA con
de Asistencia. PHPUnit - PhpLint

Página 5
INTRODUCCIÓN
El área de recursos humanos requiere el servicio de gestión de ingresos y salidas por parte
del personal corporativo, para el correcto seguimiento de accesos en el horario laboral de la
empresa, a fin de generar una constancia de concurrencia de los colaboradores, ya que es la
forma más eficaz de conocer el cumplimiento del horario de los trabajadores en el horario
laboral de los mismos mediante un registro.
La necesidad concreta es la de proporcionar una herramienta que permita a los

administrativos visualizar un registro tanto de las asistencias como de los incidentes por
parte de los colaboradores, ya sea en interfaces en el lenguaje PHP o en una página web
interna y exclusiva a la empresa.
PARTE I: EMPRESA
PROPÓSITO
La presente documentación tiene como finalidad delimitar las especificaciones funcionales
y no funcionales del sistema web para el control de asistencias el cual permitirá gestionar la
información detallada de cada uno de los colaboradores mediante el registro de ingresos, de
los mismos. Permitiendo a los supervisores y RRHH utilizar dicha data para la correcta
toma de decisiones en cuanto a las remuneraciones.
DESCRIPCIÓN DE LA EMPRESA
Dynamicall es un Contact Center multicanal ubicado en Perú, cuenta con más de 10 años de
experiencia. Se especializa en outsourcing de ventas, retenciones, servicios de back office y
de atención al cliente, con una estrategia completa que les permita amoldarse a los procesos
de sus clientes.
GIRO DEL NEGOCIO
Dynamicall cuenta con un rubro de negocio orientado B2B, buscan ser socios estratégicos
para ayudar a reducir costos y mejorar resultados, a continuación, un detalle de los
servicios.

Página 6
● Atención al Cliente
INBOUND ● Reclamos
● información y Consultas
● Gestión Promocional
● Ventas / Preventas / Citas
OUTBOUND ● Generación y Actualización de Base de Datos.
● Encuestas de Satisfacción al Cliente.
● Fidelización de Clientes.
● Selección y Capacitación
CONSULTORÍA ● Gestión de la Calidad
CALL CENTER ● Control de Gestión
● Tecnología de la información.
● Gestión de reclamos bajo la normativa de Osiptel o Indecopi.

SERVICIOS ● Análisis de aprobación de línea postpago a través de un
BACK scoring.
OFFICE
● Soporte Operacional
BPO ● Atención de Reclamos.
● Courier
● Delivery Técnico
● Speech Analytics
INTELIGENCI ● ChatBot
A ARTIFICIAL ● IVR inteligentes
● Desarrollo de aplicaciones web y cliente servidor.

APLICACIONES ● Desarrollo de aplicaciones móviles.
A MEDIDA ● Integración de sistemas.
● Manejo de integración CTI con diversas plataformas.
● Whatsapp (API oficial)
SERVICIOS ● Facebook Messenger y Muro
OMNICANA ● Twitter
L ● Instagram
● Correo electrónico
● Youtube

Página 7
MISIÓN
Implementar procesos integrales y de calidad permanentemente adaptados a la realidad

cambiante, con un equipo de personas de enfoque flexible y orientado a lograr satisfacción,
eficiencia sostenible y mejora continua.
VISIÓN
Ser en el 2021 la mejor empresa para contratar y trabajar en el Perú, capaz de ofrecer una
gran experiencia a nuestros clientes.
OBJETIVOS EMPRESARIALES
● Reducir costos y mejorar resultados de sus clientes.
● Estar alineados siempre a la tecnología y personal altamente calificado para lograr
los mejores resultados.
● Mejorar los resultados financieros de forma rápida y estructurada a sus socios
a través de estrategias sincronizadas.
PROCESOS PRINCIPALES DE LA EMPRESA

Dynamicall es una empresa creada para brindar excelencia en la gestión de ventas
(outbound) y servicio de atención al cliente (inbound).
Especialmente cuidadosos en cuatro aspectos que consideramos fundamentales para
brindar un servicio de calidad:
● equipo humano.
● plataforma tecnológica.
● infraestructura física.
● procesos operativos estandarizados.
Tienen áreas de direccionamiento para las concesionarias como son:
● CONSULTORÍA CALL CENTER: Tiene la selección y capacitación a sus

trabajadores maneja una buena Gestión de la Calidad, Control de Gestión y
Tecnología de la información.
● INBOUND: Que traducido literalmente como mercadotecnia interna y es más

conocido como marketing de atracción tiene como finalidad la Atención al Cliente,
Reclamos, información y Consultas y Gestión Promocional.
● OUTBOUND: Es el conjunto de acciones de marketing que tienen el objetivo de

captar consumidores mediante métodos directos y unidireccionales que tiene como
finalidad de ventas / Preventas / Citas, Generación y

Página 8
Actualización de Base de Datos, Encuestas de Satisfacción al Cliente y
Fidelización de Clientes.
● SERVICIOS BACK OFFICE: Engloba todas aquellas actividades relacionadas

con la gestión interna de una empresa como:
➔ Gestión de reclamos bajo la normativa de Osiptel o Indecopi.

➔ Análisis de aprobación de línea postpago a través de un scoring
● BPO: Business Process Outsourcing (BPO), el sector de tercerización de procesos

de negocio, se entiende como la delegación de uno o más procesos de negocio y sus
contenidos son Soporte Operacional, Atención de Reclamos, Courier y Delivery
Técnico
● INTELIGENCIA ARTIFICIAL: Es la combinación de algoritmos planteados con el

propósito de crear máquinas que presenten las mismas capacidades que el ser
humano las funciones son, Speech Analytics, ChatBot y IVR inteligentes.
● APLICACIONES A MEDIDA: Conocido como software personalizado teniendo

como Desarrollo de aplicaciones web y cliente servidor, Desarrollo de aplicaciones
móviles, Integración de sistemas y Manejo de integración CTI con diversas
plataformas.
● SERVICIOS OMNICANAL: Una estrategia de marketing que busca ofrecer una

experiencia única e interconectada a los clientes a través del diálogo y alineación de
canales online y offline como son Whatsapp (API oficial), Facebook Messenger y
Muro, Twitter, Instagram, Correo electrónico y Youtube.
● CLIENTES: Somos conscientes que el cliente representa nuestra razón de ser como
negocio, y debemos estudiar continuamente sus deseos y requerimientos para lograr
mantener en alto nivel de satisfacción de los mismos en el proceso de atención al
cliente es:
➔ LA AGILIDAD: Constituye el principal aspecto valorado y hace alusión a la

rapidez (el tiempo), contribuyendo a mejorar el tiempo de respuesta a nuestros
clientes.
➔ TRÁMITE: Se refiere a los menores requisitos y exigencias para la

documentación y el perfeccionamiento de atención.

Página 9
Organigrama de Dynamicall
PLANEAMIENTO ESTRATÉGICO DE TECNOLOGÍAS DE

INFORMACIÓN:
Sistema de Registro de Asistencia (SRA), pero se le ha realizado un Análisis del micro

entorno de la empresa bajo el enfoque de las Fuerzas de Porter, un Análisis Industrial y un
Análisis de FODA.
ANALISIS DE FODA:
-Fortalezas
● Evitar que los clientes tengan que hacer inversiones en infraestructuras y

personal para instalar un Call Center.
● Los clientes pueden acceder a tecnologías que individualmente es muy costosa
de conseguir.
● Transforma gastos fijos en gastos variables
● Disponibilidad flexible y dinámica que permite enfrentar con éxito demandas
variables de atención
● Los clientes evitan problemas laborales con nuevas contrataciones y
administración de personal
● Puede ser atendido de manera centralizada con cobertura nacional.

Página 10
-Oportunidades
● Integrar a la empresa nuevos sistemas.

● Extender y potenciar áreas del negocio de manera integrada
● Acceso a tecnologías, difícil de obtener de manera in House.
● Concentración en Nicho de Mercado
-Debilidades
● El cliente tiene acceso a diferentes tipos de proveedores con lo cual es fácil de

cambiar a este o particionarlo.
● La rotación del personal es alta, con lo cual hay que estar constantemente
capacitando.
● La tecnología no es un diferenciador, sino el servicio y gestión de estos.
-Amenazas
● Automatización de servicios cada vez más intensa.

● Teletrabajo como sustituto (Homework)
COMPETENCIAS:
● Un mercado competitivo, en el usuario a reclamar servicio de valor y exigir la

forma en la que quieren relacionarse con la empresa.
● Esto obliga a que la call centers tradicionales se conviertan en contact centers,
donde se integran diversos canales de interacción con la empresa como teléfonos, e-
mail, sms entre otros con la misma sencillez y eficacia que proporciona una
solución de centro de atención telefónica y ofreciendo a los clientes un único punto
de contacto para resolver sus necesidades,
GESTIÓN DE TALENTO:
El mejor equipo gerencial del mercado y programas motivacionales permanentes para

todo el personal.
● Estrategias de detección de habilidades y capacidades para definir el perfil

del personal.
● Capacitación permanente y refuerzos de conocimientos para mejorar la
productividad.
● Equipo gerencial experimentado.
● Estrategias de detección de habilidades y capacidades para definir el perfil
del personal.
● Programas motivacionales permanentes, para controlar la rotación de
personal.

Página 11
● Certificaciones internas.
PROCESOS SISTEMATIZADOS DE CONTROL DE GESTIÓN:
Sistema de gestión de indicadores, optimización de recursos involucrados y

cumplimiento de metas.
● Adaptabilidad a los procesos, horarios y enfoque de nuestros clientes.

● Políticas de seguridad.
● Control de información.
● Estructura de procesos y gestión que permiten un bajo overhead.
● Sistema de gestión de indicadores.
● Optimización de recursos
● Cumplimiento de metas.
TECNOLOGÍA:
Soporte tecnológico en cada fase del proceso de negocio para mayor efectividad.
● Marcador automático progresivo y predictivo para optimizar la producción, que

permite cross selling, scripting, CRM, agenda automática y grabación de llamadas,
entre otros.
● Sistema de reportes automáticos y de detección de fallas en cada fase.
● Servidores con discos espejo que respaldan el 100% de los servicios y la posibilidad
de contar con gestiones de 24x7x365.
● Soporte tecnológico en cada fase del proceso de negocio para mayor efectividad.
ESTRATEGIAS IMPORTANTES:
Permitir la adaptación de los procesos de cada cliente y aplicar las mejores prácticas
experimentadas en la industria. Combinar eficiencia, flexibilidad y perfeccionamiento
logrando que la inversión del cliente se vea reflejada en mayor productividad.
CONCLUSIONES:
El área de call center técnico se encarga de atender las llamadas entrantes que realizan
los usuarios de servicio de banda ancha, quienes se comunican al área a través del canal
123. El staff de asesores debe de resolver toda clase de solicitud de soporte técnico del
SBA (Small Business Administration) de los usuarios. Sin embargo, el total de llamadas
entrantes no son atendidas generando llamadas abandonadas y llamadas atendidas fuera
del tiempo establecido por el cliente. En este sentido, el área presenta problemas de
operatividad que deben ser analizadas y resueltas.

Página 12
PARTE II: PLAN DE GESTIÓN DE PROYECTO DE
PRUEBAS DEL SRA.
INFORMACIÓN DEL PROYECTO
Empresa / Organización Sistema de registro de asistencia (SRA)
Proyecto Desarrollo, implementación e testing SRA
Fecha de preparación 16/04/21
Cliente Gerente general:
ENRIQUE BELTRÁN CORNEJO - Representante de
DYNAMICALL
Patrocinadores principales Alarcón Castillo, Carlos Franco
Rojas Espinoza, Juan Carlos
Sánchez López, Fabian Leonel
Tasayco tuanama, Luis fernando
Vásquez Medina, Ana Kelly
Gerente / Líder de proyecto Vásquez Medina, Ana Kelly
Gerente / Líder de Tasayco tuanama, Luis fernando.
desarrollo de sistema
APROBACIONES
Nombre y Apellido Cargo Departamento u Fecha Firma
organización
Rojas Espinoza, Juan Desarrollador 09/05/21
Carlos Frontend Dirección y gerencia
Vasquez Medina, Ana Analista de sistemas 09/05/21
Kelly Diseño del sistema
Sanchez Lopez, Fabian Administrador de 09/05/21
Leonel Base de Datos Administrador del sistema
Tasayco tuanama Luis Desarrollador Backend Desarrollo del sistema 09/05/21
fernando
Alarcón Castillo, Carlos Backend Testing Tester 09/05/21
Franco
RESUMEN EJECUTIVO
Este documento tiene como propósito evaluar los errores y defectos que pueden existir en
un sistema, con el fin de corregirlos. Validar que los datos funcionen correctamente y
determinen el ingreso de información adecuada.
Verificar que los validadores de datos funcionen y limiten el ingreso de información, para
que no se puedan ingresar datos que no están permitidos (sólo números en campos
numéricos, por ejemplo).

Página 13
El sistema a desarrollar será a nivel de aplicación web, y tendrá que pasar evaluaciones de
aceptación de los colaboradores y supervisores. Con el requisito de optimizar los procesos de
recursos humanos para validar las asistencias de nuestros colaboradores.
1 ALCANCE
Implementación y desarrollo de una aplicación web denominada Sistema de Registro de
Asistencias (SRA).
El sistema a desarrollar será a nivel de aplicación web, y tendrá que pasar evaluaciones de
aceptación de los colaboradores y supervisores.
En su fase de producción, el sistema dará apoyo a los siguientes procesos:

● Registro y control de asistencias: Inmediato, a largo plazo y a muy largo
plazo.
● Exportación de los reportes de asistencias.
Igualmente, facilitará a los administrativos contar con herramientas que les permita la
visualización de tablas informativas con las relaciones por índices de puntualidad,
tardanzas y faltas en el rango del horario laboral establecido, el cual se obtendrá en base a
los datos proporcionados por el algoritmo del sistema desarrollado en PHP programados en
el sistema web.
Además, trabajará con la consulta de datos ingresados por los diferentes colaboradores.
Asimismo, contará con una conexión a la intranet, navegadores web de la empresa, ya que
el sistema se encontrará alojado en el servidor local de la misma.
Asimismo, por cada ingreso de datos por parte de los colaboradores al sistema, los
encargados del área de recursos humanos podrán exportar un reporte de las asistencias.
Personal involucrado
Nombre Alarcón Castillo, Carlos Franco
Rol Backend Testing
Categoría profesional Ingeniero de Sistemas
Responsabilidades Diseñar la interfaz gráfica del sistema según los
requerimientos del cliente.
Información de contacto
Nombre Rojas Espinoza, Juan Carlos

Página 14
Rol Desarrollador Frontend
Responsabilidades Adaptar y diseñar el sistema de información para trabajar de
forma más rápida y eficiente.
Nombre Sánchez López, Fabian Leonel

Rol Administrador de base de datos
Responsabilidades Configurar, administrar y mantener los sistemas de base de datos.
Nombre Tasayco tuanama Luis fernando

Rol Desarrollador Backend
Responsabilidades Programar la funcionalidad del sistema en base a los
requerimientos obtenidos.
Nombre Vásquez Medina, Ana Kelly

Rol Analista de sistemas
Responsabilidades Proporcionar informes al equipo del proyecto sobre cualquier
problema o mejora que el sistema pueda requerir.
Definiciones, acrónimos y abreviaturas

Del Negocio:
● Registro: Almacenar datos o dejar constancia de ello en un fichero.

● Incidencia: Evento que suscita un colaborador en un momento
determinado como, tardanzas, faltas, licencias, factores externos, etc.
● Control: Gestión de la información ingresada al sistema para su
posterior utilización en el análisis de desempeño laboral.
● Reporte: Informe sobre los acontecimientos recientes de los
usuarios(asistencias) a través de un pdf.
Del Sistema:
● Interfaz: Conexión funcional entre dos sistemas, programas, dispositivos o

componentes de cualquier tipo, que proporciona una comunicación de
distintos niveles produciendo el intercambio de información.

Página 15
● Ventana: Interfaz gráfica propia de un sistema operativo.
● Puntero del mouse: Representación de la posición del mouse en la
pantalla del computador y que es controlado por el usuario.
● Botones: Controles que al ser activados disparan una funcionalidad del
sistema, como, generar reporte, editar, actualizar, enviar, etc..
● Slider o control deslizador: Control tipo deslizador para manejar
cierta funcionalidad del sistema otorgándole mayor o menor intensidad.
● Animación: Secuencia de imágenes que son reproducidas en un
determinado intervalo de tiempo.
● Tablas: Organizan con arreglo a un formato de filas y columnas, similar al
de una hoja de cálculo.
● Roles: Jerarquía de control visual y de edición de datos del sistema.
● Inicio de Sesión: Nos permite conservar información sobre un usuario al
pasar de una página a otra.
● Menú:Conjuntos de opciones o posibilidades que se le presentan al
usuario.
● Formulario: Permite al usuario introducir datos los cuales son
enviados a un servidor para ser procesados.
De Tecnología:
● Actualizar o refrescar el navegador: Recargar el sistema mediante la

tecla F5 (Windows / Mac / GNU/Linux)
● Memoria caché del navegador: Es la memoria de que dispone el
navegador de internet para procesos internos.
Resumen
En el presente documento se describe la información sobre las características del
producto de software, interfaces del usuario, interfaces del sistema, características de
los usuarios, descripción de los requerimientos funcionales, no funcionales y del
sistema, los cuales se representarán mediante el siguiente formato:
SRA
ERS – Especificación de requisitos de
Software
Código Nombre Fecha Grado Necesidad
Referencia Nombre del Requerimiento Fecha de Importancia del
de Especificació requerimiento

Página 16
Requerimient
o n
Descripción Descripción del Requerimiento
Entradas Fuente Salida Destin Restricciones
o
Entradas del
Fuentes de Salidas del Donde se Restricciones a
Requerimient
o las entradas requerimiento lleva la salida tener en cuenta
Descripción detallada de las actividades que realiza el
Proceso
requerimiento.
Efecto
Efectos generados a otros procesos o sistemas, si es el caso.
Colatera
l
Código:
RF: Requerimiento funcional
RFN: Requerimiento no
funcional RI: Requerimiento de
interfaz
1.1 DESCRIPCIÓN GENERAL

1.1.1 Perspectiva del producto
El sistema SRA será un producto diseñado para trabajar en entorno web, lo cual
permitirá su utilización de forma dinámica, además será independiente por lo cual
no interactúa con otros sistemas.
El sistema registrará la asistencia de los colaboradores, el súper usuario podrá

extraer una base en excel del control de la asistencia de los colaboradores como
dando un seguimiento y control de faltas , para poder validar los pagos mensuales .
1.1.2 Funcionalidad del producto
El sistema SRA comprenderá los siguientes procesos:
a. Inicio de sesión.
b. Formulario de asistencia.
c. Reporte de asistencia.
1.1.3 Modelamiento de Casos de uso de SRA:

➢ Caso 1: Acceso al Sistema (SRA)

Página 17
Descripción: Permite el ingreso al sistema con el acceso correspondiente.
Actores: Trabajador proporciona información, previa a una validación que se trata de

un usuario autorizado del subsistema con su clave respectiva.
Precondiciones: El sistema debe estar conectado al servidor de la BD para que se

pueda almacenar la información, de la misma manera el usuario autorizado se debe
haber conectado al sistema para que se pueda generar la información que el usuario
requiera.
Flujo Normal:
1. El actor ingresa su código de identificación único.

2. El sistema presentará un mensaje de éxito.
Flujo Alternativo: Si en el sistema de empleados no se encuentra el id presentará un

mensaje de error.
Postcondiciones: La información registrada en la Base de Datos se actualizará.
➢ Caso 2: Registrar Asistencia

Página 18
Descripción: Ingresado en el sistema generar reporte de entrada, salida e historial de
asistencia del personal.
Actores: Trabajador proporciona información, previa a una validación que se trata de un
usuario autorizado del subsistema con su clave respectiva.
pueda almacenar la información, de la misma manera el usuario autorizado se debe haber
conectado al sistema para que se pueda generar la información que el usuario requiera.
Flujo Normal:
1. El actor genera su reporte de entrada en el sistema.
2. El sistema presentará un mensaje de éxito con el registro de entrada.
3. Hacer el mismo procedimiento para registrar la salida.
4. El sistema tiene una opción para ver su asistencia semanal, quincenal y
mensual.
Flujo Alternativo: Si en el sistema de empleados no se registra entrada/salida presenta
un mensaje de error.
Postcondiciones: La información registrada en la Base de Datos se actualizará.
➢ Caso 3: Generar Reportes de Asistencia.

Página 19
Descripción: Este caso de uso pretende generar el Reporte de ingreso y salida
del trabajador permitiendo la verificación de los días laborados.
Actores: Supervisor
pueda verificar la información, de la misma manera el usuario autorizado se debe
haber conectado al sistema para que pueda generar la información requerida.
Flujo Normal:
1. El actor selecciona la opción de generar reporte.
2. El sistema presenta una tabla de datos con el listado de los
empleados y un panel de control de acción con el botón de filtrar.
3. Al hacer esto el sistema generará el reporte en un Excel.
4. Hacer clic en Aceptar para que se guarde el reporte en su
Computadora.
Flujo Alternativo: Si en la filtración de lo requerido se genera un error, se notificará

al actor mediante un mensaje.
Postcondiciones: La información requerida la obtendrá el supervisor.
1.1.4 Características de los usuarios
Tipo de usuario Colaborador

Página 20
Formación nivel secundaria completa ,estudios técnico o estudios
superiores
Habilidades Conocimiento básico a intermedio sobre página web y office
Actividades Ingresa a marcar asistencia
Tipo de usuario Supervisor (super usuario)

Formación Estudios Superior o tecnicos
Habilidades Conocimiento intermedio office y conocimiento básico sobre
página web
Actividades Ingresa a marcar asistencia
Extrae una base de asistencia de sus colaboradores
Tipo de Usuario Soporte Páginas web.

Formación Ingeniero de sistemas.
Habilidades Conocimiento avanzado sobre programación web y
verificación de actualizaciones.
Actividades Mantenimiento del sistema.
1.1.5 Restricciones
● El sistema tendrá un entorno accesible y amigable para poder
realizar los registros.
1.1.6 Suposiciones y dependencias

● Compatible con todos los navegadores web
● El sistema será multiplataforma
1.1.7 Evolución previsible del sistema
● Implementación a futuras actualizaciones o mejoras del sistema

● Implementación a futuras colaboraciones con sistemas internos de la
empresa

Página 21
1.2 REQUISITOS ESPECÍFICOS
● R1: Permitir la autenticación de los usuarios.
● R2: Permitir a los colaboradores marcar la asistencia.
● R3: Gestionar reportes (exportar reporte)
1.2.1 REQUISITOS COMUNES DE LAS INTERFACES

1.2.1.1 Interfaces de usuario
Debe ser responsivo para las distintas resoluciones de pantalla, sin embargo, no
debe mostrarse en dispositivos móviles. El estilo de colores debe cumplir el
manual de estilos de la empresa, de igual manera con la fuente.
El usuario previamente debe tener su cuenta de usuario en el sistema para poder

acceder. En caso de que no ingrese correctamente el USUARIO o el
PASSWORD se desplegará un mensaje de datos incorrectos.
Una vez ingresado los datos en la pantalla de asistencia, se mostrará una
imagen agradeciendo su registro y deseando una excelente jornada laboral.
1.2.1.2 Interfaces de hardware

● Pantalla: Para que el usuario visualice el ingreso de sus
datos.
● Ratón: Para que el usuario se desplace alrededor del
sistema.
● Teclado: Para que el usuario pueda digitar sus datos.
● Impresora: Para que el administrador del sistema pueda
imprimir sus reportes.
1.2.1.3 Interfaces de software

Navegadores web (Mozilla Firefox, Google Chrome, Opera, Microsoft Edge,
etc)
1.2.1.4 Interfaces de comunicación

Comunicación con los servidores de la empresa para la exportación de los
reportes y el almacenamiento de la información. La interfaz del sistema
desarrollado en PHP, HTML5, JS y CSS se comunicará con la base de datos a
través de phpMyAdmin.
1.2.2 REQUISITOS FUNCIONALES

El SRA proveerá facilidad de acceso para el registro de sus asistencia a los
colaboradores y así acceso a la información para el manejo de reportes.

Página 22
1.2.2.1 Ingreso a la aplicación
SRA
Software
RF 2.2.1.1 Acceso al sistema 16/04/2021 Esencial
Descripción El sistema debe permitir ingresar por medio del protocolo HTTPS
Entradas Fuente Salida Destino Restricciones
Usuario y El ingreso solo lo
Contraseña realiza el usuario con
del Pantalla de Pantalla de los permisos y/o
colaborador Red logueo asistencia credenciales
necesarias y no se
abrirá desde
dispositivos móviles.
El sistema solicita un nombre de usuario y un password o contraseña en la
Proceso pantalla de logueo del sistema y si coinciden con las credenciales
almacenadas en la Base de Datos se hará el ingreso a la
pantalla de asistencia..
Efecto
El mal ingreso de las credenciales mostrará una pantalla de error
Colateral
1.2.2.2 Administración de asistencia

SRA
Software
Marcar asistencia en el
RF 2.2.2.1 14/04/2021 Esencial
sistema
El sistema debe permitir marcar asistencia una vez que haya sido logueado
Descripción
Cada usuario debe
Hora de Botón de Pantalla de Base de
marcar una entrada y
ingreso ingreso asistencia Datos
una salida
El sistema tiene la opción de marcar la entrada y salida del colaborador
Proceso para ello tomará almacenará la hora en la que ha sido
registrada su entrada al sistema.
Efecto
No marcar entrada y salida podría reflejar incidentes en sus honorarios
Colateral

Página 23
1.2.2.3 Administración de reporte
SRA
Software
Descargar reporte de
RF 2.2.3.1 asistencia de los 14/04/2021 Esencial
colaboradores
El sistema debe permitirle al usuario administrador del sistema descargar
Descripción
los reportes de cada colaborador
Archivo con
Registro de
Botón de formato XLS Archivos Solo el administrador
asistencia
descarga de descargado locales del podrá descargar los
por
asistencia en el equipo administrador reportes
colaborador local
El programa deberá almacenar todos las asistencias marcadas por los
Proceso colaboradores, el usuario administrador podrá descargar los reportes
guardados en la base de datos, los reportes se mostrarán separados
por colaborador
Efecto No marcar asistencia de los colaboradores implica que el registro no sea
Colateral llenado
1.2.3 REQUISITOS NO FUNCIONALES

1.2.3.1 Requisitos de rendimiento
● Se requerirá un sistema de respuesta rápida, pero ello dependerá del

procesador o la tarjeta de video y del tráfico de red del servidor de la
empresa.
● El sistema garantizará a los usuarios un desempeño en cuanto a los datos
almacenados en el sistema ofreciéndole una confiabilidad a esta misma.
1.2.3.2 Seguridad
● Acceso seguro al sistema se debe emplear técnicas criptográficas para la

encriptación de las contraseñas, en este sentido la información almacenada o
registros realizados podrán ser consultados y actualizados permanente y
simultáneamente, sin que se afecte el tiempo de respuesta.
● El sistema garantizará a los usuarios una seguridad en cuanto a la
información que se procede en el sistema, permitiendo el registro de

Página 24
la información al personal autorizado con la intención de consultar los datos
pertinente para cada usuario.
1.2.3.3 Fiabilidad
● El sistema debe tener una interfaz amigable de uso intuitivo y sencilla.
● La interfaz de usuario debe ajustarse a las necesidades del sistema.
1.2.3.4 Disponibilidad
● El sistema deberá estar disponible en los horarios de la jornada laboral que
corresponde a cada usuario, fuera de ello el sistema lo registrará como una
brecha de seguridad.
1.2.3.5 Mantenibilidad
● El mantenimiento del sistema se realizará de manera trimestral.
● El sistema deberá de tener un manual de instalación y manual de usuario
para facilitar los mantenimientos que serán realizados por el administrador.
1.2.3.6 Portabilidad
● En la fase de producción se definirá el porcentaje de componentes
dependientes del servidor, el porcentaje de código dependiente del servidor,
el uso de un determinado lenguaje por su portabilidad y de determinados
compiladores o sistemas operativos para el mejor desempeño.
1.2.4 Otros requisitos

La información que maneje el sistema debe estar sujeta a las normas y políticas
de las empresa.
2 PLAN DE GESTIÓN DE CALIDAD

2.1 ALCANCE DE LAS PRUEBAS
2.1.1 Elementos de pruebas

Definiremos el alcance de las pruebas en módulos, no todos los componentes serán
probados, escogimos como herramienta a SonarQube y SonarLint que permite realizar
análisis estático de código fuente de manera automática, buscando patrones con errores,
malas prácticas o incidentes, base un análisis de riesgos realizado de manera previa,
debemos tener en cuenta las variables tales como el impacto que podría ocasionar, si falla
una funcionalidad y la probabilidad de que falle en un entorno de producción.

Página 25
Por lo tanto, son de Alto nivel por las operaciones que deben desarrollarse como las pruebas a realizar:
● Detección de código duplicado.

● Pruebas unitarias y falta de comentarios.
● Complejidad ciclomática, alto acoplamiento.
● Tamaño de archivos de código.
● Tamaño de métodos.
● No adecuación a estándares y convenciones de código.
● Vulnerabilidades conocidas de seguridad.
Un listado de las pruebas que se realizarán “Desde el punto de vista del Usuario”. No es
una descripción técnica del software sino sus características y funcionalidades que
realizará, se incluirán tanto los nuevos requerimientos como los modificados.
2.1.2 Nuevas funcionalidades a probar.
El sistema de información posee 2 roles de usuario (Trabajador - Supervisor) de los cuáles

cada uno podrá tener.
Rol Usuario
➔ Ingreso de usuarios (Trabajador - Supervisor)
Por medio de la validación de 2 campos, (usuario, contraseña) el sistema generará

una advertencia cuando los datos ingresados no son los mismos que contiene la base
de datos en la tabla usuarios.
Si la información ingresada es correcta, permitirá el acceso al portal y redirigirá a la

página de información personal del usuario.
(Imagen de Logueo)
➔ Visualización de información Personal (Trabajador - Supervisor)
El usuario podrá visualizar la información registrada en la base de datos como datos

personales y tendrá la posibilidad de modificar algunos de ellos.
(Imagen de información de usuario)

Página 26
➔ Visualización de ventana de ingreso y salida de asistencia (Supervisor -
Trabajador)
Este módulo provee la información de los horarios laborados del usuario en un

periodo vigente.
(Imagen de Asistencias )
➔ Visualización de asistencia (Trabajador)
Debe coincidir con lo almacenado en la base de datos a través de la

funcionalidad de ingreso y salida de asistencia por parte del Supervisor. Se
visualizará por una cantidad de cortes que tendrá el periodo de trabajo.
(Imagen de botones de ingreso y salida de asistencia)
➔ Visualización de eventos (Calendario) (Supervisor - Trabajador)
El usuario tendrá la posibilidad de visualizar los diferentes eventos de trabajo que

proponga la empresa a los cuales el trabajador pueda ingresar.
(Imagen de su cronograma de trabajo cambiado o habitual por parte de la empresa)
➔ Ingreso de horarios de trabajo (Supervisor)
El supervisor podrá ingresar los horarios de trabajo para cada uno de los empleados
a los cuales les asignará el turno y horario de trabajo. Esta información debe quedar
almacenada en la base de datos, de tal manera que el Trabajador pueda visualizarlo a
través de la funcionalidad “Visualización de Horarios”
(Imagen de cronograma de trabajo)

Página 27
FACULTAD DE INGENIERÍA
➔ Cambio de Clave (Supervisor- Trabajador)
Mediante la validación de la clave actual, el trabajador podrá cambiar la clave de

acceso al portal WEB.
(Imagen de cambio de clave)
2.1.3 Pruebas de regresión
La prueba de regresión consiste en probar un sistema que ha sido analizado previamente

para asegurar que no se haya introducido algún tipo de defecto como resultado de cambios
realizados. ( ISTQB, 2017).
● Identificar errores introducidos por la combinación de programas probados

unitariamente.
● Determina cómo la base de datos de prueba será cargada.
● Utilizar la técnica down-top.
● Determinar que las modificaciones no han causado fallas o efectos adversos.
● Determinar que se cumplen con los requerimientos.
● Modificaciones menores selección de pruebas.
● Construir paquetes de pruebas de regresión, actualizarlas.
● La repetición de los casos de pruebas que se han realizado anteriormente y están
directamente relacionados con la parte del sistema modificada.
● La revisión de los procedimientos manuales preparados antes del cambio, para
asegurar que permanecen correctamente.
● La obtención impresa del diccionario de datos de forma que se compruebe que los
elementos de datos que han sufrido algún cambio son correctos.
2.1.4 Funcionalidades a no probar
Las pruebas No Funcionales se centran en aspectos muy importantes del comportamiento

del producto pero que no están relacionados con las funciones que realiza el sistema.
● Pruebas de carga
● Pruebas de estrés
● Pruebas de volumen
● Pruebas de configuración

Página 28
● Pruebas de usabilidad
● Pruebas de seguridad
● Pruebas de resistencia
● Pruebas de escalabilidad
● Pruebas de recuperación
● Pruebas de mantenibilidad
2.2 PROCEDIMIENTOS PARA LAS PRUEBAS

Nuestro proyecto es escalable, sin embargo consideramos correcto usar una metodología
lineal o llamada también tradicional, debido a que después de la primera entrega recién se
procederá a trabajar por sprints. Para ello proponemos las siguientes fases basándonos en
RUP.
● Planificación de pruebas
● Diseño de pruebas
● Implementación de pruebas
● Evaluación de criterios de salida
● Cierre del proceso
El fin de dividirlo en fases es para poder cumplir con cierta funcionalidad del software en
cada una de las fases. Las fases de un proyecto de metodología tradicional también pueden
definir diversos niveles de abstracción, en el caso de control de calidad se traduce en los
diferentes tipos de prueba de acuerdo a la profundidad o enfoque que se le quiera dar, en
nuestro proyecto usaremos el modelo V.

Página 29
2.2.1 Criterios de aceptación o rechazo
El SRA será entregada y posteriormente probada por el cliente DYNAMICALL, bajo los
siguientes criterios.
Criterio Descripción
Se aprobará el proyecto con un 100% de las pruebas ejecutadas pero con
un 90% de aceptación.
Aprobado Esto quiere decir que el 90% de las pruebas deben ser exitosas y sin
errores.
En el restante 10% puede existir fallas de criticidad medias o bajas pero
no graves o alta.
En caso de ocurrir que el proyecto no cumpla con el nivel exigido, el
Rechazado
proyecto se rechaza completo en su etapa final.
Los errores resultantes del Testing de Aceptación se clasifican en distintos niveles de

criticidad.
Criticidad Descripción
Son eventos producto del mal funcionamiento del sistema impidiendo
Alta
continuar con su uso.
Son eventos graves que pueden no afectar el funcionamiento del sistema
Media
pero necesitan ser corregidos.
Es un aporte al sistema que mejora la funcionalidad de los procesos.
Baja
Ninguno Indica que el evento no presenta ningún tipo de criticidad.
2.2.2 Criterios de suspensión
Los Casos de Prueba que fallaron tendrán un evento asociado a un estado donde se reporta
la incidencia/error.
❖ Los estados finales de un evento son:
Estado Evento
Satisfactorio Cuando se ejecuta un Caso de Prueba y no se produce
ningún error.
Pérdida de Vigencia Cuando un error que había sido reportado, ya no está
vigente, es decir, ya no tiene sentido corregirlo por cambio
en la funcionalidad.

Página 30
Cerrado Cuando se comprueba que el defecto ha sido corregido, la
falla que había sido reportada.
Sin valor de Este estado es asignado a un evento cuando no se puede
referencia realizar la ejecución de un Caso de Prueba debido a que la
para comparar funcionalidad que especifica el caso aún no está
desarrollada.
❖ Los estados intermedios de un evento que deben llegar a un estado final son:
Estado Evento
Pendiente Cuando el resultado de la ejecución del Caso de Prueba, se produce
un error.
Suspendido Cuando el error es reconocido como tal, pero por el momento no se
procederá a la corrección del mismo porque existen otras tareas de
mayor prioridad que deben realizarse.
No Asignado por el desarrollador: Cuando la incidencia asignada no le
corresponde al corresponde corregir, permitiéndole al jefe del proyecto asignarla al
recurso programador correspondiente.
No aplica Cuando el desarrollador o el jefe de proyecto interpretan que el error
desarrollo reportado no es tal.
Las posibles causas son: inconsistencia en la documentación,
factibilidad técnica, etc.
Cuando el analista de testing comprueba que el error ha sido
Cerrado corregido, es decir, vuelve a ejecutar el Caso de Prueba y ya no se
produce el error que había sido reportado.
Cuando el desarrollador ha corregido el error, es decir, vuelve a
Corregido ejecutar el Caso de Prueba y ya no se produce el error reportado.
Cuando el desarrollador ejecuta el Caso de Prueba para reproducir el

No se error reportado y proceder a su corrección, pero el mismo no se
puedo produce.
Reproducir
Cuando el jefe de proyecto asigna un evento a un
Asignado desarrollador para que este corrija el error reportado.

Página 31
Como condición de criterio de aceptación, se considera que la solución a un módulo son
aceptables cuando, como resultado de la ejecución del “Test de Aceptación” se encuentre
una distribución en la criticidad de los errores, que sigan los siguientes porcentajes respecto
a la totalidad de los casos de prueba:
Criticidad del Error % sobre Totalidad de Casos de Prueba
Alta 0%
Media 4%
Baja 6%
2.2.3 Criterios de reanudación
Los procesos de prueba se suspenderán y el desarrollador será contactado bajo las siguientes
circunstancias o criterios:
- Revisión de fallas básicas.

- Múltiples anomalías de alto nivel de prioridad (Crítico).
- Múltiples anomalías de nivel medio que no corresponden a las
especificaciones.
2.2.4 Roles del personal:
ROLES PARA LA GESTIÓN DE LA

CALIDAD
Funciones del rol:
ROL N O1: ● Planificación de proyecto y definición de objetivos.
Jefe de Proyecto ● Reporte de vialidad.
● Coordinación de recursos.
Reporta a:
Cliente representantes de DYNAMICALL
Funciones del rol:
ROL N O2: ● Adaptar y diseñar el sistema de información para trabajar de forma más
Analista de Sistemas rápida y eficiente.
● Análisis y modelo de procesos y datos.
Reporta a:
Jefe de proyecto
ROL N O3: Funciones del rol:
● Diseñar la interfaz gráfica del sistema según los requerimientos del
Desarrollador
cliente.
Frontend y ● Configurar, administrar y mantener los sistemas de base de datos.
● Programar la funcionalidad del sistema en base a los requerimientos
Página 32
backend

Página 33
obtenidos.
Reporta a:
Jefe de Proyecto.
Funciones del rol:
● Planificación de la logística
● Verificar y validarla eficiencia de las pruebas.
ROL N O4 : Jefe
de Calidad Supervisa a:
Analista de pruebas.
Reporta a:
Jefe de Proyecto.
Funciones del rol:
● Implementar y ejecutar las pruebas con el Sonar.
ROL N O5 : ● Definir los datos de pruebas.
Analista de ● Documentar los incidentes.
Pruebas ● Proporcionar informes al equipo del proyecto sobre cualquier
problema o mejora que el sistema pueda requerir.
Reporta a:
Jefe de Pruebas de calidad.
2.2.5 Matriz de responsabilidades:
Matriz Raci del Sistema Registro de Asistencia.
MATRIZ RACI DEL SISTEMA DE REGISTRO DE

ASISTENCIA
ROLES
ID ACTIVIDADES Jefe de Analista Dev. Jefe de Analista de
proyecto de Frontend Calidad Pruebas
sistema y Backend
1 Identificar la necesidad de los usuarios A R C I I

2 Realizar la lista de requisitos por los usuarios C R A I/C I
3 Gestión de cronograma R C C A I/C
4 Elaboración de plan de gestión del software R A C C I
5 Programador C A R I/C C
6 Administrador de la BD I C R A/I C
7 Diseñador de la página web A R I C C
8 Analista y tester de software A C/I C C R

Página 34
9 Auditoría, monitoreo y revisión del software C R I I/C I
10 Rectificación de fallas detectadas en el Software I C R I C
11 Desarrollo del Manual de Usuario C R I/A A C
12 Capacitación del Uso del Software A C R C/I C
2.2.6 Cronograma:
El cronograma del Sistema Registro de Asistencia.
NOMBRE DE TAREAS DURACIÓN COMIENZO FIN

Sistema de registro de asistencia 36 días lun 17/05/21 lun 05/07/21
Fase de Pruebas 28 días lun 17/05/21 mié 23/06/21
Reunión con el equipo de trabajo 2 días lun 17/05/21 mar 18/05/21
Identificación de la herramienta de pruebas 3 días lun 17/05/21 mié 19/05/21
Realización Plan de Pruebas 3 días lun 17/05/21 mié 19/05/21
Ejecución del plan de pruebas 12 días mié 26/05/21 jue 10/06/21
Pruebas de integridad a la BD 5 días mié 26/05/21 mar 01/06/21
Prueba de Funcionamiento 2 días mié 26/05/21 jue 27/05/21
Prueba de control de Seguridad y acceso 2 días mié 26/05/21 jue 27/05/21
Prueba de rendimiento 3 días mié 26/05/21 vie 28/05/21
Informe de Pruebas 3 días lun 14/06/21 mié 16/06/21
Confirmación de resultados 5 días jue 17/06/21 mié 23/06/21
Informe de resultados de Pruebas 2 días jue 24/06/21 vie 25/06/21
Base de los módulos 6 días lun 28/06/21 lun 05/07/21

Página 35
anexo MS del cronograma.
2.2.7 Premisas:
Para que el plan de pruebas se pueda llevar a cabo se debe tener:
➢ Disponibilidad de tiempo.
➢ Disponibilidad de recursos.
➢ Metodología de las pruebas
➢ Uso de herramientas
➢ Conocimiento de las pruebas por los integrantes del grupo.
Para que el plan de pruebas del SISTEMA DE REGISTRO DE ASISTENCIA se dé por

concluido se deben de cumplir las siguientes actividades.
Probar cada interfaz del sistema.

Probar logeo.
Probar ingreso y salida de asistencia.
Probar el botón registro de asistencias.

Página 36
2.2.8 Dependencias y Riesgos:
RIESGO PLAN DE CONTINGENCIA IMPACTO

Falta de capacitación al Capacitar al personal Reemplazar Página afectada por una mala
personal al personal antiguo. capacitación
Proyecto afectado por la inconformidad
Tiempo de Prueba Mejorar el plan de pruebas Análisis
del usuario que pueda manifestar
de las pruebas realizadas
Errores en la ejecución del Volver a realizar las pruebas Área de pruebas, desarrollo y
plan de pruebas identificando los errores mantenimiento de Software
● Posibles dificultades en las disponibilidades de entorno.

● Pruebas que dependen de factores externos al proyecto.
● Disponibilidad del personal con conocimiento especializado en las
herramientas o en la funcionalidad específica que se desarrolla.
● Posibilidad que la idea no se cumpla.
2.3 RECURSOS Y HERRAMIENTAS DE PRUEBAS

2.3.1 Requerimientos de Entornos – Hardware
Los requerimientos de hardware que necesitamos es:
● Procesador Intel o AMD de 2 a 4 núcleos

● Memoria Ram 8GB
● CPU
● Disco duro
● Placa Base
● UPS o SAI(sistema de alimentación ininterrumpida)
● Monitor IPS Full HD de 21,5” con AMD
● Impresoras
2.3.2 Requerimientos de Entornos – Software
Los requerimientos de software que necesitamos para la ejecución de nuestras pruebas

de calidad son las siguientes:
● Servidor web: Xampp vr.3.3.0
● Windows 10

Página 37
● PHP 8.0.6
● Navegadores Web
● HTML
● JS
● CSS
● SonarQube
● SonarLint
● PHPUnit
● PHPLint
2.3.3 Herramientas de Pruebas Requeridas
El equipo de pruebas utilizara las herramientas de medición para el SRA, son el paquete
SONAR (SonarQube, SonarScanner, Sonarlint) y PHPUNIT con las librerías de PHPUnit
(composer junto a PHPLint) , a continuación los detalles.
2.3.3.1 SONARQUBE:
Plataforma para evaluar código fuente y la calidad del mismo. Es software libre y
usa diversas herramientas de análisis estático de código fuente como Checkstyle,
PMD o FindBugs para obtener métricas que pueden ayudar a mejorar la calidad del
código de un programa.

Página 38
● SONARSCANNER: Herramienta complementaria de SonarQube que nos permite
escanear el código fuente y poder cargar el proyecto a la plataforma, es el
intermediario entre CÓDIGO-PLATAFORMA.
● SONARLINT: SonarLint es una extensión IDE que le ayuda a detectar y
solucionar problemas de calidad mientras escribe código. Como un corrector
ortográfico, SonarLint garabatea fallas para que puedan corregirse antes de enviar
el código.
2.3.3.2 PHPUnit:
PHPUnit es un framework para implementar pruebas unitarias en lenguaje PHP o

TDD - Desarrollo Guiado por Pruebas. Es decir, es un framework que nos ayuda
a probar nuestro código realizando pruebas unitarias. Mediante la clase de nuestro
código y la clase de pruebas.

Página 39
PARTE III: DESARROLLO CON HERRAMIENTA
DE MEDICIÓN
1 PLAN DE PRUEBAS DE SOFTWARE:
1.1 Enfoque de pruebas
En este capítulo vamos a ver los tipos de pruebas según se realizan dentro del ciclo de vida
del software.
Existen diferentes modelos de desarrollo de software. Entre ellos tenemos métodos clásicos
como pueden ser el modelo en cascada, el modelo general en V o métodos más populares
hoy en día como pueden ser metodologías ágiles, programación extrema, etc. Cada uno de
estos métodos tiene una vía de trabajo diferente, indicando cómo se tiene que trabajar
durante la vida del proyecto.
Las pruebas están dentro de estos modelos de maneras muy diferentes. Por ejemplo, dentro
del modelo en cascada las pruebas se ejecutan al final del proyecto y dentro del modelo en
V se realizan en los diferentes niveles de desarrollo.
1.5.1 Modelo en V:
Se va a utilizar el modelo en V como referencia para ver cómo se integran las pruebas
dentro del ciclo de vida del software. En este modelo las tareas de desarrollo y pruebas
tienen la misma importancia.

Página 40
1.5.2 Niveles de prueba:
Para cada nivel de desarrollo se define un nivel de prueba. Dentro de cada nivel de prueba
el probador debe asegurarse de que los resultados cumplen con la verificación y la
validación del software.
2 HERRAMIENTA DE CALIDAD DEL PRODUCTO (SonarQube)
Las herramientas de medición descritas con anterioridad para el SRA, deberá ser
capacitado en su uso y procedimiento a continuación el detalle.
2.1 Instalación y descripción de uso del SonarQube:

● Paso 1: Descargar SonarQube

Página 41
● Paso 2: Iniciar el servicio StartSonar.bat para levantar la plataforma local.
● Paso 3: Loguearnos en la plataforma “Localhost:9000”

Página 42
● Paso 4: Crear un nuevo proyecto “Add project/Manually/ *ingresar un nombre*.
● Paso 5: Crear el archivo sonar-project.properties en nuestra carpeta raíz, este

archivo debe contener el nombre del proyecto que ingresamos en el paso 4.

Página 43
● Paso 6: Descargamos SonarScanner, descomprimimos y copiamos el contenido en
la carpeta de SonarQube.
● Paso 7: Añadimos la variable de entorno “sonar-scanner\bin\...:”

Página 44
● Paso 8: Iniciamos el servicio “sonar-scanner.bat” mediante consola.
● Paso 9: Analizamos el resultado final en la plataforma identificando errores, bugs y

vulnerabilidades de seguridad.

Página 45
3.2 Leyenda de la herramienta:
● Tipos de problemas: Existen 3 tipos de problemas

1. Bug: un error de codificación que romperá su código y debe corregirse
de inmediato.
2. Vulnerabilidad: un punto en su código que está abierto a ataques.
3. Code Smell: un problema de mantenimiento que hace que su código sea

confuso y difícil de mantener.

Página 46
4. Security Hubspot: Un Security Hotspot destaca un fragmento de código
sensible a la seguridad que el desarrollador debe revisar. Tras la revisión,
encontrará que no existe ninguna amenaza o debe aplicar una solución para
proteger el código .
2.3 Gravedad del problema:

Cada problema tiene una de cinco grados de gravedad:
● Bloqueador
Error con una alta probabilidad de afectar el comportamiento de la aplicación en

producción: pérdida de memoria, conexión JDBC no cerrada, El código DEBE ser
reparado inmediatamente.
● Crítico
O un error con baja probabilidad de afectar el comportamiento de la aplicación en

producción o un problema que representa un defecto de seguridad: bloqueo de
captura vacío, inyección SQL, El código DEBE ser revisado inmediatamente.
● Importante
Defecto de calidad que puede afectar en gran medida la productividad del

desarrollador: código descubierto, bloques duplicados, parámetros no utilizados
● Menor
Defecto de calidad que puede afectar ligeramente la productividad del

desarrollador: las líneas no deben ser demasiado largas, las declaraciones de
"cambio" deben tener al menos 3 casos.
● Info
Ni un error ni un defecto de calidad, solo un hallazgo.

Página 47
Estados: Después de la creación, los problemas fluyen a lo largo de un ciclo de vida,
tomando uno de los cinco estados posibles:
● Abierto: establecido por SonarQube en problemas nuevos

● Confirmado: se configura manualmente para indicar que el problema es válido
● Resuelto: configurarlo manualmente para indicar que el siguiente análisis debe
cerrar el problema
● Reabierto: configurado automáticamente por SonarQube cuando un
problema resuelto no se ha corregido realmente
● Cerrado: configurado automáticamente por SonarQube para problemas creados
automáticamente.
Resoluciones: Los problemas cerrados tendrán una de dos resoluciones:
● Solucionado: se configura automáticamente cuando un análisis posterior muestra

que el problema se ha corregido o que el archivo ya no está disponible (eliminado
del proyecto, excluido o renombrado)
● Eliminado: se establece automáticamente cuando la regla relacionada ya no está
disponible. Es posible que la regla no esté disponible porque se eliminó del Perfil de
calidad o porque se desinstala el complemento subyacente.
● Los problemas resueltos tendrán una de dos resoluciones:
● Falso positivo: configurar manualmente
● No se arregla: configurar manualmente
Mejora de la calidad:
Como podemos observar en la siguiente imagen, después de toda la leyenda existe

un apartado llamado “Cómo solucionarlo?” es ahí donde nos da los parámetros y
recomendaciones para que el código deje de presentar dicho problema

Página 48
3 HERRAMIENTA DE PRUEBAS UNITARIAS (PHPUnit)
3.1 Instalación y descripción de uso del PHPUnit:
● Paso 1: Para la instalación de PHPUnit debemos tener PHP instalada, verificar la

versión de PHP que poseemos, para poder descargar con la versión de PHPUnit
indicado para dicha versión, cabe resaltar que por cada vr. de PHP hay una vr. de
PHPUnit compatible.(aunque se recomienda siempre tener las últimas
versiones actualizadas.)
● Paso 2: Ahora añadimos la variable de entorno en el sistema, en path

agregamos la siguiente variable “ c:\xampp\php\php.exe”

Página 49
● Paso 3: Ahora para instalar PHPUnit vamos a la Url. https://phpunit.de/getting-
started/phpunit-9.html y visualizamos que hay 2 formas de poder instalar el
PHPUnit.
● Paso 4: Ahora instalaremos el Composer(herr. enfocada al uso de PHP) para ello

iremos a descargar al siguiente Url. https://getcomposer.org/ luego instalamos.
● Paso 5: Luego verificamos la versión del composer instalada.

Página 50
● Paso 6: Ahora ejecutamos el composer para la instalación de PHPUnit, para ello
creamos una carpeta y desde el cmd ejecutamos el siguiente código: composer
require phpunit/phpunit --dev
● Paso 7: Ahora vamos a crear una carpeta y dentro de ella 2 carpetas

llamadas SCR, Tests y vendor y el composer.jason
● Paso 8: Ahora dentro del archivo composer.jason realizamos el siguiente

código para la auto carga de los archivos del dev. y de pruebas.

Página 51
● Paso 9: Ahora ejecutamos otro comando composer de autocarga para obtener las
actualización del archivo desarrollador y archivo de prueba con el comando:
composer dumpautoload.
● Paso 10: Realizaremos ejemplos, nuestro archivo es ejem, y el de pruebas es

ejemTest, recordemos que las pruebas unitarias deben estar dentro de una clases
y serán evaluadas el resultado esperado con el resultado real. con el comando
indicado en imagen.

Página 52
● Paso 9: ejecutamos la siguiente línea de comando vendor/bin/phpunit tests esta
línea de comando es para hacer el llamado de phpunit en el archivo de prueba, la
prueba muestra en el primero nos muestra una letra “E”, que significa error y un
punto “.” para una aceptación.

Página 53
3.2 Leyenda de herramienta:
Tipos de problemas: que muestra el PHPUnit.
Signo de punto “.”: Se imprime cuando la prueba es exitosa.
F: Se imprime cuando una aserción falla mientras se ejecuta un método de prueba.
E: Se imprime cuando ocurre un error mientras se ejecuta un método de prueba.
R: Se imprime cuando una prueba se ha marcado como riesgosa ( Pruebas Riesgosas).
S: Se imprime cuando la prueba ha sido omitida.
I: Se imprime cuando la prueba se marca como incompleta o aún no implementada.
3.3 Gravedad del Problema:

Por defecto PHPUnit instalará un gestor de errores que convierte los siguientes errores en excepciones:
E_WARNING
E_NOTICE
E_USER_ERROR

Página 54
E_USER_WARNING
E_USER_NOTICE
E_STRICT
E_RECOVERABLE_ERROR
E_DEPRECATED
E_USER_DEPRECATED
4 PRUEBAS UNITARIAS A 2 PROCESOS: Evaluación

4.1 PHPUnit ejemplo
➔ PHPUNIT ejemplo:
➔ En este archivo del desarrollador, tenemos la clase saludo, con una función que
retorna un string.
➔ En este archivo para realizar las pruebas, donde hacemos el llamado de la

clase que se desarrolló. y haciendo uso de Framework de PHPUnit.

Página 55
➔ Como primera instancia podemos observar el funcionamiento de las clases creadas
con éxito mediante el símbolo de un “check” en la consola o terminal, como
también nos puede exportar con el mismo check en diferentes formatos.
➔ como también nos puede exportar con el mismo check en diferentes

formatos. Como también revisar la documentación de PhpUnit testdox.
➔ Asimismo es necesario mencionar que para poder ejecutar las diferentes

herramientas de testeo que nos proporciona “PHPUnit” debemos tener
instalado y en ejecución el xdebug de php en nuestro ordenador.

Página 56
➔ “PHPUnit” nos permite generar reportes de nuestras pruebas realizadas, a través de
las cuales podemos observar las métricas mediante un dashboard, el cual mostrará:
◆ Coverage Distribution
◆ Complexity
◆ Project Risks
◆ Insufficient Coverage
➔ Como podemos observar nos presenta un alto grado de funcionalidad y corto

tiempo de ejecución, indicando en base a colores.

Página 57
➔ También nos permite poder visualizar nuestro código en caso haya algún error,
todo esto gracias al xdebug de php que anteriormente debimos poner en
ejecución.
● ahora le mostramos la cobertura en forma de dashboard.

Página 58
● Mismo ejemplo en SonarQube: En este caso SonarQube no detectó ni un bug,
vulnerabilidad o problemas de seguridad.
En este caso SonarQube no detectó ni un bug, vulnerabilidad o problemas de

seguridad.

Página 59
Sin embargo, que no haya detectado ni un error no significa que haya algún inconveniente
con el código, lo que nos detecta SonarQube es que el fragmento de código no puede ser
cubierto por la herramienta.
4.2 SonarQube ejemplo sra:
➔ Ingreso al portal del sistema de Registro de Asistencia. ingresamos usuario y

password.
➔ con la información del usuario, marcamos el ingreso o salida de la asistencia diaria.

Página 60
➔ muestra del codigo en el que se obtiene el registro de asistencia del usuario.

Página 61
En dicha prueba nos indica muestra una recomendación sobre nuestra conexión de host.
➔ La carga de archivos de nuestro proyecto.

Página 62
Aquí nos muestra líneas de código que el SonarQube no examina, en este caso es la conexión a la base de da
5 Benchmarking:
Cuadro comparativo entre el sonarqube y el phpunit.
ATRIBUTOS SONARQUBE PHPUNIT

PRUEBAS UNITARIAS x
PRUEBAS FUNCIONALES x
PRUEBAS NO FUNCIONALES x
PRUEBAS DE ACEPTACIÓN
PRUEBAS ESTÁTICAS
CAJA NEGRA x x
CAJA BLANCA

Página 63
3 Entregables de pruebas
Cuando el cliente apruebe la entrega de la solución y su funcionamiento, mediante las cartas
de aceptación, será responsable del uso de la solución.
● Formato de casos de pruebas:
<Nombre caso de prueba> <Código del CP>

Descripción: <Descripción del caso de prueba>
Prerrequisitos: <Enumerar los prerrequisitos para la prueba>
Pasos: <Pasos generales para la prueba, basados en los escenarios de los casos de uso, si existen.>
Resultado esperado: <Resultado esperado de la prueba>

Resultado obtenido: <Resultado obtenido de la ejecución del caso de prueba>
Evaluación de la prueba: <Estado obtenida de la ejecución del caso de prueba>
● Plan de pruebas unitarias: (PPU_(PROY)_Plan_Pruebas_Unitarias)

● Plan de pruebas funcionales:(PPF_[PROY]_Plan_Pruebas_Funcionales)
● Plan de pruebas de Integración:(PPI_(PROY)_Plan_Pruebas_Integracion)

Página 64
Referencia
Referencia Título Ruta Fecha Autor
ERS 3.0 ERS 3.0_standalone_v1.2 --- 17/12/2018 ---
IEEE 830 Especificación de Requisitos --- 22/10/2008 ---

Página 65
según el estándar
de IEEE 830
ANEXOS SUGERIDOS:
1 PROJECT CHARTER
Datos
Empresa / Organización DynamiCall

Proyecto Sistema de registro de asistencia
Fecha de preparación 16/04/21
Cliente
Enrique Beltrán Cornejo
Patrocinador principal Alarcón Castillo, Carlos Franco

Rojas Espinoza, Juan Carlos
Sánchez López, Fabian Leonel
Tasayco tuanama, Luis fernando
Vásquez Medina, Ana Kelly
Gerente de proyecto Vásquez Medina, Ana Kelly
Propósito y justificación del proyecto
● Delimitar las especificaciones funcionales y no funcionales del sistema web

SRA, el cual permitirá gestionar la información detallada de cada uno de los
colaboradores mediante el registro de ingresos, de los mismos.
● Evaluar los errores y defectos que pueden existir en un sistema, con el fin de
corregirlos.
● Verificar que los validadores de datos funcionen y limiten el ingreso de
información, para que no se puedan ingresar datos que no están permitidos.
● El sistema tendrá que pasar evaluaciones de aceptación de los colaboradores y
supervisores.
● Con el requisito de optimizar los procesos de recursos humanos para validar las
asistencias de nuestros colaboradores.

Página 66
Descripción del proyecto y entregables
El proyecto consiste en la implementación de un sistema que permita el registro de

Requerimientos dedealto
asistencias con el reporte nivelpara facilitar el reporte completo de todos
las mismas
los ingresos y salidas en el horario laboral al asesor de los colaboradores, en la
Requerimientos
empresa DynamiCall. del producto
Los responsables del proyecto serán:
● Alarcon
El sistema deberáCastillo Carlos
permitir Franco - Backend
al administrativo, testing
jefe administrativo y administrador
Requerimientos
● Rojas del proyecto
Espinoza Juan Carlos - Desarrollador frontend
del sistema iniciar sesión una vez ya esté registrado, ingresando usuario y
● Sánchez López Fabián Leonel - Administrador de base de datos
contraseña.
Un gerente
● Tasayco
El sistema de proyecto
deberáTuanama
permitir, Luis - Desarrolladorjefe
al administrativo, backend
administrativo y administrador
Aprobación
● Vasquez
del sistema del estudio
cerrarMedina, de requerimientos en el
sesión. Kelly - Analista de sistemas, área delíder
RRHH del Aprobación
proyecto. de
la inversión
Como
El para latenemos:
entregables
sistema deberá implementación del sistema y jefe administrativo marcar su
permitir al administrativo
Aprobación
● de
Ingreso la
al evaluación
sistema de
mediante la
ingreso, y salida del horario laboral. Siemprecantidad
una de personal
interfaz web.
que y los diferentes
se encuentre cargos
con inicio deEntregar
sesión.
un
El informe
● Registro
sistema mensual
deberá de las actividades
de ingreso
permitir dealasistenciasrealizadas, eljefe
cual
de losyusuarios
administrativo será revisado
mediante
administrativo y aprobado
un clic.
listar sus por el
jefe
horas●dederecursos
trabajohumanos.
Registro deensalida de asistencias
rangos de los usuariospor
de fechas seleccionadas mediante
él. un clic.
● Búsqueda
El sistema deberádepermitir
usuariosalpor rol correspondiente
administrativo y jefe en el sistema imprimir su lista
administrativo
● Generar
de horas trabajadas.un reporte de las asistencias registradas

Página 67
Objetivos
Objetivo Indicador de éxito
Alcance
Aprobación de todos los
● Cumplir con la elaboración de los entregables entregables por parte del
● Especificación de requerimientos directorio de la empresa.
● Plan de pruebas.
● Estudio de 2 herramientas de pruebas.
Cronograma (Tiempo)
El proyecto tendrá una duración de 5 meses a partir del cumplir con los tiempos
mes de marzo hasta julio del presente año. establecidos en el
cronograma.
Costo
5,000 PEN es el costo en la implementación del No exceder el presupuesto
sistema de registro de asistencias y reporte. del proyecto
Calidad
● Informe de plan de pruebas del proyecto. Aprobación de todos los
● Cumplir con los criterios de Aceptación. entregables.
● Benchmarking de las herramientas de prueba.
Premisas y restricciones
Para que el plan de pruebas se pueda llevar a cabo se debe tener:

Riesgos iniciales de alto nivel
➢ Disponibilidad de tiempo.
➢ Disponibilidad de recursos.
➢ Metodología de las pruebas
➢ Uso de herramientas
➢ Conocimiento de las pruebas por los integrantes del grupo.
Para que el plan de pruebas del SISTEMA DE REGISTRO DE ASISTENCIA se dé por

concluido se deben de cumplir las siguientes actividades.
Probar cada interfaz del sistema.

Probar logeo.
Probar ingreso y salida de asistencia.
Probar el botón registro de asistencias.
La restricción del sistema tendrá un entorno accesible y amigable para poder realizar
los registros.

Página 68
Retraso de en el desarrollo de los módulos del sistema
Fallos imprevistos en el sistema Levantamiento de requerimientos incompleto Problemas con los recursos hu
Cronograma de hitos principales

Hito Fecha tope
Desarrollo del inicio de sesión 19/05/21
Desarrollo del cierre de sesión 28/0521
Desarrollo del método de marcaje de asistencia 04/06/21
Desarrollo del método para listar las horas trabajadas. 11/06/21
Desarrollo del método para imprimir la lista de horas trabajadas. 18/06/21
Presupuesto estimado
Desarrollo del sistema de asistencias 5.000
Mantenimiento/actualización del 2.000
sistema de asistencias, con posibles
nuevas integraciones.
Lista de Interesados (stakeholders)

Nombre Cargo
CEO y Fundador
Enrique Beltrán Cornejo
Gianfranco Giuttari Claussi Gerente de Administración y

Finanzas
Carlos Basurto Yamani Gerente de TI
Maritza Puma Estrada Directora de Operaciones
Carolina Venegas Gala Gerente de Operaciones
Angélica Mesta Romero Gerente de Operaciones
Magaly Alvarado Caldas Gerente de Negocios
Ursula Valdez Calmet Sub Gerente de Control de Gestión
Requisitos de aprobación del proyecto
Acta de reconocimiento de prácticas pre-profesionales.

El análisis económico debe mostrar una rentabilidad adecuada frente a la

Página 69
propuesta de implementación.
Asignación del gerente de proyecto y nivel de autoridad

Gerente de proyecto
Nombre Cargo Departamento /

División
Carlos Basurto Gerente de TI área de TI
Yamani
Niveles de autoridad
Área de autoridad Descripción del nivel de autoridad

Decisiones de personal (Staffing) Gerente de TI
Gerente de Administración y Finanzas
Gestión de presupuesto y de sus Gerente de TI
variaciones Gerente de Administración y Finanzas
Decisiones técnicas Gerente de TI
Resolución de conflictos Gerente de TI
Ruta de escalamiento y limitaciones de Organigrama
autoridad
Aprobaciones
Patrocinador Fecha Firma
Carlos Basurto Yamani 19/05/21
Gianfranco Giuttari Claussi 28/05/21

Página 70
2 ESTRUCTURA DE DESGLOSE DE TRABAJO: EDT
EDT proyecto de sistemas de registro de asistencia
3 JMeter
Es una herramienta que facilita la gestión integral de los procesos de pruebas de
rendimiento, no obstante no es la única puesto que tenemos otras como: Micro Focus
LoadRunner, IBM RPT, SilkPerformer, WebLoad, NeoLoad, OpenSTA, otras.
‘Apache JMeter’ es una aplicación de código abierto, 100% basada en Java con una interfaz
gráfica de usuario. Está diseñada para analizar, medir el rendimiento y cargar el
comportamiento funcional de la aplicación web y la variedad de servicios.
Tipo de prueba

Página 71
·No funcional
Subconjunto
· Las pruebas de carga, las pruebas de estrés, las pruebas de picos, las pruebas de
resistencia y las pruebas de volumen son subconjuntos de las pruebas de rendimiento.
JMeter se utiliza principalmente para:
● probar aplicaciones web

● aplicaciones FTP
● pruebas funcionales
● conexiones de bases de datos JDBC
● servicios web
● conexiones TCP genéricas
● procesos nativos del sistema operativo
Objetivo se realizan las actividades mencionadas
· Para obtener métricas de rendimiento precisas en su servidor web.
EJEMPLO

Página 72
Página 73
f

Página 74

G05 - Plan de Pruebas de SRA-ejm

Cargado por

Información del documento

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

G05 - Plan de Pruebas de SRA-ejm

Cargado por

Copyright:

Formatos disponibles

SISTEMA DE REGISTRO DE ASISTENCIA - ANÁLISIS DE

Plan de Pruebas del Sistema de Registro de Asistencia

GIRO DEL NEGOCIO 6

PROCESOS PRINCIPALES DE LA EMPRESA 8

PLANEAMIENTO ESTRATÉGICO DE TECNOLOGÍAS DE INFORMACIÓN: 10

PARTE II: PLAN DE GESTIÓN DE PROYECTO DE PRUEBAS DEL SRA. 13

INFORMACIÓN DEL PROYECTO 13

Definiciones, acrónimos y abreviaturas 16

1.1 DESCRIPCIÓN GENERAL 17

1.1.1 Perspectiva del producto 17

1.1.2 Funcionalidad del producto 18

1.1.3 Modelamiento de Casos de uso de SRA: 18

1.1.4 Características de los usuarios 21

1.1.6 Suposiciones y dependencias 22

1.1.7 Evolución previsible del sistema 22

1.2 REQUISITOS ESPECÍFICOS 22

Plan de Pruebas del Sistema de Registro de Asistencia

1.2.1.1 Interfaces de usuario 22

1.2.1.2 Interfaces de hardware 22

1.2.1.3 Interfaces de software 23

1.2.1.4 Interfaces de comunicación 23

1.2.2 REQUISITOS FUNCIONALES 23

1.2.2.1 Ingreso a la aplicación 23

1.2.2.2 Administración de asistencia 24

1.2.2.3 Administración de reporte 24

1.2.3 REQUISITOS NO FUNCIONALES 25

1.2.3.1 Requisitos de rendimiento 25

1.2.4 Otros requisitos 26

2 PLAN DE GESTIÓN DE CALIDAD 26

2.1 ALCANCE DE LAS PRUEBAS 26

2.1.1 Elementos de pruebas 26

2.1.2 Nuevas funcionalidades a probar. 26

2.1.3 Pruebas de regresión 28

2.1.4 Funcionalidades a no probar 29

2.2 PROCEDIMIENTOS PARA LAS PRUEBAS 29

2.2.1 Criterios de aceptación o rechazo 30

2.2.2 Criterios de suspensión 31

2.2.3 Criterios de reanudación 33

2.2.4 Roles del personal: 33

2.2.5 Matriz de responsabilidades: 34

Plan de Pruebas del Sistema de Registro de Asistencia

2.2.8 Dependencias y Riesgos: 37

2.3 RECURSOS Y HERRAMIENTAS DE PRUEBAS 37

2.3.1 Requerimientos de Entornos – Hardware 37

2.3.2 Requerimientos de Entornos – Software 37

2.3.3 Herramientas de Pruebas Requeridas 38

PARTE III: DESARROLLO CON HERRAMIENTA DE MEDICIÓN 40

1 PLAN DE PRUEBAS DE SOFTWARE: 40

1.1 Enfoque de pruebas 40

2 HERRAMIENTA DE CALIDAD DEL PRODUCTO (SonarQube) 41

2.1 Instalación y descripción de uso del SonarQube: 41

3.2 Leyenda de la herramienta: 46

2.3 Gravedad del problema: 47

3 HERRAMIENTA DE PRUEBAS UNITARIAS (PHPUnit) 49

3.1 Instalación y descripción de uso del PHPUnit: 49

3.2 Leyenda de herramienta: 55

3.3 Gravedad del Problema: 55

4 PRUEBAS UNITARIAS A 2 PROCESOS: Evaluación 56

4.1 PHPUnit ejemplo 56

4.2 SonarQube ejemplo sra: 61

Plan de Pruebas del Sistema de Registro de Asistencia

2 ESTRUCTURA DE DESGLOSE DE TRABAJO: EDT 71

Plan de Pruebas del Sistema de Registro de Asistencia

La necesidad concreta es la de proporcionar una herramienta que permita a los