資訊專欄INFORMATION COLUMN
摘要：接口測試主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點。隨著案例和執(zhí)行結果的不斷積累，接口測試覆蓋會更加充分，統(tǒng)計結果會更加精確。
原文出自【聽云技術博客】：http://blog.tingyun.com/web/a...
今年遇到了幾個問題，與接口的功能和性能相關，恰巧最近公司也在組織以冒煙測試為主題的活動，于是乎突發(fā)奇想，尋思著能否將接口測試與冒煙測試結合起來，發(fā)掘一些新的接口測試思路與方法。
平時對接口測試關注的比較少，大部分接口功能都是通過應用前段的功能測試案例覆蓋了，并沒有多帶帶安排針對接口安排測試案例，因此真正到了實施時，我才發(fā)現(xiàn)對于接口測試還缺乏一個準確的定義。求助度娘，百度知道上的定義如下：接口測試是測試系統(tǒng)組件間接口的一種測試。接口測試主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點。測試的重點是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關系等。這個定義與我們之前的理解并沒有太大差異，簡而言之，開放平臺應用通過接口服務實現(xiàn)應用間消息和數(shù)據(jù)交換，因此我們的測試重點就聚焦在消息和交換兩個問題上了。
設計思路：
交換這個問題會簡單一些，畢竟應用常用的接口服務類型主要就是HTTP和SOCKET兩種，而針對這兩種類型服務的測試方法也很多，百度一下會有很多相關測試方法和框架。對于我們這些不懂編程的小白，python自然是首選。python提供了最基本的request和httplib2庫實現(xiàn)報文的發(fā)送和接收，當然對于HTTP類型接口還會區(qū)分為post和get，這個在request庫中也都有對應的方法，我們通過一張接口登記表來記錄每一個接口的類型、地址和方法，這些信息都可以從配置管理系統(tǒng)中獲得。
消息可以簡單的視為接口測試案例，比交換問題復雜很多，需要考慮很多因素，我們總結為以下四個主要問題：
1、消息獲取的途徑有哪些；
2、消息是否能夠覆蓋所有的程序分支；
3、如何判斷返回結果的正確性；
4、測試效率問題。
下面我將逐一介紹我們的解決方案：
1、消息獲取的途徑問題：
傳統(tǒng)的接口測試方法主要采用手工編輯接口報文的方法，這種方法只要按照接口文檔的描述構造測試報文就OK了，雖然簡單，但是有失高效。于是這個方法有了升級版本，就是通過參數(shù)化報文中的關鍵字段，批量生成測試案例，這也是接口性能測試的主要方法之一。這個方法雖然解決了獲取報文的效率問題，但是并不能很好解決覆蓋率的問題，畢竟報文是人工構造出來的，并不能非常真實的體現(xiàn)實際的業(yè)務交易場景，實際測試結果也印證了這一觀點。于是，我們想既然傳統(tǒng)的接口測試是在正常的業(yè)務交易測試中覆蓋了，那么我們干脆去直接捕獲前段發(fā)起交易產(chǎn)生的接口消息報文。非常幸運，公司絕大部分的開發(fā)部門都是嚴格按照LOG4J格式記錄應用交易日志的，因此我們只要按照一定的規(guī)則去分析應用的交易日志，就能夠提取出我們所需要的內(nèi)容。
2、消息是否能夠覆蓋所有的程序分支問題：
根據(jù)消息內(nèi)容的不同，應用程序會選擇不同的程序邏輯分支，如何能夠覆蓋所有的分支，傳統(tǒng)方法只有通過白盒測試實現(xiàn)，但是驗收測試更偏重于黑盒或灰盒測試，因此過去經(jīng)常因為測試案例不全面，導致某一個未覆蓋分支的程序問題流入生產(chǎn)環(huán)境。我們目前想到的方法，是通過在系統(tǒng)中導入存量的接口測試案例，并通過日志中捕獲的測試案例，經(jīng)過一段時間的積累，逐漸形成一個較為完整的接口測試案例庫。如果能夠旁路一臺生產(chǎn)環(huán)境應用服務器日志，效果會更好，畢竟生產(chǎn)的交易種類和場景是最全面的，當然這里還要解決生產(chǎn)數(shù)據(jù)脫敏等問題，對于金融行業(yè)還要面對很多制度流程的問題。
3、如何判斷消息返回結果的正確性問題：
每一個應用對于接口報文的設計都是遵照一定的規(guī)范和習慣，我們只需要梳理出標記交易成功狀態(tài)的字段就可以了。某些交易不包含這個字段，我們就需要進行人工判斷，并對成功的結果進行格式化（比如timestamp，流水號等），提取MD5特征值，作為判斷接口后續(xù)測試結果正確性的依據(jù)。不過，狀態(tài)字段是成功并不代表接口測試通過，畢竟返回結果中還包含了很多業(yè)務數(shù)據(jù)字段需要驗證。如果這些字段值變化比較規(guī)律（比如一直不變、持續(xù)增加或減少），我們準備定義一些模型規(guī)則去判斷它們。而那些上躥下跳的數(shù)據(jù)，那就留給人去判斷了。其實，對于冒煙測試而言，我們認為并不需要苛求去判斷每一筆交易的正確性，只需要統(tǒng)計大量測試案例結果的成功率，并與前期成功率進行比較，以判斷測試結果是否正常。
4、執(zhí)行效率的問題
我們理解的冒煙測試是要在盡可能短的時間內(nèi)，對新的版本或測試環(huán)境進行一個準入測試，以判斷其是否具有開展后續(xù)是驗收及適應性測試的條件，因此冒煙測試的效率至關重要。我們的策略是通過異步小批量作業(yè)的方式不間斷的掃描日志處理報文，每日定時并發(fā)的方式去執(zhí)行測試案例，執(zhí)行時間取決于版本安裝時間或測試任務的需要，目前2萬筆測試案例，基本可以控制在10分鐘之內(nèi)。
實現(xiàn)方案：
實現(xiàn)架構非常簡單，就是一套開源的ELK日志采集架構，加上python開發(fā)的接口測試框架和結果統(tǒng)計功能，如下圖所示：
主要步驟如下：
1，通過開源ELK實現(xiàn)應用日志的采集與管理。在客戶端部署logstash agent，并配置日志采集策略；日志記錄以key-value的格式上送REDIS內(nèi)存數(shù)據(jù)庫，這個設計主要是為了在client和server之間做一個緩沖，保證了日志記錄的0丟失；ELSTICSEARCH提供了日志的全文檢索功能，并提供了API服務用來外部調(diào)用
2，利用python的pyes庫調(diào)用ELSATICSEARCH的API服務，根據(jù)特征字段抓取xml和json格式的接口報文。
3，對采集到的接口報文進行格式化處理，格式化日期、流水號或時間戳等字段，并對格式化后的報文做MD5的校驗。
4，利用python的http和socket接口庫實現(xiàn)接口測試案例，這里可能要根據(jù)不同應用做一些客戶化，盡量通過通用的方式實現(xiàn)。
5，對于異常的測試案例進行自動退出。為了保證案例集的可用性，我們這里做了一個簡單的接口退出規(guī)則，如果執(zhí)行超過三次且每次都失敗的接口案例，會被系統(tǒng)自動定義為失效案例。
6，對案例的執(zhí)行結果進行成功率分析和錯誤歸因分析，最終發(fā)現(xiàn)存在的接口問題。這里不再關注每一個測試案例返回的成功和失敗，而是針對每一類接口的成功率、失敗率和錯誤類型進行統(tǒng)計，從數(shù)值和數(shù)量變化的角度去發(fā)現(xiàn)問題。
7，接口定義平臺提供了一個web的接口定義模塊，幫助業(yè)務測試人員根據(jù)接口文檔編輯接口要素，并拼裝成接口報文進行測試。對于復雜的交易場景（比如流程長或交互次數(shù)多），可以在平臺上編排接口的調(diào)用順序和前后項邏輯關系，實現(xiàn)一個比較復雜場景的接口測試。雖然這個功能更偏重于自動化測試，但是這個功能幫助我們實現(xiàn)了無法通過應用前段功能測試覆蓋的接口測試，是非常好的補充。
通過上述方法，我們在一周的時間里，在3個應用進行了試驗，發(fā)現(xiàn)了30多個接口，接近2萬筆報文案例，案例的有效性可以達到了97%。通過每日對這些案例進行自動化測試，發(fā)現(xiàn)了一些接口功能和應用環(huán)境配置的問題。
上述這種測試方法還只是從技術的角度測試，為了滿足實際業(yè)務測試的需求，我們也實現(xiàn)一些簡單的功能：比如我們提供了多維度的測試結果統(tǒng)計；提供基于業(yè)務關鍵字的報文案例和測試結果的檢索功能，以便業(yè)務測試人員快速的找到自己的測試案例；允許業(yè)務測試人員手工修改報文案例庫，這樣就可以跳過應用前端，直接針對接口開展測試；最后我們對每一次執(zhí)行時間都進行記錄，形成了報文案例響應時間的基線，用于后續(xù)的接口性能評估。
總結和問題：
以上方法是一個非常簡單的接口冒煙測試方法，前提是功能測試覆蓋過接口案例，并且接口報文會記錄在日志中。隨著案例和執(zhí)行結果的不斷積累，接口測試覆蓋會更加充分，統(tǒng)計結果會更加精確。如果能夠從生產(chǎn)環(huán)境日志中獲取案例，那么測試效果會更好。上述方法還有很多不成熟的地方，比如對于測試結果的利用上、在失敗報文的歸類和歸因分析上，還應該會有更好的方法。如果全面推廣實施，測試的效率，尤其是測試報文提取和分析的效率還需要進一步提升。
歡迎大家拍磚。
文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/44268.html
摘要：其目的是為了檢測軟件基本組成單位的正確性集成測試將程序的模塊采用適當?shù)募刹呗越M裝起來系統(tǒng)測試對整個軟件進行系統(tǒng)性測試。 ? ? ?1，什么是軟件測試 ? ? ? ? ? ? ? 概念：在規(guī)定的條件下對程序? 進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設計要求進行評估的過程 ?...
摘要：軟件測試筆記一理論篇有句話是這么說的能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。在軟件產(chǎn)品完成了單元測試集成測試和系統(tǒng)測試之后，產(chǎn)品發(fā)布之前所進行的軟件測試活動。 軟件測試筆記（一）理論篇 有句話是這么說的：能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。但是無可否認的是，良好的理論素養(yǎng)...
摘要：軟件測試筆記一理論篇有句話是這么說的能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。在軟件產(chǎn)品完成了單元測試集成測試和系統(tǒng)測試之后，產(chǎn)品發(fā)布之前所進行的軟件測試活動。 軟件測試筆記（一）理論篇 有句話是這么說的：能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。但是無可否認的是，良好的理論素養(yǎng)...
摘要：軟件測試筆記一理論篇有句話是這么說的能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。在軟件產(chǎn)品完成了單元測試集成測試和系統(tǒng)測試之后，產(chǎn)品發(fā)布之前所進行的軟件測試活動。 軟件測試筆記（一）理論篇 有句話是這么說的：能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。但是無可否認的是，良好的理論素養(yǎng)...
摘要：軟件測試筆記一理論篇有句話是這么說的能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。在軟件產(chǎn)品完成了單元測試集成測試和系統(tǒng)測試之后，產(chǎn)品發(fā)布之前所進行的軟件測試活動。 軟件測試筆記（一）理論篇 有句話是這么說的：能動手就別嗶嗶，尤其是在工作節(jié)奏堪比跑馬的今天，大家都推崇實干精神，能解決問題就好，去他的理論。但是無可否認的是，良好的理論素養(yǎng)...
閱讀 3473·2021-11-18 10:02
閱讀 3720·2021-09-13 10:25
閱讀 1928·2021-07-26 23:38
閱讀 2574·2019-08-30 15:44
閱讀 2278·2019-08-30 13:51
閱讀 1232·2019-08-26 11:35
閱讀 2277·2019-08-26 10:29
閱讀 3449·2019-08-23 14:56
