原文地址：Automated testing on devices
譯者：杰微刊兼職譯者macsokolot(@gmail.com) ? ?
作為NetflixSDK工作團隊的一員，我們的職責是確保Netflix應用新版本都經過了徹底的測試，在部署到游戲終端上或是作為一個SDK分發到（可作為一個參考樣例程序）Netflix設備的合作伙伴之前保證其高運行質量；并最終向智能電視的百萬和機頂盒子（set top boxes，STB’s）推送。總的來說，我們的測試是保證在數以百萬計游戲終端以及通過互聯網連接的電視/機頂盒中的Netflix運行質量。
不同于服務端的軟件分發方式，客戶端軟件分發所特有的挑戰在于在程序崩潰的情況下并沒有紅/黑推送（red/black pushes）或立即回滾功能。如果客戶端有一個BUG，那么從代碼修正到客戶端推送，修復這個BUG的代價將非常之高。Netflix不得不重新與眾多合作商重新對他們的設備進行再次認證，盡管他們的設備可能已經被Netflix認證過，但只要修復版本一推送，這個流程就得重新走一遍，這樣整個項目的時間花費無論是外部還是內部都是十分巨大的。與此同時，用戶對這個BUG將束手無策，隨之而來的便是糟糕的Netflix用戶體驗。那么避免此類問題出現的最好辦法就是：在版本推送之前確保應用的每項測試都能引導到設備之中，然后檢測應用的回歸測試是否達到要求。
這是關于自動測試系統一系列文章中的第一部分，闡述了我們在多個設備上用于自動化功能、性能和壓力測試Netflix SDK的關鍵概念和基礎框架。
期許目標（Aspirational Goals）
多年來，我們使用手動和自動化手段測試Netflix應用程序的經驗告訴我們幾個教訓。 因此，是時候重新設計我們的自動化系統以進入下一個級別和規模，我們需確保將這些定為核心目標。
低設置成本/高測試“靈活性”（Low setup cost / High test “agility”）
當使用自動化才測試時，測試不應難以創建和/或使用。特別是在能夠簡單地手動運行的測試應該也能在自動化中運行并保持簡單化。這意味著使用自動化工具應該具有接近零的設置成本（如果存在）。確保創建新的測試，和調試現有的測試應該是快速和無縫的，這非常重要。在測試中，這也確保了重點盡可能長地保持在測試和功能上。
無測試結構約束
使用自動化系統不應限制于特定格式編寫的測試。重點在于這樣做便于未來能夠創新測試的編寫方式。此外，不同的團隊（我們與負責平臺，安全，播放/媒體/ UI等的團隊進行了交流）可能會提出不同的方法來構建測試，以更好地滿足他們各自的需求。確保自動化系統與測試結構解耦從而提高其可重用性。
測試層盡量少的抽象層（Few layers at the test level）
當構建大規模系統時，很容易終止于太多的抽象層。雖然這在許多情況下這樣做并不是不好，但是當這些層也被添加到測試中以便能讓它們與自動化集成時，這就會出現問題。事實上，這會導致你離實際需要測試的功能越來越遠，并且在問題出現時將很難調試：在被測的應用程序之外的很多調用可能會出錯。
在我們的案例中，我們在設備上測試Netflix，因此我們要確保在設備上運行的調用函數盡可能靠近正在測試的SDK功能。
支持重要的設備功能（Support important device features）
手動完成設備管理需要消耗大量時間，因此這是一個優秀的自動化系統的應該占的很大組成部分。 由于我們測試正在開發的產品，因此我們需要能夠即時更改構建并將其部署到設備。 提取日志文件和崩潰轉儲對于自動化也非常重要，以便將調試測試失敗過程能按流水線處理。
設計自動化（Designing automation）
通過這些目標，我們的團隊需要一個提供必要的自動化和設備服務的系統，同時盡可能地避免與測試模塊耦合。
這需要重新思考現有框架并創建一種新型的自動化生態系統。為了使自動化具有這種靈活性，我們需要自動化系統是精細的，模塊化的，并且只有在確實需要測試某個功能時才需要外部服務，也就是說只有當某個功能不能從設備上的應用直接完成才會請求外部服務（例如掛起應用程序或操縱網絡）。
將外部服務的使用量減少到最低限度有幾個好處：
1、它盡可能地確保關于測試的邏輯駐留在測試本身之內。這提高了測試的可讀性，維護和可調試性。
2、大多數測試最終結束于沒有外部的依賴上，這使開發人員能夠不再重新配置就能重現一個bug然后測試，而絕對不是去用他們之前使用的工具去配置然后運行這個測試。
3、測試用例編寫者可以專注于測試設備的功能，而不必擔心外部約束。
在最簡單的層面上，我們需要有兩個單獨的實體：
1、測試框架
一種軟件抽象，通過公開控制測試流程的功能來幫助編寫測試用例。
測試框架就是幫助編寫測試，編寫的測試應盡可能接近正在測試的設備/程序底層，這樣能夠在調試一個測試失敗的時候減少需要轉換的模塊。
測試框架可能有很多，以便不同的團隊可以按照他們的需要來組織他們的測試。
2、自動化服務
一組外部后端服務能夠幫助管理設備，自動執行測試，以及在迫切需要時提供用于測試的外部功能。 自動化服務應該盡可能以最獨立的方式構建。減少服務之間的依賴關系能提升更好的可重用性，降低維護、調試和功能迭代所需的成本。例如，啟動測試的服務、收集關于測試運行的信息、驗證測試結果可以委托給單個微服務輔助實現。這些微服務有助于獨立地運行測試，而不需要運行一個測試自動化服務。自動化服務只提供服務，而并不能控制整個測試流程。
例如，測試可以請求外部服務重新啟動設備作為測試流程的一部分。但是服務不能命令這個測試去重新啟動設備或控制整個測試流程。
建立即插即用生態系統（Building a Plug and Play Ecosystem）
當涉及到設計自動化服務時，我們就需要了解每個服務需要什么。
1、設備管理
雖然測試本身是自動的，但在各種設備上進行測試需要一些自定義步驟，例如在測試開始之前刷入固件，升級和啟動應用程序，以及在測試結束后收集日志和崩潰轉儲信息。這些操作中的各個步驟可能在不同設備上操作完全不同。因此，我們需要一個服務來提取設備特定信息，并為不同設備提供一個通用接口
2、測試管理
編寫測試只是整個測試過程中的一小部分；但也需要注意以下幾點：
- 對測試進行編組（測試套件）
- 選擇何時運行它們
- 選擇要運行它們的配置如何
- 存儲測試結果
- 可視化測試結果
3、網絡操作
在帶有波動帶寬的設備上測試Netflix應用程序體驗的核心要求是確保高質量不間斷的播放體驗。我們需要一種服務可以改變網絡狀況，包括流量整形和DNS操縱。
4、文件服務
當我們開始收集用于歸檔目的或用于存儲巨大日志文件的構建時，我們需要一種方式來存儲和檢索這些文件，并且通過文件服務以實現這一點。
5、Test Runner
每個服務是完全獨立的，因此我們需要一個協調器，能夠與各個獨立的服務進行通信，以便在測試運行之前獲取和準備設備，并在測試結束后收集測試結果數據。
遵循上述的設計思想，我們構建了以下自動化系統。
下面所描述的服務（services）為滿足上述特定需求，其設計的原則：盡可能獨立，而不是將其綁定到測試框架中。這些概念在實踐中如下所述。
設備服務
設備服務抽象化了從頭到尾管理設備所需的技術細節。所有類型的設備都統一通過RESTful接口進行接入，設備服務的用戶不再需要掌握任何設備特定的知識：它們可以使用所有或者任一設備，就像它們是相同的，設備之間沒有差異。
管理每個類型的設備的方法并不是在設備服務本身中直接實現，而是授權給device handlers程序代理，而這個device handlers屬于一個獨立微服務（micro-services）。
這提高了對新類型設備支持的靈活性，因為設備處理程序（device handlers）可以根據他們自己選擇的REST API以任何編程語言編寫實現，并且現有處理程序（handlers）可以容易地與設備服務集成。一些處理程序（handlers）有時可能需要與設備進行物理連接，因此將設備服務（device service）與設備處理程序（device handlers）分離，在提高了靈活性同時也能方便快速定位到它們。
對于接收到的每個請求，設備服務的功能是找出哪個設備處理程序來聯系和代理這個請求，找到之后，由device handler與對應的一組REST API進行交互。
讓我們來看一個更具體的例子...例如，在PS4上安裝build的操作與在Roku上安裝bulid非常不同。 一個依賴于用C＃編寫的代碼，它與運行在Windows（相對于PlayStation）上的ProDG Target Manager交互，而另一個運用Node.js中的ProDG Target Manager在Linux系統中進行交互。而PS4和Roku設備處理程序（device handlers）都實現了各自設備特定安裝過程。
如果設備服務需要與設備通信，則設備服務需要知道設備特定信息。每個設備具有唯一標識符，且被存儲成可由設備服務訪問的設備映射對象（device map object），包含了關于handler所需的設備的信息。例如：
1、設備IP或主機名
2、設備Mac地址（可選）
3、處理程序IP或主機名
4、處理程序端口
5、Bifrost IP或主機名（網絡服務）
6、Powercycle IP或主機名（遠程電源管理服務）
首次將設備添加到我們的自動化中時，需要填充設備映射信息。
當引入用于測試的新設備類型時，由設備服務實現和公開該設備的特定處理程序（handler）。 設備服務支持以下常見的設備方法集：
注意，這些每個端點都需要在請求中嵌入唯一的設備標識符。此標識符（類似于序列號）需要綁定到正在操作的設備。
保持服務簡單性使得其高可拓展性。給設備添加附加功能也可以很容易地實現，如果設備不支持某個功能，你只需簡單地將其置為空。
設備服務還充當設備池：
下面是我們在實驗室中運行的一些自動化設備的一些圖片。注意看Xbox 360電源按鈕附近有個小機械手。這是一個自定義解決方案，我們只是把Xbox 360放在一起，因為此設備需要手動按鍵才能重新啟動它。我們決定自動化這個手動過程，通過設計一個機械臂連接到raspberry pi，它能發送控制命令使機械手移動并按下電源按鈕。此操作已添加到Xbox 360的設備處理程序。設備服務的powercycle端點調用Xbox 360的電源循環處理程序。此操作對于PS3或PS4不是必需的，并且不在這些設備處理程序（handler）中實現。
測試服務：
測試服務是運行測試用例會話的記錄員。其目的是標記測試用例的開始，記錄狀態變化，日志消息，元數據，文件的鏈接（在整個測試期間收集的日志/小型崩潰數據）以及由測試用例發出的數據集，直到測試完成記錄結束。該服務記錄由運行測試用例的測試框架調用的單個端點操作：
通常測試框架會內部調用這些端點操作，如下：
1、一旦測試開始，就開始調用POST / test / start。
2、周期性保持發送POST / test / keepalive操作，讓測試服務知道測試正在進行。
3、測試信息和結果在測試運行時使用POST / test / configuration和POST / tests / details發送
4、當測試結束時，調用POST / test / end
網絡服務 - Bifr?st橋
我們構建的網絡系統，用于與設備通信，進行流量整形或dns操作被稱為Bifr?st橋。我們不改變網絡拓撲，并將設備直接連接到主網絡。對于Bifrost橋不需要運行測試，而只有在某個測試需要網絡操作（如覆蓋DNS記錄）時才需要。
文件服務
如果我們正在運行某個測試，我們可以選擇收集測試生成的文件，并通過文件服務將它們上傳到存儲倉庫。這些包括設備日志文件，崩潰報告，屏幕截圖等...從使用這個服務的用戶角度來看，這個服務非常簡單：
文件服務是Varnish Cache提供技術支持，由云存儲和資源的文件服務被緩存用于快速檢索。
數據庫
我們選擇使用MongoDB作為測試服務的首選數據庫，因為它的JSON格式和它在無模式（schema-less）方面的優點。開放式JSON文檔存儲解決方案所帶來的靈活性是滿足我們需求的關鍵，因為測試結果和元數據存儲始終在不斷迭代，并且在其結構上并不是固定的。 雖然從數據庫管理角度來看，關系數據庫聽起來頗具吸引力，但它違背了了即插即用（Plug-and-Play）的原則，因為數據庫事務（schema）需要隨時隨地進行任何測試。
當運行在CI 模式下，我們記錄每個測試唯一的運行ID，并收集有關build配置信息，設備配置信息，測試細節等。可下載的鏈接到文件服務日志也存儲在數據庫測試條目中。
Test Runner — Maze Runner
為了減少每個測試用例所有者調用不同服務并單獨運行測試的負擔，我們構建了一個控制器稱為Maze Runner，它協調運行測試和調用所需的不同服務。
測試套件的所有者創建一個腳本，其中他/她指定需要運行測試的設備（或設備類型）、測試套件名稱和形成測試套件的測試用例，并請求Maze Runner執行測試（并行地）。
下面是Maze Runner所做的操作列表：
1. 根據請求查找要運行的設備/設備
2. 調用設備服務以安裝build
3. 調用設備服務以啟動測試
4. 等待測試在測試服務中標記為“已結束”
5. 顯示使用測試服務檢索的測試結果
6. 使用設備服務收集日志文件
7. 如果測試沒有啟動或沒有結束（超時），Maze Runner將使用設備服務檢查應用程序是否崩潰。
8. 如果檢測到崩潰，它會收集coredump，生成調用堆棧并通過專有調用堆棧分類器運行并檢測崩潰簽名
9. 如果發生崩潰或超時，通知測試服務。
10. 在序列操作的任何時候，如果Maze Runner檢測到設備有問題（例如因為設備丟失了其網絡連接，build將不會安裝或設備將不會啟動），它將釋放設備，并將此設備服務禁用一段時間，直到最終得到一個全新的設備來運行測試。這個想法的核心是純硬件故障不應該影響測試。
測試框架
測試框架與自動化服務完全分離，因為測試框架在設備本身中運行。大多數測試可以手動運行，無需自動化服務。這是系統設計的核心原則之一。 在這種情況下，需手動啟動測試，并在完成測試時手動檢索和結果檢查。
然而，可以將測試框架與自動化服務（例如，用于存儲測試進度和結果的測試服務）結合在一起操作。當測試在CI中并由我們的運行器運行時，我們需要這種與自動化服務集成。
為了以靈活的方式實現這一點，我們創建了一個內部稱為TPL（測試可移植性層）的抽象層。 TPL為每個自動化服務定義簡單的接口以便測試和測試框架能調用到此層中。每個自動化服務可以提供這些接口的具體實現。
這一層允許能夠在我們的自動化系統中運行的測試也能夠在另一個完全不同的自動化系統中執行，只要這個系統中的服務實現了TPL接口。這使得使用由其他團隊編寫的測試用例（使用不同的自動化系統）能夠在原封不動的情況下運行它們。 當一個測試不變時，由測試所有者對設備上的測試失敗（test failure）進行故障排除時，之間的障礙被完全消除; 我們總是想保持這種工作方式。
進展
在保持測試框架獨立于自動化服務之下，我們設法在基礎需求之上使用自動化服務以添加缺少的設備功能：
1. 拓寬我們的游戲控制臺和參考應用程序的測試自動化覆蓋面。
2. 將基礎架構（infrastructure）擴展到移動設備（Android，iOS和Windows Mobile）。
3. 使其他質量保證部門能夠利用我們的設備基礎架構建立他們的測試和自動化框架。
最近我們的測試執行覆蓋率數據顯示，我們的參考應用程序（reference applications）能夠單獨為每個build執行大約1500次測試。為了說明問題，開發團隊為參考應用程序每天在一個分支（branch）上生成大約10-15個build，每個build生成5種不同的build版本（例如Debug，Release，AddressSanitizer等）。 對于游戲終端，每天有大約3-4個build具有單一的build風格。 保守地說，使用單個build風格時，我們的生態系統負責在給定的一天運行的測試用例量接近1500 * 10 + 1500 * 3 =?20K。
新挑戰
鑒于每天執行的測試數量眾多，出現了兩個突出的挑戰：
1. 設備和生態系統的可擴展性和彈性挑戰
2. 由測試結果產生遙測分析過載挑戰
在未來的博文中，我們將更深入地探討我們在為解決這些巨大的新挑戰而采取的廣泛的舉措。
