無測試結構約束
使用自動化系統不應限制于特定格式編寫的測試。重點在于這樣做便于未來能夠創新測試的編寫方式。此外,不同的團隊(我們與負責平臺,安全,播放/媒體/ UI等的團隊進行了交流)可能會提出不同的方法來構建測試,以更好地滿足他們各自的需求。確保自動化系統與測試結構解耦從而提高其可重用性。
測試層盡量少的抽象層(Few layers at the test level)
當構建大規模系統時,很容易終止于太多的抽象層。雖然這在許多情況下這樣做并不是不好,但是當這些層也被添加到測試中以便能讓它們與自動化集成時,這就會出現問題。事實上,這會導致你離實際需要測試的功能越來越遠,并且在問題出現時將很難調試:在被測的應用程序之外的很多調用可能會出錯。
在我們的案例中,我們在設備上測試Netflix,因此我們要確保在設備上運行的調用函數盡可能靠近正在測試的SDK功能。
支持重要的設備功能(Support important device features)
手動完成設備管理需要消耗大量時間,因此這是一個優秀的自動化系統的應該占的很大組成部分。 由于我們測試正在開發的產品,因此我們需要能夠即時更改構建并將其部署到設備。 提取日志文件和崩潰轉儲對于自動化也非常重要,以便將調試測試失敗過程能按流水線處理。
設計自動化(Designing automation)
通過這些目標,我們的團隊需要一個提供必要的自動化和設備服務的系統,同時盡可能地避免與測試模塊耦合。
這需要重新思考現有框架并創建一種新型的自動化生態系統。為了使自動化具有這種靈活性,我們需要自動化系統是精細的,模塊化的,并且只有在確實需要測試某個功能時才需要外部服務,也就是說只有當某個功能不能從設備上的應用直接完成才會請求外部服務(例如掛起應用程序或操縱網絡)。