“如何保證質(zhì)量”一直是產(chǎn)品或項(xiàng)目過程中關(guān)注的焦點(diǎn)，而測試是產(chǎn)品質(zhì)量把控環(huán)節(jié)中非常關(guān)鍵的部分。本文結(jié)合我們的實(shí)踐經(jīng)驗(yàn)，總結(jié)出一套有效的自動化測試組合拳。

一、背景

 

我們的測試工作經(jīng)歷了以下四個階段。

第一階段，產(chǎn)品需求評審?fù)瓿?，開發(fā)團(tuán)隊(duì)實(shí)現(xiàn)功能開發(fā)，然后草草提測，不寫單元測試。測試人員進(jìn)行人工測試，沒有工具或系統(tǒng)做輔助，測試用例編寫是在excel或腦圖中呈現(xiàn)。這個階段只對業(yè)務(wù)熟悉，開發(fā)只關(guān)注功能實(shí)現(xiàn)。

第二階段，產(chǎn)品需求評審?fù)瓿?，開發(fā)團(tuán)隊(duì)實(shí)現(xiàn)功能開發(fā)，寫自身功能相關(guān)的單元測試，組長review組內(nèi)代碼。測試方面，依然處于人工檢測功能測試階段，但開始有一些相關(guān)的小工具輔助測試。在兩輪或多輪測試情況下，回歸一直是一個問題，還有分支測試完成，主干回歸的過程，測試環(huán)境、預(yù)發(fā)布環(huán)境、灰度環(huán)境、線上環(huán)境等測試回歸效率很低，人工測試在這方面的不足格外明顯。

第三階段，隨著業(yè)務(wù)的發(fā)展產(chǎn)品功能需要快速上線，同時系統(tǒng)技術(shù)不斷迭代，質(zhì)量也面臨著從未有過的挑戰(zhàn)，人肉戰(zhàn)術(shù)不是長久之計(jì)。在此階段部門做了很多改進(jìn)，引入和開發(fā)了很多測試輔助工具，如項(xiàng)目管理工具、測試用例管理工具、BUG管理工具、自動發(fā)布系統(tǒng)、自動打包等。

 

 

• 搭建測試用例管理工具，方便編寫及后期跟蹤用例。一輪二輪測試人員如何分配；用例狀態(tài)的管理是通過、掛起還是失敗，一目了然。 
• BUG管理工具，主要是給開發(fā)和測試人員使用，通過文字和圖片結(jié)合的方式描述功能問題，減少了開發(fā)和測試的溝通成本。 
• 項(xiàng)目方面也開發(fā)出項(xiàng)目管理工具，方便查看項(xiàng)目狀態(tài)和人力資源情況，在項(xiàng)目中做到很好的呈現(xiàn)。 
• 在此階段我們開始研發(fā)UI自動化測試工具，直觀的想法是減少人工測試成本，提高測試效率。 
• 自動化部署系統(tǒng)讓開發(fā)環(huán)境、測試環(huán)境、灰度環(huán)境和線上環(huán)境做到很好的隔離，每個階段更清晰，避免相互干擾引起的問題。 
• APP方面結(jié)合Jenkins可以實(shí)現(xiàn)自動打包，測試起來做到了開發(fā)和測試都以版本控制系統(tǒng)為主。

 

 

第四階段，因?yàn)闇y試往往是最后一個環(huán)節(jié)，風(fēng)險(xiǎn)較大，“怎么實(shí)現(xiàn)降低風(fēng)險(xiǎn)提高人效，測試用例可以復(fù)用”變成了我們這個階段的主要工作。之前的流程是開發(fā)完成提測，做一次冒煙。因?yàn)槲覀兊漠a(chǎn)品是互聯(lián)網(wǎng)金融APP，APP有服務(wù)端開發(fā)和前端開發(fā)，像web、wap、anroid、IOS等渠道，在研發(fā)過程中經(jīng)常會出現(xiàn)以下場景：

 

• 需求只是項(xiàng)目中的一小部分，測試問產(chǎn)品要不要全量測？產(chǎn)品擔(dān)心這次需求的研發(fā)會影響到其他部分，就要求全量測試，于是測試的工期會拉得很長，拉長了需求的整個工期。 
• 測試抱怨開發(fā)的BUG多，還有阻塞流程的BUG，需要等待開發(fā)解決BUG后才能繼續(xù)測試，導(dǎo)致整個測試工期加長。 
• 手工測試偶有疏忽造成漏測試的點(diǎn)，需求上線后，客戶反饋BUG。

 

產(chǎn)品上線時間有deadline；測試時間長，擠占開發(fā)時間；測試人手不夠；測試的準(zhǔn)確性達(dá)不到要求...要解決這些問題，必然要做自動化測試方案。

針對業(yè)務(wù)和測試開發(fā)同事的特點(diǎn)，我們從單元測試、接口測試、UI自動化測試三個方面做了有效銜接和可持續(xù)使用的自動化測試方案。

服務(wù)端開發(fā)完成，接口測試開始介入。接口測試前期使用一些小工具，會在小工具里寫一些腳本，來方便測試過程中的功能多次回歸檢驗(yàn)，是否有更好的方式來做這件事，于是我們搭建了接口自動化系統(tǒng)。之前測試是只對UI界面做功能測試，我們現(xiàn)在還實(shí)現(xiàn)了單元測試、UI自動化測試、接口自動化測試。

第五階段，測試團(tuán)隊(duì)全部人員轉(zhuǎn)型測開，部分成員處在人工測試和自動化測試的邊界上，實(shí)際上我們一直在做內(nèi)訓(xùn)，讓團(tuán)隊(duì)整體能更快地轉(zhuǎn)型成為一個測試開發(fā)團(tuán)隊(duì)。這個階段對成員要求相對較高，主要技術(shù)語言是python，還要對基礎(chǔ)的系統(tǒng)架構(gòu)及運(yùn)維知識有更多了解，團(tuán)隊(duì)內(nèi)部正在開發(fā)測試項(xiàng)目看板、重寫用例管理工具、升級接口自動化工具等，后期計(jì)劃實(shí)現(xiàn)APP多設(shè)備管理及測試。還有一些測試沒有提到，但也包括在主流程中，比如安全測試、兼容性測試、分辨率測試等。

目前項(xiàng)目的整體流程是這樣的：

 

 

• 產(chǎn)品通過DM上傳PRD，參與人員熟悉需求。 
• 開需求分析會議，確定需求最終版。 
• 需求定稿后，開發(fā)人員抽象基礎(chǔ)功能、編寫UI部分，測試人員通過testlink寫測試用例。 
• 測試用例編寫完需要產(chǎn)品、開發(fā)、測試人員做測試用例評審。 
• 開發(fā)人員根據(jù)測試用例，編寫自己具體業(yè)務(wù)的單元測試用例。前端人員和自動化測試人員制定UI自動化測試點(diǎn)，定義好斷言字典和模擬用戶行為的方法名稱，自動化測試人員編寫自動化測試case。 
• 開發(fā)人員開發(fā)的同時，接口測試人員根據(jù)接口文檔，編寫接口測試用例。 
• 所有編碼工作完成，開發(fā)人員單元測試通過后，進(jìn)行接口測試驗(yàn)證，再進(jìn)行UI自動化測試驗(yàn)證。UI自動化測試既要測試當(dāng)前需求點(diǎn)，也要回歸以往的case。 
• 驗(yàn)證都通過后，手工測試人員介入。 
• 手工測試完畢，自動化CASE反復(fù)測試通過的情況下，進(jìn)行上線。

接下來分別介紹團(tuán)隊(duì)在單元測試、服務(wù)層自動化測試、UI層自動化測試的具體技術(shù)實(shí)現(xiàn)。

二、單元測試

 

 

單元測試是對代碼實(shí)現(xiàn)邏輯做測試，整體項(xiàng)目環(huán)節(jié)比較靠前，所以成本最小也最有效，但對開發(fā)人員的綜合能力要求較高。

 

 

前端代碼中，用戶交互的部分交給UI自動化測試，而作為業(yè)務(wù)基礎(chǔ)的類和方法，適用單元測試，我們項(xiàng)目使用測試庫mocha和斷言庫chai，配合開發(fā)工具WEBSTORM，可以非常方便地檢測代碼通過性。比如我們開發(fā)的公用方法叫tools.js，使用mocha來測試它的文件是tools.test.js，如下圖：

 

三、UI自動化測試

 

UI自動化測試的目標(biāo)有兩個：回歸測試和測試準(zhǔn)入，也就是開發(fā)完畢后，必須通過UI自動化的測試，方可進(jìn)入手工測試階段，以節(jié)省手工測試的工作量，縮短測試工期。

UI自動化測試的難點(diǎn)在于產(chǎn)品多變，而case和UI是強(qiáng)關(guān)聯(lián)，如果UI變更，就會導(dǎo)致Case失效。如何解決case的穩(wěn)定性，使之不受UI的影響，成為我們的重要目標(biāo)。經(jīng)過反復(fù)嘗試，我們選擇了這樣的方案。

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

 

3.1 拿風(fēng)險(xiǎn)測評頁舉例

 

我們共用的字典如圖：

進(jìn)入頁面的時候，會有

測試工具抓取到riskPage，說明進(jìn)入到了風(fēng)險(xiǎn)測評頁。當(dāng)用戶勾選完選項(xiàng)提交問卷后，如果接口返回正確，前端代碼如下：

我們在彈出結(jié)果的時候，去更改assertWord的值，供測試工具斷言。

 

 

通過前端給測試工具拋值的方式，做到了case和UI的解耦。我們選擇前端來處理的原因是：UI改變也是前端來做，拋值也是前端來做，同一個人做相比前端和測試兩個人做，避免了溝通產(chǎn)生的疏漏。

另外，對于用戶操作的模擬，有時候測試工具不如前端編寫方便，比如這個風(fēng)險(xiǎn)測評頁面有很多道題目，測試工具要是模擬用戶挨個答題，相當(dāng)費(fèi)時間，而前端則只需要很少的代碼就能完成，如圖：

 

 

所以我們編寫了很多模擬用戶行為的方法，供測試工具調(diào)用。

 

目前UI自動化測試已實(shí)現(xiàn)了web平臺化，功能測試人員通過web頁面來組織、編輯、執(zhí)行RFW（robotFrameWork）測試用例腳本，將測試用例的管理和執(zhí)行統(tǒng)一到系統(tǒng)中。與傳統(tǒng)的自動化測試相比，支持協(xié)同工作、分布式測試執(zhí)行，提高了測試效率，同時也避免了功能測試人員在本地搭建一系列測試環(huán)境。

 

3.2 技術(shù)選型

 

1）web框架：Flask

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

優(yōu)點(diǎn)：

 

• 輕巧，相較于大型框架Django，flask更適合小型web項(xiàng)目。
• 簡潔，不需要復(fù)雜的分層和邏輯，框架內(nèi)建了很多功能。
• 入門簡單，即便沒有多少web開發(fā)經(jīng)驗(yàn)，也能很快做出網(wǎng)站。

 

2）分布式任務(wù)隊(duì)列：Celery

簡述：Celery 是一個分布式隊(duì)列的管理工具, 可以用Celery提供的接口快速實(shí)現(xiàn)并管理一個分布式的任務(wù)隊(duì)列。

優(yōu)點(diǎn)：

 

• 簡單，熟悉了celery的工作流程后，配置和使用還是比較簡單的。
• 高可用，當(dāng)任務(wù)執(zhí)行失敗或執(zhí)行過程中發(fā)生連接中斷，celery會自動嘗試重新執(zhí)行任務(wù)。
• 快速，一個單進(jìn)程的celery每分鐘可處理上百萬個任務(wù)。
• 靈活，幾乎celery的各個組件都可以被擴(kuò)展及自定制。

 

3）測試框架：Robot Framework

簡述：Robot Framework是一個基于Python的、可擴(kuò)展的關(guān)鍵字驅(qū)動的測試自動化框架，用于端到端驗(yàn)收測試和驗(yàn)收測試驅(qū)動開發(fā)。

優(yōu)點(diǎn)：

 

• 門檻低，通過使用關(guān)鍵字驅(qū)動測試（KDT）方法簡化了自動化測試過程，方便測試人員創(chuàng)建易讀的測試。
• 易于擴(kuò)展，可以自定義測試庫。
• 功能全面，支持WEB測試、SSH、telnet、API接口多種測試方式。

 

4）UI測試庫：SeleniumLibrary

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

優(yōu)點(diǎn)：

 

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

 

 

3.3 平臺架構(gòu)圖

 

3.4 各個功能模塊

 

 

1）測試數(shù)據(jù)構(gòu)造

測試人員可以根據(jù)測試需求獲取測試數(shù)據(jù)，簡化測試步驟提高測試效率。

 

 

 

 

2）Mock服務(wù)切換

該模塊為了滿足一些特殊測試場景，將待測服務(wù)調(diào)用第三方平臺的請求轉(zhuǎn)發(fā)到Mock server，以此來模擬那些服務(wù)，提供數(shù)據(jù)進(jìn)行測試。

 

 

 

 

3）UI測試腳本編輯

腳本的創(chuàng)建與編輯完全是通過頁面操作的，平臺展示頁面清晰、簡潔，支持協(xié)同工作。編輯頁面仿照Robot Framework官方的Ride編輯軟件，用類Excel表格的方式創(chuàng)建測試用例，同時支持關(guān)鍵字搜索、參數(shù)和使用提示，降低測試人員使用平臺門檻。

 

 

腳本中使用的關(guān)鍵字分為兩種：引用的Library和resource。library為第三方庫，resource為自定義關(guān)鍵字集合。Resource關(guān)鍵字給我們提供的是一種類似于“函數(shù)”概念的用戶自定義機(jī)制。我們可以將一些通用的業(yè)務(wù)過程封裝為一個關(guān)鍵字，在編寫測試用例時直接調(diào)用。一旦業(yè)務(wù)過程發(fā)生變化，我們只需要更改關(guān)鍵字中的業(yè)務(wù)邏輯即可，而不必更改每個測試用例。編寫自定義關(guān)鍵字需要考慮它的健壯性、合理性，所以在任務(wù)的分配過程中這部分的編寫都是由具有一定編程思想的測試人員實(shí)現(xiàn)的。

 

 

4）UI測試腳本運(yùn)行

測試執(zhí)行需要選擇腳本、測試環(huán)境和Mock地址(可選)。運(yùn)行過程中可以實(shí)時查看任務(wù)隊(duì)列中的執(zhí)行狀態(tài)和歷史任務(wù)的測試報(bào)告。

 

 

3.5 UI自動化測試架構(gòu)圖

四、接口測試

 

接口測試主要的作用是提前降低風(fēng)險(xiǎn)，不至于等到APP端開發(fā)完成才發(fā)現(xiàn)問題，越往后時間成本和開發(fā)成本越高，風(fēng)險(xiǎn)越大。在多團(tuán)隊(duì)協(xié)作項(xiàng)目工期緊張的情況下，發(fā)現(xiàn)較大問題再調(diào)整產(chǎn)品需求幾乎是不可能的，此類問題很消耗團(tuán)隊(duì)士氣，團(tuán)隊(duì)被突如其來的問題影響，很容易被打亂節(jié)奏。在服務(wù)端開發(fā)完成提測，服務(wù)端測試可以有效攔截到一半左右的問題，很大程度降低風(fēng)險(xiǎn)，提高人效。

在我們的項(xiàng)目中具體實(shí)施步驟如下：

 

• 產(chǎn)品通過DM上傳PRD，參與人員熟悉需求。 
• 開需求分析會議，確定需求最終版。 
• 需求定稿后，開發(fā)人員抽象基礎(chǔ)功能、編寫UI部分，測試人員寫測試用例。 
• 測試用例編寫完需要產(chǎn)品、開發(fā)、測試人員做測試用例評審。 
• 開發(fā)人員根據(jù)測試用例，編寫自己具體業(yè)務(wù)的單元測試用例。前端人員和自動化測試人員制定UI自動化測試點(diǎn)，定義好斷言字典和模擬用戶行為的方法名稱。自動化測試人員編寫自動化測試case。 
• 開發(fā)人員開發(fā)的同時，接口測試人員根據(jù)接口文檔，編寫接口測試用例。- 所有編碼工作完成，開發(fā)人員單元測試通過后，進(jìn)行接口測試驗(yàn)證，再進(jìn)行UI自動化測試驗(yàn)證。UI自動化測試既要測試當(dāng)前需求點(diǎn)，也要回歸以往的case。 
• 驗(yàn)證都通過后，手工測試人員介入。 
• 手工測試完畢，自動化CASE反復(fù)測試通過的情況下，進(jìn)行上線。

 

同樣接口自動化測試也實(shí)現(xiàn)了web平臺化，支持自動化測試全流程，覆蓋測試環(huán)境管理、測試項(xiàng)目管理、測試腳本開發(fā)、測試執(zhí)行、測試報(bào)告生成等流程。平臺具有良好的擴(kuò)展性、易維護(hù)性，支持異步執(zhí)行、定時任務(wù)，能與企業(yè)郵件系統(tǒng)集成發(fā)送測試報(bào)告，同時在項(xiàng)目不斷迭代的過程中，測試用例能彈性調(diào)整和復(fù)用。

 

4.1 技術(shù)選型

 

1）web框架：Django

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

優(yōu)點(diǎn)：

 

• 功能完善，自帶大量的常用工具，可以快速開發(fā)。 
• 開源框架，有完美的文檔支持。 
• 自帶后臺管理系統(tǒng)，只需要幾行配置和代碼就可以實(shí)現(xiàn)一個完整的后臺管理系統(tǒng)。 
• 路由映射，具有完整強(qiáng)大的路由映射功能，使用正則表達(dá)式使路由配置更加靈活、簡潔。 
• App設(shè)計(jì)理念，App是可插拔的，不需要了可以直接刪除，對系統(tǒng)整體影響不大。

 

2）分布式任務(wù)隊(duì)列：Celery

簡述：Celery 是一個分布式隊(duì)列的管理工具, 可以用Celery提供的接口快速實(shí)現(xiàn)并管理一個分布式的任務(wù)隊(duì)列。

優(yōu)點(diǎn)：

 

• 簡單，熟悉了celery的工作流程后，配置和使用還是比較簡單的。 
• 高可用，當(dāng)任務(wù)執(zhí)行失敗或執(zhí)行過程中發(fā)生連接中斷，celery會自動嘗試重新執(zhí)行任務(wù)。 
• 快速，一個單進(jìn)程的celery每分鐘可處理上百萬個任務(wù)。 
• 靈活，幾乎celery的各個組件都可以被擴(kuò)展及自定制。

 

3）測試框架：HttpRunner2.0

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

優(yōu)點(diǎn)：

 

• 繼承Requests的全部特性，輕松實(shí)現(xiàn)HTTP(S)的各種測試需求。 
• 采用YAML/JSON的形式描述測試場景，保障測試用例描述的統(tǒng)一性和可維護(hù)性。 
• 借助輔助函數(shù)，在測試腳本中輕松實(shí)現(xiàn)復(fù)雜的動態(tài)計(jì)算邏輯。 
• 支持完善的測試用例分層機(jī)制，充分實(shí)現(xiàn)測試用例的復(fù)用。 
• 結(jié)合Locust框架，無需額外的工作即可實(shí)現(xiàn)分布式性能測試。 
• 極強(qiáng)的可擴(kuò)展性，輕松實(shí)現(xiàn)二次開發(fā)和Web平臺化。

 

 

 

4.2 接口自動化平臺架構(gòu)圖

4.3 各個功能模塊

 

 

1）項(xiàng)目管理

用例以項(xiàng)目為維度進(jìn)行管理，可以對項(xiàng)目進(jìn)行增、刪、改、查。創(chuàng)建項(xiàng)目需要添加一些簡要描述信息，在項(xiàng)目列表頁面可以選擇單個或多個項(xiàng)目運(yùn)行。

 

 

 

 

2）模塊管理

按照待測接口所屬功能模塊進(jìn)行創(chuàng)建，支持模塊的增、刪、改、查。創(chuàng)建模塊必須指定所屬的項(xiàng)目，在模塊列表頁面可以選擇單個或多個模塊運(yùn)行。

 

 

 

 

3）用例管理

支持用例的增、刪、改、查，創(chuàng)建的用例必須指定所屬的項(xiàng)目和模塊。用例的整體結(jié)構(gòu)包括局部變量定義、請求響應(yīng)hook配置、請求接口URL、請求數(shù)據(jù)、請求Header、接口斷言和接口返回值的抽取

 

 

 

4）配置管理

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

5）測試套件

通過測試套件，將服務(wù)于同一個測試目的或同一運(yùn)行環(huán)境下的一系列測試用例有機(jī)的組合起來。支持測試套件的增、刪、改、查。

 

 

6）Json Schema管理

接口測試斷言部分采用Json Schema進(jìn)行json數(shù)據(jù)內(nèi)容校驗(yàn)。每個接口對應(yīng)著一個Json Schema的配置。支持增、刪、改、查。

 

 

 

7）報(bào)告管理

支持測試報(bào)告的可持久化存儲，可以在線查看、下載和刪除。報(bào)告基于extentreport實(shí)現(xiàn)。

 

 

8）測試環(huán)境管理

 

錄入新的測試環(huán)境信息，支持增、刪、改、查。

 

 

9）用例執(zhí)行

執(zhí)行方式分為同步和異步兩種，可以按照項(xiàng)目、模塊、用例和測試套件執(zhí)行。手動觸發(fā)需要選擇運(yùn)行環(huán)境和執(zhí)行方式，定時任務(wù)執(zhí)行支持添加項(xiàng)目級別和模塊集合，遵循crontab表達(dá)式。

 

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

【本文是51CTO專欄機(jī)構(gòu)宜信技術(shù)學(xué)院的原創(chuàng)文章，微信公眾號“宜信技術(shù)學(xué)院( id: CE_TECH)”】

戳這里，看該作者更多好文