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

2019 年 10 月 4 日
筆記

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

一、背景

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

第一階段，產品需求評審完成，開發團隊實現功能開發，然後草草提測，不寫單元測試。測試人員進行人工測試，沒有工具或系統做輔助，測試用例編寫是在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平台化，支援自動化測試全流程，覆蓋測試環境管理、測試項目管理、測試腳本開發、測試執行、測試報告生成等流程。平台具有良好的擴展性、易維護性，支援非同步執行、定時任務，能與企業郵件系統集成發送測試報告，同時在項目不斷迭代的過程中，測試用例能彈性調整和復用。