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.
Cevovod nižje izvaja običajni tok namestitve in preverjanja zdravja ter tok nadgradnje.
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, ki se nahaja za sporočilom dnevnika »V primeru napake lahko pregledate in prenesete sliko .iso in drevo sysupdate na…«, odpre brskalnik za shranjevanje za preizkušeno gradnjo. Prenesite datoteko .iso tam, da jo zaženete ročno, ali pa jo posredujte lokalnemu skladu openQA. Drevo sysupdate vsebuje artefakte postopnih posodobitev, ki jih uporablja test 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 “ test job is now running.”. Podrobnosti vključujejo rezultat modula, posnetke zaslona ali videoposnetke, kjer je to primerno, in diagnostični izhod. Na zavihku Logs & Assets prenesite ali si oglejte datoteko 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 testov openQA za KDE Linux vključuje lokalni sklad, ki vsebuje tako spletni uporabniški vmesnik openQA kot tudi delavca. Zahteva Podman in podman-compose, ki sta vključena 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ženite lokalni sklad.

./mock.sh up

Ko je pripravljeno, odprite http://localhost:1080, da si ogledate spletni uporabniški vmesnik openQA. Naloge se ne oddajo samodejno, zato odprite shell v vsebniku in oddajte običajni potek namestitve in preizkusa varnosti.

podman exec -it openqa-single-instance bash
./qa flow

Če želite namesto tega zagnati potek nadgradnje, dodajte --upgrade:

./qa flow --upgrade

Za zagon namestitvenega preizkusa šifriranja diska dodajte --encrypt:

./qa flow --encrypt

Lahko kombinirate tudi možnosti --upgrade in --encrypt:

./qa flow --upgrade --encrypt

Opravilo sanity-test mora najprej zagnati opravilo install-system, ker uporablja virtualni disk, ki ga je ustvarila namestitev. Če se želite osredotočiti na določen test, prilagodite predložena opravila v lib/worker/job_flow.py ali zaženite posamezno opravilo z ./qa job, pri čemer upoštevajte to odvisnost. Za ogled potrebnih možnosti zaženite ./qa job --help.

Na primer, če želite zagnati opravilo install-system, kjer imate datoteko .iso preneseno v imenik repozitorija:

./qa job \
    --live ./kde-linux_<build-id>.iso \
    --hdd kde-linux_<build-id>.qcow2 \
    --sysext ./openqa-sysext.img \
    --build <build-id> \
    --name install-system \
    --flavor live

Ko končate, ustavite sklad in odstranite njegove lokalne nosilce.

./mock.sh down -v

Napišite test

Definicije testov in testna koda so shranjene v datoteki os-autoinst-distri-kdelinux. Test dodajte ustreznemu toku v datoteki main.pm – toku namestitve v živo, toku preverjanja nameščenega sistema ali toku nadgradnje. Testi so običajno sestavljeni iz majhnega ovoja openQA v datoteki tests/ in testa Python, ki se izvaja na testiranem sistemu iz datoteke extensions/openqa/usr/lib/kde-linux-openqa/tests/.

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

V prej omenjenem imeniku za testiranje razširitve sistema ustvarite datoteko unittest. Ta naj bi podala trditve o testiranem sistemu in zapisal rezultate v datoteko JUnit XML, ki bo samodejno zbrana kot sredstvo openQA in poročilo 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")

V mapi tests/ ustvarite ustrezen ovoj, ki bo openQA prevzel zahtevo za izvedbo testa na gostitelju.

from testapi import *
from lib.test import cli_test

def run(self):
    cli_test.CliTest("example").run_python()

Nazadnje registrirajte ovojnik v ustreznem toku v main.pm. Ovojnik zbira rezultat JUnit in izhod ukaza, tako da se napake pojavijo 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.test 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")

Zaženite ujemajoči ovoj z run_selenium() namesto run_python(). Prenesite nameščenega testnega uporabnika za namizne aplikacije:

from testapi import *
from lib.test import cli_test
from lib.common import user_manager

def run(self):
    cli_test.CliTest("example").run_selenium(user=user_manager.installed())

Podobno kot pri običajnih testih v Pythonu dodajte njegov ovoj v main.pm, ga zaženite lokalno med razvojem in ga vključite v tok testiranja, ki izvaja to funkcijo.

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.