Trade Federation (w skrócie Tradefed lub TF) to framework do testów ciągłych przeznaczony do przeprowadzania testów na urządzeniach z Androidem. Na przykład Tradefed jest używany do uruchamiania pakietu testów zgodności (CTS) i pakietu testów dostawcy (VTS) .
Trade Federation to aplikacja Java działająca na komputerze hosta i komunikująca się z jednym lub większą liczbą urządzeń z systemem Android za pomocą ddmlib (biblioteki stojącej za DDMS) przez adb.
Poniżej wymieniliśmy niektóre z głównych funkcji TF, wraz z kilkoma przykładowymi przypadkami użycia. To powiedziawszy, jeśli chcesz od razu przystąpić do działania, możesz przejść bezpośrednio do strony Zacznij tutaj .
Cechy
- modułowa, elastyczna i skalowalna konstrukcja
- ma wbudowaną obsługę uruchamiania wielu różnych typów testów Androida: oprzyrządowanie , uiautomator , natywny/gtest, JUnit oparty na hoście itp.
- zapewnia mechanizmy niezawodności i odzyskiwania oprócz adb
- obsługuje planowanie i uruchamianie testów na wielu urządzeniach równolegle
Zobacz Testowanie za pośrednictwem TF, aby uzyskać najbardziej aktualne informacje na temat uruchamiania istniejących testów, takich jak Instrumentacja .
Przypadków użycia
Modułowość Trade Federation ułatwia dopasowanie do środowisk z istniejącą infrastrukturą kompilacji, testowania i raportowania. Poniżej podajemy kilka demonstracyjnych przypadków użycia, w których handel może umożliwić wydajne i skalowalne praktyki testowe.
Po pierwsze, warto rozważyć krajobraz potencjalnych przypadków użycia w kontekście pytania „które części można modyfikować, a które są statyczne?” Na przykład producent OEM urządzenia może modyfikować strukturę, system i sprzęt, ale ma niewielki lub żaden wpływ na istniejące aplikacje. Z drugiej strony twórca aplikacji może modyfikować aplikację, ale ma niewielką kontrolę nad większością aspektów systemu lub frameworka.
W rezultacie jednostka w każdym przypadku użycia będzie miała inne cele testowania i będzie miała różne opcje w przypadku zestawu niepowodzeń testów. Pomimo tych różnic Federacja Handlowa może pomóc w zapewnieniu wydajności, elastyczności i skalowalności każdego procesu testowego.
Urządzenie OEM
Producent OEM urządzenia buduje sprzęt i często modyfikuje system Android i platformy, aby dobrze działały na tym sprzęcie. Producent OEM może dążyć do osiągnięcia tych celów, zachowując stabilność i wydajność na poziomie sprzętu i systemu oraz upewniając się, że zmiany struktury nie zakłócają kompatybilności z istniejącymi aplikacjami.
Producent OEM może wdrożyć moduł flashowania urządzenia, który będzie wykonywany na etapie konfiguracji docelowej w cyklu życia . Moduł ten miałby pełną kontrolę nad urządzeniem w okresie jego wykonywania, co umożliwiłoby mu potencjalne wymuszenie uruchomienia programu ładującego, flashowania, a następnie wymuszenia ponownego uruchomienia urządzenia w trybie przestrzeni użytkownika. W połączeniu z modułem umożliwiającym połączenie z systemem ciągłej kompilacji umożliwiłoby to producentowi OEM przeprowadzanie testów na swoim urządzeniu podczas wprowadzania zmian w oprogramowaniu sprzętowym na poziomie systemu i frameworkach na poziomie Java.
Po pełnym uruchomieniu urządzenia producent OEM będzie mógł wykorzystać istniejące testy oparte na JUnit lub napisać nowe, aby zweryfikować interesującą go funkcjonalność. Na koniec mogliby napisać jeden lub więcej modułów raportowania wyników, aby powiązać je z istniejącymi repozytoriami wyników testów lub bezpośrednio raportować wyniki (na przykład pocztą elektroniczną ).
Twórca aplikacji
Programista aplikacji tworzy aplikację, która musi dobrze działać na różnych wersjach platform i różnych urządzeniach. Jeśli pojawi się problem dotyczący konkretnej wersji platformy i/lub urządzenia, jedynym rozwiązaniem jest dodanie obejścia i przejście dalej. W przypadku większych programistów proces testowania można włączyć do ciągłej sekwencji kompilacji. W przypadku mniejszych programistów może być uruchamiany okresowo lub ręcznie.
Większość twórców aplikacji korzystałaby z modułów instalacyjnych testów apk, które już istnieją w TF. Istnieje wersja, która instaluje się z lokalnego systemu plików , a także wersja, która może instalować aplikacje pobrane z usługi kompilacji . Należy zauważyć, że ta druga wersja będzie nadal działać poprawnie z dowolną liczbą instancji TF działających na tym samym komputerze hosta.
Ze względu na biegłość TF w posługiwaniu się wieloma urządzeniami, proste byłoby sklasyfikowanie każdego wyniku testu według rodzaju urządzenia użytego w tym teście. Zatem TF mógłby potencjalnie wygenerować dwuwymiarową (lub wielowymiarową) macierz kompatybilności dla każdej kompilacji aplikacji.
Usługa testowania
Usługa testowa może na przykład umożliwiać twórcom aplikacji przesyłanie aplikacji i przeprowadzanie testów na urządzeniach wyposażonych w narzędzia do pomiaru mocy w celu określenia zużycia energii przez aplikację. Różni się to od dwóch poprzednich przypadków użycia tym, że konstruktor usług nie kontroluje uruchomionych urządzeń ani aplikacji.
Ponieważ Federacja Handlowa może uruchomić dowolną klasę Java, która implementuje prosty interfejs IRemoteTest , napisanie sterowników, które mogą koordynować jakiś zewnętrzny element sprzętu z przypadkiem testowym uruchamianym na urządzeniu, jest banalne. Sam sterownik może tworzyć wątki, wysyłać żądania do innych serwerów lub wykonywać inne czynności, których może potrzebować. Co więcej, prostota i wszechstronność interfejsu raportowania wyników, ITestInvocationListener , oznacza, że równie łatwo jest przedstawić dowolne wyniki testów (w tym na przykład numeryczne metryki mocy) w standardowym potoku raportowania wyników.