編寫 Tradefed 測試運行程序

本頁介紹如何在 Tradefed 中編寫新的測試運行程序。

背景

如果您對 Tradefed 架構中測試運行器的位置感到好奇,請參閱測試運行器的結構。

這不是編寫新測試運行器的先決條件;測試運行器可以單獨編寫。

最低限度:實現接口

成為 Tradefed 測試運行程序的最低要求是實現IRemoteTest 接口,更具體地說是實現run(TestInformation testInfo, ITestInvocationListener listener)方法。

此方法是在使用測試運行器時由工具調用的方法,類似於 Java Runnable。

該方法的每個部分都被視為測試運行程序執行的一部分。

從測試運行器報告結果

基本接口中的run方法可以訪問ITestInvocationListener類型的偵聽器對象。該對像是將結構化結果從測試運行器報告給工具的關鍵。

通過報告結構化結果,測試運行器具有以下屬性:

  • 報告所有運行的測試的正確列表,它們花費了多長時間以及它們是否單獨通過、失敗或其他一些狀態。
  • 報告與測試相關的指標(如果適用),例如安裝時間指標。
  • 適合大多數基礎設施工具,例如顯示結果和指標等。
  • 通常更容易調試,因為有更精細的執行跟踪。

也就是說,報告結構化結果是可選的;測試運行者可能只是想將整個運行的狀態評估為 PASSED 或 FAILED,而不需要任何實際執行的細節。

注意:實現遵循事件順序的運行器更加困難,但鑑於上面列出的好處,我們建議您這樣做。

可以在偵聽器上調用以下事件來通知工具當前執行進度:

  • testRunStarted:通知一組相關聯的測試用例的開始。
    • testStarted:通知一個測試用例開始的開始。
    • testFailed/testIgnored:通知正在進行的測試用例的狀態變化。沒有任何狀態變化的測試用例被認為是通過的。
    • testEnded:通知測試用例結束。
  • testRunFailed:通知該組測試用例執行的整體狀態為失敗。測試運行可以是通過失敗,獨立於測試用例結果,具體取決於執行的預期。例如,運行多個測試用例的二進製文件可能會報告所有通過測試用例但帶有錯誤退出代碼(出於任何原因:文件洩露等)。
  • testRunEnded:通知測試用例組結束。

維護和確保回調的正確順序是測試運行器實現者的責任,例如確保使用finally子句在異常情況下調用testRunEnded

測試用例回調( testStartedtestEnded等)是可選的。可能會在沒有任何測試用例的情況下進行測試運行。

您可能會注意到這種事件結構的靈感來自典型的 JUnit 結構。這是為了使事情接近開發人員通常了解的基本知識。

來自測試運行器的報告日誌

如果您正在編寫自己的 Tradefed 測試類或運行程序,您將實現IRemoteTest並通過run()方法獲取ITestInvocationListener 。此偵聽器可用於記錄文件,如下所示:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

使用設備進行測試

上面的最小接口允許運行非常簡單的獨立測試,不需要任何特定資源,例如 Java 單元測試。

想要進行下一步設備測試的測試編寫者將需要以下接口:

測試運行者通常對這些接口感興趣,以便獲取與執行相關的工件,例如額外的文件,並獲取將在執行期間作為目標的被測設備。

使用多個設備進行測試

Tradefed 支持同時在多個設備上運行測試。這在測試需要外部交互的組件時非常有用,例如手機和手錶配對。

為了編寫可以使用多個設備的測試運行器,您需要實現IMul​​tiDeviceTest ,這將允許接收ITestDeviceIBuildInfo的映射,其中包含設備表示的完整列表及其相關的構建信息。

接口中的 setter 總是在run方法之前被調用,因此可以安全地假設該結構在調用run時可用。

測試知道他們的設置

注意:這不是一個非常常見的用例。為了完整起見,它已記錄在案,但您通常不需要它。

一些測試運行器實現可能需要有關整體設置的信息才能正常工作,例如有關調用的一些元數據,或者之前運行的target_preparer等。

為了實現這一點,測試運行程序可以訪問它所屬的IConfiguration對象,並在其中執行它。有關更多詳細信息,請參閱配置對象描述。

對於測試運行器實現,您需要實現IConfigurationReceiver以接收IConfiguration對象。

靈活的測試運行器

如果測試運行程序對它們有精細的控制,他們可以提供一種靈活的方式來運行他們的測試,例如,JUnit 測試運行程序可以單獨運行每個單元測試。

這允許更大的工具和基礎設施利用這種精細控制,並且用戶可以通過過濾部分運行測試運行器。

ITestFilterReceiver 接口中描述了過濾支持,它允許接收應該或不應該運行的測試的includeexclude過濾器集。

我們的約定是,如果它匹配一個或多個包含過濾器並且不匹配任何排除過濾器,則將運行測試。如果沒有給出包含過濾器,那麼只要它們不匹配任何排除過濾器,就應該運行所有測試。

注意:我們鼓勵以支持此過濾的方式編寫測試運行程序,因為它在更大的基礎架構中提供了巨大的附加值。但我們知道,在某些情況下,這是不可能的。