Embedded

Automatyzacja testów Systemów Wbudowanych z wykorzystaniem Robot Frameworka – część 1

Lipiec 24, 2019 0
Podziel się:

Testowanie w Embedded od dawna było procesem żmudnym i trudnym w automatyzacji. Wiele dziedzin przemysłu wciąż opiera się w dużej mierze na testach ręcznych. Wydłuża to czas od wypuszczenia oprogramowania do znalezienia defektów. Na szczęście pojawia się coraz więcej narzędzi i metod automatyzacji, które można zaadaptować do pracy nad oprogramowaniem w Embedded. W tym artykule przedstawimy przykładowy projekt Embedded wraz z metodą przetestowania jego działania.

Wprowadzenie

Najczęstszą praktyką jest wykorzystanie osobnych urządzeń do pobudzania i zbierania danych z naszego DUT (Device Under Test). Dzięki takiemu rozwiązaniu możemy zaprogramować układ, automatycznie wprowadzić go w żądany stan i symulować nieistniejące peryferia. Takie urządzenia muszą zapewnić wsparcie dla wielu magistrali komunikacyjnych czy sterowanie GPIO. Przykładem takiego komputera jest Raspberry Pi lub BeagleBone.

Do zarządzania testem i całym środowiskiem testowym od zainicjalizowaniu potrzebnych modułów po zebranie wyników potrzebujemy jarzmo testowe (ang. test harness). Istotna jest możliwość definiowania własnych bibliotek testowych, na przykład w celu wspierania komunikacji z urządzeniem. Kolejnym wymogiem jest wsparcie dla języków skryptowych w celu łatwego tworzenia testów automatycznych. Istotna jest też możliwość konfiguracji i uruchamiania testów za pomocą plików konfiguracyjnych. Świetnym narzędziem, które spełnia te wymagania jest Robot Framework.

O Robot Frameworku

Robot Framework jest darmowym, otwarto źródłowym narzędziem do tworzenia testów akceptacyjnych oraz rozwoju oprogramowania opartym na tych testach (Acceptance TDD). Poza tym, Robot pozwala nam nie tylko na tworzenie testów, ale może być również narzędziem stosowanym do automatyzacji różnych procesów. Dodatkowo Robot pozwala na wygodną egzekucję oraz generowanie raportów z tych procesów. Jego największą zaletą jest możliwość wrapowania API w słowa kluczowe – frazy w języku naturalnym, które są bardziej zrozumiałe dla osób nie zagłębionych w techniczną stronę projektu. Przykłady i szczegółowe wyjaśnienie przedstawiono w dalszej części artykułu. Sama składnia tego frameworka jest w pewien sposób podobna do Pythona: trzeba zwracać szczególną uwagę na stosowanie odstępów i tabulacji. Jednak to nie wszystko, możemy w nim również używać API napisanego w Javie!

W celu zaprezentowania możliwości Robot Frameworka wykorzystamy mini komputer Raspberry Pi w wersji 3B, wykorzystujący czujnik temperatury i wilgoci DHT11 oraz wyświetlacz LCD z konwerterem do I2C, LCM1602.

schemat połączenia e1562141061469 - Automatyzacja testów Systemów Wbudowanych z wykorzystaniem Robot Frameworka - część 1

Komunikacja z tymi urządzeniami odbywa się za pomocą protokołów I2C (wyświetlacz LCD) oraz OneWire (czujnik DHT11).

Kolorami czerwonymi oznaczone są połączenia zasilające o napięciu 5V, czarnymi połączenie masy. Inne kolory służą do komunikacji z urządzeniami.

Jak zainstalować Robot Frameworka na Raspberry Pi lub innym komputerze? Bardzo prosto! Wystarczy:

  1. Otworzyć terminal (Ctrl+Alt+t) lub, w przypadku systemu Windows, wiersz poleceń.
  2. Wpisać w terminalu/wierszu poleceń polecenie “pip install robotframework” lub
    “python3 –m pip install robotframework”.

Sposoby pisania testów

Testy akceptacyjne możemy pisać na kilka różnych sposobów, najlepiej w takim, aby był zrozumiały dla większości osób zainteresowanych projektem. Poniżej przedstawiamy 3 sposoby na pisanie testów w Robot Frameworku, które spełniają to założenie

Keyword driven tests

Styl ten polega na “opakowywaniu” kodu napisanego w Pythonie lub w Javie do słów kluczowych, które są prostsze do zrozumienia przez człowieka. Na przykład kod, który odpowiada za wyczyszczenie ekranu:

def send_clear_command(self):
""" Clears LCD screen."""
self.send_command(0x01, LCD_CMD)
time.sleep(E_DELAY)

Można opakować w dekorator:

@keyword(name="Clear screen")

Dzięki takiemu zabiegowi nie musimy stosować często niezrozumiałych funkcji. Zamiast tego, możemy je zastąpić frazami zrozumiałymi dla każdego.

Tak wygląda przykład testu, który jest napisany z użyciem słów kluczowych (ang. keywords):

Cleaning screen should remove the text from both lines
[Tags]  LCD
display message  Hello World  in line 1
display message  Robot Framework in line 2
Ask user if Is there any text displayed on the display?[y/n]
Clear screen
Ask user if Is there any text displayed on the display?[y/n]

Data Driven Tests

Ten styl polega na stworzeniu szablonu testu, a następnie na uruchamianiu go wielokrotnie, za każdym razem z innymi argumentami I oczekiwanym rezultatem.. Najlepiej będzie to pokazać, w tym przypadku dla testów wyświetlacza LCD. Oto jak wygląda szablon testu:

*** Keywords ***
Verify if text is displayed
[Arguments]  ${text}  ${expected_response}
display message  ${text}
log to console  \nDo you see "${text}" on the screen?[y/n]
${answer} =  user verification
should be equal as strings  ${answer}  ${expected_response}

Następnie, należy w sekcji Settings zdefiniować chęć użycia tego szablonu do testów.

Test Template  Verify if text is displayed

Mając spełnione obie z tych rzeczy, możemy zabrać się za tworzenie przypadków testowych. W tym przypadku testy mają formę kolumnową. Polega to na tym, że w pierwszej kolumnie wpisujemy nazwę testu, a w kolejnych kolumnach argumenty, jakie będą używane w teście. Dzięki temu, kod testów jest bardzo czytelny.

*** Test Cases ***     Text                         Expected_Response

Short text             Hello there.                  y
Longer text             Hello, my precious world!    y
Special characters      WHAT IS $!@$%&*#@?? here?    y
Greek letters           ΔΘφρπξΞΦΨ                    n

Gherkin Style Tests

Jest to składnia bardzo zbliżona do pierwszego sposobu, różni się nieznacznie, ponieważ dodatkowo stosuje słowa Given, When, and oraz Then. Pozwala nam to na jeszcze precyzyjniejsze określenie zachowania, jakiego oczekujemy od oprogramowania. Przykładowo:

Given a clean screen
When “An Example text” being displayed
Then  User should see mentioned text in the screen

Jaki jest cel naszego testowania?

Celem naszego testów jest udowodnienie, że podłączone peryferia (czujnik DHT11 oraz wyświetlacz) działają zgodnie z określonymi wymaganiami. Dokonamy też weryfikacji oprogramowania obsługującego te urządzenia. W tym celu zdefiniowaliśmy listę wymagań:

  1. Czujnik temperatury DHT11
    • Czujnik powinien być podpięty pod pin 36.
    • Czujnik powinien zwrócić poprawne dane poniżej określonego czasu (domyślnie 10 sekund).
    • Próby odczytania z niepodłączonych pinów nie powinno się udać.
    • Odczytana temperatura powinna mieścić się w zakresie od 18 do 30 stopni Celsjusza.
    • Odczytana wilgotność powinna mieścić się w zakresie od 0 do 80 %.
    • Moduł obsługujący czujnik powinien zwracać reprezentację temperatury w formacie “<temperatura> C”.
  2. Wyświetlacz LCD 2×16
    • Wyświetlacz powinien mieć możliwość wyświetlania tekstu w dwóch liniach.
    • Jeśli tekst do wyświetlenia ma więcej niż 16 znaków i zadane jest wyświetlenie w pierwszej linii, to wyświetlacz powinien przedstawić tekst w dwóch liniach.
    • Wyświetlacz nie powinien przedstawiać tekstu, jeśli tekst do wyświetlenia ma więcej niż 16 znaków i zadane jest wyświetlenie w drugiej linii.
    • Wyświetlacz nie powinien przedstawiać tekstu, który ma więcej niż 32 znaki.
    • Wyświetlacz powinien mieć zaimplementowaną opcję wyczyszczenia ekranu z wszelkiego tekstu.

Niektórych testów nie jesteśmy w pełni zautomatyzować ze względu na ograniczenia technologiczne lub budżetowe. Przykładem takich testów są testy dla wyświetlacza. Jednak i w tym przypadku możemy wykorzystać framework testowy w celu automatyzacji większości scenariusza testowego. W miejscu, w którym potrzebujemy weryfikacji manualnej (np. wyświetlonego tekstu na ekranie) Robot Framework wstrzyma wykonanie testu i będzie oczekiwać na dane wejściowe od testera.

W kolejnej części artykułu zajmiemy się praktyczną stroną testowania. Pokażemy w jaki sposób zostały stworzone słowa kluczowe do testów oraz jak napisane są testy. Uruchomimy testy i przeanalizujemy wygenerowane raporty po egzekucji testów.

 

Seria artykułów powstała dzięki pracy dwóch testerów – Bartłomieja Hirsza oraz Pawła Wilka – Testerów z Centrum Kompetencyjnego Embedded w Sii.

5 / 5
Kategorie: Embedded
Paweł Wilk
Autor: Paweł Wilk

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz