Entender os resultados de teste

Durante a execução do Pipeline, várias métricas são capturadas e comparadas aos Indicadores-chave de desempenho (KPIs) definidos pelo proprietário da empresa ou aos padrões definidos pelos Serviços gerenciados da Adobe.

Eles são reportados usando o sistema de portagem de três níveis, conforme definido nesta seção.

Portas de três níveis ao executar um pipeline

Há três portões no pipeline:

  • Qualidade do código
  • Teste de desempenho
  • Teste de segurança

Para cada uma dessas portas, existe uma estrutura em três níveis para as questões identificadas pela porta.

  • Crítico - São problemas identificados pela porta que causam uma falha imediata do pipeline.
  • Importante - são problemas identificados pela porta que fazem com que o pipeline entre em um estado de pausa. Um gerente de implantação, gerente de projeto ou proprietário de negócios pode substituir os problemas, caso em que o pipeline continua, ou pode aceitar os problemas, caso em que o pipeline pára com uma falha.
  • Informações - São questões identificadas pela porta, que são fornecidas apenas para fins informativos e não têm impacto na execução do pipeline.
Observação

Em um pipeline de qualidade de código somente, falhas importantes na porta de teste de qualidade de código não podem ser substituídas, pois a etapa de teste de qualidade de código é a etapa final no pipeline.

Teste de qualidade de código

Esta etapa avalia a qualidade do código do aplicativo. É o objetivo principal de um gasoduto de qualidade-código e é executado imediatamente após a etapa de construção em todos os gasodutos de não-produção e de produção. Consulte Configuração do seu pipeline CI-CD para saber mais sobre diferentes tipos de pipeline.

Como entender o teste de qualidade de código

Em Teste de qualidade de código, o código fonte é verificado para garantir que ele atenda a determinados critérios de qualidade. Atualmente, esta ação é implementada através de uma combinação de SonarQube e exame de nível de pacote de conteúdo utilizando OakPAL. Há mais de 100 regras que combinam regras genéricas do Java e regras específicas do AEM. Algumas das regras específicas do AEM são criadas com base nas práticas recomendadas AEM engenharia e são chamadas de Regras de qualidade de códigopersonalizado.

Observação

Você pode baixar a lista completa de regras aqui.

Os resultados desta etapa são fornecidos como Classificação. A tabela abaixo resume as classificações de vários critérios de teste:

Nome Definição Categoria Limite de falha
Classificação de segurança A = 0 Vulnerabilidade
B = pelo menos 1 Vulnerabilidade
Menor C = pelo menos 1 Vulnerabilidade Principal
D = pelo menos 1 Vulnerabilidade Crítica
E = pelo menos 1 Vulnerabilidade Bloqueadora
Crítico < B
Classificação da confiabilidade A = 0 Bug
B = pelo menos 1 Bug Menor
C = pelo menos 1 Bug Principal
D = pelo menos 1
BugE Crítico = pelo menos 1 Bug Bloqueador
Importante < C
Classificação da manutenção O custo de correção excepcional para cheiros de código é:
  • <=5% do tempo que já passou para o aplicativo, a classificação é A
  • entre 6 e 10%, a classificação é de
  • entre 11 e 20% a classificação é de C
  • entre 21 e 50% a classificação é um D
  • algo acima de 50% é um E
Importante < A
Cobertura Uma combinação da cobertura da linha de teste da unidade e da cobertura da condição usando esta fórmula:
Coverage = (CT + CF + LC)/(2*B + EL)
em que: CT = condições que foram avaliadas como 'true' pelo menos uma vez durante a execução de testes de unidade
CF = condições que foram avaliadas como 'false' pelo menos uma vez durante a execução de testes de unidade
LC = linhas cobertas = lines_to_cover - uncovered_lines

B = número total de condições
EL = número total de linhas executáveis (lines_to_cover)
Importante < 50%
Testes de unidade ignorados Número de testes de unidade ignorados. Informações > 1
Problemas em aberto Tipos de edição geral - Vulnerabilidades, Erros e Cheiros de código Informações > 0
Linhas Duplicadas Número de linhas envolvidas em blocos duplicados.
Para que um bloco de código seja considerado como duplicado:
  • Projetos não Java:
  • Deve haver pelo menos 100 tokens sucessivos e duplicados.
  • Esses tokens devem ser espalhados pelo menos em:
  • 30 linhas de código para COBOL
  • 20 linhas de código para ABAP
  • 10 linhas de código para outras línguas
  • Projetos Java:
  • Deve haver pelo menos 10 declarações sucessivas e duplicadas, independentemente do número de tokens e linhas.

As diferenças no recuo, bem como nos literais de string, são ignoradas ao detectar duplicações.
Informações > 1%
Compatibilidade com Cloud Service Número de problemas de compatibilidade de Cloud Service identificados. Informações > 0
Observação

Consulte Definições de métricas para obter definições mais detalhadas.

Observação

Para saber mais sobre as regras de qualidade de código personalizadas executadas por Cloud Manager, consulte Regras de qualidade de códigopersonalizadas.

Lidar com falsos positivos

O processo de verificação da qualidade não é perfeito e, por vezes, identificará incorretamente questões que não são realmente problemáticas. Isso é conhecido como "falso positivo".

Nesses casos, o código fonte pode ser anotado com a @SuppressWarnings anotação padrão Java que especifica a ID da regra como o atributo de anotação. Por exemplo, um problema comum é que a regra SonarQube para detectar senhas codificadas pode ser agressiva sobre como uma senha codificada é identificada.

Para ver um exemplo específico, esse código seria bastante comum em um projeto AEM que tem código para se conectar a algum serviço externo:

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

A SonarQube criará uma Vulnerabilidade do Bloqueador. Depois de revisar o código, você identifica que isso não é uma vulnerabilidade e pode anotar isso com a ID de regra apropriada.

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

No entanto, por outro lado, se o código era realmente este:

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

Em seguida, a solução correta é remover a senha codificada.

Observação

Embora seja uma prática recomendada tornar a @SuppressWarnings anotação o mais específica possível, ou seja, anotar somente a declaração específica ou o bloco que está causando o problema, é possível fazer anotações em nível de classe.

Teste de segurança

Cloud Manager executa as AEM verificações de integridade de segurança existentes na etapa seguinte à implantação e relata o status pela interface do usuário. Os resultados são agregados de todas as instâncias AEM no ambiente.

Se alguma das Instâncias reportar uma falha para uma determinada verificação de integridade, todo o Ambiente falhará nessa verificação de integridade. Como acontece com o teste de qualidade e desempenho de código, essas verificações de integridade são organizadas em categorias e reportadas usando o sistema de portagem de três níveis. A única distinção é que não existe um limiar no caso dos testes de segurança. Todos os exames de saúde são simplesmente aprovados ou reprovados.

A tabela a seguir lista as verificações atuais:

Nome Implementação da verificação de integridade Categoria
A prontidão para anexar API do firewall de desserialização está em um estado aceitável Disponibilidade da API de anexo do firewall de desserialização Crítico
O firewall de desserialização está funcionando Firewall de desserialização funcional Crítico
O firewall de desserialização é carregado Firewall de desserialização carregado Crítico
A implementação AuthorizableNodeName não expõe a ID autorizável no nome/caminho do nó. Geração do nome do nó autorizada Crítico
As senhas padrão foram alteradas Contas padrão de logon Crítico
O servlet de GET padrão Sling está protegido contra ataques de DOS. Sling Get Servlet Crítico
O Manipulador de Sling Java Script está configurado adequadamente Sling Java Script Handler Crítico
O Sling JSP Script Handler está configurado adequadamente Manipulador de script JSP Sling Crítico
O SSL está configurado corretamente Configuração do SSL Crítico
Nenhuma política de perfil do usuário obviamente insegura encontrada Acesso padrão ao perfil de usuário Crítico
O Filtro de Quem indicou Sling está configurado para impedir ataques CSRF Sling Referrer Filter Importante
O Gerenciador de biblioteca HTML do Adobe Granite está configurado adequadamente Configuração do gerenciador de biblioteca HTML CQ Importante
O pacote de suporte CRXDE está desativado Suporte do CRXDE Importante
O conjunto e o servlet Sling DavEx estão desativados Verificação de integridade do DavEx Importante
O conteúdo de amostra não está instalado Pacotes de conteúdo de exemplo Importante
O Filtro de Solicitação WCM e o Filtro de Depuração WCM estão desativados Configuração de filtros WCM Importante
O pacote e o servlet WebDAV Sling estão configurados adequadamente Verificação de integridade do WebDAV Importante
O servidor da Web está configurado para impedir o recurso de clickjacking Configuração de servidor da Web Importante
A replicação não está usando o usuário 'admin' Reprodução e usuários de transporte Informações

Teste de desempenho

O teste de desempenho em Cloud Manager é implementado usando um teste de 30 minutos.

Durante a configuração do pipeline, o gerente de implantação pode decidir quanto tráfego direcionar para cada bucket.

Você pode saber mais sobre controles de bucket, em Configure seu PipelineCI/CD.

Observação

Para configurar seu programa e definir seus KPIs, consulte Configurar seu Programa.

A tabela a seguir resume a matriz de teste de desempenho usando o sistema portátil de três níveis:

Métrica Categoria Limite de falha
Taxa de erro de solicitação de página % Crítico >= 2%
Taxa de utilização da CPU Crítico >= 80%
Tempo de espera de E/S de disco Crítico >= 50%
Tempo de Resposta de 95% Importante >= KPI em nível de Programa
Tempo de resposta máximo Importante >= 18 segundos
Visualizações de página por minuto Importante < KPI em nível de Programa
Utilização da largura de banda do disco Importante >= 90%
Utilização da largura de banda da rede Importante >= 90%
Solicitações por minuto Informações >= 6000

Gráficos de resultados de teste de desempenho

Novos gráficos e opções de download foram adicionados à caixa de diálogo Resultados do teste de desempenho.

Ao abrir a caixa de diálogo Teste de desempenho, os painéis de métricas podem ser expandidos para exibir um gráfico, fornecer um link para um download ou ambos.

Para a Cloud Manager versão 2018.7.0, essa funcionalidade está disponível para as seguintes métricas:

  • Utilização da CPU

    • Um gráfico de Utilização da CPU durante o período de teste.
  • Tempo de espera de E/S do disco

    • Um gráfico de Tempo de espera de E/S do disco durante o período de teste.
  • Taxa de erro de página

    • Um gráfico de erros de página por minuto durante o período de teste.
    • Um arquivo CSV que lista as páginas que apresentaram um erro durante o teste.
  • Utilização da largura de banda do disco

    • Um gráfico de Utilização da Largura de Banda do Disco durante o período de teste.
  • Utilização da largura de banda da rede

    • Um gráfico de Utilização da Largura de Banda da Rede durante o período de teste.
  • Tempo de resposta máximo

    • Um gráfico do tempo de resposta de pico por minuto durante o período de teste.
  • 95.º Percentual de Tempo de Resposta

    • Gráfico de 95% de tempo de resposta por minuto durante o período de teste.
    • Um arquivo CSV que lista as páginas cujo tempo de resposta do 95º percentil excedeu o KPI definido.

As seguintes imagens exibem os gráficos de teste de desempenho:

Nesta página