Cấu trúc tổng thể của cấu hình mô-đun tuân theo 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 các cấu hình này chạy trong một bộ.
Danh sách thẻ được phép
AndroidTest.xml hoặc cấu hình mô-đun rộng hơn 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 nhu cầu thiết lập mô-đun kiểm thử và kiểm thử cần chạy.
LƯU Ý: Hãy xem phần Cấu hình XML Tradefed nếu bạn cần ôn lại các thẻ khác nhau.
Các đối tượng như build_provider hoặc result_reporter sẽ tăng ConfigurationException nếu bạn cố gắng chạy từ bên trong cấu hình mô-đun. Điều này nhằm tránh việc các đối tượng này thực sự thực hiện một số tác vụ từ bên trong 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 kiểm thử yêu cầu cài đặt CtsGestureTestCases.apk và sẽ chạy một hoạt động đo lường dựa trên gói android.gesture.cts.
Thẻ bao gồm <include> và <template-include>
Bạn 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 tính năng này sẽ hoạt động như mong đợi.
Trường hợp đặc biệt cho thẻ metrics_collector
metrics_collector được phép nhưng 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 cho mô-đun. Điều này rất hữu ích nếu bạn để nhật ký ở một vị trí cụ thể và muốn tự động khôi phục nhật ký.
Cấu hình mẫu:
<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?
Việc định nghĩa về các thẻ được phép có thể gây ra hiển thị không chính xác rằng một mô-đun sẽ không nhận được bất kỳ thông tin bản dựng nào. Đ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ả mô-đun của bộ chia sẻ. Điều này cho phép một chế độ thiết lập cấp cao nhất cho bộ công cụ để chạy tất cả các mô-đun trong bộ công cụ.
Ví dụ: thay vì mỗi mô-đun Bộ kiểm thử khả năng tương thích (CTS) truy vấn riêng thông tin, loại thiết bị, v.v., thì quá trình thiết lập cấp bộ CTS (cts.xml) sẽ thực hiện một lần và mỗi mô-đun sẽ nhận được thông tin đó nếu yêu cầu.
Để các đối tượng trong mô-đun nhận được thông tin bản dựng, các đối tượng đó cần làm như trong cấu hình Tradefed thông thường: triển khai giao diện IBuildReceiver để nhận IBuildInfo. Hãy xem phần 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 mô-đun kiểm thử bao gồm một số thông số kỹ thuật metadata, mỗi thông số kỹ thuật 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ử. Phương thứ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. Kiểm thử này không thành công khi gửi trước nếu một thành phần không tồn tại được thêm vào mô-đunCTS.
Bạn có thể lọc một bộ sản phẩm chạy 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.
Thông 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, 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 bài kiểm thử tương tự nhau nhưng ở các chế độ khác nhau.
instant_app: Tạo một biến thể của các chương trình kiểm thử cài đặt tệp 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 từng 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ử dưới dạng người dùng phụ.
Thu thập chỉ số và xử lý hậu kỳ cho các mô-đun kiểm tra hiệu suất
Đối với các mô-đun kiểm thử hiệu suất, metrics_collector và metric_post_processor ở cấp mô-đun được cho phép vì chúng rấ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 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 với giá trị performance, chẳng hạn như: xml
<option name="config-descriptor:metadata" key="test-type" value="performance" /> Nếu không, 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ì quá trình kiểm thử sẽ không thành công trong quá trình gửi trước.
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>