Niektóre moduły testowe mogą wymagać niestandardowej konfiguracji i zlikwidować etapy, których nie można można przeprowadzać w samym przypadku testowym. Typowe przykłady:
- zainstaluj inne pliki APK (oprócz testowego pakietu apk)
- Przekazywanie plików na urządzenie
- uruchamianie poleceń (np. adb shell pm ...)
W przeszłości zespoły składowe zwykle uciekały się do pisania testów po stronie hosta, i wykonywania takich zadań, a to wymaga wiedzy na temat tego, jak funkcjonuje federacja handlowa. i zwykle zwiększa złożoność modułu testowego .
Korzystając z platformy CTS, wprowadziliśmy koncepcję konfiguracji modułów testowych, tych typowych zadań można wykonać, używając kilku wierszy config. Aby uzyskać maksymalną elastyczność, możesz nawet wprowadzić własny cel, przygotowujący zgodnie z definicją podaną w ITargetPreparer. lub ITargetCleaner, i skonfigurować je do użycia w konfiguracji Twojego modułu testowego.
Konfiguracja modułu testowego dla modułu testowego to wymagany plik XML dodany na górze sekcji folder źródłowy modułu level o nazwie „AndroidTest.xml”. Plik XML ma format pliku konfiguracji wykorzystywanego przez algorytm automatyzacji testów przeprowadzanych przez federację handlową. Obecnie główne tagi obsługiwane w konfiguracji modułu testowego to „target_preparer” i „test” .
Przygotowanie do kierowania
Tag „target_preparer”, jak sama nazwa wskazuje, definiuje element przygotowujący element docelowy (zobacz ITargetPreparer). oferuje metodę konfiguracji, która jest wywoływana przed wykonaniem modułu testowego do testowania; a klasa, do której odwołuje się tag „target_preparer”, także implements ITargetCleaner, jego metoda zakończenia zostanie wywołana po zakończeniu pracy modułu testowego.
Aby użyć konfiguracji wbudowanego modułu wspólnego, dodaj nowy plik „AndroidTest.xml” na stronie w folderze najwyższego poziomu przeznaczonego na moduł testowy i zapełnij go następującymi wartościami: treść:
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
Na 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>
Te opcje spowodują skonfigurowanie jarzma testowego, aby:
- przed wywołaniem modułu testowego wykonaj polecenie powłoki „settings put Secure” 1 cal ułatwień dostępu na urządzeniu
- Po zakończeniu modułu testowego wykonaj polecenie powłoki „settings put Secure” ułatwienia dostępu 0”
W tym przykładzie ułatwienia dostępu są włączane i wyłączane przed do uruchomienia modułu testowego. Ten prosty przykład pokazuje, który zawiera więcej informacji o sposobie korzystania z tagu „option”. Jak pokazano powyżej, Tag może mieć 2 atrybuty: name oraz value. Atrybut name musi odnosić się do jedną z opcji dostępnych przez osoby przygotowujące.
Dokładne przeznaczenie pola wartości zależy od tego, jak zdefiniował on tę opcję: może to być ciąg, liczba, wartość logiczna, a nawet ścieżka pliku. Oto podsumowanie trzech najpopularniejszych sposobów przygotowywania celów:
nazwa klasy: PushFilePreparer
- short name: push-file
- function: przenosi dowolne pliki z folderu przypadku testowego do miejsce docelowe na urządzeniu
- uwagi:
- ten moduł przygotowujący może przekazać dane z folderu do folderu lub pliku do pliku; które że nie można przekazać pliku do folderu na urządzeniu. określ nazwę pliku docelowego także w tym folderze
- opcji:
- push-file:specyfikacja push określająca plik lokalny w ścieżce. w którym należy go umieścić na urządzeniu. Można się powtarzać. Jeśli kilka pliki są skonfigurowane tak, aby były przekazywane na tę samą ścieżkę zdalną, zostanie przesłany najnowszy.
- push: (wycofane) specyfikacja push w formacie
„
/path/to/srcfile.txt->/path/to/destfile.txt” lub „/path/to/srcfile.txt->/path/to/destdir/”. Można się powtarzać. Ścieżka ta może być względna do katalogu modułu testowego lub do katalogu do katalogu. - post-push: polecenie do uruchomienia na urządzeniu (z „
adb shell <your command>”) po wykonaniu wszystkich prób wypchnięcia. Typowe zastosowanie w przypadku użycia uprawnienia chmod
nazwa zajęć: InstallApkSetup
- short name:install-apk
- function: przenosi dowolne pliki APK do miejsca docelowego na urządzenie
- Opcje:
- nazwa-pliku-testowego: nazwa pakietu APK, na którym chcesz zainstalować plik urządzenia.
- install-arg: dodatkowe argumenty do przekazania do PM install z myślnikiem na początku, np. „-d”. Mogą się powtarzać
nazwa klasy: RunCommandTargetPreparer
- short name: run-command
- function: wykonuje dowolne polecenia powłoki przed testem lub po nim. wykonanie modułu
- Opcje:
- run-command:polecenie powłoki adb do uruchomienia. Mogą się powtarzać
- teardown-command: polecenie powłoki adb uruchamiane na etapie demontażu. Mogą się powtarzać
Zajęcia testowe
Klasa testowa to klasa federacji handlowej, która ma zostać użyta do przeprowadzenia 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 3 popularne klasy testów:
nazwa klasy: GTest
- short name (krótka nazwa): gtest
- function:test, który uruchamia natywny pakiet testowy na danym urządzeniu.
- Opcje:
- native-test-device-path: ścieżka na urządzeniu, na którym znajdują się testy natywne.
nazwa zajęć: InstrumentationTest
- short name:instrumentacja
- function:test, który uruchamia pakiet testowy narzędzi na danym urządzeniu.
- Opcje:
- package: nazwa pakietu manifestu aplikacji testowej na Androida, która ma zostać uruchomiona.
- class: nazwa klasy testowej do uruchomienia.
- method: nazwa metody testowej do uruchomienia.
nazwa zajęć: AndroidJUnitTest
- function:test, który uruchamia pakiet testów narzędziowych na danym na urządzeniu z Androidem.support.test.runner.AndroidJUnitRunner Jest to główny sposób wykonywania testu z instrumentacją.