Slik bruker du Checksum til kontinuerlig ende-til-ende-testing i CI/CD

Å kjøre ende-til-ende-tester (E2E) i CI/CD fungerer bare hvis testpakken kan utvikle seg sammen med applikasjonen. Når produktet endres, kan det å opprette nye tester manuelt og rette ødelagte tester raskt bli flaskehalsen som forsinker hver lansering.

Checksum er utviklet for å automatisere mye av denne prosessen. 

Denne veiledningen viser deg hvordan du kobler Checksum til miljøet og repositoriet ditt, genererer og kjører Playwright-tester i CI/CD-pipelinen din, og aktiverer autonomt vedlikehold etter hvert som applikasjonen utvikler seg.

Slik støtter Checksum kontinuerlig E2E-testing

Checksum støtter kontinuerlig E2E-testing gjennom en kontinuerlig arbeidsflyt:

1. Oppsett: Kobler til repositoriet og testmiljøet ditt.
2. Oppdage: Analyserer applikasjonen din og identifiserer de viktigste brukerflytene som bør testes.
3. Generere: Oppretter produksjonsklare Playwright-tester og leverer dem som pull requests til repositoriet ditt.
4. Kjøre: Kjører testene lokalt eller i CI/CD-pipelinen din, mens automatisk gjenoppretting forsøker å løse midlertidige feil under kjøringen.
5. Reparere: Oppdaterer ødelagte Playwright-tester når applikasjonen din endres, og åpner en pull request med den foreslåtte løsningen.
6. Overvåke: Følger med på testhelsen og varsler teamet ditt når problemer krever oppmerksomhet.

Siden hver test er standard Playwright-kode, beholder du fullt eierskap og kan kjøre testpakken med eller uten Checksum.

Forutsetninger for kontinuerlig E2E-testing i Checksum

Før du setter opp Checksum for kontinuerlig E2E-testing, må du sørge for at følgende er klart.

Et staging- eller produksjonslignende miljø

Checksum tester mot en aktiv applikasjon, så du trenger et tilgjengelig staging- eller produksjonslignende miljø med en miljø-URL. Hvis applikasjonen din krever autentisering, konfigurerer du en påloggings-URL og oppgir legitimasjon for en testbruker som Checksum kan bruke til å logge inn og analysere brukerflytene i applikasjonen din.

Et tilkoblet repositorium og en CI-pipeline

Koble til GitHub- eller GitLab-repositoriet ditt slik at Checksum kan analysere kodebasen din og opprette pull requests som inneholder genererte eller oppdaterte Playwright-tester. Hvis testene dine ligger i et separat repository, blir flytdeteksjonen mer nøyaktig når du kobler til både kilde- og testrepoet.

Du trenger også en CI-plattform for å kjøre testene. Checksum har innebygd støtte for GitHub Actions og GitLab CI/CD, mens andre CI-plattformer kan integreres gjennom Checksum CLI eller det offentlige API-et.

Et Checksum-prosjekt og en API-nøkkel

Opprett et Checksum-prosjekt i nettappen og generer en prosjekt-API-nøkkel fra prosjektinnstillingene. API-nøkkelen autentiserer Checksum CLI og gjør det mulig for CI-pipelinen din å laste ned miljøvariablene som kreves for å kjøre testene.

Hvis du ønsker en mer detaljert gjennomgang av den innledende oppsettsprosessen, kan du også besøke Checksums Kom i gang-side</em>.<em>

Slik utfører du kontinuerlig E2E-testing i Checksum

Trinnene nedenfor forutsetter at du har opprettet et Checksum-prosjekt og har API-nøkkelen tilgjengelig.

Trinn 1. Koble til miljøet og repositoriet ditt

I oppsettsveiviseren i nettappen angir du miljø-URL (f.eks. https://staging.myapp.com) og påloggings-URL, og legger til legitimasjonen for testbrukeren som Checksum skal autentisere med. 

Installer deretter Git-appen for GitHub eller GitLab, slik at Checksum kan lese koden din og åpne pull requests. Hvis testene skal ligge sammen med kildekoden, kobler du til det samme repoet for begge deler.

Trinn 2. Initialiser testrepoet ditt

Opprett (eller utpek) et repo for testene dine 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 oppretter en checksum/-mappe med konfigurasjon, en Playwright-konfigurasjon og en eksempeltest. Kontroller koblingen 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 bekrefter at innlogging fungerer mot miljøet ditt. Et grønt resultat betyr at du er klar til å oppdage reelle flyter.

Steg 3. La agenten oppdage kritiske brukerflyter

Utløs en oppdagingsøkt og la E2E-agenten analysere applikasjonen din for å identifisere viktige brukerflyter. Når oppdagelsen er fullført, går du gjennom de foreslåtte flytene og prioriterer dem som er mest relevante for lanseringen din, før du genererer tester.

Steg 4. Generer produksjonsklare Playwright-tester

Generer Playwright-tester for flytene du valgte. 

Agenten planlegger, implementerer, gjennomgår og verifiserer hver test før den åpner en pull request som inneholder en menneskelesbar story-fil og Playwright-testen. 

Gå gjennom pull request-en som enhver annen kodeendring, og slå deretter sammen testene du er klar til å legge til i testpakken.

Steg 5. Koble testene til CI/CD-pipelinen din

For GitHub Actions lagrer du API-nøkkelen og miljøverdiene som repository-hemmeligheter, og legger deretter til en arbeidsflyt som installerer Playwright, laster ned Checksum-miljøfilen og kjører testpakken:

name: Kjør Checksum-tester
on:
  workflow_dispatch:        # manuell utløser for å starte
  # schedule:
  #   - cron: '0 0 * * *'   # hver natt, når dette er bekreftet
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installer npm-avhengigheter
        run: npm install
      - name: Installer Playwright med avhengigheter
        run: npx playwright install --with-deps
      - name: Last ned .env fra Checksum
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Kjør Checksum-tester
        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 manuell utløsning (workflow_dispatch / when: manual) for å bekrefte at kjøringen fungerer, og gå deretter over til en tidsplan for nattlige helsesjekker eller en fletteutløsning for å verifisere etter distribusjoner.

Steg 6. Legg til kjøringer per PR og aktiver autonom reparasjon

Hvis du vil at Checksum skal kjøre tester for hver pull request, bruker du den offisielle GitHub-handlingen i stedet for å kjøre CLI-en på din egen runner. Dette er nyttig for å validere endringene som introduseres i hver pull request.

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

grep-alternativet filtrerer hvilke tester som kjøres etter navn, mens auto-heal: true aktiverer automatisk reparasjon når en test mislykkes. 

Som standard avsluttes arbeidsflyten etter at kjøringen er godtatt, og resultatene legges ut som en kommentar på pull request-en. Hvis du vil at arbeidsflyten skal vente på det endelige resultatet og bestå eller mislykkes tilsvarende, angir du wait: true.

Med automatisk selvretting aktivert forsøker Checksum å gjenopprette i sanntid under testkjøringen. Hvis testen fortsatt mislykkes, oppdaterer den Playwright-testen, åpner en pull request med det foreslåtte rettingsforslaget og legger ut fremdriften som en kommentar på den opprinnelige pull request-en. 

Teamet ditt kan deretter gjennomgå og slå sammen endringene på samme måte som alle andre kodebidrag.

Slik ser vellykket kontinuerlig E2E-testing ut

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

• E2E-testpakken din kjøres automatisk basert på utløseren du har konfigurert, inkludert pull requests, planlagte kjøringer og distribusjoner.
• Nye brukerflyter oppdages og konverteres til Playwright-tester uten at du må skrive hver test manuelt.
• Testfeil som skyldes endringer i applikasjonen, løses gjennom automatisk gjenoppretting eller automatisk selvretting før manuelle oppdateringer blir nødvendige.
• Teamet ditt bruker mindre tid på å vedlikeholde Playwright-tester og mer tid på å gjennomgå meningsfulle testendringer som leveres gjennom pull requests.

For å måle helsen til implementeringen din bør du følge med på testbeståelsesraten, prosentandelen tester som er rettet automatisk, gjennomsnittlig tid til å løse testfeil og andelen falske positiver. 

Disse målingene hjelper deg med å forstå hvor pålitelig E2E-testpakken kjører etter hvert som applikasjonen utvikler seg. For å sammenligne resultatene dine med produksjonsreferanser gir Checksums QA-referanserapport data for disse målingene basert på mer enn 1 million reelle produksjonskjøringer.

Vanlige feil ved kontinuerlig E2E-testing og eksperttips

Selv med riktig oppsett kan noen vanlige feil påvirke testkvalitet, kjøring og vedlikehold. Her er tingene du bør være oppmerksom på, og hvordan du kan unngå dem.

Kjøre tester mot et ustabilt miljø

Hvis testresultatene dine er inkonsekvente eller testene mislykkes før meningsfull testkjøring begynner, er testmiljøet kanskje ikke klart. Sørg for at staging- eller produksjonslignende miljøet ditt er stabilt, at påloggingsinformasjonen til testbrukeren fungerer som den skal, og at eksempeltesten består før du genererer ytterligere dekning.

Generere for mange brukerflyter

Checksum kan identifisere flere brukerflyter enn du trenger i utgangspunktet. Å generere tester for alle kandidater øker kjøretiden og arbeidsmengden ved gjennomgang. Begynn med arbeidsflytene som er viktigst for lanseringene dine, og utvid deretter dekningen over tid.

Slå sammen genererte tester uten gjennomgang

Genererte og selvrettede tester leveres som pull requests, slik at teamet ditt kan validere hver endring før den blir en del av testpakken. Gå nøye gjennom nye tester i de tidlige fasene av innføringen, og bygg gradvis tillit til genereringsprosessen.

Automatisere pipelinen for tidlig

Før du planlegger kjøringer eller utløser tester for hver pull request, må du bekrefte at pipelinen er stabil ved manuelle kjøringer. Når du konsekvent får pålitelige resultater, kan du automatisere arbeidsflyten med større trygghet.

Blokkere alle pull requests

Hvis du aktiverer wait: true, venter arbeidsflyten på at testkjøringen skal fullføres før den avsluttes. Bruk dette bare for arbeidsflyter som må blokkere en sammenslåing. For alt annet gir standardkommentaren på pull request-en tilbakemelding uten å binde opp CI-kjørere.

Konklusjon

Du har nå sett hvordan Checksum inngår i en arbeidsflyt for kontinuerlig E2E-testing, fra å koble til miljøet og repositoriet ditt til å generere Playwright-tester, integrere dem i CI/CD-pipelinen og aktivere autonomt vedlikehold. 

Etter hvert som applikasjonen din utvikler seg, bidrar Checksum til å holde E2E-testpakken pålitelig uten å tilføre samme nivå av manuelt vedlikehold.

Hvis du vil utforske plattformen videre, kan du lese vår grundige gjennomgang av Checksum for å lære mer om funksjonene, eller se hvordan Checksum fungerer med din egen applikasjon ved å koble deg direkte til teamet deres.