NO IMAGE

一直都在說什麼自動化測試,效能測試,安全測試,介面測試,今天說說介面測試到底是啥東西

本文只是擼點概念,常用的工具。。

介面測試時整合測試實現的一種方式,其實在整合測試中分為訊息介面和程式碼介面測試兩類。

介面是指系統模組與模組或系統與系統間進行互動,一般現在我們用的多的是基於HTTP協議為基礎的介面(包括WebService協議或者Tuxedo協議),還有就是RPC的介面。但是不管哪種介面,其本質就是傳送一個Request報文給伺服器,然後伺服器響應返回一個Response報文。
我們對於Response的報文進行分析,判斷是否和我們傳送給伺服器的Request對應的返回相同,從而驗證業務是否正確實現,這即是介面測試。

 

1)核心:保證系統介面的功能正常
2)方式:持續整合
3)目的:提高測試效率,保證資料的準確性
4)文件:介面測試對介面定義文件要求很高,所有的介面資料型別及業務分支導致的報文返回結構是需要事先定義好的,所以要形成文件的習慣,以方便查閱,儘量減少團隊與團隊間的溝通成本。
同樣我們在介面測試中,也需要根據文件,整理出我們的介面測試資料及介面測試案例,有效的生成相關測試報告,方便其它人去稽核、分析介面測試的成果。

二.介面測試流程
測試人員選擇
1)熟悉測試方法,能夠根據需求制定出測試計劃及測試用例
2)具備一定的程式設計能力
3)瞭解資料庫知識
4)有較強的學習能力,能夠分析業務邏輯中可能存在的問題
職責定義
1)能夠搭建測試框架
2)對系統要深入瞭解
3)能夠對系統可能存在的問題進行預判
4)嚴格把控產品質量

測試框架的選擇及技術選型
介面測試在某種程度上來說,還是屬於灰盒測試,測試框架的選擇與系統本身的語言並無太大的關係。
如果測試框架與被測試系統的語言一致,有些基礎檔案可能還可以複用一下;如果不一致,則要重新的構建資料型別,重新的分析業務邏輯,這樣對測試系統本身也是有極大的好處的。
測試框架的選擇,有一個最重要的點,就是要讓大多數的測試人員都能接受的語言,且有大量的資料可以查閱的語言,這樣才能快速的搭建框架及後期快速的編寫介面測試用例,比如介面測試中JAVA、Python都用的比較多。
介面測試的具體實現及環境部署
介面測試的指令碼的實現是建立在測試用例的基礎之上的,所以,完善的測試用例是必需的,其中測試用例中,請求介面的引數,請求方式,請求的標頭檔案,等這些因素都是必需的,對於響應的response, 返回的狀態碼,返回的資料的檢查點,都是必須要事先說明好的,用例完善後,我們的指令碼在寫起來就會效率很高,在指令碼中,我們需要保證的一點,就是穩定,因為請求的響應時間也是我們要考慮的方面。

介面測試的指令碼的實現是建立在測試用例的基礎之上的,所以,完善的測試用例是必需的,其中測試用例中,請求介面的引數,請求方式,請求的標頭檔案,等這些因素都是必需的,對於響應的response, 返回的狀態碼,返回的資料的檢查點,都是必須要事先說明好的,用例完善後,我們的指令碼在寫起來就會效率很高,在指令碼中,我們需要保證的一點,就是穩定,因為請求的響應時間也是我們要考慮的方面。
介面測試的指令碼必須隨著介面本身的改變而改變,為了達到這種效果,建立良好的溝通機制是很有必要的。(郵件溝通或檢視介面提交LOG都是可行的)
環境部署是測試人員的基本素質,為了使介面測試的結果的穩定性及正確性,我們的環境必須與生產環境保持一致,且與生產環境保持同步更新。

三、介面測試工具
常用工具介紹
發包工具
典型商業工具:loadrunner、soapui
典型開源工具:     jmeter、jsoup、httpclient、python中的urllib2,urllib庫
抓包工具
HTTP抓包:HTTP Analyzer 、HTTPwatch、Fiddler、Firebug
通用資料抓包:MiniSniffer、Sniffer、Omnipeek
程序級抓包:WSExplorer
商業工具特點:良好的圖形操作介面,良好的技術支援,良好的指令碼驅動模式,良好的結果報告,對測試人員的程式碼能力要求稍低等等,但其缺點也很明顯,貴,工具不開源,無法瞭解問題的本質。

開源工具的特點:大量的資料可以查閱(因為用的人多,社群有大量的人一起貢獻),有原始碼可以查閱,可以根據自已的業務特點進行定製化。缺點就是對測試人員的程式碼能力有一定的要求,框架需要從零開始搭建。
工具選擇
1)確定是商業的還是開源的
2)調查測試人員的程式碼熟練程度
3)調查系統的介面型別
4) 開發和維護的成本

HTTP協議報文捕獲

1.Chrome F12

2.Firefox Firebug
Firefox瀏覽器中我們都會安裝Firebug這個外掛,該外掛可以幫助我們方便的對頁面元素進行檢視、除錯,其中也包括了協議捕獲。
在Firefox中安裝了Firebug外掛後,使用F12快捷鍵就可以啟動該外掛。

3.IE HTTPWatch

HTTPWatch是一個商業工具(也提供了免費版本),它可以方便的整合在IE和Firefox上,幫助我們對HTTP協議進行捕獲。

安裝HTTPWatch後,在IE選單欄的工具下會找到該工具的啟動項。

4.Fiddler

Fiddler是一個代理攔截工具,它和上面的幾個工具都不太相同,它不依賴於任何瀏覽器,或者可以這樣說它可以捕獲任意通過它的HTTP資料包。

在Fiddler Option的設定裡面提供了針對代理的埠配置,Fiddler將會監聽8888埠,所有通過這個埠訪問的HTTP協議均會被捕獲,預設情況一般都不需要配置。

接著我們開啟IE(當然也可以啟動任意軟體只要可以配置代理伺服器即可,指向埠8888),檢視IE的代理設定可以看到,IE的預設代理已經被配置指向了Fiddler。

接著我們來看一下這個請求的內容,點選Inspectors標籤。

在上面可以看到完整的Request請求部分,而Response應答部分由於編碼格式問題(一般是GZIP動態壓縮),所以不會自動顯示,我們需要在Transformer裡面做一些配置。
這裡我們設定返回的應答沒有經過壓縮No Compression。接著切換標籤到TextView就可以看到完整的Response正文了。

上面介紹了4種常見的HTTP協議捕獲方式,至於使用Wireshark工具來做HTTP捕獲我覺得可能稍微有些大材小用了,所以這裡就不具體介紹了。

HTTP協議報文傳送
在瞭解了HTTP協議報文後,接著要做的就是如何自己構建HTTP協議包並且傳送給伺服器再獲得對應的響應內容,這也是介面測試的雛形。
1.Poster
Poster是一個Firefox外掛,可以通過Firefox外掛市場更新下載。
通過工具選單或者快捷鍵都可以啟動Poster。

啟動後會彈出一個新的窗體,Poster介面中包含了所需要傳送HTTP請求的地址、請求型別、超時策略、許可權驗證、Header請求頭及Parameter引數配置。

2.PostMan
PostMan是一款在Chrome上執行的請求傳送外掛,由於其需要在谷歌市場上安裝所以相對來說比較麻煩,具體安裝方式FQ或自行查詢開發模式解決。
安裝完成後左上角會有個應用按鈕,點選後就能看到當前在Chrome中安裝的應用,其中就有PostMan。

3.Fiddler
在Fiddler中也提供了對請求定義傳送的功能,點選Composer既可以開啟編輯介面,在這裡按照規範填寫對應的請求報文體系點選Execute即可。

WebService

MockServer

五、介面測試工具SoapUI

呼叫We server、呼叫http、代理設定、擴充套件請求

六、介面測試工具LoadRunner

呼叫We server、呼叫http、代理設定

七、介面測試框架Jsoup

Jsoup、TestNG