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 đã trao đổi nếu bạn cần ôn lại kiến thức về các thẻ khác nhau.
Các đối tượng như build_provider hoặc result_reporter sẽ tạo ra một 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 kỳ vọng rằng 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ộ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 bài 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ẻ metric_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 sẽ hữu ích nếu bạn đang để 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?
Định nghĩa về các thẻ được phép có thể gây ra ấ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 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 thiết lập cấp cao nhất duy nhất cho bộ ứng dụng để chạy tất cả các phần mô-đun của bộ công cụ.
Ví dụ: thay vì mỗi mô-đun Bộ kiểm tra tính tương thích (CTS) truy vấn riêng từng thông tin thiết bị, loại, v.v., quy 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 có 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ử có một số thông số kỹ thuật metadata, mỗi mô-đun 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.
Bạn có thể truy cập danh sách mới nhất về các thành phần được phép của CTS 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ế độ chỉ 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 biến thể của các bài 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 biến thể của các bài kiểm thử cài đặt tệp APK và chạy chương trình kiểm thử với tư cách là người dùng phụ.
Thu thập và xử lý sau chỉ số 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 phép sử dụng metrics_collector và metric_post_processor ở cấp mô-đun vì chúng cần thiết cho việ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>