由於建磊小朋友離職，開始接手比較高大上的分散式模擬器的工作。分散式模擬器關係到團隊自動化的執行效率，也關係著測試人力的投入，也算是機遇與挑戰並存吧。

2014年4月8日 潛龍勿用

剛接手的第一天，遇到的第一個問題是由於節假日公司斷電，導致模擬器無法執行自動化。當時問題比較棘手，自動化可以說是癱瘓了，等待執行自動化的同學一次次帶著希望詢問解決的進展，一次次又失望地走回工位。針對這個問題，第一個想到的是交接時提到的，如果機器重啟，需要重新配置分散式模擬器的ip。根據這個想法，簡單梳理了下分散式模擬器的執行流程，主要是通過兩種方式來觸發自動化測試：

第一種是直接在jenkins平臺觸發自動化測試的job。

第二種是通過一體化平臺排程觸發自動化測試job,第二種的執行流程圖如下：

step1：首先從一體化測試平臺選擇測試地址的url資訊，經由分散式模擬器的前端服務程式進行排程。

step2：經由分散式模擬器前端服務執行經由模擬器排程層的輪詢操作。

step3：模擬器排程層會通過RMI的形式與模擬器所在的PC端響應程式通訊，返回當前模擬器的使用情況。

step4：如果有空閒的機器則會繼續選擇需要測試的型別，例如：FE自測、核心功能測試（Main）,非核心功能測試（other）等。

step5 : 模擬器排程層會根據測試型別的選擇，拼接出排程jenkins測試服務的url，以post形式觸發jenkins jos。

在這個過程中需要幾個準備工作：

第一個工作是需要啟動nodejs來啟用分散式模擬器的前端服務，其次是開啟模擬器的響應程式，然後就是執行jenkins提供的slave.jar保持與jenkins服務平臺的通訊。

在模擬器排程層，需要配置模擬器所在機器的ip資訊，當機器的IP地址改變後，需要手動配置排程層中的IP資訊，但是由於排程層是一個client.jar的jar包，每次修改都需要重新打包，這個當然是比較耗時。且在當時同事走得比較倉促，沒有把client.jar和server.jar的原始碼留下，在此又通過XJar將程式碼反編譯後，將配置的IP的資訊抽離到配置檔案，大體流程弄明白了，問題也迎刃而解。

這次問題的解決花了大約兩個小時的時間，解決過程中發現，如果優先啟動slave.jar保證直接觸發jenkins的方式可用，就可以保證自動化測試的正常執行。對於交接後流程的快速瞭解，成為了這幾天分散式模擬器工作的重點。攻堅戰即將開始。

4月12日-4月16日 履霜，堅冰至

上一週的主要精力放在了自動化用例編輯平臺上，這一週發現大家對分散式模擬器的抱怨越演越烈，關於執行時間長、執行失敗甚至無法執行的問題反饋越來越多，為了優先保證自動化測試工作的有效進行，這周主要對模擬器的當前狀況進行了摸底，並通讀原始碼，快速瞭解自動化測試的執行流程。

看了下jenkins的job執行情況，dailyrun的執行時間的最高紀錄達到了7個多小時，平均下來也在5個多小時，測試中常用的核心用例和非核心用例的測試頁保持在2.5-3個小時，對於當前的形勢，自動化測試已經成為了測試過程中的瓶頸，同時也具有很大的優化潛力。

兵欲善其事，必現利其器。想要庖丁解牛，首先要對牛具備透徹的瞭解，對於當前的流程，需要花時間的閱讀原始碼，繪製執行流程圖。於是花了半天的時間對自動化的執行流程進行梳理，自動化測試的基本流程圖如下：

step1：當我們有自動化需求時，會觸發對應的jenkins job, 然後會經由jenkins的服務端與節點主機的slave.jar服務進行通訊，

從而對自動化測試的流程進行控制，並且對測試的控制檯資訊進行收集。

step2：在確認通訊已經OK的情況下，slave會受到更新svn的命令，將本次測試所需的程式碼進行更新。

step3：更新完畢後，就會執行我們已經寫好的executeJob.bat指令碼，這個指令碼是用來具體操作執行流程的。

step4：首先會設定環境變數，保證下一步命令的正確執行。

step5：環境變數設定完畢後，會先後進行自動化Suite的構建工作，例如：ant -buildfile buildAllFunction.xml all。

step6：在構建的同時，會執行一個sayHi.py的python檔案，對模擬器進行相應的操作。

在這個過程中，由於測試的構建與模擬器的啟動同時進行，並且模擬器的啟動需要幾分鐘的時間，會導致第一次進行的自動化測試不能建立WebDriver,導致丟擲org.openqa.selenium.remote.UnreachableBrowserException異常，所有case skip後，等待第二輪測試的執行。

在模擬器的管理中，sayHi.py利用了對UnreachableBrowserException異常的判斷，進行了模擬器的啟動操作，sayHi.py中主要針對模擬器的生命週期和測試的重跑進行了控制，先上一張模擬器環境的啟動流程圖：

step1：正如上面所說的，剛開始會根據UnreachableBrowserException的異常判斷是否已經執行了第一次測試。如果沒有的話，會等到testng-results.xml中存在這個異常後，進行模擬器的啟動操作。

step2：開始執行模擬器的啟動操作時，優先會kill掉與模擬器相關的幾個程序（adb、pcdroid和VBox虛擬機器相關的幾個程序）。

step3：啟動VBox虛擬機器和pcdroid模擬器，獲取當前裝置的ID後，通過adb對模擬器進行連線。

step4：這裡如果裝置沒有啟動成功，會進行重啟操作。（後面發現，由於pcdroid在一定時間內無法啟動，導致無限重啟的情況。）

step5：進行埠對映，啟動測試所需的程式webDriver，啟動定位程式，與模擬器相關的測試環境在這裡算是啟動完畢了。

這個過程中，以通過判斷異常的方式來啟動模擬器服務，在一方面是保證了自動化測試的編譯及case生成工作已經準備就緒，避免出現因測試程式碼問題而導致的重啟，但在另一方面也對測試的效率略有影響。與此同時，模擬器環境的穩定性對測試效率的關聯性較大，由於模擬器環境會在測試過程中出現卡死或者無響應等情況，因此也對測試的重跑做了以下機制：

step1：在模擬器啟動過程中，會使用一個死迴圈來判斷當前模擬器的執行狀況以及當前測試的狀況。

step2：通過讀取testng-results.xml中skip與fail的數量來判斷是否需要重跑。一般來說，測試的case是不允許skip的，因此當發現存在skip的case時，會觸發重跑的機制。同時，因為模擬器環境的穩定性問題，可能導致case失敗，因此在這裡我們的假設是可以通過多次執行case的手段來保證case的正常執行，在這裡也就加了一個針對失敗用例的重跑規則：如果上一次失敗數與本次相同且沒有skip的用例，那麼我們就認為測試完畢了。

step3：測試完畢後，需要對測試環境進行還原，並將測試結果傳送給本次測試的關注人。

以上兩張圖的解析，模擬器的執行流程也就梳理完畢了。接下來是與之並存的自動化執行流程，直接上圖：

簡單的說就是使用ant對測試程式碼進行編譯和構建，通過讀取case的配置檔案生成對應的java檔案。當編譯與打包的工作完畢之後，就進入了自動化的具體執行流程，由於本次主要針對分散式模擬器流程來說，在這裡就不對框架的具體流程進行詳細論述。在測試中，採用testng這個測試框架，以註解的形式對case的執行流程做了簡單歸納，如圖：

BeforeMethod註解主要是執行case執行前的初始化操作。

Method註解標註的就是我們要執行的用例了。

AfterMethod是在用例執行完畢後，為了不影響下一個case的測試而清空了當前webdriver對應的session資訊。

通過這三個註解，對測試case的生命週期進行了管理，從而保證了自動化測試的有序執行。

好了，整體的構造已經被我瞭解明白了，下面也該當當醫生了，看看這個病人的病症到底在哪裡。作為一個合格的醫生，當然要中西醫結合，在對程式一頓望聞問切之後發現，表徵很明顯，分佈地很廣，於是就把這周所遇到的表象都記錄了下來。

大體分為四個方面：

人工干預

1.PC電腦鎖屏，模擬器無法執行，需手動解鎖，自動化方可正常執行。

2.模擬器不能正常啟動，導致頻繁重啟，job無法結束，手動關閉，job執行失敗。

3.執行自動化時，模擬器出現“抱歉，程式意外結束”彈出框，模擬器無法重啟，需要人工關閉後可繼續執行。

4.Pcdroid中VBoxmanage.exe無法啟動，出現報錯pcdroidsession被鎖定，需要手動重啟VBox中pcdroid的虛擬器。

5.失敗次數過多時，生成結果目錄名稱過長，導致測試結果檔案在svn更新前無法自動刪除。

穩定性

1.xml使用testNG.dtd，編譯成java過程受dtd規則響應影響，dtd無法訪問或延遲，影響自動化功能。（case相關的xml檔案已經取出testNG.dtd規則，處理完畢）

2.在測試中自動化框架可能會命中小流量，導致測試用例失敗。（已新增對Monitor小流量的相容，但是目前不能支援頁面元素不同的情況，處理完畢）

3.自動化框架不支援多組資料相容，增加case可靠性。

可用性

1.自動化框架日誌輸出不夠完善，且自動化郵件caseinfo資訊不能精確定位問題，通過控制檯很難辨別case執行程度。

2.Pcdroid版本在4.2，不能支援其他版本自動化。

效率

1.執行自動化，模擬器出現白屏，需要等待本輪執行的所有case執行完畢（確切說是skip）後，再會重啟模擬器進行驗證。

2.每次執行通過case過少，導致多次執行，耗時嚴重。在此做了一次dailyrun中執行自動化case的記錄。

(不包含模擬器測試環境啟動與重啟的時間)

第一次：用時21秒（模擬器沒開啟，全部skip）

第二次：用時57分26秒(第二次執行，僅通過了59個case)

第三次：用時8分27秒（模擬器白屏，人工干預1次，關閉模擬器，case沒有通過）

第四次：用時21分48秒（通過34個）

第五次：用時14分29秒（模擬器白屏，人工干預1次，關閉模擬器，case通過45個）

第六次：用時11分41秒（通過0個）

第七次：用時11分41秒（通過0個）

第八次：用時11分41秒（通過0個）

第九次：用時9分26秒（模擬器白屏，人工干預1次，關閉模擬器，發現沒有打出monitor監控的log，懷疑通過case未執行,通過0個case）

第十次：用時8分30秒，通過7個case（由此可得出，白屏後需手動）

第11次：用時8分9秒，通過0個case

第12次：用時46秒（不能忍了，白屏了N久，手動關閉模擬器，通過case0個）

第13次：用時6分59秒（遠端登入PC機器導致模擬器執行出錯，通過40個）

第14次全部skip

第16-25次，分別耗時1分17秒，一直是系統找不到制定路徑，執行0個case

第26次，耗時6分30秒，完成83個case，daliyrun執行完畢。

本次case在多次人工干預的情況下仍然以耗時5小時6分鐘結束。

4月19日-4月23日見龍在田，利見大人

鑑於以上幾個方面，該如何對症下藥，還需要進一步的化驗，那就驗個血、做個B超什麼的，看看到底癥結在哪裡。由於上週一直在處理分散式模擬器方面的問題，用例編輯平臺進展較為緩慢，本週準備把主要精力放在用例編輯平臺的工作上，可是因為與爽姐的溝通改變了計劃。

當我把當前模擬器的問題跟爽姐看了之後，得到的反饋是白屏問題已經是自動化測試的當務之急，需要通過技術手段予以解決。進行了一番交流後，大體頭腦風暴了以下幾種方案：

第一種，解除安裝並重裝webdriver，處理的比較徹底，屬於寧可錯殺一千，不可放過一個的型別，因為無法獲取case的執行狀態而pass。

第二種，首先，儲存最後一個執行成功case的id和上一個case的id。

其次，在init時判斷上一個case的id和最後一個執行成功id是否一致，如果不一致說明上一個case出現了錯誤（防止skip的錯誤驗證，skip時只會執行teardown方法）。

然後，呼叫指令碼解除安裝webdriver。

最後，重新執行skip的用例。

第三種，在log中進行打點，經由判斷控制檯日誌來驗證webdriver執行狀態，從而進行解除安裝重灌操作。

這種方法個人感覺可能會麻煩一些，因為可能涉及到多次白屏，每次白屏判斷之後需要把指標設定到上一次白屏日誌之後，然後再進行判斷。同時如果監控日誌的話，也需要在case執行的週期中做判斷或者增加監控執行緒，在實現難度上感覺會比直接用邏輯判斷要大，pass。

感覺第二種方案比較靠譜，於是就根據第二種方案的思路進行實施。於是，我抱著這種態度對自動化框架進行了打點。打點的目的主要針對兩個問題：第一個是判斷這個case已經正確執行。第二個是判斷沒有正確執行的case因為什麼原因沒有執行。

分別針對 進入BeforeMethod(打點為1)，執行webdriver、selenium初始化（打點為2），載入元素配置（打點為3）、BeforeMethod結束（打點為4）、開始執行Method(打點為5)、執行完畢Method(打點為6) 進行了打點，然後在程式中輸出出來，執行jenkins job，開始觀察。

最後發現出現兩種比較反常的情況，一種是，在4停留的時間過長，一直沒有進行5的操作。一種是，在5執行時間過長，沒有6的操作就呼叫了AfterMethod。鑑於這兩種情況觸發場景進行了還原，發現是因為webdriver掛起導致case無法執行的問題。（額。。。在init中驗證是否為白屏，如果白屏就重啟模擬器，方案貌似可行，結果在執行時發現在init中無法判斷白屏問題。）

接下來就針對當前癥結對症下藥，為了解決第一個問題，在自動化框架初始化過程供增加了一個對執行狀態的監控執行緒，發現一旦在4停留時間過長，那麼我們就認為webdriver異常了，執行重啟Webdriver操作，此問題KO。第二種問題的捕獲點在AfterMethod中觸發，一旦發現進入該方法時仍為5狀態，我們就可以斷定case沒有按照我們的預期完成，標誌異常，執行重啟webDriver操作，這個也KO。在經過多次除錯後，這個影響效率的大毒瘤終於被解決掉了。上一張dailyrun的執行效率圖。

在這裡也感謝使用分散式模擬器的同事們，你們的每一次認可都會成為我繼續優化的動力。同時希望分散式模擬器能夠帶來更多的價值，優化我們的測試流程，讓WebAppQAs的工作更加高效！

轉載於:https://blog.51cto.com/327229983/1558884