劉國慶 汪興軒

(復旦大學信息科學與工程學院 上海 200433)

0 引 言

接口測試是指Web系統(tǒng)組件間的測試，它主要用于檢測組件與組件之間的交互點[1]。在移動軟件開發(fā)領域，大多采用分層軟件體系結(jié)構(gòu)，服務提供者和消費者基于接口契約傳遞數(shù)據(jù)和上下文信息。應用軟件的數(shù)據(jù)大多來源于服務端的接口返回，持續(xù)保障接口有效返回、及時發(fā)現(xiàn)異常接口是移動軟件測試中的一個重要課題[2]。

在Web應用開發(fā)領域，客戶端服務器模型是一種被廣泛應用的網(wǎng)絡架構(gòu)，它把整套軟件系統(tǒng)劃分為客戶端和服務端[3]，即客戶端請求數(shù)據(jù)，服務端響應內(nèi)容。超文本傳輸協(xié)議是一個基于請求與響應的無狀態(tài)Web傳輸協(xié)議，因其具有傳輸效率高、占用較低的網(wǎng)絡帶寬等特點而被廣泛使用[4]。

Charles是一款被廣大Web開發(fā)者廣泛使用的HTTP/HTTPS代理服務器、監(jiān)視器、反向代理服務器軟件，當Web應用程序通過Charles的代理訪問互聯(lián)網(wǎng)時，Charles可以監(jiān)控HTTP/HTTPS應用程序發(fā)送和接收的所有數(shù)據(jù)。Charles允許開發(fā)者查看所有連接互聯(lián)網(wǎng)的HTTP/HTTPS通信，包括Request、Response以及Headers等，在Web開發(fā)中扮演著重要的角色。

1 概 述

傳統(tǒng)的HTTP接口測試需要測試人員手工設計用例與構(gòu)建參數(shù)，利用接口測試工具，如postman、jmeter、fiddler等[5]，模擬客戶端向服務端發(fā)送請求，服務端處理后返回請求結(jié)果，測試人員手工檢查返回的結(jié)果是否符合預期。傳統(tǒng)的測試工具雖然使用方便，易于上手，但是它們也有很多不足之處：

(1) 測試數(shù)據(jù)需手工輸入 接口測試本質(zhì)上是對接口輸入和輸出數(shù)據(jù)對應關系的測試。測試人員手動調(diào)用接口，輸入測試數(shù)據(jù)，然后驗證接口返回數(shù)據(jù)的正確性。每次接口測試之前，測試人員必須手動向工具輸入測試數(shù)據(jù)，耗時耗力。

(2) 無法測試加密接口 接口測試工具無法自動執(zhí)行加解密操作，例如md5、base64、AES等加密方式。對于加密接口，測試人員需使用加解密工具對參數(shù)處理之后才能進行測試，導致測試效率低下。

(3) 擴展能力不足 接口測試工具雖然有它的便利性，但與此同時也伴隨著局限性。例如，測試人員需要將測試結(jié)果生成HTML形式的測試報告后發(fā)到指定的郵箱、需要對接口做持續(xù)集成測試等，這些都是工具難以做到的。

對應客戶端服務端模型，在移動軟件測試領域中，基本上采用“端分離測試”的工作模式，即各端保障各端質(zhì)量[6]。實際上，客戶端工作時往往頻繁地調(diào)用服務端接口，獲得了大量的測試數(shù)據(jù)，生成了豐富的測試用例。而“端分離測試”這種工作模式忽略了客戶端測試人員在測試過程產(chǎn)生的大量的服務端測試用例，從而導致了冗余的測試工作。

傳統(tǒng)的接口測試需要測試人員了解接口定義、設計測試用例、配置請求參數(shù)、觀察接口響應等[7]。由于軟件開發(fā)中接口設計場景化、請求參數(shù)復雜化、服務端數(shù)據(jù)動態(tài)化等趨勢愈發(fā)明顯，人工觀察接口響應容易出錯，上述步驟必然會導致測試效率不高。特別對于新開發(fā)的移動應用軟件，必伴隨著大量的服務端接口，測試人員逐個測試接口，造成了大量的重復工作。

為此，本文提出了一種應用于新開發(fā)移動應用場景下，伴隨客戶端功能測試，基于Charles錄制會話的HTTP接口自動化測試框架。它依托于業(yè)界內(nèi)已有的開源持續(xù)集成平臺[8]和單元測試框架，從客戶端功能測試出發(fā)，實現(xiàn)了自動生成測試用例、對測試數(shù)據(jù)自動處理、持續(xù)集成測試、生成測試報告等功能，測試人員在進行客戶端功能測試的同時收集服務端測試數(shù)據(jù)與用例，添加接口響應校驗規(guī)則后，便可持續(xù)檢驗接口是否正常工作。

相較于傳統(tǒng)的接口測試工具與測試流程，本文提出的方案省去手工構(gòu)建請求參數(shù)環(huán)節(jié)，實現(xiàn)自動構(gòu)建請求與校驗響應，增加集成測試與擴展功能，實現(xiàn)接口測試由人工到自動化的轉(zhuǎn)變，提高了測試效率。

2 方案設計

2.1 架構(gòu)設計

如圖1所示，本文提出的接口自動化測試框架主要包含測試用例錄制單元、中間件服務單元以及持續(xù)集成測試單元三部分，每個單元又由不同的子單元構(gòu)成。

圖1 接口自動化測試框架系統(tǒng)架構(gòu)

(1) 測試用例錄制單元：客戶端監(jiān)聽工具(Charles)：記錄HTTP會話，監(jiān)聽被調(diào)用接口傳遞的參數(shù)，錄制接口測試用例，導出“.har”文件；

“.har”文件解析：提取會話數(shù)據(jù)，生成測試用例；

測試用例池：存放測試用例、接口請求參數(shù)與校驗規(guī)則。

(2) 中間件服務單元：接口請求構(gòu)建：調(diào)用測試用例池中的接口Url、Method等參數(shù)，構(gòu)建并向服務端發(fā)送接口請求；

接口響應校驗：校驗接口響應信息，檢查接口返回的數(shù)據(jù)結(jié)構(gòu)與值是否符合預期。

(3) 持續(xù)集成測試單元：單元測試框架：調(diào)用中間件服務單元，執(zhí)行測試用例，生成測試報告；

持續(xù)集成平臺：定時調(diào)用單元測試框架，自動化執(zhí)行接口測試，發(fā)送測試報告，如有異常則發(fā)送報警信息。

2.2 流程設計

如圖2所示，當客戶端開發(fā)人員完成應用開發(fā)并且轉(zhuǎn)交給測試人員后，測試人員在客戶端安裝待測應用進行功能測試的同時，監(jiān)聽工具自動采集接口測試用例，具體流程如下：啟動Charles，客戶端連接代理服務器；測試人員進行客戶端功能測試，Charles錄制客戶端與服務端交互過程中所調(diào)用的接口以及傳遞的參數(shù)信息；通過調(diào)用Python腳本，提取Charles錄制的接口請求數(shù)據(jù)，生成測試用例；測試人員完善測試用例并且添加接口響應校驗規(guī)則后裝入單元測試框架；持續(xù)集成平臺以任務的形式定時運行單元測試框架，其分別完成向服務端發(fā)送接口請求數(shù)據(jù)、接收服務端響應并與預先填寫的檢驗規(guī)則作對比、發(fā)送測試結(jié)果三項任務。

圖2 接口自動化測試框架工作流程

2.3 工程設計

如圖3所示，在工程上，本文提出的接口自動化測試框架由Charles+Python+Unittest+Git+Jenkins構(gòu)成，主要分為兩部分：錄制接口測試用例與接口自動化測試。

圖3 接口自動化測試框架工程設計

3 錄制接口測試用例

如圖4所示，錄制接口測試用例部分以Charles為核心，Python腳本將HTTP會話過程轉(zhuǎn)換成可用的測試用例。測試人員在進行功能測試的同時，Charles錄制客戶端與服務端會話，測試結(jié)束后，導出“.har”格式文件。經(jīng)過白名單與黑名單過濾后，接口測試用例存入測試用例池。

圖4 接口測試用例錄制結(jié)構(gòu)

3.1 錄制接口測試用例

當客戶端連接Charles后，客戶端的請求參數(shù)通過Charles轉(zhuǎn)發(fā)至服務端，服務端的響應又通過Charles下發(fā)至客戶端。如圖5所示，對于某款特定的移動應用，其接口一般歸于一個或多個域名，而Charles將客戶端與服務端會話過程中所有的數(shù)據(jù)按照域名進行歸類，導出HTTP Archive(Har) format格式(“.har”)后，可查看會話詳情。

圖5 Charles代理服務器軟件

“.har”格式文件在本質(zhì)上是“utf-8”格式的json字符串文件，其中的“entries”字段為列表對象，保存了HTTP會話的詳情，一個元素則記錄了一條HTTP會話，“entries”的數(shù)據(jù)結(jié)構(gòu)如表1所示。

表1 “entries”數(shù)據(jù)結(jié)構(gòu)

3.2 構(gòu)建接口測試用例池

從上一節(jié)得知，“entries”中的一個元素即可視為一條測試用例，而其中的“request”和“response”對象則保存了完整的請求與響應信息。本文構(gòu)建了Python腳本將請求參數(shù)與響應數(shù)據(jù)映射至測試用例池。測試用例根據(jù)接口的url字段歸檔，采用“一對多”的模式組織數(shù)據(jù)結(jié)構(gòu)，即一個url對應多組參數(shù)，從而實現(xiàn)同一個接口對應多個測試用例的組織模式。構(gòu)建測試用例池流程如圖6所示。

圖6 構(gòu)建測試用例流程圖

除了完整的請求與響應信息以外，賦予測試用例名稱與編號，方便后期的維護與擴展。測試用例池的每條用例結(jié)構(gòu)如表2所示，其中headers、queryString、cookies、postData均為json對象。

表2 測試用例組織結(jié)構(gòu)

Python的xlrd和xlwt庫可以很方便地實現(xiàn)對Excel文件的寫入與讀取，而Excel表格可以直觀地顯示接口的信息以及請求的詳細數(shù)據(jù)。本文使用Excel文件作為測試用例池的存儲容器，一行為一條測試用例，而測試用例之間可能存在相同的請求對象，后期維護時可以較快擴展用例。

4 中間件服務

中間件服務用于連接用例池與服務端。它分為兩個部分，一部分是構(gòu)建單元，另一部分是接收單元。構(gòu)建單元負責將測試用例池中的用例參數(shù)組裝成HTTP請求并向服務端發(fā)送，待服務端解析請求后，接收單元接收接口響應并將響應報文轉(zhuǎn)換成預期的格式，與預先配置的校驗規(guī)則做對比。

4.1 構(gòu)建單元

構(gòu)建單元以Python的requests庫為基礎，將測試用例中參數(shù)組裝成一個完整的HTTP請求。requests庫支持HTTP協(xié)議中的所有請求方法，并且其能攜帶所有的HTTP請求信息。

本主動托換體系設計的特點是受力明確、承載力可靠、變形易于控制、能夠適應現(xiàn)有結(jié)構(gòu)布置和樁基布置條件、托換施工期間和托換完成以后的建筑物安全控制設計采取靜態(tài)應變測試系統(tǒng)、電子位移計、傾角儀、裂縫觀測儀對新托換梁的撓度、沉降、傾斜度、裂縫進行高精度動態(tài)監(jiān)測，得出同步頂升時托換梁的即時變化結(jié)果，以便更準確地指導托換梁頂升工作。

服務端解析構(gòu)建單元的請求之后，會將響應以Response對象的形式返回。而在移動應用軟件開發(fā)中，大多數(shù)移動應用基本采用json格式耦合客戶端與服務端。借助于Python中的json庫，將HTTP響應報文轉(zhuǎn)換成json格式，方便校驗其響應內(nèi)容。

本文將request庫和json庫進一步封裝，構(gòu)成基礎http請求包，以類方法的形式對外開放，用于傳遞HTTP數(shù)據(jù)。

類方法介紹如表3所示，Get_main和Post_main分別對應HTTP協(xié)議中的Get和Post方法，Headers和Data若為空，則調(diào)用默認值，返回對象為統(tǒng)一的json格式的字符串。

表3 封裝HTTP請求方法

4.2 接收單元

對于接口響應內(nèi)容的校驗，本文選取了兩種校驗方式。對于無代碼能力的測試人員，使用Json Schema；另一種方式是使用斷言(Assert)，而這也對測試人員提出了更高的要求。Json Schema指的是數(shù)據(jù)交換中的一種虛擬“合同”，用于Json數(shù)據(jù)的一致性檢驗。它可以驗證值的數(shù)據(jù)類型是否正確，是否包含所需的數(shù)據(jù)，數(shù)據(jù)的組成結(jié)構(gòu)是否正確，值的范圍是否符合預期等。Python的jsonschema庫提供了豐富的json數(shù)據(jù)驗證功能，用戶僅僅需要將數(shù)據(jù)導入庫即可進行可靠的json驗證。在unittest框架中，TestCase類提供了較多的方法用于對接口響應結(jié)果的校驗，表4列出了幾個常用的斷言方法。

表4 TestCase類常用斷言方法

5 持續(xù)測試

持續(xù)測試單元由unittest單元測試框架、HTMLTest Runnner、Sendmail以及Jenkins構(gòu)成。其中unittest完成測試用例池中的用例組織與管理，HTMLTestRunner用于生成測試報告，Sendmail發(fā)送測試報告，而Jenkins則是整個持續(xù)測試的核心，它定期執(zhí)行測試任務，實現(xiàn)接口測試框架的持續(xù)運行。

使用unittest單元測試框架組織管理測試用例池中的測試用例，執(zhí)行所有用例結(jié)束后利用HTMLTest Runner庫生成html格式的測試報告，同時構(gòu)建了SendMail模塊發(fā)送測試信息，便于遠程測試人員查看測試詳情。

5.1 unittest與HTMLTestRunnner

unittest是一個Python單元測試框架，支持自動化測試，全局配置測試的開啟與關閉，測試用例以集合的形式聚合到框架中。unittest以類的形式組織測試用例，每一個測試類起始由“setup()”構(gòu)成，結(jié)束由“teardown()”構(gòu)成，中間包括各個測試用例“test_case()”。HTMLTestRunner配合unittest用于將測試結(jié)果保存至html文件中，提高可讀性。

在調(diào)用unittest單元測試框架時，測試用例必須以“test_”開頭。通過中間件服務單元將測試用例池中的用例以方法的形式實例化并嵌入至unittest單元測試框架。另外，unittest提供了完整的斷言方法，如果某個測試用例斷言失敗，框架則拋出“AssertionError”，并標識該用例測試失敗；否則，則標識該用例為測試成功狀態(tài)。例如assertEqual方法用于驗證兩個參數(shù)值是否相等，下述嵌入示例中的assertEqual驗證響應結(jié)果的狀態(tài)碼是否為200，若不是則輸出“測試失敗”，并標記該用例為失敗狀態(tài)；否則，測試用例通過。一個類中可定義多個測試用例函數(shù)，按類分組批量執(zhí)行測試用例。嵌入示例及代碼結(jié)構(gòu)如下所示：

嵌入示例:利用assertEqual檢查接口的響應狀態(tài)碼類名←繼承unittest中的TestCase類起始方法setUp測試用例函數(shù)func←傳入用例參數(shù)(來源于測試用例池) url←用例池中的Request.url header←用例池中的Request.headers data←用例池中的Request.data res←Get_main/Post_main(url, header, data) assertEqual(res[′status′], ′200′, ′測試失敗′)結(jié)束方法teardown

測試用例嵌入至unittest后，給定html文件的保存路徑以及測試報告名稱，完整的接口測試框架遍搭建完畢。unitest使用TestSuite管理測試用例，一個TestSuite是多個測試用例的集合，該集合內(nèi)的所有測試用例將被一起執(zhí)行。利用TestSuite可以將不同的測試用例組成測試邏輯組，即接口測試用例可根本被測軟件的邏輯功能進行模塊化組織，然后設置為統(tǒng)一的測試套件，對外僅暴露一個命令即可實現(xiàn)批量執(zhí)行測試用例。

5.2 SendMail

接口自動化測試框架托管于遠程服務器中，為了方便查看測試報告，本文利用smtplib庫構(gòu)建了SendMail模塊集成至框架中，以郵件的形式發(fā)送測試報告?；玖鞒虨椋?/p>

1) 讀取測試報告；

2) 添加郵件內(nèi)容及附件；

3) 連接郵件服務器；

4) 發(fā)送郵件；

5) 退出。

框架定義list對象存儲郵件接收者信息，每個元素為接收者的郵箱地址，用于接收測試報告。測試報告以“MIMEText”格式集成至框架中，用戶設置本地郵箱和密碼后，建立 SMTP郵件服務器，啟動郵件發(fā)送流程，如發(fā)送異常，框架打印異常信息。

5.3 Jenkins持續(xù)集成測試

Jenkins平臺安裝Git插件后，將托管在Git服務器的代碼更新至測試環(huán)境后做持續(xù)集成測試。在配置Jenkins任務時選擇Git源碼管理，通過“Poll SCM”設定測試時間間隔，便可持續(xù)進行接口測試。值得注意的是，設定測試時間間隔忌太短，以免對服務端造成額外的壓力。每次測試結(jié)束后，Jenkins控制臺輸出測試信息，同時，測試報告以html形式存放于測試環(huán)境中的指定路徑。

6 實施驗證

在已部署接口自動化測試框架的測試機系統(tǒng)上，本文對一個Android開發(fā)應用實施接口自動化測試。具體環(huán)境、測試過程、結(jié)果如下所述。

6.1 測試環(huán)境

搭建基于CentOS 6.7 操作系統(tǒng)的的Linux測試環(huán)境， 部署本文提出的接口自動化測試框架。框架使用Python 3.6.12版本編寫，依托于Jenkins 2.150.2版本持續(xù)集成運行。測試環(huán)境安裝Git命令行工具，Jenkins配置Git服務器地址并生成密鑰后與Git服務器建立連接。

6.2 測試過程

如表5所示，本文對國內(nèi)某主流動漫社區(qū)安卓應用進行冒煙測試，收集其一級按鈕下后端接口數(shù)據(jù)。首先使裝有待測應用的客戶端連接Charles代理服務器，然后對移動應用進行指定測試范圍內(nèi)的冒煙測試。測試結(jié)束后，Charles導出接口“.har”文件，經(jīng)過Python解析后，共獲取124個接口測試用例，部分測試用例數(shù)據(jù)如圖7、圖8所示。

表5 測試對象、方法、范圍

圖7 測試用例池記錄(1)

圖8 測試用例池記錄(2)

6.3 添加校驗規(guī)則與配置Jenkins

根據(jù)接口響應數(shù)據(jù)格式以及接口數(shù)據(jù)結(jié)構(gòu)的不同，本文選取jsonschema與斷言兩種校驗方式交叉驗證接口數(shù)據(jù)是否正常返回。為上一小節(jié)測試用例池中的測試用例逐條添加校驗規(guī)則裝入unittest后，提交至Git服務器。

如表6的配置說明所述，在Jenkins平臺，配置Git服務器地址，以Python腳本的方式每5分鐘循環(huán)遍歷用例池中的用例，每條測試用例通過unittest向服務端發(fā)出請求，檢查響應是否符合預期設定的校驗規(guī)則。單次遍歷接口用例結(jié)束后，生成一份html格式的測試報告，包括執(zhí)行用例時間、用例狀態(tài)、成功或失敗詳情等，如圖9所示。如圖10所示，在Jenkins中配置發(fā)送者與接收者郵箱后，測試結(jié)束后便可向指定郵箱發(fā)送測試報告。

表6 Jenkins配置說明

圖9 測試報告

圖10 發(fā)送測試報告

6.4 框架運行分析

本文將提出的接口自動化測試框架在測試環(huán)境中運行24小時。郵箱以5分鐘為間隔收集測試報告，每份報告提供測試詳情。因接口返回數(shù)據(jù)動態(tài)變化，框架運行前期會出現(xiàn)因校驗規(guī)則設計不完整與接口響應數(shù)據(jù)不匹配的現(xiàn)象，需及時修改校驗規(guī)則以兼容所有可能的接口并正確返回；運行后期，框架便可實現(xiàn)無人值守的接口自動化測試。

另外，本文對于某些接口設計了相應的負向情況以檢驗框架的穩(wěn)定性，當框架運行異常時，如腳本錯誤、服務端響應超時、測試任務異常等，Jenkins平臺可按照向預先設置的管理員郵箱發(fā)送報警郵件，并提供出錯的堆棧輸出。

7 結(jié) 語

本文提出了一種基于Charles錄制測試用例的HTTP接口自動化測試框架，它融合了現(xiàn)有接口測試工具的便利性，與此同時提高了測試效率。以功能測試為出發(fā)點，收集功能測試過程中的數(shù)據(jù)，以此為基礎快速完善與補充測試用例，配合unittest框架和Jenkins平臺實現(xiàn)完整的接口自動化測試。通過實踐證明，工具在執(zhí)行自動化接口測試的同時，起到了一定程度的監(jiān)控作用，持續(xù)保證接口下發(fā)數(shù)據(jù)正常。

下一步的研究方向是增加參數(shù)列表，實現(xiàn)工具的自動構(gòu)建測試用例，進而提高接口測試效率以及保證接口測試的全面性。