介面測試簡介

1.什麼是介面

介面就是內部模組對模組，外部系統對其他服務提供的一種可呼叫或者連線的能力的標準，就好比usb介面，他是系統向外接提供的一種用於物理資料傳輸的一個介面，當然僅僅是一個介面是不能進行傳輸的，我們還的對這個介面怎麼進行傳輸進行進行一些設定和定義。開發所謂的介面是模組模組之間的一種連線，而測試眼中的介面是一種協議（對介面的功能的一種定義）

2.介面的種類和分類

外部介面，內部介面：上層服務於下層服務，同級服務。常見的介面分類http：get，post，delete，put
系統對外的介面：比如你要從別的網站或伺服器上獲取資源或資訊，別人肯定不會把資料庫共享給你，他只能給你提供一個他們寫好的方法來獲取資料，你引用他提供的介面就能使用他寫好的方法，從而達到資料共享的目的。
程式內部的介面：方法與方法之間，模組與模組之間的互動，程式內部丟擲的介面，比如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中的類物件等。）

3.各個介面之間的區別

通常我們測試的介面分為get介面和post介面，get的提交方式是明文提交，把提交的引數跟在url後面傳送給伺服器，所以不安全，而且get提交的引數是有字元限制的且可以被當做書籤儲存，但是post的提交方式跟get完全不一樣，post提交的引數是放在表單裡的，所以不會存在字元限制，而且因為引數是放在表單裡，不容易被看到，所以會比get更安全。

4.什麼是介面測試

簡單的來說介面測試對於測試來說其實是對介面協議的一種測試，這個協議指的是為了讓這個介面實現某種需要的功能還設計的一種要求。

5.為什麼要進行介面測試

因為不同端（前段，後端）的工作進度不一樣，所以我們要針對最開始出來的介面，以及需要呼叫其他公司的（銀行，支付寶，微信，qq等）一些介面進行介面測試及驗證資料，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易），需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證。前後端傳輸、日誌列印等資訊是否加密傳輸也是需要驗證的，特別是涉及到使用者的隱私資訊，如身份證，銀行卡等。

6.介面測試流程

需求討論，需求評審，場景設計，編寫用列，準備資料，執行測試

7.怎麼進行介面測試

通過工具模擬客戶端向服務端傳送請求並接受伺服器返回的資料來對介面的功能，邏輯業務，異常，安全進行測試

功能測試：測試這個介面的功能是否實現，並且測試這個介面是否按照介面文件來進行開發的（比如說介面文件規定了一些關鍵字，而開大的時候把關鍵字改成了其他的關鍵字，因為在整個專案週期，並不只有一個開發而是有多個，所以可能因為在開發過程中因為關鍵字不一樣導致某些開發的功能異常，還有自動化指令碼也會發生異常）

　　邏輯業務，主要指的是一些邏輯業務依賴關係（比如支付寶提交訂單的時候要保證你是在登入的情況下，如果你沒有登入而提交成功了，這就是異常，可以修改請求的cookie來測試）

　　異常測試：引數異常：關鍵字引數（應用其他的關鍵字替換進行測試）、引數為空、引數多少（通過新增引數增添個數），引數錯誤。資料異常：關鍵字資料（填入的資料用其他的資料語言的資料替用）、資料長度、資料為空、資料錯誤。
　　
　　由於我們專案前後端呼叫主要是基於http協議的介面，所以測試介面時主要是通過工具或程式碼模擬http請求的傳送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
　　–也可以用 介面自動化來實現，就是用程式碼實現，框架和UI自動化差不多，傳送請求用斷言來判斷。

8.介面測試需要用到的工具

　 介面測試常用的工具，fiddler抓取請求，postman模擬客戶端通過對fiddler抓取的請求修改併發送到服務端並接收伺服器返回的資料及異常來進行驗證介面。工具不是固定的，需要根據專案來進行選擇。

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

介面測試用例設計思路
目的：測試介面的正確性和穩定性；
　　原理：模擬客戶端向伺服器傳送請求報文，伺服器接收請求報文後對相應的報文做處理並向客戶端返回應答，客戶端接收應答的過程；
　　重點：檢查資料的交換，傳遞和控制管理過程，還包括處理的次數；
　　核心：持續整合是介面測試的核心；
　　優點：為高複雜性的平臺帶來高效的缺陷監測和質量監督能力，平臺越複雜，系統越龐大，介面測試的效果越明顯（提高測試效率，提升使用者體驗，降低研發成本）；
　　用例設計重點：通常情況下主要測試最外層的兩類介面:資料進入系統介面（呼叫外部系統的引數為本系統使用）和資料流出系統介面（驗證系統處理後的資料是否正常）；
　　PS：設計用例時還需要注意外部介面提供給使用這些介面的外部使用者什麼功能，外部使用者真正需要什麼功能；

1 輸入

　　輸入引數主要從以下幾各方面設計：

　　a 必填項校驗

　　介面文件中有是否必填的說明。參考介面文件即可。

　　b 引數長度校驗

　　參考介面文件即可。

　　c 引數值的有效性校驗

　　如：身份證號的校驗 ，設計的資料雖然符合身份證號的規則，但是並不是真實有效的身份證號；這種情況就要看身份證號的校驗規則是什麼樣了，一般都是用的現成的身份證號校驗器，但是有些是自己寫的校驗演算法，這個本人就遇到過這種問題—校驗演算法寫的不正確；

　　所以引數有效性的校驗就需要結合實際業務場景，判斷哪些資料是真實有效的資料，一定要確保所有真實有效的資料是可以驗證通過的。

　　d 引數組合校驗

　　不同的引數組合可能會存在不同的業務場景；

　　e 如果引數是列舉值，一定要各種列舉值都要測試，因為可能不同的列舉走的不同的業務流程；

　　f 引數值的預設值的校驗

　　參考介面文件。

　　g 某些引數具有特定的生成規則，要單獨針對生成規則設計用例，一定要保證真實有效的資料是可以驗證通過的。

　　如身份證號中間幾位 ***19860701*，本人就遇到過輸入***19861001*這種值校驗不正確；

2 介面邏輯

　　介面邏輯我用的設計方法是分支覆蓋—>路徑覆蓋—>場景覆蓋,同樣也是要結合實際業務場景，根本不發生的業務場景就是無效的測試用例。

　　a 第一步先把業務流程圖畫出來；

　　b 依據路程圖中的分支分別設計，不同分支不同的場景，這裡就要把異常的場景考慮進去；如介面超時，介面異常，介面請求成功或失敗，成功後怎麼處理，失敗後流程是否繼續執行，失敗後的資料怎麼處理；

　　以打款介面為例：

　　打款結果有打款成功或打款失敗，成功後怎麼處理，需要回寫打款成功狀態，失敗後怎麼處理，也需要回寫失敗狀態，失敗後的資料可以操作退回，也可以操作重新出款等等；

c 測試邏輯設計完成後要想一想不同的業務場景怎麼去測試，需要哪些人員協助，

如介面超時怎麼去測試，請求重複怎麼去測試，請求併發怎麼去測試

3 輸出

輸入結果：正常輸出和異常輸出，常用的方法有錯誤推斷法（列舉出程式中可能存在的錯誤或者異常，根據他們選擇測試用例）

4 以上都完成後，要結合實際的業務場景去掉冗餘的用例（即實際業務場景不存在的流程或者輸入資料）；

5 如果業務流程涉及到狀態轉換，要單獨設計使用者—方法：狀態轉換圖；

6 涉及到多個不同金額或者手續費的計算，可能還會用到正交實驗法去設計用例；

7 另外，用例設計中還應當包含異常流程中產生的異常資料的處理流程；—通常所說的補償機制，這塊流程能大大的減輕人工運營的工作量，當然，這需要在做系統設計的時候就需要把這部分考慮進去。

介面測試和app測試的相同和區別

1.兩者區別：App端效能主要關注與手機相關的特性，如手機cpu、記憶體、流量、fps等。而介面效能主要關注介面響應時間、併發、服務端資源的使用情況等。兩種測試時的策略和方法都有很大區別，所以這部分內容是需要分開單獨進行測試的，理論上來說這也是不同的部分。
2.介面測試持續整合：
　　對介面測試而言，持續整合自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實現了介面自動化，主要應用於迴歸階段，後續還需要加強自動化的程度，包括但不限於下面的內容：
　　　　a) 流程方面：在迴歸階段加強介面異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。
　　　　b) 結果展示：更加豐富的結果展示、趨勢分析，質量統計和分析等
　　　　c) 問題定位：報錯資訊、日誌更精準，方便問題復現與定位。
　　　　d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。
　　　　e) 程式碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高程式碼覆蓋率。
　　　　f) 效能需求：完善效能測試體系，通過自動化的手段監控介面效能指標是否正常。

最後ps：介面測試需要掌握的知識。
　　①瞭解系統及內部各個元件之間的業務邏輯互動；
　　②瞭解介面的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裡面的所有介面，也有報文，直接填入引數呼叫，看返回結果就可以了。
　　天氣預報wsdl地址：http://www.webservicex.net/globalweather.asmx?wsdl　　
　　cookie與session的區別：
　　1、cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上。
　　2、cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙
　　考慮到安全應當使用session。
　　3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能
　　考慮到減輕伺服器效能方面，應當使用cookie。
　　4、單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。
　　5、所以個人建議：
　　將登陸資訊等重要資訊存放為session
　　其他資訊如果需要保留，可以放在cookie中
————————————————
版權宣告：本文為CSDN博主「剽悍六杯茶」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/nikita1995/article/details/82494416