Khởi chạy ứng dụng khách Repo
Hãy làm theo hướng dẫn trong bài viết Tải mã nguồn xuống để tải
và tạo mã nguồn Android. Khi đưa ra lệnh repo init, hãy chỉ định một nhánh CTS cụ thể bằng cách sử dụng -b. Điều này đảm bảo rằng các thay đổi của bạn đối với CTS sẽ được đưa vào các bản phát hành CTS tiếp theo.
Mã ví dụ sau đây cho biết cách sử dụng repo init.
mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8
Tạo và chạy CTS
Thực thi các lệnh sau để tạo CTS và khởi động bảng điều khiển CTS tương tác:
Tạo CTS (AOSP 14 trở xuống)
cd /path/to/android/rootsource build/envsetup.shmake cts -j32 TARGET_PRODUCT=aosp_arm64cts-tradefed
Tạo CTS (AOSP 15)
cd /path/to/android/rootsource build/envsetup.shmake cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release cts-tradefed
Vui lòng tham khảo bảng sau để chọn giá trị target-release:
| Cành cây | Bản phát hành mục tiêu |
|---|---|
| android15-tests-dev | ap3a |
Chạy CTS
Trong bảng điều khiển CTS, hãy nhập:
tf> run cts --plan CTS
Viết mã kiểm thử CTS
Mã kiểm thử CTS sử dụng JUnit và các API kiểm thử Android. Hãy xem hướng dẫn
Kiểm thử
ứng dụng
và các mã kiểm thử hiện có trong thư mục cts/tests.
Mã kiểm thử CTS chủ yếu tuân theo các quy ước tương tự được dùng trong các mã kiểm thử Android khác.
CTS chạy trên nhiều thiết bị sản xuất, vì vậy, mã kiểm thử phải tuân theo các quy tắc sau:
- Tính đến các kích thước màn hình, hướng và bố cục bàn phím khác nhau.
- Chỉ sử dụng các phương thức API công khai. Nói cách khác, hãy tránh tất cả các lớp, phương thức và trường
có chú thích
hide. - Tránh sử dụng bố cục khung hiển thị hoặc dựa vào kích thước của các thành phần có thể không có trên một số thiết bị.
- Không dựa vào đặc quyền gốc.
Thêm chú thích Java
Nếu mã kiểm thử của bạn xác minh hành vi của API, hãy chú thích mã kiểm thử bằng @ApiTest và liệt kê
tất cả các API liên quan trong trường apis. Hãy sử dụng định dạng thích hợp trong số các ví dụ
sau:
| Loại API | Định dạng chú thích | Ghi chú |
|---|---|---|
| Phương thức | android.example.ClassA#methodA |
Trường hợp sử dụng phổ biến nhất. |
| Phương thức có giá trị khoá | android.example.ClassB#methodB(KeyA) |
Chỉ sử dụng khi mã kiểm thử của bạn sử dụng một phương thức API để xác thực một trường, như trong ví dụ này. |
| Trường | android.example.ClassC#FieldA |
Chỉ sử dụng khi mã kiểm thử của bạn xác thực trực tiếp một trường API, như trong ví dụ này. |
Nếu mã kiểm thử của bạn xác minh một yêu cầu của CDD, hãy chú thích mã nhận dạng yêu cầu (bao gồm cả Mã nhận dạng phần CDD
và Mã nhận dạng yêu cầu) bằng @CddTest trong mã kiểm thử CTS như minh hoạ trong ví dụ
sau. Trong thông báo xác nhận, hãy đề cập đến yêu cầu CDD nào được mã kiểm thử của bạn
kiểm thử bằng cách tham khảo mã nhận dạng yêu cầu CDD. Mã nhận dạng yêu cầu CDD là sự kết hợp của mã nhận dạng phần
và mã nhận dạng yêu cầu, được kết nối bằng dấu gạch chéo (/) như trong 7.3.1/C-1-1.
/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
@CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
public void testAddPasspointConfigWithUserCredential() throws Exception {
if (!WifiFeature.isWifiSupported(getContext())) {
// skip the test if WiFi is not supported
return;
} testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
}
Đối với Trình xác minh CTS, hãy chú thích từng Hoạt động trong AndroidManifest.xml bằng
mã nhận dạng CDD có liên quan. Các định dạng cho trường giá trị tương tự như định dạng của chú thích Java trong
CTS. Trong thông báo xác nhận, hãy đề cập đến yêu cầu CDD
nào được thực thi bằng cách tham khảo mã nhận dạng yêu cầu CDD.
<activity>
......
<!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
<meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />
<!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
<meta-data android:name="api_test"
android:value="com.example.MyClass#myMethod" />
<!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
<meta-data android:name="non_compliance_test"
android:value="detailed reasons" />
</activity>
Trong thông báo xác nhận
Hãy đề cập rõ ràng lý do bạn cần thêm mã kiểm thử và thêm các đường liên kết có liên quan để được hỗ trợ. Đối với mã kiểm thử CTS-D tests, hãy thêm đường liên kết đến đề xuất kiểm thử mà bạn đã tạo trong Google Trình theo dõi sự cố trong quy trình gửi CTS-D.
Tạo kế hoạch phụ
Ví dụ: bạn có thể thêm tệp SubPlan.xml vào android-cts/subplans như sau:
<?xml version="1.0" encoding="utf-8" standalone="no"?> <SubPlan version="2.0"> <Entry include="CtsSystemIntentTestCases" /> <Entry include="CtsSystemUiHostTestCases" /> <Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" /> <Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" /> </SubPlan>
Cách chạy kế hoạch phụ:
run cts --subplan aSubPlan
Định dạng mục nhập kế hoạch phụ là:
Include a module name as follows: <Entry include="MODULE_NAME" /> Include a package: <Entry include="MODULE_NAME PACKAGE_NAME" /> Include a class: <Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" /> Include an individual test: <Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />
Tên và vị trí kiểm thử
Hầu hết các trường hợp kiểm thử CTS đều nhắm đến một lớp cụ thể trong API Android. Các mã kiểm thử này có tên gói Java có hậu tố cts và tên lớp có hậu tố Test. Mỗi trường hợp kiểm thử bao gồm nhiều mã kiểm thử, trong đó mỗi mã kiểm thử thường thực thi một phương thức cụ thể của lớp đang được kiểm thử.
Các mã kiểm thử này được sắp xếp theo cấu trúc thư mục, trong đó các mã kiểm thử được nhóm thành nhiều danh mục như "tiện ích" hoặc "khung hiển thị".
Ví dụ: mã kiểm thử CTS cho gói Java
android.widget.TextView là
android.widget.cts.TextViewTest với tên gói Java là
android.widget.cts và tên lớp là
TextViewTest.
- Tên gói Java
Tên gói Java cho mã kiểm thử CTS là tên gói của lớp mà mã kiểm thử đang kiểm thử, theo sau là.cts. Đối với ví dụ của chúng tôi, tên gói sẽ làandroid.widget.cts. - Tên lớp
Tên lớp cho mã kiểm thử CTS là tên của lớp đang được kiểm thử, có thêm "Test". Ví dụ: nếu một mã kiểm thử nhắm đếnTextView, thì tên lớp phải làTextViewTest. - Tên mô-đun (chỉ CTS v2)
CTS v2 sắp xếp các mã kiểm thử theo mô-đun. Tên mô-đun thường là chuỗi thứ hai của tên gói Java (trong ví dụ của chúng tôi,widget).
Cấu trúc thư mục và mã mẫu phụ thuộc vào việc bạn đang sử dụng CTS v1 hay CTS v2.
CTS v1
Đối với Android 6.0 trở xuống, hãy sử dụng CTS v1. Đối với CTS v1, mã mẫu nằm ở cts/tests/tests/example.
Cấu trúc thư mục trong mã kiểm thử CTS v1 có dạng như sau:
cts/
tests/
tests/
package-name/
Android.mk
AndroidManifest.xml
src/
android/
package-name/
SampleDeviceActivity.java
cts/
SampleDeviceTest.java
CTS v2
Đối với Android 7.0 trở lên, hãy sử dụng CTS v2. Để biết thông tin chi tiết, hãy xem mã kiểm thử mẫu trong Dự án nguồn mở Android (AOSP).
Cấu trúc thư mục CTS v2 có dạng như sau:
cts/
tests/
module-name/
Android.mk
AndroidManifest.xml
src/
android/
package-name/
SampleDeviceActivity.java
cts/
SampleDeviceTest.java
Gói mẫu mới
Khi thêm mã kiểm thử mới, có thể không có thư mục hiện có để đặt mã kiểm thử của bạn. Trong những trường hợp đó, bạn cần tạo thư mục và sao chép các tệp mẫu thích hợp.
CTS v1
Nếu bạn đang sử dụng CTS v1, hãy tham khảo ví dụ trong cts/tests/tests/example và tạo một thư mục mới. Ngoài ra,
hãy nhớ thêm tên mô-đun của gói mới từ Android.mk
vào CTS_COVERAGE_TEST_CASE_LIST trong
cts/CtsTestCaseList.mk. build/core/tasks/cts.mk sử dụng makefile
này để kết hợp tất cả các mã kiểm thử và tạo gói CTS cuối cùng.
CTS v2
Sử dụng mã kiểm thử mẫu
/cts/tests/sample/
để nhanh chóng bắt đầu mô-đun kiểm thử mới theo các bước sau:
- Để tạo thư mục kiểm thử và sao chép các tệp mẫu, hãy chạy:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
- Chuyển đến
cts/tests/module-namevà thay thế tất cả các thực thể của "[Ss]ample" bằng quy ước đặt tên được đề xuất ở trên. - Cập nhật
SampleDeviceActivityđể thực thi tính năng bạn đang kiểm thử. - Cập nhật
SampleDeviceTestđể đảm bảo rằng hoạt động thành công hoặc ghi lại các lỗi của hoạt động đó.
Thư mục bổ sung
Bạn cũng có thể thêm các thư mục Android khác như assets, jni, libs và res.
Để thêm mã JNI, hãy tạo một thư mục ở gốc của dự án bên cạnh src bằng mã gốc và một makefile Android.mk trong đó.
Makefile thường chứa các chế độ cài đặt sau:
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := libCtsSample_jni # don't include this package in any target LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := list of source code files LOCAL_C_INCLUDES := $(JNI_H_INCLUDE) # Tag this module as a cts test artifact LOCAL_COMPATIBILITY_SUITE := cts LOCAL_SHARED_LIBRARIES := libnativehelper LOCAL_SDK_VERSION := current include $(BUILD_SHARED_LIBRARY)
Tệp Android.mk
Cuối cùng, hãy sửa đổi tệp Android.mk ở gốc của dự án để tạo mã gốc và phụ thuộc vào mã đó, như minh hoạ bên dưới:
# All tests should include android.test.runner. LOCAL_JAVA_LIBRARIES := android.test.runner # Includes the jni code as a shared library LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni # Include for InstrumentationCtsTestRunner LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner... LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE) #Tells make to look in subdirectories for more make files to include include $(call all-makefiles-under,$(LOCAL_PATH))
Khắc phục hoặc xoá mã kiểm thử
Ngoài việc thêm mã kiểm thử mới, bạn có thể khắc phục hoặc xoá các mã kiểm thử được chú thích bằng BrokenTest hoặc KnownFailure.
Gửi nội dung thay đổi của bạn
Hãy làm theo quy trình Gửi nội dung thay đổi mã workflow khi đóng góp các thay đổi cho CTS.
- Chọn nhánh phát triển dựa trên các cấp độ API mà bản vá áp dụng.
- Phát triển hoặc chọn riêng các thay đổi cho nhánh kiểm thử chính xác bằng DO NOT MERGE (KHÔNG HỢP NHẤT) hoặc RESTRICT AUTOMERGE (HẠN CHẾ TỰ ĐỘNG HỢP NHẤT) trong thông báo xác nhận.
Một người xem xét sẽ được chỉ định để xem xét thay đổi của bạn và chọn riêng thay đổi đó vào Gerrit nội bộ cho phù hợp.
Lịch phát hành và thông tin về nhánh
Các bản phát hành CTS tuân theo lịch này.
| Phiên bản | Cấp độ API | Nhánh phát triển | Tần suất phát hành |
|---|---|---|---|
| 16+ | 36+ | Gerrit nội bộ | Hằng quý |
| 15 | 35 | android15-tests-dev | Hằng quý |
| 14 | 34 | android14-tests-dev | Hằng quý |
| 13 | 33 | android13-tests-dev | Hằng quý |
Các ngày quan trọng trong quá trình phát hành
- Cuối tuần đầu tiên: Khoá mã. Các thay đổi được hợp nhất trong nhánh cho đến khi khoá mã được xem xét cho phiên bản CTS sắp tới. Các nội dung gửi đến nhánh sau khi khoá mã hoặc sau khi chọn ứng viên cho bản phát hành sẽ được xem xét cho bản phát hành tiếp theo.
- Tuần thứ hai hoặc thứ ba: CTS được xuất bản trên trang tải xuống Bộ kiểm tra tính tương thích.
Quy trình tự động hợp nhất
Các nhánh phát triển CTS đã được thiết lập để các thay đổi được gửi đến từng nhánh tự động hợp nhất với các nhánh cao hơn.
Đối với các thay đổi trực tiếp đối với nhánh phát triển kiểm thử AOSP, đường dẫn tự động hợp nhất là:
android13-tests-dev >
android14-tests-dev >
android15-tests-dev
- Đối với các phiên bản CTS 16+, người xem xét sẽ chọn riêng thay đổi đó vào Gerrit nội bộ cho phù hợp.
Nếu danh sách thay đổi (CL) không hợp nhất đúng cách, thì tác giả của bản vá sẽ nhận được email hướng dẫn cách giải quyết xung đột. Trong hầu hết các trường hợp, tác giả của bản vá có thể sử dụng hướng dẫn để bỏ qua quá trình tự động hợp nhất CL xung đột.
Nếu một nhánh cũ hơn yêu cầu thay đổi, thì bản vá cần được chọn riêng từ nhánh mới hơn.
Đối với các thay đổi đối với mã kiểm thử áp dụng cho phiên bản Android tiếp theo, sau khi bạn tải nội dung thay đổi đề xuất lên, Google sẽ xem xét nội dung đó và nếu được chấp nhận, sẽ chọn riêng nội dung đó vào Gerrit nội bộ.