Phát triển Bộ thử nghiệm lượt chuyển đổi (CTS)

Khởi chạy ứng dụng Repo

Hãy làm theo hướng dẫn trong phần Tải nguồn xuống để tải và tạo mã nguồn Android. Khi tạo lệnh repo init, hãy chỉ định 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 CTS của bạn được đưa vào trong các bản phát hành CTS tiếp theo.

Mã ví dụ sau đây cho thấy 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à bắt đầu tương tác Bảng điều khiển CTS (Bộ kiểm tra tính tương thích):

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Trong bảng điều khiển CTS, hãy nhập:

tf> run cts --plan CTS

Viết chương trình kiểm thử CTS

Thử nghiệm CTS sử dụng JUnit và API kiểm thử Android. Xem xét Thử nghiệm ứng dụng của bạn và các bài kiểm thử hiện có trong thư mục cts/tests. Các chương trình kiểm thử CTS chủ yếu tuân theo cùng một quy ước dùng trong các chương trình kiểm thử Android khác.

CTS chạy trên nhiều thiết bị sản xuất, nên các bài kiểm thử phải tuân theo các quy tắc sau:

  • Hãy 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, tránh tất cả các lớp, phương thức và trường bằng 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 những thành phần có thể không được thiết bị.
  • Đừng dựa vào đặc quyền gốc.

Thêm chú giải Java

Nếu quy trình kiểm thử của bạn xác minh một hành vi của API, hãy chú thích mã kiểm thử bằng @ApiTest và danh sách tất cả API có liên quan đến 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ó khoá-giá trị android.example.ClassB#methodB(KeyA) Chỉ sử dụng khi 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 thử nghiệm 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 quy trình 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ã yêu cầu đó (bao gồm cả Mục CDD) (mã nhận dạng và mã yêu cầu) với @CddTest trong mã kiểm thử CTS như được thể hiện trong ví dụ sau. Trong thông báo cam kết của bạn, hãy đề cập đến yêu cầu CDD nào được kiểm tra bởi kiểm thử bằng cách tham khảo mã yêu cầu của CDD. Mã yêu cầu CDD là sự kết hợp giữa mã mục và mã 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 của bạn bằng mã CDD có liên quan. Định dạng cho trường giá trị tương tự với định dạng của chú thích Java trong CTS (Bộ kiểm tra tính tương thích) Trong thông báo cam kết, hãy đề cập đến yêu cầu CDD được thực thi bằng cách tham chiếu đến CDD mã yêu cầu. 


  <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

Nêu rõ lý do bạn cần thêm thử nghiệm và thêm các đường liên kết liên quan để được hỗ trợ. Cho CTS-D các thử nghiệm này, hãy bao gồm liên kết đến đề xuất thử nghiệm mà bạn đã tạo trong Công cụ theo dõi lỗi của Google dưới dạng một phần của quy trình gửi bộ chứng nhận CTS-D.

Tạo kế hoạch phụ

Ví dụ: bạn có thể thêm tệp SubPlan.xml trong 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 gói phụ:

run cts --subplan aSubPlan

Định dạng mục nhập của 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í thử nghiệm

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 kiểm thử này có tên gói Java với 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 lượt kiểm thử, trong đó mỗi lượt kiểm thử thường kiểm thử một phương thức cụ thể của lớp được kiểm thử. Các chương trình kiểm thử này được sắp xếp theo một cấu trúc thư mục nơi các chương trình kiểm thử được nhóm thành các danh mục khác nhau, chẳng hạn như "tiện ích" hoặc "lượt xem".

Ví dụ: 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 các chương trình kiểm thử CTS là tên gói của lớp mà bài kiểm thử đang kiểm thử, theo sau là .cts. Ví dụ: tên gói sẽ là android.widget.cts.
  • Tên lớp
    Tên lớp cho thử nghiệm CTS là tên của lớp đang được kiểm thử bằng tuỳ chọn "Test" được thêm vào. Để Ví dụ: nếu kiểm thử nhắm đến TextView, thì tên lớp phải là TextViewTest.
  • Tên mô-đun (chỉ dành cho CTS phiên bản 2)
    CTS v2 tổ chức các bài 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ụ: widget).

Cấu trúc thư mục và mã mẫu phụ thuộc vào việc bạn có đang sử dụng CTS v1 hay không hoặc CTS phiên bản 2.

CTS phiên bản 1

Đối với Android 6.0 trở xuống, hãy sử dụng CTS v1. Đối với CTS v1, mã mẫu là ở cts/tests/tests/example.

Cấu trúc thư mục trong các bài 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 phiên bản 2

Đối với Android 7.0 trở lên, hãy sử dụng CTS v2. Để biết chi tiết, hãy xem 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 chương trình kiểm thử mới, có thể không có thư mục hiện có để đặt thử nghiệm. Trong những trường hợp đó, bạn cần tạo thư mục và sao chép tệp mẫu thích hợp.

CTS phiên bản 1

Nếu bạn đang sử dụng CTS v1, hãy tham khảo ví dụ trong cts/tests/tests/example rồi 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 đến CTS_COVERAGE_TEST_CASE_LIST inch cts/CtsTestCaseList.mk. build/core/tasks/cts.mk dùng tệp makefile này để kết hợp tất cả các bài kiểm thử và tạo gói CTS cuối cùng.

CTS phiên bản 2

Sử dụng kiểm thử mẫu /cts/tests/sample/ để bắt đầu nhanh mô-đun kiểm thử mới bằng các bước sau:

  1. Để tạo thư mục kiểm thử và sao chép tệp mẫu, hãy chạy mã: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Chuyển đến cts/tests/module-name và thay thế tất cả các bản sao của "[Ss]đa dạng" với quy ước đặt tên đề xuất nêu trên.
  3. Cập nhật SampleDeviceActivity để thực thi tính năng bạn đang kiểm thử.
  4. Cập nhật SampleDeviceTest để đảm bảo hoạt động thành công hoặc ghi nhật ký các lỗi của trang web đó.

Thư mục bổ sung

Các thư mục Android khác như assets, jni, Bạn cũng có thể thêm libs và res. Cách thêm mã JNI: tạo một thư mục trong gốc của dự án bên cạnh src bằng mã gốc và một tệp makefile Android.mk trong đó.

Tệp 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 trong thư mục gốc của dự án để tạo mã gốc và phụ thuộc vào mã đó, như sau:

# 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á thử nghiệm

Ngoài việc thêm các thử nghiệm mới, bạn có thể khắc phục hoặc xoá các kiểm thử được chú thích bằng BrokenTest hoặc KnownFailure.

Gửi các thay đổi

Khi gửi bản vá CTS hoặc VTS trong AOSP, hãy chọn nhánh phát triển của bạn dựa trên cấp độ API mà bản vá áp dụng.

  • Đối với những thay đổi áp dụng cho nhiều cấp độ API, trước tiên hãy phát triển một bản vá trong aosp/main rồi lựa chọn những bản vá tốt nhất nhánh kiểm thử ngược dòng. Cho phép trình tự động hợp nhất hợp nhất các thay đổi ở hạ nguồn trong Các nhánh kiểm thử AOSP. Xem Lịch phát hành và thông tin nhánh để biết danh sách nhánh và thông tin đường dẫn tự động hợp nhất.
  • Đối với các thay đổi dành riêng cho một cấp độ API cụ thể, hãy phát triển hoặc lựa chọn ưu tiên các thay đổi đối với nhánh kiểm thử chính xác bằng DO NOT MERGE (KHÔNG HỢP NHẤT) hoặc THOÁT ĐỘNG TỰ ĐỘNG HOÁ HẠN CHẾ trong thông báo cam kết.

Tuân thủ quy trình gửi bản vá để đóng góp các thay đổi cho CTS. Một người đánh giá sẽ được chỉ định để xem xét thay đổi của bạn cho phù hợp.

Thông tin về nhánh và lịch phát hành

Các bản phát hành CTS sẽ tuân theo lịch trình này.

Phiên bản Cấp độ API Chi nhánh Tần suất sao lưu
15 35 android15-tests-dev Hàng quý
14 34 android14-tests-dev Hàng quý
13 33 android13-tests-dev Hàng quý
12L 32 android12L-tests-dev Hàng quý
12 31 android12-tests-dev Hàng quý

Các ngày quan trọng trong thời gian phát hành

  • Kết thúc tuần đầu tiên: Mã bị treo. Các thay đổi đã được hợp nhất trong nhánh cho đến khi hệ thống xem xét tình trạng treo mã cho phiên bản CTS sắp tới. Gửi cho chi nhánh sau khi mã bị treo hoặc sau khi ứng cử viên cho bản phát hành được chọn, sẽ được xem xét cho bản phát hành tiếp theo.
  • Tuần thứ hai hoặc thứ ba:Nhà xuất bản CTS được xuất bản trong AOSP (Dự án nguồn mở Android).

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 tới mỗi nhánh tự động hợp nhất thành các nhánh cao hơn.

Đối với các thay đổi trực tiếp trên nhánh nhà phát triển thử nghiệm AOSP, đường dẫn tự động hợp nhất là:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Đối với những thay đổi chỉ dành cho phiên bản Android tiếp theo, đường dẫn tự động hợp nhất sẽ là:
aosp-main > <Internal git_main>.

Nếu danh sách thay đổi (CL) không hợp nhất chính xác, thì tác giả của bản vá sẽ được gửi email kèm theo hướng dẫn về cách giải quyết xung đột. Trong hầu hết trong trường hợp này, 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ũ yêu cầu thay đổi, thì bản vá cần phải được được chọn từ nhánh mới.