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

Le lien fourni après le message de journal « En cas d'échec, vous pouvez inspecter et télécharger l'image .iso et l'arborescence de sysupdate à… » ouvre un navigateur pour enregistrer la compilation en cours de test. Veuillez y télécharger le fichier .iso là, pour le démarrer manuellement ou le fournir à une pile locale de openQA. L'arborescence de « sysupdate » contient les artefacts de mise à jour validés, utilisés par le test de mise à niveau.

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 est en cours d'exécution. ». Ses détails précisent le résultat du module, des captures d'écran ou une vidéo, selon le cas, et la sortie de diagnostics. Dans l'onglet Journaux et ressources, téléchargez ou consultez le fichier « autoinst-log.txt » pour le journal du processus pour openQA et du moteur de test. Il s'agit du journal principal pour la tâche elle-même.

Pour les tests exécutant des commandes sur le système en tests, KDE Linux les exécute dans des services « systemd » transitoires et enregistre le journal des services comme sortie de diagnostic dans le résultat du test. Veuillez regarder le fichier « autoinst-log.txt » pour la sortie de la commande et le journal. Vous pouvez également télécharger le fichier « *kde-linux-collected-logs.tar.zst » pour les journaux capturés par l'outil collect-logs.

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.

Veuillez cloner le dépôt de tests, puis placer l'image .iso de KDE Linux que vous souhaitez tester dans son dossier racine. Si aucune image n'est présente, le programme d'exécution des tests télécharge à la place la dernière image disponible de façon publique.

Démarrez la pile locale.

./mock.sh up

Une fois qu'il est prêt, veuillez ouvrir la page http://localhost:1080 pour inspecter l'interface utilisateur Internet de openQA. Les tâches ne sont pas soumises automatiquement. Alors, veuillez ouvrir un shell dans le conteneur et lancer le flux normal d'installation et de test d'intégrité.

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

La tâche « sanity-test » nécessite que le processus « install-system » soit exécuté en premier car il utilise le disque virtuel créé par l'installation. Pour vous concentrer sur un test particulier, veuillez ajuster les tâches soumises dans le le fichier « lib/worker/job_flow.py » ou lancer une tâche individuelle avec . /qa job en gardant cette dépendance à l'esprit. Veuillez lancer la commande . /qa job --help pour afficher les options requises.

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

Créez un test unitaire dans le dossier de tests d'extension du système précédemment cité. Il doit faire des assertions sur le système à tester et écrire ses résultats dans un fichier « XML » pour JUnit. Celui-ci sera automatiquement envoyé comme un actif de openQA et comme rapport pour l'intégration continue (CI) sous GitLab.

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

Les tests graphiques sont également des classes Python « unittest ». Cependant, ils utilisent le pilote Appium / Selenium pour rechercher et interagir avec les éléments accessibles d'interface utilisateur. Le lanceur de Selenium active l'infrastructure d'accessibilité et démarre le pilote pour vous.

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.