Kuinka Checksumia käytetään jatkuvaan päästä päähän -testaukseen CI/CD-putkessa

E2E-testien suorittaminen CI/CD-putkessa toimii vain, jos testisarjasi voi kehittyä sovelluksesi mukana. Kun tuotteesi muuttuu, uusien testien manuaalinen luominen ja rikkoutuneiden testien korjaaminen voivat nopeasti muodostua pullonkaulaksi, joka hidastaa jokaista julkaisua.

Checksum on suunniteltu automatisoimaan suuren osan tästä prosessista. 

Tässä oppaassa näytetään, kuinka Checksum yhdistetään ympäristöösi ja repositorioosi, kuinka Playwright-testit luodaan ja suoritetaan CI/CD-putkessasi sekä kuinka automaattinen ylläpito otetaan käyttöön sovelluksesi kehittyessä.

Kuinka Checksum tukee jatkuvaa E2E-testausta

Checksum tukee jatkuvaa E2E-testausta jatkuvan työnkulun avulla:

1. Käyttöönotto: Yhdistää repositoriosi ja testausympäristösi.
2. Tunnistaminen: Analysoi sovelluksesi ja tunnistaa tärkeimmät testattavat käyttäjäpolut.
3. Luominen: Luo tuotantovalmiit Playwright-testit ja toimittaa ne pull requesteina repositorioosi.
4. Suorittaminen: Suorittaa testit paikallisesti tai CI/CD-putkessasi, kun taas automaattinen palautuminen yrittää ratkaista väliaikaiset virheet suorituksen aikana.
5. Korjaaminen: Päivittää rikkoutuneet Playwright-testit, kun sovelluksesi muuttuu, ja avaa pull requestin ehdotetulla korjauksella.
6. Valvonta: Seuraa testien kuntoa ja ilmoittaa tiimillesi huomiota vaativista ongelmista.

Koska jokainen testi on tavallista Playwright-koodia, omistat testit täysin ja voit suorittaa testisarjan Checksumilla tai ilman sitä.

Checksumissa jatkuvan E2E-testauksen edellytykset

Ennen kuin määrität Checksumia jatkuvaa E2E-testausta varten, varmista, että seuraavat asiat ovat valmiina.

Esituotanto- tai tuotantoa vastaava ympäristö

Checksum testaa toimivaa sovellusta, joten tarvitset käytettävissä olevan esituotanto- tai tuotantoa vastaavan ympäristön, jolla on ympäristön URL-osoite. Jos sovelluksesi vaatii todennuksen, määritä kirjautumisen URL-osoite ja anna testikäyttäjän tunnistetiedot, joita Checksum voi käyttää kirjautumiseen ja sovelluksesi käyttäjäpolkujen analysointiin.

Yhdistetty repositorio ja CI-putki

Yhdistä GitHub- tai GitLab-repositoriosi, jotta Checksum voi analysoida koodikantasi ja luoda pull requesteja, jotka sisältävät luotuja tai päivitettyjä Playwright-testejä. Jos testisi sijaitsevat erillisessä repositoriossa, sekä lähderepositorion että testirepositorion yhdistäminen parantaa käyttäjäpolkujen tunnistamisen tarkkuutta.

Tarvitset myös CI-alustan testiesi suorittamiseen. Checksum tarjoaa sisäänrakennetun tuen GitHub Actionsille ja GitLab CI/CD:lle, kun taas muut CI-alustat voidaan integroida Checksum CLI:n tai julkisen API:n kautta.

Checksum-projekti ja API-avain

Luo Checksum-projekti verkkosovelluksessa ja luo projektin API-avain kohdasta projektin asetukset. API-avain todentaa Checksum CLI:n ja antaa CI-putkellesi mahdollisuuden ladata testien suorittamiseen tarvittavat ympäristömuuttujat.

Jos haluat tarkemman katsauksen alkuasetusten tekemiseen, voit tutustua myös {{deeplink:154034:[Checksumin aloitussivuun.]:getting_started}}

Kuinka jatkuva E2E-testaus suoritetaan Checksumissa

Alla olevissa vaiheissa oletetaan, että olet luonut Checksum-projektin ja että API-avaimesi on käytettävissä.

Vaihe 1. Yhdistä ympäristösi ja repositoriosi

Määritä verkkosovelluksen ohjatun käyttöönoton toiminnossa ympäristön URL-osoite (esim. https://staging.myapp.com) ja kirjautumisen URL-osoite sekä lisää testikäyttäjän tunnistetiedot, joilla Checksum todentaa käyttäjän. 

Asenna sen jälkeen Git-sovellus GitHubia tai GitLabia varten, jotta Checksum voi lukea koodiasi ja avata pull requesteja. Jos testisi sijaitsevat lähdekoodin yhteydessä, yhdistä sama repositorio molempia varten.

Vaihe 2. Alusta testirepositoriosi

Luo (tai määritä) testeillesi repositorio ja alusta se CLI:llä:

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

npm init -y

npm install @checksum-ai/runtime playwright

npx checksumai init

Tämä luo checksum/-kansion, joka sisältää määritykset, Playwright-määrityksen ja esimerkkitestin. Varmista asetusten toimivuus ennen etenemistä:

npm install

npx playwright install --with-deps

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

npx checksumai test -g "example"

Esimerkkitesti vahvistaa, että kirjautuminen toimii ympäristössäsi. Vihreä tulos tarkoittaa, että olet valmis tunnistamaan todellisia työnkulkuja.

Vaihe 3. Anna agentin tunnistaa kriittiset käyttäjätyönkulut

Käynnistä tunnistussessio ja anna E2E-agentin analysoida sovelluksesi tärkeiden käyttäjätyönkulkujen tunnistamiseksi. Kun tunnistus on valmis, tarkista ehdotetut työnkulut ja priorisoi julkaisusi kannalta olennaisimmat ennen testien luomista.

Vaihe 4. Luo tuotantovalmiit Playwright-testit

Luo Playwright-testit valitsemillesi työnkuluille. 

Agentti suunnittelee, toteuttaa, tarkistaa ja varmistaa jokaisen testin ennen pull requestin avaamista. Pull request sisältää ihmisen luettavissa olevan tarinatiedoston ja Playwright-testin. 

Tarkista pull request kuten mikä tahansa muu koodimuutos ja yhdistä testit, jotka olet valmis lisäämään testikokoelmaasi.

Vaihe 5. Liitä testit CI/CD-putkeesi

GitHub Actionsia varten tallenna API-avaimesi ja ympäristöarvosi repositorion salaisuuksina ja lisää sitten työnkulku, joka asentaa Playwrightin, lataa Checksum-ympäristötiedoston ja suorittaa testikokoelman:

name: Suorita Checksum-testit
on:
  workflow_dispatch:        # manuaalinen käynnistys
  # schedule:
  #   - cron: '0 0 * * *'   # öisin, kun toimivuus on varmistettu
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Asenna npm-riippuvuudet
        run: npm install
      - name: Asenna Playwright riippuvuuksineen
        run: npx playwright install --with-deps
      - name: Lataa .env Checksumista
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Suorita Checksum-testit
        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 noudattaa samaa rakennetta tiedostossa .gitlab-ci.yml. Aloita manuaalisella käynnistyksellä (workflow_dispatch / when: manual) varmistaaksesi, että suoritus toimii oikein, ja siirry sitten ajastukseen öisiä toimintakuntotarkistuksia varten tai yhdistämisen käynnistämään työnkulkuun, joka tarkistaa tilanteen käyttöönottojen jälkeen.

Vaihe 6. Lisää suoritus jokaiselle pull requestille ja ota käyttöön itsenäinen korjaus

Jos haluat Checksum-järjestelmän suorittavan testit jokaiselle pull requestille, käytä virallista GitHub Actionia sen sijaan, että suorittaisit CLI:n omalla suorittimellasi. Tämä on hyödyllistä jokaisessa pull requestissa tehtyjen muutosten tarkistamiseen.

name: Checksum-testit
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-asetus suodattaa nimen perusteella suoritettavat testit, kun taas auto-heal: true ottaa käyttöön automaattisen korjauksen testin epäonnistuessa. 

Oletusarvoisesti työnkulku päättyy, kun suoritus on hyväksytty, ja julkaisee tulokset kommenttina pull requestiin. Jos haluat työnkulun odottavan lopullista tulosta ja ilmoittavan sen perusteella onnistumisesta tai epäonnistumisesta, määritä wait: true.

Kun automaattinen korjaus on käytössä, Checksum yrittää palauttaa tilanteen reaaliaikaisesti testiajon aikana. Jos testi epäonnistuu edelleen, se päivittää Playwright-testin, avaa ehdotetun korjauksen sisältävän yhdistämispyynnön ja julkaisee edistymisestä kommentin alkuperäiseen yhdistämispyyntöön. 

Tiimisi voi sen jälkeen tarkistaa ja yhdistää muutokset kuten minkä tahansa muun koodimuutoksen.

Miltä onnistunut jatkuva E2E-testaus näyttää

Kun Checksum on integroitu CI/CD-putkeesi, sinun pitäisi odottaa seuraavaa:

• E2E-testisarjasi suoritetaan automaattisesti määrittämäsi käynnistimen perusteella. Käynnistimiä voivat olla esimerkiksi yhdistämispyynnöt, ajoitetut ajot ja käyttöönotot.
• Uudet käyttäjäpolut tunnistetaan ja muunnetaan Playwright-testeiksi ilman, että jokaista testiä tarvitsee kirjoittaa manuaalisesti.
• Sovelluksen muutosten aiheuttamat testivirheet ratkaistaan automaattisen palautuksen tai automaattisen korjauksen avulla ennen manuaalisten päivitysten tarvetta.
• Tiimisi käyttää vähemmän aikaa Playwright-testien ylläpitoon ja enemmän aikaa yhdistämispyyntöjen kautta toimitettujen merkityksellisten testimuutosten tarkistamiseen.

Toteutuksesi toimivuuden mittaamiseksi seuraa testien läpäisyastetta, automaattisesti korjattujen testien prosenttiosuutta, testivirheiden ratkaisemiseen kuluvaa keskimääräistä aikaa sekä väärien positiivisten tulosten määrää. 

Näiden mittareiden avulla ymmärrät, kuinka luotettavasti E2E-testisarjasi toimii sovelluksesi kehittyessä. Voit verrata tuloksiasi tuotantoympäristöjen vertailuarvoihin tutustumalla {{deeplink:154034:[Checksumin laadunvarmistuksen vertailuraporttiin]:qa_benchmark}}, joka sisältää näitä mittareita koskevia tietoja yli miljoonasta todellisesta tuotantoajosta.

Yleiset jatkuvan E2E-testauksen virheet ja asiantuntijavinkit

Oikeista asetuksista huolimatta muutamat yleiset virheet voivat vaikuttaa testien laatuun, suorittamiseen ja ylläpitoon. Seuraavassa kerrotaan, mitä kannattaa tarkkailla ja miten ongelmilta voi välttyä.

Testien suorittaminen epävakaassa ympäristössä

Jos testituloksesi ovat epäjohdonmukaisia tai testit epäonnistuvat ennen merkityksellisen testisuorituksen alkamista, testiympäristösi ei ehkä ole valmis. Varmista, että testi- tai tuotannon kaltainen ympäristösi on vakaa, testikäyttäjän tunnistetiedot toimivat oikein ja esimerkkitesti läpäistään ennen lisäkattavuuden luomista.

Liian monien käyttäjäpolkujen luominen

Checksum saattaa tunnistaa aluksi enemmän käyttäjäpolkuja kuin tarvitset. Testien luominen jokaiselle ehdokkaalle pidentää suoritusaikaa ja lisää tarkistustyötä. Aloita julkaisuillesi tärkeimmistä työnkuluista ja laajenna kattavuutta ajan mittaan.

Luotujen testien yhdistäminen ilman tarkistusta

Luodut ja automaattisesti korjatut testit toimitetaan yhdistämispyyntöinä, jotta tiimisi voi tarkistaa jokaisen muutoksen ennen kuin siitä tulee osa testisarjaa. Tarkista uudet testit huolellisesti käyttöönoton alkuvaiheissa ja rakenna luottamusta luontiprosessiin ajan mittaan.

Putken automatisointi liian aikaisin

Ennen kuin ajoitat ajot tai käynnistät testit jokaiselle yhdistämispyynnölle, varmista manuaalisilla suorituksilla, että putkesi on vakaa. Kun saat jatkuvasti luotettavia tuloksia, voit automatisoida työnkulun varmemmin.

Jokaisen yhdistämispyynnön estäminen

wait: true -asetuksen käyttöönotto saa työnkulun odottamaan testiajon valmistumista ennen suorittamisen loppuun saattamista. Käytä sitä vain työnkuluissa, joiden on estettävä yhdistäminen. Muissa tapauksissa oletusarvoinen yhdistämispyynnön kommentti antaa palautetta sitomatta CI-ajoresursseja.

Yhteenveto

Nyt olet nähnyt, miten Checksum sopii jatkuvaan E2E-testaustyönkulkuun: ympäristön ja repositorion yhdistämisestä Playwright-testien luomiseen, niiden integroimiseen CI/CD-putkeesi ja itsenäisen ylläpidon käyttöönottoon. 

Sovelluksesi kehittyessä Checksum auttaa pitämään E2E-testisarjasi luotettavana lisäämättä samanlaista manuaalisen ylläpidon määrää.

Jos haluat tutustua alustaan tarkemmin, voit lukea perusteellisen Checksum-arvostelumme saadaksesi lisätietoja sen ominaisuuksista tai nähdä, miten Checksum toimii omassa sovelluksessasi {{deeplink:154034:[ottamalla suoraan yhteyttä heidän tiimiinsä.]:end_to_end}}