CI/CD testų integracija su Azure DevOps: kaip automatizuoti testų vykdymą ir sumažinti klaidų riziką

Automatizuoti testai duoda didžiausią vertę tada, kai jie nėra paleidžiami tik rankiniu būdu, o tampa natūralia kūrimo proceso dalimi. Būtent tam reikalinga CI/CD testų integracija su Azure DevOps.

Kai testai automatiškai paleidžiami po kodo pakeitimo, pull request arba prieš diegimą, komanda greičiau pamato klaidas, saugiau leidžia naujas versijas ir mažiau priklauso nuo paskutinės minutės rankinio testavimo.

Šiame straipsnyje paaiškinsime, kaip integruoti automatizuotus testus į Azure DevOps pipeline, kokius testus verta paleisti pirmiausia, kada testai turi stabdyti diegimą ir kokių klaidų vengti.

Trumpai:

CI/CD testų integracija reiškia, kad testai paleidžiami automatiškai pipeline procese.
Pradėti verta nuo smoke, API ir kritinių vartotojo scenarijų.
Ne visi testai turi stabdyti deployment — svarbu atskirti kritinius ir ilgesnius regresinius testus.
Azure DevOps leidžia publikuoti testų rezultatus, ataskaitas, logus ir artefaktus vienoje vietoje.

Jei dar tik planuojate automatizavimą, pirmiausia verta suprasti kiek kainuoja testų automatizavimas ir kada verta automatizuoti testus.

Kas yra CI/CD testų integracija?

CI/CD testų integracija – tai automatizuotų testų prijungimas prie build, pull request, release arba deployment proceso. Vietoje to, kad testuotojas ar programuotojas testus paleistų rankiniu būdu, pipeline tai padaro automatiškai.

CI reiškia Continuous Integration. Tai procesas, kai kiekvienas kodo pakeitimas automatiškai surenkamas ir patikrinamas.

CD reiškia Continuous Delivery arba Continuous Deployment. Tai procesas, kai po sėkmingų patikrinimų pakeitimus galima saugiau diegti į testavimo, staging arba produkcinę aplinką.

Testų integracija į CI/CD leidžia komandai ne spėlioti, ar sistema vis dar veikia, o turėti aiškų signalą: testai praėjo, testai nepraėjo, arba reikia analizės.

Kodėl testus verta leisti Azure DevOps pipeline?

Azure DevOps pipeline leidžia automatizuoti ne tik build procesą, bet ir testavimą. Tai ypač svarbu komandoms, kurios dažnai keičia kodą, dirba su pull request'ais arba leidžia naujas versijas kas savaitę, kasdien ar net kelis kartus per dieną.

klaidos aptinkamos anksčiau;
sumažėja rankinio regresinio testavimo apimtis;
komanda greičiau gauna grįžtamąjį ryšį;
lengviau nuspręsti, ar pakeitimą galima diegti;
testų rezultatai tampa matomi visai komandai;
release procesas tampa stabilesnis ir labiau prognozuojamas.

Verslui tai reiškia mažesnę riziką, greitesnį funkcijų išleidimą ir mažiau klaidų, kurios pasiekia vartotojus.

Kaip veikia CI/CD testų integracija Azure DevOps aplinkoje?

Tipinis procesas atrodo taip:

programuotojas sukuria pakeitimą ir atidaro pull request;
Azure DevOps automatiškai paleidžia build pipeline;
pipeline įdiegia priklausomybes ir paruošia testavimo aplinką;
paleidžiami automatizuoti testai;
publikuojami testų rezultatai, logai, screenshot'ai arba HTML ataskaitos;
pagal rezultatą sprendžiama, ar pakeitimą galima merge'inti arba diegti toliau.

Tokiu būdu testavimas tampa ne atskiru rankiniu žingsniu, o automatine kokybės kontrole.

Kokius testus verta integruoti pirmiausia?

Viena dažniausių klaidų – bandyti iš karto paleisti visus automatizuotus testus kiekviename pipeline. Tai gali padaryti procesą lėtą, nestabilų ir erzinti komandą. Geriau pradėti nuo mažo, bet vertingo rinkinio.

1. Smoke testai

Smoke testai tikrina, ar pagrindinės sistemos dalys apskritai veikia. Tai gali būti prisijungimas, pagrindinio puslapio atidarymas, svarbiausios formos pateikimas arba pagrindinis vartotojo kelias.

Šie testai turėtų būti trumpi, stabilūs ir paleidžiami dažnai.

2. Kritiniai verslo scenarijai

Pirmiausia verta automatizuoti scenarijus, kurių klaidos tiesiogiai paveiktų vartotojus arba pajamas: registracija, mokėjimas, užsakymas, dokumento sukūrimas, duomenų išsaugojimas ar kita pagrindinė funkcija.

3. API testai

API testai dažnai yra greitesni ir stabilesni nei UI testai, todėl jie labai tinka CI/CD procesui. Jie leidžia greitai patikrinti verslo logiką, duomenų validaciją ir svarbius endpoint'us.

4. Kritiniai UI testai

UI testai yra naudingi tada, kai reikia patikrinti realų vartotojo kelią naršyklėje. Tačiau jų nereikėtų naudoti viskam. Geriausia CI/CD pipeline paleisti tik svarbiausius ir stabiliausius UI testus.

5. Pilna regresija

Pilnas regresinių testų rinkinys dažnai yra per ilgas kiekvienam pull request. Tokius testus galima paleisti pagal grafiką, pavyzdžiui, naktį arba prieš svarbų release.

Kurie testai turi stabdyti pipeline?

Ne visi testai turi vienodą svarbą. Jeigu kiekvienas nepavykęs testas stabdo darbą, komanda greitai praranda pasitikėjimą pipeline. Todėl testus verta suskirstyti pagal riziką.

PR validation: trumpi smoke ir kritiniai testai, kurie turi būti stabilūs.
Main branch pipeline: platesnis testų rinkinys po merge į pagrindinę šaką.
Pre-deployment: testai, kurie turi praeiti prieš diegimą į aplinką.
Nightly regression: ilgesnis regresinių testų rinkinys, paleidžiamas pagal grafiką.

Kritiniai smoke testai dažniausiai turi stabdyti pipeline. Ilgesni arba mažiau stabilūs testai gali būti vykdomi atskirai, kad netrukdytų kasdieniam darbui.

Playwright testų integracija į Azure DevOps

Playwright puikiai tinka modernių web sistemų automatizavimui ir gali būti lengvai integruojamas į Azure DevOps. Žemiau pateiktas supaprastintas pipeline pavyzdys Node.js projektui.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '20.x'
  displayName: 'Install Node.js'

- script: npm ci
  displayName: 'Install dependencies'

- script: npx playwright install --with-deps
  displayName: 'Install Playwright browsers'

- script: npx playwright test
  displayName: 'Run Playwright tests'

- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/test-results/*.xml'
    failTaskOnFailedTests: true
  condition: succeededOrFailed()
  displayName: 'Publish test results'

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: 'playwright-report'
    artifact: 'playwright-report'
  condition: succeededOrFailed()
  displayName: 'Publish Playwright report'

Šis pavyzdys parodo pagrindinę idėją: įdiegti priklausomybes, paruošti Playwright naršykles, paleisti testus ir publikuoti rezultatus. Realiame projekte pipeline gali turėti daugiau žingsnių: aplinkos konfigūraciją, testų duomenis, secret'us, skirtingas aplinkas ar atskirus testų rinkinius.

Svarbu: jeigu norite publikuoti JUnit rezultatus Azure DevOps aplinkoje, Playwright konfigūracijoje turi būti įjungtas JUnit reporteris.

reporter: [
  ['html'],
  ['junit', { outputFile: 'test-results/results.xml' }]
]

Jei dar tik pradedate su Playwright, skaitykite: kaip pradėti su Playwright nuo nulio.

PR, main branch ir nightly testų strategija

Gera CI/CD testavimo strategija dažniausiai nėra vienas pipeline viskam. Skirtingiems tikslams verta turėti skirtingus testų paleidimo lygius.

Pull request testai

Pull request metu verta paleisti trumpą, stabilų testų rinkinį. Tikslas – greitai pasakyti komandai, ar pakeitimas nesugadino svarbiausių sistemos vietų.

Main branch testai

Po merge į pagrindinę šaką galima paleisti platesnį testų rinkinį. Čia jau galima įtraukti daugiau API, integracinių ar UI testų.

Nightly regression

Ilgi regresiniai testai dažnai geriau tinka naktiniam paleidimui. Taip jie netrukdo kasdieniam darbui, bet vis tiek reguliariai tikrina platesnę sistemos dalį.

Pre-release testai

Prieš svarbų release verta paleisti papildomą patikrinimą: kritinius UI scenarijus, API testus, integracinius testus ir testus, kurie tikrina didžiausią verslo riziką.

Kokias ataskaitas ir artefaktus verta publikuoti?

Testų rezultatai turi būti aiškūs ne tik automatizavimo inžinieriui, bet ir visai komandai. Jei testas nepavyko, turi būti lengva suprasti, kas įvyko.

JUnit arba TRX testų rezultatai;
Playwright HTML report;
screenshot'ai po klaidos;
video įrašai, kai reikia analizuoti UI problemą;
trace failai;
logai ir diagnostinė informacija;
pipeline artefaktai, kuriuos galima atsisiųsti po vykdymo.

Kuo greičiau komanda supranta klaidos priežastį, tuo mažiau laiko prarandama analizei.

Kaip tvarkytis su flaky testais?

Flaky testai – tai testai, kurie kartais praeina, kartais nepraeina, nors kodas nepasikeitė. Tokie testai yra viena didžiausių CI/CD testavimo problemų, nes jie mažina pasitikėjimą automatizavimu.

Norint sumažinti flaky testų skaičių, verta:

naudoti stabilius lokatorius;
vengti fiksuotų laukimų, pvz. sleep tipo sprendimų;
tvarkyti testų duomenis prieš kiekvieną testą;
atskirti nepriklausomus testus vieną nuo kito;
naudoti Playwright auto-waiting galimybes;
analizuoti trace, screenshot'us ir video;
nestabilių testų nelaikyti kaip kritinio deployment gate.

Daugiau apie stabilią Playwright struktūrą: Playwright lokatoriai ir Playwright Page Object Model.

Dažniausios CI/CD testavimo klaidos

bandoma paleisti per daug testų kiekviename pull request;
nėra aišku, kurie testai stabdo pipeline, o kurie tik informuoja;
testų rezultatai nepublikuojami arba sunkiai randami;
flaky testai maišomi su kritiniais smoke testais;
testų duomenys nėra stabilūs;
testavimo aplinka nėra paruošta automatiniam vykdymui;
komanda nereaguoja į nepavykusius testus;
nėra aiškaus atsakingo žmogaus už testų priežiūrą.

Dažniausiai CI/CD testavimo problema nėra pats įrankis. Problema būna strategijoje: ką paleisti, kada paleisti, kaip reaguoti į rezultatą ir kaip prižiūrėti testų rinkinį.

Kada verta pradėti CI/CD testų integraciją?

CI/CD integraciją verta pradėti tada, kai turite bent kelis stabilius automatizuotus testus ir reguliariai leidžiate naujas versijas. Nereikia laukti, kol turėsite šimtus testų.

Geras pirmas etapas gali būti:

5–10 smoke testų;
keli svarbiausi API testai;
Playwright HTML report publikavimas;
testų paleidimas po merge į pagrindinę šaką;
aiški taisyklė, ką daryti, kai testai nepraeina.

Jei dar neturite aiškios krypties, naudinga pradėti nuo bendros testavimo strategijos startupams arba įvertinti testų automatizavimo galimybes.

Kaip suprasti, ar CI/CD testai duoda vertę?

Integruoti testus į pipeline neužtenka. Reikia stebėti, ar jie realiai padeda komandai. Geras testų rinkinys turi taupyti laiką, mažinti riziką ir suteikti pasitikėjimo prieš release.

kiek klaidų testai randa prieš release;
kiek laiko trunka pipeline;
kiek testų yra stabilūs;
kiek laiko užima nepavykusio testo analizė;
ar sumažėjo rankinio regresinio testavimo poreikis;
ar komanda pasitiki testų rezultatais;
ar sumažėjo kritinių klaidų produkcijoje.

Susijusios temos

DUK apie CI/CD testų integraciją su Azure DevOps

Kas yra CI/CD testavimas?

CI/CD testavimas – tai automatizuotų testų paleidimas build, pull request arba deployment pipeline metu. Jo tikslas – kuo anksčiau aptikti klaidas ir užtikrinti, kad pakeitimai nesugadino svarbiausių sistemos dalių.

Kokius testus verta paleisti Azure DevOps pipeline?

Pirmiausia verta paleisti smoke testus, kritinius API testus ir svarbiausius vartotojo scenarijus. Ilgesnius regresinius testus dažnai geriau paleisti atskirai arba pagal grafiką.

Ar visi testai turi stabdyti deployment?

Ne. Deployment dažniausiai turi stabdyti tik kritiniai smoke, API arba pagrindiniai verslo scenarijai. Ilgi, eksperimentiniai arba nestabilūs testai neturėtų būti pagrindinis deployment gate.

Ar Playwright tinka Azure DevOps pipeline?

Taip. Playwright gerai tinka Azure DevOps pipeline, nes gali veikti headless režimu, generuoti HTML, JUnit, screenshot, video ir trace ataskaitas bei būti paleidžiamas automatiškai CI/CD procese.

Kaip dažnai reikia leisti automatizuotus testus?

Trumpus ir kritinius testus verta leisti kiekviename pull request arba po merge į pagrindinę šaką. Ilgesnius regresinius testus galima paleisti naktį, prieš release arba pagal komandos pasirinktą grafiką.

Reikia pagalbos su Azure DevOps testų integracija?

Padedame komandoms įdiegti testų automatizavimą su Azure DevOps: nuo strategijos ir testų atrankos iki veikiančio pipeline, ataskaitų, Playwright integracijos ir stabilaus testų vykdymo.

Jei jau turite automatizuotus testus, bet jie nėra patikimai paleidžiami pipeline, verta sutvarkyti strategiją, testų struktūrą ir ataskaitas.

Susisiekite →