聲明：原文作者：Syw? ? 出處：http://www.cnblogs.com/syw20170419/?

業(yè)務穩(wěn)定為啥要測接口？

　　為了回歸。而且接口有個好處，定位問題簡單，一出問題基本都是服務端的問題，而且肯定是和這個接口相關的代碼，不用花時間再去抓包->分析（->撕逼）

對于page的接口測試，測試點如何設計？

　　第一頁、中間頁、最后一頁，那么如何獲取到的頁數就是最后一頁？讓開發(fā)協(xié)助寫獲取最后一頁的接口，測試來調用。

接口測試是否成功的校驗點是？

　?。?）從reponse中是否包含指定內容開始。

　?。?）擴展到數據庫的校驗

接口測試的用例驗證點（容錯性驗證）？

　　ADD/MOD（添加/修改）:

　?。?）字段邊界值，最大最小字符，為空以及格式校驗

　　（2）重復提交相同的參數

　?。?）權限校驗

　　（4）業(yè)務邏輯

　　DEL:（刪除）

　?。?）刪除不存在的

　?。?）刪除無權限刪除的

　　（3）刪除后再添加相同的

　?。?）重復刪除

　　LST:（列表）

　?。?）為空時獲取

　?。?）數量大時獲取

　　（3）分頁

　?。?）獲取無權限獲取的

接口測試的本質？

　　通過測試參數的排列組合驗證返回值/數據庫變更是否符合預期，從而確定接口相關代碼是否正確。

接口測試的優(yōu)點？

　?。?）簡單（對于開發(fā)基礎比較好的同學來說）

　?。?）穩(wěn)定（成功率高，很少出現ui自動化的各種狀況）

　?。?）效率（1個接口下的100條用例幾秒可執(zhí)行完成）

　?。?）可信（ui自動化測試報告天天執(zhí)行，一堆fail，由于各種環(huán)境問題、兼容等問題導致排查測試報錯的原因較麻煩）

　?。?）時間（用例編寫時間短，相對來說復用性高）

簡單的一個接口測試（用例編寫、開始執(zhí)行）的步驟？

　?。?）開始編寫前置條件、入參、返回參數、預期結果等測試相關的信息

　?。?）運用工具去執(zhí)行測試用例或者執(zhí)行自己寫的腳本

　?。?）校驗返回結果是否正確

接口測試是什么？

　　接口測試是功能測試不可或缺的一部分，拋開了前段的邏輯和限制對于服務器的功能進行了完整的測試，一個好的功能測試人員應該充分了解所測系統(tǒng)有多少個接口，接口的核心參數和響應，完成對接口代碼的走讀，接口有沒有白名單，防刷，內部接口和外部接口等。

接口測試的作用是什么？

　　從接口測發(fā)起的測試彌補了界面測試的遺漏點，能將接口測試納入功能測試的一部分，測試的完整性得到了很大的提高，界面測試起碼遺漏了如下的信息：

　　（1）服務器端接口參數校驗

　?。?）接口是否存在安全漏洞或者邏輯漏洞，實時性，防刷

　?。?）接口是否存在越權的可能

接口測試注意點？

　　【第一步：看】

　?。?）、看接口的請求參數構造是否合理

　?。?）、看所傳參數有無敏感參數需要加密傳輸。比如說用戶userid、password等數據如果不使用https進行通信，最好使用加密的方式進行傳輸，這也是業(yè)界通用的標準，并且入庫也需是加密的

　　（3）、看所測服務的代碼。第一看對于傳入參數的校驗部分，第二是看整體邏輯處理部分。舉個例子，大家在測試過程中經過會遇到如圖五所示，有多個必填或者選填項、輸入條件特別多、每個輸入條件都需要做校驗。有些測試人員會對此類問題用正交的方式一項一項測試，這類效率太慢。個人認為效率最高的方式為對于接口參數的校驗，以靜態(tài)測試為主，review代碼的過濾條件，頁面控件實際輸入測試為輔助。很多的輸入界面，其中判空處理是必須的。開發(fā)代碼中常用的一個判空函數是if（xxx.isempty（））。首先界面類查找是否有控件對象未使用該函數，若未使用肯定存在bug；其次即使使用這個函數也是有bug，該函數并未完全滿足需求。這個函數漏掉了輸入空格的情況,正確的做法是if（xxx.trimme().isempty（））。那么如果在全工程內，搜索isempty,對比發(fā)現bug，最后可以選擇一個輸入項進行測試，通過后所有輸入控間判空測試均告完畢。

　?。?）、看接口的返回體是否返回一些不必要的敏感信息，返回格式是否合理

　　【第二步：改】

　?。?）請求體中參數的常規(guī)修改。常規(guī)修改就是通用的邊界值方法，如極大值、極小值、極長值、null、空。未對這些值做校驗的后果可大可小。小的方面僅僅是服務器throw一個統(tǒng)一的錯誤提示，如網絡錯誤等。中等一點的為前端頁面會返回如圖六形式的內部錯誤，這種錯誤會泄露一些敏感信息。嚴重的后果可能就是影響現有或者后續(xù)業(yè)務，使得業(yè)務往不可控的方向進行。

　?。?）與業(yè)務強相關的參數修改。

　　（3）請求消息體中的字段修改。有些人習慣在cookie中傳輸大量的信息，也是值得關注的測試點。

接口測試的主要關注點？

　?。?）業(yè)務邏輯（業(yè)務邏輯覆蓋）

　?。?）響應結構

　　（3）數據格式

　?。?）數據正確性（依據來源：查數據庫與服務器和接口返回值比較）

測試的原則？

　?。?）基礎配置，如域名，環(huán)境配置等，單獨文件配置，方便不同環(huán)境測試，腳本維護

　?。?）明確接口實現什么樣的功能，實際需要什么樣的功能。是否一致

　?。?）接口測試數據太多，用數據驅動模式更有層次，且易維護

　　（4）要眾多用例中選出冒煙測試用例及可用于性能測試的用例

　?。?）先單接口測試，在多接口測試

　　（6）測試完成后，需要清理臟數據

為什么選擇JMeter做為接口測試的技術方案？

?? （1） 基于配置實現接口測試的自動化，免代碼開發(fā)

?? （2）豐富的斷言能力支持，返回值校驗，數據庫比對校驗

?? （3） 比較好的支持流程控制

?? （4） 比較完善的結果監(jiān)聽

?? （5）和Jenkins易于集成，集成后支持接口性能趨勢的查看能力

?? （6）非標準協(xié)議或者對接方有特殊安全處理的情況可以使用JavaSample的方式處理

接口測試的流程？

　　類似于功能測試，需求討論--評審需求—確定需求—產出接口定義—根據需求文檔及接口定義設計測試用例（測試用例主要從業(yè)務場景，功能以及異常測試幾個方面考慮）—評審用例—執(zhí)行測試

需求的頻繁變化，做接口測試的測試人員應該如何應對？

　　個人覺得此在于團隊開發(fā)的流程，團隊之間的溝通和測試人員的警覺性。

　　在開發(fā)階段，需求的變更是一件極為頻繁和正常的事情，對于此點團隊中的任何一個人都應該正確的心態(tài)來面對，團隊需要規(guī)范的開發(fā)流程，良好的溝通方式，測試人員更需要及時跟進軟件進度，和開發(fā)人員并進齊行，同時，測試與開發(fā)需要相對獨立的工作環(huán)境，總結而言為知己知彼，亦敵亦友。

接口測試的原理？

　　通過測試程序模擬客戶端向服務器發(fā)送請求報文，服務器接收請求報文后對相應的報文做出處理然后再把應答報文發(fā)送給客戶端，客戶端接收應答報文這一過程（request→response）

接口測試的范圍？

　　（1）、新增接口的測試；

　?。?）、新增業(yè)務功能接口測試；

　?。?）、整個服務器的接口測試，所需測試接口一次增多，在測試時間足夠的條件下，當然需要對所有接口進行測試用例的設計，如果測試較短的情況下，則應該首先根據用戶的典型操作對測試接口進行優(yōu)先級劃分，對調用平凡接口需要優(yōu)先進行測試。

?接口測試策略？

　?。?）、接口設計檢查（整數型數據位數、浮點型數據精度、字符串數據范圍值)

　?。?）、接口依賴關系檢查

　　（3）、接口輸入/ 輸出驗證

　　　　3.1 、條件判斷接口

　　　　　　 3.1.1、條件判斷的驗證：要對判斷條件進行驗證，則需要知道接口是根據哪些輸入項來進行判斷的

　　　　? ? ? ?3.1.2、異常數據的響應：對于密碼重置接口，用戶ID不存在、不合法，郵箱輸入格式錯誤、用戶郵箱信息不存在或未激活就是測試時需要考慮的異常場景，設計這類輸入值，并且檢查接口返回的響應碼，響應碼的正確才能保證客戶端根據異常情況來顯示相應的提示信息。

　　　　3.2、數據查詢接口

　　　　　　?除了像條件判斷接口之外根據請求參數設計合法/不合法/正常/異常測試值之外，還需要結合數據庫來對查詢結果進行驗證。

　　　　　　3.2.1、是否根據 正確的關聯數據表進行查詢

　　　　　　3.2.2、驗證查詢結果是否從數據表中正確項中獲取，涉及到多表聯合查詢時，不同表中的相同項設計不同測試數據來進行驗證。

　　　　　　3.2.3、修改查詢結果在數據表中對應項中的數據，使其為空值或客戶端相應項的范圍值的最大和最小值，查看接口輸出是否正確。

　　　　3.3、邏輯運算接口

后端接口都測試什么？

　　回答這個問題，我們可以從接口測試活動內容的角度下手，看一下面這張圖，基本反應了當前我們項目后端接口測試的主要內容：

后端接口測試一遍 ，前端也測試一遍，是不是重復測試了？

　　回答這個問題，我們可以直接對比接口測試和app端測試活動的內容，如下圖為app測試時需要覆蓋或考慮內容：

接口測試持續(xù)集成：

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

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

　　b) 結果展示：更加豐富的結果展示、趨勢分析，質量統(tǒng)計和分析等

　　c) 問題定位：報錯信息、日志更精準，方便問題復現與定位。

　　d) 結果校驗：加強自動化校驗能力，如數據庫信息校驗。

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

　　f) 性能需求：完善性能測試體系，通過自動化的手段監(jiān)控接口性能指標是否正常。

接口測試質量評估標準：

a) 業(yè)務功能覆蓋是否完整?

　　b) 業(yè)務規(guī)則覆蓋是否完整

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

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

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

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

　　g) 性能指標是否滿足要求

　　h) 安全指標是否滿足要求