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 CTS do nhà phát triển cung cấp (CTS-D).

Kiểm thử phạm vi

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

  • Tất 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 về khả năng tương thích với Android (CDD) 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ư STRONGLY RECOMMENDED (RẤT KHUYÊN DÙNG), SHOULD (NÊN), MAY (THỂ), là không bắt buộc và không thể kiểm thử bằng CTS.

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

Quy tắc tạo thử nghiệm CTS

  • Một kiểm thử phải tạo ra kết quả khách quan giống nhau một cách nhất quán.
  • Quy trình 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 xuất xưởng.
  • Người tạo thử nghiệm phải loại bỏ mọi yếu tố có thể ảnh hưởng đến kết quả thử nghiệm.
  • Nếu 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ì chế độ thiết lập đó phải được xác định rõ ràng trong thông báo cam kết. Để biết ví dụ về hướng dẫn thiết lập, hãy xem bài viết Thiết lập CTS.
  • Mỗi lần chạy, kiểm thử không được chạy quá 6 giờ. Nếu cần chạy trong thời gian dài hơn, vui lòng đưa lý do vào đề xuất kiểm thử của bạn để chúng tôi có thể xem xét.

Sau đây là một bộ điều kiện kiểm thử mẫu để kiểm thử một hạn chế của ứng dụng:

  • Wi-Fi đang ổn định (đối với thử nghiệm dựa vào Wi-Fi).
  • Thiết bị đứng yên trong quá trình thử nghiệm (hoặc không đứng yên, tuỳ thuộc vào thử nghiệm).
  • Thiết bị đã rút phích cắm khỏi nguồn điện bất kỳ với mức pin X%.
  • Không có ứng dụng, dịch vụ trên 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 trong khi chạy CTS.
  • Thiết bị KHÔNG phải là isLowRamDevice.
  • Các quy tắc hạn chế về trình tiết kiệm pin / ứng dụng không thay đổi từ trạng thái "mới cài đặt".

Điều kiện xét nghiệm

Chúng tôi chấp nhận các chương trình kiểm thử mới thực thi một hành vi không được kiểm thử bằng các chương trình kiểm thử CTS, CTS Verifier hoặc CTS-D hiện có. Mọi kiểm thử kiểm tra hành vi nằm ngoài phạm vi mức độ bao phủ 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 Công cụ theo dõi lỗi của Google, mô tả vấn đề đã được xác định và đề xuất một kiểm thử để kiểm tra vấn đề đó. Đề xuất phải bao gồm mã yêu cầu CDD liên quan. Nhóm Android sẽ xem xét đề xuất.
  2. Phát triển kiểm thử CTS: Sau khi đề xuất được phê duyệt, người gửi sẽ tạo một kiểm thử CTS trên AOSP trên nhánh chính (AOSP/main). Nhóm Android xem xét mã.
  3. Xuất bản kiểm thử: Gửi CL trên AOSP/main rồi chọn một số thay đổi trong đó để đưa vào nhánh androidx-tests-dev mới nhất. Bài kiểm thử này hiện đã được cung cấp công khai.

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

  • Tuân theo Hướng dẫn về kiểu mã Java.
  • Làm theo tất cả các bước được mô tả trong phần Phát triển CTS.
  • Thêm các chương trình kiểm thử vào kế hoạch kiểm thử thích hợp:
    • Sử dụng include-filters để thêm các chương trình 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ừ các 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ảnh báo và đề xuất errorprone trong build_error.log.
  • Đặt lại các thay đổi của bạn thành head. Bao gồm cả kế hoạch kiểm thử cts-developer.xml và cts-developer-exclude.xml.
  • Làm việc 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 các thông tin sau, lấy từ chủ sở hữu kiểm thử của Google mà bạn đang làm việc:
    • # Bug component: xxx
    • LDAP chủ sở hữu kiểm thử của Google
  • Trong AndroidTest.xml, hãy chỉ định các tham số sau. Hãy 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 đúng minSDK, hãy tham khảo tài liệu về <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 các phương thức, lớp hoặc mô-đun đó 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 chương trình kiểm thử mới.

Chạy kiểm thử CTS-D

Chạy kế hoạch kiểm thử CTS-D từ dòng lệnh bằ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 phần Chạy 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 của CDD hoặc hành vi API được ghi nhận. Nếu xác định được kiểm thử đang kiểm tra một yêu cầu hoặc hành vi hợp lệ, nhóm sẽ chuyển tiếp trường hợp kiểm thử này đến 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 để đưa ra ý kiến phản hồi về cách cải thiện quy trình kiểm thử trước khi quy trình đó được chấp nhận vào CTS.

Hãy xem phần 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.