About arc42
arc42, the template for documentation of software and system architecture.
Template Version 8.2 EN. (based upon AsciiDoc version), January 2023
Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. See https://arc42.org.
1. Introducción y Objetivos 🎇
El proyecto WIQ 04D es un desarrollo en el marco de la asignatura de Arquitectura del Software, que consiste en la creación de una aplicación web similar al estilo de "Saber y Ganar". Este es un juego de preguntas de cultura general que se generan automáticamente con la ayuda de Wikidata, una base de conocimientos accesible tanto para humanos como para máquinas.
Los desarrolladores de la aplicación son Zohaib Akhtar Kausar, Yago Navajas González y Santiago López Laso.
1.1. Requisitos Funcionales
1.2. Atributos de Calidad
| Prioridad | Objetivo | Descripción |
|---|---|---|
1 |
Usabilidad |
La aplicación debe ser accesible y fácil de usar para todos los usuarios, independientemente de sus limitaciones. |
2 |
Rendimiento |
Los tiempos de respuesta deben ser adecuados, incluso con múltiples usuarios accediendo a la aplicación simultáneamente. |
3 |
Seguridad |
Los datos sensibles de los usuarios deben estar protegidos y accesibles únicamente para cada usuario. |
4 |
Mantenibilidad |
El código y la documentación de la aplicación deben estar organizados de manera que faciliten futuras modificaciones y ampliaciones. |
5 |
Portabilidad |
La aplicación web debe ser compatible con los navegadores más utilizados como Chrome, Firefox, Safari y Edge. |
1.3. Stakeholders
| Rol/Nombre | Contacto | Expectativas |
|---|---|---|
Equipo de Desarrollo |
Yago Navajas González |
Estudiantes encargados del desarrollo de la aplicación, incluyendo la arquitectura, la documentación y la codificación. |
Profesores |
Jose Emilio Labra Gayo |
Supervisores de los avances y encargados de evaluar la aplicación final y su desarrollo. |
Usuarios |
Jugadores de la aplicación |
Personas que interactuarán con el registro de usuarios y el juego, y deberán ser capaces de completar una partida correctamente. |
HappySw |
Empresa responsable |
Empresa contratada para colaborar en el desarrollo del juego junto al equipo de desarrollo. |
Wikidata |
Proveedor de la información para las preguntas |
Interesado en el éxito de la aplicación como forma de obtener publicidad gratuita. |
RTVE |
Empleador |
Interesados en la creación del juego e impulsores de su desarrollo. |
2. Restricciones de arquitectura ⛔
| Restricción | Descripción |
|---|---|
Wikidata |
El uso de Wikidata para obtener información para las preguntas es obligatorio. Las principales limitaciones de esta API incluyen el número máximo de consultas por unidad de tiempo y la disponibilidad de datos, lo que puede repercutir en los tiempos de carga. |
Git |
Posibilidad de conflictos cuando varios miembros del equipo trabajan simultáneamente en el mismo recurso, requiriendo una gestión cuidadosa de las ramificaciones y fusiones. |
GitHub |
La falta de experiencia con GitHub puede conducir a problemas en la gestión del proyecto y en el despliegue del mismo, impactando la eficacia del trabajo en equipo y la entrega de resultados. |
Integración continua/despliegue continuo (CI/CD) |
Restricciones en la configuración de pipelines de CI/CD pueden limitar la capacidad para automatizar pruebas, compilaciones y despliegues en un servidor Docker, afectando la velocidad y frecuencia de actualizaciones y correcciones. |
3. Alcance del sistema y Contexto 💭
3.1. Contexto de negocio
4. Estrategia de Solución 📚
4.1. Decisiones tecnológicas
-
Se utilizará la biblioteca de JavaScript, React, para facilitar la implementación de la interfaz de usuario.
-
Se adoptará una arquitectura basada en microservicios para los diferentes componentes del proyecto, como la generación de preguntas y el registro de usuarios.
-
Para el alojamiento de la página web, se utilizará una máquina virtual de Azure aprovechando el crédito para estudiantes proporcionado.
-
Se empleará GitHub Actions para el despliegue automático del proyecto, complementado con tests para asegurar su correcta ejecución.
-
Se realizarán pruebas de usabilidad para verificar la facilidad de uso de la aplicación.
-
Se efectuarán pruebas de carga para evaluar el rendimiento de la aplicación.
4.2. Decisiones organizativas
-
Este grupo (wiq_es04d) se formó a partir de un grupo preexistente (wiq_es04c), reduciendo su tamaño de cinco a tres integrantes. Se decidió retomar el proyecto inicial tras la disolución del grupo anterior, empezando de cero.
-
No se ha establecido una división clara de roles específicos; todos los integrantes participan en todas las áreas.
-
Se llevará a cabo al menos una reunión semanal en clase para organizar y revisar el progreso del trabajo, así como planificar las siguientes tareas. Se podrán realizar reuniones adicionales fuera del horario de clase.
5. Vista de Bloque de Construcción 🔨
5.1. Sistema general de caja blanca
Este diagrama del sistema general muestra una descripción del sistema con los componentes básicos.
- Bloques de Construcción Contenidos
-
-
Wiq_es0d: la aplicación web. Los usuarios pueden usarla para jugar o pueden usar su API. Usa Wikidata para generar las preguntas.
-
5.2. Nivel 2
5.2.1. Caja blanca webapp
Interfaz web.
5.2.2. Caja blanca gatewayservice
Puente entre webapp y resto de componentes.
5.2.3. Caja blanca questionservice
Generador de las preguntas.
5.3. Nivel 3.
5.3.1. Caja blanca authservice
Gestión del inicio de sesión.
5.3.2. Caja blanca historyservice
Gestión del histórico de participación de los usuarios en el sistema.
5.3.3. Caja blanca userservice
Gestión del registro de usuarios.
6. Vista de Ejecución 📽️
6.1. Escenario de Ejecución 1
Este escenario describe el proceso de jugar una partida cuando la base de datos cuenta con suficientes preguntas disponibles. El proceso implica mostrar una pregunta y procesar la respuesta del usuario. Esto se repite para cada una de las 3 preguntas en la partida. La pregunta "n" representa la última pregunta de la serie.
6.2. Escenario de Ejecución 2
Este escenario aborda una partida cuando la base de datos no tiene suficientes preguntas. Hasta el momento de "acceder al juego", la ejecución sigue el mismo flujo que el escenario de ejecución 1. Desde "mostrar primera pregunta", la ejecución continúa conforme al escenario de ejecución 1.
7. Vista de Despliegue 👀
7.1. Diagrama de Despliegue
Este diagrama ilustra cómo interactúan los diferentes servicios del sistema.
La arquitectura del sistema está compuesta por varios servicios, cada uno contenerizado usando Docker y desplegados en una máquina virtual de Azure. A continuación se describen los servicios principales y su función dentro del sistema:
7.2. Servicios
-
WebApp
Tecnología: React
Descripción: Interfaz de usuario que proporciona funcionalidades de inicio de sesión, registro, juego y revisión de historial y ranking.
Interacción: Comunica con el Gateway Service para todas las operaciones. -
Gateway Service
Tecnología: Express
Descripción: Actúa como un proxy para los servicios internos, exponiendo una API unificada hacia la WebApp. -
User Service
Tecnología: Express
Descripción: Maneja operaciones relacionadas con usuarios, incluyendo inserción de nuevos registros.
Base de Datos: MongoDB (Colección: userdb). -
Auth Service
Tecnología: Express
Descripción: Procesa la autenticación de usuarios.
Base de Datos: MongoDB (Colección: userdb). -
Question Service
Tecnología: Express
Descripción: Genera preguntas y realiza consultas a la API de Wikidata.
Base de Datos: MongoDB (Colección: questiondb). -
History Service
Tecnología: Express
Descripción: Administra el historial de juegos de los usuarios y maneja el ranking.
Base de Datos: MongoDB (Colección: historydb). -
MongoDB
Descripción: Base de datos no relacional que almacena datos de usuarios, preguntas y historiales de juego.
7.3. Monitoreo
-
Prometheus
Descripción: Sistema de monitoreo y alerta que recolecta métricas de los diferentes servicios. Utilizado para mantener la visibilidad del rendimiento y la salud operativa de los servicios dentro de la arquitectura del sistema.Configuración: Configurado para realizar scraping cada 5 segundos al servicio Gateway, que es el punto central de comunicación y datos para la aplicación. La configuración específica define un solo trabajo de scraping que apunta al servicio Gateway en el puerto 8000. Esta configuración está diseñada para ser simple y directa, enfocada en la recolección eficiente de métricas críticas.
-
Grafana
Descripción: Herramienta de visualización y análisis que transforma los datos recolectados por Prometheus en dashboards interactivos y detallados.
8. Conceptos Transversales 🧭
8.1. Experiencia de Usuario
La Experiencia de Usuario en nuestra aplicación refleja la impresión general que los usuarios tienen al interactuar con ella. Se refiere a cómo se sienten y qué piensan al utilizar nuestra aplicación web, incluyendo aspectos como la facilidad para registrarse, iniciar sesión y lo intuitivo del juego de preguntas.
Para nuestra aplicación, la Experiencia de Usuario implica comprender profundamente las necesidades y expectativas de nuestros usuarios. Siguiendo la regla de "Keep It Simple Stupid" (KISS), hemos diseñado cada aspecto de la interfaz para que sea lo más sencillo y directo posible, facilitando una experiencia efectiva y agradable. Esto implica asegurar que la navegación sea intuitiva, que la información esté clara y accesible, que las acciones sean fáciles de realizar y que el sistema responda de manera rápida y confiable a las interacciones del usuario.
Nos esforzamos por crear una experiencia de usuario cómoda y accesible, donde cada detalle está cuidadosamente diseñado para brindar una experiencia fluida y satisfactoria. Nuestro objetivo es ofrecer un juego entretenido y funcional, manteniendo la simplicidad en cada elemento.
8.2. Arquitectura
Utilizaremos una arquitectura basada en microservicios para mantener la independencia entre las distintas partes de la aplicación. Esta estructura ofrece una arquitectura flexible y modular, con beneficios significativos en términos de escalabilidad, flexibilidad tecnológica, agilidad en el desarrollo, resistencia a fallos y facilidad de mantenimiento.
8.3. Desarrollo
En el desarrollo de nuestra aplicación, nos centramos en varios aspectos clave para garantizar su eficacia:
-
Mantenibilidad del código: Escribimos nuestro código de manera clara y organizada, siguiendo las mejores prácticas de desarrollo para facilitar su mantenimiento y futuras actualizaciones.
-
Automatización de pruebas: Implementamos pruebas automatizadas para asegurar que nuestra aplicación funcione correctamente bajo diferentes situaciones y escenarios. Esto nos ayuda a identificar y corregir errores de manera oportuna, manteniendo la calidad del software.
-
Integración continua: La implementación exitosa de CI/CD proporciona un camino continuo hacia la entrega de software de alta calidad, permitiendo la automatización de pruebas, integración y despliegue, agilizando así el ciclo de vida del desarrollo y garantizando una entrega rápida y confiable de valor al cliente.
-
Optimización de rendimiento: Nos esforzamos por mejorar el rendimiento de nuestra aplicación, optimizando el tiempo de carga, la velocidad de respuesta y el consumo de recursos.
8.4. Gestión del proyecto
En la gestión de nuestro proyecto, nos enfocamos en garantizar un entorno de producción estable y eficiente:
-
Gestión de infraestructura: Utilizamos una máquina virtual de Azure para administrar la infraestructura de nuestra aplicación, garantizando su disponibilidad y rendimiento óptimo.
-
Gestión de versiones: Gestionamos las versiones utilizando etiquetas (tags) en nuestro proyecto de GitHub, que luego se despliegan en la máquina virtual, asegurando actualizaciones controladas y sin interrupciones en el servicio.
-
Desarrollo del equipo: Nuestro equipo ha progresado en el proyecto mediante el autoaprendizaje de las tecnologías utilizadas, garantizando una comprensión profunda de la aplicación y manteniendo un entorno operativo eficiente.
8.5. Seguridad
Nos comprometemos a proteger la información personal y sensible de nuestros usuarios, así como a prevenir vulnerabilidades que puedan comprometer su seguridad mientras utilizan nuestra aplicación web, dentro de nuestras capacidades y conocimientos.
Para ello, implementamos medidas de seguridad como la encriptación de datos y la autenticación de usuarios mediante contraseñas.
Queremos que nuestros usuarios se sientan seguros y protegidos mientras utilizan nuestra aplicación.
9. Decisiones de Arquitectura 🗣️
10. Requisitos de Calidad 🌟
10.1. Árbol de Calidad
El árbol de calidad se organiza con "calidad" como raíz, desglosándose en varias ramas principales, que representan categorías de calidad relevantes para el proyecto WIQ. Estas ramas incluyen:
-
Usabilidad: Se refiere a la facilidad con la que los usuarios pueden utilizar un sistema para alcanzar sus objetivos de manera eficiente y satisfactoria. La usabilidad implica interfaces intuitivas, accesibilidad y una experiencia de usuario agradable.
-
Rendimiento: Evalúa la eficiencia del sistema en términos de velocidad de respuesta, consumo de recursos y escalabilidad. Un buen rendimiento asegura que el sistema puede manejar cargas de trabajo elevadas con tiempos de respuesta rápidos.
-
Seguridad: Implica proteger la información y los sistemas contra accesos no autorizados, divulgación, alteración o destrucción, garantizando la confidencialidad, integridad y disponibilidad de los datos.
-
Mantenibilidad: Se refiere a la facilidad con la que un sistema puede ser modificado para corregir fallos, mejorar su funcionamiento o adaptarse a un entorno cambiante. Una alta mantenibilidad facilita las actualizaciones y reduce los costos a largo plazo.
-
Portabilidad: La capacidad de un sistema para ser utilizado en diferentes entornos operativos con mínimas modificaciones. La portabilidad permite que el software sea compatible con diversos dispositivos, sistemas operativos o navegadores webs.
10.2. Escenarios de Calidad
10.2.1. Usabilidad
-
Escenario: Un nuevo usuario puede registrarse e iniciar a jugar en menos de 2 minutos después de su primer acceso al sitio web. La interfaz intuitiva y la guía de inicio rápido facilitan este proceso.
10.2.2. Rendimiento
-
Escenario: El sistema responde a las solicitudes de los usuarios en menos de 0,5 segundos bajo condiciones normales de carga, asegurando una experiencia de juego fluida.
10.2.3. Seguridad
-
Escenario: Todos los datos personales de los usuarios están cifrados tanto en tránsito como en reposo, utilizando estándares de seguridad actuales para prevenir accesos no autorizados.
10.2.4. Mantenibilidad
-
Escenario: El sistema permite la adición de nuevas funcionalidades (como tipos de preguntas o temáticas) sin necesidad de una reestructuración mayor, promoviendo una arquitectura modular.
10.2.5. Portabilidad
-
Escenario: La aplicación web es compatible con los navegadores web más utilizados (Chrome, Firefox, Safari, Edge) en sus últimas dos versiones principales, asegurando un amplio acceso.
11. Riesgos y Deuda Técnica ⚠️
11.1. Riesgos
| Riesgo | Descripción |
|---|---|
Tiempo de entrega |
Estamos limitados por el plazo de entrega del proyecto y el tiempo que podemos dedicar mientras trabajamos en otras asignaturas. |
Proyecto grande y trabajo en equipo |
La coordinación y comunicación dentro de un equipo grande pueden ser desafiantes. |
Diseño inadecuado o enfoque incorrecto |
Los errores en las etapas tempranas pueden tener consecuencias devastadoras, y un mal diseño descubierto tarde podría ser difícil de corregir. Esto subraya la importancia de una planificación cuidadosa y una visión previsora. |
Falta de familiaridad con las tecnologías |
El equipo comienza con un conocimiento limitado sobre las herramientas necesarias, lo que puede resultar en un uso subóptimo de estas. |
Errores de implementación |
Los errores no críticos en la lógica de negocio pueden permanecer ocultos durante mucho tiempo, afectando la calidad del sistema. |
Comunicación deficiente entre miembros |
Las diferencias y desacuerdos pueden obstaculizar la colaboración efectiva, esencial para el éxito del equipo. |
Distribución desigual del trabajo |
Una asignación desequilibrada del trabajo puede sobrecargar a algunos miembros mientras deja a otros con menos responsabilidades. |
Reducción del tamaño del equipo |
La salida inesperada de miembros del equipo puede desafiar la continuidad y el avance del proyecto, requiriendo adaptaciones rápidas y eficientes. |
Incumplimiento de normas |
La falta de cumplimiento con regulaciones o estándares de seguridad pertinentes podría resultar en sanciones legales o multas. |
11.2. Deuda Técnica
| Deuda Técnica | Descripción |
|---|---|
Uso del proyecto base creado por los profesores |
Hemos optado por utilizar el proyecto base creado por los profesores para evitar empezar desde cero. Esto requiere revisar y comprender el código existente y expandirlo con nuestro propio código, lo cual puede introducir errores y llevar tiempo. Además, implica aprender nuevas tecnologías y su aplicación. |
Uso de React |
Aunque React puede facilitar el desarrollo en ciertas etapas, nuestra falta de familiaridad con este framework y sus características puede complicar el proceso. |
Dependencias desactualizadas |
El uso de versiones antiguas de bibliotecas, frameworks o plataformas puede resultar en vulnerabilidades de seguridad y limitaciones de rendimiento que necesitarán ser abordadas en el futuro. |
Falta de pruebas automatizadas |
La escasez de pruebas automatizadas a medida que el proyecto avanza puede acumular deuda técnica, ya que impide realizar cambios rápidos y efectivos sin la capacidad de probarlos de inmediato. |
Empezar desde cero |
Debido a problemas previos, el equipo ha tenido que reiniciar el proyecto desde cero, lo cual ha provocado un retraso significativo y las implicaciones correspondientes. |
12. Glosario
| Término | Definición |
|---|---|
React |
Biblioteca de JavaScript diseñada para crear interfaces de usuario de forma eficiente y sencilla. Se integra fácilmente en proyectos existentes. |
Node.js |
Entorno de ejecución para JavaScript orientado al desarrollo de servidores web. Es dirigido por eventos, multiplataforma, de código abierto y maneja la concurrencia de manera eficaz. |
Microservicio |
Enfoque arquitectónico que divide un software en pequeños servicios independientes que se comunican a través de APIs. Son rápidos, simples de desarrollar y pueden ejecutarse de manera autónoma. |
API |
Acrónimo de Interfaz de Programación de Aplicaciones. Facilita la comunicación entre diferentes partes de un software, permitiendo que los servicios interactúen de manera eficiente. |
MongoDB |
Base de datos NoSQL que es compatible con múltiples lenguajes de programación y sistemas operativos. Almacena datos en documentos BSON, un formato binario que extiende JSON. |
BSON |
Formato binario utilizado por MongoDB para almacenar documentos de manera eficiente. A diferencia de JSON, BSON está optimizado para ser más rápido en la lectura y escritura. |
Mongoose |
Biblioteca que proporciona una solución sencilla para modelar datos en aplicaciones Node.js que utilizan MongoDB. Simplifica la manipulación y el acceso a los datos. |
Docker |
Plataforma que permite empaquetar aplicaciones dentro de contenedores, asegurando que funcionen de manera uniforme en cualquier entorno. Es de código abierto y facilita el despliegue escalable de aplicaciones. |
GitHub Actions |
Herramienta de automatización que permite la ejecución de flujos de trabajo directamente desde un repositorio en GitHub. Soporta múltiples lenguajes y sistemas operativos, y es especialmente útil para la integración y despliegue continuo. |
Integración continua/despliegue continuo (CI/CD) |
Metodología de desarrollo de software que integra la integración continua (CI), la cual implica integrar automáticamente y con frecuencia los cambios de código en un repositorio compartido, y el despliegue continuo (CD), que automatiza la implementación de esos cambios en entornos de producción. |
Interfaz de Usuario (UI) |
Aspecto visual y funcional de un sistema informático a través del cual los usuarios interactúan. Incluye elementos como botones, menús y formularios, facilitando la interacción con el sistema. |
Express (en el contexto de Node.js) |
Framework de desarrollo web para Node.js, que ofrece herramientas y características que simplifican la creación de aplicaciones web y APIs de manera eficiente. |
13. Pruebas 🔍
Para asegurarnos del correcto funcionamiento de la aplicación y encontrar maneras de mejorarla, se han realizado pruebas de todo tipo. Aquí están los resultados obtenidos.
13.1. Pruebas de Cobertura (Tests Unitarios)
Estas pruebas se han realizado para la comprobación de cada componente de manera individual, evaluando los diferentes casos de uso. A continuación, se detallan las pruebas realizadas, divididas por componente.
13.1.1. Tests Gateway Service
-
Should forward login request to auth service: Verifica que las solicitudes de inicio de sesión sean correctamente reenviadas al servicio de autenticación y que el token esperado sea retornado si las credenciales son correctas.
-
Should forward add user request to user service: Comprueba que las solicitudes para agregar un nuevo usuario sean reenviadas al servicio de usuarios y que se reciba un ID de usuario como respuesta.
-
Should handle errors from the auth service on login: Asegura que se manejen adecuadamente los errores durante el proceso de inicio de sesión, como credenciales incorrectas, y que se retorne el mensaje de error apropiado.
-
Should validate a token successfully: Verifica que el servicio pueda validar correctamente un token, devolviendo un estado de validez.
-
Should handle validation error: Comprueba que se manejen correctamente los errores al validar tokens inválidos, retornando el mensaje de error adecuado.
-
Should forward get random questions request to generate service: Asegura que las solicitudes para obtener preguntas aleatorias sean correctamente reenviadas al servicio de generación y que las preguntas esperadas sean retornadas.
-
Should forward get questions request to generate service: Verifica que las solicitudes para obtener preguntas sean correctamente reenviadas al servicio de generación y que se retornen las preguntas adecuadas.
-
Should forward create question request to generate service: Comprueba que las solicitudes para crear una nueva pregunta sean correctamente reenviadas al servicio de generación y que se devuelva un estado de éxito y el ID de la pregunta.
-
Should forward update question request to generate service: Asegura que las solicitudes para actualizar una pregunta existente sean reenviadas al servicio de generación y que se retorne un estado de "OK".
-
Should forward save history request to history service: Verifica que las solicitudes para guardar el historial de acciones del usuario sean correctamente reenviadas al servicio de historial y que se retorne un estado de éxito.
-
Should forward get history request to history service: Comprueba que las solicitudes para obtener el historial de un usuario sean correctamente reenviadas al servicio de historial y que se retornen los datos esperados.
-
Should handle error getting random questions from generate service: Asegura que se manejen correctamente los errores al obtener preguntas aleatorias del servicio de generación, retornando el mensaje de error apropiado.
-
Should handle error getting questions from generate service: Verifica que se manejen correctamente los errores al obtener preguntas del servicio de generación, retornando el mensaje de error adecuado.
-
Should handle error creating question in generate service: Comprueba que se manejen correctamente los errores al crear una nueva pregunta en el servicio de generación, retornando el mensaje de error correspondiente.
-
Should handle error updating question in generate service: Asegura que se manejen correctamente los errores al actualizar una pregunta en el servicio de generación, retornando el mensaje de error apropiado.
-
Should handle error saving history in history service: Verifica que se manejen correctamente los errores al guardar el historial en el servicio de historial, retornando el mensaje de error adecuado.
-
Should handle error getting history from history service with query: Comprueba que se manejen correctamente los errores al obtener el historial desde el servicio de historial, usando una consulta específica y retornando el mensaje de error correspondiente.
-
Should handle error deleting non-existent user in user service: Este test verifica que el servicio de gateway maneje adecuadamente la solicitud para eliminar un usuario que no existe en el servicio de usuarios, asegurando que se propague el mensaje de error correcto y se devuelva el código de estado adecuado.
-
Should propagate parameters correctly on user update request: Este test asegura que los cambios en los datos de un usuario a través de una solicitud PATCH sean correctamente propagados al servicio de usuarios, validando así que los parámetros se transmitan correctamente y se obtenga una respuesta de éxito.
-
Should ensure data consistency when retrieving user history: Este test verifica que el servicio de gateway proporcione una respuesta consistente y completa cuando se solicita el historial de un usuario específico, validando que todos los campos esperados estén presentes y sean correctos.
-
Should forward delete user request to user service and handle response: Este test verifica que el endpoint de eliminación de usuario (DELETE /user/:id) funcione correctamente, reenviando la solicitud al servicio de usuarios y gestionando la respuesta adecuadamente.
-
Should forward delete question request to generate service and handle response: Comprueba que el endpoint para eliminar preguntas (DELETE /question/:id) reenvíe correctamente la solicitud al servicio de generación de preguntas y maneje las respuestas adecuadamente.
-
Should forward get ranking request to history service and return rankings: Asegura que el endpoint para obtener el ranking de usuarios (GET /getranking) reenvíe correctamente la solicitud al servicio de historial y reciba la lista de rankings esperada.
-
Should handle error deleting user from user service: Este test verifica que el servicio de gateway maneje correctamente los errores retornados por el servicio de usuarios al intentar eliminar un usuario que no existe o cuando hay un fallo en la operación.
13.1.2. Tests Question Service
-
Should generate questions /generatequestions: Verifica que el endpoint /generatequestions genere correctamente las preguntas solicitadas y las almacene en la base de datos. Se espera que se generen y cuenten 100 preguntas en la base de datos tras la ejecución.
-
Should get questions /question/randoms: Comprueba que el endpoint /question/randoms recupere y devuelva un número específico de preguntas aleatorias, en este caso, se espera que devuelva 5 preguntas.
-
Should get all questions GET /question: Testea que el endpoint GET /question recupere todas las preguntas existentes en la base de datos. En este caso, se insertan dos preguntas específicas y se verifica que ambas se retornen correctamente.
-
Should create a new question: Verifica que el endpoint POST /question permita crear una nueva pregunta y que esta se almacene correctamente en la base de datos. Se espera que la solicitud se complete con éxito (código de estado 201) y que los datos de la pregunta creada coincidan con los enviados en la solicitud.
-
Should update a question by ID: Prueba que el endpoint PATCH /question/:id actualice correctamente una pregunta existente en la base de datos según los datos proporcionados. Se verifica que la solicitud se complete con éxito (código de estado 200) y que los datos de la pregunta actualizada en la respuesta coincidan con los datos actualizados enviados.
-
Should delete a question by ID: Asegura que el endpoint DELETE /question/:id elimine correctamente una pregunta específica de la base de datos. Se espera que la solicitud se complete con éxito (código de estado 200) y que la pregunta ya no exista en la base de datos tras la eliminación.
13.1.3. Tests llamadas a Wikidata
-
Wiki Call
-
should fetch and return data from Wikidata for a valid SPARQL query: Este test evalúa si la función wikiCall realiza correctamente una solicitud HTTP para recuperar datos desde Wikidata utilizando una consulta SPARQL válida. Especificaciones del test incluyen:
-
Preparación de Datos Simulados: Configura un mock de node-fetch para simular una respuesta exitosa de la API de Wikidata. Esto implica establecer un JSON de respuesta que imita los datos que se esperarían de una consulta SPARQL real.
-
Ejecución y Validación de la Consulta: Ejecuta wikiCall con una consulta SPARQL de prueba para verificar si procesa esta consulta adecuadamente y si retorna los datos correctos. Se espera que la función transforme la respuesta simulada en el formato adecuado para su uso posterior, en este caso, un arreglo que contiene un objeto vacío que representa una fila de resultados SPARQL.
-
Verificación de la Llamada a fetch: Confirma que node-fetch se llamó exactamente una vez y con los parámetros correctos, incluyendo la URL de Wikidata con la consulta SPARQL codificada y los headers apropiados para aceptar JSON de resultados SPARQL.
-
-
Wiki Query
-
Debería obtener preguntas de Wikidata y formatearlas correctamente: Este test verifica que el método getQuestions de WikiQuery realice correctamente la llamada a wikiCall para obtener datos de Wikidata, y que luego formatee estos datos en el formato esperado para preguntas. Se realiza una configuración previa para simular respuestas de wikiCall que contienen preguntas y respuestas en un formato específico. El test comprueba que:
-
wikiCall se llama correctamente con una consulta SPARQL formateada para seleccionar etiquetas de preguntas y respuestas.
-
wikiCall se invoca una sola vez, asegurando que la función no realiza llamadas redundantes o innecesarias.
-
El modelo Question se instancia correctamente con los argumentos esperados para cada elemento de los resultados simulados, incluyendo la validación del formato de las preguntas y las respuestas.
-
Se verifica que el número de preguntas creadas y su formato coincidan con los datos proporcionados en los resultados simulados, asegurando que cada pregunta está bien formada con la estructura correcta y categoría especificada.
-
13.1.4. Tests Auth Service
-
Should perform a login operation /login: Este test verifica que el endpoint /login permita a un usuario existente realizar el inicio de sesión correctamente. Comprueba que al enviar un nombre de usuario y contraseña válidos, el sistema responde con un estado 200 y retorna la propiedad 'username' en el cuerpo de la respuesta, indicando que el proceso de autenticación fue exitoso.
-
Should reject login with incorrect credentials: Este test se asegura de que el endpoint /login rechace el intento de inicio de sesión cuando las credenciales son incorrectas. En este caso, se envía una contraseña errónea para un nombre de usuario existente. El test verifica que el servidor responda con un estado 401 y que el cuerpo dé la respuesta contenga el mensaje de error 'Invalid credentials', indicando que las credenciales proporcionadas no son válidas.
-
Should require username and password fields for login: Este test evalúa que el endpoint /login requiera tanto el nombre de usuario como la contraseña para procesar una solicitud de inicio de sesión. Aquí se envía solo el nombre de usuario sin proporcionar una contraseña. El test verifica que el servidor responda con un estado 500 y que el cuerpo dé la respuesta contenga un mensaje de error, indicando que la solicitud está incompleta o mal formada.
-
Should validate a JWT token: Este test primero realiza un inicio de sesión válido para obtener un token JWT y luego verifica la validez de ese token a través de otro endpoint. Tras obtener el token, se realiza una solicitud de validación para dicho token y se verifica que el servidor responda con un estado 200 y que el cuerpo dé la respuesta indique que el token es válido (valid: true).
-
Should reject an invalid JWT token: Este test verifica la funcionalidad del sistema para rechazar tokens JWT que no son válidos. Se envía un token arbitrario (incorrecto) al endpoint de validación y se comprueba que el servidor responda con un estado 200, pero con el cuerpo de la respuesta indicando que el token no es válido (valid: false).
13.1.5. Tests History Service
-
POST /savehistory:
-
Should save history entry for a new user that plays a game: Este test verifica que el endpoint /savehistory pueda crear una nueva entrada de historial para un usuario que no existía previamente en la base de datos. Evalúa si la entrada se almacena correctamente y si los datos devueltos en la respuesta coinciden con los datos enviados, incluyendo la correcta diferenciación entre preguntas acertadas y falladas.
-
Should update history entry for an existing user: Este test comprueba que el endpoint /savehistory actualice correctamente una entrada de historial existente para un usuario, sumando correctamente las nuevas jugadas, preguntas jugadas, preguntas acertadas y preguntas falladas a los totales previos.
-
Should reject history entry with missing data: Este test verifica que el endpoint /savehistory maneje adecuadamente situaciones donde los datos esenciales como NumPreguntasJugadas o NumAcertadas no se proporcionen en la solicitud. Se espera que el servidor responda con un código de estado 400 y un mensaje de error claro indicando qué dato falta.
-
GET /gethistory:
-
Should get history entry for an existing user: Este test verifica que el endpoint /gethistory (con un query param) recupere correctamente la entrada de historial de un usuario existente. Evalúa si los datos devueltos coinciden exactamente con los que están almacenados en la base de datos.
-
Should create new history entry for a non-existing user: Este test comprueba que el endpoint /gethistory sea capaz de manejar solicitudes para usuarios no existentes correctamente, retornando una entrada de historial con contadores en cero.
-
Should handle non-existent username on get history: Este test verifica que el endpoint /gethistory responda adecuadamente cuando se consulta el historial de un usuario que no existe. Se espera que el servidor responda con un código de estado 404.
-
GET /gethistory/:username:
-
Should get history entry for an existing user: Similar al test anterior bajo el endpoint /gethistory, pero esta vez utilizando una ruta con parámetro. Verifica si la solicitud a /gethistory/:username recupera correctamente la entrada de historial para un usuario específico usando la identificación del usuario en la URL, asegurándose de que todos los datos devueltos coincidan con los almacenados.
-
GET /getranking:
-
Should handle insufficient data for rankings: Verifica que cuando no hay datos suficientes para calcular un ranking, el servicio devuelve correctamente un arreglo vacío, lo cual es importante para evitar errores en la visualización del cliente cuando no hay datos disponibles.
-
Should return a correct ranking of players based on their scores: Asegura que el servicio calcula y devuelve el ranking de los jugadores de manera correcta basándose en sus respuestas acertadas y el total de preguntas jugadas, ordenando los jugadores según sus rendimientos.
-
Should correctly calculate posterior probabilities in rankings: Este test evalúa si se calcula adecuadamente las probabilidades a posteriori basadas en las estadísticas de juego de los jugadores, asegurando que los resultados del ranking sean justos y precisos.
-
Should handle server error during ranking calculation: Este test asegura que /getranking maneje correctamente los errores internos durante el cálculo del ranking, devolviendo un estado de error 500 para indicar problemas en el proceso.
13.1.6. Tests User Service
-
Should add a new user on POST /adduser: Esta prueba verifica que un usuario nuevo se pueda añadir correctamente mediante el endpoint /adduser. Al enviar una solicitud POST con un nombre de usuario y contraseña válidos, se espera que el servidor responda con un código de estado 200 y que el cuerpo dé la respuesta contenga el nombre de usuario que fue añadido.
-
Should reject a user without a username: Prueba la validación del campo requerido para el nombre de usuario. Al intentar registrar un usuario sin proporcionar un nombre de usuario, se espera que el servidor responda con un código de estado 400 y un mensaje de error indicando que falta el campo requerido "username".
-
Should reject a user without a password: Verifica que el servicio rechace las solicitudes para crear un usuario que no incluyan una contraseña. Si se envía una solicitud sin una contraseña, el servidor debe responder con un código de estado 400 y un mensaje de error que indique que falta el campo requerido "password".
-
Should not allow adding a user with an existing username: Asegura que no se pueda registrar más de un usuario con el mismo nombre de usuario. Al intentar añadir un usuario que ya existe en la base de datos, el servidor debe responder con un código de estado 400 y un mensaje indicando que el usuario ya existe.
-
Should get all users correctly: Este test verifica que el endpoint /user funcione correctamente al recuperar todos los usuarios registrados. Se espera que el servidor responda con un código de estado 200 y que el cuerpo dé la respuesta contenga una lista de usuarios, mostrando únicamente sus nombres de usuario y fechas de creación.
-
Should update an existing user: Este test verifica que el endpoint /user/:id actualice correctamente un usuario existente. Al enviar una solicitud PATCH con un nuevo nombre de usuario, se espera que el servidor responda con un código de estado 200 y que el cuerpo dé la respuesta refleje la actualización.
-
Should handle deletion of a non-existent user correctly: Este test asegura que el servidor responda correctamente cuando se intenta eliminar un usuario que no existe. Al enviar una solicitud DELETE a /user/:id con un ID inexistente, se espera que el servidor responda con un código de estado 404 y un mensaje de error indicando que el usuario no fue encontrado.
-
Should handle internal server error when getting users: Verifica que el servicio maneje correctamente los errores internos al intentar obtener la lista de usuarios. Si ocurre un error interno (simulado mediante un fallo en la conexión a la base de datos, por ejemplo), se espera que el servidor responda con un código de estado 500.
13.1.7. Tests Componentes React
Estas pruebas han sido diseñadas para mejorar el coverage de la aplicación y no tienen mayor objetivo que comprobar que los componentes se cargan de manera correcta, sin probar la funcionalidad, ya que de esta sen encargan los servicios, estos componentes son:
-
About US
-
Add User
-
Ayuda
-
Créditos
-
Página de Error (404)
-
Historial
-
Home (Inicio)
-
Jugar
-
Login
-
Ranking
-
Card Items (del About Us)
-
Footer
-
Layout
-
NavBar
13.2. Pruebas e2e
Estas pruebas están enfocadas en el correcto funcionamiento de la application cuando el usuario interactúa con ella. Haciendo que las páginas muestren los resultados esperados y redirijan de manera correcta.
Las features son:
-
Register Form:
-
Jugar Form:
-
History Form:
13.3. Pruebas de carga
Se enfocarán en evaluar cómo se comporta nuestro sistema bajo condiciones de alto tráfico y uso intensivo. Este tipo de pruebas es crucial para identificar cuellos de botella y asegurar que nuestra aplicación pueda manejar eficientemente el volumen de usuarios y transacciones esperado en producción, sin comprometer el rendimiento ni la estabilidad. Se han realizado 2 pruebas de carga con diferente número de usuarios simultáneos. Las pruebas seguirán el siguiente procedimiento sencillo, pero que servirá para probar los servicios y como se comportan ante el estrés generado por muchos usuarios:
-
El usuario inicia sesión en la página
-
Juega una partida completa
-
Ve su historial
-
Hace logout
Esto se realiza en el transcurso de 1 minuto.
Aquí los resultados de la primera prueba con 240 usuarios.
Estos son los resultados con 900 seguidores concurrentes.
Podemos observar que la primera prueba la soporta de manera más o menos asumible. Sin embargo, en la segunda prueba ya se está superando el límite de usuarios concurrentes y comienzan a fallar los servicios. Esto se debe principalmente a las limitadas prestaciones de la máquina virtual, determinadas por el crédito disponible para estudiantes que nos proporciona Azure.
13.4. Pruebas de usabilidad
En este apartado, nos centraremos en las pruebas de usabilidad, un componente esencial para asegurar que nuestro sistema sea intuitivo, eficiente y accesible para todos los usuarios. Este tipo de pruebas evalúa la interacción entre el usuario y la aplicación, con el objetivo de identificar áreas de mejora en la interfaz de usuario que faciliten una mejor experiencia general.
Las pruebas se han dividido en iteraciones. En cada iteración hay 3 fases.
-
Fase de pruebas, con un grupo de usuarios variado (no muy extenso) en cuanto a conocimientos y soltura en el área de la informática donde los desarrolladores toman nota de las dificultades de los usuarios, sin intervenir, a no ser que sea estrictamente necesario.
-
Fase de estudio de los resultados. El equipo de desarrolladores se reúne y decide que mejoras se han de implementar basadas en las observaciones de la fase anterior.
-
Fase de Implementación. Las mejoras decididas se implementan y se repite el proceso, para comprobar que hay una mejoría en la usabilidad.
Debido al escaso tiempo de desarrollo tan solo se realizarán 2 Iteraciones de estas pruebas. A continuación se detallan paso a paso se desarrollaron las pruebas.
13.4.1. 1ª Iteración
-
Se ha seleccionado el grupo de pruebas. El grupo consta de 2 personas con altos conocimientos de informatica, 2 personas con un nivel medio y 2 personas con un nivel bajo. Se deja al grupo trabajar mientras los desarrolladores observan.
-
Los resultados obtenidos son los siguientes.
-
El diseño de la página es bastante intuitivo en especial para los usuarios que tiene alto conocimiento. Los usuarios con bajo conocimiento necesitaron de una pequeña intervención por parte del observador.
-
A los usuarios de nivel bajo se les hace difícil tener que registrarse y a continuación, tener que iniciar sesión en la página.
-
Los usuarios se quejan de que no se muestre cuando se acierta o se falla una pregunta.
-
Los usuarios de nivel alto destacan que no hay restricciones en el nombre de usuario y la contraseña.
-
Dificultad en las preguntas.
-
Fallos de formato en las preguntas.
-
-
Las soluciones que se han aplicado a las observaciones tras debatir entre los desarrolladores son las siguientes.
-
Agregar una página de ayuda para los usuarios que no sepan qué pasos seguir para jugar. Ya sea tener que registrarse en la página, como jugar o como usar la API (aunque la API tenga su documentación).
-
Añadir un pequeño aviso que te diga cuando se acierta o se falla la pregunta. Cuando se falla también se mostrará la respuesta correcta.
-
Añadir restricciones a la creación de usuarios. Nombre de usuario de mínimo 4 caracteres y contraseña con mínimo una letra mayúscula y un número.
-
Se han revisado las plantillas de preguntas con mayor dificultad y se han añadido alguna más sencilla.
-
Se ha corregido los errores de formato de las respuestas donde existen fechas.
-
13.4.2. 2ª Iteración
-
Para la segunda iteración se ha contado con un grupo más reducido por incompatibilidad en los horarios. Sin embargo, seguimos contando con un usuario de cada nivel. Los resultados observados de esta segunda y última iteración se detallan a continuación.
-
Las observaciones han cambiado y se han solucionado prácticamente todos los problemas de la primera versión, sin embargo, han aparecido problemáticas nuevas.
-
La observación más importante de todos los usuarios es que no se puede recuperar la contraseña en caso de que se le olvide al usuario.
-
El cálculo del Ranking es poco intuitivo.
-
Los usuarios poco habituados a los juegos destacan que la velocidad de la entrada al juego es demasiado rápida y no da tiempo a entrar en contexto.
-
Posibilidad de borrar usuarios desde la API sin tener permisos especiales. Esta problemática afecta a los usuarios más avanzados.
-
Repetición de las respuestas en la pregunta.
-
-
Debido a la falta de tiempo no se podrán implementar todas las mejoras que había planteadas, sin embargo, estas son las decisiones de mejora tomadas por el equipo de desarrolladores.
-
La única mejora implementada es evitar en la lógica de generación de preguntas que existan respuestas repetidas.
-
Crear un sistema de recuperación de contraseña, a través del correo electrónico, por lo que habría que modificar el registro de usuarios.
-
Monitorizar el cálculo del Ranking y valorar en el futuro si es correcto o hay que cambiarlo.
-
Introducir una cuenta atrás cuando le das a jugar una partida nueva para que al usuario de tiempo a entrar en contexto.
-
Añadir permisos de usuario para realizar acciones especiales en la página y asi poder borrar o editar usuario a través de la API.
-
13.4.3. 3ª Iteración
Para probar la versión final de la aplicación que se entregará a los profesores, se ha realizado una última prueba para comprobar el correcto funcionamiento de todo con un par de usuarios ajeno a la aplicación. Su nivel es medio y alto. Han destacado que todo es correcto en general (Obviando los puntos de la 2ª iteración).
13.4.4. Conclusiones
Las pruebas de usabilidad han sido de gran utilidad para introducir mejoras en la aplicación, pero sobre todo han ayudado para dar un enfoque externo y más crítico a nuestra aplicación.