內容來源：2018 年 5 月 20 日，eBay中國研發中心技術主管茹炳晟在“2018全球技術周暨第四屆南京（全球）軟件大會”進行《Quality Engineering向Engineering Productivity轉型下的測試基礎架構實踐》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發佈。
閱讀字數：3994 | 10分鐘閱讀
獲取嘉賓演講視頻及PPT，請複製鏈接：http://t.cn/RD2gSSr，粘貼至瀏覽器即可。
摘要
本次演講首先會介紹Quality Engineering向Engineering Productivity轉型的概念，接著通過一步步的實踐引出轉型後的測試基礎架構。
Quality Engineering向Engineering Productivity的轉型
從Google談起
Google 的GTAC大會從測試技術上來講可以說是國際上最權威的技術峰會，從2006年開始舉辦一直持續到2016年，不過2017年的會議並沒有舉辦。Google對此的說法是當時舉辦GTAC的初衷是為了提高測試效率，更好的做自動化測試，但是在2016年之後他們發現單靠自動化測試已經不能解決軟件工程所面臨的眾多問題，為此他們提出了一個新的概念Engineering Productivity（工程效能），可以簡單將它理解成是為了更好的做自動化測試以及測試產出而衍生出的工程效能上的工具平臺或方法論。
基於Google在全球的影響力，這一概念在被提出後，國際上的很多大公司也開始了著手探究。
測試誰來做
在Engineering Productivity模式下是沒有專職的測試人員的，開發工程師需要自己來做測試。原先的開發流程中，測試和開發是分來的，所以經常會出現由於雙方對同一事物的不同認知而產生的糾紛，造成工作效能的低下，而如果開發人員能自行做相應的測試無疑會提高效率。
QE向轉型後的測試實踐
在原先的傳統軟件團隊中產品測試類似於圖中左邊結構，自下而上依次是unit test、API test、GUI test。在轉型之後unit test減少，API test增多，GUI test依舊，上方多了一層Exploratory test，這一層是真正的基於測試的理念和探索式方法來儘可能多的發現軟件系統潛在的缺陷。
從人員的角度來看，無論是轉型之前還是之後unit test都是開發來做，但是API test和GUI test在轉型之後從測試轉向了開發，原來團隊的業務測試人員現在專注於Exploratory test。
轉型後測試基礎架構的最佳實踐
統一的測試數據準備服務
不管是API test還是GUI test在跑一個case之前都需要準備測試數據，這一階段一般會耗費很多時間，粗略的估計會佔用整個測試的30%-35%的時間。對此一般的做法是採用固定的數據來進行測試，以節省時間，但是這種做法要面臨髒數據的問題，有可能數據在使用過一次後無法再繼續使用，比如訂單數據。測試數據本身也具備一定複雜性和多樣性，用戶數據的創建就有著各種組合和限制。
微服務化之後Cross domain的數據準備缺乏knowledge，以前的單體架構下，如果需要某些信息可以直接向特定團隊要求相應數據，但是微服務化之後，整個團隊都被拆分成了各個小的服務，沒有了具體的數據提供方。性能測試的數據準備同樣要消耗大量時間，因為數據量基本上在百萬級到千萬級。
測試數據準備解決方案
針對以上這些問題，我們從工程效能的角度給出了相對完美的解決方案。不過這個解決方案也不是一蹴而就的，而是經歷了好幾個不同階段的發展演化而來的。
1.0時代要準備User數據最簡便的方式是創建一個函數createUser，這個函數會去調用產品的API來生成user，它的參數列表中包含所有需要的參數信息。這種方式看似不錯，但是在真正的工程實踐中依然存在問題。其實可以發現在createUser函數的參數列表中有些參數本身就是一個結構，也就是說在定義createUser之前可能還需要定義與參數類型對應的create類。這樣一來腳本中測試數據準備代碼會佔很大一部分並且效率很低。
2.0時代解決了以上的問題，它是基於Builder Pattern的實現。如果build的時候未提供任何的信息就會生成一個全部採用默認值的user，也可以只指定部分信息而其餘部分依然採用默認值。
2.0時代雖然已經相對完善，不過數據是作為工具提供給所有的開發者使用，不同的開發團隊技術棧都不相同，前面的做法是通過Java實現的 ，對於後端來說當然沒有問題，但前端團隊就無法使用了。因此我們在3.0時代將這些基於Java的數據工具都封裝成了統一的Web Service，以Restful的形式對外提供服務，這樣前端、後端以及任何支持Restful接口的工具都可調用它。這時候的3.0還只能算是雛形，在此之上還會繼續演進。
之前的架構中對於所有創建數據請求都會重新執行創建數據的操作，3.0演進之後系統對於已經創建的過的數據會保存下來，在下次有同樣請求的時候會直接返回數據，這就縮短了數據返回的時間。同時對於一次性返回的數據在返回過一次之後就不會再返回，以避免髒數據。
測試執行環境的工程效能提升
對使用者來說，所期望的是測試執行環境的“透明性”。比如開發人員在跑UI測試的時候，只需要指定特定的操作系統和瀏覽器版本，不必關心具體的運行環境或機器，後臺會自動找到目標環境。
對維護者來說，期望的是“易維護”。因為整個測試環境是一個集群，大的公司中集群的規模會達到上千臺，構成一個小的私有云。面對這一套架構如何更好的維護就成了一個問題。
對於大量測試用例的執行而言，重要的是執行能力的可擴展性。雖然在短時間內跑完大量測試case的一個核心解決方案是應用大量機器併發運行，但是當沒有測試執行的空閒時間，就會造成大量機器的閒置。因此動態的根據測試用例的排隊數量來決定集群節點是非常必要的。
解決方案
基於jenkins觸發測試執行可能是大多數的測試人員使用的方案，但是在case數量非常龐大的情況下，基於jenkins的來管理管理這些test suite的效率往往並不高。為此我們在jenkins前面做了一個Test Execution System，它相當於一個測試用例管理系統，為jenkins腳本的管理提供了良好的界面，讓開發能夠直接通過界面操作建立jenkins腳本、觸發對應測試、管理測試版本。
後續的版本中我們用Selenium Grid代替了原來的虛擬機，所有的測試節點發給Selenium hub之後，hub就會自動找到相應的node進行測試。此時的jenkins還是單節點的構造，因此當同時運行的測試用例數量非常大的時候，實際的工程中會有大量的工程堵塞在jenkins上。為此我們將jenkins集群化了，同時為保證下游能承受住壓力，又用Docker實現了Selenium Grid的動態擴展與收縮。
應對微服務架構的高效API測試策略
傳統的API測試方案最大的問題在於無法做持續集成，因為常見的postman、soapui都是界面化的工具。這種情況下就需要將API 測試代碼化，在此之後還要剝離測試腳本和測試數據，也就是Data-Driven Test。進一步還可以動態的生成測試數據，比如測試API的時候動態分析API的參數類型自動生成一些邊緣case，這樣不僅提高了效率也方便開發發現一些邊界值的問題。
一般的功能測試不是單個API測試，而是併發的測試，因此需要有併發執行控制器，同時在進行全鏈路壓測的時候，還要有Load Generator Cluster。
微服務架構下API測試的最大挑戰在於測試用例的數量非常多，面對大量的API無法保證測試的質量。為此我們提出了基於消費者契約的API測試方式，將原先測試數量降低到了原先20%不到，同時還能保證質量，下面是具體實現思路。
假設有A、B、T三個微服務，T是不對外部暴露的被測微服務，A、B是T的消費者。 傳統的方案中會對T暴露出的所有接口的可能組合都測試一遍，然後驗證是否達標，不達標就再補各種case來覆蓋未測試的代碼。而在當前的場景下其實只需要測試A和B所調用的接口組合，不用關心其他接口的組合，這樣一來就能很大程度的降低測試數量。
接下的問題就是如何找到A、B調用的接口組合。通常的邏輯方案是在被測服務T前面添加一層代理，所有進出T的請求都會經過代理，然後就能獲取到進出流量中的request和response，將他們總結起來之後就有了一個針對T的測試contract。
這種方式同時解決了API依賴耦合的問題，如果在之前的架構中T還調用了X和Y且他們之間相互耦合，這種情況下為了能夠測試T，可以基於X和Y的contract來啟動Mock Service，這時測試T就不會再調用真實的X和Y，而是調用Mock Service X和Mock Service Y。
大型全球化電商的整體測試基礎架構
上圖就是全球化大型電子商務網站建議採用的整體的測試基礎架構。首先所有的請求都來自於CI/CD，Test Case依賴於Test Data Service以及Global Reglotry Service和unified Flow Fromework，Test Data Service用來準備要用的測試數據。所有的測試運行在測試執行環境中，Test Bed Service會準備這個測試執行環境。右下的unified Mock Service負責將微服務契約轉化成Mock以及Mock的版本管理。
以上為今天的全部分享內容，謝謝大家！
閱讀更多 IT大咖說 的文章
