openQA za razvijalce in vzdrževalce
KDE Linux uporablja openQA za samodejno testiranje vsake sistemske slike, preden se objavi. openQA zažene vsako sliko v virtualnem stroju in preveri, ali jo je mogoče namestiti, nadgraditi in uspešno uporabiti.
openQA ima nekaj specifične terminologije: job - opravilo je ena izvedba testnega nabora na sliki, medtem ko je worker - delavec stroj ali vsebnik, ki izvaja opravilo. Dokumentacija openQA pojasnjuje te in druge koncepte, vključno s testnimi moduli, skupinami opravil, sredstvi in spletnim uporabniškim vmesnikom.
Kako delujejo testi
Testni delavec deluje vzporedno s cevovodom CI, zato lahko uporablja slike in virtualne diske, ki jih ustvari gradnja, ne da bi te velike datoteke naložil drugam. Testi se dostavijo virtualnemu stroju prek sistemske razširitve in z njim komunicirajo prek SSH.
Namizni testi uporabljajo API za dostopnost prek selenium-webdriver-at-spi, kar jim omogoča interakcijo z aplikacijami in preverjanje njihovega stanja, ne da bi se zanašali izključno na ujemanje posnetkov zaslona. Paket preverja tudi okvarjene sistemske storitve, sesute procese namizja, težave z omrežjem in regresije v ukazih KDE Linux.
Cevovod CI in potek dela vzdrževalca
Na zaščiteni privzeti veji navzgor repozitorija KDE Linux deluje cevovod takole:
- Opravilo imaging - slikanje gradi, podpisuje in postavlja sliko in njen kanal sysupdate na
storage.kde.org. - Opravilo trigger-openqa zažene cevovod v os-autoinst-distri-kdelinux in mu posreduje URL slike v fazi razvoja in URL kanala sysupdate.
- Delovni tok (downstream pipeline) izvaja postopka
installinupgrade, opredeljena v datotekitests/tests.toml, in sicer za namestitve brez šifriranja ter s šifriranjem. - Opravilo publish - objavi zgoraj se zažene šele po uspešnem zaključku cevovoda openQA. Predstavlja že pripravljeno sliko za javno uporabo.
To naredi napako openQA vrata za objavo slike. Začnite z odpiranjem cevovoda za nadaljnji razvoj iz opravila trigger-openqa, nato pa odprite neuspešno opravilo openQA iz njegovega dnevnika CI. Stran opravila prikazuje testne module po vrstnem redu in vam omogoča, da ugotovite, ali je napaka v namestitvi, testih varnosti nameščenega sistema ali poti nadgradnje.
Prenesite pripravljeno sliko sistema
Povezava, navedena za sporočilom v dnevniku »In case of failure, inspect and download the image and sysupdate tree at…«, odpre brskalnik za dostop do datotek graditve, ki se preizkuša. Tam lahko prenesete datoteko .iso in jo ročno zaženete ali pa jo posredujete lokalnemu sistemu openQA. Drevo sysupdate vsebuje pripravljene artefakte posodobitve, ki se uporabljajo pri preizkusu nadgradnje.
Raziščite neuspešno opravilo
Odprite opravilo v spletnem uporabniškem vmesniku openQA in najprej izberite neuspešen modul. Povezava do spletnega uporabniškega vmesnika se bo prikazala po sporočilu dnevnika “autoinst-log.txt za dnevnik delavca in testnega mehanizma openQA. To je primarni dnevnik za samo opravilo.
Za teste, ki izvajajo ukaze v testiranem sistemu, jih KDE Linux zažene v prehodnih storitvah systemd in zabeleži dnevnik storitev kot diagnostični izhod v rezultatu testa. Za izhod ukaza in dnevnik preverite autoinst-log.txt. Za dnevnike, ki jih je zajelo orodje collect-logs, lahko prenesete tudi datoteko *kde-linux-collected-logs.tar.zst.
Izvajanje testov lokalno
Z openQA lahko preizkusite lokalno zgrajeno sliko sistema, preden oddate spremembo. To je potrebno pri delu iz razvejitve zunaj kde-linux/kde-linux - njen cevovod CI zgradi testno sliko sistema, vendar ne sproži cevovoda openQA. Uporabno je tudi pri razvoju testov za lastne spremembe.
Repozitorij za testiranje KDE Linux openQA vključuje lokalni sklad, ki vsebuje tako spletni vmesnik openQA kot tudi delavca. Za delovanje potrebuje Python 3.14, Podman in podman-compose, ki so vključeni v KDE Linux.
Klonirajte testno skladišče in nato v njegov korenski imenik postavite sliko .iso za KDE Linux, ki jo želite preizkusiti. Če slike ni, bo izvajalec preizkusa prenesel najnovejšo javno dostopno sliko.
Zaženi lokalni sklad iz korenske mape repozitorija:
./qa-mock up
Ko je vse pripravljeno, odprite http://localhost:1080 za dostop do spletnega vmesnika openQA. Opravila se ne oddajo samodejno, zato odprite shell v vsebniku in zaženite postopek install. V tem vsebniku izvedite ukaze flow, job in build-sysext.
./qa-mock enter ./qa flow install
Če želite namesto tega izvesti postopek nadgradnje:
./qa flow upgrade
Za šifrirano namestitev podajte FDE_INSTALL=1 kot nastavitev za openQA. Pripona različice v spletnem vmesniku omogoča razlikovanje med opravili s šifriranjem:
./qa flow install --var FDE_INSTALL=1 --flavor-suffix=-encrypted ./qa flow upgrade --var FDE_INSTALL=1 --flavor-suffix=-encrypted
--var NAME=VALUE se lahko ponovi, vendar mora biti vsaka spremenljivka deklarirana na seznamu variables izbranega poteka v datoteki tests/tests.toml.
Nabor testov sanity-test uporablja navidezni disk, ki ga ustvari install-system. Če se želite osredotočiti na določene teste, uredite seznam tests v datoteki tests/tests.toml ali pa tam definirajte nov nabor testov in delovni tok. Posamezen nabor testov lahko zaženete tudi z ukazom ./qa job --name <suite>, pri čemer morate upoštevati odvisnosti od diska. Ukazi flow, job in build-sysext podpirajo parameter --manifest-path <pot>, ki omogoča uporabo druge datoteke manifesta namesto tests/tests.toml. Poti do testov v manifestu so podane relativno glede na mapo, v kateri se nahaja ta manifest. Za informacije o obveznih parametrih zaženite ./qa job --help.
Na primer, sestavite sistemsko razširitev in zaženite opravilo install-system z datoteko .iso v imeniku repozitorija. ID gradnje in varianto zamenjajte s tistima, ki ustrezata vaši sliki:
./qa build-sysext
./qa job \
--live ./kde-linux_<build-id>.iso \
--hdd kde-linux_<build-id>.qcow2 \
--sysext ./openqa-sysext.img \
--build <build-id> \
--variant <variant> \
--name install-system \
--flavor live
Ko končate, zapustite shell vsebnika, nato ustavite sklad in z gostitelja odstranite njegove lokalne nosilce.
./qa-mock down -v
./qa-mock posreduje argumente orodju podman-compose. Za zagon sklopa v ozadju na primer uporabite ./qa-mock up -d.
Preizkusi nadgradnje med lokalnimi gradnjami
Osnovno datoteko ISO postavite v korenski imenik testnega repozitorija. Ob zagonu sklada z gostiteljskega sistema nastavite spremenljivko KDE_LINUX_OUTPUT na imenik mkosi.output, ki vsebuje gradnjo, na katero želite nadgraditi:
KDE_LINUX_OUTPUT=~/Repositories/kde-linux/mkosi.output ./qa-mock up
Vstopite v vsebnik in zaženite postopek nadgradnje, pri čemer <build-id> nadomestite z ID-jem gradnje vaše osnovne slike ISO:
./qa-mock enter
./qa flow upgrade \
--upgrade-from /casedir/kde-linux_<build-id>.iso \
--upgrade-to /kde-linux-output
Obe možnosti je treba podati hkrati. Repozitorij je priklopljen na /casedir, izbrani imenik mkosi.output pa je priklopljen z dovoljenjem samo za branje na /kde-linux-output. Najnovejša gradnja v tem imeniku se navidezni stroju posreduje kot začasen vir za sysupdate in mora biti novejša od osnovne slike ISO. Za preizkus šifrirane namestitve dodajte --var FDE_INSTALL=1 --flavor-suffix=-encrypted.
Definirajte nize testov in delovne tokove
Datoteka tests/tests.toml določa distribucijo (name in distri), nize testov (suites) in tokove (flows). Niz testov je urejen seznam testov, ki se izvedejo v okviru enega opravila openQA. Njegov parameter action določa, kako opravilo uporablja navidezni disk:
installzažene živo sliko in ustvari nameščeni disk.- Ukaz
upgradezažene sistem z nameščenega diska in nastaviDO_UPGRADEza teste, ki izvajajo nadgradnjo. testzažene sistem z nameščenega diska za namene preverjanja.
Delovni tok izvaja sklope v določenem vrstnem redu in med opravili prenaša nameščeni disk. KDE Linux opredeljuje naslednje tokove:
[flows.install] suites = ["install-system", "sanity-test"] variables = ["FDE_INSTALL"] [flows.upgrade] suites = ["install-system", "upgrade-system", "sanity-test"] variables = ["FDE_INSTALL"]
Tok install namesti in preveri gradnjo, ki je predmet testiranja. Tok upgrade najprej namesti starejšo sliko, jo nadgradi na gradnjo, ki se testira, nato pa izvede teste osnovnega delovanja (sanity tests). Pri stopenjski gradnji CI (staged CI build) je izhodišče najnovejša objavljena slika. Če nista podana parametra --upgrade-from in --upgrade-to, lokalna nadgradnja privzeto cilja na najnovejšo javno gradnjo, pri čemer uporabi starejšo lokalno datoteko ISO (če je na voljo) ali prenese prejšnjo sliko.
Pred vsakim opravilom delavec ustvari začasni testni imenik (CASEDIR) z razporedom main.pm za izbrani nabor testov. Testi se izvajajo v vrstnem redu, določenem v manifestu, vključno s ponavljajočimi se vnosi. Za spremembo razporeda uredite manifest.
Napišite test
Definicije testov in koda se nahajajo v os-autoinst-distri-kdelinux. Skripte za teste dodajte v mapo tests/ poleg sorodnih testov in jih registrirajte v polju tests ustreznega nabora testov v datoteki tests/tests.toml. Na primer:
[suites.example]
action = "test"
tests = [
{ path = "common/bootup.py", type = "openqa" },
{ path = "common/basic_test.py", type = "python" },
{ path = "kdelinux/app/firefox.py", type = "selenium", user = "installed", timeout = 180 },
]
Testi openqa se izvajajo na delavcu in neposredno uporabljajo vmesnike API sistema openQA. Testi python in selenium se izvajajo na sistemu, ki je predmet testiranja; sistemska razširitev samodejno zapakira njihove skripte, delavec pa ustvari ovojne elemente (wrapperje) testa openQA, ki te skripte sprožijo.
Izberite vrsto testa glede na to, kaj preverjate:
- Za orodja ukazne vrstice, storitve, stanje datotečnega sistema ali drugo negrafično vedenje uporabite običajni Pythonov
unittest. - Uporabite Selenium prek
selenium-webdriver-at-spi, kadar vedenje zahteva interakcijo z grafično aplikacijo.
Običajni testi v Pythonu
Ustvarite unittest v mapi tests/, na primer tests/kdelinux/system/example.py. Test mora vključevati preverjanja za sistem, ki se testira, rezultate pa zapisati v datoteko JUnit XML; ta bo samodejno zbrana kot sredstvo za openQA in poročilo za GitLab CI.
import unittest
from lib.sut import openqa_junit_xml
class ExampleTests(unittest.TestCase):
def test_expected_behaviour(self):
self.assertTrue(True)
if __name__ == "__main__":
openqa_junit_xml.run(ExampleTests, "example")
Dodajte vnos v polje tests ustreznega sklopa:
{ path = "kdelinux/system/example.py", type = "python" },
Ustvarjeni ovoj zbira rezultate JUnit in izpis ukazov, tako da so napake vidne v opravilu openQA in artefaktih CI.
Grafični testi z orodjem Selenium
Grafični testi so prav tako razredi Python unittest, vendar uporabljajo gonilnik Appium/Selenium za iskanje in interakcijo z dostopnimi elementi uporabniškega vmesnika. Izvajalec Selenium omogoča infrastrukturo dostopnosti in zažene gonilnik namesto vas.
Na primer, grafični test ustvari gonilnik za svojo aplikacijo, komunicira z dostopnimi elementi in nato zapre gonilnik:
import unittest
from appium import webdriver
from appium.options.common.base import AppiumOptions
from appium.webdriver.common.appiumby import AppiumBy
from lib.sut import openqa_junit_xml
class ExampleTests(unittest.TestCase):
@classmethod
def setUpClass(cls):
options = AppiumOptions()
options.set_capability("app", "org.kde.example.desktop")
cls.driver = webdriver.Remote("http://127.0.0.1:4723", options=options)
@classmethod
def tearDownClass(cls):
cls.driver.quit()
def test_expected_behaviour(self):
self.driver.find_element(AppiumBy.ACCESSIBILITY_ID, "example-control").click()
if __name__ == "__main__":
openqa_junit_xml.run(ExampleTests, "example")
Skript shranite na primer kot tests/kdelinux/app/example.py in ga dodajte v ustrezen nabor testov z nastavitvijo type = "selenium". Izberite nameščenega testnega uporabnika za namizne aplikacije:
{ path = "kdelinux/app/example.py", type = "selenium", user = "installed", timeout = 180 },
Zaženite tok lokalno, ki vsebuje vašo zbirko testov med razvojem.
Možnosti testiranja in ovojnice po meri
Pri ustvarjenih ovojih SUT lahko vnosi v manifestu določijo uporabnika (user: root, live, installed ali plasma_setup), časovno omejitev v sekundah (timeout; privzeto 90), artefakte (artifacts) kot seznam poti za zbiranje ter oznake openQA fatal = true ali always_run = true. Z nastavitvijo enabled = false test ohranite deklariran, vendar ga izključite iz razporeda izvajanja.
Če test za izvedbo potrebuje določeno obliko prilagojene orkestracije, poleg skripta SUT postavite ovojni skript in nanj usmerite z uporabo parametra override:
{ path = "kdelinux/system/collect_logs.py", type = "selenium", override = "kdelinux/system/collect_logs.openqa.py" },
Ta namenski ovojni skript upravlja z lastnimi zastavicami, uporabnikom, časovno omejitvijo in zbiranjem artefaktov ter mora relativno pot do skripta SUT posredovati funkciji CliTest.run_python() ali CliTest.run_selenium(). Za primer si oglejte obstoječi skript collect_logs.openqa.py.
Za več informacij o pisanju testov za Selenium glejte Appium avtomatizacijsko testiranje in GUI Testing with selenium-webdriver-at-spi.
Preučite več
Za podrobnejšo razlago poteka testiranja in njegove implementacije glejte openQA Testiranje v KDE Linuxu. Testna infrastruktura je razvita v repozitoriju os-autoinst-distri-kdelinux.
Članek je prispeval Thomas Duckworth z dovoljenjem CC-BY-4.0.