Så använder du Checksum för kontinuerlig end-to-end-testning i CI/CD

Att köra end-to-end-tester (E2E) i CI/CD fungerar bara om din testsvit kan utvecklas tillsammans med din applikation. När din produkt förändras kan det snabbt bli en flaskhals som fördröjer varje lansering att manuellt skapa nya tester och åtgärda trasiga tester.

Checksum är byggt för att automatisera mycket av den processen. 

Den här guiden visar hur du ansluter Checksum till din miljö och ditt kodförråd, genererar och kör Playwright-tester i din CI/CD-pipeline samt aktiverar autonomt underhåll när din applikation utvecklas.

Så stöder Checksum kontinuerlig E2E-testning

Checksum stöder kontinuerlig E2E-testning genom ett kontinuerligt arbetsflöde:

1. Konfigurera: Ansluter ditt kodförråd och din testmiljö.
2. Identifiera: Analyserar din applikation och identifierar de viktigaste användarflödena att testa.
3. Generera: Skapar produktionsklara Playwright-tester och levererar dem som pull requests till ditt kodförråd.
4. Köra: Kör dessa tester lokalt eller i din CI/CD-pipeline, medan automatisk återställning försöker lösa tillfälliga fel under körningen.
5. Reparera: Uppdaterar trasiga Playwright-tester när din applikation förändras och öppnar en pull request med den föreslagna åtgärden.
6. Övervaka: Följer testernas hälsa och meddelar ditt team när problem kräver åtgärd.

Eftersom varje test är standardkod i Playwright behåller du full äganderätt och kan köra testsviten med eller utan Checksum.

Förutsättningar för kontinuerlig E2E-testning i Checksum

Innan du konfigurerar Checksum för kontinuerlig E2E-testning bör du se till att följande är klart.

En staging- eller produktionslik miljö

Checksum testar mot en aktiv applikation, så du behöver en tillgänglig staging- eller produktionslik miljö med en miljö-URL. Om din applikation kräver autentisering konfigurerar du en inloggnings-URL och anger autentiseringsuppgifter för en testanvändare som Checksum kan använda för att logga in och analysera applikationens användarflöden.

Ett anslutet kodförråd och en CI-pipeline

Anslut ditt GitHub- eller GitLab-kodförråd så att Checksum kan analysera din kodbas och skapa pull requests som innehåller genererade eller uppdaterade Playwright-tester. Om dina tester finns i ett separat kodförråd förbättras precisionen i identifieringen av flöden om du ansluter både källkodsförrådet och testkodsförrådet.

Du behöver också en CI-plattform för att köra dina tester. Checksum har inbyggt stöd för GitHub Actions och GitLab CI/CD, medan andra CI-plattformar kan integreras via Checksum CLI eller ett offentligt API.

Ett Checksum-projekt och en API-nyckel

Skapa ett Checksum-projekt i webbappen och generera en API-nyckel för projektet från Projektinställningar. API-nyckeln autentiserar Checksum CLI och gör det möjligt för din CI-pipeline att hämta de miljövariabler som krävs för att köra dina tester.

Om du vill ha en mer detaljerad genomgång av den inledande konfigurationsprocessen kan du också besöka Checksums sida Kom igång.

Så utför du kontinuerlig E2E-testning i Checksum

Stegen nedan förutsätter att du har skapat ett Checksum-projekt och har din API-nyckel till hands.

Steg 1. Anslut din miljö och ditt kodförråd

I webbappens konfigurationsguide anger du din miljö-URL (t.ex. https://staging.myapp.com) och inloggnings-URL samt lägger till autentiseringsuppgifterna för testanvändaren som Checksum ska autentisera med. 

Installera sedan Git-appen för GitHub eller GitLab så att Checksum kan läsa din kod och öppna pull requests. Om dina tester ska finnas tillsammans med källkoden ansluter du samma kodförråd för båda.

Steg 2. Initiera ditt testkodförråd

Skapa (eller utse) ett repo för dina tester och initiera det med CLI:t:

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

npm init -y

npm install @checksum-ai/runtime playwright

npx checksumai init

Detta skapar en checksum/-mapp med konfiguration, en Playwright-konfiguration och ett exempeltest. Kontrollera kopplingen innan du går vidare:

npm install

npx playwright install --with-deps

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

npx checksumai test -g "example"

Exempeltestet bekräftar att inloggningen fungerar i din miljö. Ett godkänt resultat betyder att du är redo att identifiera verkliga flöden.

Steg 3. Låt agenten identifiera kritiska användarflöden

Starta en identifieringssession och låt E2E-agenten analysera din applikation för att identifiera viktiga användarflöden. När identifieringen är klar granskar du de föreslagna flödena och prioriterar de som är mest relevanta för din release innan du genererar tester.

Steg 4. Generera produktionsklara Playwright-tester

Generera Playwright-tester för de flöden du har valt. 

Agenten planerar, implementerar, granskar och verifierar varje test innan den öppnar en pull request som innehåller en lättläst story-fil och Playwright-testet. 

Granska pull requesten som vilken annan kodändring som helst och sammanfoga sedan de tester du är redo att lägga till i din testsvit.

Steg 5. Koppla in tester i din CI/CD-pipeline

För GitHub Actions sparar du din API-nyckel och dina miljövärden som repohemligheter och lägger sedan till ett arbetsflöde som installerar Playwright, laddar ned Checksum-miljöfilen och kör testsviten:

name: Kör Checksum-tester
on:
  workflow_dispatch:        # manuell utlösare för att starta
  # schedule:
  #   - cron: '0 0 * * *'   # varje natt, när det har verifierats
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installera npm-beroenden
        run: npm install
      - name: Installera Playwright med beroenden
        run: npx playwright install --with-deps
      - name: Ladda ned .env från Checksum
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Kö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öljer samma struktur i .gitlab-ci.yml. Börja med en manuell utlösare (workflow_dispatch / when: manual) för att bekräfta att körningen fungerar, och övergå sedan till ett schema för nattliga hälsokontroller eller en sammanfogningsutlösare för att verifiera efter driftsättningar.

Steg 6. Lägg till körningar per PR och aktivera autonom självläkning

Om du vill att Checksum ska köra tester för varje pull request använder du den officiella GitHub-åtgärden i stället för att köra CLI:t på din egen körmiljö. Detta är användbart för att validera ändringarna som introduceras i varje 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

Alternativet grep filtrerar vilka tester som körs efter namn, medan auto-heal: true aktiverar automatisk självläkning när ett test misslyckas. 

Som standard avslutas arbetsflödet när körningen har godkänts och publicerar resultaten som en kommentar i pull requesten. Om du vill att arbetsflödet ska vänta på slutresultatet och lyckas eller misslyckas i enlighet med detta anger du wait: true.

Med automatisk självläkning aktiverad försöker Checksum återställa tester i realtid under testkörningen. Om testet fortfarande misslyckas uppdaterar det Playwright-testet, öppnar en pull request med den föreslagna korrigeringen och publicerar framstegen som en kommentar på den ursprungliga pull requesten. 

Ditt team kan sedan granska och sammanfoga ändringarna precis som alla andra kodbidrag.

Så här ser framgångsrika kontinuerliga E2E-tester ut

När Checksum har integrerats i din CI/CD-pipeline bör du förvänta dig följande:

• Din E2E-testsvit körs automatiskt baserat på den utlösare du har konfigurerat, inklusive pull requests, schemalagda körningar och driftsättningar.
• Nya användarflöden upptäcks och konverteras till Playwright-tester utan att du behöver skriva varje test manuellt.
• Testfel som orsakas av ändringar i applikationen löses genom automatisk återställning eller självläkning innan manuella uppdateringar krävs.
• Ditt team lägger mindre tid på att underhålla Playwright-tester och mer tid på att granska meningsfulla teständringar som levereras via pull requests.

För att mäta hälsan hos din implementering bör du övervaka andelen godkända tester, procentandelen tester som självläks automatiskt, den genomsnittliga tiden för att lösa testfel och andelen falska positiva resultat. 

De här mätvärdena hjälper dig att förstå hur tillförlitligt din E2E-testsvit körs när applikationen utvecklas. Om du vill jämföra dina resultat med produktionsriktvärden innehåller Checksums QA-benchmarkrapport data för dessa mätvärden baserat på över 1 miljon verkliga produktionskörningar.

Vanliga misstag vid kontinuerliga E2E-tester och experttips

Även med rätt konfiguration kan några vanliga misstag påverka testernas kvalitet, körning och underhåll. Här är sådant du bör vara uppmärksam på och hur du undviker det.

Att köra tester mot en instabil miljö

Om dina testresultat är inkonsekventa eller misslyckas innan en meningsfull testkörning har börjat kanske testmiljön inte är redo. Se till att din stagingmiljö eller produktionsliknande miljö är stabil, att autentiseringsuppgifterna för testanvändaren fungerar korrekt och att exempeltestet godkänns innan du genererar ytterligare täckning.

Att generera för många användarflöden

Checksum kan identifiera fler användarflöden än du behöver till en början. Om du genererar tester för varje kandidat ökar körningstiden och granskningsarbetet. Börja med de arbetsflöden som är viktigast för dina releaser och utöka sedan täckningen över tid.

Att sammanfoga genererade tester utan granskning

Genererade och självläkta tester levereras som pull requests så att ditt team kan validera varje ändring innan den blir en del av testsviten. Granska nya tester noggrant under de tidiga adoptionsfaserna och bygg gradvis upp förtroendet för genereringsprocessen.

Att automatisera din pipeline för tidigt

Innan du schemalägger körningar eller utlöser tester för varje pull request bör du bekräfta att din pipeline är stabil vid manuella körningar. När du konsekvent får tillförlitliga resultat kan du automatisera arbetsflödet med större trygghet.

Att blockera varje pull request

Om du aktiverar wait: true väntar arbetsflödet på att testkörningen ska slutföras innan det avslutas. Använd det endast för arbetsflöden som behöver blockera en sammanfogning. För allt annat ger standardkommentaren på pull requesten återkoppling utan att binda upp CI-körmiljöer.

Sammanfattning

Nu har du sett hur Checksum passar in i ett kontinuerligt E2E-testarbetsflöde – från att ansluta din miljö och ditt kodförråd till att generera Playwright-tester, integrera dem i din CI/CD-pipeline och aktivera autonomt underhåll. 

När din applikation utvecklas hjälper Checksum till att hålla din E2E-testsvit tillförlitlig utan att kräva samma nivå av manuellt underhåll.

Om du vill utforska plattformen mer kan du läsa vår djupgående recension av Checksum för att lära dig mer om dess funktioner, eller se hur Checksum fungerar med din egen applikation genom att ansluta direkt till deras team.