CTS do nhà phát triển cung cấp

Trang này trình bày các nguyên tắc sử dụng Bộ kiểm tra tính tương thích (CTS) do nhà phát triển cung cấp (CTS-D).

Phạm vi kiểm thử

CTS-D, giống như CTS và Trình xác minh CTS, chỉ có thể thực thi những điều sau:

  • Tất cả các API công khai được mô tả trong SDK dành cho nhà phát triển (developer.android.com) cho một cấp độ API nhất định.
  • Tất cả các yêu cầu BẮT BUỘC có trong Tài liệu định nghĩa về khả năng tương thích (CDD) với Android cho một cấp độ API nhất định.

Các yêu cầu không BẮT BUỘC, chẳng hạn như NÊN, CÓ THỂ, RẤT NÊN, là không bắt buộc và không thể kiểm thử bằng CTS.

Vì tất cả các API và yêu cầu CDD đều được liên kết với một cấp độ API cụ thể, nên tất cả các bài kiểm thử CTS (CTS, CTS-D và Trình xác minh CTS) đều được liên kết với cùng một cấp độ API như các API hoặc yêu cầu được liên kết. Nếu một API cụ thể bị ngừng sử dụng hoặc thay đổi, thì bài kiểm thử tương ứng của API đó phải bị ngừng sử dụng hoặc cập nhật.

Quy tắc tạo bài kiểm thử CTS

  • Bài kiểm thử phải luôn cho ra cùng một kết quả khách quan.
  • Bài kiểm thử phải xác định xem một thiết bị có đạt hay không bằng cách kiểm thử thiết bị đó một lần ngay khi mở hộp.
  • Người tạo bài kiểm thử phải loại bỏ tất cả các yếu tố có thể ảnh hưởng đến kết quả kiểm thử.
  • Nếu một thiết bị cần một điều kiện/môi trường/thiết lập phần cứng nhất định, thì thiết lập đó phải được xác định rõ ràng trong thông báo cam kết. Để biết hướng dẫn thiết lập mẫu, hãy xem phần Thiết lập CTS.
  • Bài kiểm thử không được chạy quá 6 giờ mỗi lần. Nếu cần chạy lâu hơn, vui lòng nêu lý do trong đề xuất kiểm thử để chúng tôi có thể xem xét.

Sau đây là một ví dụ về tập hợp các điều kiện kiểm thử để kiểm thử một quy định hạn chế đối với ứng dụng:

  • Wi-Fi ổn định (đối với bài kiểm thử dựa vào Wi-Fi).
  • Thiết bị vẫn đứng yên trong quá trình kiểm thử (hoặc không, tuỳ thuộc vào bài kiểm thử).
  • Thiết bị được rút khỏi mọi nguồn điện khi mức pin là X phần trăm.
  • Không có ứng dụng, dịch vụ trên nền trước hoặc dịch vụ trên nền sau nào đang chạy, ngoại trừ CTS.
  • Màn hình tắt khi chạy CTS.
  • Thiết bị KHÔNG phải là isLowRamDevice.
  • Trình tiết kiệm pin / quy định hạn chế đối với ứng dụng không thay đổi so với trạng thái "ngay khi mở hộp".

Điều kiện kiểm thử

Chúng tôi chấp nhận các bài kiểm thử mới thực thi một hành vi mà các bài kiểm thử CTS, Trình xác minh CTS hoặc CTS-D hiện có không kiểm thử. Mọi bài kiểm thử kiểm tra một hành vi nằm ngoài phạm vi kiểm thử của chúng tôi sẽ bị từ chối.

Quy trình gửi CTS

  1. Viết đề xuất kiểm thử: Nhà phát triển ứng dụng gửi đề xuất kiểm thử bằng Trình theo dõi sự cố của Google, mô tả vấn đề đã xác định và đề xuất một bài kiểm thử để kiểm tra vấn đề đó. Đề xuất phải bao gồm mã nhận dạng yêu cầu CDD được liên kết. Nhóm Android xem xét đề xuất.
  2. Phát triển bài kiểm thử CTS: Sau khi đề xuất được phê duyệt, người gửi sẽ tạo bài kiểm thử CTS trên AOSP trên nhánh phát hành mới nhất của Android (android17-release). Nhóm Android xem xét mã và nếu được chấp nhận, sẽ chọn thay đổi và hợp nhất thay đổi đó vào nhánh phát triển nội bộ. Để biết thông tin chi tiết, hãy xem bài viết Tôi nên đề xuất thay đổi đối với AOSP ở đâu?.

Nguyên tắc viết bài kiểm thử CTS-D

  • Tuân theo Hướng dẫn về kiểu mã Java.
  • Tuân theo tất cả các bước được mô tả trong Phát triển CTS.
  • Thêm bài kiểm thử vào kế hoạch kiểm thử thích hợp:
    • Sử dụng include-filters để thêm bài kiểm thử mới vào kế hoạch kiểm thử CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Sử dụng exclude-filters để loại trừ bài kiểm thử mới khỏi kế hoạch kiểm thử CTS chính: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Xử lý tất cả các cảnh báo và đề xuất errorprone trong build_error.log.
  • Đổi cơ sở các thay đổi của bạn thành head. Điều này bao gồm các kế hoạch kiểm thử cts-developer.xml và cts-developer-exclude.xml.
  • Phối hợp với người liên hệ phụ trách kỹ thuật của Google để xác định xem trường hợp kiểm thử của bạn có thể được đưa vào mô-đun CTS hiện có hay không. Nếu không, họ sẽ giúp bạn tạo một mô-đun mới.
  • Đối với mỗi mô-đun kiểm thử mới được tạo, hãy tạo một tệp OWNERS trong thư mục mô-đun kiểm thử mới.
    • Tệp OWNERS của bạn phải chứa thông tin sau, lấy từ chủ sở hữu bài kiểm thử của Google mà bạn đang làm việc cùng:
    • # Bug component: xxx
    • Ldap của chủ sở hữu bài kiểm thử của Google
  • Trong AndroidTest.xml, hãy chỉ định các tham số sau. Tham khảo các tệp mẫu (1, 2) để xem ví dụ:
    • Instant_app hoặc not_instant_app
    • secondary_user hoặc not_secondary_user
    • all_foldable_states hoặc no_foldable_states
  • Để chỉ định minSDK chính xác, hãy tham khảo tài liệu <uses-sdk>.
  • Khi kiểm tra các phương thức, lớp hoặc mô-đun kiểm thử mới, hãy thêm chúng vào kế hoạch kiểm thử CTS-D và loại trừ chúng khỏi kế hoạch kiểm thử CTS chính theo cách tương tự như đối với các bài kiểm thử mới.

Chạy bài kiểm thử CTS-D

Chạy kế hoạch kiểm thử CTS-D từ dòng lệnh bằng cách sử dụng run cts --plan cts-developer.

Để chạy một trường hợp kiểm thử cụ thể, hãy sử dụng run cts --include-filter "test_module_name test_name".

Để biết thông tin về cách chạy toàn bộ CTS, hãy xem bài viết Chạy bài kiểm thử CTS.

Chấp nhận và phát hành

Sau khi bạn gửi yêu cầu kiểm thử, một nhóm nội bộ sẽ xem xét yêu cầu đó để đảm bảo yêu cầu đó kiểm thử một yêu cầu CDD hoặc hành vi API được ghi lại. Nếu xác định được rằng bài kiểm thử đang kiểm tra một yêu cầu hoặc hành vi hợp lệ, thì nhóm sẽ chuyển trường hợp kiểm thử này cho một kỹ sư của Google để xem xét thêm. Kỹ sư của Google sẽ liên hệ với bạn để phản hồi về cách cải thiện bài kiểm thử trước khi bài kiểm thử đó có thể được chấp nhận vào CTS.

Hãy xem bài viết Lịch phát hành và thông tin về nhánh để biết thông tin chi tiết về lịch phát hành CTS.