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.

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.

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

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.

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.

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: