openQA – jak testujemy system EuroLinux

OpenQA – czyli jak testujemy system EuroLinux

Jednym z elementów łańcucha testów systemu EuroLinux jest oprogramowanie openQA. To zautomatyzowane narzędzie testowe, które pozwala na kompleksową analizę całego procesu instalacji systemu operacyjnego, jak również na wizualne testy poszczególnych aplikacji. W tym artykule pokażemy, jak z niego korzystamy.

Jednym z elementów łańcucha testów systemu EuroLinux jest oprogramowanie openQA. To zautomatyzowane narzędzie testowe, które pozwala na kompleksową analizę całego procesu instalacji systemu operacyjnego, jak również na wizualne testy poszczególnych aplikacji. W tym artykule pokażemy, jak z niego korzystamy.

openQA wykorzystuje maszyny wirtualne i fizyczne do odtwarzania procesu instalacji, sprawdzania wyjścia (zarówno konsoli szeregowej, jak i ekranu) i wysyłania niezbędnych wciśnięć klawiszy, poleceń i ruchów myszy. Testy openQA są napisane w języku Perl, a do ich obsługi wymagana jest znajomość tego języka. Pakiet openQA jest zbudowany na perlowym frameworku Mojolicious służącym do budowania interaktywnych stron internetowych.

Interfejs openQA
Interfejs openQA

openQA może przeprowadzić kilka kombinacji testów dla każdej wersji systemu operacyjnego, raportując wykryte błędy dla każdej kombinacji konfiguracji sprzętowej, opcji instalacyjnych i wariantu systemu operacyjnego. Wykorzystuje tutaj możliwości zestawu KVM/QEMU, a w przypadku systemu EuroLinux, korzysta również z wirtualizacji zagnieżdżonej. openQA jest wolnym oprogramowaniem udostępnianym na licencji GPLv2.

Sercem silnika testowego jest samodzielna aplikacja o nazwie os-autoinst. Aplikacja ta tworzy maszynę wirtualną i wykorzystuje ją do uruchomienia zestawu skryptów testowych. Generuje filmy, zrzuty ekranu i pliki JSON ze szczegółowymi wynikami testów.

Przykładowy film z procesu instalacji wersji Minimal systemu EuroLinux 8 wygenerowany poprzez silnik openQA

openQA dostarcza webowy interfejs użytkownika i infrastrukturę do uruchomienia os-autoinst w sposób rozproszony. Interfejs webowy dostarcza również REST API umożliwiające korzystanie z zewnętrznych skryptów i do użytku przez tzw. workery. Pobierają one dane i pliki wejściowe z openQA dla os-autoinst w celu uruchomienia testów. Jeden system hosta może odpalić kilka takich prac. Aplikacja webowa i workery mogą być uruchomione na tej samej maszynie, jak również połączone przez sieć na wielu maszynach.

Maszyny

Aby przeprowadzić testy, musimy posiadać skonfigurowaną przynajmniej jedną maszynę w YAML-owych plikach definicji. Pliki te reprezentują typy maszyn wirtualnych, które chcemy testować. Aby testy się odbyły, musi zostać uruchomiony przynajmniej jeden worker openQA, który spełnia poniższe specyfikacje:

  • nazwa – ciąg znaków zdefiniowany przez użytkownika – potrzebny operatorowi do identyfikacji konfiguracji maszyny
  • backend – zalecaną wartością jest qemu, ponieważ jest to najczęściej wykorzystywany silnik, ale inne opcje (takie jak kvm2usb lub vbox) są również dostępne
  • zmienne – większość zmiennych maszyny wpływa na zachowanie os-autoinst pod względem tego, jak maszyna testowa jest skonfigurowana. Kilka przykładów:
    • QEMUCPU (‘qemu32’ lub ‘qemu64’) – określa architekturę wirtualnego CPU
    • QEMUCPUS – jest liczbą całkowitą określającą liczbę rdzeni, które chcemy włączyć do testów
    • LAPTOP – jeśli ustawione na 1, QEMU utworzy profil laptop
    • USBBOOT – jeśli ustawione na 1, obraz będzie ładowany przez emulowaną pamięć USB.

Poniżej przykładowe definicje

maszyny:

   "Machines": {
        "64bit": {
            "backend": "qemu",
            "settings": {
                "ARCH_BASE_MACHINE": "64bit",
                "PART_TABLE_TYPE": "mbr",
                "QEMUCPU": "Nehalem",
                "QEMUCPUS": "2",
                "QEMURAM": "2048",
                "QEMUVGA": "virtio",
                "QEMU_VIRTIO_RNG": "1",
                "WORKER_CLASS": "qemu_x86_64"
            }
        }

dystrybucji:

   "Products": {
        "EuroLinux-8-x86_64-*": {
            "arch": "x86_64",
            "distri": "eurolinux",
            "flavor": "DVD",
            "settings": {
                "+QEMURAM": 3072,
                "TEST_TARGET": "ISO"
            },
            "version": "*"
        }
    }

profili:

    "Profiles": {
        "EuroLinux-8-x86_64-*-64bit": {
            "machine": "64bit",
            "product": "EuroLinux-8-x86_64-*"
        }
    }

Igły

Jednym z głównych mechanizmów pozwalających openQA poznać stan maszyny wirtualnej, jest sprawdzenie obecności pewnych elementów na „ekranie” wirtualnej maszyny. Odbywa się to za pomocą rozmytego dopasowania obrazu pomiędzy ekranem, a tzw. igłami. Igła określa zarówno elementy do wyszukania, jak i listę znaczników służących do decydowania, które igły powinny być w danym momencie użyte.

Igła składa się z pełnego zrzutu ekranu w formacie PNG oraz pliku JSON o tej samej nazwie (np. el12.png i el12.json). Zawiera on powiązane dane, takie jak obszary wewnątrz pełnego zrzutu ekranu, które są istotne dla procesu testującego.

Przykładowa igła w interfejsie openQA
Przykładowa igła w interfejsie openQA

Odpowiednie obszary są oznaczane wizualnie bezpośrednio w serwisie openQA – zaznaczenie obszaru skutkuje utworzeniem odpowiedniego pliku JSON z opisanymi współrzędnymi obszarów. W powyższym przypadku plik JSON igły ma następującą postać:

{
  "area": [
    {
      "xpos": 7,
      "ypos": 86,
      "width": 536,
      "height": 33,
      "type": "match"
    },
    {
      "xpos": 31,
      "ypos": 96,
      "width": 10,
      "height": 10,
      "type": "match"
    },
    {
      "xpos": 23,
      "ypos": 36,
      "width": 74,
      "height": 29,
      "type": "match",
      "click_point": {
        "xpos": 37,
        "ypos": 14.5
      }
    }
  ],
  "properties": [],
  "tags": [
    "timezone-next"
  ]
}

Obszary

Istnieją trzy rodzaje obszarów:

  • obszary regularne – definiują istotne części zrzutu ekranu. Muszą pasować do siebie z co najmniej określonym procentem podobieństwa. Są wyświetlane jako zielone pola w edytorze igieł oraz jako zielone lub czerwone ramki w widoku igły (zielone dla obszarów pasujących, czerwone dla niepasujących)
  • obszary OCR – również definiują istotne części zrzutu ekranu, jednak do dopasowania używany jest algorytm OCR. W edytorze igły obszary OCR są wyświetlane jako pomarańczowe pola
  • obszary wykluczające – można je wykorzystać do ignorowania części obrazu referencyjnego. W edytorze igieł wykluczone obszary są wyświetlane jako czerwone ramki. W widoku igły wykluczone obszary są wyświetlane jako szare pola.
needleedit
Edycja obszarów dokonywana jest wizualnie bezpośrednio w interfejsie webowym

Zarządzanie dostępem

Niektóre działania w openQA wymagają specjalnych uprawnień. Domyślnie instancja openQA jest skonfigurowana do używania openID, ale może być łatwo skonfigurowana do korzystania z dowolnego innego dostawcy. Profil użytkownika zawiera tożsamość openID i dwie flagi używane do kontroli dostępu:

  • operator – oznacza, że użytkownik jest w stanie zarządzać zadaniami, wykonując takie czynności jak tworzenie nowych zadań, ich anulowanie itp.
  • admin – oznacza, że użytkownik jest w stanie zarządzać użytkownikami (nadając lub odbierając prawa operatora i administratora), jak również szablonami zadań i innymi powiązanymi informacjami.

Wiele z operacji openQA nie jest wykonywanych przez interfejs WWW, ale za pomocą REST API. Najbardziej typowym przykładem wykorzystania API są workery i skrypty, które pobierają nowe wersje systemu operacyjnego i planują odpowiednie testy.

Testowanie obrazu ISO

Aby rozpocząć testy nowego ISO, należy umieścić je w katalogu /var/lib/openqa/share/factory/iso i wywołać następujące, przykładowe polecenie:

openqa-cli api -X POST isos \
	ISO=EL-8.5-x86_64-20211201-appstream.iso \
	DISTRI=eurolinux8 \
	VERSION=5 \
	FLAVOR=appstream \
	ARCH=x86_64 \
	BUILD='EL8.5_20211201'

Grupy zadań

Grupy zadań to przestrzeń, gdzie definiuje się rzeczywiste scenariusze testowe poprzez wybór typu, zestawu testowego i maszyny wraz z wartością priorytetu. Jeżeli zaplanowanych jest wiele zadań i spełnione są wymagania do ich wykonania, uruchamiane są te o niższym priorytecie. Grupy zadań mogą być tworzone zarówno za pomocą interfejsu webowego, jak i REST API. Mogą być też opcjonalnie zagnieżdżane w kategoriach. Kolejność wyświetlania grup zadań i kategorii może być konfigurowana metodą „przeciągnij i upuść” w interfejsie webowym.

groups
Lista grup zadań

Testy oparte na serwerze pomocniczym

Dla zaawansowanych procedur testowych opartych na sieci, wymagane jest posiadanie dedykowanego „serwera pomocniczego”. Serwer pomocniczy wykorzystuje podstawową konfigurację równoległą, gdzie serwer pomocniczy jest testem nadrzędnym „A”, a potrzebujący go test jest testem potomnym „B”.

Używanie konsoli tekstowych i terminala szeregowego

Zazwyczaj system operacyjny uruchamia się w powłoce graficznej. W przypadku openQA jest to przydatne, gdy chcemy testować system z GUI, ale w wielu sytuacjach potrzebujemy wprowadzać polecenia bezpośrednio do powłoki, TTY, terminala tekstowego, wiersza poleceń itp. openQA posiada dwie podstawowe metody interakcji z powłoką tekstową. Pierwsza z nich wykorzystuje te same metody wejścia i wyjścia, jak w przypadku interakcji z GUI, plus port szeregowy dla uzyskania surowego tekstu wyjściowego. Druga metoda używa innego portu szeregowego zarówno dla wejścia, jak i wyjścia. Cała komunikacja jest więc wtedy oparta wyłącznie na tekście.

Podsumowanie

W artykule przedstawiamy zaledwie fragment możliwości openQA. Narzędzie to jest bardzo rozbudowane i oferuje szereg innych rozwiązań testowych, które systematycznie wdrażamy w nasz łańcuch testów. Nasza autorska integracja z Jenkinsem jeszcze bardziej rozszerza możliwości openQA i sprawia, że testowanie systemu EuroLinux jest procesem w pełni zautomatyzowanym i spójnym.

Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.