Show Menu
TEMAS×

Comprender los resultados de la prueba

Las ejecuciones de canalizaciones de Cloud Manager para servicios de nube admitirán la ejecución de pruebas que se ejecuten con el entorno de la fase. Esto contrasta con las pruebas que se ejecutan durante el paso Generar y Prueba de unidades que se ejecutan sin conexión, sin acceso a ningún entorno AEM en ejecución. Existen dos tipos de pruebas ejecutadas en este contexto:
  • Pruebas escritas por el cliente
  • Pruebas escritas por Adobe
Ambos tipos de pruebas se ejecutan en una infraestructura de contenedores diseñada para ejecutar estos tipos de pruebas.

Prueba de calidad del código

Como parte de la canalización, se analiza el código fuente para asegurarse de que las implementaciones cumplen determinados criterios de calidad. Actualmente, esto se implementa mediante una combinación de SonarQube y un examen a nivel de paquete de contenido con OakPAL. Existen más de 100 reglas que combinan reglas genéricas de Java y reglas específicas de AEM. La siguiente tabla resume la clasificación para los 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 grave
D = al menos 1 vulnerabilidad crítica
E = al menos 1 vulnerabilidad de bloqueador
Crítico
< B
Clasificación de confiabilidad
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 de bloqueo
Importante
< C
Clasificación de mantenimiento
El costo de corrección sobresaliente de los olores de código es:
  • <=5% del tiempo que ya ha pasado a la aplicación, la clasificación es A
  • entre el 6 y el 10 % la calificación es B
  • entre el 11 y el 20 % la calificación es una C
  • entre el 21 y el 50 % la calificación es una D
  • cualquier cosa superior al 50% es una E
Importante
< A
Cobertura
Combinación de cobertura de la línea de prueba unitaria y cobertura de condición mediante esta fórmula:
Coverage = (CT + CF + LC)/(2*B + EL)
donde: CT = condiciones que se han evaluado en 'true' al menos una vez mientras se ejecutan las pruebas unitarias
CF = condiciones que se han evaluado en 'false' al menos una vez mientras se ejecutan las pruebas unitarias
LC = líneas cubiertas = líneas_to_cover - líneasdescubiertas
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 como 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 de Java:
  • Debe haber al menos 10 declaraciones sucesivas y duplicadas, independientemente del número de tokens y líneas.
Las diferencias en sangría y en literales de cadena se omiten al detectar duplicaciones.
Información
> 1%
Compatibilidad del servicio de nube
Número de problemas de compatibilidad con los servicios de nube identificados.
Información
> 0
Consulte Definiciones de métricas para obtener definiciones más detalladas.
Puede descargar la lista de reglas aquí code-quality-rules.xlsx
Para obtener más información sobre las reglas de calidad de código personalizadas ejecutadas por Cloud Manager, consulte Reglas de calidad de código personalizado.

Tratar con falsos positivos

El proceso de análisis de calidad no es perfecto y a veces identifica incorrectamente 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 de Java @SuppressWarnings que especifica el ID de la regla como el 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 de 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 generará una vulnerabilidad de bloqueador. Después de revisar el código, se identifica que no se trata de una vulnerabilidad y se puede anotar con la identificación de regla adecuada.
@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 en realidad esto:
@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.
Si bien es recomendable que la anotación sea lo más específica posible, es decir, que solo haga una anotación de la sentencia o bloque específico que causa el problema, es posible realizar anotaciones a nivel de clase. @SuppressWarnings

Escritura de pruebas funcionales

Las pruebas funcionales escritas por el cliente deben empaquetarse como un archivo JAR independiente producido por la misma compilación Maven que los artefactos que se implementarán en AEM. Generalmente sería un módulo Maven independiente. El archivo JAR resultante debe contener todas las dependencias requeridas y generalmente se crearía usando el complemento maven-assembly-plugin usando el descriptor jar-con-dependencias.
Además, JAR debe tener el encabezado de manifiesto Cloud-Manager-TestType establecido en integration-test. En el futuro, se espera que se admitan valores de encabezado adicionales. Una configuración de ejemplo para maven-assembly-plugin es:
<build>
    <plugins>
        <!-- Create self-contained jar with dependencies -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <archive>
                    <manifestEntries>
                        <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType>
                    </manifestEntries>
                </archive>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

Dentro de este archivo JAR, los nombres de clase de las pruebas reales que se van a ejecutar deben terminar en TI.
Por ejemplo, se ejecutaría una clase denominada com.myco.tests.aem.ExampleIT , pero no una clase denominada com.myco.tests.aem.ExampleTest .
Las clases de prueba deben ser pruebas JUnit normales. La infraestructura de prueba está diseñada y configurada para ser compatible con las convenciones utilizadas por la biblioteca de pruebas aem-testing-customers. Se recomienda encarecidamente a los desarrolladores que utilicen esta biblioteca y sigan sus prácticas recomendadas. Consulte Git Link para obtener más detalles.

Prueba funcional personalizada

El paso de prueba funcional personalizada de la canalización siempre está presente y no se puede omitir.
Sin embargo, si la compilación no produce JAR de prueba, la prueba pasa de forma predeterminada. Este paso se realiza inmediatamente después de la implementación de la etapa.
El botón Descargar registro permite acceder a un archivo ZIP que contiene el formulario detallado de la ejecución de la prueba. Estos registros no incluyen los registros del proceso de tiempo de ejecución real de AEM; se puede acceder a ellos mediante la funcionalidad de registro de descargas o de cola habitual. Consulte Acceso y administración de registros para obtener más detalles.

Ejecución de pruebas locales

Como las clases de prueba son pruebas JUnit, se pueden ejecutar desde IDE de Java convencionales como Eclipse, IntelliJ, NetBeans, etc.
Sin embargo, al ejecutar estas pruebas necesariamente, será necesario establecer una variedad de propiedades del sistema que esperan los clientes de prueba de aem (y los clientes de prueba de Sling subyacentes).
Las propiedades del sistema son las siguientes:
  • sling.it.instances - should be set to 2
  • sling.it.instance.url.1 - should be set to the author URL, for example, http://localhost:4502
  • sling.it.instance.runmode.1 - should be set to author
  • sling.it.instance.adminUser.1 - should be set to the author admin user, e.g. admin
  • sling.it.instance.adminPassword.1 - should be set to the author admin password
  • sling.it.instance.url.2 - should be set to the author URL, for example, http://localhost:4503
  • sling.it.instance.runmode.2 - should be set to publish
  • sling.it.instance.adminUser.2 - should be set to the publish admin user, for example, admin
  • sling.it.instance.adminPassword.2 - should be set to the publish admin password