一個優秀的測試基礎架構是如何煉成的?

• 2019 年 12 月 11 日
• 筆記

來源：http://www.51testing.com

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集群里發送請求，詢問集群下面有沒有安裝著這個作業系統的這個瀏覽器版本的節點?如果有，測試系統會直接發給他，如果沒有，測試系統會動態地創建一個。

歡迎參加眾測：

https://wap.ztestin.com/site/register?usercode=FAAAQwMQGAAXAwQBA3QhExcDHAQDPjVaABMIQg%3D%3D