原文出自【聽雲技術部落格】：
今年遇到了幾個問題，與介面的功能和效能相關，恰巧最近公司也在組織以冒煙測試為主題的活動，於是乎突發奇想，尋思著能否將介面測試與冒煙測試結合起來，發掘一些新的介面測試思路與方法。
設計思路：
訊息可以簡單的視為介面測試案例，比交換問題複雜很多，需要考慮很多因素，我們總結為以下四個主要問題
：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%。通過每日對這些案例進行自動化測試，發現了一些介面功能和應用環境配置的問題。
上述這種測試方法還只是從技術的角度測試，為了滿足實際業務測試的需求，我們也實現一些簡單的功能
：比如我們提供了多維度的測試結果統計；提供基於業務關鍵字的報文案例和測試結果的檢索功能，以便業務測試人員快速的找到自己的測試案例；允許業務測試人員手工修改報文案例庫，這樣就可以跳過應用前端，直接針對介面開展測試；最後我們對每一次執行時間都進行記錄，形成了報文案例響應時間的基線，用於後續的介面效能評估。
總結和問題：
以上方法是乙個非常簡單的介面冒煙測試方法，前提是功能測試覆蓋過介面案例，並且介面報文會記錄在日誌中。隨著案例和執行結果的不斷積累，介面測試覆蓋會更加充分，統計結果會更加精確。如果能夠從生產環境日誌中獲取案例，那麼測試效果會更好。上述方法還有很多不成熟的地方，比如對於測試結果的利用上、在失敗報文的歸類和歸因分析上，還應該會有更好的方法。如果全面推廣實施，測試的效率，尤其是測試報文提取和分析的效率還需要進一步提公升。
工行資料中心高階經理 李雁南 介面冒煙測試方法
原文出自 聽雲技術部落格 今年遇到了幾個問題，與介面的功能和效能相關，恰巧最近公司也在組織以冒煙測試為主題的活動，於是乎突發奇想，尋思著能否將介面測試與冒煙測試結合起來，發掘一些新的介面測試思路與方法。設計思路 訊息可以簡單的視為介面測試案例，比交換問題複雜很多，需要考慮很多因素，我們總結為以下四個...
雲資料中心 高可用是關鍵
以創新為核心競爭力的高成長性企業，在取得輝煌業績的同時也面臨著來自管理 技術和成本等方面的風險。考慮到成本以及it創新管理等多方面因素，越來越多的高成長性企業的首席資訊官 cio 正在調整其it戰略方向，將焦點匯聚在彈性與成本優勢兼具且不失安全性的公有雲領域。公有雲成理想模式 隨著虛擬化與雲計算技術...
資料中心高架地板 通風靜壓箱 的作用及其計算方法
資料中心高架地板 通風靜壓箱 說明 資料中心常借由高架地板作為乙個送風風箱 借由此送風風箱來達到送風均衡且減少壓損的效果。在空調系統中 資料中心高架地板就等於乙個通風靜壓箱。靜壓箱又稱穩壓室，靜壓箱連線空調箱送風口使氣流在此空間中流速降低趨近於零，動壓轉化為靜壓，且各點靜壓近似相同，使送風口達到均勻...