Moduły na wiele urządzeń

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. Przykład: cts/hostsidetests/multidevices/. Zalecamy to, aby wszystkie moduły na wiele urządzeń były przynajmniej na początku umieszczone w pobliżu, 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, 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, np.:

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 mogą być zlokalizowane oraz zainstalowane w teście przez 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 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 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 taki jak: 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>

Pamiętaj, że:

  • Ten przykładowy test jest zależny od Mobly. Możesz określić dowolną zależność dla aplikacji PythonVirtualenvPreparer i zostanie zainstalowane za pomocą pip.
  • Parametr mobly-par-file-namefor MoblyBinaryHostTest musi być zgodny z modułem na przykład Android.bp.
  • Określ mobly-test-timeout na potrzeby testu. Jest on podawany w milisekundach i dotyczy pełnego wykonania kodu binarnego Pythona (wszystkich przypadków testowych razem). Jest to konieczne, aby w przypadku niektórych problemów przypadki testowe nie były zawieszane na zawsze.
  • Każdy tag device może zawierać odmienną 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 dotyczące instalacji pakietu APK kodu krótkiego:

  • 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 są przeprowadzane tylko na urządzeniach fizycznych. Przed uruchomieniem testu 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.

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 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 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 znajduje się w ścieżce 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 są przeznaczone albo na wiele urządzeń, albo na jedno urządzenie. Nie ma mieszanych 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

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.