引言
我最初開始接觸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概覽
六、待完善部分
平臺目前有兩個較大的功能欠缺：
- 賬戶體系和權限控制
- 代碼動態編譯運行的安全控制(沙箱)
賬戶體系和權限控制目前沒有實現，主要是時間成本的問題，考慮目前平臺都是公司內部各測試組使用，暫時沒有特別強的需求。至于動態編譯運行的安全問題，主要是難度和時間成本兩方面的原因，對于這個安全問題，目前我自己還沒有一個周全的解決方案，歡迎提出寶貴意見，另一方面，作為內網運行的平臺，安全需求相對較低。
