工商銀行數據中心接口冒煙測試方法(2)

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

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

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

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

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

4、執行效率的問題

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

原文轉自：http://blog.tingyun.com/web/article/detail/1340