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).

Phạm vi kiểm thử

CTS-D, giống như CTS và CTS Verifier, 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 phải là BẮT BUỘC, chẳng hạn như RẤT NÊN, NÊN, CÓ THỂ, 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 của CDD đều gắn liền với một cấp độ API cụ thể, nên tất cả các kiểm thử CTS (CTS, CTS-D và CTS Verifier) đều gắn liền 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ể không được dùng nữa hoặc thay đổi, thì thử nghiệm tương ứng của API đó cũng phải không được dùng nữa hoặc được cập nhật.

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

  • Một thử nghiệm phải luôn cho ra cùng một kết quả mục tiêu.
  • Một 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 khi mới mua.
  • Người tạo bài kiểm tra phải loại bỏ tất cả các yếu tố có thể ảnh hưởng đến kết quả kiểm tra.
  • 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ì bạn phải xác định rõ thiết lập đó trong thông báo cam kết. Để biết hướng dẫn thiết lập ví dụ, hãy xem phần Thiết lập CTS.
  • Mỗi lần, bạn không được chạy thử nghiệm quá 6 giờ. 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 bộ điều kiện kiểm thử mẫu để kiểm thử một quy tắc hạn chế đối với ứng dụng:

  • Wi-Fi ổn định (đối với một 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 quá trình kiểm thử).
  • Thiết bị đã rút khỏi mọi nguồn điện và còn X phần trăm pin.
  • Không có ứng dụng, dịch vụ trên nền trước hoặc dịch vụ trong nền nào đang chạy, ngoại trừ CTS.
  • Màn hình sẽ tắt trong khi chạy CTS.
  • Thiết bị KHÔNG isLowRamDevice.
  • Trình tiết kiệm pin / các quy định hạn chế đối với ứng dụng không thay đổi so với trạng thái "mới mua".

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

Chúng tôi chấp nhận các kiểm thử mới thực thi một hành vi không được kiểm thử bởi CTS, Trình xác minh CTS hoặc các kiểm thử CTS-D hiện có. Mọi kiểm thử kiểm tra một hành vi nằm ngoài phạm vi 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 Công cụ theo dõi lỗi của Google, mô tả vấn đề đã xác định và đề xuất một quy trình kiểm thử để kiểm tra vấn đề đó. Đề xuất phải có mã yêu cầu CDD liên quan. Nhóm Android sẽ xem xét đề xuất này.
  2. Phát triển một bài kiểm thử CTS: Sau khi đề xuất được phê duyệt, người gửi sẽ tạo một bài kiểm thử CTS trên AOSP trong nhánh phát hành mới nhất của Android (android16-release). Nhóm Android sẽ xem xét mã và nếu được chấp nhận, họ sẽ chọn lọc thay đổi và hợp nhất vào nhánh phát triển nội bộ. Để biết thông tin chi tiết, hãy xem phần 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 thủ 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 kiểm thử vào kế hoạch kiểm thử thích hợp:
    • Sử dụng include-filters để thêm các 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.
  • Đổi cơ sở cho các thay đổi của bạn thành head. Trong đó 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ột 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 phải chứa 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 cùng:
    • # Bug component: xxx
    • Ldap của chủ sở hữu 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 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 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 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 CTS đầy đủ, hãy xem phần Chạy các 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 rằng yêu cầu đó kiểm thử một yêu cầu CDD hoặc một hành vi API được ghi lại. Nếu xác định được rằng bài kiểm tra đang kiểm tra một 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 một kỹ sư của Google để xem xét thêm. Kỹ sư 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 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.