?如能幫到你，下方為我們點個在看??推薦：15款“云買菜”平臺如何選？36城200名體驗者告訴你！注：文章原標題“接口測試與服務虛擬化”正文開始：什么是接口測試?前幾年當我們提自動化測試時，很多時候是指UI界面層的自動化測試。但是近年來隨著分層自動化測試(圖1)概念的興起以及自動化測試自身的發展與細分，自動化測試有了更多的內容。比如本文即將要談到的接口自動化測試，就是其中一種。

圖1：分層自動化測試接口測試并沒有一個標準的定義，老外的文章也較少提"Interface Testing"這個詞，一般見到比較多的是"API Testing"。我們從百度百科可以查到，“接口測試是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等”。這幾年隨著微服務架構的流行與發展，在接口測試領域又蹦出了一個詞，叫“契約測試”(Consumer-DrivenContracts Testing，簡稱CDC Testing)。但是正所謂萬變不離其宗，無論如何稱呼，始終都是圍繞著系統與系統之間，接口與接口之間邏輯的正確性來開展測試，所以也是屬于接口測試的一種。很多人一談到接口自動化測試，首當其沖就想到SoapUI，Postmon或者JMeter等接口自動化測試工具。誠然，這些工具都是屬于接口自動化測試的利器，解決了模擬客戶端向服務端發請求并且校驗結果的功能。但是在筆者看來，這些還不是接口自動化測試的全部內涵。讓我們再回顧接口測試的定義，接口測試是測試系統組件間接口的一種測試，言下之意也就是說不僅要模擬客戶端組件測服務端功能，也要模擬服務端組件測客戶端功能，只有雙向都能進行測試，才是完整“接口測試”的含義。而對于模擬服務端，我們有一個高大上的術語，叫“服務虛擬化”，在老外的文章中經常會看到這個詞的英文翻譯叫：“Service Virtualization”。什么是服務虛擬化？筆者最早接觸服務虛擬化這個詞，是在2013年左右。當時IBM收購了英國一家專門做接口測試工具的廠商叫“Green Hat”(這家公司在歐美很成功，四五十人的團隊每年的營業額卻能達到幾千萬美元)。由于Green Hat的中文翻譯有點令人尷尬，所以IBM索性改名為Rational Integration Tester，同時還配套推出了一本電子書叫“Service Virtualization for Dummies”。這本書有六七十頁，很系統的講了服務虛擬化的知識。那么，究竟什么是服務虛擬化呢？服務虛擬化是指通過錄制或構造建模的方式產生服務仿真模塊(圖2)，從而配合客戶端組件進行功能測試。看到這里可能有人會說，這不就是樁(Stub)嗎？我讓開發人員碼一個出來不就行了？確實，生成樁是結果，但是請注意生成樁的過程，服務虛擬化是通過錄制或構造建模生成樁，而不是要靠開發人員大量編碼來生成。設想，要是一個復雜系統有上百的不同協議不同報文格式的接口，開發人員一個個開發，那是何等大的開發量！

圖2：服務虛擬化服務虛擬化的價值那么服務虛擬化究竟有什么價值呢？筆者認為主要有以下幾點：1. 節省建設測試環境的費用大家知道，我們的測試環境一般有幾套，像常見的集成測試環境、系統測試環境、系統集成測試環境等等；如果這些環境所需的硬件資源要求不高則罷，若是要求很高的話是很難為每套環境都配置資源的。比如銀行corebanking有不少是用IBM system Z大機，這種一臺動輒上億投入的硬件，是根本不可能會隨便能配幾套做測試環境的。很多時候當進行前期的測試時如果需要跟核心系統聯調的話，勢必會存在資源不足的情況。這種情況下，如果能把核心系統的接口服務進行虛擬化，那么測試的過程則不必需要真的去調真正的接口，但同時也能使得整個交易的測試過程進行下去。這樣就可以在前期測試階段減少了大量的投入。另外一個方面是關于第三方測試環境，比如大家知道萬事達信用卡。如果您是作為銀行系統的測試人員，要想隨時和萬事達接口聯調是很困難的，而且每個月你還必須為聯調測試環境附上一筆不菲的租賃費用。那么我們其實也可以利用服務虛擬化技術，在測試前期通過和虛擬服務樁的測試，確保早點完成業務交易測試過程，從而節省了第三方測試license的費用。2. 縮減環境建設時間在整個測試過程中，測試環境的搭建是非常花費時間的。據業界統計，大概有40%的測試時間都花在環境搭建上面。我們如果在前期測試階段的環境中某些子系統或者組件利用服務虛擬化的技術，簡單的生成可測試的樁，這樣不僅能保證測試的業務流程不會阻塞，還能大大簡化整個測試環境的搭建時間，給項目帶來非常大的幫助。3. 降低風險我們在做系統聯調測試的時候最怕的就是那種所謂的“Big-Bang Testing”，也就是在測試的前面階段由于環境不具備、對端接口沒完成等各種環境問題導致測試人員在不停的等待，直到所有的環境接口都開發完后而測試時間所剩無幾的情況下再進行測試。這時的情況就像定時炸彈一樣隨時都有可能爆炸。為了避免“Big-Bang Testing”，就需要我們在前期階段就開始測試，這時需要通過服務虛擬化，先對自己的接口模塊進行自測，盡早發現問題并且盡早解決，從而降低了項目的質量風險。服務虛擬化的局限任何事情都有兩面性，前面談了服務虛擬化這么多好處，當然它也是有局限性的，比如它就不是很適合在用戶驗收測試階段。因為用戶驗收測試階段已經到了測試尾聲階段，這時需要在最接近生產系統的環境進行測試，而如果還用假的服務來測試當然會影響到結果的正確性。所以服務虛擬化最佳的適用測試階段應該是單元測試、集成測試、接口聯調等測試前期階段。接口測試工具現在一般開源的接口測試工具只能解決模擬客戶端測服務端的單向接口測試，而能做到模擬服務端提供服務虛擬化能力的開源工具幾乎沒有。具有雙向測試能力的工具基本上都是商業工具，比如CA的Lisa，IBM的Rational Integration Tester(圖3)，惠普(現在被MicroFocus收購)，Parasoft，Smartbear等。

圖3：IBM Rational Integration Tester架構圖拋開商業開源之分，單從技術上來說，什么樣的接口測試工具是好的測試工具？筆者認為好的接口測試工具必須具備以下幾個條件：1. 能一個工具同時支持雙向測試過程。也就是即能模擬客戶端，也能模擬服務端。從這點看，大部分的開源接口測試工具功能都太有限。而其實即使是惠普的接口測試工具，也是客戶端和服務端分開成兩個工具(至少在2016年前是這樣)。這樣會給測試人員帶來很大的不便，同時也不能充分利用錄制或構建一次測試報文可以同時給雙向的測試用例使用。在客戶端接口自動化測試功能方面：* 需要支持正則表達式；* 需要支持實際測試結果與預期結果自動比較，自動告知成功/失敗，同時自動高亮顯示失敗的行數，杜絕人肉觀察的情況；* 需要支持復雜邏輯，比如分支、循環、判斷、會話連接和參數傳遞* 需要可擴展功能，支持自定義函數；在服務端虛擬化功能方面：* 需要能根據不同的請求返回不同的結果；* 需要支持復雜邏輯，比如分支、循環、判斷、會話連接和參數傳遞* 需要能支持多并發，多用戶同時使用* 需要能支持樁的定時起停；* 需要能支持CI持續集成和DevOps2. 支持越多的通訊協議、消息報文和行業標準接口自動化測試工具的強大與否，很重要的一點就是能否支持更多的協議、報文和標準。如果不能支持協議，通訊就好像雞同鴨講；如果不能支持報文格式，就好像獲取了天書，根本不知道里面是什么內容，也就無法進行正確的解析。至少工具需要對業界流行的協議、報文和標準支持，才能更加方便的讓測試人員使用一個工具能進行更多的接口自動化測試。比如:Web方面：Http/Https、Webservice，Soap等；中間件方面：WebSphere、WebLogic、Tomcat等消息中間件方面：MQ、Tuxedo等；傳輸方面：FTP、TCP等；數據庫方面：Oracle、DB2等；報文格式方面：XML、Json、Stream等；行業標準方面：Fix、Swift、銀聯ISO8582等總結接口測試一般是在集成測試階段進行，很多時候都是在沒有界面的環境下進行測試，所以借助接口測試工具來進行測試是一個比較合適的方式。當然，在選擇接口測試工具的時候最關鍵的還是要根據實際情況來選擇，商業的工具功能強大操作方便但是貴；開源的工具功能較弱但是免費，針無兩頭尖。如果只是簡單的接口，找個開源工具進行測試，又何必非得花錢買商業工具殺雞用牛刀呢？

——————— ?End??———————

測試大咖秀5000人QQ交流群：QQ群號：636803769加群暗號：武漢加油，中國加油！測試大咖秀微信交流群：請加群主微信 1327239410回復數字2視頻公開課：釘釘掃描下方海報進入直播群即可！

如能幫到你，為我們點個在看哦?

總結

以上是生活随笔為你收集整理的tcp接口测试工具_你不了解的，完整“接口测试”与服务虚拟化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。