Wyślij zapytanie Dołącz do Sii

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.

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 “ 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 ( głosy: 5)
Ocena:
5/5 ( głosy: 5)
Autor
Avatar
Paweł Wilk

Zajmuje się testowaniem oprogramowania od ok. 7 lat, wykorzystując do tego Pythona i Robot Frameworka. Bierze udział głównie w krótkoterminowych projektach z branży Embedded oraz bankowej. Poza pracą uwielbia biegać i spacerować, a do tego zaczytuje się w tematach astrofizyki oraz wschodnich filozofii.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

  • Fajne, lekkie wprowadzenie do tematu testów systemów wbudowanych z użyciem RF.

    Temat bliski memu sercu dlatego wtrocę swoje 2 grosze ;). Mianowicie powstały problem półautomatycznych testów można rozwiązać na kilka sposobów, mniej lub bardziej ekonomicznych.

    Do tych chyba najmniej ekonomicznych, z pnktu widzenia rozwoju oprogramowania, należą te z wykożystaniem cyfrowego bliźniaka (Digital Twin). Stosowane są róźne poziomy duplikowania funkcjonalności. A najpopularniejszym zestawem wspomagającym proces DT jest chyba LabView + PXI + dodatkowy sprzęt labolatoryjny. Taki DT pozwala na pełną symulację budowanego systemu, tworzenie testów, integrację tworzonego SW/HW (symylowany-symylowany/ symylowany-rzeczywisty) w róznych konfiguracjach i na róznych poziomach. Sam temat DT nie jest zbyt popularny, dlatego też jest odpowiednio mniej narzędzi SW/HW. Te open source zostawiają wiele do życzenia 🙁 np MyOpenLab

    Tańszą alternatywą, np dla mniej wymagających projektów niż SpaceX;) , może być stosowanie dodatkowych układów HW/SW wspomagających test – np jeśli w opisanym tutorialu testujemy wyświetlacz LCD z czujnikiem temp/hum, możemy wzbogacić nasz test harness o dodatkowy RPI z kamerą i programem analizującym wyświetlany tekst na wyświetlaczu LCD. Zastosować mini komorę klimatyczną dla czujnika (jeśli jego działąnie jest strategiczne), lub po prostu zamiast czujnika wpiąć sie naszym RPI poprzez GPIO i zasymulować sam czujnik, itp. Ważne żeby zawsze separować testowany system od środowiska testowego.

    Tak czy inaczej pełna automatyzacje wymaga zazwyczaj trochę większego nakładu pracy, przez co musi być uzasadniona ekonomicznie. Jeśli projekt jest długoterminowy warto zawsze inwestować w pełnowartościowe automaty do testów regresyjnych. Tymbardziej że w testach półautomatycznych, wg mnie, o pomyłkę dużo łątwiej niż przy testach całkowicie manualnych lub całkowicie automatycznych.

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?