CTS do nhà phát triển hỗ trợ

Trang này nêu các nguyên tắc sử dụng cho CTS do nhà phát triển cung cấp (CTS-D).

Kiểm tra vùng phủ sóng

CTS-D, giống như Trình xác minh CTS & 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 PHẢI có trong Tài liệu Định nghĩa Tương thích Android (CDD) đối với một cấp API nhất định.

Các yêu cầu KHÔNG PHẢI, chẳng hạn như ĐƯỢC KHUYẾN NGHỊ MẠNH, NÊN, CÓ THỂ, là tùy chọn và không thể kiểm tra bằng CTS.

Vì tất cả các yêu cầu về API và CDD đều được gắn với một cấp API cụ thể nên tất cả các thử nghiệm CTS (CTS, CTS-D và CTS Verifier) ​​đều được gắn với cùng cấp API với các API hoặc yêu cầu liên quan của chúng. Nếu một API cụ thể không được dùng nữa hoặc bị thay đổi thì thử nghiệm tương ứng của nó cũng phải được loại bỏ hoặc cập nhật.

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

  • Một bài kiểm tra phải tạo ra cùng một kết quả khách quan một cách nhất quán.
  • Quá trình kiểm tra phải xác định xem một thiết bị đạt hay không đạt bằng cách kiểm tra thiết bị đó ngay khi lấy ra khỏi hộp.
  • Người tạo thử nghiệm phải loại bỏ tất cả các yếu tố có thể ảnh hưởng đến kết quả thử nghiệm.
  • 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. Ví dụ về hướng dẫn thiết lập, hãy xem Thiết lập CTS .
  • Bài kiểm tra 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 đưa lý do vào đề xuất thử nghiệm của bạn để chúng tôi có thể xem xét.

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

  • Wifi ổn định (đối với thử nghiệm dựa trên Wifi).
  • Thiết bị vẫn đứng yên trong quá trình thử nghiệm (hoặc không, tùy thuộc vào thử nghiệm).
  • Thiết bị được rút khỏi bất kỳ nguồn điện nào có X phần trăm mức pin.
  • Không có ứng dụng, dịch vụ nền trước hoặc dịch vụ nền nào đang chạy, ngoại trừ CTS.
  • Màn hình tắt khi đang chạy CTS.
  • Thiết bị KHÔNG phải là isLowRamDevice .
  • Các hạn chế về trình tiết kiệm pin/ứng dụng vẫn chưa được thay đổi so với trạng thái “có sẵn”.

Tính đủ điều kiện kiểm tra

Chúng tôi chấp nhận các thử nghiệm mới thực thi một hành vi chưa được thử nghiệm bởi các thử nghiệm CTS, CTS Verifier hoặc CTS-D hiện có. Bất kỳ thử nghiệm nào kiểm tra hành vi nằm ngoài phạm vi kiểm tra của chúng tôi sẽ bị từ chối.

Quy trình nộp CTS

  1. Viết đề xuất thử nghiệm: Nhà phát triển ứng dụng gửi đề xuất thử nghiệm bằng cách sử dụng Google Issue Tracker , mô tả sự cố đã được xác định và đề xuất thử nghiệm để kiểm tra sự cố đó. Đề xuất phải bao gồm ID yêu cầu CDD liên quan. Nhóm Android xem xét đề xuất.
  2. Phát triển thử nghiệm CTS: Sau khi đề xuất được phê duyệt, người gửi đề xuất đó sẽ tạo thử nghiệm CTS trên AOSP trên nhánh chính (AOSP/main). Nhóm Android xem xét mã.
  3. Xuất bản thử nghiệm: Gửi CL của bạn trên AOSP/main và sau đó chọn nó đến nhánh androidx-tests-dev mới nhất. Bài kiểm tra hiện đã có sẵn công khai.

Hướng dẫn viết bài kiểm tra CTS-D

  • Thực hiện theo Hướng dẫn về kiểu mã Java .
  • Thực hiện theo tất cả các bước được mô tả trong CTS Development .
  • Thêm các bài kiểm tra của bạn vào kế hoạch kiểm tra thích hợp:
    • Sử dụng include-filters để thêm các thử nghiệm mới của bạn vào kế hoạch thử nghiệm CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml .
    • Sử dụng exclude-filters để loại trừ các thử nghiệm mới của bạn khỏi kế hoạch thử nghiệm 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 có errorprone trong build_error.log .
  • Rebase các thay đổi của bạn đối với head . Điều này bao gồm các kế hoạch kiểm tra cts-developer.xml và cts-developer-exclude.xml .
  • Làm việc với người liên hệ kỹ thuật của Google để xác định xem trường hợp thử nghiệm của bạn có thể được đưa vào mô-đun CTS hiện có hay không. Nếu không thể, họ sẽ giúp bạn tạo một mô-đun mới.
  • Đối với mỗi mô-đun thử nghiệm mới được tạo, hãy tạo tệp SỞ HỮU trong thư mục mô-đun thử nghiệm mới.
    • Tệp SỞ HỮU của bạn phải chứa thông tin sau, được lấy từ chủ sở hữu thử nghiệm của Google mà bạn đang làm việc cùng:
    • # Bug component: xxx
    • Chủ sở hữu thử nghiệm của Google ldap
  • Trong AndroidTest.xml , chỉ định các tham số sau. Tham khảo các tệp mẫu ( 1 , 2 ) để biết 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 pháp, lớp hoặc mô-đun kiểm tra mới, hãy thêm chúng vào kế hoạch kiểm tra CTS-D và loại chúng khỏi kế hoạch kiểm tra CTS chính theo cách tương tự như đối với các bài kiểm tra mới.

Chạy thử nghiệm CTS-D của bạn

Chạy kế hoạch kiểm tra 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 thử nghiệm 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 CTS đầy đủ, hãy xem Chạy thử nghiệm CTS .

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

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

Xem Lịch phát hành và thông tin chi nhánh để biết chi tiết về lịch phát hành CTS.