Comprender los resultados de la prueba

Durante la ejecución de la canalización, se capturan varias métricas y se comparan con los Indicadores de rendimiento clave (KPI) definidos por el propietario del negocio o con los estándares establecidos por Adobe Managed Services.

Estos se registran utilizando el sistema de enlace de tres niveles definido en esta sección.

Puerta de tres niveles al ejecutar una canalización

Hay tres puertas en la canalización:

• Calidad de código
• Pruebas de rendimiento
• Pruebas de seguridad

Para cada una de estas puertas, hay una estructura de tres niveles para los problemas identificados por la puerta.

• Crítico : Son problemas identificados por la puerta que causan un fallo inmediato de la canalización.
• Importante : Son problemas identificados por la puerta que hacen que la canalización introduzca un estado pausado. Un administrador de implementación, un administrador de proyectos o un propietario de empresa pueden anular los problemas, en cuyo caso la canalización continúa, o pueden aceptar los problemas, en cuyo caso la canalización se detiene con un error.
• Información : Son problemas identificados por la puerta que se proporcionan exclusivamente con fines informativos y no tienen impacto en la ejecución de la canalización.

Prueba de calidad de código

Este paso evalúa la calidad del código de la aplicación. Es el objetivo central de una canalización solo de calidad de código y se ejecuta inmediatamente después del paso de compilación en todas las canalizaciones que no sean de producción y producción. Consulte Configuración de la canalización CI-CD para obtener más información sobre los distintos tipos de canalizaciones.

Entender la prueba de calidad del código

En la prueba de calidad del código, se analiza el código fuente para asegurarse de que cumple determinados criterios de calidad. Actualmente, esto se implementa mediante una combinación de SonarQube, un examen a nivel de paquete de contenido usando OakPAL y la validación de Dispatcher usando la Herramienta de Optimización de Dispatcher. Hay más de 100 reglas que combinan reglas genéricas de Java y reglas específicas de AEM. Algunas de las reglas específicas del AEM se crean en función de las prácticas recomendadas de AEM ingeniería y se denominan Reglas de calidad de código personalizado.

Los resultados de este paso se entregan como Clasificación. La tabla siguiente resume las clasificaciones de varios criterios de prueba:

Nombre	Definición	Categoría	Umbral de error
Clasificación de seguridad	A = 0 Vulnerabilidad B = al menos 1 Vulnerabilidad menor C = al menos 1 Vulnerabilidad mayor D = al menos 1 Vulnerabilidad crítica E = al menos 1 Vulnerabilidad del bloqueador	Importante	< B
Clasificación de fiabilidad	A = 0 Error B = al menos 1 Error menor C = al menos 1 Error mayor D = al menos 1 Error crítico E = al menos 1 Error del bloqueador	Importante	< C
Puntuación de mantenimiento	El coste de corrección pendiente de los olores de código es: <> entre el 6% y el 10% la calificación es a B entre el 11% y el 20% la calificación es C entre el 21 y el 50 % la calificación es D cualquier valor superior al 50% es una E	Importante	< A
Cobertura	Una combinación de cobertura de línea de prueba unitaria y cobertura de condición utilizando esta fórmula: Coverage = (CT + CF + LC)/(2*B + EL) donde: CT = condiciones que se han evaluado en 'true' al menos una vez al ejecutar pruebas unitarias CF = condiciones que se han evaluado en 'false' al menos una vez al ejecutar pruebas unitarias LC = líneas cubiertas = líneas_to_cover - uncovered_lines B = número total de condiciones EL = número total de líneas ejecutables (lines_to_cover)	Importante	< 50%
Pruebas unitarias omitidas	Número de pruebas unitarias omitidas.	Información	> 1
Problemas abiertos	Tipos de problemas generales: Vulnerabilidades, errores y huecos de código	Información	> 0
Líneas duplicadas	Número de líneas involucradas en bloques duplicados. Para que un bloque de código se considere duplicado: Proyectos que no son de Java: Debe haber al menos 100 tokens sucesivos y duplicados. Estos tokens deben propagarse al menos en: 30 líneas de código para COBOL 20 líneas de código para ABAP 10 líneas de código para otros idiomas Proyectos Java: Debe haber al menos 10 afirmaciones sucesivas y duplicadas, independientemente del número de tokens y líneas. Las diferencias en la sangría y en los literales de cadena se ignoran al detectar duplicados.	Información	> 1%
Compatibilidad del Cloud Service	Número de problemas de compatibilidad con Cloud Service identificados.	Información	> 0

Tratamiento de falsos positivos

El proceso de digitalización de la calidad no es perfecto y a veces identifica incorrectamente los problemas que no son realmente problemáticos. Esto se denomina "falso positivo".

En estos casos, el código fuente se puede anotar con la anotación estándar Java @SuppressWarnings que especifica el ID de regla como atributo de anotación. Por ejemplo, un problema común es que la regla SonarQube para detectar contraseñas codificadas puede ser agresiva sobre cómo se identifica una contraseña codificada.

Para ver un ejemplo específico, este código sería bastante común en un proyecto AEM que tiene código para conectarse a algún servicio externo:

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube entonces generará una vulnerabilidad Blocker. Después de revisar el código, identifique que esta no es una vulnerabilidad y pueda anotarla con el id de regla adecuado.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Sin embargo, por otro lado, si el código era realmente así:

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

A continuación, la solución correcta es quitar la contraseña codificada.

Pruebas de seguridad

Cloud Manager ejecuta el paso existente AEM Security Heath Checkson después de la implementación e informa del estado a través de la interfaz de usuario. Los resultados se agregan de todas las instancias AEM del entorno.

Estas mismas comprobaciones de estado se pueden ejecutar en cualquier momento a través de la consola web o el panel de operaciones.

Si alguna de las Instancias informa de un error en una comprobación de estado determinada, toda la Entorno falla en esa comprobación de estado. Al igual que con las pruebas de calidad y rendimiento del código, estas comprobaciones de estado se organizan en categorías y se notifican utilizando el sistema de tres niveles. La única distinción es que no hay umbral en el caso de las pruebas de seguridad. Todos los controles de salud simplemente se aprueban o no.

En la tabla siguiente se enumeran las comprobaciones actuales:

Nombre	Implementación de comprobación de estado	Categoría
Deserialización firewall Adjuntar preparación de API está en un estado aceptable	Disposición de la API de anexo de cortafuegos de deserialización	Importante
El firewall de deserialización funciona	Cortafuegos de deserialización funcional	Importante
Deserialización del firewall cargado	Cortafuegos de deserialización cargado	Importante
La implementación de AuthorizableNodeName no expone el ID autorizado en el nombre/ruta del nodo.	Generación del nombre de nodo con autorización	Importante
Se han cambiado las contraseñas predeterminadas	Cuentas de inicio de sesión predet.	Importante
El servlet de GET predeterminado de Sling está protegido de ataques DOS.	Sling Get Servlet	Importante
El controlador de script Java de Sling está configurado correctamente	Sling Java Script Handler	Importante
El controlador de script JSP de Sling está configurado correctamente	Controlador de script JSP de Sling	Importante
SSL está configurado correctamente	Configuración SSL	Importante
No se encontraron directivas de perfil de usuario obviamente inseguras	Acceso predet. del perfil de usuario	Importante
El filtro de referente de Sling está configurado para evitar ataques de CSRF	Filtro de referente de Sling	Importante
El Administrador de bibliotecas HTML de Adobe Granite está configurado correctamente	Configuración del administrador de bibliotecas HTML de CQ	Importante
El paquete de soporte CRXDE está deshabilitado	Compatibilidad con CRXDE	Importante
El paquete y el servlet Sling DavEx están desactivados	Comprobación de estado de DavEx	Importante
El contenido de muestra no está instalado	Paquetes de contenido de ejemplo	Importante
Tanto el filtro de solicitud WCM como el filtro de depuración WCM están desactivados	Configuración de filtros WCM	Importante
El paquete y el servlet Sling WebDAV están correctamente configurados	Comprobación de estado de WebDAV	Importante
El servidor web está configurado para evitar el secuestro de clics	Configuración de servidor web	Importante
La replicación no utiliza el usuario "admin"	Replicación y usuarios de transporte	Información

Pruebas de rendimiento

AEM Sites

Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Sites. La prueba de rendimiento se ejecuta durante ~ 30 minutos girando los usuarios virtuales (contenedores) que simulan que los usuarios reales acceden a páginas en el entorno de ensayo y simulan el tráfico. Estas páginas se encuentran usando un rastreador.

1. Usuarios virtuales

   El número de usuarios virtuales o contenedores que Cloud Manager genera depende del KPI (tiempo de respuesta y vistas de página/min) definido por el usuario en la función Propietario empresarial mientras crea o edita el programa. Según los KPI definidos, se enviarán hasta 10 contenedores que simulen usuarios reales. Las páginas seleccionadas para la prueba se dividen y se asignan a cada virtual.

2. Rastreador

   Antes del inicio del periodo de prueba de 30 minutos, Cloud Manager rastreará el entorno de ensayo utilizando un conjunto de una o más URL semilla configuradas por el ingeniero de éxito del cliente. A partir de estas direcciones URL, se inspecciona el HTML de cada página y los vínculos se atraviesan de forma predeterminada. Este proceso de rastreo está limitado a un máximo de 5000 páginas. Las solicitudes del rastreador tienen un tiempo de espera fijo de 10 segundos.

3. Conjuntos de páginas para pruebas

   Las páginas se seleccionan mediante tres conjuntos de páginas. Cloud Manager utiliza los registros de acceso de las instancias de AEM en Producción y Etapa para determinar los tres bloques siguientes:

   • Páginas en directo populares: Esta opción está seleccionada para asegurarse de que se prueben las páginas más populares a las que acceden los clientes activos. Cloud Manager leerá el registro de acceso y determinará las 25 páginas más visitadas por los clientes activos para generar una lista de las principales Popular Live Pages. La intersección de estas que también están presentes en Stage se rastrea en el entorno de ensayo.

   • Otras páginas en directo: Esta opción está seleccionada para asegurarse de que se prueben las páginas que quedan fuera de las 25 páginas activas más populares y que pueden no ser populares, pero que es importante probar. De forma similar a las páginas en vivo populares, se extraen del registro de acceso y también deben estar presentes en el escenario.

   • Nuevas páginas: Esta opción está seleccionada para probar las páginas nuevas que solo se hayan implementado en la fase y que aún no estén en producción, pero que deben probarse.

     Distribución del tráfico entre conjuntos de páginas seleccionados

     Puede elegir entre uno y los tres conjuntos de la pestaña "Pruebas" de la configuración de la canalización (vínculo Insertar ). La distribución del tráfico se basa en el número de conjuntos seleccionados, es decir, si se seleccionan los tres, el 33 % del total de vistas de página se asigna a cada conjunto; si se seleccionan dos, el 50 % se dirige a cada conjunto; si se selecciona uno, el 100 % del tráfico se destina a ese conjunto.

     Por ejemplo, supongamos que hay una división del 50 % - 50 % entre el conjunto de páginas en directo populares y páginas nuevas (en este ejemplo, no se usa Otras páginas en directo) y que el conjunto de páginas nuevas contiene 3000 páginas. El KPI de vistas de página por minuto se establece en 200. Durante el periodo de prueba de 30 minutos:

     • Cada una de las 25 páginas del conjunto de páginas en directo populares se visita 120 veces - (200 * 0,5) / 25) * 30 = 120

     • Cada una de las 3000 páginas del conjunto Nuevas páginas se visita una vez - (200 * 0,5) / 3000) * 30 = 1

Pruebas y creación de informes

Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Sites solicitando páginas (como usuario no autenticado de forma predeterminada) en el servidor de publicación de escenario durante un periodo de prueba de 30 minutos y midiendo las métricas (virtuales) generadas por el usuario (tiempo de respuesta, tasa de error, vistas por minuto, etc.) para cada página, así como varias métricas de nivel de sistema (CPU, memoria, datos de red) para todas las instancias.
En la tabla siguiente se resumen las métricas de prueba de rendimiento en relación con el uso del sistema de navegación de tres niveles:

En la tabla siguiente se resume la matriz de prueba de rendimiento utilizando el sistema de navegación de tres niveles:

Métrica	Categoría	Umbral de error
Tasa de error de solicitud de página %	Importante	>= 2%
Tasa de uso de CPU	Importante	>= 80 %
Tiempo de espera de IO de disco	Importante	>= 50%
Tiempo de respuesta del percentil 95	Importante	>= KPI a nivel de programa
Tiempo de respuesta máximo	Importante	>= 18 segundos
Vistas de página por minuto	Importante	< Program-level="" KPI="">
Uso del ancho de banda del disco	Importante	>= 90%
Utilización del ancho de banda de red	Importante	>= 90 %
Solicitudes por minuto	Información	>= 6000

Consulte la sección siguiente, Pruebas de rendimiento autenticadas para obtener más información sobre el uso de la autenticación básica para las pruebas de rendimiento de Sites y Assets.

Pruebas de rendimiento autenticadas

Esta función es opcional en Sitios .
Los clientes de AMS con sitios autenticados pueden especificar un nombre de usuario y una contraseña que Cloud Manager utilizará para acceder al sitio web durante las pruebas de rendimiento del sitio.
El nombre de usuario y la contraseña se especifican como Variables de canalización con los nombres CM_PERF_TEST_BASIC_USERNAME y CM_PERF_TEST_BASIC_PASSWORD.
Aunque no es estrictamente necesario, se recomienda utilizar el tipo de variable de cadena para el nombre de usuario y el tipo de variable secretString para la contraseña. Si se especifican ambos, cada solicitud del rastreador de prueba de rendimiento y los usuarios virtuales de prueba contendrán estas credenciales como autenticación HTTP Basic.

Para establecer estas variables utilizando la CLI de Cloud Manager, ejecute:

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

Consulte Variables para aprender a utilizar la API.

AEM Assets

Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Assets cargando recursos repetidamente durante un periodo de prueba de 30 minutos.

1. Requisito de integración

   Para las pruebas de rendimiento de Assets, el ingeniero de éxito del cliente creará un cloudmanager usuario (y contraseña) durante la incorporación del entorno Author to Stage . Los pasos de la prueba de rendimiento necesitarán el usuario llamado cloudmanager y la contraseña asociada configurada por su CSE. Esto no debe eliminarse del Autor ni cambiarse de texto a permisos. Si lo hace, es probable que se produzca un error en las pruebas de rendimiento de Assets.

2. Imágenes y recursos para pruebas

   Los clientes pueden cargar sus propios recursos para realizar pruebas. Esto se puede hacer desde la pantalla Configuración o edición de canalización . Los formatos de imagen comunes, como JPEG, PNG, GIF y BMP, son compatibles con los archivos Photoshop, Illustrator y Postscript. Sin embargo, si no se carga ninguna imagen, Cloud Manager utilizará una imagen y un documento PDF predeterminados para realizar pruebas.

3. Distribución de recursos para pruebas

   La distribución de cuántos recursos de cada tipo se cargan por minuto se establece en la pantalla Configuración de canalización o Editar.
   Por ejemplo, si se utiliza una división 70/30, como se ve en la figura siguiente. Hay 10 activos cargados por minuto, 7 imágenes se cargarán por minuto y 3 documentos.

4. Pruebas e informes

   Cloud Manager creará una carpeta en la instancia de Autor, utilizando el nombre de usuario y la contraseña configuradas por el CSE desde el paso 1 (Requisitos de integración), como se mencionó anteriormente, y cargará recursos en la carpeta utilizando una biblioteca de código abierto. Las pruebas ejecutadas por el paso de prueba de Assets se escriben utilizando esta biblioteca de código abierto. Tanto el tiempo de procesamiento de cada recurso como varias métricas a nivel de sistema se miden en la duración de las pruebas de 30 minutos. Esta capacidad puede cargar imágenes y documentos PDF.

   NOTA

   Puede obtener más información sobre la configuración de las pruebas de rendimiento en Configuración de la canalización de CI/CD. Consulte Configuración del programa para obtener información sobre cómo configurar el programa y definir los KPI.

Gráficos de resultados de pruebas de rendimiento

Se han añadido nuevos gráficos y opciones de descarga al cuadro de diálogo Resultados de la prueba de rendimiento .

Cuando se abre el cuadro de diálogo Prueba de rendimiento, los paneles de métricas se pueden expandir para mostrar un gráfico, proporcionar un vínculo a una descarga o ambos.

Para la Cloud Manager versión 2018.7.0, esta funcionalidad está disponible para las siguientes métricas:

• Uso de CPU

  • Un gráfico de la utilización de la CPU durante el periodo de prueba.

• Tiempo de espera de E/S de disco

  • Un gráfico del tiempo de espera de E/S de disco durante el período de prueba.

• Tasa de error de página

  • Gráfico de errores de página por minuto durante el periodo de prueba.
  • Un archivo CSV enumera las páginas que han producido un error durante la prueba.

• Uso del ancho de banda del disco

  • Gráfico de la utilización del ancho de banda del disco durante el periodo de prueba.

• Utilización del ancho de banda de red

  • Gráfico de la utilización del ancho de banda de red durante el periodo de prueba.

• Tiempo de respuesta máximo

  • Un gráfico del tiempo de respuesta pico por minuto durante el periodo de prueba.

• Tiempo de respuesta del percentil 95

  • Gráfico del tiempo de respuesta del percentil 95 por minuto durante el periodo de prueba.
  • Archivo CSV que enumera las páginas cuyo tiempo de respuesta del percentil 95 ha superado el KPI definido.

Las imágenes siguientes muestran los gráficos de prueba de rendimiento: