openQA для розробників і супровідників

KDE Linux використовує openQA для автоматичного тестування кожного образу системи перед його оприлюдненням. openQA завантажує кожен образ у віртуальну машину та перевіряє, чи його можна встановити, оновити та успішно використовувати.

openQA має певну специфічну термінологію: завдання (job) — це одне виконання набору тестів на зображенні, тоді як обробник (worker) — це машина або контейнер, який виконує це завдання. Документація openQA пояснює ці та інші концепції, включаючи тестові модулі, групи завдань, ресурси (resources) та веб-інтерфейс.

Як працюють тести

Обробник тестів працює паралельно з конвеєром неперервної інтеграції (CI), тому він може використовувати образи та віртуальні диски, створені під час збірки, не завантажуючи ці великі файли в інше місце. Тести надходять до віртуальної машини через системне розширення та взаємодіють з нею за допомогою SSH.

Тести стільниці використовують програмний інтерфейс доступності через selenium-webdriver-at-spi, що дозволяє їм взаємодіяти з програмами та перевіряти їхній стан, не покладаючись виключно на зіставлення знімків екрана. Пакет також перевіряє наявність збоїв системних служб, аварійно завершених процесів робочого столу, мережевих проблем та регресій у командах KDE Linux.

Робочий процес конвеєра неперервної інтеграції та супроводу

У захищеній типовій гілці основного сховища KDE Linux конвеєр працює наступним чином:

Завдання створення образів збирає, підписує та розміщує образ і його канал sysupdate на storage.kde.org.
Завдання trigger-openqa запускає конвеєр в os-autoinst-distri-kdelinux, передаючи йому адресу проміжного образу та адресу каналу sysupdate.
Нижній конвеєр виконує звичайний процес встановлення та перевірки справності, а також процес оновлення.
Завдання оприлюднення основного потоку виконується лише після успішного завершення конвеєра openQA. Воно поширює вже підготовлений образ для публічного використання.

Це робить збій openQA шлюзом для оприлюднення образу. Спочатку відкрийте низхідний конвеєр із завдання trigger-openqa, а потім відкрийте завдання openQA, що завершилося невдачею, з його журналу неперервної інтеграції. Сторінка завдання показує тестові модулі за порядком та надає змогу визначити тип збою: у встановленні, тестах на працездатність встановленої системи чи шляху оновлення.

Отримання етапного образу

Посилання, надане після повідомлення журналу «У разі невдачі ви можете перевірити та завантажити образ .iso та дерево sysupdate за адресою…», відкриває браузер сховища для тестованої збірки. Вивантажте туди файл .iso, щоб завантажити його вручну, або передайте його до локального стосу openQA. Дерево sysupdate містить артефакти поетапного оновлення, що використовуються тестом оновлення.

Виявлення завдання, виконання якого призвело до помилки

Відкрийте завдання у вебінтерфейсі openQA і спочатку виберіть модуль, у якому сталася помилка. Посилання на вебінтерфейс з’явиться після повідомлення журналу «<назва> тестове завдання зараз виконується». Його детальна інформація містить результат модуля, знімки екрана або відео, де це можливо, та діагностичні дані. На вкладці Журнали та ресурси завантажте або перегляньте файл autoinst-log.txt для журналу обробника openQA та тестового рушія. Це основний журнал для самого завдання.

Тести, які виконують команди в тестованій системі, KDE Linux запускає у тимчасових службах systemd та записує журнал служби як діагностичне виведення результатів перевірки. Перегляньте autoinst-log.txt, щоб ознайомитися із виведеними командою даними та журналом. Ви також можете завантажити файл *kde-linux-collected-logs.tar.zst для ознайомлення зі журналом, отриманим за допомогою інструменту collect-logs.

Запуск тестів локально

Ви можете використовувати openQA для тестування локально зібраного образу перед надсиланням змін. Це потрібно під час роботи з відгалуженням поза kde-linux/kde-linux — його конвеєр неперервної інтеграції створює тестовий образ, але не запускає конвеєр openQA. Це також корисно під час розробки тестів для ваших власних змін.

Тестове сховище openQA для KDE Linux містить локальний стос, що містить як вебінтерфейс openQA, так і обробник. Для нього потрібні Podman та podman-compose, які включені до KDE Linux.

Клонуйте тестове сховище, а потім помістіть образ .iso KDE Linux, який ви хочете протестувати, у його кореневий каталог. Якщо образу немає, програма тестування завантажує останній загальнодоступний образ.

Запустіть локальний стос.

./mock.sh up

Як тільки все буде готово, відкрийте http://localhost:1080, щоб оглянути вебінтерфейс openQA. Завдання не надсилаються автоматично, тому відкрийте оболонку в контейнері та надішліть звичайний процес встановлення та процедури тестування працездатності.

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

Щоб запустити процес оновлення, додайте --upgrade:

./qa flow --upgrade

Щоб запустити процедуру перевірки встановлення з шифрування диска, додайте --encrypt:

./qa flow --encrypt

Ви можете поєднати параметри --upgrade і --encrypt:

./qa flow --upgrade --encrypt

Для виконання завдання sanity-test слід спочатку виконати завдання install-system, оскільки завдання використовує віртуальний диск, створений встановленням. Щоб зосередитися на певному тесті, скоригуйте надіслані завдання у lib/worker/job_flow.py або запустіть окреме завдання за допомогою ./qa job, враховуючи залежності. Запустіть ./qa job --help, щоб ознайомитися із потрібними параметрами.

Наприклад, щоб запустити завдання install-system, де у вас є файл .iso, завантажений у каталог сховища, віддайте таку команду:

./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

Коли роботу буде завершено, зупиніть стос і вилучіть його локальні томи.

./mock.sh down -v

Написання тесту

Визначення тестів та програмний код тестів зберігаються в os-autoinst-distri-kdelinux. Додайте тест до відповідного потоку в main.pm — потоку інтерактивного встановлення, потоку перевірки встановленої системи або потоку оновлення. Тести зазвичай складаються з невеликої обгортки openQA в tests/ та тесту Python, який запускається на тестованій системі з extensions/openqa/usr/lib/kde-linux-openqa/tests/.

Виберіть тип тестування на основі того, що ви перевіряєте:

Скористайтеся звичайним unittest Python для інструментів командного рядка, служб, стану файлової системи або інших речей, які не пов'язано із графікою.
Скористайтеся Selenium за допомогою selenium-webdriver-at-spi, якщо потрібне взаємодія із програмою з графічним інтерфейсом.

Звичайні тести Python

Створіть unittest у вищезгаданому каталозі тестування розширень системи. Він має виконати перевірки тестованої системи і записати свої результати у файл XML JUnit, який буде автоматично зібраний як ресурс openQA та звіт неперервної інтеграції 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")

Створіть відповідну обгортку у tests/, яка отримає доступ до openQA для виконання тесту в основній системі.

from testapi import *
from lib.test import cli_test

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

Нарешті, зареєструйте обгортку у відповідному потоці в main.pm. Обгортка збирає результат JUnit та виведені командою дані, щоб помилки було показано у завданні openQA та результатах роботи системи неперервної інтеграції.

Тестування графіки з Selenium

Тести графіки також є класами Python unittest, але використовують драйвер Appium/Selenium для пошуку та взаємодії з доступними елементами інтерфейсу користувача. Засіб запуску Selenium активує інфраструктуру доступності і запускає драйвер.

Наприклад, тест графіки створює драйвер для своєї програми, взаємодіє з доступними елементами і після цього закриває драйвер:

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")

Запустіть відповідну обгортку з run_selenium() замість run_python(). Передайте користувача тестованої встановленої системи для стільничних програм:

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())

Подібно до звичайних тестів Python, додайте його обгортку до main.pm, запустіть її локально під час розробки та включіть її в потік тестування, який перевіряє цю можливість.

Щоб дізнатися більше про написання тестів Selenium, ознайомтеся з даними щодо автоматичного тестування Appium та тестуванням графіки за допомогою selenium-webdriver-at-spi.

Додаткові відомості

Докладніші пояснення щодо процесу тестування та його реалізації наведено на сторінці Тестування openQA в KDE Linux. Розробка інфраструктури тестування виконується у сховищі os-autoinst-distri-kdelinux.

Статтю надіслано Thomas Duckworth, умови ліцензування — CC-BY-4.0.