掃盲內容:

1.為什么要做接口測試?

2.怎樣做接口測試?

3.接口測測試點是什么?

4.接口測試都要掌握哪些知識?

5.其他相關知識?

一.為什么要做接口測試?

①.越底層發現bug,它的修復成本是越低的。

②.前端隨便變,接口測好了,后端不用變,前后端是兩撥人開發的。

③.檢查系統的安全性、穩定性,前端傳參不可信,比如京東購物,前端價格不可能傳入-1元,但是通過接口可以傳入-1元。

④.如今的系統復雜度不斷上升,傳統的測試方法成本急劇增加且測試效率大幅下降,接口測試可以提供這種情況下的解決方案。

⑤. 接口測試相對容易實現自動化持續集成,且相對UI自動化也比較穩定,可以減少人工回歸測試人力成本與時間,縮短測試周期,支持后端快速發版需求。接口持續集成是為什么能低成本高收益的根源。

⑥. 現在很多系統前后端架構是分離的,從安全層面來說:

(1)、只依賴前端進行限制已經完全不能滿足系統的安全要求(繞過前面實在太容易), 需要后端同樣進行控制,在這種情況下就需要從接口層面進行驗證。

(2)、前后端傳輸、日志打印等信息是否加密傳輸也是需要驗證的,特別是涉及到用戶的隱私信息,如身份證,銀行卡等。

二.怎樣做接口測試?

由于我們項目前后端調用主要是基于http協議的接口,所以測試接口時主要是通過工具或代碼模擬http請求的發送與接收。工具有很多如:

postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

也可以用接口自動化來實現,就是用代碼實現,框架和UI自動化差不多,發送請求用斷言來判斷。

三.接口測試中心思想是什么?

目的:測試接口的正確性和穩定性;

原理:模擬客戶端向服務器發送請求報文,服務器接收請求報文后對相應的報文做處理并向客戶端返回應答,客戶端接收應答的過程;

重點:檢查數據的交換,傳遞和控制管理過程,還包括處理的次數;

核心:持續集成是接口測試的核心;

優點:為高復雜性的平臺帶來高效的缺陷監測和質量監督能力,平臺越復雜,系統越龐大,接口測試的效果越明顯(提高測試效率,提升用戶體驗,降低研發成本);

用例設計重點:通常情況下主要測試最外層的兩類接口:數據進入系統接口(調用外部系統的參數為本系統使用)和數據流出系統接口(驗證系統處理后的數據是否正常);

PS:設計用例時還需要注意外部接口提供給使用這些接口的外部用戶什么功能,外部用戶真正需要什么功能;

1、基本功能測試:

由于是針對基本業務功能進行測試,所以這部分是兩種測試重合度最高的一塊,開發同學通常所指的也主要是這部分的內容。

2、邊界分析測試:

在基本功能測試的基礎上考慮輸入輸出的邊界條件,這部分內容也會有重復的部分(比如業務規則的邊界)。但是,前端的輸入輸出很多時候都是提供固守的值讓用戶選擇(如下拉框),在這種情況下測試的邊界范圍就非常有限,但接口測試就不存在這方面的限制,相對來說接口可以覆蓋的范圍更廣,同樣的,接口出現問題的概率也更高。

3、性能測試:

這個比較容易區分,雖然都需要做性能測試,但關注點確大不相同。App端性能主要關注與手機相關的特性,如手機cpu、內存、流量、fps等。而接口性能主要關注接口響應時間、并發、服務端資源的使用情況等。兩種測試時的策略和方法都有很大區別,所以這部分內容是需要分開單獨進行測試的,理論上來說這也是不同的部分。

四.接口測試都要掌握哪些知識?

①了解系統及內部各個組件之間的業務邏輯交互;

②了解接口的I/O(input/output:輸入輸出);

③了解協議的基本內容,包括:通信原理、三次握手、常用的協議類型、報文構成、數據傳輸方式、常見的狀態碼、URL構成等;

④常用的接口測試工具,比如:jmeter、loadrunner、postman、soapUI等;

⑤數據庫基礎操作命令(檢查數據入庫、提取測試數據等);

⑥常見的字符類型,比如:char、varchar、text、int、float、datatime、string等;

如何學這些技能?

①系統間業務交互邏輯:通過需求文檔、流程圖、思維導圖、溝通等很多渠道和方式;

②協議:推薦《圖解http》這本書,內容生動,相對算是入門級的書籍,其他的還有《圖解tcp、IP》等;

③接口測試工具:百度這些工具,然后你會發現,好多的教學博客、相關問題解決方案、以及一些基于工具的書籍,當然,選擇合適的書很重要;

④數據庫操作命令:學習網站(W3C、菜鳥教程)、教學博客,以及一些數據庫相關書籍,入門級推薦:《mysql必知必會》、《oracle PL/SQL必知必會》等

⑤字符類型:還是百度,有句話這么說:內事不決問百度,外事不決問Google。。。

接口文檔八要素:

封面:封面最好是本公司規定的封面,有logo,內容標題,版本號,公司名稱,文檔產生日期;

修訂歷史:表格形式較好些,包括:版本、修訂說明、修訂日期、修訂人、審核時間審核人等;

接口信息:接口調用方式,常用的GET/POST方式,接口地址;

功能描述:簡潔清晰的描述接口功能,比如:接口獲取的信息不包括哪些;

接口參數說明:每個參數都要和實際中調用的一樣,包括大小寫;參數的含義言簡意賅的說明,格式,是string 還是int 還是long等格式;

說明部分,說明參數值是需要哪里提供,并詳細說明參數怎么生成的,例如時間戳,是哪個時間段的,參數是否必填,一些參數是必須要有的,有些是可選參數等;

返回值說明:

①最好有一個模板返回值,并說明每個返回參數的意義;

②提供一個真實的調用接口,真實的返回值;

調用限制,安全方面:

加密方式,或者自己公司一個特殊的加密過程,只要雙方采用一致的加密算法就可以調用接口,保證了接口調用的安全性,比如常見的md5;

文檔維護:文檔在維護的時候,如有修改一定要寫上修改日期,修改人,對大的修改要有版本號變更;

五.其他相關知識?

get請求,post請求的區別:

1、GET使用URL或Cookie傳參。而POST將數據放在BODY中。

2、GET的URL會有長度上的限制,則POST的數據則可以非常大。

3、POST比GET安全,因為數據在地址欄上不可見。

4、一般get請求用來獲取數據,post請求用來發送數據。

其實上面這幾點,只有最后一點說的是比較靠譜的,第一點post請求也可以把數據放到url里面,get請求其實也沒長度限制,post請求看起來參數是隱式的,稍微安全那么一些些,但是那只是對于小白用戶來說的,就算post請求,你通過抓包也是可以抓到參數的。(唯一區別就是這一點,上面3點區別都是不準確的)

http狀態碼:

1、200 2開頭的都表示這個請求發送成功,最常見的就是200,就代表這個請求是ok的,服務器也返回了。

2、300 3開頭的代表重定向,最常見的是302,把這個請求重定向到別的地方了。

3、400 400代表客戶端發送的請求有語法錯誤,401代表訪問的頁面沒有授權,403表示沒有權限訪問這個頁面,404代表沒有這個頁面。

4、500 5開頭的代表服務器有異常,500代表服務器內部異常,504代表服務器端超時,沒返回結果。

webservice接口怎么測試:

它不需要你在拼報文了,會給一個webservice的地址,或者wsdl文件,直接在soapui導入,就可以看到這個webservice里面的所有接口,也有報文,直接填入參數調用,看返回結果就可以了。

cookie與session的區別:

1、cookie數據存放在客戶的瀏覽器上,session數據放在服務器上。

2、cookie不是很安全,別人可以分析存放在本地的cookie并進行cookie欺騙考慮到安全應當使用session。

3、session會在一定時間內保存在服務器上。當訪問增多,會比較占用你服務器的性能考慮到減輕服務器性能方面,應當使用cookie。

4、單個cookie保存的數據不能超過4K,很多瀏覽器都限制一個站點最多保存20個cookie。

5、所以個人建議:

將登陸信息等重要信息存放為session

其他信息如果需要保留,可以放在cookie中