今年遇到了幾個問題，與接口的功能和性能相關，恰巧最近公司也在組織以冒煙測試為主題的活動，于是乎突發奇想，尋思着能否将接口測試與冒煙測試結合起來，發掘一些新的接口測試思路與方法。
平時對接口測試關注的比較少，大部分接口功能都是通過應用前段的功能測試案例覆寫了，并沒有單獨安排針對接口安排測試案例，是以真正到了實施時，我才發現對于接口測試還缺乏一個準确的定義。求助度娘，百度知道上的定義如下：接口測試是測試系統元件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及内部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的互相邏輯依賴關系等。這個定義與我們之前的了解并沒有太大差異，簡而言之，開放平台應用通過接口服務實作應用間消息和資料交換，是以我們的測試重點就聚焦在消息和交換兩個問題上了。
設計思路：
交換這個問題會簡單一些，畢竟應用常用的接口服務類型主要就是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%。通過每日對這些案例進行自動化測試，發現了一些接口功能和應用環境配置的問題。
上述這種測試方法還隻是從技術的角度測試，為了滿足實際業務測試的需求，我們也實作一些簡單的功能：比如我們提供了多元度的測試結果統計；提供基于業務關鍵字的封包案例和測試結果的檢索功能，以便業務測試人員快速的找到自己的測試案例；允許業務測試人員手工修改封包案例庫，這樣就可以跳過應用前端，直接針對接口開展測試；最後我們對每一次執行時間都進行記錄，形成了封包案例響應時間的基線，用于後續的接口性能評估。
總結和問題：
以上方法是一個非常簡單的接口冒煙測試方法，前提是功能測試覆寫過接口案例，并且接口封包會記錄在日志中。随着案例和執行結果的不斷積累，接口測試覆寫會更加充分，統計結果會更加精确。如果能夠從生産環境日志中擷取案例，那麼測試效果會更好。上述方法還有很多不成熟的地方，比如對于測試結果的利用上、在失敗封包的歸類和歸因分析上，還應該會有更好的方法。如果全面推廣實施，測試的效率，尤其是測試封包提取和分析的效率還需要進一步提升。
歡迎大家拍磚。