Experimento Sprint 4 - ISIS2503-202310-S2-LasDivinas/Documentacion_Arquitectura GitHub Wiki
Escenarios de prueba
ASR 1: Corregir Bug de forma aislada
No se realiza un experimento para el ASR de corregir un bug de manera aislada. Sin embargo, el diseño utilizado para el componente de historias clínicas es posible satisfacer el ASR dado.
ASR 2: Impedir creación no autorizada de historias clínicas
Para comprobar que siempre que se intenta realizar una creación de historia clínica se utiliza la táctica de autenticación para evitar que actores no autorizados realicen esa acción, se diseñó el siguiente escenario de prueba, que consiste de tres momentos:
- No autenticación: Se intenta realizar la edición de una historia clínica sin haberse autenticado previamente. El resultado esperado de este escenario de prueba es que no se permite la creación de las historias clínicas y se obtiene un mensaje que indica la falta de autorización del usuario actual.
- Autenticación sin el rol apropiado: Se realiza el proceso de autenticación, pero con una cuenta que no cuenta con el rol necesario para crear historias clínicas, en concreto, con una cuenta que no tiene el rol de médico. El resultado esperado de esta prueba es idéntico a la anterior: se espera obtener un mensaje que indica la falta autorización del usuario actual para realizar la acción que intenta.
- Autenticación y rol apropiado: Se realiza el proceso de autenticación con una cuenta que si tiene los permisos esperados para poder realizar la creación de historias clínicas, es decir, con una cuenta que tiene el rol de médico. El resultado esperado de esta prueba es que después de una autenticación exitosa, el usuario sea capaz de realizar la acción intentada.
ASR 3: Consultar información
Se insertaron estratégicamente pacientes y pacientes prioritarios en la base de datos. Se realizó la inserción con los siguientes parámetros:
- El enunciado de WIDMY, que estipula que se manejan 50.000 pacientes.
- Las estadísticas nacionales de pacientes con obesidad de grado I, II o III, del 18%. Se realiza la consulta y se espera que satisfaga el ASR.
Se realizan pruebas en Jmeter para comprobar que se satisface el ASR tras usar los patrones adecuados en la base de datos documental.
Implementación de la prueba
ASR 3: Consultar información
En primer lugar, se proporciona la información utilizada en las pruebas realizadas en JMeter. Se realizó una solicitud GET al servidor de Kong en el API Gateway, específicamente en la ruta de pacientes prioritarios que cumplen con los requisitos de la consulta del ASR.(prioritario18).
Se realizaron 2 pruebas. En cada una se ejecutó una única solicitud (un solo hilo getAll) para obtener los miles de pacientes que cumplen con las condiciones de la consulta. A continuación se muestran los resultados obtenidos:
Como se puede observar en las imágenes anteriores, las pruebas arrojaron un tiempo de ejecución de 14000 a 16000 milisegundos (14-16 segundos), lo cual es considerablemente más alto de lo esperado para el ASR (inferior a 1 segundo). Debido a esta situación, se decidió reducir la cantidad de pacientes en la base de datos para llevar a cabo una tercera prueba adicional. A continuación se presenta esta prueba en detalle:
En el último escenario, podemos observar que el tiempo de consulta fue de 422 milisegundos, lo cual cumple con el objetivo del ASR planteado, ya que se completó en menos de 1 segundo. Es importante destacar que a medida que aumenta la cantidad de pacientes, el tiempo de consulta también aumenta. A pesar de haber incluido los patrones de "subset" y "computed", cuando se realiza una consulta sobre un conjunto extremadamente grande de datos el tiempo de respuesta puede ser considerablemente alto. Ante esta situación, se recomendaría al cliente considerar cambiar la consulta, enfocándose en un grupo más específico de pacientes o buscar si hay algún paciente en especifico que cumpla con las condiciones de la consulta. En estos casos, donde se trata de una cantidad mucho menor de pacientes, los tiempos de respuesta son más cortos y satisfactorios para el cliente.