Cấu trúc tổng thể của cấu hình mô-đun tuân theo một mẫu tương tự như cấu hình XML Tradefed thông thường nhưng có một số hạn chế do thực tế là chúng chạy như một phần của bộ.
Danh sách các thẻ được phép
AndroidTest.xml hoặc cấu hình mô-đun nói chung chỉ có thể chứa các thẻ XML sau: target_preparer, multi_target_preparer, test và metrics_collector.
Mặc dù danh sách đó có vẻ hạn chế, nhưng nó cho phép bạn xác định chính xác các nhu cầu thiết lập mô-đun kiểm thử và kiểm thử để chạy.
LƯU Ý: Hãy xem phần Cấu hình XML Tradefed nếu bạn cần xem lại các thẻ khác nhau.
Các đối tượng như build_provider hoặc result_reporter sẽ tạo ra ConfigurationException nếu được cố gắng chạy từ bên trong cấu hình mô-đun. Điều này nhằm tránh kỳ vọng rằng những đối tượng này thực sự thực hiện một số tác vụ trong một mô-đun.
Ví dụ về cấu hình mô-đun
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Cấu hình này mô tả một quy trình kiểm thử yêu cầu phải cài đặt CtsGestureTestCases.apk và sẽ chạy một quy trình đo lường đối với gói android.gesture.cts.
Thẻ bao gồm <include> và <template-include>
Không nên sử dụng <include> và <template-include> trong cấu hình mô-đun. Chúng tôi không đảm bảo rằng các ứng dụng này sẽ hoạt động như mong đợi.
Trường hợp đặc biệt đối với thẻ metrics_collector
metrics_collector được phép nhưng chỉ giới hạn ở lớp FilePullerLogCollector để chỉ định một tệp hoặc thư mục nhất định cần được kéo và ghi nhật ký cho mô-đun. Điều này sẽ hữu ích nếu bạn đang lưu trữ nhật ký ở một vị trí cụ thể và muốn tự động khôi phục nhật ký.
Ví dụ về cấu hình:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
Còn thông tin bản dựng hoặc nội dung tải xuống thì sao?
Định nghĩa về các thẻ được phép có thể gây ấn tượng không chính xác rằng một mô-đun sẽ không nhận được bất kỳ thông tin nào về bản dựng. Điều này không đúng.
Thông tin bản dựng được cung cấp từ chế độ thiết lập cấp bộ và sẽ được tất cả các mô-đun của bộ chia sẻ. Điều này cho phép thiết lập một cấp cao nhất cho bộ để chạy tất cả các mô-đun thuộc bộ.
Ví dụ: thay vì mỗi mô-đun Bộ kiểm tra tính tương thích (CTS) truy vấn riêng thông tin, loại thiết bị, v.v., thì chế độ thiết lập cấp bộ CTS (cts.xml) sẽ thực hiện việc này một lần và mỗi mô-đun sẽ nhận được thông tin đó nếu chúng yêu cầu.
Để các đối tượng trong một mô-đun nhận được thông tin bản dựng, chúng cần thực hiện tương tự như trong cấu hình Tradefed thông thường: triển khai giao diện IBuildReceiver để nhận IBuildInfo. Hãy xem bài viết kiểm thử bằng thiết bị để biết thêm thông tin chi tiết.
Trường siêu dữ liệu
Một số lượng lớn các mô-đun kiểm thử bao gồm một số quy cách metadata, mỗi quy cách có một mục tiêu riêng.
Ví dụ:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
Thành phần
Siêu dữ liệu component mô tả thành phần Android chung mà mô-đun dự định kiểm thử. Thư mục này không ảnh hưởng trực tiếp đến quá trình thực thi kiểm thử; chủ yếu được dùng cho mục đích tổ chức.
Danh sách mới nhất về các thành phần được phép cho CTS có trong CtsConfigLoadingTest. Thử nghiệm này sẽ không thành công trong giai đoạn kiểm tra trước khi gửi nếu một thành phần không tồn tại được thêm vào mô-đun CTS.
Bạn có thể lọc một lần chạy bộ kiểm thử dựa trên các thành phần bằng cách sử dụng module-metadata-include-filter và module-metadata-exclude-filter.
Ví dụ:
--module-metadata-include-filter component framework
Ví dụ này chỉ chạy mô-đun kiểm thử được chú thích bằng thành phần framework.
Tham số
Siêu dữ liệu parameter là thông tin và ảnh hưởng đến quá trình thực thi kiểm thử. Tệp này chỉ định chế độ Android mà mô-đun kiểm thử áp dụng.
Trong trường hợp này, các chế độ bị giới hạn ở các chế độ Android cấp cao, chẳng hạn như instant apps, secondary users hoặc different abis.
Trong quá trình chạy bộ kiểm thử, nếu chế độ áp dụng cho kiểm thử, thì một số biến thể của mô-đun kiểm thử sẽ được tạo dựa trên chế độ đó. Mỗi biến thể chạy các kiểm thử tương tự nhưng ở các chế độ khác nhau.
instant_app: Tạo một biến thể của các kiểm thử cài đặt APK dưới dạng ứng dụng tức thì.multi_abi: Tạo một biến thể của các bài kiểm thử cho mỗi ABI mà thiết bị hỗ trợ.secondary_user: Tạo một biến thể của các kiểm thử cài đặt APK và chạy kiểm thử với tư cách là người dùng phụ.
Thu thập chỉ số và xử lý hậu kỳ cho các mô-đun kiểm thử hiệu suất
Đối với các mô-đun kiểm thử hiệu suất, bạn có thể dùng metrics_collector và metric_post_processor ở cấp mô-đun vì đây là những yếu tố cần thiết cho các kiểm thử hiệu suất.
Bộ thu thập chỉ số và bộ xử lý hậu kỳ ở cấp độ mô-đun có thể dành riêng cho mô-đun.
Bạn không nên chỉ định các trình xử lý hậu kỳ ở cả cấp cao nhất và cấp mô-đun.
Cấu hình mô-đun kiểm thử hiệu suất phải bao gồm siêu dữ liệu test-type có giá trị performance, chẳng hạn như: xml
<option name="config-descriptor:metadata" key="test-type" value="performance" /> Nếu không có siêu dữ liệu này, nếu cấu hình kiểm thử bao gồm metric_collector khác với FilePullerLogCollector hoặc bất kỳ metric_post_processor nào, thì kiểm thử sẽ không thành công trong giai đoạn trước khi gửi.
Ví dụ về cấu hình mô-đun kiểm thử hiệu suất:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>