Ten dokument zawiera szczegółowe instrukcje tworzenia modułów na wiele urządzeń oraz informacje o aktualnych ograniczeniach (jeśli są znane).
Przykład
Udostępniamy moduł CTS obsługujący Wi-Fi na wielu urządzeniach. Wysyła wiadomość z jednego urządzenia przez Wi-Fi i sprawdza, czy drugie urządzenie ją odbierz.
Źródło modułu znajduje się w folderze packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.
W przykładzie dodaliśmy tyle komentarzy, ile uznaliśmy za przydatne.
Krok 1. Utwórz folder modułu
Zalecamy utworzenie folderu dla modułu na wiele urządzeń w ramach projektu pakietu, do którego należy. Przykład: cts/hostsidetests/multidevices/. Zalecamy to ustawienie, aby przynajmniej na początku wszystkie moduły obsługiwały wiele urządzeń, co ułatwi znajdowanie przykładów.
Wszystkie pliki tego modułu powinny znajdować się w osobnym folderze modułu. Przykład: wifi_aware.
Krok 2. Utwórz test
Tutaj wdrażasz logikę testu. Jest to bardzo zależne od tego, co jest testowane.
Utwórz źródło testu Mobly, np. wifi_aware_test.py.
Krok 3. Utwórz plik kompilacji: Android.bp
Dodaj plik Android.bp, np. packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp. Zdefiniuj moduł python_test_host podobny do tego:
python_test_host {
name: "CtsWifiAwareTestCases",
main: "wifi_aware_test.py",
srcs: ["wifi_aware_test.py"],
test_suites: [
"cts",
"general-tests",
],
test_options: {
unit_test: false,
},
data: [
// Package the snippet with the mobly test
":wifi_aware_snippet",
],
}
Określ fragmenty testu za pomocą pola danych. Zostaną one zapakowane z binarnym plikiem i można je zlokalizować oraz zainstalować w teście za pomocą ATest lub w ramach ciągłego wykonywania.
Fragmenty kodu w pakiecie Mobly są dostępne na Androidzie na stronie external/mobly-bundled-snippets/.
Opcjonalnie: tworzenie niestandardowych fragmentów
Niektóre moduły wieloplatformowe mogą wymagać niestandardowych fragmentów kodu Mobly. Przykładowy test zawiera fragment kodu obsługujący Wi-Fi w pliku packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, który został utworzony za pomocą biblioteki fragmentów kodu Mobly, dostępnej w Androidzie w folderze external/mobly-snippet-lib/.
Fragment kodu powinien być zdefiniowany za pomocą reguły android_test w pliku Android.bp tak jak standardowe pomiary:
android_test {
name: "wifi_aware_snippet",
sdk_version: "current",
srcs: [
"CallbackUtils.java",
"WifiAwareSnippet.java",
],
manifest: "AndroidManifest.xml",
static_libs: [
"androidx.test.runner",
"guava",
"mobly-snippet-lib",
],
}
Krok 4. Utwórz konfigurację modułu: AndroidTest.xml
Dodaj plik AndroidTest.xml, np. packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml. W tej konfiguracji testowej musisz określić 2 urządzenia do testu, na przykład:
<configuration description="Config for CTS Wifi Aware test cases">
<option name="test-suite-tag" value="cts" />
<option name="config-descriptor:metadata" key="component" value="wifi" />
<option name="config-descriptor:metadata" key="parameter" value="not_instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="not_multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="not_secondary_user" />
<device name="device1">
<!-- For coverage to work, the APK should not be uninstalled until after coverage is pulled.
So it's a lot easier to install APKs outside the python code.
-->
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="test-file-name" value="wifi_aware_snippet.apk" />
</target_preparer>
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="input keyevent KEYCODE_WAKEUP" />
<option name="run-command" value="wm dismiss-keyguard" />
</target_preparer>
<target_preparer class="com.android.tradefed.targetprep.PythonVirtualenvPreparer">
<!-- Any python dependencies can be specified and will be installed with pip -->
<option name="dep-module" value="mobly" />
</target_preparer>
</device>
<device name="device2">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="test-file-name" value="wifi_aware_snippet.apk" />
</target_preparer>
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="input keyevent KEYCODE_WAKEUP" />
<option name="run-command" value="wm dismiss-keyguard" />
</target_preparer>
</device>
<test class="com.android.tradefed.testtype.mobly.MoblyBinaryHostTest">
<!-- The mobly-par-file-name should match the module name -->
<option name="mobly-par-file-name" value="CtsWifiAwareTestCases" />
<!-- Timeout limit in milliseconds for all test cases of the python binary -->
<option name="mobly-test-timeout" value="60000" />
</test>
</configuration>
Uwaga:
- Ten przykładowy test jest zależny od Mobly. W przypadku
PythonVirtualenvPreparermożna określić dowolną zależność, która zostanie zainstalowana za pomocą pip. - Wartość
mobly-par-file-namedlaMoblyBinaryHostTestmusi być zgodna z nazwą modułu w pliku Android.bp. - Pamiętaj, aby podać
mobly-test-timeoutna potrzeby testu. Jest ona wyrażona w milisekundach i ma zastosowanie do pełnego wykonania kodu binarnego Pythona (we wszystkich przypadkach testowych). Jest to konieczne, aby w przypadku niektórych problemów przypadki testowe nie były zawieszane na zawsze. - Każdy tag
devicemoże zawierać inną konfigurację na każdym urządzeniu. Konfiguracja Mobly otrzyma je w tej samej kolejności, w jakiej zostały określone w pliku XML.
Informacje związane z instalacją fragmentu kodu apk:
- Początkowy prototyp został zaktualizowany, aby instalować pakiety APK fragmentów kodu za pomocą narzędzia target_preparer. Zrobiliśmy to po rozmowie z zespołem ds. pokrycia. Aby zapewnić, że pomiary pokrycia nie zostaną usunięte zbyt wcześnie, odinstalowanie za pomocą narzędzia Harness zamiast kodu testowego w binarnych plikach Pythona zapewnia lepsze gwarancje dotyczące czasu.
Krok 5. Uruchom test lokalnie: atest
Obecnie testy na wielu urządzeniach są przeprowadzane tylko na urządzeniach fizycznych. Przed uruchomieniem testu sprawdź, czy urządzenia testowe są w odpowiednim stanie. Polecenie adb
devices powinno podać listę połączonych urządzeń. Jeśli lista zawiera urządzenia, które nie są przeznaczone do testowania, określ urządzenia do testowania za pomocą flagi -s.
W przypadku testów Wi-Fi sprawdź, czy Wi-Fi jest włączone na urządzeniach (po przywróceniu do ustawień fabrycznych).
Test możesz uruchomić lokalnie za pomocą atest:
$ atest CtsWifiAwareTestCases
Liczba urządzeń użytych w teście powinna być widoczna w nagłówku podsumowania w wyniku testu, np. Test executed with 2 device(s).
Rozwiązywanie problemów
Jeśli test nie uruchomi się lokalnie z tych powodów:
Błąd virtualenv
java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory
Upewnij się, że virtualenv znajduje się w ścieżce PATH. Dodanie „~/.local/bin” do ścieżki PATH powinno rozwiązać problem.
Jeśli nie masz zainstalowanego środowiska virtualenv, wykonaj instrukcje z tego artykułu: https://virtualenv.pypa.io/pl/latest/installation.html
Oczekiwano co najmniej 2 obiektów kontrolera, uzyskano 1
Moduły testowe dotyczą wielu urządzeń lub 1 urządzenia – nie ma żadnych połączonych modułów. Jeśli spróbujesz uruchomić moduł na wiele urządzeń bez wielu urządzeń, pojawi się ten komunikat o błędzie:
Expected to get at least 2 controller objects, got 1
Rozwiązaniem jest uruchomienie modułu w trybie wielu urządzeń.
CTS: możesz użyć fragmentacji, aby wywołać tę funkcję (np. --shard-count 2) lub run cts-multidevces.