“如何保證品質”一直是産品或項目過程中關注的焦點，而測試是産品品質把控環節中非常關鍵的部分。本文結合我們的實踐經驗，總結出一套有效的自動化測試組合拳。
一、背景
我們的測試工作經曆了以下四個階段。
第一階段，産品需求評審完成，開發團隊實作功能開發，然後草草提測，不寫單元測試。測試人員進行人工測試，沒有工具或系統做輔助，測試用例編寫是在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端開發完成才發現問題，越往後時間成本和開發成本越高，風險越大。在多團隊協作項目工期緊張的情況下，發現較大問題再調整産品需求幾乎是不可能的，此類問題很消耗團隊士氣，團隊被突如其來的問題影響，很容易被打亂節奏。在服務端開發完成提測，服務端測試可以有效攔截到一半左右的問題，很大程度降低風險，提高人效。
在我們的項目中具體實施步驟如下：
- 需求定稿後，開發人員抽象基礎功能、編寫UI部分，測試人員測試用例。
- 開發人員根據測試用例，編寫自己具體業務的單元測試用例。前端人員和自動化測試人員制定UI自動化測試點，定義好斷言字典和模拟使用者行為的方法名稱。自動化測試人員編寫自動化測試case。
同樣接口自動化測試也實作了web平台化，支援自動化測試全流程，覆寫測試環境管理、測試項目管理、測試腳本開發、測試執行、測試報告生成等流程。平台具有良好的擴充性、易維護性，支援異步執行、定時任務，能與企業郵件系統內建發送測試報告，同時在項目不斷疊代的過程中，測試用例能彈性調整和複用。
4.1 技術選型
1）web架構：Django
簡述：最流行的python web架構，采用了MVC的架構模式，提供全套的web開發解決方案。
- 功能完善，自帶大量的常用工具，可以快速開發。
- 開源架構，有完美的文檔支援。
- 自帶背景管理系統，隻需要幾行配置和代碼就可以實作一個完整的背景管理系統。
- 路由映射，具有完整強大的路由映射功能，使用正規表達式使路由配置更加靈活、簡潔。
- App設計理念，App是可插拔的，不需要了可以直接删除，對系統整體影響不大。
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 接口自動化測試架構圖(引自官方文檔)
作者：宜信綜合理财研發部馬宗澤、周政、黃雅哲
來源：宜信技術學院