Pisanie testu w ramach narzędzia Tradefed

Na tej stronie dowiesz się, jak napisać nowy przebieg testowy w ramach Tradefed.

Tło

Jeśli chcesz dowiedzieć się więcej o miejscu testów w architekturze Tradefed, zapoznaj się z artykułem Struktura testu.

Nie jest to warunek wstępny dla napisania nowego narzędzia do testowania. Narzędzie do testowania można napisać niezależnie.

Wymagane minimum: wdrożenie interfejsu

Minimalnym wymogiem, aby spełniać kryteria testu Tradefed, jest implementacja interfejsu IRemoteTest, a w szczególności metody run(TestInformation testInfo, ITestInvocationListener listener).

Ta metoda jest wywoływana przez narzędzie testowe podczas uruchamiania testu, podobnie jak metoda Runnable w języku Java.

Każda część tej metody jest uważana za część wykonania testu.

Raportuj wyniki z testera

Metoda run w interfejsie podstawowym zapewnia dostęp do obiektu listenera typu ITestInvocationListener. Ten obiekt jest kluczem do raportowania uporządkowanych wyników z testu do gniazda.

W przypadku raportowania uporządkowanych wyników testów wykonawca testów ma te właściwości:

  • raportuje odpowiednią listę wszystkich przeprowadzonych testów, ich czas trwania oraz informacje o tym, czy poszczególne testy zakończyły się powodzeniem, niepowodzeniem czy w innym stanie;
  • Uwzględniaj w raportach dane związane z testami (w odpowiednich przypadkach), np. wskaźników związanych z instalacją.
  • Dopasowanie do większości narzędzi infrastruktury, np. wyświetlania wyników dane itd.
  • Zwykle łatwiej jest debugować, ponieważ dostępny jest bardziej szczegółowy ślad

Pamiętaj, że raportowanie uporządkowanych wyników jest opcjonalne. biegacz, chce tylko ocenić stan całego przebiegu jako ZAKOŃCZONO lub NIE ZAKOŃCZONO bez żadnych szczegółów dotyczących faktycznego wykonania.

Poniższe zdarzenia mogą być wywoływane dla detektora, aby powiadamiać o użyciu bieżący postęp wykonań:

  • testRunStarted: powiadamia o początku grupy powiązanych ze sobą przypadków testowych.
    • testStarted: powiadamia o rozpoczęciu przypadku testowego.
    • testFailed/testignored: powiadamiaj o zmianie stanu przypadku testowego w toku. Uwzględniany jest przypadek testowy bez żadnej zmiany stanu zaliczono.
    • testEnded: powiadamia o końcu przypadku testowego.
  • testRunFailed: powiadomienie o tym, że ogólny stan wykonania grupy przypadków testowych to błąd. Test może być zaliczony lub niezaliczony. niezależnie od wyników przypadków testowych, w zależności od tego, oczekiwanego wykonania. Na przykład binarny plik wykonywalny z kilkoma przypadkami testowymi może zgłosić wszystkie przypadki testowe jako pozytywny, ale z błędnym kodem zakończenia (z dowolnych powodów, np. wyciek plików).
  • testRunEnded: powiadamia o końcu grupy przypadków testowych.

Utrzymanie i zapewnienie odpowiedniej kolejności wywołań zwrotnych to odpowiedzialnością uruchamiającą proces testowania, na przykład za zapewnienie, Funkcja testRunEnded jest wywoływana w przypadku wyjątku za pomocą klauzuli finally.

Wywołania zwrotne testów (testStarted, testEnded itd.) są opcjonalne. Test może odbyć się bez żadnych przypadków testowych.

Być może z pewnością zauważysz, że inspiracją do tej struktury wydarzeń typową strukturę JUnit. Dzięki temu deweloperzy mają do dyspozycji podstawowe informacje, mają zazwyczaj wiedzę na ten temat.

Raportowanie dzienników z testu

Jeśli piszesz własną klasę testu lub funkcję testu Tradefed, zaimplementujesz IRemoteTest i uzyskasz ITestInvocationListener za pomocą metody run(). Ten detektor umożliwia rejestrowanie plików w następujący sposób:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Testowanie na urządzeniu

Minimalny interfejs powyżej pozwala na przeprowadzanie bardzo prostych testów, które są wydzielone i nie wymagają żadnych konkretnych zasobów, np. testów jednostkowych w języku Java.

Autorzy testów, którzy chcą przejść do następnego etapu testowania urządzeń, będą potrzebować tych interfejsów:

  • IDeviceTest umożliwia odbieranie obiektu ITestDevice, który reprezentuje urządzenie testu i udostępnia interfejs API do interakcji z nim.
  • IBuildReceiver umożliwia testowi pobranie obiektu IBuildInfo utworzonego w krok dostawcy kompilacji który zawiera wszystkie informacje i artefakty związane z konfiguracją testu.

Te interfejsy są zwykle interesujące dla osób uruchamiających testy, ponieważ umożliwiają uzyskiwanie artefaktów związanych z wykonaniem, na przykład dodatkowych plików, oraz dostęp do urządzenia testowanego w ramach wykonania.

Testowanie na wielu urządzeniach

Narzędzie Tradefed obsługuje uruchamianie testów na wielu urządzeniach jednocześnie. Jest to przydatne podczas testowania komponentów, które wymagają interakcji zewnętrznej, takich jak parowanie telefonu i zegara.

Aby napisać test runner, który może używać wielu urządzeń, musisz zaimplementować interfejs IMultiDeviceTest, który umożliwi otrzymanie mapy ITestDevice na IBuildInfo zawierającej pełną listę reprezentacji urządzeń i powiązanych informacji o kompilacji.

Setter z interfejsu zawsze będzie wywoływany przed metodą run, więc można założyć, że struktura będzie dostępna, gdy zostanie wywołana metoda run.

testy z uwzględnieniem konfiguracji,

Niektóre implementacje testów mogą wymagać informacji o całym skonfigurowaniu, aby działać prawidłowo. Mogą to być na przykład metadane dotyczące wywołania lub informacje o tym, które target_preparer zostały uruchomione wcześniej.

Aby to osiągnąć, test runner może uzyskać dostęp do obiektu IConfiguration, którego jest częścią i w którym jest wykonywany. Więcej informacji znajdziesz w opisie obiektu konfiguracji.

W przypadku implementacji mechanizmu uruchamiania testów musisz zastosować IConfigurationReceiver aby otrzymać obiekt IConfiguration.

Elastyczny biegacz testowy

Uruchamianie testów może być elastyczne, jeśli mają one precyzyjną kontrolę nad testami. Na przykład uruchamiacz testów JUnit może osobno uruchamiać poszczególne testy jednostkowe.

Dzięki temu szersze pasy i infrastruktura mogą wykorzystać tę dokładną kontrolę. i uruchamiać częściowe uruchamianie testu przy użyciu filtrowania.

Obsługa filtrowania jest opisana w interfejsie ITestFilterReceiver, który umożliwia odbiór zestawów filtrów include i exclude dla testów, które powinny lub nie powinny być wykonywane.

Zgodnie z naszą konwencją test jest wykonywany, jeśli pasuje do co najmniej 1 filtru uwzględniającego i nie pasuje do żadnego filtra wykluczającego. Jeśli nie podasz żadnych filtrów uwzględniających, wszystkie testy powinny być uruchamiane, o ile nie pasują do żadnego z filtrów wykluczających.