本頁概述了開發人員支持的 CTS (CTS-D) 的使用指南。
測試覆蓋率
CTS-D 與 CTS 和 CTS 驗證程序一樣,只能強制執行以下操作:
- 開發者 SDK (developer.android.com) 中針對特定 API 級別描述的所有公共 API。
- 特定 API 級別的 Android 兼容性定義文檔 (CDD) 中包含的所有 MUST 要求。
非 MUST 要求(例如強烈推薦、應該、可能)是可選的,不能使用 CTS 進行測試。
由於所有 API 和 CDD 要求都與特定的 API 級別相關聯,因此所有 CTS 測試(CTS、CTS-D 和 CTS 驗證程序)都與與其關聯的 API 或要求相同的 API 級別相關聯。如果某個特定 API 被棄用或更改,則必須棄用或更新其相應的測試。
CTS 測試創建規則
- 測試必須始終如一地產生相同的客觀結果。
- 測試必須通過開箱即用的一次設備測試來確定設備是通過還是失敗。
- 測試創建者必須消除所有可能影響測試結果的因素。
- 如果設備需要特定的硬件條件/環境/設置,則必須在提交消息中明確定義該設置。有關設置說明的示例,請參閱設置 CTS 。
- 測試一次不得超過 6 小時。如果它需要運行更長時間,請在您的測試提案中包含推理,以便我們對其進行審核。
以下是用於測試應用限制的一組示例測試條件:
- Wifi 穩定(對於依賴 Wifi 的測試)。
- 設備在測試期間保持靜止(或不保持靜止,取決於測試)。
- 設備已從任何電量為 X% 的電源上拔下。
- 除 CTS 外,沒有任何應用程序、前台服務或後台服務正在運行。
- 運行 CTS 時屏幕關閉。
- 該設備不是
isLowRamDevice
。 - 電池保護程序/應用程序限制未從“開箱即用”狀態更改。
測試資格
我們接受執行現有 CTS、CTS 驗證程序或 CTS-D 測試未測試的行為的新測試。任何檢查超出我們測試覆蓋範圍的行為的測試都將被拒絕。
CTS 提交流程
- 編寫測試提案:應用程序開發人員使用Google 問題跟踪器提交測試提案,描述已識別的問題並提出測試以檢查它。提案必須包含關聯的CDD 需求 ID 。 Android 團隊審核了該提案。
- 開發 CTS 測試:提案獲得批准後,其提交者在主(AOSP/master)分支上的 AOSP 上創建 CTS 測試。 Android 團隊審查代碼。
- 發布測試:在
AOSP/master
上提交您的 CL,然後將其挑選到最新的androidx-tests-dev
分支。該測試現已公開。
CTS-D 考試寫作指南
- 遵循Java 代碼樣式指南。
- 遵循CTS 開發中描述的所有步驟。
- 將您的測試添加到適當的測試計劃中:
- 使用
include-filters
將新測試添加到 CTS-D 測試計劃:platform/cts/tools/cts-tradefed/res/config/cts-developer.xml
。 - 使用
exclude-filters
從主 CTS 測試計劃中排除您的新測試:platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml
。
- 使用
- 處理
errorprone
中所有容易build_error.log
的警告和建議。 - 重新調整對
head
的更改。這包括cts-developer.xml
和cts-developer-exclude.xml
測試計劃。 - 與您的 Google 工程聯繫人一起確定您的測試用例是否可以包含在現有的 CTS 模塊中。如果不能,他們會幫助您創建一個新模塊。
- 對於創建的每個新測試模塊,在新測試模塊目錄中創建一個 OWNERS 文件。
- 您的 OWNERS 文件應包含以下信息,這些信息是從您正在使用的 Google 測試所有者處獲得的:
-
# Bug component: xxx
- 谷歌測試所有者 ldap
- 在
AndroidTest.xml
中,指定以下參數。有關示例,請參閱示例文件( 1 、 2 ):-
Instant_app
或not_instant_app
-
secondary_user
或not_secondary_user
-
all_foldable_states
或no_foldable_states
-
- 要指定正確的 minSDK,請參閱<uses-sdk> 文檔。
- 簽入新的測試方法、類或模塊時,將它們添加到 CTS-D 測試計劃中,並以與新測試相同的方式將它們從主 CTS 測試計劃中排除。
運行 CTS-D 測試
使用run cts --plan cts-developer
從命令行運行 CTS-D 測試計劃。
要運行特定的測試用例,請使用run cts --include-filter "test_module_name test_name"
。
有關運行完整 CTS 的信息,請參閱運行 CTS 測試。
接受和釋放
提交測試請求後,內部團隊將對其進行審查,以確保它測試了 CDD 要求或記錄在案的 API 行為。如果確定該測試是為了檢查有效的要求或行為,則團隊會將此測試用例轉發給 Google 工程師以供進一步審查。 Google 工程師會與您聯繫,提供有關如何改進測試的反饋,然後才能將其納入 CTS。
有關 CTS 發布計劃的詳細信息,請參閱發布計劃和分支信息。