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ự thành cấu hình XML Tradefeed thông thường nhưng có một số hạn chế do mà chúng chạy như một phần của một bộ sản phẩm.
Danh sách thẻ được phép
Cấu hình mô-đun rộng từ AndroidTest.xml trở lê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à bài kiểm thử để chạy.
LƯU Ý: Hãy xem phần Cấu hình XML được trao đổi 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
ConfigurationException nếu chạy từ bên trong một mô-đun
. Điều này nhằm tránh kỳ vọng rằng
các đối tượng thực sự thực hiện tác vụ nào đó từ bên trong một mô-đun.
Cấu hình mô-đun mẫu
<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 chương trình kiểm thử yêu cầu CtsGestureTestCases.apk
sẽ được cài đặt và chạy đo lường dựa trên android.gesture.cts
.
Thẻ bao gồm <include> và <template-include>
Việc sử dụng <include> và <template-include> trong cấu hình mô-đun là
không khuyến khích. Tuy nhiên, chúng không được đảm bảo hoạt động như mong đợi.
Trường hợp đặc biệt cho thẻ chỉ_collector
metrics_collector được phép nhưng giới hạn ở
FilePullerLogCollector
để chỉ định một tệp hoặc thư mục nhất định để kéo và ghi nhật ký
mô-đun. Cách này rất hữu ích nếu bạn để nhật ký ở một vị trí cụ thể và
muốn khôi phục chúng một cách tự động.
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 hiển thị không chính xác mà 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 qua quá trình thiết lập cấp bộ và sẽ được chia sẻ bởi tất cả mô-đun của bộ ứng dụng. Điều này cho phép bạn thiết lập một cấp cao nhất cho bộ ứng dụng để chạy tất cả các phần mô-đun của bộ ứng dụng.
Ví dụ: thay vì mỗi
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. CTS
chế độ thiết lập cấp phòng (cts.xml) thực hiện việc này một lần và mỗi mô-đun sẽ nhận được mã đó
nếu họ 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
để thực hiện tương tự như trong cấu hình Tradefeed thông thường: triển khai
Giao diện IBuildReceiver để nhận IBuildInfo. Xem
kiểm thử bằng 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 kiểm thử có chứa một số thông số kỹ thuật metadata,
mỗi loại lại 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 cho mô-đun
dự định thử nghiệm. Không ảnh hưởng trực tiếp đến quá trình chạy kiểm thử; đó là
chủ yếu được sử 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 của CTS có trong CtsConfigLoadingTest. Kiểm thử này không thành công trong phần gửi trước 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 loạt chương trình 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ú giải bằng framework
thành phần.
Thông số
Siêu dữ liệu parameter chỉ nhằm cung cấp thông tin và ảnh hưởng đến thử nghiệm
thực thi. Trường này chỉ định chế độ Android mà mô-đun kiểm thử sẽ á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 khi chạy bộ công cụ, nếu chế độ này áp dụng cho thử nghiệm, một vài biến thể của mô-đun kiểm thử đượ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 biến thể của các bài kiểm thử cài đặt APK dưới dạng ứng dụng tức thì.multi_abi: Tạo biến thể bài kiểm thử cho từng ABI mà thiết bị.secondary_user: Tạo biến thể của các bài 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 tra hiệu suất
Đối với các mô-đun kiểm thử hiệu suất, metrics_collector cấp mô-đun và
Bạn có thể dùng metric_post_processor vì đây là thành phần cần thiết trong các chương trình kiểm thử hiệu suất.
Bộ thu thập chỉ số và bộ xử lý bài đăng ở cấp mô-đun có thể cụ thể theo từng mô-đun.
Bạn không nên chỉ định bộ xử lý bài đăng ở 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ó thuộc tính này, nếu cấu hình kiểm thử bao gồm metric_collector ngoại trừ
FilePullerLogCollector hoặc metric_post_processor bất kỳ, phép kiểm thử
không thành công ở phần 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>