Ten dokument zawiera szczegółowe instrukcje tworzenia modułów na wiele urządzeń oraz informacje o aktualnych ograniczeniach (jeśli są znane).
Przykład
Dostępny jest moduł CTS uwzględniający Wi-Fi z wieloma urządzeniami. 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/.
Opatrzyliśmy do przykładu tyle komentarzy, ile naszym zdaniem było 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. Na przykład: cts/hostsidetests/multidevices/. Zalecamy to, aby wszystkie moduły na wiele urządzeń pozostały w początkowo zgrupowane, co ułatwi odkrywanie 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 kodu
Niektóre moduły obsługujące wiele urządzeń 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 należy zdefiniować za pomocą reguły android_test w pliku Android.bp, tak jak w przypadku standardowej instrumentacji:
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 przeprowadzenia 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>
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 on podawany w milisekundach i dotyczy pełnego wykonania binarnego kodu Pythona (wszystkie przypadki testowe razem). 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. Przeprowadź 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 prawidłowym stanie. Polecenie adb
devices powinno podać listę połączonych urządzeń. Jeśli lista zawiera urządzenia nieprzeznaczone do testowania, wskaż je, używając 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, korzystając z narzędzia 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 się nie powiedzie podczas uruchamiania lokalnie z powodu:
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 ś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 są przeznaczone albo na wiele urządzeń, albo na jedno urządzenie. Nie ma modułów mieszanych. Jeśli spróbujesz uruchomić moduł dla wielu urządzeń bez użycia wielu urządzeń, zobaczysz ten błąd:
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.