“如何保證質量”一直是產品或專案過程中關注的焦點，而測試是產品質量把控環節中非常關鍵的部分。本文結合我們的實踐經驗，總結出一套有效的自動化測試組合拳。

一、背景

我們的測試工作經歷了以下四個階段。

第一階段，產品需求評審完成，開發團隊實現功能開發，然後草草提測，不寫單元測試。測試人員進行人工測試，沒有工具或系統做輔助，測試用例編寫是在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層自動化測試的具體技術實現。

二、單元測試

單元測試是對程式碼實現邏輯做測試，整體專案環節比較靠前，所以成本最小也最有效，但對開發人員的綜合能力要求較高。

前端程式碼中，使用者互動的部分交給UI自動化測試，而作為業務基礎的類和方法，適用單元測試，我們專案使用測試庫mocha和斷言庫chai，配合開發工具WEBSTORM，可以非常方便地檢測程式碼通過性。比如我們開發的公用方法叫tools.js，使用mocha來測試它的檔案是tools.test.js，如下圖：

三、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自動化測試架構圖

四、介面測試

介面測試主要的作用是提前降低風險，不至於等到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 介面自動化測試架構圖(引自官方檔案)

作者：馬宗澤、周政、黃雅哲

來源：宜信技術學院