【51CTO.com原創稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運維技術峰會在北京召開。此次峰會圍繞人工智能、大數據、物聯網、區塊鏈等12大核心熱點，匯聚海內外60位一線專家，是一場高端的技術盛宴，也是***IT技術人才學習和人脈拓展不容錯過的平臺。

　　在“DevOps轉型之路”分會場，eBay中國研發中心測試基礎架構技術主管茹炳晟帶來了《測試基礎架構的演進之路》的主題演講，分享了大型電商網站的測試基礎架構設計經驗與心得。會后，51CTO記者根據茹炳晟在WOT2018全球軟件與運維技術峰會的演講內容進行了整理。

[[232477]]

　　GUI 自動化測試框架的演變

　　茹炳晟介紹到，eBay是一家大型電商平臺，其中測試基礎架構與DevOps的關系非常大，跟CI/CD(持續集成持續發布)高度集成。在CI/CD的流程中，對測試的調用都是通過統一的測試執行服務，通過這個統一的測試執行服務來發起所有的測試執行，包括API測試，GUI測試和性能測試。CI/CD整個流程過程當中，發起者并不需要知道測試運行在哪里，測試執行環境在哪里，測試是怎么設計的，他只負責發起一個測試，同步或者異步得到一個結果，然后決定這個流水線是不是可以往下走。這些行為都是基于測試基礎架構來進行構建的。

　　GUI(圖形用戶界面)自動化測試是最早的自動化測試之一，屬于比較重量級的測試，投入產出比一直不高，所以對于大型電商網站通常用于上線前的輕量級Smoke測試以確保所以核心功能的正確性。同時GUI(圖形用戶界面)自動化測試也是經歷了一個傳奇式的變化，從一個非常簡單的架構，一直演進到大型電子商務能夠適應全球化站點，同一套測試腳本能夠運行在全球化不同國家的站點上。

　　在最原始的測試框圖上，有業務的需求會轉換成功能需求，功能需求轉換成測試需求，測試需求會有測試用例，測試用例會在本地測試執行環境運行。測試團隊會在本地機器上面打開這個網站進行測試，那么問題來了，一旦需要進行全回歸測試，原始方法效率肯定很差，必須借助自動化測試功能，錄制回放就是最初的自動化。UFT這種工具可以在錄制完之后反復回放腳本。但是缺點是一旦界面有任何變化的，腳本需要從最初開始修改，這顯然讓人無法接受。

　　模塊化因此應運而生，它可以將一些基于操作級別可重復的腳本單獨抽象出來，并且把它參數化。但茹炳晟表示，在實際操作中，哪些是可重復的腳本，腳本的力度如何控制，其實比較難處理。因為每個人理解都不一樣，對于可重用腳本的定義，在每個團隊之間會有很大的差異。

　　經過進一步的發展，茹炳晟和他的團隊把可重復的腳本進一步演變成對于Page Object(頁面對象模型)的抽象，自動化腳本就變成了page的分裝，上面有基于page元素上的操作。后來，他們在page的基礎上，又做了一層Business Flow(業務流程)的抽象，測試人員可以直接看到業務驅動的測試腳本，從case維護的易操作性及可讀性來看，又上了一個檔次。

　　再到后來，茹炳晟和他的團隊開始嘗試使用Out-of-box Test Data / Golden Data Set測試數據，逐漸開始基于Unified Flow Framework實現Flow Branch控制。茹炳晟解釋道，像全球都擁有站點的大型電商網站，每一個國家對網站的功能都會有輕微的差異，這就要求技術團隊必須在同一個業務流程里能夠實現不同的功能點。過去是5個國家寫5個各自獨立的腳本，而現在只需要1個腳本就可以供不同國家站點進行差異化測試，對工程師的工作效能提升而言是非常有幫助的。

　　后來，他們又基于Page Encapsulation Code Generator提高Page Object的效率。當一個新的page或者一個page有改動的時候，他們可以通過一個很小的程序，就可以把這個page上面所有的元素動態捕捉下來，以后需要用的時候，只要是這個page上面的元素就可以調用了，整個page的生成都是自動完成，不需要人工去做。

　　到了這個階段，測試能力已經非常強，但是eBay的測試團隊仍然沒有滿足，他們引入Test Data Service，提供統一的測試數據準備服務。他們提供了一個完整統一的接口，可以幫助測試人員降低所有測試數據的復雜性，讓測試工作變得更加高效。

　　測試數據之疼+應對策略的平臺化演變

　　茹炳晟將測試數據的痛點歸納成五個部分。

　　***個痛點是On-the-fly數據的時間消耗準備。On-the-fly是什么概念呢?測試人員在測試用例開始實施之前，會在測試的腳本里動態生成數據，但如果是非常復雜的數據會十分消耗時間。

　　第二個痛點是Out-of-box測試數據的臟數據，在擁有大量測試用例的場景，可能存在數據相互干擾的問題，會讓大量的測試用例由于臟數據而測試不通過。

　　第三個痛點是測試數據本身組合的復雜性，電子商務網站需要綁定不同的支付方式、快遞方式，不同國家有不同法務要求，各種參數的組合非常多，給測試數據帶來很大的困擾。

　　第四個痛點是測試數據準備的環境依賴性，例如做某個功能的測試，需要準備特定的數據，但是因為微服務，這個數據是由另外一個服務器提供，但各種問題可能導致數據準備不出來，結果功能測試就無法完成。

　　第五個痛點是性能測試數據準備的時間消耗。在這方面eBay有非常好的實踐，通過Test Data Service，他們將成功率提高了很高的量級，并且把測試數據的問題從原來的30%降到5%以下。

　　API自動化測試框架的演變

　　茹炳晟介紹到，大型電商網站通常有上萬個API，由于快速迭代并上線發布，留給測試的時間非常少，只能通過一個很大的集群環境去并行運行這些API測試，他們會引入一個并發的訪問控制器，對這些集群、上萬個API進行控制。

　　經過五六個不同階段的發展，對于API測試，目前eBay已經完全遷到微服務上實現。目前公司service數量大概有百余個，如果按原來API的思路，case數量會超過10萬，即使用集群也跑不完。所以他們改變策略，引入了一個基于消費者契約的驗證模式。例如當A端的B來調用某個腳本，測試系統只需要知道是誰來調用，如何調用，然后把涉及到的API調用測試一遍就可以了。下一次只會測試之前調用過的腳本，就能保證整個模塊的質量。

　　對于測試執行環境的搭建，茹炳晟以GUI測試為例，例如某個測試人員要求這個GUI測試是運行在某個操作系統中的某個瀏覽器上的某一個版本上。那么他們會先到Selenium Grid集群里發送請求，詢問集群下面有沒有安裝著這個操作系統的這個瀏覽器版本的節點?如果有，測試系統會直接發給他，如果沒有，測試系統會動態地創建一個。

　　以上內容是51CTO記者根據eBay中國研發中心測試基礎架構技術主管茹炳晟在WOT2018全球軟件與運維技術峰會的采訪內容整理，更多關于WOT的內容請關注51cto.com。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】