openQA pour les équipement de développement et de maintenance
KDE Linux utilise openQA pour tester automatiquement chaque image système avant sa publication. openQA démarre chaque image dans une machine virtuelle et vérifie qu'elle peut être installée, mise à niveau et utilisée avec succès.
openQA possède une terminologie spécifique : une tâche est une exécution d'une suite de tests sur une image, tandis qu'un processus est la machine ou le conteneur exécutant la tâche. La documentation sur openQA explique ces concepts ainsi que d'autres, notamment les modules de test, les groupes de tâches, les actifs et l'interface utilisateur Internet.
Comment fonctionnent les tests
La tâche de tests s'exécute parallèlement au pipeline d'intégration continue (CI), afin de pouvoir utiliser les images et les disques virtuels produits par la compilation sans télécharger ces fichiers volumineux ailleurs. Les tests sont fournis à la machine virtuelle grâce à une extension système et communiquant avec elle grâce à SSH.
Les tests sur le bureau utilisent l'API d'accessibilité grâce à « selenium-webdriver-at-spi », lui permettant d'interagir avec les applications et de vérifier leur état sans se fier uniquement à la correspondance de captures d'écran. La suite vérifie également les services système défaillants, les processus de bureau défaillants, les problèmes de réseau et les régressions dans les commandes de KDE Linux.
Cycle d'intégration continue (CI) et flux de travail de l'équipe de maintenance
Sur la branche protégée par défaut du dépôt amont de KDE Linux, le pipeline fonctionne comme suit :
- La tâche imaging compile, signe et valide l'image et son canal « sysupdate » sur « storage.kde.org ».
- La tâche trigger-openqa démarre le pipeline dans os-autoinst-distri-kdelinux, en lui transmettant l'URL de l'image validée et l'URL du canal « sysupdate ».
- Le pipeline en aval exécute le flux normal d’installation et d’intégrité ainsi que le flux de mise à niveau.
- La tâche publish amont ne s'exécute qu'après la réussite du pipeline pour openQA. Il fait la promotion de l’image déjà mise en ligne auprès du public.
Cela fait d’un échec sous openQA un point bloquant pour la publication d’images. Veuillez démarrer par l'ouverture du pipeline en aval à partir de la tâche « trigger-openqa », puis l'ouverture de la tâche de openQA défaillante à partir de son journal d'intégration continue (CI). La page de la tâche affiche les modules de test dans l'ordre et vous permet d'identifier si l'échec concerne l'installation, les tests d'intégrité du système installé ou l'emplacement de la mise à niveau.
Télécharger une image préparée
The link provided after the log message “In case of failure, you can inspect and download the .iso image and sysupdate tree at…” opens a storage browser for the build under test. Download the .iso there to boot it manually or give it to a local openQA stack. The sysupdate tree contains the staged update artifacts used by the upgrade test.
Investiguer sur une tâche en erreur
Ouvrez la tâche dans l'interface utilisateur Internet de openQA et sélectionnez d'abord le module défaillant. Le lien vers l'interface utilisateur Internet apparaîtra après que le message de journal « La tâche de tests
For tests that execute commands on the system under test, KDE Linux runs them in transient systemd services and records the service journal as diagnostic output in the test result. Inspect autoinst-log.txt for the command output and journal. You can also download the *kde-linux-collected-logs.tar.zst file for logs captured by the collect-logs tool.
Exécutez des tests localement
Vous pouvez utiliser openQA pour tester une image construite localement avant de soumettre une modification. Ceci est requis lorsque vous travaillez à partir d'un fork en dehors de « kde-linux/kde-linux » - son pipeline d'intégration continue (CI) construit une image de tests, mais ne déclenche pas le pipeline de openQA. C'est également utile lors du développement de tests pour vos propres modifications.
Le dépôt de tests de KDE Linux, openQA comprend une pile locale contenant à la fois une interface utilisateur Internet pour openQA et un processus. Cela nécessite Podman et « podman-compose », faisant partie de KDE Linux.
Clone the test repository, then place the KDE Linux .iso image you want to test in its root directory. If no image is present, the test runner downloads the latest publicly available image instead.
Démarrez la pile locale.
./mock.sh up
Once it is ready, open http://localhost:1080 to inspect the openQA web UI. Jobs are not submitted automatically, so, open a shell in the container and submit the normal install and sanity-test flow.
podman exec -it openqa-single-instance bash ./qa flow
Pour exécuter le flux de mise à niveau à la place, veuillez ajouter --upgrade :
./qa flow --upgrade
Pour exécuter le flux de test d'installation de chiffrement de disque, veuillez ajouter --encrypt :
./qa flow --encrypt
Vous pouvez également combiner les options --upgrade et --encrypt :
./qa flow --upgrade --encrypt
The sanity-test job needs the install-system job to run first because it uses the virtual disk created by the installation. To concentrate on a particular test, adjust the submitted jobs in lib/worker/job_flow.py or run an individual job with ./qa job while keeping that dependency in mind. Run ./qa job --help to see the options it requires.
Par exemple, pour exécuter une tâche « install-system » dans laquelle vous avez téléchargé un fichier « .iso » dans le dossier du dépôt :
./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
Lorsque vous avez terminé, veuillez arrêter la pile et supprime ses volumes locaux.
./mock.sh down -v
Écrire un test
Les définitions de test et le code de test se trouvent sur la page os-autoinst-distri-kdelinux. Ajoutez le test au flux approprié dans le fichier « main.pm » : le flux d'installation en direct, le flux d'intégrité du système installé ou le flux de mise à niveau. Les tests sont généralement composés d'un petit wrapper pour openQA dans le dossier « tests/ » et d'un test Python s'exécutant sur le système à tester à partir du dossier « extensions/openqa/usr/lib/kde-linux-openqa/tests/ ».
Sectionnez le type de test en fonction de ce que vous vérifiez :
- Utilisez un « test unitaire » Python normal pour les outils en ligne de commandes, les services, l'état du système de fichiers ou tout autre comportement non graphique.
- Utilisez Selenium grâce à « selenium-webdriver-at-spi » lorsque le comportement nécessite une interaction avec une application graphique.
Tests Python classiques
Create a unittest in the aforementioned system extension test directory. It should make assertions about the system under test and write its results to a JUnit XML file, which will be automatically collected as an openQA asset and a GitLab CI report.
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")
Créez un wrapper correspondant sous le dossier « tests/ » permettant à openQA d'exécuter le test sur l'hôte.
from testapi import *
from lib.test import cli_test
def run(self):
cli_test.CliTest("example").run_python()
Enfin, veuillez enregistrer le wrapper dans le flux concerné dans le fichier « main.pm ». Le wrapper collecte le résultat de JUnit et la sortie de la commandes afin que les échecs apparaissent dans la tâche de openQA et les artefacts d'intégration continue (CI).
Tests graphiques avec Selenium
Graphical tests are also Python unittest classes, but use the Appium/Selenium driver to find and interact with accessible UI elements. The Selenium runner enables the accessibility infrastructure and starts the driver for you.
Par exemple, un test graphique crée un pilote pour son application, interagit avec les éléments accessibles et ferme ensuite le pilote :
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")
Exécutez le wrapper correspondant avec « run_selenium() » plutôt que « run_python() ». Réussissez le test utilisateur installé pour les applications de bureau :
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 la même manière que les tests normaux sous Python, veuillez ajouter son wrapper à « main.pm », l'exécuter localement pendant le développement et l'inclure dans le flux de tests qui testera la fonctionnalité.
Pour plus d'informations sur l'écriture de tests avec Selenium, veuillez consulter la page Tests d'automatisation avec Appium et Tests d'interface graphique Utilisateur avec selenium-webdriver-at-spi.
En apprendre encore plus
Pour une explication plus détaillée du flux de tests et de sa mise en œuvre, veuillez consulter la page Exécution de tests sous openQA sous KDE Linux. L'infrastructure des tests est développée dans le dépôt os-autoinst-distri-kdelinux.
Article rédigé par Thomas Duckworth sous licence CC-BY-4.0.