Google jest zaangażowany w promowanie równości rasowej dla społeczności czarnych. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Złożona konfiguracja testu

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 apk testowego)
  • przesłać niektóre pliki do urządzenia
  • uruchom polecenia (np. adb shell pm ...)

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

Pożyczając od CTS, wprowadziliśmy koncepcję konfiguracji modułu testowego do obsługi takich zadań, powyższą listę typowych zadań można osiągnąć za pomocą zaledwie kilku linii konfiguracji. Aby uzyskać maksymalną elastyczność, można nawet zaimplementować własny docelowy program przygotowujący, zgodnie z definicją ITargetPreparer lub ITargetCleaner , i skonfigurować go 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”. Kod XML jest zgodny z formatem pliku konfiguracyjnego używanego przez zespół przewodów automatyzacji testów Trade Federation. Obecnie głównymi tagami obsługiwanymi przez konfiguracje modułu testowego są tagi „target_preparer” i „test”.

Docelowi przygotowujący

Znacznik „target_preparer”, jak sugeruje nazwa, definiuje docelową osobę przygotowującą (patrz ITargetPreparer ), która oferuje metodę konfiguracji, która jest wywoływana przed wykonaniem modułu testowego w celu przetestowania; a jeśli klasa, do której odwołuje się znacznik „target_preparer”, również implementuje ITargetCleaner , jej metoda porzucenia zostanie wywołana po zakończeniu działania modułu testowego.

Aby użyć wbudowanej wspólnej konfiguracji 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 (pod komentarzem „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ą, aby:

  1. przed wywołaniem modułu testowego wykonaj na urządzeniu polecenie powłoki „settings put secure accessibility_enabled 1”
  2. po zakończeniu testowania modułu, wykonaj polecenie powłoki „ustawienia umieścić bezpieczną dostępność_ włączone 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, trzeba opisać więcej szczegółów na temat używania tagu „opcja”. Jak pokazano powyżej, tag może mieć dwa atrybuty: nazwę, wartość. Atrybut name wskazywał nazwę opcji i jest dalej podzielony na dwie części oddzielone dwukropkiem: krótka nazwa dla przygotowującego i rzeczywista nazwa opcji oferowana przez przygotowującego.

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

  • nazwa klasy: PushFilePreparer

    • krótka nazwa : plik push
    • funkcja : wypycha dowolne pliki z folderu przypadków testowych do miejsca docelowego na urządzeniu
    • uwagi :
      • ten przygotowujący może wypychać z folderu do folderu lub z pliku do pliku; oznacza to, że nie można umieścić pliku w folderze na urządzeniu: należy również określić nazwę pliku docelowego w tym folderze
    • opcje :
      • push: specyfikacja wypychana, sformatowana jako „ /path/to/srcfile.txt->/path/to/destfile.txt ” lub „ /path/to/srcfile.txt->/path/to/destdir/ ”. Może zostać powtórzona Ta ścieżka może odnosić się do katalogu modułu testowego lub samego katalogu wyjściowego.
      • ** post-push: ** Polecenie do uruchomienia na urządzeniu (z ` adb shell <your command> `) po wykonaniu wszystkich wypchnięć. Typowy przypadek użycia to 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:
      • nazwa-pliku-testowego: nazwa apk do zainstalowania na urządzeniu.
      • install-arg: dodatkowe argumenty, które mają być przekazane do polecenia pm install, w tym początkowy myślnik, np. „-d”. Może zostać powtórzony
  • nazwa klasy: RunCommandTargetPreparer

    • krótka 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ć
      • teardown-command: komenda powłoki adb do uruchomienia podczas fazy rozrywania. Może się powtórzyć

Klasa testowa

Klasa testowa to klasa Trade Federation 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 typowe klasy testów:

  • nazwa klasy: GTest

    • krótka nazwa: gtest
    • funkcja: Test, który uruchamia natywny pakiet testowy na danym urządzeniu.
    • opcje:
      • native-test-device-path: ścieżka na urządzeniu, w której znajdują się testy natywne.
  • nazwa klasy: InstrumentationTest

    • krótka 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 przy użyciu android.support.test.runner.AndroidJUnitRunner Jest to główny sposób wykonywania testu oprzyrządowania.