El objetivo del presente documento es listar los criterios utilizados para la evaluación del producto “reporte de resultado de pruebas de desempeño”, entregado por las dependencias a la Secretaría de la Función Pública, así como los criterios considerados para iniciar la evaluación. Se describen además los niveles de severidad que han de otorgárseles a los hallazgos detectados durante la evaluación del producto y las distintas conclusiones que pueden resultar de la evaluación de acuerdo a los criterios y severidades.

Severidad de criterios y hallazgos

La severidad se refiere al grado de impacto en la eficiencia del aplicativo y/o trámite que tiene la no satisfacción de un criterio de evaluación y los hallazgos identificados a partir de ese criterio de evaluación.

Los niveles de severidad que serán utilizados durante las evaluaciones para clasificar tanto a criterios como a hallazgos son los siguientes:

Grado 
severidad		 Descripción Recomendación
Crítica Se refiere a aspectos imprescindibles que comprometan el desempeño
de la aplicación/sistema y que sean un factor clave para elevar el grado
de riesgo de fallo ante una concurrencia de usuarios o volumen de datos.

Por ejemplo, hallazgos con severidad crítica detectados en las
pruebas de desempeño y que no se encuentran cerrados,
que no exista la monitorización de recursos de los servidores que
forman parte de la arquitectura, que no se muestren los
tiempos de respuesta de las funcionalidades principales,
entre otros.

También se consideran críticos, aquellos aspectos que sean
necesarios para identificar la aplicación y le tipo de
escenario considerado en el análisis.
Por ejemplo nombre de la aplicación, fecha en que se realizó
el análisis y la estrategia de pruebas de desempeño.		 Es necesario realizar la corrección de los hallazgos y lograr
el cumplimiento de los criterios de evaluación de severidad crítica
antes de publicar el tramite/aplicación en la plataforma gob.mx
Alta Se refiere a aspectos informativos de la aplicación que pueden afectar
directamente al rendimiento del sistema / aplicación o que puedan
servir para identificar más claramente la naturaleza de los hallazgos.

Por ejemplo, descripción de los objetivos, acuerdos de los niveles
servicios, omisiones de las descripciones de los hallazgos detectados
así como su posible impacto en el sistema, etc.		 Se recomienda realizar las adecuaciones pertinentes para atender
los hallazgos, de primera instancia no se identifica un riesgo mayor
en la publicación del trámite/aplicación en la plataforma gob.mx
Media Se refiere a aspectos informativos de los reportes de pruebas de
desempeño que no afecten de manera directa al rendimiento del
sistema / aplicación, pero que son importantes para registrar de
manera completa la calidad del sistema /aplicación desde la
perspectiva de eficiencia. Por ejemplo, el objetivo de la
revisión/ciclo de análisis, descripción de tecnologías de la aplicación, etc.		 Se recomienda realizar las adecuaciones pertinentes para atender
los hallazgos, de primera instancia no se identifica un riesgo mayor
en la publicación del trámite/aplicación en la plataforma gob.m

Criterios para iniciar evaluación

Para iniciar la evaluación completa de los productos de tipo “reporte de resultado de pruebas de desempeño” entregado por las dependencias a La Secretaría de la Función Pública, es necesario que estos cuenten con la información mínima suficiente para evidenciar que el aplicativo del cual se describen los resultados de las pruebas de desempeño cubre el estándar de servicios digitales de gob.mx.

En caso de que no se encuentre dicha información en los productos entregados por las dependencias a La Secretaría de la Función Pública, no es posible realizar el análisis de manera completa y confiable.

La información necesaria es aquella que muestre los resultados del análisis para los aspectos críticos y determinantes referentes a los temas descritos a continuación:

Estrategia de las prueba

En la planeación y estrategia de las pruebas se define qué tipo de pruebas se están empleando, el objetivo que persiguen, las funcionalidades principales y los flujos para operarlas en el sistema, además de los escenarios que se plantearon.

En los escenarios es importante incluir lo obtenido en el modelo de carga, el cual es creado con base en las estadísticas productivas o a lo que realmente está proyectado el sistema:

  • Nombre de la operación / funcionalidad
    • 01 Login al sistema Banca Electrónica
    • 02 Pago de Tarjeta de Crédito
    • 03 Consulta de Saldo
    • 04 Logout
  • Cantidad de usuarios y rampa de conexión
    • Carga
    • Capacidad
  • Cantidad de transacciones planeadas
  • Volumen de Datos planeados

Deben considerarse al menos dos escenarios dentro de la estrategia:

  • Medición de SLAs con el modelo de carga definido de acuerdo a las estadísticas productivas
  • Búsqueda de punto de quiebre, contemplando la ejecución con hasta el triple de lo definido en el modelo de carga

Tiempos de Respuesta

Las pruebas de rendimiento de software se centran en determinar la velocidad con la que el sistema realiza tareas específicas bajo condiciones particulares, tomando en cuenta el tiempo desde que se hacen las solicitudes al servidor de aplicación hasta que se recibe una respuesta por parte de este. El tiempo de respuesta es un factor importante en la fase de inspección y análisis ya que sirve para detectar en cuales operaciones/funcionalidades pudiera existir cuellos de botella y que además no cumplen con los niveles de servicio acordados.

Dentro de la distribución de datos obtenidos durante la prueba es importante mostrar los siguientes:

  • Promedio
  • Máximo
  • Mínimo
  • 90% Percentil

Errores y hallazgos

Con las herramientas para pruebas de performance se deben registrar todas las respuestas de peticiones hechas por cada usuario virtual programado con la herramienta de carga, es importante que se defina la cantidad y tipos de errores que surgen en el periodo de la prueba. Los errores comunes de performance son:

  • Errores 500
  • Conexiones insuficientes hacia la BD
  • Out of Memory
  • Errores 404
  • Time out

Monitorización de Recursos

La monitorización de recursos es fundamental en la fase de análisis, porque podemos identificar si la causa del cuello de botella es por el uso de recursos presentes en cada sistema:

  • CPU
  • Ancho de banda
  • Memoria
  • Almacenamiento
  • Conexiones

Es importante que se identifique el uso de CPU y Memoria principalmente, ambos no deben sobrepasar el 80% constante, ya que a este nivel se está comprometiendo la salud de los servidores y esto puede ser un problema que se traduce después en altos tiempos de respuesta y por ende mala experiencia del usuario final.

Los criterios considerados para evaluar cada uno de los temas descritos, se encuentran listados y marcados como críticos en la sección “Criterios de evaluación” de este documento.

Criterios de evaluación

Para evaluar la completitud y calidad de los productos, se realizará verificación estática basada en una lista de verificación que contiene los criterios de evaluación tanto generales como técnicos.

Criterios generales de evaluación

Se refiere a aquellos puntos que han de ser evaluados en el producto pero que no buscan inspeccionar a detalle los resultados reflejados en el reporte proporcionado por la dependencia, sino realizar un reconocimiento del producto, contemplan aspectos de identificación de aplicaciones, dependencias, herramientas utilizadas y secciones del reporte motivo de la evaluación.

Los criterios generales de evaluación del producto, así como su severidad, se listan a continuación:

ID Criterio para iniciar evaluación Nivel de interacción
1 Se identifica el nombre de la Aplicación-Sistema Crítica
2 Se identifica la dependencia de gobierno a la que pertenece el sistema Crítica
3 Se identifican las fechas en que fue realizado el análisis de desempeño Crítica

Criterios técnicos de evaluación

Se refiere a aquellos puntos que han de ser evaluados en el producto que buscan inspeccionar a detalle los resultados reflejados en el reporte proporcionado por la dependencia, a fin de identificar si el aplicativo, sistema o trámite que ha sido analizado cumple con los requerimientos necesarios para su publicación en el portal gob.mx

Los criterios técnicos de evaluación del producto, así como su severidad, se listan a continuación:

ID Criterio para iniciar evaluación Nivel de interacción
4 Se describe la estrategia de pruebas y en ella se contemplan los escenarios para:
  • Medición de SLAs con el modelo de carga definido de acuerdo a las estadísticas productivas
  • Búsqueda de punto de quiebre, contemplando la ejecución con hasta el triple de lo definido en el
    modelo de carga
 Crítica
5 Se describe el modelo de carga utilizado contemplando:
  • Nombre de la operación / funcionalidad
  • Cantidad de usuarios y rampa de conexión
  • Cantidad de transacciones planeadas
  • Volumen de Datos planeados
 Crítica
6 Se describe la fuente de donde se toman los datos fuente para la definición del modelo de carga
y se justifica el motivo en caso de no tomarse como base las estadísticas productivas		 Alta
7 Se definen los límites del SLA en cuanto a:
  • Tiempos de respuesta
  • Porcentaje de error
  • Consumo de recursos (CPU, Memoria, GC).
 Crítica
8 Se identifica la herramienta o conjunto de herramientas con la que son ejecutadas las pruebas. Media
9 Se identifica el ambiente en donde se realizan las pruebas, debiendo ser el ambiente productivo
o alguno con características idénticas. En caso de no utilizarse el ambiente productivo se debe
justificar la razón.		 Crítica
10 Se expresan los tiempos de respuesta de cada operación y describe el impacto sobre el rendimiento.
  • Promedio
  • Máximo
  • Mínimo
  • 90percentil

Estos tiempos de respuesta están dentro de los SLA establecidos.

 Crítica
11 Se detallan los errores obtenidos, total de incidencias y el impacto sobre el rendimiento.

Principalmente:

  • Errores 500
  • Conexiones insuficientes hacia la BD
  • Out of Memory
  • Errores 404
  • Time out

La cantidad y tipo de errores se encuentra dentro de los SLA establecidos.

 Crítica
12 Se detallan los resultados del monitoreo de consumo de recursos durante la ejecución,
contemplando:
  • CPU.- Uso de procesamiento representado en porcentaje
  • Ancho de banda.- Uso de Ancho de banda de la aplicación
  • Memoria.- Utilización de memoria RAM en megabytes y comportamiento de memoria compartida
    y uso de cache.
  • Almacenamiento. El uso de disco nos determina cuantos accesos se tienen al disco.
    En ocasiones cuando la memoria libre de los equipos es mínima, el sistema provoca uso de disco lo cual 
    se ve reflejado de forma exponencial.
  • Conexiones.- Tanto el número de conexiones hacia la base de datos como al servidor de
    aplicaciones o al servidor de base de datos.

El consumo de recursos informado en cada uno de los rubros se encuentra dentro de los SLA establecidos.

 Crítica
13 Se identifica el listado final completo de hallazgos de desempeño encontrados durante la revisión. Alta
14 El listado de hallazgos incluye severidad de acuerdo al impacto que tiene sobre el rendimiento del aplicativo.
  • Crítico
  • Alto
  • Medio
  • Bajo
 Alta
15 Se identifica el estado actual de los hallazgos de desempeño detectados:
  • Abierto
  • Cerrado corregido
  • Cerrado no corregido
  • En proceso de corrección
 Alta
16 Todos los hallazgos contenidos en los reportes de análisis de desempeño, con severidad crítica y alta, 
se encuentran corregidos o existe justificación para su no corrección		 Crítica
17 Se identifica en que parte del software (modulo/ funcionalidad/archivo) fue localizada cada uno de los
hallazgos de desempeño		 Alta
18 Se describe las acciones que se emplearon para mitigar el riesgo de cada una de los hallazgos detectados. Media
19 Se informan resultados de al menos dos ciclos, uno de línea base y otro ejecutado con la corrección de 
errores y adecuaciones para cumplir los SLA establecidos.		 Crítica