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

　　在“DevOps轉(zhuǎn)型之路”分會場，eBay中國研發(fā)中心測試基礎(chǔ)架構(gòu)技術(shù)主管茹炳晟帶來了《測試基礎(chǔ)架構(gòu)的演進之路》的主題演講，分享了大型電商網(wǎng)站的測試基礎(chǔ)架構(gòu)設(shè)計經(jīng)驗與心得。會后，51CTO記者根據(jù)茹炳晟在WOT2018全球軟件與運維技術(shù)峰會的演講內(nèi)容進行了整理。

[[232477]]

　　GUI 自動化測試框架的演變

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

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

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

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

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

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

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

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

　　測試數(shù)據(jù)之疼+應(yīng)對策略的平臺化演變

　　茹炳晟將測試數(shù)據(jù)的痛點歸納成五個部分。

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

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

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

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

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

　　API自動化測試框架的演變

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

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

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

　　以上內(nèi)容是51CTO記者根據(jù)eBay中國研發(fā)中心測試基礎(chǔ)架構(gòu)技術(shù)主管茹炳晟在WOT2018全球軟件與運維技術(shù)峰會的采訪內(nèi)容整理，更多關(guān)于WOT的內(nèi)容請關(guān)注51cto.com。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】