Sådan bruger du Checksum til kontinuerlig ende-til-ende-test i CI/CD

At køre end-to-end-tests (E2E) i CI/CD fungerer kun, hvis din testsuite kan udvikle sig sammen med din applikation. Når dit produkt ændrer sig, kan det hurtigt blive flaskehalsen, der forsinker hver udgivelse, manuelt at oprette nye tests og rette tests, der er gået i stykker.

Checksum er udviklet til at automatisere en stor del af denne proces. 

Denne vejledning viser dig, hvordan du forbinder Checksum med dit miljø og repository, genererer og kører Playwright-tests i din CI/CD-pipeline og aktiverer autonom vedligeholdelse, efterhånden som din applikation udvikler sig.

Sådan understøtter Checksum løbende E2E-test

Checksum understøtter løbende E2E-test gennem en kontinuerlig arbejdsgang:

1. Opsætning: Forbinder dit repository og testmiljø.
2. Registrering: Analyserer din applikation og identificerer de vigtigste brugerflows, der skal testes.
3. Generering: Opretter produktionsklare Playwright-tests og leverer dem som pull requests til dit repository.
4. Kørsel: Kører disse tests lokalt eller i din CI/CD-pipeline, mens automatisk gendannelse forsøger at løse midlertidige fejl under kørslen.
5. Udbedring: Opdaterer Playwright-tests, der er gået i stykker, når din applikation ændrer sig, og åbner en pull request med den foreslåede rettelse.
6. Overvågning: Følger testenes tilstand og advarer dit team, når problemer kræver opmærksomhed.

Da hver test er standard Playwright-kode, bevarer du det fulde ejerskab og kan køre testsuiten med eller uden Checksum.

Forudsætninger for løbende E2E-test i Checksum

Før du konfigurerer Checksum til løbende E2E-test, skal du sikre dig, at følgende er klar.

Et test- eller produktionslignende miljø

Checksum tester mod en aktiv applikation, så du skal bruge et tilgængeligt test- eller produktionslignende miljø med en miljø-URL. Hvis din applikation kræver godkendelse, skal du konfigurere en login-URL og angive legitimationsoplysninger til en testbruger, som Checksum kan bruge til at logge ind og analysere din applikations brugerflows.

Et forbundet repository og en CI-pipeline

Forbind dit GitHub- eller GitLab-repository, så Checksum kan analysere din kodebase og oprette pull requests med genererede eller opdaterede Playwright-tests. Hvis dine tests ligger i et separat repository, forbedrer det nøjagtigheden af flowregistreringen at forbinde både kilde-repositoryet og testrepositoryet.

Du skal også bruge en CI-platform til at køre dine tests. Checksum har indbygget understøttelse af GitHub Actions og GitLab CI/CD, mens andre CI-platforme kan integreres via Checksum CLI eller den offentlige API.

Et Checksum-projekt og en API-nøgle

Opret et Checksum-projekt i webappen, og generer en projekt-API-nøgle fra projektindstillingerne. API-nøglen godkender Checksum CLI og giver din CI-pipeline mulighed for at hente de miljøvariabler, der kræves for at køre dine tests.

Hvis du gerne vil have en mere detaljeret gennemgang af den indledende opsætningsproces, kan du også besøge Checksums side Kom godt i gang.

Sådan udfører du løbende E2E-test i Checksum

Trinnene nedenfor forudsætter, at du har oprettet et Checksum-projekt og har din API-nøgle klar.

Trin 1. Forbind dit miljø og repository

I webappens opsætningsguide skal du angive din miljø-URL (f.eks. https://staging.myapp.com) og login-URL samt tilføje legitimationsoplysningerne til den testbruger, som Checksum skal logge ind med. 

Installer derefter Git-appen til GitHub eller GitLab, så Checksum kan læse din kode og åbne PR'er. Hvis dine tests skal ligge sammen med din kildekode, skal du forbinde det samme repository til begge dele.

Trin 2. Initialiser dit testrepository

Opret (eller udpeg) et repo til dine tests, og initialiser det med CLI'en:

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

npm init -y

npm install @checksum-ai/runtime playwright

npx checksumai init

Dette opretter en checksum/-mappe med konfiguration, en Playwright-konfiguration og en eksempeltest. Kontrollér forbindelsen, før du går videre:

npm install

npx playwright install --with-deps

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

npx checksumai test -g "example"

Eksempeltesten bekræfter, at login fungerer i dit miljø. Et grønt resultat betyder, at du er klar til at registrere virkelige flows.

Trin 3. Lad agenten registrere kritiske brugerflows

Udløs en registreringssession, og lad E2E-agenten analysere din applikation for at identificere vigtige brugerflows. Når registreringen er fuldført, skal du gennemgå de foreslåede flows og prioritere dem, der er mest relevante for din udgivelse, før du genererer tests.

Trin 4. Generér produktionsklare Playwright-tests

Generér Playwright-tests for de flows, du har valgt. 

Agenten planlægger, implementerer, gennemgår og verificerer hver test, før den åbner en pull request med en menneskeligt læsbar story-fil og Playwright-testen. 

Gennemgå pull requesten som enhver anden kodeændring, og flet derefter de tests ind, som du er klar til at føje til din testpakke.

Trin 5. Tilslut tests til din CI/CD-pipeline

I GitHub Actions skal du gemme din API-nøgle og dine miljøværdier som repository-hemmeligheder og derefter tilføje en workflow, der installerer Playwright, downloader Checksum-miljøfilen og kører testpakken:

name: Kør Checksum-tests
on:
  workflow_dispatch:        # manuel udløser til start
  # schedule:
  #   - cron: '0 0 * * *'   # hver nat, når det er verificeret
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installér npm-afhængigheder
        run: npm install
      - name: Installér Playwright med afhængigheder
        run: npx playwright install --with-deps
      - name: Download .env fra Checksum
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Kør Checksum-tests
        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

GitLab CI/CD følger samme struktur i .gitlab-ci.yml. Start med en manuel udløser (workflow_dispatch / when: manual) for at bekræfte, at kørslen fungerer korrekt, og gå derefter over til en tidsplan for natlige sundhedstjek eller en fletteudløser for at verificere efter implementeringer.

Trin 6. Tilføj kørsler pr. pull request, og aktivér autonom reparation

Hvis du vil have Checksum til at køre tests for hver pull request, skal du bruge den officielle GitHub Action i stedet for selv at køre CLI'en på din egen runner. Det er nyttigt til at validere de ændringer, der introduceres i hver pull request.

name: Checksum-tests
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

Indstillingen grep filtrerer, hvilke tests der køres efter navn, mens auto-heal: true aktiverer automatisk reparation, når en test mislykkes. 

Som standard afsluttes workflowet, når kørslen er accepteret, og resultaterne slås op som en kommentar på pull requesten. Hvis du vil have workflowet til at vente på det endelige resultat og bestå eller fejle tilsvarende, skal du angive wait: true.

Med automatisk selvheling aktiveret forsøger Checksum at gendanne i realtid under testkørslen. Hvis testen stadig mislykkes, opdaterer den Playwright-testen, åbner en pullanmodning med den foreslåede løsning og offentliggør status som en kommentar på den oprindelige pullanmodning. 

Dit team kan derefter gennemgå og sammenflette ændringerne ligesom ethvert andet kodebidrag.

Sådan ser vellykket kontinuerlig E2E-test ud

Når Checksum er integreret i din CI/CD-pipeline, bør du forvente at se følgende:

• Din E2E-testsuite kører automatisk baseret på den udløser, du har konfigureret, herunder pullanmodninger, planlagte kørsler og udrulninger.
• Nye brugerflows registreres og konverteres til Playwright-tests uden manuelt at skrive hver enkelt test.
• Testfejl forårsaget af ændringer i applikationen løses gennem automatisk gendannelse eller selvheling, før der kræves manuelle opdateringer.
• Dit team bruger mindre tid på at vedligeholde Playwright-tests og mere tid på at gennemgå meningsfulde testændringer, der leveres via pullanmodninger.

For at måle din implementeringsstatus skal du overvåge din beståelsesrate for tests, procentdelen af tests, der er blevet selvhelet automatisk, den gennemsnitlige tid til at løse testfejl og raten af falske positive. 

Disse målinger hjælper dig med at forstå, hvor pålideligt din E2E-testsuite kører, efterhånden som din applikation udvikler sig. Hvis du vil sammenligne dine resultater med produktionsbenchmarks, Checksums benchmarkrapport for QA indeholder data for disse målinger baseret på mere end 1 mio. reelle produktionskørsler.

Almindelige fejl ved kontinuerlig E2E-test og eksperttips

Selv med den rette opsætning kan nogle få almindelige fejl påvirke testkvalitet, udførelse og vedligeholdelse. Her er de ting, du skal være opmærksom på, og hvordan du undgår dem.

Kørsel af tests mod et ustabilt miljø

Hvis dine testresultater er inkonsistente eller mislykkes, før meningsfuld testudførelse begynder, er dit testmiljø muligvis ikke klart. Sørg for, at dit stagingmiljø eller produktionslignende miljø er stabilt, at legitimationsoplysningerne til din testbruger fungerer korrekt, og at eksempeltesten består, før du genererer yderligere dækning.

Generering af for mange brugerflows

Checksum identificerer muligvis flere brugerflows, end du har brug for i første omgang. Generering af tests for alle kandidater øger udførelsestiden og den tid, der bruges på gennemgang. Start med de arbejdsgange, der er mest kritiske for dine udgivelser, og udvid derefter dækningen over tid.

Sammenfletning af genererede tests uden gennemgang

Genererede og selvhelede tests leveres som pullanmodninger, så dit team kan validere hver ændring, før den bliver en del af testsuiten. Gennemgå nye tests omhyggeligt i de tidlige faser af implementeringen, og opbyg gradvist tillid til genereringsprocessen.

Automatisering af din pipeline for tidligt

Før du planlægger kørsler eller udløser tests for hver pullanmodning, skal du bekræfte, at din pipeline er stabil ved manuelle kørsler. Når du konsekvent får pålidelige resultater, kan du automatisere arbejdsgangen med større sikkerhed.

Blokering af hver pullanmodning

Aktivering af wait: true får arbejdsgangen til at vente på, at testkørslen afsluttes, før den færdiggøres. Brug det kun til arbejdsgange, der skal blokere en sammenfletning. For alt andet giver standardkommentaren på pullanmodningen feedback uden at optage CI-kørere.

Konklusion

Du har nu set, hvordan Checksum indgår i en kontinuerlig E2E-testarbejdsgang – fra tilslutning af dit miljø og kodearkiv til generering af Playwright-tests, integrering af dem i din CI/CD-pipeline og aktivering af autonom vedligeholdelse. 

Efterhånden som din applikation udvikler sig, hjælper Checksum med at holde din E2E-testsuite pålidelig uden at tilføje samme niveau af manuel vedligeholdelse.

Hvis du vil udforske platformen yderligere, kan du læse vores dybdegående anmeldelse af Checksum for at få mere at vide om dens funktioner eller se, hvordan Checksum fungerer med din egen applikation, ved at kontakte deres team direkte.