工行資料中心高階經理 李雁南：介面冒煙測試方法

原文出自【聽雲技術部落格】：http://blog.tingyun.com/web/article/detail/1340

今年遇到了幾個問題，與介面的功能和效能相關，恰巧最近公司也在組織以冒煙測試為主題的活動，於是乎突發奇想，尋思著能否將介面測試與冒煙測試結合起來，發掘一些新的介面測試思路與方法。

平時對介面測試關注的比較少，大部分介面功能都是通過應用前段的功能測試案例覆蓋了，並沒有單獨安排針對介面安排測試案例，因此真正到了實施時，我才發現對於介面測試還缺乏一個準確的定義。求助度娘，百度知道上的定義如下：介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。這個定義與我們之前的理解並沒有太大差異，簡而言之，開放平臺應用通過介面服務實現應用間訊息和資料交換，因此我們的測試重點就聚焦在訊息和交換兩個問題上了。

設計思路：

交換這個問題會簡單一些，畢竟應用常用的介面服務型別主要就是HTTP和SOCKET兩種，而針對這兩種型別服務的測試方法也很多，百度一下會有很多相關測試方法和框架。對於我們這些不懂程式設計的小白，python自然是首選。python提供了最基本的request和httplib2庫實現報文的傳送和接收，當然對於HTTP型別介面還會區分為post和get，這個在request庫中也都有對應的方法，我們通過一張介面登記表來記錄每一個介面的型別、地址和方法，這些資訊都可以從配置管理系統中獲得。

訊息可以簡單的視為介面測試案例，比交換問題複雜很多，需要考慮很多因素，我們總結為以下四個主要問題：

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

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

3、如何判斷返回結果的正確性；

4、測試效率問題。

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

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

傳統的介面測試方法主要採用手工編輯介面報文的方法，這種方法只要按照介面文件的描述構造測試報文就OK了，雖然簡單，但是有失高效。於是這個方法有了升級版本，就是通過引數化報文中的關鍵欄位，批量生成測試案例，這也是介面效能測試的主要方法之一。這個方法雖然解決了獲取報文的效率問題，但是並不能很好解決覆蓋率的問題，畢竟報文是人工構造出來的，並不能非常真實的體現實際的業務交易場景，實際測試結果也印證了這一觀點。於是，我們想既然傳統的介面測試是在正常的業務交易測試中覆蓋了，那麼我們乾脆去直接捕獲前段發起交易產生的介面訊息報文。非常幸運，公司絕大部分的開發部門都是嚴格按照LOG4J格式記錄應用交易日誌的，因此我們只要按照一定的規則去分析應用的交易日誌，就能夠提取出我們所需要的內容。

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

根據訊息內容的不同，應用程式會選擇不同的程式邏輯分支，如何能夠覆蓋所有的分支，傳統方法只有通過白盒測試實現，但是驗收測試更偏重於黑盒或灰盒測試，因此過去經常因為測試案例不全面，導致某一個未覆蓋分支的程式問題流入生產環境。我們目前想到的方法，是通過在系統中匯入存量的介面測試案例，並通過日誌中捕獲的測試案例，經過一段時間的積累，逐漸形成一個較為完整的介面測試案例庫。如果能夠旁路一臺生產環境應用伺服器日誌，效果會更好，畢竟生產的交易種類和場景是最全面的，當然這裡還要解決生產資料脫敏等問題，對於金融行業還要面對很多制度流程的問題。

3、如何判斷訊息返回結果的正確性問題：

每一個應用對於介面報文的設計都是遵照一定的規範和習慣，我們只需要梳理出標記交易成功狀態的欄位就可以了。某些交易不包含這個欄位，我們就需要進行人工判斷，並對成功的結果進行格式化（比如timestamp，流水號等），提取MD5特徵值，作為判斷介面後續測試結果正確性的依據。不過，狀態欄位是成功並不代表介面測試通過，畢竟返回結果中還包含了很多業務資料欄位需要驗證。如果這些欄位值變化比較規律（比如一直不變、持續增加或減少），我們準備定義一些模型規則去判斷它們。而那些上躥下跳的資料，那就留給人去判斷了。其實，對於冒煙測試而言，我們認為並不需要苛求去判斷每一筆交易的正確性，只需要統計大量測試案例結果的成功率，並與前期成功率進行比較，以判斷測試結果是否正常。

4、執行效率的問題

我們理解的冒煙測試是要在儘可能短的時間內，對新的版本或測試環境進行一個准入測試，以判斷其是否具有開展後續是驗收及適應性測試的條件，因此冒煙測試的效率至關重要。我們的策略是通過非同步小批量作業的方式不間斷的掃描日誌處理報文，每日定時併發的方式去執行測試案例，執行時間取決於版本安裝時間或測試任務的需要，目前2萬筆測試案例，基本可以控制在10分鐘之內。

實現方案：

實現架構非常簡單，就是一套開源的ELK日誌採集架構，加上python開發的介面測試框架和結果統計功能，如下圖所示：

主要步驟如下：

1，通過開源ELK實現應用日誌的採集與管理。在客戶端部署logstash agent，並配置日誌採集策略；日誌記錄以key-value的格式上送REDIS記憶體資料庫，這個設計主要是為了在client和server之間做一個緩衝，保證了日誌記錄的0丟失；ELSTICSEARCH提供了日誌的全文檢索功能，並提供了API服務用來外部呼叫

2，利用python的pyes庫呼叫ELSATICSEARCH的API服務，根據特徵欄位抓取xml和json格式的介面報文。

3，對採集到的介面報文進行格式化處理，格式化日期、流水號或時間戳等欄位，並對格式化後的報文做MD5的校驗。

4，利用python的http和socket介面庫實現介面測試案例，這裡可能要根據不同應用做一些客戶化，儘量通過通用的方式實現。

5，對於異常的測試案例進行自動退出。為了保證案例集的可用性，我們這裡做了一個簡單的介面退出規則，如果執行超過三次且每次都失敗的介面案例，會被系統自動定義為失效案例。

6，對案例的執行結果進行成功率分析和錯誤歸因分析，最終發現存在的介面問題。這裡不再關注每一個測試案例返回的成功和失敗，而是針對每一類介面的成功率、失敗率和錯誤型別進行統計，從數值和數量變化的角度去發現問題。

7，介面定義平臺提供了一個web的介面定義模組，幫助業務測試人員根據介面文件編輯介面要素，並拼裝成介面報文進行測試。對於複雜的交易場景（比如流程長或互動次數多），可以在平臺上編排介面的呼叫順序和前後項邏輯關係，實現一個比較複雜場景的介面測試。雖然這個功能更偏重於自動化測試，但是這個功能幫助我們實現了無法通過應用前段功能測試覆蓋的介面測試，是非常好的補充。

通過上述方法，我們在一週的時間裡，在3個應用進行了試驗，發現了30多個介面，接近2萬筆報文案例，案例的有效性可以達到了97%。通過每日對這些案例進行自動化測試，發現了一些介面功能和應用環境配置的問題。

上述這種測試方法還只是從技術的角度測試，為了滿足實際業務測試的需求，我們也實現一些簡單的功能：比如我們提供了多維度的測試結果統計；提供基於業務關鍵字的報文案例和測試結果的檢索功能，以便業務測試人員快速的找到自己的測試案例；允許業務測試人員手工修改報文案例庫，這樣就可以跳過應用前端，直接針對介面開展測試；最後我們對每一次執行時間都進行記錄，形成了報文案例響應時間的基線，用於後續的介面效能評估。

總結和問題：

以上方法是一個非常簡單的介面冒煙測試方法，前提是功能測試覆蓋過介面案例，並且介面報文會記錄在日誌中。隨著案例和執行結果的不斷積累，介面測試覆蓋會更加充分，統計結果會更加精確。如果能夠從生產環境日誌中獲取案例，那麼測試效果會更好。上述方法還有很多不成熟的地方，比如對於測試結果的利用上、在失敗報文的歸類和歸因分析上，還應該會有更好的方法。如果全面推廣實施，測試的效率，尤其是測試報文提取和分析的效率還需要進一步提升。

歡迎大家拍磚。