openQA per a desenvolupadors i mantenidors
La KDE Linux utilitza openQA per a provar automàticament totes les imatges del sistema abans de publicar-les. openQA arranca cada imatge en una màquina virtual i comprova que es pot instal·lar, actualitzar i utilitzar correctament.
openQA té una terminologia específica: un treball és una execució d'un conjunt de proves d'una imatge, mentre que un treballador és la màquina o contenidor que executa el treball. La documentació d'OpenQA explica estos i altres conceptes, inclosos els mòduls de prova, grups de treball, actius i la interfície d'usuari web.
Com funcionen les proves
El treballador de la prova s'executa junt amb la canonada de CI, de manera que pot utilitzar les imatges i els discs virtuals produïts per la construcció sense carregar estos fitxers grans en un altre lloc. Les proves se subministren a la màquina virtual a través d'una extensió del sistema i es comuniquen amb ella a través de SSH.
Les proves d'escriptori utilitzen l'API d'accessibilitat a través de selenium-webdriver-at-spi, permetent-les interactuar amb les aplicacions i comprovar el seu estat sense dependre únicament de la coincidència de captures de pantalla. El conjunt també comprova si hi ha serveis del sistema que hagen fallat, processos d'escriptori que petin, problemes de xarxa i regressions a les ordres de la KDE Linux.
Canonada de CI i flux de treball del mantenidor
En la branca predeterminada protegida de la font principal del repositori de la KDE Linux, la canonada funciona de la manera següent:
- El treball de creació d'imatges construïx, signa i situa la imatge i el seu canal «sysupdate» en
storage.kde.org. - El treball trigger-openqa inicia la canonada en os-autoinst-distri-kdelinux, passant-hi l'URL de la imatge situada i l'URL del canal «sysupdate».
- La canonada de la font secundària executa el flux normal «install-and-sanity» i el flux «upgrade».
- El treball de publicació de la font principal només s'executarà després que el pipeline openQA haja tingut èxit. Promou la imatge ja posada en escena per al consum públic.
Açò fa que una fallada d'openQA siga una porta per a la publicació d'imatges. Comenceu obrint la canonada de la font secundària des del treball trigger-openqa, i després obriu el treball openQA que ha fallat des del seu registre de CI. La pàgina de treball mostra els mòduls de prova en ordre i us permet identificar si la fallada està en la instal·lació, les proves de sanejament del sistema instal·lat o el camí d'actualització.
Baixada d'una imatge situada
L'enllaç proporcionat després del missatge de registre «En cas de fallada, podeu inspeccionar i descarregar la imatge .iso i l'arbre de sysupdate a…» obri un navegador d'emmagatzematge per a la construcció que es prova. Descarregueu allí la .iso per a arrancar-la manualment o donar-la a una pila local d'openQA. L'arbre del sysupdate conté els artificis d'actualització situats utilitzats per la prova d'actualització.
Investigació d'un treball que ha fallat
Obriu el treball a la interfície d'usuari web d'OpenQA i trieu primer el mòdul que ha fallat. L'enllaç cap a la interfície d'usuari web apareixerà després del missatge de registre «autoinst-log.txt per al treballador d'openQA i el registre del motor de proves. Este és el registre principal del treball en si.
Les proves que executen ordres en el sistema per a proves, la KDE Linux les executa en serveis de systemd transitoris i registra el diari de servei com a eixida de diagnòstic en el resultat de la prova. Inspeccioneu autoinst-log.txt on hi ha l'eixida d'ordres i el diari. També podeu baixar el fitxer *kde-linux-collected-logs.tar.zst dels registres capturats per l'eina collect-logs.
Executar localment les proves
Podeu utilitzar openQA per a provar una imatge construïda localment abans d'enviar un canvi. Açò és necessari quan es treballa des d'una bifurcació fora de kde-linux/kde-linux: la seua canonada de CI construïx una imatge de prova, però no activa la canonada d'openQA. També és útil mentre desenvolupeu proves per als vostres propis canvis.
El repositori de proves d'openQA de la KDE Linux inclou una pila local que conté tant una interfície d'usuari web d'openQA i un treballador. Requerix Podman i podman-compose, els quals estan inclosos en la KDE Linux.
Cloneu el repositori de proves, després col·loqueu la imatge .iso de la KDE Linux que voleu provar al seu directori arrel. Si no hi ha cap imatge, l'executor de proves baixa l'última imatge disponible públicament.
Inicieu la pila local.
./mock.sh up
Una vegada estiga llest, obriu http://localhost:1080 per a inspeccionar la interfície d'usuari web d'openQA. Els treballs no s'envien automàticament, per tant, obriu un intèrpret d'ordres al contenidor i envieu el flux normal d'instal·lació i «sanity-test».
podman exec -it openqa-single-instance bash ./qa flow
En canvi, per a executar el flux d'actualització, afegiu --upgrade:
./qa flow --upgrade
Per a executar el flux «install-test» de «disk-encryption», afegiu --encrypt:
./qa flow --encrypt
També podeu combinar les opcions --upgrade i --encrypt:
./qa flow --upgrade --encrypt
La tasca sanity-test necessita que la tasca install-system s'execute primer perquè utilitza el disc virtual creat per la instal·lació. Per concentrar-se en una prova en particular, ajusteu les tasques enviades cap a lib/worker/job.flow.py o executeu una tasca individual amb ./qa job mentre es té en compte esta dependència. Executeu ./qa job --help per a veure les opcions que requerix.
Per exemple, per a executar un treball install-system a on teniu un .iso baixat al directori del repositori:
./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
Quan hàgeu acabat, pareu la pila i elimineu els seus volums locals.
./mock.sh down -v
Escriure una prova
Les definicions de prova i el codi de prova estan a os-autoinst-distri-kdelinux. Afegiu la prova al flux apropiat a main.pm – el flux «live-install», el flux «installed-system sanity» o el flux «upgrade». Les proves es componen generalment d'un embolcall xicotet d'openQA en tests/ i una prova de Python que s'executa en el sistema per a proves des de extensions/openqa/usr/lib/kde-linux-openqa/tests/.
Trieu el tipus de prova en funció del que esteu comprovant:
- Utilitzeu un
unittestnormal de Python per a eines de línia d'ordres, serveis, estat del sistema de fitxers o altres comportaments no gràfics. - Utilitzeu Selenium a través de
selenium-webdriver-at-spiquan el comportament requerix interactuar amb una aplicació gràfica.
Proves normals de Python
Creeu una unittest al directori de proves d'extensió del sistema esmentat. Ha de fer assercions sobre el sistema per a proves i escriure els seus resultats a un fitxer en XML de JUnit, el qual s'arreplegarà automàticament com un actiu d'openQA i un informe 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")
Creeu un embolcall coincident a tests/ que obtinga l'openQA per a executar la prova en l'amfitrió.
from testapi import *
from lib.test import cli_test
def run(self):
cli_test.CliTest("example").run_python()
Finalment, registreu l'embolcall en el flux rellevant en main.pm. L'embolcall arreplega el resultat de JUnit i l'eixida de l'ordre de manera que les fallades apareixen en el treball d'openQA i els artificis de CI.
Proves gràfiques amb Selenium
Les proves gràfiques també són classes unittest de Python, però utilitzen el controlador Appium/Selenium per a trobar i interactuar amb elements accessibles de la interfície d'usuari. L'executor de Selenium habilita la infraestructura d'accessibilitat i inicia el conductor per a tu.
Per exemple, una prova gràfica crea un controlador per a la seua aplicació, interactua amb els elements accessibles i després tanca el controlador:
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")
Executeu l'embolcall que coincidisca amb run_selenium() en lloc de run_python(). Passeu l'usuari de prova instal·lat per a aplicacions d'escriptori:
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())
De manera similar a les proves normals de Python, afegiu el seu embolcall a main.pm, executeu-lo localment mentre es desenvolupa, i incloeu-lo en el flux de prova que exerceix la funció.
Per a més informació sobre l'escriptura de proves de Selenium, vegeu Proves d'automatització d'Appium i Proves GUI amb selenium-webdriver-at-spi.
Aprendre'n més
Per a una explicació més detallada del flux de prova i la seua implementació, vegeu proves d'openQA en la KDE Linux. La infraestructura de proves es desenvolupa al repositori os-autoinst-distri-kdelinux.
Article escrit per Thomas Duckworth d'acord amb la llicència CC-BY-4.0.