接口測試全流程掃盲

jmeter接口層性能與自動化測試視訊：http://edu.51cto.com/course/14305.html

一.什麼是接口？

接口測試主要用于外部系統與系統之間以及内部各個子系統之間的互動點，定義特定的互動點，然後通過這些互動點來，通過一些特殊的規則也就是協定，來進行資料之間的互動。

二.接口都有哪些類型？

接口一般分為兩種：

1.程式内部的接口

2.系統對外的接口

系統對外的接口：比如你要從别的網站或伺服器上擷取資源或資訊，别人肯定不會把資料庫共享給你，他隻能給你提供一個他們寫好的方法來擷取資料，你引用他提供的接口就能使用他寫好的方法，進而達到資料共享的目的。

程式内部的接口：方法與方法之間，子產品與子產品之間的互動，程式内部抛出的接口，比如bbs系統，有登入子產品、發帖子產品等等，那你要發帖就必須先登入，那麼這兩個子產品就得有互動，它就會抛出一個接口，供内部系統進行調用。

接口的分類：

1.webservice接口 

2.http api接口

webService接口是走soap協定通過http傳輸，請求封包和傳回封包都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。

http api接口是走http協定，通過路徑來區分調用的方法，請求封包都是key-value形式的，傳回封包一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。

json是一種通用的資料類型，所有的語言都認識它。（json的本質是字元串，他與其他語言無關，隻是可以經過稍稍加工可以轉換成其他語言的資料類型，比如可以轉換成Python中的字典，key-value的形式，可以轉換成JavaScript中的原生對象，可以轉換成java中的類對象等。）

三.接口的本質及其工作原理是什麼？

接口你可以簡單的了解他就是URL，工作原理就會說URL通過get或者post請求像伺服器發送一些東西，然後得到一些相應的傳回值，本質就是資料的傳輸與接收。

四.什麼是接口測試？

接口測試是測試系統元件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及内部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的互相邏輯依賴關系等。

--百度百科

簡答的說就是通過URL像伺服器或者其他子產品等，傳輸我們想傳輸的資料，然後看看他們傳回的是不是我們預期想要的。

五.問什麼要做接口測試？

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

②.前端随便變，接口測好了，後端不用變，前後端是兩撥人開發的。

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

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

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

⑥.   現在很多系統前後端架構是分離的，從安全層面來說：

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

(2)、前後端傳輸、日志列印等資訊是否加密傳輸也是需要驗證的，特别是涉及到使用者的隐私資訊，如×××，銀行卡等。

六.怎樣做接口測試？

--由于我們項目前後端調用主要是基于http協定的接口，是以測試接口時主要是通過工具或代碼模拟http請求的發送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

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

七.接口測測試點是什麼？

目的：測試接口的正确性和穩定性；

原理：模拟用戶端向伺服器發送請求封包，伺服器接收請求封包後對相應的封包做處理并向用戶端傳回應答，用戶端接收應答的過程；

重點：檢查資料的交換，傳遞和控制管理過程，還包括處理的次數；

核心：持續內建是接口測試的核心；

優點：為高複雜性的平台帶來高效的缺陷監測和品質監督能力，平台越複雜，系統越龐大，接口測試的效果越明顯（提高測試效率，提升使用者體驗，降低研發成本）；

用例設計重點：通常情況下主要測試最外層的兩類接口:資料進入系統接口（調用外部系統的參數為本系統使用）和資料流出系統接口（驗證系統處理後的資料是否正常）；

PS：設計用例時還需要注意外部接口提供給使用這些接口的外部使用者什麼功能，外部使用者真正需要什麼功能；

1、基本功能測試：

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

2、邊界分析測試：

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

 3、性能測試：

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

 綜論：

1、接口測試和app測試的活動有部分重複的内容，主要集中在業務功能測試方面。除此之外，針對各自特性的測試都不一樣，需要分别進行有針對性的測試，才能確定整個産品的品質。

2、接口測試可以關注于伺服器邏輯驗證，而UI測試可以關注于頁面展示邏輯及界面前端與伺服器內建驗證

3、接口測試持續內建：

對接口測試而言，持續內建自動化是核心内容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實作了接口自動化，主要應用于回歸階段，後續還需要加強自動化的程度，包括但不限于下面的内容：

a) 流程方面：在回歸階段加強接口異常場景的覆寫度，并逐漸向系統測試，冒煙測試階段延伸，最終達到全流程自動化。

b) 結果展示：更加豐富的結果展示、趨勢分析，品質統計和分析等

c) 問題定位：報錯資訊、日志更精準，友善問題複現與定位。

d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。

e) 代碼覆寫率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆寫率。

f) 性能需求：完善性能測試體系，通過自動化的手段監控接口性能名額是否正常。

4、接口測試品質評估标準：

a) 業務功能覆寫是否完整

b) 業務規則覆寫是否完整

c) 參數驗證是否達到要求（邊界、業務規則）

d) 接口異常場景覆寫是否完整

e) 接口覆寫率是否達到要求

f)  代碼覆寫率是否達到要求

g) 性能名額是否滿足要求

h) 安全名額是否滿足要求

八.接口測試都要掌握哪些知識？

①了解系統及内部各個元件之間的業務邏輯互動；

②了解接口的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、是以個人建議：