巧用自動化測試組合拳保證產品質量

「如何保證質量」一直是產品或項目過程當中關注的焦點，而測試是產品質量把控環節中很是關鍵的部分。本文結合咱們的實踐經驗，總結出一套有效的自動化測試組合拳。

1、背景

咱們的測試工做經歷瞭如下四個階段。

第一階段，產品需求評審完成，開發團隊實現功能開發，而後草草提測，不寫單元測試。測試人員進行人工測試，沒有工具或系統作輔助，測試用例編寫是在excel或腦圖中呈現。這個階段只對業務熟悉，開發只關注功能實現。

第二階段，產品需求評審完成，開發團隊實現功能開發，寫自身功能相關的單元測試，組長review組內代碼。測試方面，依然處於人工檢測功能測試階段，但開始有一些相關的小工具輔助測試。在兩輪或多輪測試狀況下，迴歸一直是一個問題，還有分支測試完成，主幹迴歸的過程，測試環境、預發佈環境、灰度環境、線上環境等測試迴歸效率很低，人工測試在這方面的不足格外明顯。

第三階段，隨着業務的發展產品功能須要快速上線，同時系統技術不斷迭代，質量也面臨着從未有過的挑戰，人肉戰術不是長久之計。在此階段部門作了不少改進，引入和開發了不少測試輔助工具，如項目管理工具、測試用例管理工具、BUG管理工具、自動發佈系統、自動打包等。

• 搭建測試用例管理工具，方便編寫及後期跟蹤用例。一輪二輪測試人員如何分配；用例狀態的管理是經過、掛起仍是失敗，一目瞭然。
• BUG管理工具，主要是給開發和測試人員使用，經過文字和圖片結合的方式描述功能問題，減小了開發和測試的溝通成本。
• 項目方面也開發出項目管理工具，方便查看項目狀態和人力資源狀況，在項目中作到很好的呈現。
• 在此階段咱們開始研發UI自動化測試工具，直觀的想法是減小人工測試成本，提升測試效率。
• 自動化部署系統讓開發環境、測試環境、灰度環境和線上環境作到很好的隔離，每一個階段更清晰，避免相互干擾引發的問題。
• APP方面結合Jenkins能夠實現自動打包，測試起來作到了開發和測試都以版本控制系統爲主。

第四階段，由於測試每每是最後一個環節，風險較大，「怎麼實現下降風險提升人效，測試用例能夠複用」變成了咱們這個階段的主要工做。以前的流程是開發完成提測，作一次冒煙。由於咱們的產品是互聯網金融APP，APP有服務端開發和前端開發，像web、wap、anroid、IOS等渠道，在研發過程當中常常會出現如下場景：

• 需求只是項目中的一小部分，測試問產品要不要全量測？產品擔憂此次需求的研發會影響到其餘部分，就要求全量測試，因而測試的工期會拉得很長，拉長了需求的整個工期。
• 測試抱怨開發的BUG多，還有阻塞流程的BUG，須要等待開發解決BUG後才能繼續測試，致使整個測試工期加長。
• 手工測試偶有疏忽形成漏測試的點，需求上線後，客戶反饋BUG。

產品上線時間有deadline；測試時間長，擠佔開發時間；測試人手不夠；測試的準確性達不到要求...要解決這些問題，必然要作自動化測試方案。

針對業務和測試開發同事的特色，咱們從單元測試、接口測試、UI自動化測試三個方面作了有效銜接和可持續使用的自動化測試方案。

服務端開發完成，接口測試開始介入。接口測試前期使用一些小工具，會在小工具裏寫一些腳本，來方便測試過程當中的功能屢次迴歸檢驗，是否有更好的方式來作這件事，因而咱們搭建了接口自動化系統。以前測試是隻對UI界面作功能測試，咱們如今還實現了單元測試、UI自動化測試、接口自動化測試。

第五階段，測試團隊所有人員轉型測開，部分紅員處在人工測試和自動化測試的邊界上，實際上咱們一直在作內訓，讓團隊總體能更快地轉型成爲一個測試開發團隊。這個階段對成員要求相對較高，主要技術語言是python，還要對基礎的系統架構及運維知識有更多瞭解，團隊內部正在開發測試項目看板、重寫用例管理工具、升級接口自動化工具等，後期計劃實現APP多設備管理及測試。還有一些測試沒有提到，但也包括在主流程中，好比安全測試、兼容性測試、分辯率測試等。

目前項目的總體流程是這樣的：

• 產品經過DM上傳PRD，參與人員熟悉需求。
• 開需求分析會議，肯定需求最終版。
• 需求定稿後，開發人員抽象基礎功能、編寫UI部分，測試人員經過testlink寫測試用例。
• 測試用例編寫完須要產品、開發、測試人員作測試用例評審。
• 開發人員根據測試用例，編寫本身具體業務的單元測試用例。前端人員和自動化測試人員制定UI自動化測試點，定義好斷言字典和模擬用戶行爲的方法名稱，自動化測試人員編寫自動化測試case。
• 開發人員開發的同時，接口測試人員根據接口文檔，編寫接口測試用例。
• 全部編碼工做完成，開發人員單元測試經過後，進行接口測試驗證，再進行UI自動化測試驗證。UI自動化測試既要測試當前需求點，也要回歸以往的case。
• 驗證都經過後，手工測試人員介入。
• 手工測試完畢，自動化CASE反覆測試經過的狀況下，進行上線。

接下來分別介紹團隊在單元測試、服務層自動化測試、UI層自動化測試的具體技術實現。

2、單元測試

單元測試是對代碼實現邏輯作測試，總體項目環節比較靠前，因此成本最小也最有效，但對開發人員的綜合能力要求較高。

前端代碼中，用戶交互的部分交給UI自動化測試，而做爲業務基礎的類和方法，適用單元測試，咱們項目使用測試庫mocha和斷言庫chai，配合開發工具WEBSTORM，能夠很是方便地檢測代碼經過性。好比咱們開發的公用方法叫tools.js，使用mocha來測試它的文件是tools.test.js，以下圖：

3、UI自動化測試

UI自動化測試的目標有兩個：迴歸測試和測試准入，也就是開發完畢後，必須經過UI自動化的測試，方可進入手工測試階段，以節省手工測試的工做量，縮短測試工期。

UI自動化測試的難點在於產品多變，而case和UI是強關聯，若是UI變動，就會致使Case失效。如何解決case的穩定性，使之不受UI的影響，成爲咱們的重要目標。通過反覆嘗試，咱們選擇了這樣的方案。

測試工具對dom的選取，再也不使用ID或者XPATH，而由前端人員在頁面上定義專門用於UI自動化的屬性，測試工具須要的斷言也由前端人員在場景觸發時輸出到頁面中供測試工具抓取。測試工具和前端代碼維護共同的字典，保證雙方取值的正確性。咱們在每一個頁面都有一個ID名爲assertWord的隱藏div，用來存放斷言的值供測試工具抓取，用戶不一樣操做的時候，會去更改這個值。

3.1 拿風險測評頁舉例

咱們共用的字典如圖：

進入頁面的時候，會有

測試工具抓取到riskPage，說明進入到了風險測評頁。當用戶勾選完選項提交問卷後，若是接口返回正確，前端代碼以下：

咱們在彈出結果的時候，去更改assertWord的值，供測試工具斷言。

經過前端給測試工具拋值的方式，作到了case和UI的解耦。咱們選擇前端來處理的緣由是：UI改變也是前端來作，拋值也是前端來作，同一我的作相比前端和測試兩我的作，避免了溝通產生的疏漏。

另外，對於用戶操做的模擬，有時候測試工具不如前端編寫方便，好比這個風險測評頁面有不少道題目，測試工具要是模擬用戶挨個答題，至關費時間，而前端則只須要不多的代碼就能完成，如圖：

因此咱們編寫了不少模擬用戶行爲的方法，供測試工具調用。

目前UI自動化測試已實現了web平臺化，功能測試人員經過web頁面來組織、編輯、執行RFW（robotFrameWork）測試用例腳本，將測試用例的管理和執行統一到系統中。與傳統的自動化測試相比，支持協同工做、分佈式測試執行，提升了測試效率，同時也避免了功能測試人員在本地搭建一系列測試環境。

3.2 技術選型

1）web框架：Flask

簡述：Flask是一個使用Python編寫的輕量級Web應用框架。

優勢：

• 輕巧，相較於大型框架Django，flask更適合小型web項目。
• 簡潔，不須要複雜的分層和邏輯，框架內建了不少功能。
• 入門簡單，即使沒有多少web開發經驗，也能很快作出網站。

2）分佈式任務隊列：Celery

簡述：Celery 是一個分佈式隊列的管理工具, 能夠用Celery提供的接口快速實現並管理一個分佈式的任務隊列。

優勢：

• 簡單，熟悉了celery的工做流程後，配置和使用仍是比較簡單的。
• 高可用，當任務執行失敗或執行過程當中發生鏈接中斷，celery會自動嘗試從新執行任務。
• 快速，一個單進程的celery每分鐘可處理上百萬個任務。
• 靈活，幾乎celery的各個組件均可以被擴展及自定製。

3）測試框架：Robot Framework

簡述：Robot Framework是一個基於Python的、可擴展的關鍵字驅動的測試自動化框架，用於端到端驗收測試和驗收測試驅動開發。

優勢：

• 門檻低，經過使用關鍵字驅動測試（KDT）方法簡化了自動化測試過程，方便測試人員建立易讀的測試。
• 易於擴展，能夠自定義測試庫。
• 功能全面，支持WEB測試、SSH、telnet、API接口多種測試方式。

4）UI測試庫：SeleniumLibrary

簡述：SeleniumLibrary是針對Robot Framework開發的Selenium庫，它也是Robot Framework下最流行的庫之一，主要用於編寫Web UI自動化測試。

優勢：

• 多瀏覽器支持，包括Firefox、Chrome、IE、Opera、Safari。
• 多平臺支持，包括Linux 、windows、Mac。
• 多語言支持，包括Java、Python、ruby、PHP、C#、JavaScript。

3.3 平臺架構圖

3.4 各個功能模塊

1）測試數據構造

測試人員能夠根據測試需求獲取測試數據，簡化測試步驟提升測試效率。

2）Mock服務切換

該模塊爲了知足一些特殊測試場景，將待測服務調用第三方平臺的請求轉發到Mock server，以此來模擬那些服務，提供數據進行測試。

3）UI測試腳本編輯

腳本的建立與編輯徹底是經過頁面操做的，平臺展現頁面清晰、簡潔，支持協同工做。編輯頁面仿照Robot Framework官方的Ride編輯軟件，用類Excel表格的方式建立測試用例，同時支持關鍵字搜索、參數和使用提示，下降測試人員使用平臺門檻。

腳本中使用的關鍵字分爲兩種：引用的Library和resource。library爲第三方庫，resource爲自定義關鍵字集合。Resource關鍵字給咱們提供的是一種相似於「函數」概念的用戶自定義機制。咱們能夠將一些通用的業務過程封裝爲一個關鍵字。在編寫測試用例時直接調用。一旦業務過程發生變化，咱們只須要更改關鍵字中的業務邏輯便可，而沒必要更改每一個測試用例。編寫自定義關鍵字須要考慮它的健壯性、合理性，因此在任務的分配過程當中這部分的編寫都是由具備必定編程思想的測試人員實現的。

4）UI測試腳本運行

測試執行須要選擇腳本、測試環境和Mock地址(可選)。運行過程當中能夠實時查看任務隊列中的執行狀態和歷史任務的測試報告。

3.5 UI自動化測試架構圖

4、接口測試

接口測試主要的做用是提早下降風險，不至於等到APP端開發完成才發現問題，越日後時間成本和開發成本越高，風險越大。在多團隊協做項目工期緊張的狀況下，發現較大問題再調整產品需求幾乎是不可能的，此類問題很消耗團隊士氣，團隊被突如其來的問題影響，很容易被打亂節奏。在服務端開發完成提測，服務端測試能夠有效攔截到一半左右的問題，很大程度下降風險，提升人效。

在咱們的項目中具體實施步驟以下：

• 產品經過DM上傳PRD，參與人員熟悉需求。
• 開需求分析會議，肯定需求最終版。
• 需求定稿後，開發人員抽象基礎功能、編寫UI部分，測試人員測試用例。
• 測試用例編寫完須要產品、開發、測試人員作測試用例評審。
• 開發人員根據測試用例，編寫本身具體業務的單元測試用例。前端人員和自動化測試人員制定UI自動化測試點，定義好斷言字典和模擬用戶行爲的方法名稱。自動化測試人員編寫自動化測試case。
• 開發人員開發的同時，接口測試人員根據接口文檔，編寫接口測試用例。
• 全部編碼工做完成，開發人員單元測試經過後，進行接口測試驗證，再進行UI自動化測試驗證。UI自動化測試既要測試當前需求點，也要回歸以往的case。
• 驗證都經過後，手工測試人員介入。
• 手工測試完畢，自動化CASE反覆測試經過的狀況下，進行上線。

一樣接口自動化測試也實現了web平臺化，支持自動化測試全流程，覆蓋測試環境管理、測試項目管理、測試腳本開發、測試執行、測試報告生成等流程。平臺具備良好的擴展性、易維護性，支持異步執行、定時任務，能與企業郵件系統集成發送測試報告，同時在項目不斷迭代的過程當中，測試用例能彈性調整和複用。

4.1 技術選型

1）web框架：Django

簡述：最流行的python web框架，採用了MVC的框架模式，提供全套的web開發解決方案。

優勢：

• 功能完善，自帶大量的經常使用工具，能夠快速開發。
• 開源框架，有完美的文檔支持。
• 自帶後臺管理系統，只須要幾行配置和代碼就能夠實現一個完整的後臺管理系統。
• 路由映射，具備完整強大的路由映射功能，使用正則表達式使路由配置更加靈活、簡潔。
• App設計理念，App是可插拔的，不須要了能夠直接刪除，對系統總體影響不大。

2）分佈式任務隊列：Celery

簡述：Celery 是一個分佈式隊列的管理工具, 能夠用Celery提供的接口快速實現並管理一個分佈式的任務隊列。

優勢：

• 簡單，熟悉了celery的工做流程後，配置和使用仍是比較簡單的。
• 高可用，當任務執行失敗或執行過程當中發生鏈接中斷，celery會自動嘗試從新執行任務。
• 快速，一個單進程的celery每分鐘可處理上百萬個任務。
• 靈活，幾乎celery的各個組件均可以被擴展及自定製。

3）測試框架：HttpRunner2.0

簡述：HttpRunner是一款面向 HTTP(S) 協議的通用測試框架，只需編寫維護一份YAML/JSON腳本，便可實現自動化測試、性能測試、線上監控、持續集成等多種測試需求。

優勢：

• 繼承Requests的所有特性，輕鬆實現HTTP(S)的各類測試需求。
• 採用YAML/JSON的形式描述測試場景，保障測試用例描述的統一性和可維護性。
• 藉助輔助函數，在測試腳本中輕鬆實現複雜的動態計算邏輯。
• 支持完善的測試用例分層機制，充分實現測試用例的複用。
• 結合Locust框架，無需額外的工做便可實現分佈式性能測試。
• 極強的可擴展性，輕鬆實現二次開發和Web平臺化。

4.2 接口自動化平臺架構圖

4.3 各個功能模塊

1）項目管理

用例以項目爲維度進行管理，能夠對項目進行增、刪、改、查。建立項目須要添加一些簡要描述信息，在項目列表頁面能夠選擇單個或多個項目運行。

2）模塊管理

按照待測接口所屬功能模塊進行建立，支持模塊的增、刪、改、查。建立模塊必須指定所屬的項目，在模塊列表頁面能夠選擇單個或多個模塊運行。

3）用例管理

支持用例的增、刪、改、查，建立的用例必須指定所屬的項目和模塊。用例的總體結構包括局部變量定義、請求響應hook配置、請求接口URL、請求數據、請求Header、接口斷言和接口返回值的抽取。

4）配置管理

配置內可定義全局變量和全局hook，支持配置的增、刪、改、查。

5）測試套件

經過測試套件，將服務於同一個測試目的或同一運行環境下的一系列測試用例有機的組合起來。支持測試套件的增、刪、改、查。

6）Json Schema管理

接口測試斷言部分採用Json Schema進行json數據內容校驗。每一個接口對應着一個Json Schema的配置。支持增、刪、改、查。

7）報告管理

支持測試報告的可持久化存儲，能夠在線查看、下載和刪除。報告基於extentreport實現。

8）測試環境管理

錄入新的測試環境信息，支持增、刪、改、查。

9）用例執行

執行方式分爲同步和異步兩種，能夠按照項目、模塊、用例和測試套件執行。手動觸發須要選擇運行環境和執行方式，定時任務執行支持添加項目級別和模塊集合，遵循crontab表達式。

4.4 接口自動化測試架構圖(引自官方文檔)

做者：宜信綜合理財研發部馬宗澤、周政、黃雅哲

來源：宜信技術學院