接口測試簡介
1.什么是接口
接口就是內(nèi)部模塊對模塊，外部系統(tǒng)對其他服務提供的一種可調(diào)用或者連接的能力的標準，就好比usb接口，他是系統(tǒng)向外接提供的一種用于物理數(shù)據(jù)傳輸?shù)囊粋€接口，當然僅僅是一個接口是不能進行傳輸?shù)?，我們還的對這個接口怎么進行傳輸進行進行一些設置和定義。開發(fā)所謂的接口是模塊模塊之間的一種連接，而測試眼中的接口是一種協(xié)議（對接口的功能的一種定義）
2.接口的種類和分類
外部接口，內(nèi)部接口：上層服務于下層服務，同級服務。常見的接口分類http：get，post，delete，put
系統(tǒng)對外的接口：比如你要從別的網(wǎng)站或服務器上獲取資源或信息，別人肯定不會把數(shù)據(jù)庫共享給你，他只能給你提供一個他們寫好的方法來獲取數(shù)據(jù)，你引用他提供的接口就能使用他寫好的方法，從而達到數(shù)據(jù)共享的目的。
程序內(nèi)部的接口：方法與方法之間，模塊與模塊之間的交互，程序內(nèi)部拋出的接口，比如bbs系統(tǒng)，有登錄模塊、發(fā)帖模塊等等，那你要發(fā)帖就必須先登錄，那么這兩個模塊就得有交互，它就會拋出一個接口，供內(nèi)部系統(tǒng)進行調(diào)用。
接口的分類：1.webservice接口 2.http api接口
webService接口是走soap協(xié)議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調(diào)用，測試。
http api接口是走http協(xié)議，通過路徑來區(qū)分調(diào)用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。
json是一種通用的數(shù)據(jù)類型，所有的語言都認識它。（json的本質(zhì)是字符串，他與其他語言無關，只是可以經(jīng)過稍稍加工可以轉換成其他語言的數(shù)據(jù)類型，比如可以轉換成Python中的字典，key-value的形式，可以轉換成JavaScript中的原生對象，可以轉換成java中的類對象等。）
3.各個接口之間的區(qū)別
通常我們測試的接口分為get接口和post接口，get的提交方式是明文提交，把提交的參數(shù)跟在url后面發(fā)送給服務器，所以不安全，而且get提交的參數(shù)是有字符限制的且可以被當做書簽保存，但是post的提交方式跟get完全不一樣，post提交的參數(shù)是放在表單里的，所以不會存在字符限制，而且因為參數(shù)是放在表單里，不容易被看到，所以會比get更安全。
4.什么是接口測試
簡單的來說接口測試對于測試來說其實是對接口協(xié)議的一種測試，這個協(xié)議指的是為了讓這個接口實現(xiàn)某種需要的功能還設計的一種要求。
5.為什么要進行接口測試
因為不同端（前段，后端）的工作進度不一樣，所以我們要針對最開始出來的接口，以及需要調(diào)用其他公司的（銀行，支付寶，微信，qq等）一些接口進行接口測試及驗證數(shù)據(jù)，從安全層面來說，只依賴前端進行限制已經(jīng)完全不能滿足系統(tǒng)的安全要求（繞過前面實在太容易），需要后端同樣進行控制，在這種情況下就需要從接口層面進行驗證。前后端傳輸、日志打印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。
6.接口測試流程
需求討論，需求評審，場景設計，編寫用列，準備數(shù)據(jù)，執(zhí)行測試
7.怎么進行接口測試
通過工具模擬客戶端向服務端發(fā)送請求并接受服務器返回的數(shù)據(jù)來對接口的功能，邏輯業(yè)務，異常，安全進行測試
功能測試：測試這個接口的功能是否實現(xiàn)，并且測試這個接口是否按照接口文檔來進行開發(fā)的（比如說接口文檔規(guī)定了一些關鍵字，而開大的時候把關鍵字改成了其他的關鍵字，因為在整個項目周期，并不只有一個開發(fā)而是有多個，所以可能因為在開發(fā)過程中因為關鍵字不一樣導致某些開發(fā)的功能異常，還有自動化腳本也會發(fā)生異常）
邏輯業(yè)務，主要指的是一些邏輯業(yè)務依賴關系（比如支付寶提交訂單的時候要保證你是在登錄的情況下，如果你沒有登錄而提交成功了，這就是異常，可以修改請求的cookie來測試）
異常測試：參數(shù)異常：關鍵字參數(shù)（應用其他的關鍵字替換進行測試）、參數(shù)為空、參數(shù)多少（通過添加參數(shù)增添個數(shù)），參數(shù)錯誤。數(shù)據(jù)異常：關鍵字數(shù)據(jù)（填入的數(shù)據(jù)用其他的數(shù)據(jù)語言的數(shù)據(jù)替用）、數(shù)據(jù)長度、數(shù)據(jù)為空、數(shù)據(jù)錯誤。
由于我們項目前后端調(diào)用主要是基于http協(xié)議的接口，所以測試接口時主要是通過工具或代碼模擬http請求的發(fā)送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
–也可以用 接口自動化來實現(xiàn)，就是用代碼實現(xiàn)，框架和UI自動化差不多，發(fā)送請求用斷言來判斷。
8.接口測試需要用到的工具
接口測試常用的工具，fiddler抓取請求，postman模擬客戶端通過對fiddler抓取的請求修改并發(fā)送到服務端并接收服務器返回的數(shù)據(jù)及異常來進行驗證接口。工具不是固定的，需要根據(jù)項目來進行選擇。
9.接口的本質(zhì)及其工作原理
接口你可以簡單的理解他就是URL，工作原理就會說URL通過get或者post請求像服務器發(fā)送一些東西，然后得到一些相應的返回值，本質(zhì)就是數(shù)據(jù)的傳輸與接收。
接口測試用例設計思路
目的：測試接口的正確性和穩(wěn)定性；
原理：模擬客戶端向服務器發(fā)送請求報文，服務器接收請求報文后對相應的報文做處理并向客戶端返回應答，客戶端接收應答的過程；
重點：檢查數(shù)據(jù)的交換，傳遞和控制管理過程，還包括處理的次數(shù)；
核心：持續(xù)集成是接口測試的核心；
優(yōu)點：為高復雜性的平臺帶來高效的缺陷監(jiān)測和質(zhì)量監(jiān)督能力，平臺越復雜，系統(tǒng)越龐大，接口測試的效果越明顯（提高測試效率，提升用戶體驗，降低研發(fā)成本）；
用例設計重點：通常情況下主要測試最外層的兩類接口:數(shù)據(jù)進入系統(tǒng)接口（調(diào)用外部系統(tǒng)的參數(shù)為本系統(tǒng)使用）和數(shù)據(jù)流出系統(tǒng)接口（驗證系統(tǒng)處理后的數(shù)據(jù)是否正常）；
PS：設計用例時還需要注意外部接口提供給使用這些接口的外部用戶什么功能，外部用戶真正需要什么功能；
1 輸入
輸入?yún)?shù)主要從以下幾各方面設計：
a 必填項校驗
接口文檔中有是否必填的說明。參考接口文檔即可。
b 參數(shù)長度校驗
參考接口文檔即可。
c 參數(shù)值的有效性校驗
如：身份證號的校驗 ，設計的數(shù)據(jù)雖然符合身份證號的規(guī)則，但是并不是真實有效的身份證號；這種情況就要看身份證號的校驗規(guī)則是什么樣了，一般都是用的現(xiàn)成的身份證號校驗器，但是有些是自己寫的校驗算法，這個本人就遇到過這種問題—校驗算法寫的不正確；
所以參數(shù)有效性的校驗就需要結合實際業(yè)務場景，判斷哪些數(shù)據(jù)是真實有效的數(shù)據(jù)，一定要確保所有真實有效的數(shù)據(jù)是可以驗證通過的。
d 參數(shù)組合校驗
不同的參數(shù)組合可能會存在不同的業(yè)務場景；
e 如果參數(shù)是枚舉值，一定要各種枚舉值都要測試，因為可能不同的枚舉走的不同的業(yè)務流程；
f 參數(shù)值的默認值的校驗
參考接口文檔。
g 某些參數(shù)具有特定的生成規(guī)則，要單獨針對生成規(guī)則設計用例，一定要保證真實有效的數(shù)據(jù)是可以驗證通過的。
如身份證號中間幾位 ***19860701*，本人就遇到過輸入***19861001*這種值校驗不正確；
2 接口邏輯
接口邏輯我用的設計方法是分支覆蓋—>路徑覆蓋—>場景覆蓋,同樣也是要結合實際業(yè)務場景，根本不發(fā)生的業(yè)務場景就是無效的測試用例。
a 第一步先把業(yè)務流程圖畫出來；
b 依據(jù)路程圖中的分支分別設計，不同分支不同的場景，這里就要把異常的場景考慮進去；如接口超時，接口異常，接口請求成功或失敗，成功后怎么處理，失敗后流程是否繼續(xù)執(zhí)行，失敗后的數(shù)據(jù)怎么處理；
以打款接口為例：
打款結果有打款成功或打款失敗，成功后怎么處理，需要回寫打款成功狀態(tài)，失敗后怎么處理，也需要回寫失敗狀態(tài)，失敗后的數(shù)據(jù)可以操作退回，也可以操作重新出款等等；
c 測試邏輯設計完成后要想一想不同的業(yè)務場景怎么去測試，需要哪些人員協(xié)助，
如接口超時怎么去測試，請求重復怎么去測試，請求并發(fā)怎么去測試
3 輸出
輸入結果：正常輸出和異常輸出，常用的方法有錯誤推斷法（列舉出程序中可能存在的錯誤或者異常，根據(jù)他們選擇測試用例）
4 以上都完成后，要結合實際的業(yè)務場景去掉冗余的用例（即實際業(yè)務場景不存在的流程或者輸入數(shù)據(jù)）；
5 如果業(yè)務流程涉及到狀態(tài)轉換，要單獨設計用戶—方法：狀態(tài)轉換圖；
6 涉及到多個不同金額或者手續(xù)費的計算，可能還會用到正交實驗法去設計用例；
7 另外，用例設計中還應當包含異常流程中產(chǎn)生的異常數(shù)據(jù)的處理流程；—通常所說的補償機制，這塊流程能大大的減輕人工運營的工作量，當然，這需要在做系統(tǒng)設計的時候就需要把這部分考慮進去。
接口測試和app測試的相同和區(qū)別
1.兩者區(qū)別：App端性能主要關注與手機相關的特性，如手機cpu、內(nèi)存、流量、fps等。而接口性能主要關注接口響應時間、并發(fā)、服務端資源的使用情況等。兩種測試時的策略和方法都有很大區(qū)別，所以這部分內(nèi)容是需要分開單獨進行測試的，理論上來說這也是不同的部分。
2.接口測試持續(xù)集成：
對接口測試而言，持續(xù)集成自動化是核心內(nèi)容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經(jīng)實現(xiàn)了接口自動化，主要應用于回歸階段，后續(xù)還需要加強自動化的程度，包括但不限于下面的內(nèi)容：
a) 流程方面：在回歸階段加強接口異常場景的覆蓋度，并逐步向系統(tǒng)測試，冒煙測試階段延伸，最終達到全流程自動化。
b) 結果展示：更加豐富的結果展示、趨勢分析，質(zhì)量統(tǒng)計和分析等
c) 問題定位：報錯信息、日志更精準，方便問題復現(xiàn)與定位。
d) 結果校驗：加強自動化校驗能力，如數(shù)據(jù)庫信息校驗。
e) 代碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆蓋率。
f) 性能需求：完善性能測試體系，通過自動化的手段監(jiān)控接口性能指標是否正常。
最后ps：接口測試需要掌握的知識。
?、倭私庀到y(tǒng)及內(nèi)部各個組件之間的業(yè)務邏輯交互；
②了解接口的I/O（input/output：輸入輸出）；
?、哿私鈪f(xié)議的基本內(nèi)容，包括：通信原理、三次握手、常用的協(xié)議類型、報文構成、數(shù)據(jù)傳輸方式、常見的狀態(tài)碼、URL構成等；
?、艹Ｓ玫慕涌跍y試工具，比如：jmeter、loadrunner、postman、soapUI等；
⑤數(shù)據(jù)庫基礎操作命令（檢查數(shù)據(jù)入庫、提取測試數(shù)據(jù)等）；
⑥常見的字符類型，比如：char、varchar、text、int、float、datatime、string等；
如何學這些技能？
①系統(tǒng)間業(yè)務交互邏輯：通過需求文檔、流程圖、思維導圖、溝通等很多渠道和方式；
?、趨f(xié)議：推薦《圖解http》這本書，內(nèi)容生動，相對算是入門級的書籍，其他的還有《圖解tcp、IP》等；
?、劢涌跍y試工具：百度這些工具，然后你會發(fā)現(xiàn)，好多的教學博客、相關問題解決方案、以及一些基于工具的書籍，當然，選擇合適的書很重要；
?、軘?shù)據(jù)庫操作命令：學習網(wǎng)站（W3C、菜鳥教程）、教學博客，以及一些數(shù)據(jù)庫相關書籍，入門級推薦：《mysql必知必會》、《oracle PL/SQL必知必會》等
?、葑址愋停哼€是百度，有句話這么說：內(nèi)事不決問百度，外事不決問Google。。。
如何獲取接口相關信息？
一般的企業(yè)，都會由開發(fā)或者對應的技術負責人員編寫接口文檔，里面會注明接口相關的地址、參數(shù)類型、方法、輸入、輸出等信息，如果沒有，想辦法獲取。。。
接口文檔八要素：
封面：封面最好是本公司規(guī)定的封面，有l(wèi)ogo，內(nèi)容標題，版本號，公司名稱，文檔產(chǎn)生日期；
修訂歷史：表格形式較好些，包括：版本、修訂說明、修訂日期、修訂人、審核時間審核人等；
接口信息：接口調(diào)用方式，常用的GET/POST方式，接口地址；
功能描述：簡潔清晰的描述接口功能，比如：接口獲取的信息不包括哪些；
接口參數(shù)說明：每個參數(shù)都要和實際中調(diào)用的一樣，包括大小寫；參數(shù)的含義言簡意賅的說明，格式，是string 還是int 還是long等格式；
說明部分，說明參數(shù)值是需要哪里提供，并詳細說明參數(shù)怎么生成的，例如時間戳，是哪個時間段的，參數(shù)是否必填，一些參數(shù)是必須要有的，有些是可選參數(shù)等；
返回值說明：
?、僮詈糜幸粋€模板返回值，并說明每個返回參數(shù)的意義；
?、谔峁┮粋€真實的調(diào)用接口，真實的返回值；
調(diào)用限制，安全方面：
加密方式，或者自己公司一個特殊的加密過程，只要雙方采用一致的加密算法就可以調(diào)用接口，保證了接口調(diào)用的安全性，比如常見的md5；
文檔維護：文檔在維護的時候，如有修改一定要寫上修改日期，修改人，對大的修改要有版本號變更；
其他相關知識？
get請求，post請求的區(qū)別：
1、GET使用URL或Cookie傳參。而POST將數(shù)據(jù)放在BODY中。
2、GET的URL會有長度上的限制，則POST的數(shù)據(jù)則可以非常大。
3、POST比GET安全，因為數(shù)據(jù)在地址欄上不可見。
4、一般get請求用來獲取數(shù)據(jù)，post請求用來發(fā)送數(shù)據(jù)。
其實上面這幾點，只有最后一點說的是比較靠譜的，第一點post請求也可以把數(shù)據(jù)放到url里面，get請求其實也沒長度限制，post請求看起來參數(shù)是隱式的，稍微安全那么一些些，但是那只是對于小白用戶來說的，就算post請求，你通過抓包也是可以抓到參數(shù)的。（唯一區(qū)別就是這一點，上面3點區(qū)別都是不準確的）
http狀態(tài)碼：
1、200 2開頭的都表示這個請求發(fā)送成功，最常見的就是200，就代表這個請求是ok的，服務器也返回了。
2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了。
3、400 400代表客戶端發(fā)送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404代表沒有這個頁面。
4、500 5開頭的代表服務器有異常，500代表服務器內(nèi)部異常，504代表服務器端超時，沒返回結果。
webservice接口怎么測試：
它不需要你在拼報文了，會給一個webservice的地址，或者wsdl文件，直接在soapui導入，就可以看到這個webservice里面的所有接口，也有報文，直接填入?yún)?shù)調(diào)用，看返回結果就可以了。
天氣預報wsdl地址：http://www.webservicex.net/globalweather.asmx?wsdl
cookie與session的區(qū)別：
1、cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上。
2、cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙
考慮到安全應當使用session。
3、session會在一定時間內(nèi)保存在服務器上。當訪問增多，會比較占用你服務器的性能
考慮到減輕服務器性能方面，應當使用cookie。
4、單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、所以個人建議：
將登陸信息等重要信息存放為session
其他信息如果需要保留，可以放在cookie中
————————————————
版權聲明：本文為CSDN博主「剽悍六杯茶」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/nikita1995/article/details/82494416
