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 Tradefed XML 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 một bộ.
Danh sách các thẻ được phép
Cấu hình mô-đun AndroidTest.xml hoặc rộng hơn chỉ có thể chứa các thẻ XML sau: target_preparer , multi_target_preparer , test 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 thử nghiệm và thử nghiệm sẽ chạy.
LƯU Ý: Xem cấu hình Tradefed XML 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ẽ đưa ra một ConfigurationException nếu 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 các đối tượng này thực sự thực hiện một số nhiệm vụ từ bên trong một mô-đun.
Cấu hình mô-đun ví dụ
<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 thử nghiệm yêu cầu cài đặt CtsGestureTestCases.apk và sẽ chạy một công cụ đo lường dựa trên 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 không được đảm bảo hoạt động như mong đợi.
Trường hợp đặc biệt cho thẻ số liệu_collector
Cho phép metrics_collector nhưng giới hạn ở lớp FilePullerLogCollector để chỉ định một tệp hoặc thư mục nhất định sẽ được kéo và ghi lại cho mô-đun. Điều này 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 chúng.
Cấu hình ví dụ:
<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 của các thẻ được phép có thể gây ấn tượng không chính xác rằng mô-đun sẽ không nhận được bất kỳ thông tin bản dựng nào. Đây không phải là sự thật .
Thông tin bản dựng được cung cấp từ thiết lập cấp bộ và sẽ được chia sẻ bởi tất cả các mô-đun của bộ. Điều này cho phép một thiết lập cấp cao nhất cho bộ phần mềm để chạy tất cả các phần mô-đun của bộ phần mềm.
Ví dụ: thay vì mỗi mô-đun Bộ kiểm tra tương thích (CTS) truy vấn riêng lẻ thông tin, loại thiết bị, v.v., thiết lập cấp bộ CTS ( cts.xml ) sẽ thực hiện việc đó 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ô-đ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 . Xem thử nghiệm với thiết bị để biết thêm chi tiết.
Trường siêu dữ liệu
Một số lượng lớn mô-đun thử nghiệm bao gồm một số thông số metadata , mỗi mô-đun này 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 thử nghiệm. Nó không có bất kỳ tác động trực tiếp nào đến việc thực hiện kiểm thử; nó chủ yếu được sử dụng cho mục đích tổ chức.
Danh sách cập nhật các thành phần được phép cho CTS có sẵn trong CtsConfigLoadingTest . Thử nghiệm này không thành công khi gửi trước nếu 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 bộ ứng dụng 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 thử nghiệm được chú thích bằng thành phần framework .
Tham số
Siêu dữ liệu parameter mang tính thông tin và tác động đến việc thực hiện kiểm thử. Nó chỉ định chế độ Android nào mà mô-đun thử nghiệm áp dụng. Trong trường hợp này, các chế độ được 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ộ phần mềm, nếu chế độ áp dụng cho thử nghiệm, một số biến thể của mô-đun thử nghiệm sẽ được tạo dựa trên chế độ đó. Mỗi biến thể chạy các thử nghiệm tương tự nhưng ở các chế độ khác nhau.
-
instant_app: Tạo một biến thể của thử nghiệm 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 thử nghiệm cho từng ABI được thiết bị hỗ trợ. -
secondary_user: Tạo một biến thể của các thử nghiệm cài đặt APK và chạy thử nghiệm với tư cách là người dùng phụ.
Thu thập số liệu 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 tra hiệu suất, được phép sử metrics_collector và metric_post_processor ở cấp độ mô-đun vì chúng cần thiết cho các thử nghiệm hiệu suất. Bộ thu thập số liệu và bộ xử lý hậu kỳ ở cấp mô-đun có thể dành riêng cho mô-đun. Không nên chỉ định bộ xử lý hậu kỳ ở cả cấp cao nhất và cấp mô-đun.
Cấu hình mô-đun kiểm tra hiệu suất phải bao gồm siêu dữ liệu test-type có giá trị performance , như: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Nếu không có điều này, nếu kiểm tra config bao gồm metric_collector không phải là FilePullerLogCollector hoặc bất kỳ metric_post_processor nào, thì quá trình kiểm tra sẽ không thành công khi gửi trước.
Ví dụ về cấu hình mô-đun kiểm tra 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>