摘要：接口測(cè)試主要用于檢測(cè)外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)。隨著案例和執(zhí)行結(jié)果的不斷積累，接口測(cè)試覆蓋會(huì)更加充分，統(tǒng)計(jì)結(jié)果會(huì)更加精確。

原文出自【聽云技術(shù)博客】：http://blog.tingyun.com/web/a...

今年遇到了幾個(gè)問題，與接口的功能和性能相關(guān)，恰巧最近公司也在組織以冒煙測(cè)試為主題的活動(dòng)，于是乎突發(fā)奇想，尋思著能否將接口測(cè)試與冒煙測(cè)試結(jié)合起來，發(fā)掘一些新的接口測(cè)試思路與方法。

平時(shí)對(duì)接口測(cè)試關(guān)注的比較少，大部分接口功能都是通過應(yīng)用前段的功能測(cè)試案例覆蓋了，并沒有多帶帶安排針對(duì)接口安排測(cè)試案例，因此真正到了實(shí)施時(shí)，我才發(fā)現(xiàn)對(duì)于接口測(cè)試還缺乏一個(gè)準(zhǔn)確的定義。求助度娘，百度知道上的定義如下：接口測(cè)試是測(cè)試系統(tǒng)組件間接口的一種測(cè)試。接口測(cè)試主要用于檢測(cè)外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)。測(cè)試的重點(diǎn)是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等。這個(gè)定義與我們之前的理解并沒有太大差異，簡(jiǎn)而言之，開放平臺(tái)應(yīng)用通過接口服務(wù)實(shí)現(xiàn)應(yīng)用間消息和數(shù)據(jù)交換，因此我們的測(cè)試重點(diǎn)就聚焦在消息和交換兩個(gè)問題上了。

設(shè)計(jì)思路：

交換這個(gè)問題會(huì)簡(jiǎn)單一些，畢竟應(yīng)用常用的接口服務(wù)類型主要就是HTTP和SOCKET兩種，而針對(duì)這兩種類型服務(wù)的測(cè)試方法也很多，百度一下會(huì)有很多相關(guān)測(cè)試方法和框架。對(duì)于我們這些不懂編程的小白，python自然是首選。python提供了最基本的request和httplib2庫實(shí)現(xiàn)報(bào)文的發(fā)送和接收，當(dāng)然對(duì)于HTTP類型接口還會(huì)區(qū)分為post和get，這個(gè)在request庫中也都有對(duì)應(yīng)的方法，我們通過一張接口登記表來記錄每一個(gè)接口的類型、地址和方法，這些信息都可以從配置管理系統(tǒng)中獲得。

消息可以簡(jiǎn)單的視為接口測(cè)試案例，比交換問題復(fù)雜很多，需要考慮很多因素，我們總結(jié)為以下四個(gè)主要問題：

1、消息獲取的途徑有哪些；

2、消息是否能夠覆蓋所有的程序分支；

3、如何判斷返回結(jié)果的正確性；

4、測(cè)試效率問題。

下面我將逐一介紹我們的解決方案：

1、消息獲取的途徑問題：

傳統(tǒng)的接口測(cè)試方法主要采用手工編輯接口報(bào)文的方法，這種方法只要按照接口文檔的描述構(gòu)造測(cè)試報(bào)文就OK了，雖然簡(jiǎn)單，但是有失高效。于是這個(gè)方法有了升級(jí)版本，就是通過參數(shù)化報(bào)文中的關(guān)鍵字段，批量生成測(cè)試案例，這也是接口性能測(cè)試的主要方法之一。這個(gè)方法雖然解決了獲取報(bào)文的效率問題，但是并不能很好解決覆蓋率的問題，畢竟報(bào)文是人工構(gòu)造出來的，并不能非常真實(shí)的體現(xiàn)實(shí)際的業(yè)務(wù)交易場(chǎng)景，實(shí)際測(cè)試結(jié)果也印證了這一觀點(diǎn)。于是，我們想既然傳統(tǒng)的接口測(cè)試是在正常的業(yè)務(wù)交易測(cè)試中覆蓋了，那么我們干脆去直接捕獲前段發(fā)起交易產(chǎn)生的接口消息報(bào)文。非常幸運(yùn)，公司絕大部分的開發(fā)部門都是嚴(yán)格按照LOG4J格式記錄應(yīng)用交易日志的，因此我們只要按照一定的規(guī)則去分析應(yīng)用的交易日志，就能夠提取出我們所需要的內(nèi)容。

2、消息是否能夠覆蓋所有的程序分支問題：

根據(jù)消息內(nèi)容的不同，應(yīng)用程序會(huì)選擇不同的程序邏輯分支，如何能夠覆蓋所有的分支，傳統(tǒng)方法只有通過白盒測(cè)試實(shí)現(xiàn)，但是驗(yàn)收測(cè)試更偏重于黑盒或灰盒測(cè)試，因此過去經(jīng)常因?yàn)闇y(cè)試案例不全面，導(dǎo)致某一個(gè)未覆蓋分支的程序問題流入生產(chǎn)環(huán)境。我們目前想到的方法，是通過在系統(tǒng)中導(dǎo)入存量的接口測(cè)試案例，并通過日志中捕獲的測(cè)試案例，經(jīng)過一段時(shí)間的積累，逐漸形成一個(gè)較為完整的接口測(cè)試案例庫。如果能夠旁路一臺(tái)生產(chǎn)環(huán)境應(yīng)用服務(wù)器日志，效果會(huì)更好，畢竟生產(chǎn)的交易種類和場(chǎng)景是最全面的，當(dāng)然這里還要解決生產(chǎn)數(shù)據(jù)脫敏等問題，對(duì)于金融行業(yè)還要面對(duì)很多制度流程的問題。

3、如何判斷消息返回結(jié)果的正確性問題：

每一個(gè)應(yīng)用對(duì)于接口報(bào)文的設(shè)計(jì)都是遵照一定的規(guī)范和習(xí)慣，我們只需要梳理出標(biāo)記交易成功狀態(tài)的字段就可以了。某些交易不包含這個(gè)字段，我們就需要進(jìn)行人工判斷，并對(duì)成功的結(jié)果進(jìn)行格式化（比如timestamp，流水號(hào)等），提取MD5特征值，作為判斷接口后續(xù)測(cè)試結(jié)果正確性的依據(jù)。不過，狀態(tài)字段是成功并不代表接口測(cè)試通過，畢竟返回結(jié)果中還包含了很多業(yè)務(wù)數(shù)據(jù)字段需要驗(yàn)證。如果這些字段值變化比較規(guī)律（比如一直不變、持續(xù)增加或減少），我們準(zhǔn)備定義一些模型規(guī)則去判斷它們。而那些上躥下跳的數(shù)據(jù)，那就留給人去判斷了。其實(shí)，對(duì)于冒煙測(cè)試而言，我們認(rèn)為并不需要苛求去判斷每一筆交易的正確性，只需要統(tǒng)計(jì)大量測(cè)試案例結(jié)果的成功率，并與前期成功率進(jìn)行比較，以判斷測(cè)試結(jié)果是否正常。

4、執(zhí)行效率的問題

我們理解的冒煙測(cè)試是要在盡可能短的時(shí)間內(nèi)，對(duì)新的版本或測(cè)試環(huán)境進(jìn)行一個(gè)準(zhǔn)入測(cè)試，以判斷其是否具有開展后續(xù)是驗(yàn)收及適應(yīng)性測(cè)試的條件，因此冒煙測(cè)試的效率至關(guān)重要。我們的策略是通過異步小批量作業(yè)的方式不間斷的掃描日志處理報(bào)文，每日定時(shí)并發(fā)的方式去執(zhí)行測(cè)試案例，執(zhí)行時(shí)間取決于版本安裝時(shí)間或測(cè)試任務(wù)的需要，目前2萬筆測(cè)試案例，基本可以控制在10分鐘之內(nèi)。

實(shí)現(xiàn)方案：

實(shí)現(xiàn)架構(gòu)非常簡(jiǎn)單，就是一套開源的ELK日志采集架構(gòu)，加上python開發(fā)的接口測(cè)試框架和結(jié)果統(tǒng)計(jì)功能，如下圖所示：

主要步驟如下：

1，通過開源ELK實(shí)現(xiàn)應(yīng)用日志的采集與管理。在客戶端部署logstash agent，并配置日志采集策略；日志記錄以key-value的格式上送REDIS內(nèi)存數(shù)據(jù)庫，這個(gè)設(shè)計(jì)主要是為了在client和server之間做一個(gè)緩沖，保證了日志記錄的0丟失；ELSTICSEARCH提供了日志的全文檢索功能，并提供了API服務(wù)用來外部調(diào)用

2，利用python的pyes庫調(diào)用ELSATICSEARCH的API服務(wù)，根據(jù)特征字段抓取xml和json格式的接口報(bào)文。

3，對(duì)采集到的接口報(bào)文進(jìn)行格式化處理，格式化日期、流水號(hào)或時(shí)間戳等字段，并對(duì)格式化后的報(bào)文做MD5的校驗(yàn)。

4，利用python的http和socket接口庫實(shí)現(xiàn)接口測(cè)試案例，這里可能要根據(jù)不同應(yīng)用做一些客戶化，盡量通過通用的方式實(shí)現(xiàn)。

5，對(duì)于異常的測(cè)試案例進(jìn)行自動(dòng)退出。為了保證案例集的可用性，我們這里做了一個(gè)簡(jiǎn)單的接口退出規(guī)則，如果執(zhí)行超過三次且每次都失敗的接口案例，會(huì)被系統(tǒng)自動(dòng)定義為失效案例。

6，對(duì)案例的執(zhí)行結(jié)果進(jìn)行成功率分析和錯(cuò)誤歸因分析，最終發(fā)現(xiàn)存在的接口問題。這里不再關(guān)注每一個(gè)測(cè)試案例返回的成功和失敗，而是針對(duì)每一類接口的成功率、失敗率和錯(cuò)誤類型進(jìn)行統(tǒng)計(jì)，從數(shù)值和數(shù)量變化的角度去發(fā)現(xiàn)問題。

7，接口定義平臺(tái)提供了一個(gè)web的接口定義模塊，幫助業(yè)務(wù)測(cè)試人員根據(jù)接口文檔編輯接口要素，并拼裝成接口報(bào)文進(jìn)行測(cè)試。對(duì)于復(fù)雜的交易場(chǎng)景（比如流程長(zhǎng)或交互次數(shù)多），可以在平臺(tái)上編排接口的調(diào)用順序和前后項(xiàng)邏輯關(guān)系，實(shí)現(xiàn)一個(gè)比較復(fù)雜場(chǎng)景的接口測(cè)試。雖然這個(gè)功能更偏重于自動(dòng)化測(cè)試，但是這個(gè)功能幫助我們實(shí)現(xiàn)了無法通過應(yīng)用前段功能測(cè)試覆蓋的接口測(cè)試，是非常好的補(bǔ)充。

通過上述方法，我們?cè)谝恢艿臅r(shí)間里，在3個(gè)應(yīng)用進(jìn)行了試驗(yàn)，發(fā)現(xiàn)了30多個(gè)接口，接近2萬筆報(bào)文案例，案例的有效性可以達(dá)到了97%。通過每日對(duì)這些案例進(jìn)行自動(dòng)化測(cè)試，發(fā)現(xiàn)了一些接口功能和應(yīng)用環(huán)境配置的問題。

上述這種測(cè)試方法還只是從技術(shù)的角度測(cè)試，為了滿足實(shí)際業(yè)務(wù)測(cè)試的需求，我們也實(shí)現(xiàn)一些簡(jiǎn)單的功能：比如我們提供了多維度的測(cè)試結(jié)果統(tǒng)計(jì)；提供基于業(yè)務(wù)關(guān)鍵字的報(bào)文案例和測(cè)試結(jié)果的檢索功能，以便業(yè)務(wù)測(cè)試人員快速的找到自己的測(cè)試案例；允許業(yè)務(wù)測(cè)試人員手工修改報(bào)文案例庫，這樣就可以跳過應(yīng)用前端，直接針對(duì)接口開展測(cè)試；最后我們對(duì)每一次執(zhí)行時(shí)間都進(jìn)行記錄，形成了報(bào)文案例響應(yīng)時(shí)間的基線，用于后續(xù)的接口性能評(píng)估。

總結(jié)和問題：

以上方法是一個(gè)非常簡(jiǎn)單的接口冒煙測(cè)試方法，前提是功能測(cè)試覆蓋過接口案例，并且接口報(bào)文會(huì)記錄在日志中。隨著案例和執(zhí)行結(jié)果的不斷積累，接口測(cè)試覆蓋會(huì)更加充分，統(tǒng)計(jì)結(jié)果會(huì)更加精確。如果能夠從生產(chǎn)環(huán)境日志中獲取案例，那么測(cè)試效果會(huì)更好。上述方法還有很多不成熟的地方，比如對(duì)于測(cè)試結(jié)果的利用上、在失敗報(bào)文的歸類和歸因分析上，還應(yīng)該會(huì)有更好的方法。如果全面推廣實(shí)施，測(cè)試的效率，尤其是測(cè)試報(bào)文提取和分析的效率還需要進(jìn)一步提升。

歡迎大家拍磚。