從0到1 —— 自動化測驗成功起步

前言

本文分享一個小規模測驗團隊從0到1探索自動化測驗實踐的程序，主要從專案背景、測驗方法、框架選擇、實作路徑、遇到的問題及解決方法、價值、經驗等方面進行介紹，希望對有自動化測驗需求的團隊有所幫助，

先說成果

2020年我們前后用了六個月左右時間，泰康云CSDG測驗團隊三位伙伴在日常測驗作業之余，從零開始掌握了python+selenium技能，完成了17個選單下136個測驗用例的撰寫，經過不斷優化腳本和測驗資料，腳本通過率可以達到80%以上，使原本需要花費兩人天時間的回歸驗證作業壓縮到3個小時內完成（自動化測驗加未通過的用例手動驗證），

實作自動化測驗之前，因為回歸測驗太耗費時間和人力，上線之前基本沒有做過完整的回歸測驗，只對主要功能進行簡單檢查，實作自動化測驗之后，每次上線之前都可以對原有功能進行回歸，上線更安心，

團隊不大，挑戰不小

我們是個小測驗團隊，六位測驗伙伴負責四個產品的測驗任務，深度參與產品研發全程序：參與產品需求討論，測驗用例設計，測驗計劃制定，測驗執行，上線驗證作業，每個產品開發團隊十人左右，測驗人員一到兩人，開發采用敏捷管理模式，開發系統為WEB系統，兩到三周一個迭代，

目前各個產品都在新功能開發階段，開發節奏緊張，人力投入有限，導致開發完成時間離功能上線的deadline越來越逼近，嚴重壓縮了測驗時間，寶貴的測驗時間只能用來完成新功能驗證，原有功能的回歸測驗越來越力不從心，因各系統具有很大的差異性，并且各個專案上線節奏不同步，測驗人員無法在專案間共享，無法增加人力，只能寄希望于自動化測驗來解決回歸測驗的需求，

在本次自動化測驗實踐之前，我們是個純手工測驗團隊，幾乎沒有自動化測驗經驗，本次自動化測驗實踐是一次從零開始的探索實踐程序，我們針對其中一個投入人力最多、回歸測驗壓力最大的專案進行，參與的測驗人員四人，其中三人主要完成測驗框架和測驗用例腳本開發任務，一人參與了流水線配置和測驗環境配置作業，均在不影響日常測驗作業的情況下進行，

測驗方法選擇

目前功能測驗角度的自動化測驗往往采用介面自動化測驗和UI自動化測驗兩種方式，UI界面一般變動比較頻繁，每次界面變動都可能引起測驗腳本修改，因此維護測驗腳本的作業量比較大，所以目前業內比較推崇介面自動化測驗，但是實際選取哪種自動化測驗方式還得取決于業務實際情況，

我們首先也嘗試了介面自動化測驗，嘗試過使用JAVA+TestNG撰寫測驗腳本，嘗試過Jemter生成介面測驗用例，但是實踐證明，對于有大量界面功能的系統，介面測驗無法對系統進行有效的回歸，有超過50%的問題是前端問題，或前端對介面的不恰當呼叫引起的問題，所以完全采用介面自動化測驗無法滿足我們系統日常回歸測驗的需求，我們采用了UI自動化測驗，

實作路徑

自動化測驗一般采用如下工具來實作：

• 采購商業化測驗平臺，功能完善，界面友好，成本較高；
• 自研測驗平臺，滿足公司或專案個性化需求；
• 采用開源工具，介面測驗使用的較多；
• 基于開源框架撰寫測驗腳本/代碼，靈活性強，作業量較大，對測驗能力有一定要求；
• 使用工具錄屏，生成測驗腳本，操作簡單，缺乏靈活性，維護成本很大，

對于測驗投入有限的小團隊，采購商業測驗軟體和自研測驗平臺都不現實；錄屏工具看似容易，但穩定性非常差，難以持續維護，因此我們采用基于開源框架撰寫測驗腳本的方式來實作，考慮到我們是一個年輕的純手動測驗團隊，團隊成員測驗經驗有限，缺少編程語言基礎，在這種情況下，我們選擇python+selenium這種應用廣泛的腳本語言和主流測驗組件，降低學習成本，激發學習熱情，

我們首先劃分了測驗工具的功能模塊，設計每個模塊的具體功能，采用HTMLTestRunner管理測驗用例執行和測驗報告生成，

HTMLTestRunner實際上是采用的python unittest進行用例執行管理的，方便靈活，如果對測驗報告有特殊要求，可以對HTMLTestRunner的測驗報告部分進行修改和編輯，使用python unittest的斷言來判斷測驗用例執行結果，我們基于python logging模塊進行了log功能封裝，根據每個測驗用例生成測驗報告，對測驗服務啟動、運行程序等公共代碼執行也能生成log檔案進行記錄，便于問題定位，測驗環境地址、瀏覽器型別等通過組態檔定義，增強靈活性，測驗資料通過excel檔案進行管理，可以靈活修改，也為后續資料驅動測驗提供可能，撰寫了郵件通知功能，測驗結束后，對測驗報告和測驗log進行打包發送，可以根據配置選擇發送或者不發送，可以配置郵件接收人，測驗框架的主要模塊以及模塊間關系如下圖所示，

測驗腳本完成后就可以隨時隨地執行，但是最重要的是能在新版本上線前執行，我們之前只有一套測驗環境，測驗腳本撰寫好后，發現執行自動化測驗的時間和手動測驗的時間有沖突，自動化測驗和手動測驗同時在一套測驗環境上執行會產生干擾，影響測驗效果，于是我們搭建了一套自動化測驗環境，專門用于進行自動化測驗，在一個完整迭代周期里，我們執行的各種測驗作業如下圖所示，

那么，對于一個零自動化測驗基礎的團隊，如何進行上文介紹的框架的搭建和腳本的撰寫呢？我們通過自學和內部培訓的方式來獲得技能，先熟悉python語言，然后由有代碼經驗的測驗工程師進行測驗框架的設計、模塊劃分，主要代碼的撰寫，Python語言學習掌握較好的伙伴可參與撰寫公共部分代碼，然后由有經驗的工程師選取幾個穩定的頁面（很少修改的頁面）撰寫測驗腳本demo，使用撰寫好的框架和測驗腳本進行內部培訓，測驗人員按照測驗腳本demo的結構和流程撰寫腳本并除錯，之后團隊一起對新撰寫的腳本進行review，經過幾輪撰寫腳本和review之后，團隊成員基本掌握了在本框架下撰寫測驗用例的能力，

測驗代碼管理

在本專案實踐中，沒有專門的自動化測驗崗位，參與測驗的測驗工程師都需要撰寫自己負責的模塊的測驗腳本，隨著學習和實踐經驗的積累，測驗腳本中的公共代碼部分也在優化，那么這就需要對測驗腳本進行代碼管理，我們把測驗專案放在gitlab上管理，并且制定了分支管理策略，

我們將devops分支作為執行測驗的分支，個人修改代碼后提交到遠程個人分支，再merge到devops分支，當腳本穩定后，將devops分支merge到master分支，可以考慮打標簽進行備份，

測驗流水線

我們申請了專門的虛擬機來運行測驗腳本，在TDS平臺（基于jenkins的Taikang Deveops Service平臺）建立測驗專案流水線，通過TDS平臺一鍵發起測驗，測驗結束后系統自動發送郵件將測驗報告發送給相關測驗和開發人員，

測驗腳本專案和一般的開發專案有所不同，TDS中現有流水線模板不滿足我們的需求，所以本流水線采用自定義jenkins的方式構建測驗執行流水線，

Python是一種腳本語言，不需要編譯直接可以運行，為了便于查看代碼，便于出現問題后除錯，我們通過自定義jenkinsfile，從gitlab直接下載代碼上傳到測驗服務器，然后執行測驗腳本的入口程式，測驗腳本的執行時長因實際情況而不同，如果執行時間較短，可以讓流水線執行起腳本后等待測驗結束腳本退出，根據腳本的退出狀態判斷腳本執行情況，在流水線上顯示腳本執行結果，如果測驗腳本執行的時間較長，也可以讓流水線執行起測驗腳本后就結束本次流水線操作，

問題及解決

在開發測驗腳本程序中，首先遇到的問題是，前端代碼撰寫時很多元素沒有定義id或者name，只能通過xpath進行定位，這樣的話前端只要一點輕微的調整，xpath就可能發生改變，導致腳本穩定性很差，給腳本維護帶來難度，我們通過和前端開發人員溝通約定，給大部分前端元素都設定id或者name，這樣測驗腳本里就可以通過id或name來定位元素，腳本的穩定性有了很大提升，對于必須用xpath定位的元素，通過學習xpath語法，優化xpath寫法，從而在一定程度上提高了腳本可讀性和穩定性，另外，對測驗腳本進行適當改造，基于PageObject（頁面物件）撰寫腳本，使測驗腳本更易于維護，通過上述手段，測驗腳本不斷優化，腳本穩定性有了很大提高，

展望

雖然我們的UI自動化測驗框架已經在團隊內落地使用，解決了實際問題，但是不得不承認它使用起來不夠簡單，對使用者有一定的門檻，接下來我們會對該測驗框架進行以下優化：

• 對測驗配置部分進行優化，增強通用性，
• 將元素和操作進一步封裝，從而讓測驗用例撰寫更簡單，
• 將測驗框架從單機模式改造成web服務，增加可視性，方便協作，
• 分級測驗用例，制定不同級別的用例集，和被測系統的流水線結合，部署后執行測驗，

UI自動化測驗是針對界面功能進行操作和結果檢查，不太適合對業務鏈條比較長的操作進行測驗，下一步我們將業務鏈條比較長的測驗點和復雜流程，用介面自動化測驗覆寫這些場景，最終通過手動測驗+主要選單的UI自動化測驗+復雜業務場景的介面自動化測驗來實作功能測驗的立體覆寫，

經驗分享

本次自動化測驗實踐，我們有幾個小經驗想和大家分享：

1.對于小團隊，初次進行自動化測驗，建議充分利用優秀的開源專案，不追求重復造輪子，而是將好用的輪子組裝成好用的戰車，在最短的時間里追求盡量大的投入產出比，解決實際問題，

2.要選擇合適的測驗方式，否則可能投入很大的作業量但是解決不了實際問題，

3.從零開始實踐，需要有一定經驗的人進行測驗設計，或者有人先行學習獲得一定的自動化能力，指引方向，然后組織其他成員一起實踐，效果往往更好，

4.要注意測驗用例的有效性，明確用例的設計原則，注意斷言的合理性，有效的用例才可能測驗出問題，

本作業受到組內測驗伙伴的極大支持，小伙伴們表現出了極大的學習熱情和能力，做有價值的事情，一起學習成長，往往會有事半功倍的效果，也要感謝開發小伙伴們的支持和配合，代碼更規范，測驗才能更容易，

以上是泰康云測驗團隊自動化測驗實踐的一點經驗，希望對人力投入有限，但是迭代頻繁、前端界面功能復雜、專案有回歸測驗需求的團隊有所參考，
感謝！

最后： 可以在公眾號：傷心的辣條 ！ 免費領取一份216頁軟體測驗工程師面試寶典檔案資料，以及相對應的視頻學習教程免費分享！，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，

如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！喜歡軟體測驗的小伙伴們，可以加入我們的測驗技術交流扣扣群：914172719（里面有各種軟體測驗資源和技術討論）

好文推薦

轉行面試，跳槽面試，軟體測驗人員都必須知道的這幾種面試技巧！

面試經：一線城市搬磚！又面軟體測驗崗，5000就知足了…

面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號…

什么樣的人適合從事軟體測驗作業？

那個準點下班的人，比我先升職了…

測驗崗反復跳槽，跳著跳著就跳沒了…