一、問題引入
在做接口自動化時隨着案例增多，特別是流程類案例增多，特別是asp.net的webform類型的項目，再加上數據庫校驗也比較耗時，導致RF執行案例時間越來越長，就遇到這樣一個問題，705個接口測試案例(案例包含流程類案例，一個流程類案例可能包含3、4個單個案例，單個案例又都包含登錄)，通過Jenkins在單機上要跑13小時30分鍾，而且目前還不是整個項目所有的接口測試案例，案例個數還在繼續增長，一個系統假如有3、4000個接口那如果按照這個速度可能得跑一兩天，這是很可怕的。
二、解決方案
於是就是在想有沒有方法能縮短運行時間呢？一是將大的項目分成幾個子模塊，測試案例也是分為幾個子模塊，這樣可以做分布式測試，二是進行並行測試，在一台機子上開啟多個進程進行測試，最好的方案是一、二的結合，在網上搜了下，沒想到已經有開源的類庫Pabot。Pabot通過開啟多個進程以Suite為單位並行運行RF測試案例，而且對於進程之間資源共享問題也有鎖機制。它也兼容RF命令行參數，這樣在Jenkins中修改之前RF命令也很容易，只需加幾個參數就可以了。
三、測試
這里新建了一個PabotDemo，包含3個Suite，每個Suite中還有3個Test，每個Test都是執行相同的步驟sleep 10s,暫停10s。如果在RF中運行9個Test，每個Test耗時10s，那就需要90s。下圖為在RF中運行的測試結果。
如果使用Pabot，開啟多個進程並行運行案例，那就會減少運行時間，這里分別2個進程和3個進程。
2個進程：pabot --processes 2 PabotDemo，這里原本要90s的案例耗時63s。
3個進程：pabot --processes 3 PabotDemo，這里原本要90s的案例耗時32s。
上面簡單測試了使用Pabot開啟多個進程並行執行RF案例，這里沒有進程間的資源共享，所以沒加鎖，具體使用可以參考：https://github.com/mkorpela/pabot。使用Pabot開啟2個進程還是在原來單個執行機運行上面提到的705個測試案例，耗時減少5個小時，通過率也有提升，運行時間下降到8小時30分。
四、進一步優化
在開啟2個進程並行運行705個案例減少5小時的運行時間，如果再多開啟幾個進程還是有下降的空間，除了多開幾個進程外，還可以對案例進行優化。我們應該都下載過文件，有的大文件幾個G，有的只有幾M，小的文件很快下載完了，大的文件可能才剛開始，影響下載時間的關鍵因素可能就是幾個大的文件，為了達到並行下載的目的，可以將大文件分為幾個小文件，這樣並行下載效果更好。由於Pabot並行運行是以Suite為單位運行的，因為項目的案例結構有的Suite中案例個數100多個，有的只有幾個，這樣就導致案例少的Suite幾個可能已經運行完了，案例多的Suite可能才剛開始，並不能發揮並行運行的最大效果，分布不均，所以需要對案例進行調整，將案例多的Suite進行拆分，這樣也能開啟多個進程，不然總共有3個Suite開啟5個進程，那也沒用，還是只有3個進程在運行，上面只是舉了下載文件的例子，還有好多整體與部分的關系，有點類似木桶原理。
五、優缺點
這里只是使用Pabot進行的接口案例執行，對於UI測試案例可能會殺瀏覽器進程的，這里沒測是否能用Pabot進行測試。
六、總結
上面優化案例結構也是為了並行執行案例進行的優化，其實還有地方進行優化，比如登錄，目前每個案例在執行時都會先進行登錄，算是多了一個get和post請求，特別是那種json的，可能就是先get、post進行登錄，然后就只有post請求就結束的，如果能模擬人的操作，同一個用戶只登錄一次，那效率應該也會有所提高，案例少的話可能不明顯，案例多的話應該就會明顯些。