Niektóre moduły testów mogą wymagać niestandardowych czynności konfiguracyjnych i demontażu, których nie można wykonać w ramach samego przypadku testowego. 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 .
W ramach CTS wprowadziliśmy koncepcję konfiguracji modułu testowego, aby ułatwić wykonywanie takich zadań. Dzięki temu można wykonać wymienione powyżej typowe zadania za pomocą kilku linii konfiguracji. Aby uzyskać maksymalną elastyczność, możesz nawet wprowadzić własny cel, przygotowujący według definicji zawartej w ITargetPreparer lub ITargetCleaner, i skonfigurować je do użycia w konfiguracji Twojego modułu testowego.
Konfiguracja modułu testowego to wymagany plik XML dodany do najwyższego folderu źródłowego modułu o nazwie „AndroidTest.xml”. Plik XML jest zgodny z formatem pliku konfiguracyjnego używanego przez mechanizm automatyzacji testów Trade Federation. Obecnie główne tagi obsługiwane w konfiguracji modułu testowego to „target_preparer” i „test” .
Docelowi autorzy
Tag „target_preparer”, jak sugeruje nazwa, definiuje obiekt do przygotowywania docelowego (patrz ITargetPreparer), który udostępnia metodę konfiguracji wywoływaną przed wykonaniem modułu testowego. Jeśli klasa, do której odwołuje się tag „target_preparer”, implementuje też interfejs ITargetCleaner, to po zakończeniu modułu testowego zostanie wywołana jego metoda porządkowania.
Aby użyć wbudowanej wspólnej konfiguracji modułu, dodaj nowy plik „AndroidTest.xml” w folderze najwyższego poziomu modułu testowego i uzupełnij go o takie treści:
<?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. Aby zilustrować to za pomocą prostego przykładu, omówimy szczegółowo sposób korzystania z tagu „option”. Jak widać powyżej, tag może mieć 2 atrybuty: nazwę i wartość. Atrybut name musi odnosić się do jednej z opcji oferowanych przez autora.
Dokładny cel pola wartości zależy od tego, jak zdefiniowano tę opcję: może to być ciąg znaków, liczba, wartość logiczna lub nawet ścieżka do pliku. Oto podsumowanie 3 najczęstszych typów przygotowujących:
Nazwa klasy: PushFilePreparer
- krótka nazwa: push-file
- function: przesyła dowolne pliki z folderu test case do miejsca docelowego 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
- opcje:
- push-file: specyfikacja push, która określa lokalny plik na ścieżce, na którą ma zostać przesłany na urządzenie. 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 może być ścieżką względną do katalogu modułu testowego lub samego katalogu wyjściowego. - post-push: polecenie do wykonania na urządzeniu (z parametrem „
adb shell <your command>”) po wykonaniu wszystkich poleceń push. Typowe zastosowanie w przypadku użycia uprawnienia chmod
Nazwa klasy: InstallApkSetup
- short name:install-apk
- function: przesyła dowolne pliki APK do miejsca docelowego na urządzeniu
- options:
- nazwa-pliku-testowego: nazwa pliku APK, który ma zostać zainstalowany na urządzeniu;
- install-arg: dodatkowe argumenty do przekazania do PM install z myślnikiem na początku, np. „-d”. Może być powtarzany
nazwa klasy: RunCommandTargetPreparer
- krótka nazwa: run-command
- function: wykonuje dowolne polecenia powłoki przed lub po wykonaniu testu module.
- options:
- run-command:polecenie powłoki adb do uruchomienia. Może być powtarzany
- teardown-command: polecenie powłoki adb uruchamiane na etapie demontażu. Mogą się powtarzać
Klasa testowa
Klasa testu to klasa Federacji Handlu, której używa się 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 3 najczęstsze klasy testów:
Nazwa klasy: GTest
- short name (krótka nazwa): gtest
- function: test, który uruchamia natywny pakiet testów na danym urządzeniu.
- options:
- native-test-device-path: ścieżka na urządzeniu, na której znajdują się testy natywne.
nazwa zajęć: InstrumentationTest
- short name:instrumentacja
- function: test, który uruchamia pakiet testów z instrumentacją 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 testu do wykonania.
Nazwa klasy: 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ą.