接口方面

一、 接口測試

1、接口的理解

一般在企業中接觸的接口測試有前後端進行數據傳輸的內部接口，和跨平臺跨系統連接外部接口的測試。
跨平臺跨系統的接口測試，比如說第三方支付接口。
接口可以理解爲數據傳遞的通道，可能只是服務端底層的一個函數，接口參數一般是指函數的參數，接口的返回數據是函數的返回值。

2、爲什麼要做接口測試

接口測試的開展有比較多的因素，目前接口測試的開展，大部分是由於前後端分離這種開發流程決定的。

當開發一個產品的時候，分爲前端和後端，在編碼過程中，會出現前端和後端進度不對等的情況，比如前端開發頁面還沒有完成的時候，後端就已經開發完成了，通過接口測試可以更好的發現問題，否則，一個底層的問題，會在做功能測試的時候引發多個功能性的問題。這種進度時開展接口測試，可以發現底層代碼的錯誤，減少在功能測試時時間的消耗。

還有一個主要的原因，就是技術的不斷髮展，現在企業的平臺越來越複雜，系統也越來越龐大，多系統間交互開發不斷，傳統的測試方法測試成本急劇增加，鑑於對系統的安全性、穩定性而言，接口測試在檢查系統的異常處理能力方面起着決定性的作用，且接口測試有利於在自動化及持續集成這兩方面建立一個完整的測試體系。

3、接口測試的步驟

• 1、拿到接口需求，分析需求
• 2、依據接口需求去設計接口用例，
• 3、選擇接口測試的工具，比如postman或jmeter來執行測試，也可以通過直接寫代碼的方式來執行測試用例
• 4、在測試過程中，需同步關注數據庫的數據準確性，若遇到bug，就提交給開發，進行bug的跟蹤和處理

4、接口測試用例

接口測試用例的編寫，思路和功能測試用例的編寫是一樣的：

• 首先需要考慮接口正常調用：
  就是輸入正常的參數值，檢查結果返回的響應結果和接口文檔給定的是否一致；還需要考慮數據庫的增刪改差是否正確。
• 接着是考慮接口的異常驗證：
  依據限制約束，需要去考慮包括長度、類型、必填等異常場景；同步的話需要考慮一下邊界值
• 另外需要考慮業務規則驗證：
  接口的安全性驗證，比如說鑑權
• 最後需要考慮接口的性能：
  這一點需要考慮系統有沒有需求要做這個。

5、定位前後端bug

可以通過fiddler和其他抓包工具來抓取請求信息來進行分析

fiddler沒有設置過過濾器的情況下：

• 沒有抓到請求信息，可能是前端頁面元素沒有綁定事件，也有可能是前端發生了js錯誤，這就是前端的bug；
• 若抓到的請求返回的結果錯誤，需確認前端傳輸的數據是否錯誤的，
  若前端傳輸的數據錯誤，那就是前端的bug，
  若前端傳輸的值是正確的，那就是後端的bug。
• 若抓取的請求返回值中間的http的狀態碼是500的話，說明是後端服務器的內部錯誤，不過一般情況下都不會讓500的錯誤顯示到前端，會通過nginx反向代理將服務器錯誤顯示爲404。
  若抓取的請求返回值得http狀態碼是404的話，說明後端服務器沒有對應地址的服務，也有可能是前端js提交請求的時候提交了錯誤的地址。

二、抓包

1、爲什麼要抓包

在程序運行的時候，數據都是以數據包的形式進行傳輸，在發送和接受數據的過程中，發出的數據可能是錯誤的，也可能接受的包中有錯誤的數據，從而導致程序處理出錯。因此我們直接抓取傳輸的數據包，通過其他的工具或者方法解析數據包裝的原始數據，可以定位出來，是否因爲數據出錯而導致程序的出錯，如果是因爲數據出錯，可以定位是哪一部分的數據出錯，等等。

2、抓包工具

2.1、抓包使用的工具

• HTTP、HTTPS 協議，使用fiddler、charles進行抓包
  一些簡單的接口測試，比如使用json形式進行前後端交互的數據，也可以直接在瀏覽器的控制檯查看
• TCP、UDP 協議，使用wireshark進行抓包
  這類抓包其實也是很看經驗的，比如一個視頻流，出現了花屏，wireshark一抓一存是對的，而原因可能是開發人員沒處理好udp亂序問題，但如果沒看源碼的話就只能看時間戳和序號，這種測試起來就很煩躁

2.2、wireshark的使用場景

wireshark工具主要是用於測試過程中遇到的一些網絡問題，以及要去分析一些網絡協議的時候會用到。

比如說在測試過程中發現某個web頁面突然間沒法訪問了，就可以通過wireshark上的抓包，來分析一下是客戶端的問題還是服務器的問題，並且可以確認是連接過程中哪個階段出現了問題。
拿HTTP協議來說，就可以通過抓包來分析，是在TCP三次握手過程中出現了問題，還是說在完成三次握手之後，http進行數據傳輸的時候出現了問題；並且可以看出是客戶端主動斷開的連接，還是被服務器reset重置了連接。這些都是可以通過wireshark上的抓包分析得出來的。