工行數據中心高級經理 李雁南：接口冒煙測試方法

➠更多技術乾貨請戳：聽雲博客

今年遇到了幾個問題，與接口的功能和性能相關，恰巧最近公司也在組織以冒煙測試爲主題的活動，因而乎突發奇想，尋思着可否將接口測試與冒煙測試結合起來，發掘一些新的接口測試思路與方法。

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

設計思路：

交換這個問題會簡單一些，畢竟應用經常使用的接口服務類型主要就是HTTP和SOCKET兩種，而針對這兩種類型服務的測試方法也不少，百度一下會有不少相關測試方法和框架。對於咱們這些不懂編程的小白，python天然是首選。python提供了最基本的request和httplib2庫實現報文的發送和接收，固然對於HTTP類型接口還會區分爲post和get，這個在request庫中也都有對應的方法，咱們經過一張接口登記表來記錄每個接口的類型、地址和方法，這些信息均可以從配置管理系統中得到。

消息能夠簡單的視爲接口測試案例，比交換問題複雜不少，須要考慮不少因素，咱們總結爲如下四個主要問題：

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

二、消息是否可以覆蓋全部的程序分支；

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

四、測試效率問題。

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

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

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

二、消息是否可以覆蓋全部的程序分支問題：

根據消息內容的不一樣，應用程序會選擇不一樣的程序邏輯分支，如何可以覆蓋全部的分支，傳統方法只有經過白盒測試實現，可是驗收測試更偏重於黑盒或灰盒測試，所以過去常常由於測試案例不全面，致使某一個未覆蓋分支的程序問題流入生產環境。咱們目前想到的方法，是經過在系統中導入存量的接口測試案例，並經過日誌中捕獲的測試案例，通過一段時間的積累，逐漸造成一個較爲完整的接口測試案例庫。若是可以旁路一臺生產環境應用服務器日誌，效果會更好，畢竟生產的交易種類和場景是最全面的，固然這裏還要解決生產數據脫敏等問題，對於金融行業還要面對不少制度流程的問題。

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

每個應用對於接口報文的設計都是遵守必定的規範和習慣，咱們只須要梳理出標記交易成功狀態的字段就能夠了。某些交易不包含這個字段，咱們就須要進行人工判斷，並對成功的結果進行格式化（好比timestamp，流水號等），提取MD5特徵值，做爲判斷接口後續測試結果正確性的依據。不過，狀態字段是成功並不表明接口測試經過，畢竟返回結果中還包含了不少業務數據字段須要驗證。若是這些字段值變化比較規律（好比一直不變、持續增長或減小），咱們準備定義一些模型規則去判斷它們。而那些上躥下跳的數據，那就留給人去判斷了。其實，對於冒煙測試而言，咱們認爲並不須要苛求去判斷每一筆交易的正確性，只須要統計大量測試案例結果的成功率，並與前期成功率進行比較，以判斷測試結果是否正常。

四、執行效率的問題

咱們理解的冒煙測試是要在儘量短的時間內，對新的版本或測試環境進行一個准入測試，以判斷其是否具備開展後續是驗收及適應性測試的條件，所以冒煙測試的效率相當重要。咱們的策略是經過異步小批量做業的方式不間斷的掃描日誌處理報文，每日定時併發的方式去執行測試案例，執行時間取決於版本安裝時間或測試任務的須要，目前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%。經過每日對這些案例進行自動化測試，發現了一些接口功能和應用環境配置的問題。

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

總結和問題：

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

歡迎你們拍磚。

 

原文連接：http://blog.tingyun.com/web/article/detail/1340