Trade Federation (w skrócie Tradefed lub TF) to ciągły framework testowy przeznaczony do uruchamiania testów na urządzeniach z systemem Android. Na przykład Tradefed służy do uruchamiania zestawu testów zgodności (CTS) i zestawu testów dostawcy (VTS) .
Trade Federation to aplikacja Java, która działa na komputerze-hoście i komunikuje się z jednym lub kilkoma urządzeniami z Androidem za pomocą ddmlib (biblioteka stojąca 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 wskoczyć i zacząć, możesz przejść bezpośrednio do strony Zacznij tutaj .
Cechy
- modułowa, elastyczna, skalowalna konstrukcja
- ma wbudowaną obsługę uruchamiania wielu różnych typów testów Androida: instrumentation , uiautomator , native/gtest, JUnit oparty na hoście itp.
- zapewnia mechanizmy niezawodności i odzyskiwania poza adb
- obsługuje planowanie i uruchamianie testów na wielu urządzeniach równolegle
Zobacz Testowanie przez TF , aby uzyskać najbardziej aktualne informacje na temat uruchamiania istniejących testów, takich jak Instrumentacja .
Przypadków użycia
Modułowość Federacji Handlowej ułatwia wpasowanie się w środowiska z istniejącą infrastrukturą kompilacji, testowania i raportowania. Poniżej przedstawiamy kilka demonstracyjnych przypadków użycia, w których handel może umożliwić wydajne, skalowalne praktyki testowe.
Po pierwsze, warto rozważyć krajobraz potencjalnych przypadków użycia pod kątem 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 deweloper aplikacji może modyfikować aplikację, ale ma niewielką kontrolę nad większością aspektów systemu lub struktury.
W rezultacie encja w każdym przypadku użycia będzie miała różne 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 uczynieniu każdego z procesów testowych wydajnym, elastycznym i skalowalnym.
Urządzenie OEM
Producent OEM urządzenia buduje sprzęt i często dostosowuje system Android i frameworki, aby działały dobrze 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 naruszają zgodności z istniejącymi aplikacjami.
OEM może wdrożyć moduł flashowania urządzeń, który będzie wykonywany podczas etapu konfiguracji docelowej cyklu życia . Ten moduł miałby pełną kontrolę nad urządzeniem w trakcie jego wykonywania, co pozwoliłoby mu potencjalnie zmusić urządzenie do uruchomienia programu ładującego, flashować, a następnie wymusić ponowne uruchomienie urządzenia w trybie przestrzeni użytkownika. W połączeniu z modułem do powiązania z systemem ciągłej kompilacji, umożliwiłoby to producentom OEM przeprowadzanie testów na ich urządzeniu podczas wprowadzania zmian w oprogramowaniu układowym na poziomie systemu i strukturach 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ą funkcjonalność. Wreszcie 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ą ).
Programista aplikacji
Programista aplikacji tworzy aplikację, która musi działać dobrze na różnych wersjach platformy i na różnych urządzeniach. Jeśli pojawi się problem na określonej wersji platformy i/lub urządzeniu, jedynym rozwiązaniem jest dodanie obejścia i przejście dalej. W przypadku większych programistów proces testowania może zostać włączony do ciągłej sekwencji kompilacji. W przypadku mniejszych programistów może być uruchamiany okresowo lub ręcznie.
Większość programistów aplikacji używałaby modułów instalacyjnych testowych 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ć apki pobrane z usługi budowania . Należy zauważyć, że ta druga wersja będzie nadal działać poprawnie z dowolną liczbą instancji TF uruchomionych na tym samym komputerze hosta.
Ze względu na biegłość TF w radzeniu sobie z wieloma urządzeniami, łatwo byłoby sklasyfikować każdy wynik testu według typu urządzenia, które zostało użyte do tego testu. W ten sposób TF może potencjalnie wygenerować dwuwymiarową (lub wielowymiarową) macierz zgodności dla każdej kompilacji aplikacji.
Usługa testowania
Usługa testowa może na przykład umożliwiać deweloperom aplikacji przesyłanie aplikacji i uruchamianie 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 poprzednich dwóch przypadków użycia tym, że konstruktor usług nie kontroluje urządzeń ani uruchamianych 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 trywialne. Sam sterownik może tworzyć wątki, wysyłać żądania do innych serwerów lub robić wszystko, czego może potrzebować. Co więcej, prostota i wszechstronność interfejsu raportowania wyników, ITestInvocationListener , oznacza, że równie proste jest reprezentowanie dowolnych wyników testów (w tym na przykład liczbowych metryk mocy) w standardowym potoku raportowania wyników.