“如何保證質(zhì)量”一直是產(chǎn)品或項(xiàng)目過(guò)程中關(guān)注的焦點(diǎn)，而測(cè)試是產(chǎn)品質(zhì)量把控環(huán)節(jié)中非常關(guān)鍵的部分。本文結(jié)合我們的實(shí)踐經(jīng)驗(yàn)，總結(jié)出一套有效的自動(dòng)化測(cè)試組合拳。
“如何保證質(zhì)量”一直是產(chǎn)品或項(xiàng)目過(guò)程中關(guān)注的焦點(diǎn)，而測(cè)試是產(chǎn)品質(zhì)量把控環(huán)節(jié)中非常關(guān)鍵的部分。本文結(jié)合我們的實(shí)踐經(jīng)驗(yàn)，總結(jié)出一套有效的自動(dòng)化測(cè)試組合拳。
一、背景
我們的測(cè)試工作經(jīng)歷了以下四個(gè)階段。第一階段，產(chǎn)品需求評(píng)審?fù)瓿?，開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)功能開(kāi)發(fā)，然后草草提測(cè)，不寫(xiě)單元測(cè)試。測(cè)試人員進(jìn)行人工測(cè)試，沒(méi)有工具或系統(tǒng)做輔助，測(cè)試用例編寫(xiě)是在excel或腦圖中呈現(xiàn)。這個(gè)階段只對(duì)業(yè)務(wù)熟悉，開(kāi)發(fā)只關(guān)注功能實(shí)現(xiàn)。第二階段，產(chǎn)品需求評(píng)審?fù)瓿桑_(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)功能開(kāi)發(fā)，寫(xiě)自身功能相關(guān)的單元測(cè)試，組長(zhǎng)review組內(nèi)代碼。測(cè)試方面，依然處于人工檢測(cè)功能測(cè)試階段，但開(kāi)始有一些相關(guān)的小工具輔助測(cè)試。在兩輪或多輪測(cè)試情況下，回歸一直是一個(gè)問(wèn)題，還有分支測(cè)試完成，主干回歸的過(guò)程，測(cè)試環(huán)境、預(yù)發(fā)布環(huán)境、灰度環(huán)境、線上環(huán)境等測(cè)試回歸效率很低，人工測(cè)試在這方面的不足格外明顯。第三階段，隨著業(yè)務(wù)的發(fā)展產(chǎn)品功能需要快速上線，同時(shí)系統(tǒng)技術(shù)不斷迭代，質(zhì)量也面臨著從未有過(guò)的挑戰(zhàn)，人肉戰(zhàn)術(shù)不是長(zhǎng)久之計(jì)。在此階段部門做了很多改進(jìn)，引入和開(kāi)發(fā)了很多測(cè)試輔助工具，如項(xiàng)目管理工具、測(cè)試用例管理工具、BUG管理工具、自動(dòng)發(fā)布系統(tǒng)、自動(dòng)打包等。
- 搭建測(cè)試用例管理工具，方便編寫(xiě)及后期跟蹤用例。一輪二輪測(cè)試人員如何分配；用例狀態(tài)的管理是通過(guò)、掛起還是失敗，一目了然。
- BUG管理工具，主要是給開(kāi)發(fā)和測(cè)試人員使用，通過(guò)文字和圖片結(jié)合的方式描述功能問(wèn)題，減少了開(kāi)發(fā)和測(cè)試的溝通成本。
- 項(xiàng)目方面也開(kāi)發(fā)出項(xiàng)目管理工具，方便查看項(xiàng)目狀態(tài)和人力資源情況，在項(xiàng)目中做到很好的呈現(xiàn)。
- 在此階段我們開(kāi)始研發(fā)UI自動(dòng)化測(cè)試工具，直觀的想法是減少人工測(cè)試成本，提高測(cè)試效率。
- 自動(dòng)化部署系統(tǒng)讓開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境、灰度環(huán)境和線上環(huán)境做到很好的隔離，每個(gè)階段更清晰，避免相互干擾引起的問(wèn)題。
- APP方面結(jié)合Jenkins可以實(shí)現(xiàn)自動(dòng)打包，測(cè)試起來(lái)做到了開(kāi)發(fā)和測(cè)試都以版本控制系統(tǒng)為主。
第四階段，因?yàn)闇y(cè)試往往是最后一個(gè)環(huán)節(jié)，風(fēng)險(xiǎn)較大，“怎么實(shí)現(xiàn)降低風(fēng)險(xiǎn)提高人效，測(cè)試用例可以復(fù)用”變成了我們這個(gè)階段的主要工作。之前的流程是開(kāi)發(fā)完成提測(cè)，做一次冒煙。因?yàn)槲覀兊漠a(chǎn)品是互聯(lián)網(wǎng)金融APP，APP有服務(wù)端開(kāi)發(fā)和前端開(kāi)發(fā)，像web、wap、anroid、IOS等渠道，在研發(fā)過(guò)程中經(jīng)常會(huì)出現(xiàn)以下場(chǎng)景：
- 需求只是項(xiàng)目中的一小部分，測(cè)試問(wèn)產(chǎn)品要不要全量測(cè)？產(chǎn)品擔(dān)心這次需求的研發(fā)會(huì)影響到其他部分，就要求全量測(cè)試，于是測(cè)試的工期會(huì)拉得很長(zhǎng)，拉長(zhǎng)了需求的整個(gè)工期。
- 測(cè)試抱怨開(kāi)發(fā)的BUG多，還有阻塞流程的BUG，需要等待開(kāi)發(fā)解決BUG后才能繼續(xù)測(cè)試，導(dǎo)致整個(gè)測(cè)試工期加長(zhǎng)。
- 手工測(cè)試偶有疏忽造成漏測(cè)試的點(diǎn)，需求上線后，客戶反饋BUG。
產(chǎn)品上線時(shí)間有deadline；測(cè)試時(shí)間長(zhǎng)，擠占開(kāi)發(fā)時(shí)間；測(cè)試人手不夠；測(cè)試的準(zhǔn)確性達(dá)不到要求...要解決這些問(wèn)題，必然要做自動(dòng)化測(cè)試方案。針對(duì)業(yè)務(wù)和測(cè)試開(kāi)發(fā)同事的特點(diǎn)，我們從單元測(cè)試、接口測(cè)試、UI自動(dòng)化測(cè)試三個(gè)方面做了有效銜接和可持續(xù)使用的自動(dòng)化測(cè)試方案。服務(wù)端開(kāi)發(fā)完成，接口測(cè)試開(kāi)始介入。接口測(cè)試前期使用一些小工具，會(huì)在小工具里寫(xiě)一些腳本，來(lái)方便測(cè)試過(guò)程中的功能多次回歸檢驗(yàn)，是否有更好的方式來(lái)做這件事，于是我們搭建了接口自動(dòng)化系統(tǒng)。之前測(cè)試是只對(duì)UI界面做功能測(cè)試，我們現(xiàn)在還實(shí)現(xiàn)了單元測(cè)試、UI自動(dòng)化測(cè)試、接口自動(dòng)化測(cè)試。第五階段，測(cè)試團(tuán)隊(duì)全部人員轉(zhuǎn)型測(cè)開(kāi)，部分成員處在人工測(cè)試和自動(dòng)化測(cè)試的邊界上，實(shí)際上我們一直在做內(nèi)訓(xùn)，讓團(tuán)隊(duì)整體能更快地轉(zhuǎn)型成為一個(gè)測(cè)試開(kāi)發(fā)團(tuán)隊(duì)。這個(gè)階段對(duì)成員要求相對(duì)較高，主要技術(shù)語(yǔ)言是python，還要對(duì)基礎(chǔ)的系統(tǒng)架構(gòu)及運(yùn)維知識(shí)有更多了解，團(tuán)隊(duì)內(nèi)部正在開(kāi)發(fā)測(cè)試項(xiàng)目看板、重寫(xiě)用例管理工具、升級(jí)接口自動(dòng)化工具等，后期計(jì)劃實(shí)現(xiàn)APP多設(shè)備管理及測(cè)試。還有一些測(cè)試沒(méi)有提到，但也包括在主流程中，比如安全測(cè)試、兼容性測(cè)試、分辨率測(cè)試等。
- 產(chǎn)品通過(guò)DM上傳PRD，參與人員熟悉需求。
- 開(kāi)需求分析會(huì)議，確定需求最終版。
- 需求定稿后，開(kāi)發(fā)人員抽象基礎(chǔ)功能、編寫(xiě)UI部分，測(cè)試人員通過(guò)testlink寫(xiě)測(cè)試用例。
- 測(cè)試用例編寫(xiě)完需要產(chǎn)品、開(kāi)發(fā)、測(cè)試人員做測(cè)試用例評(píng)審。
- 開(kāi)發(fā)人員根據(jù)測(cè)試用例，編寫(xiě)自己具體業(yè)務(wù)的單元測(cè)試用例。前端人員和自動(dòng)化測(cè)試人員制定UI自動(dòng)化測(cè)試點(diǎn)，定義好斷言字典和模擬用戶行為的方法名稱，自動(dòng)化測(cè)試人員編寫(xiě)自動(dòng)化測(cè)試case。
- 開(kāi)發(fā)人員開(kāi)發(fā)的同時(shí)，接口測(cè)試人員根據(jù)接口文檔，編寫(xiě)接口測(cè)試用例。
- 所有編碼工作完成，開(kāi)發(fā)人員單元測(cè)試通過(guò)后，進(jìn)行接口測(cè)試驗(yàn)證，再進(jìn)行UI自動(dòng)化測(cè)試驗(yàn)證。UI自動(dòng)化測(cè)試既要測(cè)試當(dāng)前需求點(diǎn)，也要回歸以往的case。
- 驗(yàn)證都通過(guò)后，手工測(cè)試人員介入。
- 手工測(cè)試完畢，自動(dòng)化CASE反復(fù)測(cè)試通過(guò)的情況下，進(jìn)行上線。
接下來(lái)分別介紹團(tuán)隊(duì)在單元測(cè)試、服務(wù)層自動(dòng)化測(cè)試、UI層自動(dòng)化測(cè)試的具體技術(shù)實(shí)現(xiàn)。
二、單元測(cè)試
單元測(cè)試是對(duì)代碼實(shí)現(xiàn)邏輯做測(cè)試，整體項(xiàng)目環(huán)節(jié)比較靠前，所以成本最小也最有效，但對(duì)開(kāi)發(fā)人員的綜合能力要求較高。
前端代碼中，用戶交互的部分交給UI自動(dòng)化測(cè)試，而作為業(yè)務(wù)基礎(chǔ)的類和方法，適用單元測(cè)試，我們項(xiàng)目使用測(cè)試庫(kù)mocha和斷言庫(kù)chai，配合開(kāi)發(fā)工具WEBSTORM，可以非常方便地檢測(cè)代碼通過(guò)性。比如我們開(kāi)發(fā)的公用方法叫tools.js，使用mocha來(lái)測(cè)試它的文件是tools.test.js，如下圖：
三、UI自動(dòng)化測(cè)試
UI自動(dòng)化測(cè)試的目標(biāo)有兩個(gè)：回歸測(cè)試和測(cè)試準(zhǔn)入，也就是開(kāi)發(fā)完畢后，必須通過(guò)UI自動(dòng)化的測(cè)試，方可進(jìn)入手工測(cè)試階段，以節(jié)省手工測(cè)試的工作量，縮短測(cè)試工期。UI自動(dòng)化測(cè)試的難點(diǎn)在于產(chǎn)品多變，而case和UI是強(qiáng)關(guān)聯(lián)，如果UI變更，就會(huì)導(dǎo)致Case失效。如何解決case的穩(wěn)定性，使之不受UI的影響，成為我們的重要目標(biāo)。經(jīng)過(guò)反復(fù)嘗試，我們選擇了這樣的方案。測(cè)試工具對(duì)dom的選取，不再使用ID或者XPATH，而由前端人員在頁(yè)面上定義專門用于UI自動(dòng)化的屬性，測(cè)試工具需要的斷言也由前端人員在場(chǎng)景觸發(fā)時(shí)輸出到頁(yè)面中供測(cè)試工具抓取。測(cè)試工具和前端代碼維護(hù)共同的字典，保證雙方取值的正確性。我們?cè)诿總€(gè)頁(yè)面都有一個(gè)ID名為assertWord的隱藏div，用來(lái)存放斷言的值供測(cè)試工具抓取，用戶不同操作的時(shí)候，會(huì)去更改這個(gè)值。
3.1 拿風(fēng)險(xiǎn)測(cè)評(píng)頁(yè)舉例
進(jìn)入頁(yè)面的時(shí)候，會(huì)有
測(cè)試工具抓取到riskPage，說(shuō)明進(jìn)入到了風(fēng)險(xiǎn)測(cè)評(píng)頁(yè)。當(dāng)用戶勾選完選項(xiàng)提交問(wèn)卷后，如果接口返回正確，前端代碼如下：
我們?cè)趶棾鼋Y(jié)果的時(shí)候，去更改assertWord的值，供測(cè)試工具斷言。
通過(guò)前端給測(cè)試工具拋值的方式，做到了case和UI的解耦。我們選擇前端來(lái)處理的原因是：UI改變也是前端來(lái)做，拋值也是前端來(lái)做，同一個(gè)人做相比前端和測(cè)試兩個(gè)人做，避免了溝通產(chǎn)生的疏漏。另外，對(duì)于用戶操作的模擬，有時(shí)候測(cè)試工具不如前端編寫(xiě)方便，比如這個(gè)風(fēng)險(xiǎn)測(cè)評(píng)頁(yè)面有很多道題目，測(cè)試工具要是模擬用戶挨個(gè)答題，相當(dāng)費(fèi)時(shí)間，而前端則只需要很少的代碼就能完成，如圖：
所以我們編寫(xiě)了很多模擬用戶行為的方法，供測(cè)試工具調(diào)用。
目前UI自動(dòng)化測(cè)試已實(shí)現(xiàn)了web平臺(tái)化，功能測(cè)試人員通過(guò)web頁(yè)面來(lái)組織、編輯、執(zhí)行RFW（robotFrameWork）測(cè)試用例腳本，將測(cè)試用例的管理和執(zhí)行統(tǒng)一到系統(tǒng)中。與傳統(tǒng)的自動(dòng)化測(cè)試相比，支持協(xié)同工作、分布式測(cè)試執(zhí)行，提高了測(cè)試效率，同時(shí)也避免了功能測(cè)試人員在本地搭建一系列測(cè)試環(huán)境。
3.2 技術(shù)選型
簡(jiǎn)述：Flask是一個(gè)使用Python編寫(xiě)的輕量級(jí)Web應(yīng)用框架。
- 輕巧，相較于大型框架Django，flask更適合小型web項(xiàng)目。
- 簡(jiǎn)潔，不需要復(fù)雜的分層和邏輯，框架內(nèi)建了很多功能。
- 入門簡(jiǎn)單，即便沒(méi)有多少web開(kāi)發(fā)經(jīng)驗(yàn)，也能很快做出網(wǎng)站。
2）分布式任務(wù)隊(duì)列：Celery簡(jiǎn)述：Celery 是一個(gè)分布式隊(duì)列的管理工具, 可以用Celery提供的接口快速實(shí)現(xiàn)并管理一個(gè)分布式的任務(wù)隊(duì)列。
- 簡(jiǎn)單，熟悉了celery的工作流程后，配置和使用還是比較簡(jiǎn)單的。
- 高可用，當(dāng)任務(wù)執(zhí)行失敗或執(zhí)行過(guò)程中發(fā)生連接中斷，celery會(huì)自動(dòng)嘗試重新執(zhí)行任務(wù)。
- 快速，一個(gè)單進(jìn)程的celery每分鐘可處理上百萬(wàn)個(gè)任務(wù)。
- 靈活，幾乎celery的各個(gè)組件都可以被擴(kuò)展及自定制。
3）測(cè)試框架：Robot Framework簡(jiǎn)述：Robot Framework是一個(gè)基于Python的、可擴(kuò)展的關(guān)鍵字驅(qū)動(dòng)的測(cè)試自動(dòng)化框架，用于端到端驗(yàn)收測(cè)試和驗(yàn)收測(cè)試驅(qū)動(dòng)開(kāi)發(fā)。
- 門檻低，通過(guò)使用關(guān)鍵字驅(qū)動(dòng)測(cè)試（KDT）方法簡(jiǎn)化了自動(dòng)化測(cè)試過(guò)程，方便測(cè)試人員創(chuàng)建易讀的測(cè)試。
- 易于擴(kuò)展，可以自定義測(cè)試庫(kù)。
- 功能全面，支持WEB測(cè)試、SSH、telnet、API接口多種測(cè)試方式。
4）UI測(cè)試庫(kù)：SeleniumLibrary簡(jiǎn)述：SeleniumLibrary是針對(duì)Robot Framework開(kāi)發(fā)的Selenium庫(kù)，它也是Robot Framework下最流行的庫(kù)之一，主要用于編寫(xiě)Web UI自動(dòng)化測(cè)試。
- 多瀏覽器支持，包括Firefox、Chrome、IE、Opera、Safari。
- 多平臺(tái)支持，包括Linux 、windows、Mac。
- 多語(yǔ)言支持，包括Java、Python、ruby、PHP、C#、JavaScript。
3.3 平臺(tái)架構(gòu)圖
3.4 各個(gè)功能模塊
1）測(cè)試數(shù)據(jù)構(gòu)造測(cè)試人員可以根據(jù)測(cè)試需求獲取測(cè)試數(shù)據(jù)，簡(jiǎn)化測(cè)試步驟提高測(cè)試效率。
該模塊為了滿足一些特殊測(cè)試場(chǎng)景，將待測(cè)服務(wù)調(diào)用第三方平臺(tái)的請(qǐng)求轉(zhuǎn)發(fā)到Mock server，以此來(lái)模擬那些服務(wù)，提供數(shù)據(jù)進(jìn)行測(cè)試。
腳本的創(chuàng)建與編輯完全是通過(guò)頁(yè)面操作的，平臺(tái)展示頁(yè)面清晰、簡(jiǎn)潔，支持協(xié)同工作。編輯頁(yè)面仿照Robot Framework官方的Ride編輯軟件，用類Excel表格的方式創(chuàng)建測(cè)試用例，同時(shí)支持關(guān)鍵字搜索、參數(shù)和使用提示，降低測(cè)試人員使用平臺(tái)門檻。
腳本中使用的關(guān)鍵字分為兩種：引用的Library和resource。library為第三方庫(kù)，resource為自定義關(guān)鍵字集合。Resource關(guān)鍵字給我們提供的是一種類似于“函數(shù)”概念的用戶自定義機(jī)制。我們可以將一些通用的業(yè)務(wù)過(guò)程封裝為一個(gè)關(guān)鍵字，在編寫(xiě)測(cè)試用例時(shí)直接調(diào)用。一旦業(yè)務(wù)過(guò)程發(fā)生變化，我們只需要更改關(guān)鍵字中的業(yè)務(wù)邏輯即可，而不必更改每個(gè)測(cè)試用例。編寫(xiě)自定義關(guān)鍵字需要考慮它的健壯性、合理性，所以在任務(wù)的分配過(guò)程中這部分的編寫(xiě)都是由具有一定編程思想的測(cè)試人員實(shí)現(xiàn)的。
測(cè)試執(zhí)行需要選擇腳本、測(cè)試環(huán)境和Mock地址(可選)。運(yùn)行過(guò)程中可以實(shí)時(shí)查看任務(wù)隊(duì)列中的執(zhí)行狀態(tài)和歷史任務(wù)的測(cè)試報(bào)告。
3.5 UI自動(dòng)化測(cè)試架構(gòu)圖
四、接口測(cè)試
接口測(cè)試主要的作用是提前降低風(fēng)險(xiǎn)，不至于等到APP端開(kāi)發(fā)完成才發(fā)現(xiàn)問(wèn)題，越往后時(shí)間成本和開(kāi)發(fā)成本越高，風(fēng)險(xiǎn)越大。在多團(tuán)隊(duì)協(xié)作項(xiàng)目工期緊張的情況下，發(fā)現(xiàn)較大問(wèn)題再調(diào)整產(chǎn)品需求幾乎是不可能的，此類問(wèn)題很消耗團(tuán)隊(duì)士氣，團(tuán)隊(duì)被突如其來(lái)的問(wèn)題影響，很容易被打亂節(jié)奏。在服務(wù)端開(kāi)發(fā)完成提測(cè)，服務(wù)端測(cè)試可以有效攔截到一半左右的問(wèn)題，很大程度降低風(fēng)險(xiǎn)，提高人效。在我們的項(xiàng)目中具體實(shí)施步驟如下：
- 產(chǎn)品通過(guò)DM上傳PRD，參與人員熟悉需求。
- 開(kāi)需求分析會(huì)議，確定需求最終版。
- 需求定稿后，開(kāi)發(fā)人員抽象基礎(chǔ)功能、編寫(xiě)UI部分，測(cè)試人員寫(xiě)測(cè)試用例。
- 測(cè)試用例編寫(xiě)完需要產(chǎn)品、開(kāi)發(fā)、測(cè)試人員做測(cè)試用例評(píng)審。
- 開(kāi)發(fā)人員根據(jù)測(cè)試用例，編寫(xiě)自己具體業(yè)務(wù)的單元測(cè)試用例。前端人員和自動(dòng)化測(cè)試人員制定UI自動(dòng)化測(cè)試點(diǎn)，定義好斷言字典和模擬用戶行為的方法名稱。自動(dòng)化測(cè)試人員編寫(xiě)自動(dòng)化測(cè)試case。
- 開(kāi)發(fā)人員開(kāi)發(fā)的同時(shí)，接口測(cè)試人員根據(jù)接口文檔，編寫(xiě)接口測(cè)試用例。- 所有編碼工作完成，開(kāi)發(fā)人員單元測(cè)試通過(guò)后，進(jìn)行接口測(cè)試驗(yàn)證，再進(jìn)行UI自動(dòng)化測(cè)試驗(yàn)證。UI自動(dòng)化測(cè)試既要測(cè)試當(dāng)前需求點(diǎn)，也要回歸以往的case。
- 驗(yàn)證都通過(guò)后，手工測(cè)試人員介入。
- 手工測(cè)試完畢，自動(dòng)化CASE反復(fù)測(cè)試通過(guò)的情況下，進(jìn)行上線。
同樣接口自動(dòng)化測(cè)試也實(shí)現(xiàn)了web平臺(tái)化，支持自動(dòng)化測(cè)試全流程，覆蓋測(cè)試環(huán)境管理、測(cè)試項(xiàng)目管理、測(cè)試腳本開(kāi)發(fā)、測(cè)試執(zhí)行、測(cè)試報(bào)告生成等流程。平臺(tái)具有良好的擴(kuò)展性、易維護(hù)性，支持異步執(zhí)行、定時(shí)任務(wù)，能與企業(yè)郵件系統(tǒng)集成發(fā)送測(cè)試報(bào)告，同時(shí)在項(xiàng)目不斷迭代的過(guò)程中，測(cè)試用例能彈性調(diào)整和復(fù)用。
4.1 技術(shù)選型
簡(jiǎn)述：最流行的python web框架，采用了MVC的框架模式，提供全套的web開(kāi)發(fā)解決方案。
- 功能完善，自帶大量的常用工具，可以快速開(kāi)發(fā)。
- 自帶后臺(tái)管理系統(tǒng)，只需要幾行配置和代碼就可以實(shí)現(xiàn)一個(gè)完整的后臺(tái)管理系統(tǒng)。
- 路由映射，具有完整強(qiáng)大的路由映射功能，使用正則表達(dá)式使路由配置更加靈活、簡(jiǎn)潔。
- App設(shè)計(jì)理念，App是可插拔的，不需要了可以直接刪除，對(duì)系統(tǒng)整體影響不大。
2）分布式任務(wù)隊(duì)列：Celery簡(jiǎn)述：Celery 是一個(gè)分布式隊(duì)列的管理工具, 可以用Celery提供的接口快速實(shí)現(xiàn)并管理一個(gè)分布式的任務(wù)隊(duì)列。
- 簡(jiǎn)單，熟悉了celery的工作流程后，配置和使用還是比較簡(jiǎn)單的。
- 高可用，當(dāng)任務(wù)執(zhí)行失敗或執(zhí)行過(guò)程中發(fā)生連接中斷，celery會(huì)自動(dòng)嘗試重新執(zhí)行任務(wù)。
- 快速，一個(gè)單進(jìn)程的celery每分鐘可處理上百萬(wàn)個(gè)任務(wù)。
- 靈活，幾乎celery的各個(gè)組件都可以被擴(kuò)展及自定制。
簡(jiǎn)述：HttpRunner是一款面向 HTTP(S) 協(xié)議的通用測(cè)試框架，只需編寫(xiě)維護(hù)一份YAML/JSON腳本，即可實(shí)現(xiàn)自動(dòng)化測(cè)試、性能測(cè)試、線上監(jiān)控、持續(xù)集成等多種測(cè)試需求。
- 繼承Requests的全部特性，輕松實(shí)現(xiàn)HTTP(S)的各種測(cè)試需求。
- 采用YAML/JSON的形式描述測(cè)試場(chǎng)景，保障測(cè)試用例描述的統(tǒng)一性和可維護(hù)性。
- 借助輔助函數(shù)，在測(cè)試腳本中輕松實(shí)現(xiàn)復(fù)雜的動(dòng)態(tài)計(jì)算邏輯。
- 支持完善的測(cè)試用例分層機(jī)制，充分實(shí)現(xiàn)測(cè)試用例的復(fù)用。
- 結(jié)合Locust框架，無(wú)需額外的工作即可實(shí)現(xiàn)分布式性能測(cè)試。
- 極強(qiáng)的可擴(kuò)展性，輕松實(shí)現(xiàn)二次開(kāi)發(fā)和Web平臺(tái)化。
4.2 接口自動(dòng)化平臺(tái)架構(gòu)圖
4.3 各個(gè)功能模塊
用例以項(xiàng)目為維度進(jìn)行管理，可以對(duì)項(xiàng)目進(jìn)行增、刪、改、查。創(chuàng)建項(xiàng)目需要添加一些簡(jiǎn)要描述信息，在項(xiàng)目列表頁(yè)面可以選擇單個(gè)或多個(gè)項(xiàng)目運(yùn)行。
按照待測(cè)接口所屬功能模塊進(jìn)行創(chuàng)建，支持模塊的增、刪、改、查。創(chuàng)建模塊必須指定所屬的項(xiàng)目，在模塊列表頁(yè)面可以選擇單個(gè)或多個(gè)模塊運(yùn)行。
支持用例的增、刪、改、查，創(chuàng)建的用例必須指定所屬的項(xiàng)目和模塊。用例的整體結(jié)構(gòu)包括局部變量定義、請(qǐng)求響應(yīng)hook配置、請(qǐng)求接口URL、請(qǐng)求數(shù)據(jù)、請(qǐng)求Header、接口斷言和接口返回值的抽取
配置內(nèi)可定義全局變量和全局hook，支持配置的增、刪、改、查。通過(guò)測(cè)試套件，將服務(wù)于同一個(gè)測(cè)試目的或同一運(yùn)行環(huán)境下的一系列測(cè)試用例有機(jī)的組合起來(lái)。支持測(cè)試套件的增、刪、改、查。
接口測(cè)試斷言部分采用Json Schema進(jìn)行json數(shù)據(jù)內(nèi)容校驗(yàn)。每個(gè)接口對(duì)應(yīng)著一個(gè)Json Schema的配置。支持增、刪、改、查。
支持測(cè)試報(bào)告的可持久化存儲(chǔ)，可以在線查看、下載和刪除。報(bào)告基于extentreport實(shí)現(xiàn)。
8）測(cè)試環(huán)境管理
錄入新的測(cè)試環(huán)境信息，支持增、刪、改、查。
執(zhí)行方式分為同步和異步兩種，可以按照項(xiàng)目、模塊、用例和測(cè)試套件執(zhí)行。手動(dòng)觸發(fā)需要選擇運(yùn)行環(huán)境和執(zhí)行方式，定時(shí)任務(wù)執(zhí)行支持添加項(xiàng)目級(jí)別和模塊集合，遵循crontab表達(dá)式。
4.4 接口自動(dòng)化測(cè)試架構(gòu)圖(引自官方文檔)
【本文是51CTO專欄機(jī)構(gòu)宜信技術(shù)學(xué)院的原創(chuàng)文章，微信公眾號(hào)“宜信技術(shù)學(xué)院( id: CE_TECH)”】
戳這里，看該作者更多好文
