Web自動化測試平臺設計與落地-概覽

引言

關於Web自動化測試，投入產出比是一個繞不開的話題，對於走到2017年的測試人，這時候可能已經有很多人會想到著名的自動化測試金字塔。它形象地展示了Mike Cohn對自動化分層中各層所應該投入比重的看法，可以作為我們Web自動化實施策略的重要參考。

我最初開始接觸Web自動化測試的時候，沒有直接的領路人，測試行業知識也遠不及如今這麼豐富和易獲取，當時我對於自動化測試的分層幾乎沒有什麼瞭解，更不知道什麼金字塔，就如很多同行一樣，我一開始先入的是UI自動化的坑，那時候我還沒有養成搜尋英文資料的習慣，關於Selenuim2、WebDriver的中文資訊還相當有限，國內主流還在Selenuim1, 先熟悉API，熟悉元素定位方式，進行一些簡單的封裝，到後來的PageObject，幹勁十足。

不過在UI自動化這個階段的後期，我已經對自動化測試有了更多的認識，加上工作變動，開始跳介面自動化的坑，通過工作經歷、朋友和網路，對現狀有了一定的瞭解，大約2015年的時候，心裡隱約有一些想法，我們的測試物件的架構從最簡單的三層架構，到分散式架構，再到SOA，到微服務，一路向前，而再看我們測試人對Web系統介面自動化的實現方式，直接使用如 Postman這樣成熟工具的先不談，就自研框架而言，有用Java的，如Junit/TestNG + Ant（ + Jenkins + JMeter + xxx),有用Python的，比如基於廣為人知的RobotFramework，有用Ruby的，可能基於BDD界耳熟能詳的Cucumber，等等，技術棧可能各有不同，本質上，大多是孤立的工程 + 檔案形式管理的資料和用例。

可能四五年前，我看到的，大多是這樣的方案，到今天，測試從業者的數量大幅度增長，有良好程式碼能力的並且能將其用到測試工作中的也越來越多，然而我看到的，這些的方案仍然佔大多數，除開國內幾家頂尖的網際網路企業，就我所瞭解的以及網路上能搜尋到的，嘗試將方案走到簡單Web系統的形式，用資料庫儲存資料，線上管理自動化實施的，很少。就這些方案本身，我覺得只要能達到自己團隊的目的，都是很好的，沒有優劣之分，我在意的是，我看到的變化低於預期很多，新的嘗試低於預期很多，我覺得很多新的嘗試，對於現在的測試人來說，難度並不會比以前的方案高多少，所需要的時間成本，也並不會高出多少，我希望我們測試人在做自動化實施的時候，能夠像做業務測試一樣，能夠不侷限於某一個方向。

既然看到的嘗試很少，那我就想自己去做一做，慢慢形成一些思路，到2016年，公司原有的自動化方案不能支撐一些新產品的需求，開始投入精力去設計和實現一個Web型別的測試平臺，當時感覺就像當年剛開始自主實施UI自動化一樣，有一股勁。設計選型、編碼、首版服務端上線、第一個團隊開始使用、首版UI上線、1.6、2.0、…在功能方面來說，算是做出了勉強接近自己預期的系統(如果不考慮那拙劣UI的話)。 平臺明面上是我單獨完成的，但實際上，同行大牛對思路的肯定、工作安排上的支援、業務線夥伴的需求，都是不可或缺的。本來今年年就計劃寫關於這部分的文章，但由於今年工作、生活上都很忙，這半年幾乎沒有一個週末有自己獨立的時間，加上拖延症作祟，所以直到今天才總算開始碼了。

雖然並不確定這次計劃輸出的內容對讀者能有多少幫助，但還是計劃分幾篇來寫，當然具體能輸出幾篇現在我也沒底，拖延症是個強敵，所以決定第一篇先做一個總覽

這期的引言太長了點，抱歉。希望本文能為有耐心讀到這裡的人帶來些許價值

一、目標和定位

首選需要說明的是，由於近年的工作重心主要在Web服務端，同時根據團隊當前的工作情況，定的自動化策略是優先實施介面層而非UI層，所以平臺當前的主要功能是圍繞HTTP層的自動化測試展開的。

平臺的定位是作為公司各業務線服務端的自動化公共平臺，目標是通過快速落地自動化測試來支撐公司各產品組提高測試效率。

二、平臺特點

最基本的特點，平臺是一個前後端分離的Web服務、由資料庫管理基本資訊和測試用例、線上檢視測試報告。詳細一點的話，我認為通過對比的方式來呈現可能比較明瞭。這裡以引言中提到的實施方案與本文所述的測試平臺進行對比。

對比項	業界常見專案	本文平臺
定位	支撐某一產品線的介面自動化需求	支撐各產品線的多種自動化需求
適用性	適用於特定Web系統介面的自動化	適用於不同產品、不同設計理念介面的自動化
基礎架構	獨立的工程，基於檔案管理資料	前後端分離的Web服務，基於資料庫管理資料
落地方式	本地搭建執行環境，獲取工程並執行以除錯新用例	線上UI操作，開放介面便於CI整合
資料管理	通過更新/上傳檔案的形式管理用例	線上建立/更新用例，使用MySQL管理資料
執行方式	通過編輯Jenkins job/Crontab等實現執行計劃管理	線上自定義執行時間計劃和執行內容
結果校驗	校驗粒度較粗，資料庫校驗可能在程式碼中	基於Json解析的細粒度校驗，線上管理資料庫校驗
歷史資料	歷史資料缺乏有效管理	線上檢視歷史執行記錄和測試報告

三、系統架構

整個平臺的大體系統架構如下圖，其中產品資料庫互動主要是資料預置/清理/校驗

四、相關技術棧

應用	技術/工具
Web服務基礎框架	Spring Boot
Web容器	Jetty
持久層框架	MyBatis
HTTP呼叫和校驗基礎框架	REST-assured
用例排程執行	TestNG
HTML報告	Allure
平臺介面資訊	Swagger
基礎UI元件	Bootstrap
前後端互動	AJAX(Jquery)
線上程式碼編輯	Ace

關於線上程式碼編輯，主要提供給有基礎程式碼能力的同學應用在複雜場景的自動化實施，普通的介面自動化需求不需要。後續文章會做更多的說明。

五、UI概覽

六、待完善部分

平臺目前有兩個較大的功能欠缺：

• 賬戶體系和許可權控制
• 程式碼動態編譯執行的安全控制(沙箱)

賬戶體系和許可權控制目前沒有實現，主要是時間成本的問題，考慮目前平臺都是公司內部各測試組使用，暫時沒有特別強的需求。至於動態編譯執行的安全問題，主要是難度和時間成本兩方面的原因，對於這個安全問題，目前我自己還沒有一個周全的解決方案，歡迎提出寶貴意見，另一方面，作為內網執行的平臺，安全需求相對較低。