Ten dokument zawiera szczegółowe instrukcje, jak utworzyć wiele urządzeń modułów i informuje o aktualnych ograniczeniach, jeśli są one znane.
Przykład
Dostępny jest moduł CTS uwzględniający Wi-Fi z wieloma urządzeniami. Wysyła wiadomość z jednego przez sieć Wi-Fi i sprawdzić, czy odbiera ono drugie urządzenie.
Źródło tego modułu to: packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.
Opatrzyliśmy do przykładu tyle komentarzy, ile naszym zdaniem było przydatne.
Krok 1. Utwórz folder modułu
Zaleca się utworzenie folderu dla modułu obsługi wielu urządzeń w pakiecie projektu, do którego należy. Przykład: cts/hostsidetests/multidevices/. Zalecamy to ustawienie, aby wszystkie moduły obsługiwały wiele urządzeń co ułatwi znajdowanie przykładów.
Wszystkie pliki związane z tym modułem powinny znajdować się w osobnym folderze modułu. Dla:
przykład: wifi_aware.
Krok 2. Utwórz test
Tutaj implementujesz logikę testową. który w dużym stopniu zależy od tego, które są testowane.
Utwórz źródło testu Mobly, na przykład: 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",
],
}
W polu danych wskaż fragmenty kodu do przetestowania, które będą zawierać: pliku binarnego i można go zlokalizować i zainstalować w teście za pomocą ATest lub Ciągłe wykonywanie.
Fragmenty kodu w pakiecie Mobly są dostępne na Androidzie na external/mobly-bundled-snippets/.
Opcjonalnie: tworzenie niestandardowych fragmentów kodu
Niektóre moduły obsługujące wiele urządzeń mogą wymagać niestandardowych fragmentów kodu Mobly. Przykładowy test zawiera fragment kodu uwzględniający Wi-Fi na stronie packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, która została stworzona z wykorzystaniem Mobly Snippet Lib, który jest dostępny na Androida pod adresem: external/mobly-snippet-lib/.
Fragment kodu należy zdefiniować w pliku Android.bp regułą android_test w postaci: instrumentacja standardowa:
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 taki jak: packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml. W tej konfiguracji testowej musisz określić 2 urządzenia do testu: podobne do:
<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>
Pamiętaj, że:
- Ten przykładowy test zależy od Mobly. Możesz określić dowolną zależność
dla aplikacji
PythonVirtualenvPrepareri zostanie zainstalowane za pomocą pip. - Parametr
mobly-par-file-nameforMoblyBinaryHostTestmusi być zgodny z modułem na przykład Android.bp. - Określ
mobly-test-timeoutna potrzeby testu. Jest wyrażona w milisekundach, dotyczy pełnego wykonania pliku binarnego Pythona (we wszystkich przypadkach testowych). Jest to konieczne, aby uniknąć zawieszenia na zawsze przypadków testowych w przypadku pewnych problemów. - Każdy tag
devicemoże zawierać odrębną konfigurację na każdym urządzeniu – The Mobly. config otrzyma je w kolejności określonej w pliku XML.
Powiązany z fragmentem kodu apk Instalacja:
- Początkowa osoba kontaktowa została zaktualizowana, aby instalować fragment kodu apks za pomocą target_preparer w związku z rozmową z zespołem ds. ochrony danych: aby mieć pewność, pomiary zasięgu nie są usuwane zbyt wcześnie, odinstalowywanie przez Harness niż za pomocą kodu testowego w plikach binarnych Pythona, co dają większe gwarancje czas.
Krok 5. Przeprowadź test lokalnie: atest
Obecnie testy na wielu urządzeniach działają tylko na urządzeniach fizycznych. Przed uruchomieniem
, sprawdź, czy urządzenia testowe są w odpowiednim stanie. Polecenie adb
devices powinno zgłosić listę połączonych urządzeń. Jeśli lista zawiera
urządzenia nieprzeznaczone do testowania, wskaż urządzenia do testu za pomocą -s
flaga.
Na potrzeby testów Wi-Fi upewnij się, że na urządzeniach jest włączona sieć Wi-Fi (po przywróceniu ustawień fabrycznych).
Test możesz uruchomić lokalnie, korzystając z narzędzia atest:
$ atest CtsWifiAwareTestCases
Liczba używanych urządzeń powinna być widoczna w nagłówku podsumowania w teście
danych wyjściowych, 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 jest w PATH. Dodanie „~/.local/bin” do PATH powinno
napraw to.
jeśli nie masz zainstalowanego virtualenv, postępuj zgodnie z instrukcjami: https://virtualenv.pypa.io/en/latest/installation.html
Oczekiwano co najmniej 2 obiektów kontrolera, uzyskano 1
Moduły testowe dotyczą wielu urządzeń albo jednego urządzenia. Nie ma złożone z modułów mieszanych. Jeśli próbujesz uruchomić moduł obejmujący wiele urządzeń bez urządzeń, na których zobaczysz ten błąd:
Expected to get at least 2 controller objects, got 1
Problem można rozwiązać, uruchamiając moduł w trybie wielu urządzeń.
W przypadku CTS: aby aktywować tę funkcję, możesz użyć fragmentacji (na przykład: --shard-count 2)
lub run cts-multidevces.