Ten dokument zawiera instrukcje krok po kroku dotyczące tworzenia modułów obsługujących wiele urządzeń i opisuje aktualne ograniczenia, jeśli są znane.
Próbka
Dostępny jest moduł CTS obsługujący wiele urządzeń. Wysyła wiadomość z jednego urządzenia przez Wi-Fi i sprawdza, czy drugie urządzenie ją odbiera.
Źródło modułu znajduje się pod adresem package/modules/Wifi/tests/hostsidetests/muldevices/test/aware/ .
Do przykładu dodaliśmy tyle komentarzy, ile uznamy za przydatne.
Krok 1: Utwórz folder modułu
Zaleca się utworzenie folderu dla modułu obsługi wielu urządzeń w projekcie pakietu, do którego należy. Na przykład: cts/hostsidetests/multidevices/ . Zalecamy, aby przynajmniej na początku wszystkie moduły obsługujące wiele urządzeń pozostały kolokowane, co ułatwi odnalezienie przykładów.
Wszystkie pliki tego modułu należy umieścić w osobnym folderze modułu. Na przykład: wifi_aware .
Krok 2: Utwórz test
Tutaj implementujesz logikę testową. Zależy to w dużej mierze od tego, co jest testowane.
Utwórz źródło testowe Mobly, takie jak: wifi_aware_test.py .
Krok 3: Utwórz plik kompilacji: Android.bp
Dodaj plik Android.bp, taki jak package/modules/Wifi/tests/hostsidetests/muldevices/test/Android.bp . Zdefiniuj moduł python_test_host, podobny do:
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, które zostaną spakowane w pliku binarnym i mogą zostać zlokalizowane i zainstalowane w teście przez ATest lub w trybie ciągłego wykonywania.
Mobly Bundled Snippets są dostępne w systemie Android pod adresem external/mobly-bundled-snippets/ .
Opcjonalnie: utwórz niestandardowe fragmenty
Niektóre moduły obsługujące wiele urządzeń mogą wymagać niestandardowych fragmentów Mobly. Przykładowy test zawiera fragment obsługujący Wi-Fi w pakietach/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java , który jest zbudowany przy użyciu Mobly Snippet Lib, dostępnego w systemie Android pod adresem: external /mobly-snippet-lib/ .
Fragment powinien być zdefiniowany za pomocą reguły android_test w Android.bp, podobnie jak standardowe instrumenty:
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 package/modules/Wifi/tests/hostsidetests/muldevices/test/aware/AndroidTest.xml . W tej konfiguracji testowej musisz określić dwa urządzenia do testu, podobnie jak:
<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>
Zauważ, że:
- Ten przykładowy test jest zależny od Mobly. Dla
PythonVirtualenvPreparermożna określić dowolną zależność i zostanie ona zainstalowana za pomocą pip. -
mobly-par-file-namedlaMoblyBinaryHostTestmusi być zgodna z nazwą modułu, jak w Android.bp. - Określ
mobly-test-timeoutdla testu. Podawana jest w milisekundach i dotyczy pełnego wykonania binarnego Pythona (łącznie wszystkich przypadków testowych). Jest to potrzebne, aby uniknąć zawieszenia przypadków testowych na zawsze w przypadku niektórych problemów. - Każdy znacznik
devicemoże zawierać odrębną konfigurację na każdym urządzeniu. Konfiguracja Mobly otrzyma je w tej samej kolejności, jak określono w pliku XML.
Powiązane z instalacją fragmentu apk:
- Początkowy POC został zaktualizowany w celu instalowania fragmentów aplikacji za pośrednictwem target_preparer w wyniku rozmowy z zespołem ds. pokrycia: Aby mieć pewność, że pomiary zasięgu nie zostaną usunięte zbyt wcześnie, odinstalowanie przez Harness, a nie przez kod testowy w plikach binarnych Pythona, zapewnia lepszą gwarancję czasu.
Krok 5: Uruchom test lokalnie: atest
Obecnie testy na wielu urządzeniach działają tylko na urządzeniach fizycznych. Przed uruchomieniem testu sprawdź, czy urządzenia testowe są w odpowiednim stanie. Polecenie adb devices powinno zgłosić listę podłączonych urządzeń. Jeśli lista zawiera urządzenia nieprzeznaczone do testowania, określ urządzenia do testu za pomocą flagi -s.
W przypadku testów Wi-Fi upewnij się, że Wi-Fi jest włączone dla urządzeń (po przywróceniu ustawień fabrycznych).
Możesz uruchomić test lokalnie za pomocą atest:
$ atest CtsWifiAwareTestCases
Powinieneś zobaczyć liczbę urządzeń użytych w nagłówku podsumowania w wynikach testu, coś w rodzaju Test executed with 2 device(s) .
Rozwiązywanie problemów
Jeśli test zakończy się niepowodzeniem podczas działania lokalnego z powodu:
Błąd Virtualenv
java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory
Upewnij się, że virtualenv znajduje się w Twojej ścieżce. Dodanie „~/.local/bin” do PATH powinno to naprawić. jeśli virtualenv nie jest zainstalowany, wykonaj następujące czynności: https://virtualenv.pypa.io/en/latest/installation.html
Oczekiwano uzyskania co najmniej 2 obiektów kontrolera, otrzymano 1
Moduły testowe obejmują wiele urządzeń lub jedno urządzenie, nie ma modułów mieszanych. Jeśli spróbujesz uruchomić moduł obsługujący wiele urządzeń bez wielu urządzeń, zobaczysz ten błąd:
Expected to get at least 2 controller objects, got 1
Uruchomienie modułu w trybie wielu urządzeń rozwiąże problem.
W przypadku CTS: możesz użyć shardingu, aby go uruchomić (na przykład: --shard-count 2) lub run cts-multidevces .