Złożona konfiguracja testowa

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Niektóre moduły testowe mogą wymagać niestandardowej konfiguracji i usuwania kroków, których nie można wykonać w samym przypadku testowym. Typowe przykłady mogą obejmować:

  • zainstaluj inne apki (oprócz testowego apk)
  • przesłać niektóre pliki na urządzenie
  • uruchamiaj polecenia (np. adb shell pm ...)

W przeszłości zespoły komponentów zwykle uciekały się do pisania testów po stronie hosta w celu wykonania takich zadań, co wymagało zrozumienia uprzęży Federacji Handlowej i zazwyczaj zwiększało złożoność modułu testowego.

Zapożyczając się z CTS, wprowadziliśmy koncepcję konfiguracji modułu testowego do obsługi takich zadań, powyższa lista wspólnych zadań może zostać osiągnięta za pomocą zaledwie kilku linii konfiguracji. Aby uzyskać maksymalną elastyczność, możesz nawet zaimplementować własne narzędzie przygotowujące docelowe, zdefiniowane przez ITargetPreparer lub ITargetCleaner , i skonfigurować je do użycia we własnej konfiguracji modułu testowego.

Konfiguracja modułu testowego dla modułu testowego to wymagany plik XML dodany do folderu źródłowego modułu najwyższego poziomu o nazwie „AndroidTest.xml”. XML jest zgodny z formatem pliku konfiguracyjnego używanego przez uprząż automatyzacji testów Federacji Handlowej. Obecnie głównymi tagami obsługiwanymi przez konfiguracje modułu testowego są tagi „target_preparer” i „test”.

Przygotowujący docelowi

Znacznik „target_preparer”, jak sama nazwa wskazuje, definiuje docelowy program przygotowawczy (patrz ITargetPreparer ), który oferuje metodę konfiguracji, która jest wywoływana przed wykonaniem modułu testowego w celu testowania; a jeśli klasa, do której odwołuje się znacznik „target_preparer”, implementuje również ITargetCleaner , jej metoda rozkładania zostanie wywołana po zakończeniu modułu testowego.

Aby użyć wbudowanej konfiguracji wspólnego modułu, dodaj nowy plik „AndroidTest.xml” w folderze najwyższego poziomu modułu testowego i wypełnij go następującą zawartością:

<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>

Jako przykład możemy dodać następujące tagi opcji (w komentarzu „wstaw” powyżej):

    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>

Opcje skonfigurują wiązkę testową tak, aby:

  1. przed wywołaniem modułu testowego wykonaj polecenie powłoki „settings put secure access_enabled 1” na urządzeniu
  2. po zakończeniu testowania modułu wykonaj polecenie powłoki „settings put secure access_enabled 0”

W tym konkretnym przykładzie dostępność jest włączana/wyłączana odpowiednio przed/po wykonaniu modułu testowego. Przedstawiając prosty przykład, należy omówić więcej szczegółów na temat używania tagu „opcja”. Jak pokazano powyżej, tag może mieć dwa atrybuty: nazwa, wartość. Atrybut nazwy wskazuje nazwę opcji i jest dalej podzielony na dwie części oddzielone dwukropkiem: skróconą nazwę osoby przygotowującej i rzeczywistą nazwę opcji oferowanej przez osobę przygotowującą.

Dokładne przeznaczenie pola wartości zależy od tego, jak przygotowujący zdefiniował opcję: może to być ciąg znaków, liczba, wartość logiczna, a nawet ścieżka do pliku itp. W powyższym przykładzie nazwa „run-command:run-command” oznacza że ustawiamy wartość dla opcji „run-command” zdefiniowanej przez docelowego przygotowującego o krótkiej nazwie „run-command”; a nazwa „run-command:teardown-command” oznacza, że ​​ustawiamy wartość dla opcji „teardown-command” również zdefiniowanej przez ten sam przygotowujący docelowy o krótkiej nazwie „run-command”. Oto podsumowanie trzech wspólnych osób przygotowujących cele:

  • nazwa klasy: PushFilePreparer

    • skrócona nazwa : plik push
    • funkcja : wypycha dowolne pliki z folderu przypadków testowych do miejsca docelowego na urządzeniu
    • uwagi :
      • ten przygotowujący może przesyłać z folderu do folderu lub z pliku do pliku; oznacza to, że nie możesz umieścić pliku w folderze na urządzeniu: musisz również określić docelową nazwę pliku w tym folderze
    • opcje :
      • push-file: specyfikacja push, określająca plik lokalny w ścieżce, do której powinien zostać wypchnięty na urządzeniu. Może się powtórzyć. Jeśli wiele plików jest skonfigurowanych do wypychania do tej samej ścieżki zdalnej, zostanie wypchnięty najnowszy.
      • push: (przestarzałe) Specyfikacja push, sformatowana jako ' /path/to/srcfile.txt->/path/to/destfile.txt ' lub ' /path/to/srcfile.txt->/path/to/destdir/ '. Może się powtórzyć. Ta ścieżka może odnosić się do katalogu modułu testowego lub samego katalogu out.
      • post-push: Polecenie do uruchomienia na urządzeniu (z ` adb shell <your command> `) po wykonaniu wszystkich prób push. Typowym przypadkiem użycia byłoby użycie chmod dla uprawnień
  • nazwa klasy: InstallApkSetup

    • krótka nazwa: install-apk
    • funkcja: wypycha dowolne pliki apk do miejsca docelowego na urządzeniu
    • opcje:
      • test-file-name: nazwa apk do zainstalowania na urządzeniu.
      • install-arg: dodatkowe argumenty, które należy przekazać do polecenia pm install, w tym myślnik, np. „-d”. Może się powtarzać
  • nazwa klasy: RunCommandTargetPreparer

    • skrócona nazwa: polecenie uruchomienia
    • funkcja: wykonuje dowolne polecenia powłoki przed lub po wykonaniu modułu testowego
    • opcje:
      • run-command: polecenie powłoki adb do uruchomienia. Może się powtórzyć
      • polecenie rozerwania: polecenie powłoki adb do uruchomienia podczas fazy rozdzierania. Może się powtórzyć

Klasa testowa

Klasa testowa to klasa Federacji Handlowej używana do wykonania testu.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

Oto trzy popularne klasy testowe:

  • nazwa klasy: GTest

    • skrócona nazwa: gtest
    • funkcja: Test, który uruchamia natywny pakiet testowy na danym urządzeniu.
    • opcje:
      • ścieżka-natywnego-urządzenia-testowego: Ścieżka na urządzeniu, na którym znajdują się testy natywne.
  • nazwa klasy: InstrumentationTest

    • skrócona nazwa: oprzyrządowanie
    • funkcja: Test, który uruchamia pakiet testowy oprzyrządowania na danym urządzeniu
    • opcje:
      • pakiet: nazwa pakietu manifestu aplikacji testowej systemu Android do uruchomienia.
      • class: nazwa klasy testowej do uruchomienia.
      • metoda: nazwa metody testowej do uruchomienia.
  • nazwa klasy: AndroidJUnitTest

    • funkcja: Test, który uruchamia pakiet testowy oprzyrządowania na danym urządzeniu za pomocą android.support.test.runner.AndroidJUnitRunner Jest to główny sposób wykonania testu oprzyrządowania.