W tym dokumencie znajdziesz szczegółowe instrukcje tworzenia modułów na wiele urządzeń oraz informacje o aktualnych ograniczeniach.
Próbka
Dostępny jest moduł CTS obsługujący wiele urządzeń z funkcją Wi-Fi Aware. 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ę w packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.
Przykład został opatrzony jak największą liczbą komentarzy, które naszym zdaniem są przydatne.
Krok 1. Utwórz folder modułu
Zalecamy utworzenie folderu dla modułu obsługującego wiele urządzeń w projekcie pakietu, do którego należy. Na przykład: cts/hostsidetests/multidevices/. Zalecamy to, aby wszystkie moduły na wiele urządzeń pozostały na początku w tym samym miejscu, co ułatwi znajdowanie przykładów.
Wszystkie pliki tego modułu powinny znajdować się w jego folderze. Przykład: wifi_aware.
Krok 2. Utwórz test
W tym miejscu możesz zaimplementować logikę testu. Zależy to w dużym stopniu 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, podobnie jak w tym przykładzie:
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 kodu do testu za pomocą pola danych, które zostanie spakowane z plikiem binarnym i może zostać zlokalizowane oraz zainstalowane w teście przez ATest lub w ramach ciągłego wykonywania.
Fragmenty kodu Mobly Bundled Snippets są dostępne w Androidzie pod adresem external/mobly-bundled-snippets/.
Opcjonalnie: tworzenie niestandardowych rozszerzeń
Niektóre moduły na wiele urządzeń mogą wymagać niestandardowych fragmentów kodu Mobly. Przykładowy test zawiera fragment kodu dotyczący Wi-Fi Aware w lokalizacji packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, który jest tworzony za pomocą biblioteki Mobly Snippet Lib dostępnej w Androidzie w lokalizacji: external/mobly-snippet-lib/.
Fragment kodu powinien być zdefiniowany za pomocą reguły android_test w pliku Android.bp, np.: standardowa instrumentacja:
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 testu musisz określić 2 urządzenia, np.:
<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 test przykładowy 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-namew przypadkuMoblyBinaryHostTestmusi być zgodna z nazwą modułu w pliku Android.bp. - Określ
mobly-test-timeouttestu. Jest on podawany w milisekundach i dotyczy pełnego wykonania binarnego pliku Pythona (wszystkich przypadków testowych razem). Jest to konieczne, aby uniknąć zawieszania się przypadków testowych w przypadku wystąpienia problemów. - 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.
Powiązane z instalacją pliku APK fragmentu kodu:
- Początkowy dowód koncepcji został zaktualizowany, aby instalować pakiety APK fragmentów kodu za pomocą parametru target_preparer ze względu na rozmowę z zespołem ds. pokrycia: aby mieć pewność, że pomiary pokrycia nie zostaną usunięte zbyt wcześnie, odinstalowywanie przez Harness zamiast przez kod testowy w plikach binarnych Pythona daje lepsze gwarancje pod względem 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 zwrócić listę połączonych urządzeń. Jeśli lista zawiera urządzenia, które nie są przeznaczone 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 na urządzeniach (po przywróceniu ustawień fabrycznych).
Możesz uruchomić test lokalnie za pomocą polecenia atest:
$ atest CtsWifiAwareTestCases
W nagłówku podsumowania w danych wyjściowych atestu powinna być widoczna liczba używanych urządzeń, np. Test executed with 2 device(s).
Rozwiązywanie problemów
Jeśli test przeprowadzany lokalnie nie powiedzie się 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 zmiennej PATH. Dodanie „~/.local/bin” do ścieżki PATH powinno rozwiązać ten problem.
Jeśli nie masz zainstalowanego środowiska wirtualnego, postępuj zgodnie z instrukcjami na stronie https://virtualenv.pypa.io/en/latest/installation.html
Oczekiwano co najmniej 2 obiektów kontrolera, a uzyskano 1
Moduły testowe są wielourządzeniowe lub jednourządzeniowe. Nie ma modułów mieszanych. Jeśli spróbujesz uruchomić moduł obsługujący wiele urządzeń bez wielu urządzeń, pojawi się ten błąd:
Expected to get at least 2 controller objects, got 1
Wykonanie modułu w trybie wielu urządzeń rozwiąże ten problem.
W przypadku CTS możesz użyć fragmentacji, aby wywołać test (np. --shard-count 2) lub run cts-multidevces.