Wyślij zapytanie Dołącz do Sii

W tej części zajmiemy się praktyczną stroną testowania, pokażemy w jaki sposób używać słów kluczowych oraz jak pisać testy. Część pierwszą przeczytacie tutaj.

Biblioteki testowe

Dużym atutem Robot Frameworka jest łatwe dołączanie i wykorzystywanie bibliotek testowych. Bardziej zaawansowane operacje są prostsze w implementacji w języku skryptowym takim jak Python. Na poniższym przykładzie przedstawimy dwie wersje słowa kluczowego, zaimplementowanego w Robot Frameworku i w Pythonie. Przy pracy z Robotem możemy wykorzystać wbudowane biblioteki albo zaimplementować własne.

Repozytorium kodu możecie pobrać tutaj > robot-framework-tests.

Importowanie biblioteki wygląda następująco:

*** Settings ***
 
Library DHT11TestLibrary.py

Jeżeli nazwa pliku biblioteki oraz nazwa klasy będzie taka sama, to Robot Framework sam utworzy instancję biblioteki. W naszym przypadku dla klasy DHT11TestLibrary tworzymy o takiej samej nazwie z rozszerzeniem .py . Domyślnie Robot Framework utworzy jedną instancję na jedną egzekucję testów. Jeżeli zależy nam na zmianie tego zachowania możemy użyć następującej deklaracji w bibliotece:

class DHT11TestLibrary:
ROBOT_LIBRARY_SCOPE = 'TEST CASE'

Spowoduje  to, że biblioteka będzie inicjalizowana ponownie dla każdego testu z osobna. Z dostępnych opcji możemy ustawić inicjalizację biblioteki:

  • osobno dla każdej grupy testów ( ‘TEST SUITE’)
  • dla całej egzekucji (‘GLOBAL’)

Robot Framework parsuje metody w klasie biblioteki testowej tak, aby można wywoływać je w skrypcie Robota. Dla poniższej metody testowej:

def temperature_string_shall_be_in_correct_format(self):
temperature_str = self.dht11_inst.temperature_to_str()
if re.match(r'^[1-9]+\d* C$', temperature_str):
return True
raise AssertionError('Temperature string in invalid format: {}'.format(temperature_str))

Możemy użyć następujących metod wywołania w Robocie (podkreślniki można zastąpić spacjami, wielkość liter nie ma znaczenia). Nie ma również potrzeby określenia nazwy biblioteki, z której wywołujemy słowa kluczowe, co w ostateczności skutkuje takim formatem wywołania metody:

Temperature_string_shall_be_in_correct_format
Temperature string shall be in correct format

Możemy użyć Robot API, aby wywołać słowo kluczowe pod inną nazwą niż zadeklarowana w bibliotece. Dzięki API możemy dodać wszelakie informacje, takie jak tagi, dokumentację czy typ przekazywanego argumentu (domyślnie przekazywane są bez zmian).
Na przykładzie naszego testu keyword napisany w Robot Frameworku oraz w Pythonie (o podobnym działaniu):

Robot Framework

Temperature shall be in range
[Arguments] ${min} ${max}
Log \nVerify that read temperature is between ${min} and ${max} console=True
${data}= dht11 shall return sensor data
Log Temperature: ${data.temperature} console=True
Run_Keyword_If ${min} > ${data.temperature} > ${max} FAIL  msg='DHT11 returned temperature outside range'

Python

def humidity_shall_be_in_range(self, min_hum, max_hum):
"""
Verify that humidity from sensor is in given range.
Args:
min_hum(int): minimum for humidity threshold (exluding)
max_hum(int): maximum for humidity threshold (exluding)
 
Raises:
TimeoutError: when timeout pass before correct data is returned
AssertionError: when read humidity is not between min_hum and max_hum
 
Returns:
True: when read humidity is between min_hum and max_hum
"""
 
logger.info('Verify that humidity is between {} and {}'.format(min_hum, max_hum), True, True)
senses = self.dht11_inst.get_sensor_data()
logger.info('Humidity: {}'.format(senses.humidity), True, True)
if (min_hum > senses.humidity) or (senses.humidity > max_hum):
raise AssertionError('DHT11 returned humidity outside range')
return True

Testowanie sensora DHT11 i struktura pliku .robot

Do pracy z sensorem DHT11 przygotowaliśmy moduł do obsługi czujnika DHT11.py oraz bibliotekę testową DHT11TestLibrary.py
Na podstawie postawionych wymagań stworzyliśmy plik Robot z testami, znajdujący się w pliku DHT11Tests.robot

Teraz dobrze byłoby przyjrzeć się strukturze pliku, używanego przez Robot Frameworka.

W pliku znajdują się 4 sekcje, zaczynające się słowem kluczowym, otoczonym gwiazdkami:

  • Settings – tutaj umieszczana jest dokumentacja testu, importowane są biblioteki oraz ‘zasoby’, czyli wbudowane biblioteki robot frameworka,
  • Variables – w tym miejscu możemy sobie zdefiniować zmienne, które będziemy stosowali testach,
  • Test Cases – chyba nikomu nie trzeba tłumaczyć  ?
  • Keywords – miejsce na tworzenie słów kluczowych w Robocie z pomocą składni Robota

Uruchamianie testów

Aby uruchomić testy przeznaczone dla Robot Frameworka, wystarczy wpisać w wierszu polecenia/linii komend następujące zaklęcie:

robot <lokalizacja_pliku_z_testami>

Możliwe jest również podanie samego katalogu, gdzie znajdują się pliki .robot, w takim wypadku, zostaną uruchomione wszystkie testy, jakie znajdują się w plikach tego katalogu.

Po uruchomieniu testów na Raspberry Pi Robot wygenerował logi z testów. Z konsoli możemy odczytać ogólny przebieg testów (również w trakcie ich wykonywania):

logi z testow e1563964044215 - Automatyzacja testów Systemów Wbudowanych z wykorzystaniem Robot Frameworka - część 2

Bardziej szczegółowe informacje dostępne są po zakończeniu testów, gdy Robot wygeneruje sam logi oraz raport z egzekucji.

logi html 1 - Automatyzacja testów Systemów Wbudowanych z wykorzystaniem Robot Frameworka - część 2

Jak widać, każdy z tych testów ma możliwość „rozwinięcia”, dzięki czemu możemy zobaczyć dokładniej, jakie instrukcje zostały wykonane w teście.

logi html rozwiniete - Automatyzacja testów Systemów Wbudowanych z wykorzystaniem Robot Frameworka - część 2

Robot Framework udostępnia również szereg narzędzi do formatowania i parsowania raportów (np. testdoc, rebot). Za ich pomocą możemy zmienić wygląd logów albo nadpisać pewne dane. Dzięki temu z jednej egzekucji testów możemy wygenerować raporty dla różnych interesariuszy.

Testowanie wyświetlacza LCD i Date Driven Tests

Do weryfikacji funkcji wyświetlacza nie wystarczy nam tylko oprogramowanie (chyba, że posłużylibyśmy się rozpoznawaniem tekstu), lecz potrzebna będzie też osoba, która zweryfikuje, czy na wyświetlaczu pokazywane są pożądane rezultaty. Dlatego wygodnym sposobem jest jak największe zautomatyzowanie tego procesu oraz dostarczenie użytkownikowi w miarę wygodnego sposobu do weryfikacji zjawisk. W naszym przypadku będzie to proste pytanie z wymagające od użytkownika odpowiedzi y/n .

Plik z testami LCD znajduje się w pliku LCDDataDriverTests.robot lub w LCDKeywordDrivenTests.robot.

W pierwszym pliku jest zaprezentowany sposób Data Driven, który był opisywany w poprzedniej częśći artykułu. Tworzenie takich testów polega na:
– Stworzeniu/użyciu słowa kluczowego, który będzie używany przez każdy przypadek testowy. W naszym przypadku jest to słowo kluczowe ‘Verify if text is displayed’.
– Ustawienia keyworda jako szablonu, do którego będą podawane różne dane, robimy to za pomocą opcji Test Template
– Napisania testów, w tym przypadku polega to na podaniu nazwy testu i odpowiednich argumentów

Gdy uruchomimy testy wyświetlacza, zauważymy że egzekucja zostanie zatrzymana, a użytkownik poproszony o wprowadzenie odpowiedzi na podstawie własnych obserwacji.

Oto, jak wygląda w praktyce praca z takimi testami:

1 pytanie e1563964301172 1 - Automatyzacja testów Systemów Wbudowanych z wykorzystaniem Robot Frameworka - część 2
2 pytanie e1563964346723 1 - Automatyzacja testów Systemów Wbudowanych z wykorzystaniem Robot Frameworka - część 2

Podsumowanie

Powyżej zaprezentowaliśmy zaledwie namiastkę możliwości, na jakie pozwala nam Robot Framework, w tym przypadku dla zastosowań embedded, w których nie jest często używany. Pokazaliśmy również, jak możemy używać bibliotek do zastosowań testowych i jak pisać testy w Robot Frameworku na dwa sposoby.

Użyteczne linki i bibliografia

Zauważyliśmy, że Robot Framework ma bardzo dobrze napisaną dokumentację wraz z przykładami użycia, dlatego dołączamy tutaj jeszcze kilka linków dla osób bardziej zainteresowanych.

https://robotframework.org/
https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html
https://github.com/robotframework/HowToWriteGoodTestCases/blob/master/HowToWriteGoodTestCases.rst
https://github.com/robotframework/robotframework/blob/master/doc/userguide/src/ExtendingRobotFramework/CreatingTestLibraries.rst

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.

4.2/5 ( głosy: 8)
Ocena:
4.2/5 ( głosy: 8)
Autor
Avatar
Bartłomiej Hirsz

Zajmuję się testami funkcjonalnymi i integracyjnymi dla branży automotive za pomocą Robot Frameworka i Pythona. W wolnych chwilach lubię przeczytać dobry komiks albo wybrać się na rowerową wyprawę.

Zostaw komentarz

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

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?