Mô-đun nhiều thiết bị

Tài liệu này cung cấp hướng dẫn từng bước về cách tạo mô-đun nhiều thiết bị và nêu ra các giới hạn hiện tại (nếu có).

Mẫu

Một mô-đun nhiều thiết bị nhận biết Wi-Fi của CTS được cung cấp. Mô-đun này gửi một thông báo từ một thiết bị qua Wi-Fi và xác minh rằng thiết bị kia nhận được thông báo đó.

Nguồn cho mô-đun này nằm tại packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.

Chúng tôi đã chú thích ví dụ này bằng nhiều nhận xét nhất có thể để bạn dễ hiểu.

Bước 1: Tạo thư mục mô-đun

Bạn nên tạo một thư mục cho mô-đun nhiều thiết bị trong dự án bộ kiểm thử mà mô-đun đó thuộc về. Ví dụ: cts/hostsidetests/multidevices/. Bạn nên làm như vậy để tất cả mô-đun nhiều thiết bị vẫn được đặt cùng nhau ít nhất là lúc đầu, giúp bạn dễ dàng tìm thấy các ví dụ hơn.

Tất cả tệp cho mô-đun này phải được đặt trong thư mục mô-đun riêng của chúng. Ví dụ: wifi_aware.

Bước 2: Tạo quy trình kiểm thử

Đây là nơi bạn triển khai logic kiểm thử. Logic này phụ thuộc rất nhiều vào nội dung được kiểm thử.

Tạo nguồn kiểm thử Mobly, chẳng hạn như: wifi_aware_test.py.

Bước 3: Tạo tệp bản dựng: Android.bp

Thêm tệp Android.bp như packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp. Xác định một mô-đun python_test_host, tương tự như:

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",
    ],
}

Chỉ định các đoạn mã cho quy trình kiểm thử bằng trường dữ liệu. Trường này sẽ được đóng gói bằng tệp nhị phân và có thể được ATest tìm và cài đặt trong quy trình kiểm thử hoặc trong quá trình thực thi Liên tục.

Các đoạn mã được gói Mobly có trong Android tại external/mobly-bundled-snippets/.

Không bắt buộc: Tạo đoạn mã tuỳ chỉnh

Một số mô-đun nhiều thiết bị có thể yêu cầu các đoạn mã Mobly tuỳ chỉnh. Quy trình kiểm thử mẫu bao gồm một đoạn mã nhận biết Wi-Fi tại packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, đoạn mã này được xây dựng bằng Thư viện đoạn mã Mobly, có trong Android tại: external/mobly-snippet-lib/.

Đoạn mã phải được xác định bằng quy tắc android_test trong Android.bp như đo lường tiêu chuẩn:

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",
    ],
}

Bước 4: Tạo cấu hình mô-đun: AndroidTest.xml

Thêm tệp AndroidTest.xml như packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml. Trong cấu hình kiểm thử này, bạn cần chỉ định 2 thiết bị cho quy trình kiểm thử, tương tự như:

<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>

Lưu ý:

  • Quy trình kiểm thử mẫu này có phần phụ thuộc vào Mobly. Bạn có thể chỉ định mọi phần phụ thuộc cho PythonVirtualenvPreparer và sẽ được cài đặt bằng pip.
  • mobly-par-file-name cho MoblyBinaryHostTest phải khớp với tên mô-đun như trong Android.bp.
  • Hãy chỉ định mobly-test-timeout cho quy trình kiểm thử. Giá trị này tính bằng mili giây và áp dụng cho toàn bộ quá trình thực thi tệp nhị phân Python (tất cả trường hợp kiểm thử cùng nhau). Điều này là cần thiết để tránh các trường hợp kiểm thử bị treo vĩnh viễn trong trường hợp gặp một số vấn đề.
  • Mỗi thẻ device có thể chứa một chế độ thiết lập riêng biệt trên mỗi thiết bị. Cấu hình Mobly sẽ nhận các thẻ này theo cùng một thứ tự như được chỉ định trong XML.

Liên quan đến việc cài đặt apk đoạn mã:

  • POC ban đầu đã được cập nhật để cài đặt apk đoạn mã thông qua target_preparer do cuộc trò chuyện với nhóm Mức độ sử dụng mã: Để đảm bảo các phép đo mức độ sử dụng mã không bị xoá quá sớm, việc gỡ cài đặt bằng Harness thay vì bằng mã kiểm thử trong tệp nhị phân Python sẽ đảm bảo tốt hơn về mặt thời gian.

Bước 5: Chạy quy trình kiểm thử cục bộ: atest

Hiện tại, quy trình kiểm thử nhiều thiết bị chỉ chạy trên các thiết bị thực. Trước khi chạy quy trình kiểm thử, hãy xác minh rằng các thiết bị kiểm thử của bạn ở trạng thái thích hợp. Lệnh adb devices sẽ báo cáo danh sách các thiết bị đã kết nối của bạn. Nếu danh sách chứa các thiết bị không dành cho việc kiểm thử, hãy chỉ định các thiết bị cho quy trình kiểm thử bằng cách sử dụng cờ -s.

Đối với các quy trình kiểm thử Wi-Fi, hãy đảm bảo rằng Wi-Fi được bật cho các thiết bị (sau khi đặt lại về trạng thái ban đầu).

Bạn có thể chạy quy trình kiểm thử cục bộ bằng atest:

$ atest CtsWifiAwareTestCases

Bạn sẽ thấy số lượng thiết bị được sử dụng trong tiêu đề tóm tắt trong đầu ra atest, chẳng hạn như Test executed with 2 device(s).

Khắc phục sự cố

Nếu quy trình kiểm thử không thành công khi chạy cục bộ do:

Lỗi Virtualenv

java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory

Vui lòng đảm bảo virtualenv nằm trong PATH của bạn. Việc thêm "~/.local/bin" vào PATH sẽ khắc phục vấn đề này. Nếu bạn chưa cài đặt virtualenv, hãy làm theo hướng dẫn tại: https://virtualenv.pypa.io/en/latest/installation.html

Dự kiến nhận được ít nhất 2 đối tượng bộ điều khiển, nhưng thực tế chỉ nhận được 1

Các mô-đun kiểm thử là mô-đun nhiều thiết bị hoặc một thiết bị, không có mô-đun hỗn hợp. Nếu bạn cố chạy một mô-đun nhiều thiết bị mà không có nhiều thiết bị, bạn sẽ thấy lỗi này:

Expected to get at least 2 controller objects, got 1

Việc thực thi mô-đun ở chế độ nhiều thiết bị sẽ giải quyết vấn đề này.

Đối với CTS: Bạn có thể sử dụng phân mảnh để kích hoạt (Ví dụ: --shard-count 2) hoặc run cts-multidevces.