Relatórios de teste detalhados e visualmente atraentes são cruciais para que os testadores de software entendam os resultados dos testes e tomem decisões informadas. Com atenção meticulosa aos detalhes, a equipe do Social Discovery Group cria relatórios de teste visualmente cativantes com a ajuda do Allure Reports – a potência do código aberto que parecia ter todas as respostas. No entanto, descobrimos uma falha: segurança. Qualquer pessoa com um link poderia espiar o interior, e faltava sua adaptabilidade entre subsistemas. Neste artigo, a equipe de testes do SDG compartilha como eles conseguiram resolver problemas de segurança de relatórios do Allure criando um Allure Docker adequado e modificando o esquema de armazenamento.  O ambiente de desenvolvimento SDG é baseado em produtos Microsoft, com Azure DevOps utilizado para executar processos de CI/CD. Por meio do pipeline de CI, é construído o repositório de testes automatizados, seguido da categorização por meio de diversos pipelines de CD com base nas preferências dos testadores para execução de testes.  Vamos considerar o esquema tal como foi originalmente configurado:   Nessa configuração, o pipeline de CD também serve como gerador para dois relatórios do Allure: um para notificações do Slack, fornecendo aos testadores um link convenientemente legível especificando estágios e categorias de teste, e outro para exportar o relatório do Allure para o Azure DevOps.  Isto é conseguido através da instalação de uma extensão no Azure DevOps, que permite a geração de relatórios e posterior upload para o contentor $web para sites estáticos na conta de armazenamento do Azure. A configuração habilitada de acesso anônimo permite que o relatório seja exibido através de um link.   Para maior comodidade, um plugin adicional também foi usado para exibir o relatório Allure no pipeline de construção.   Embora este esquema seja funcional, ele tem algumas desvantagens:  Em primeiro lugar, este método carece de segurança, pois os relatórios do Allure são acessíveis a qualquer pessoa com o link. Dependendo do teste, o relatório pode conter informações confidenciais sobre serviços, suas vulnerabilidades e quaisquer outros dados confidenciais cujo acesso público deva ser restrito. O acesso geral é concedido devido ao sinalizador de "acesso anônimo" habilitado na conta de armazenamento do Azure, que fornece a qualquer pessoa acesso ao endereço. Desabilitar essa função interromperia o acesso externo aos arquivos para indivíduos não autorizados, mas também tornaria o relatório inacessível na página do Azure DevOps.  Em segundo lugar, o método não é universalmente aplicável em todos os subsistemas. Se examinarmos a lista de trabalhos no pipeline do CD, veremos que o trabalho nativo "azcopy" é usado para copiar o relatório para a conta de armazenamento. Este trabalho está disponível apenas com agentes no Windows e, ao usar Linux, retorna um erro.   Em terceiro lugar, há a inconveniência de visualizar o histórico e as tendências dos testes. O único histórico de relatórios disponível pode ser acessado por meio de notificações do Slack, o que não é um método conveniente para encontrar testes específicos.  Todos os factores acima mencionados levaram à conclusão de que o sistema existente necessita de ser modificado. Portanto, foram consideradas diversas soluções para este problema:  Criação de um método para gerar um arquivo .html unificado que combinaria todo o projeto de relatório do Allure em um documento.  Utilizar serviços de terceiros que oferecem autenticação para visualização do relatório.  Busca de imagem pré-fabricada com autenticação própria para visualização de relatórios.  Agora, vamos nos aprofundar em cada um desses pontos com mais detalhes.  Conforme mencionado anteriormente, desabilitar a função de “acesso anônimo” na conta de armazenamento restringe o acesso aos arquivos através do link para usuários não autorizados. Para fornecer acesso a indivíduos específicos de fora, o próprio Azure oferece várias opções possíveis - incluindo a concessão de tokens SAS e a configuração de políticas de acesso. No entanto, devido à natureza da geração do relatório Allure, especificamente do arquivo index.html, que faz referência a scripts JavaScript existentes na estrutura do projeto:   Ao abrir o relatório, a página fica vazia porque o acesso entre arquivos dentro do próprio armazenamento de blobs é restrito.  Para criar um único arquivo .html, descobrimos um  que, quando implantado, facilitou a geração do arquivo de um projeto Allure inteiro usando o comando incorporado "allure-combine ./path/to/allure/generated/report/folder". No entanto, este processo requer que o agente tenha o Python instalado. Infelizmente, esta abordagem mostrou-se ineficaz devido à ausência de arquivos anexados aos resultados dos testes da API, componentes cruciais para garantir o bom funcionamento do trabalho dos testadores.    imagem  Também é importante notar que o Azure oferece lista de permissões de IP, que permite a filtragem de indivíduos que necessitam de acesso. Porém, como a equipe que necessita de acesso não possui um endereço IP estático, esse método não era adequado.  Considerando que o Allure é uma prática popular de coleta de testes no ambiente de desenvolvimento, existem serviços pagos disponíveis online. Por exemplo, o serviço   fornece armazenamento e geração de relatórios Allure em uma interface web amigável. No entanto, esses serviços são normalmente pagos e a funcionalidade necessária é mínima. Portanto, consideramos esta opção de implementação como último recurso. https://qameta.io/  A escolha que escolhemos foi a imagem Docker do serviço allure-docker (   ) com a capacidade de integração do painel de interface do usuário (   ) com autenticação. A comunicação com o serviço é configurada via HTTP/HTTPS, e a própria imagem oferece suporte à funcionalidade por meio de solicitações de API. https://github.com/fescobar/allure-docker-service https://github.com/fescobar/ allure-docker-service-ui  Vamos destacar algumas vantagens desta solução:  Segurança: A transmissão de dados é criptografada usando mecanismos SSL e TLS, e a imagem fornece aos usuários integrados "admin" e "visualizador" credenciais de login que podem ser modificadas e fornecidas aos usuários com base em suas necessidades.  Conveniência: O serviço vem com interface visual própria que oferece diversas funcionalidades para trabalhar com relatórios Allure.  Funcionalidade: graças às solicitações de API, combinações interessantes podem ser criadas com pipelines de lançamento no lado do Azure DevOps. Por exemplo, gerar um relatório, carregá-lo e limpar o cache em um único estágio.  Concluindo, nosso pipeline de lançamento é assim:   Vale ressaltar que não nos afastamos da extensão Azure DevOps, que permite o upload de relatórios Allure, pois nessa época já havíamos feito a transição para nossos próprios agentes e aderido à ideia de ter tudo funcionando "por conta própria "máquinas.  Em relação ao armazenamento, experimentamos gravar em contas de armazenamento do Azure, carregando especificamente para File Share, Blob e Blob usando o utilitário azcopy.  Os resultados variaram significativamente. Ao usar o comando para File Share az storage file upload-batch, a velocidade de gravação para nosso teste foi superior a uma hora:   Ao utilizar o Blob Storage com o comando az storage blob upload-batch, o desempenho melhorou seis vezes, demorando aproximadamente 11 minutos:   O resultado mais rápido foi pela ferramenta azcopy:   Embora use a integração interna do azcopy no pipeline de lançamento, ele é incompatível com máquinas Linux. No entanto, ao utilizar o trabalho Azure CLI e instalar este utilitário no agente, o comando pode ser empregue com confiança:   azcopy copy 'FONTE' 'DESTINO' --recursive=true  Graças à descoberta da imagem Allure Docker nas profundezas da rede, conseguimos modificar o esquema de armazenamento e exibição dos relatórios. O acesso aos dados agora é protegido por senha e a criação e o processamento de relatórios permanecem rápidos. Além disso, do ponto de vista dos utilizadores (testadores), as mudanças são mínimas. A solução opera independentemente de outros programas, graças a um agente separado no cluster, e não pode afetar outros processos de desenvolvimento. A relação custo-benefício desta solução é comparável à de um agente auto-hospedado separado (US$ 15, desde que isolado), que é muito mais barato do que as alternativas existentes. Por exemplo, o anteriormente considerado qameta.io, onde o preço para um único usuário é de US$ 30/mês.   Escrito por Dmitrijs Gusarovs, engenheiro Middle DevOps do Social Discovery Group.   Social Discovery Group (SDG) é uma empresa global de tecnologia que cria aplicativos de descoberta social na interseção de namoro, social e entretenimento. O portfólio da empresa inclui 70 plataformas com foco em IA, mecânica de jogos e streaming de vídeo. Os produtos ODS são utilizados por mais de 500 milhões de pessoas em 150 países.

This is a PR written by or for the company mentioned within it. The writer has a vested interest in the company and products mentioned within.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Como resolver problemas de segurança do relatório Allure

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Uma breve introdução à teoria do cérebro de Boltzmann

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Uma breve introdução à teoria do cérebro de Boltzmann

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps