Como utilizar o Checksum para testes contínuos de ponta a ponta em CI/CD

A execução de testes de ponta a ponta (E2E) em CI/CD só funciona se o seu conjunto de testes puder evoluir com a sua aplicação. À medida que o seu produto muda, criar manualmente novos testes e corrigir os que deixaram de funcionar pode rapidamente tornar-se o obstáculo que abranda cada lançamento.

O Checksum foi criado para automatizar grande parte desse processo. 

Este guia mostra-lhe como ligar o Checksum ao seu ambiente e repositório, gerar e executar testes Playwright no seu pipeline de CI/CD e ativar a manutenção autónoma à medida que a sua aplicação evolui.

Como o Checksum suporta testes E2E contínuos

O Checksum suporta testes E2E contínuos através de um fluxo de trabalho contínuo:

1. Configuração: liga o seu repositório e ambiente de testes.
2. Deteção: analisa a sua aplicação e identifica os fluxos de utilizador mais importantes a testar.
3. Geração: cria testes Playwright prontos para produção e entrega-os como pedidos de integração no seu repositório.
4. Execução: executa esses testes localmente ou no seu pipeline de CI/CD, enquanto a recuperação automática tenta resolver falhas temporárias durante a execução.
5. Correção: atualiza testes Playwright que deixaram de funcionar quando a sua aplicação muda e abre um pedido de integração com a correção proposta.
6. Monitorização: acompanha o estado dos testes e alerta a sua equipa quando é necessária atenção.

Como cada teste é código Playwright padrão, mantém a propriedade total e pode executar o conjunto de testes com ou sem o Checksum.

Pré-requisitos para testes E2E contínuos no Checksum

Antes de configurar o Checksum para testes E2E contínuos, certifique-se de que os seguintes elementos estão prontos.

Um ambiente de preparação ou semelhante ao de produção

O Checksum testa uma aplicação ativa, pelo que precisará de um ambiente de preparação ou semelhante ao de produção acessível, com um URL do ambiente. Se a sua aplicação exigir autenticação, configure um URL de início de sessão e forneça credenciais de utilizador de teste que o Checksum possa utilizar para iniciar sessão e analisar os fluxos de utilizador da sua aplicação.

Um repositório e pipeline de CI ligados

Ligue o seu repositório GitHub ou GitLab para que o Checksum possa analisar a sua base de código e criar pedidos de integração que contenham testes Playwright gerados ou atualizados. Se os seus testes estiverem num repositório separado, ligar tanto o repositório de origem como o repositório de testes melhora a precisão da deteção de fluxos.

Também precisará de uma plataforma de CI para executar os seus testes. O Checksum fornece suporte integrado para GitHub Actions e GitLab CI/CD, enquanto outras plataformas de CI podem ser integradas através da CLI do Checksum ou da API pública.

Um projeto Checksum e uma chave de API

Crie um projeto Checksum na aplicação Web e gere uma chave de API do projeto em Definições do projeto. A chave de API autentica a CLI do Checksum e permite que o seu pipeline de CI transfira as variáveis de ambiente necessárias para executar os seus testes.

Se pretender uma explicação mais detalhada do processo de configuração inicial, pode também visitar Página de introdução do Checksum.

Como realizar testes E2E contínuos no Checksum

Os passos abaixo pressupõem que criou um projeto Checksum e que tem a sua chave de API disponível.

Passo 1. Ligue o seu ambiente e repositório

No assistente de configuração da aplicação Web, defina o seu URL do ambiente (por exemplo, https://staging.myapp.com) e o URL de início de sessão, e adicione as credenciais do utilizador de teste com as quais o Checksum irá autenticar-se. 

Em seguida, instale a aplicação Git para GitHub ou GitLab, para que o Checksum possa ler o seu código e abrir pedidos de integração. Se os seus testes forem armazenados juntamente com o código-fonte, ligue o mesmo repositório para ambos.

Passo 2. Inicialize o seu repositório de testes

Crie (ou designe) um repositório para os seus testes e inicialize-o com a CLI:

mkdir my-checksum-tests && cd my-checksum-tests

npm init -y

npm install @checksum-ai/runtime playwright

npx checksumai init

Isto cria uma pasta checksum/ com configuração, uma configuração do Playwright e um teste de exemplo. Verifique a integração antes de prosseguir:

npm install

npx playwright install --with-deps

npx checksumai dotenv --download --api-key=<YOUR_API_KEY>

npx checksumai test -g "example"

O teste de exemplo confirma que o início de sessão funciona no seu ambiente. Um resultado positivo significa que está pronto para detetar fluxos reais.

Passo 3. Permita que o agente detete fluxos de utilizador críticos

Acione uma sessão de deteção e permita que o agente E2E analise a sua aplicação para identificar fluxos de utilizador importantes. Quando a deteção estiver concluída, reveja os fluxos propostos e atribua prioridade aos mais relevantes para a sua versão antes de gerar os testes.

Passo 4. Gere testes Playwright prontos para produção

Gere testes Playwright para os fluxos que selecionou. 

O agente planeia, implementa, revê e verifica cada teste antes de abrir um pedido de integração que contém um ficheiro de história legível por humanos e o teste Playwright. 

Reveja o pedido de integração como qualquer outra alteração de código e, em seguida, faça a integração dos testes que está pronto para adicionar ao seu conjunto.

Passo 5. Integre os testes na sua pipeline de CI/CD

Para o GitHub Actions, armazene a sua chave de API e os valores do ambiente como segredos do repositório e, em seguida, adicione um fluxo de trabalho que instale o Playwright, transfira o ficheiro de ambiente do Checksum e execute o conjunto de testes:

name: Executar testes do Checksum
on:
  workflow_dispatch:        # acionamento manual para iniciar
  # schedule:
  #   - cron: '0 0 * * *'   # todas as noites, depois de verificado
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Instalar dependências npm
        run: npm install
      - name: Instalar o Playwright com dependências
        run: npx playwright install --with-deps
      - name: Transferir .env do Checksum
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Executar testes do Checksum
        run: npx checksumai test
        env:
          CHECKSUM_API_KEY: ${{ secrets.CHECKSUM_API_KEY }}
          USERNAME: ${{ secrets.USERNAME }}
          PASSWORD: ${{ secrets.PASSWORD }}
          LOGIN_URL: ${{ secrets.LOGIN_URL }}
          BASE_URL: ${{ secrets.BASE_URL }}
          CI: true

O GitLab CI/CD segue a mesma estrutura em .gitlab-ci.yml. Comece com um acionamento manual (workflow_dispatch / when: manual) para confirmar que a execução está a funcionar corretamente e, em seguida, passe para uma agenda de verificações noturnas do estado ou para um acionamento após a integração, de modo a verificar o sistema depois das implementações.

Passo 6. Adicione execuções por pedido de integração e ative a autorreparação

Se quiser que o Checksum execute testes para cada pedido de integração, utilize a ação oficial do GitHub em vez de executar a CLI no seu próprio executor. Isto é útil para validar as alterações introduzidas em cada pedido de integração.

name: Testes do Checksum
on: pull_request
permissions:
  contents: read
  pull-requests: read
jobs:
  checksum:
    runs-on: ubuntu-latest
    steps:
      - uses: checksum-ai/test-run-action@v1
        with:
          api-key: ${{ secrets.CHECKSUM_API_KEY }}
          grep: 'checkout'
          auto-heal: true

A opção grep filtra os testes executados pelo nome, enquanto auto-heal: true ativa a autorreparação quando um teste falha. 

Por predefinição, o fluxo de trabalho termina depois de a execução ser aceite e publica os resultados como um comentário no pedido de integração. Se quiser que o fluxo de trabalho aguarde pelo resultado final e seja aprovado ou reprovado em conformidade, defina wait: true.

Com a recuperação automática ativada, o Checksum tenta recuperar os erros em tempo real durante a execução do teste. Se o teste continuar a falhar, atualiza o teste do Playwright, abre um pedido de integração com a correção proposta e publica o progresso como comentário no pedido de integração original. 

A sua equipa pode então rever e integrar as alterações como qualquer outra contribuição de código.

Como é o sucesso nos testes E2E contínuos

Depois de integrar o Checksum no seu pipeline de CI/CD, deverá esperar o seguinte:

• O seu conjunto de testes E2E é executado automaticamente com base no acionador que configurou, incluindo pedidos de integração, execuções agendadas e implementações.
• Os novos fluxos de utilizador são detetados e convertidos em testes do Playwright sem ter de escrever manualmente cada teste.
• As falhas dos testes causadas por alterações na aplicação são resolvidas através de recuperação automática ou correção automática antes de serem necessárias atualizações manuais.
• A sua equipa passa menos tempo a manter os testes do Playwright e mais tempo a rever alterações relevantes aos testes, disponibilizadas através de pedidos de integração.

Para medir o estado da sua implementação, acompanhe a taxa de aprovação dos testes, a percentagem de testes corrigidos automaticamente, o tempo médio de resolução das falhas dos testes e a taxa de falsos positivos. 

Estas métricas ajudam-no a compreender com que fiabilidade o seu conjunto de testes E2E está a ser executado à medida que a sua aplicação evolui. Para comparar os seus resultados com referências de produção, o Relatório de referência de QA do Checksum fornece dados relativos a estas métricas com base em mais de 1 milhão de execuções reais em produção.

Erros comuns nos testes E2E contínuos e dicas profissionais

Mesmo com a configuração adequada, alguns erros comuns podem afetar a qualidade, a execução e a manutenção dos testes. Eis o que deve ter em atenção e como evitar esses problemas.

Executar testes num ambiente instável

Se os resultados dos seus testes forem inconsistentes ou falharem antes de começar uma execução de testes relevante, o seu ambiente de testes poderá não estar pronto. Certifique-se de que o seu ambiente de preparação ou semelhante ao de produção é estável, que as credenciais do utilizador de teste funcionam corretamente e que o teste de exemplo é aprovado antes de gerar cobertura adicional.

Gerar demasiados fluxos de utilizador

O Checksum pode identificar mais fluxos de utilizador do que aqueles de que necessita inicialmente. Gerar testes para todos os candidatos aumenta o tempo de execução e o esforço de revisão. Comece pelos fluxos de trabalho mais importantes para as suas versões e, em seguida, amplie a cobertura ao longo do tempo.

Integrar testes gerados sem revisão

Os testes gerados e corrigidos são disponibilizados como pedidos de integração para que a sua equipa possa validar cada alteração antes de esta passar a fazer parte do conjunto de testes. Reveja cuidadosamente os novos testes durante as primeiras fases de adoção e ganhe confiança no processo de geração ao longo do tempo.

Automatizar o seu pipeline demasiado cedo

Antes de agendar execuções ou acionar testes para cada pedido de integração, confirme que o seu pipeline é estável através de execuções manuais. Quando obtiver resultados fiáveis de forma consistente, poderá automatizar o fluxo de trabalho com maior confiança.

Bloquear todos os pedidos de integração

Ativar wait: true faz com que o fluxo de trabalho aguarde pela conclusão da execução do teste antes de terminar. Utilize esta opção apenas nos fluxos de trabalho que precisam de bloquear uma integração. Para tudo o resto, o comentário predefinido no pedido de integração fornece feedback sem ocupar os executores de CI.

Conclusão

Viu agora como o Checksum se integra num fluxo de trabalho de testes E2E contínuos, desde a ligação do seu ambiente e repositório à geração de testes do Playwright, à sua integração no pipeline de CI/CD e à ativação da manutenção autónoma. 

À medida que a sua aplicação evolui, o Checksum ajuda a manter o seu conjunto de testes E2E fiável sem acrescentar o mesmo nível de manutenção manual.

Se quiser explorar melhor a plataforma, pode ler a nossa análise aprofundada do Checksum para saber mais sobre as suas capacidades ou ver como o Checksum funciona com a sua própria aplicação, contactando diretamente a equipa.