接口測試標準及規(guī)范
1.后端服務(wù)產(chǎn)品接口測試說明
后端服務(wù)性產(chǎn)品基本上都是以API的形式對外提供服務(wù)，所以其最重要的一個測試類型就是接口測試。
對測試人員的要求
接口測試要求有較好的編碼水平，測試代碼才能更簡潔、高效。接口測試既要求對系統(tǒng)的整體架構(gòu)有足夠的了解，又要求對用戶場景熟悉，兩者相輔相承。要求從白盒角度了解系統(tǒng)設(shè)計，從黑盒角度設(shè)計測試場景，注重兩者之間的權(quán)衡。
2接口測試的優(yōu)缺點
對于后臺產(chǎn)品，接口測試作為最重要的一個測試類型，基本上是必由之路。所以，這里無需探討要不要引入接口測試的問題，而是直接探討接口測試的優(yōu)缺點即可。
2.1接口測試優(yōu)勢
后臺基礎(chǔ)服務(wù)的架構(gòu)往往很復(fù)雜，而接口測試可以讓測試人員集中精力關(guān)注系統(tǒng)對外交互的部分，因而能夠提供系統(tǒng)復(fù)雜度上升情況下的低成本高效率的解決方案。相比單元測試，接口測試是站在用戶的角度對系統(tǒng)接口進行全面高效持續(xù)的檢測。接口測試能高效完成手工測試比較難覆蓋的場景，比如上傳100個文件等。容易轉(zhuǎn)型到性能測試和穩(wěn)定性測試，因為性能測試是基于接口來進行場景設(shè)計的，所以接口測試人員做性能測試在技術(shù)層面是比較方便的。
2.2接口測試不足
接口測試運行速度相對于單元測試要慢得多
比如單元測試執(zhí)行時間控制在5分鐘之內(nèi)很容易
接口測試如果是針對復(fù)雜系統(tǒng)，全量測試往往要幾個小時。
所以在持續(xù)集成中，要注意權(quán)衡測試的覆蓋和執(zhí)行的速度之間的關(guān)系。
接口測試需要的測試環(huán)境比較復(fù)雜單元測試可以不依賴數(shù)據(jù)庫、文件系統(tǒng)等
接口測試需要的是一個完整的測試環(huán)境，并要求盡可能和產(chǎn)生環(huán)境一致，這對于復(fù)雜性來說，有時候一個獨立的測試環(huán)境是比較困難的。
如果要對系統(tǒng)進行mock，也不如單元測試那么方便。
接口測試的粒度較粗
以接口為最小的粒度，這樣的粒度相對單元測試就屬于粗粒度，容易造成一定的測試遺漏
需要測試和開發(fā)人員共同評審用例，必要時需要分析測試覆蓋情況來補充測試用例。
接口返回值做為校驗條件有風險
接口本身可能存在bug，在使用接口返回值做為校驗條件時有較高的風險，必須輔助其他的校驗方式，比如數(shù)據(jù)庫查詢、操作系統(tǒng)狀態(tài)等。
例1，測試RDS擴容接口時，接口返回了擴容成功，但是實際上從操作系統(tǒng)用df命令查看磁盤容量還是原來的大小。
例2，創(chuàng)建一個云主機的接口調(diào)用，接口返回成功后，還需要真的登錄到這臺機器上（通過ssh或者VNC），才能認為這臺主機創(chuàng)建成功了。
接口測試并不能全面保證產(chǎn)品質(zhì)量
接口測試的覆蓋范圍有限，需要結(jié)合單元測試，共同提高測試覆蓋率
接口測試不關(guān)注性能和穩(wěn)定性，在項目初期應(yīng)該考慮這方面的影響。
接口測試更多的關(guān)注正常邏輯和參數(shù)異常，對系統(tǒng)級異常需要更多的關(guān)注。
3．工具及測試形式
后臺項目接口一般分HTTP接口和Dubbo接口兩種，從接口測試的角度來看，兩者區(qū)別不大。測試用例書寫一般采用有如下方式：
直接采用程序編寫測試代碼（Java、Python等），并且基于已有的測試框架，比如TestNG和UnitTest。用工具錄制或者組裝接口請求（Jmeter、Postman等）。如果是HTTP請求，則采用requests；如果是dubbo接口，則直接調(diào)用Hessian。文件解析方式?jīng)]有采用上面接口方式，單獨設(shè)計框架進行解析處理。
4．接口測試用例設(shè)計方法
4.1場景覆蓋
場景覆蓋，是從用戶角度進行設(shè)計的測試覆蓋。主要是模擬用戶的業(yè)務(wù)操作，達到對用戶行為的覆蓋。場景覆蓋是后端基礎(chǔ)服務(wù)接口測試中最重要的覆蓋。
例如，用戶對云主機的使用，會涉及到創(chuàng)建云主機、創(chuàng)建用戶密鑰、修改安全組、通過SSH客戶端登陸到云主機、執(zhí)行用戶操作5個步驟。如果只是單純的接口測試，對后面兩個步驟容易忽略，雖然對系統(tǒng)來說資源可以分配成功，但是可能造成用戶無法登錄云主機，造成非常嚴重的影響。
4.1.1場景收集
需求文檔中定義的usecase，也可以適當?shù)难由旌蛿U展。接口使用方的使用場景，比如云主機提供給RDS的接口，RDS是如何調(diào)用的。每次云主機的接口修改，會不會影響到RDS的使用。
產(chǎn)品用戶的使用場景，比如云主機的用戶是運維人員，需要對運維人員的使用習慣，操作頻率做收集和整理，增加到測試場景中。
線上bug，針對線上bug要做專門的分析，是否需要增加到測試場景中。他途徑的用戶反饋，比如郵件列表、POPO群討論，反饋系統(tǒng)等。
4.1.2場景覆蓋
測試場景要覆蓋用戶的關(guān)鍵使用場景，在測試設(shè)計階段要需要讓用戶參與評審。
場景測試和參數(shù)測試允許有部分重疊。
場景測試優(yōu)先覆蓋正常路徑，其次是分支路徑以及異常路徑。
場景需要分組，比如分成冒煙測試、主干功能測試、異常測試、參數(shù)測試等不同的分組，根據(jù)需要選擇其中的部分進行評審、執(zhí)行。
測試場景保持獨立性和原子性，每個測試場景完成獨立的功能，不受其他操作的影響。
4.2接口參數(shù)覆蓋
接口測試是通過輸入使用參數(shù)組合，獲得服務(wù)器返回值，并根據(jù)預(yù)先設(shè)定的規(guī)則判斷是否符合預(yù)期值。所以接口測試中，參數(shù)的覆蓋非常重要。
比如，一個上傳文件到網(wǎng)盤的操作接口
uploadFile(Stringusername, String dir, String filename, int length, boolean isPublic)
參數(shù)的含義分別為：
username：用戶名，字符型，取值范圍：6---100字符。
dir：文件存放的目錄名，字符型，取值范圍：不限。
filename：上傳的文件名，字符型，取值范圍：1---255字符。
length：文件長度，整型，取值范圍：1---65535。
isPublic：是否公開顯示此文件，布爾型，取值為True/False。
FileInfo：返回上傳的文件描述信息。
參數(shù)類型
數(shù)值型：包括整型、浮點型，比如文件長度、距離、重量等。
字符型：英文、中文字符串，比如姓名、賬號等。
布爾型：True / False。
枚舉型：一組基本類型的列表，比如學歷=[qa:本科以下、本科、碩士、博士]。
組合類型：List、Map、json等。
單值覆蓋
隨機型：在指定范圍或指定長度內(nèi)任意取值，比如一個整數(shù)取值在0-65535、長度為10的字符串.
枚舉型：依次取每一個值，比如性別（男、女）、快遞地址的省、市、區(qū)。
邊界值：對取值范圍內(nèi)的最大、最小、最大+1、最小-1取值。
異常值：null、類型最大值和最小值、空字符。
默認值：對某些非必選參數(shù)，采用默認值。
非法值：類型不匹配、超出類型范圍、超出操作系統(tǒng)限制、系統(tǒng)關(guān)鍵字
參數(shù)組合覆蓋
參數(shù)組合：采用笛卡爾積的全組合策略。比如3個參數(shù)，每個參數(shù)有5種取值，組合起來就有5x5x5=125個測試用例，優(yōu)點是覆蓋全面，缺點是組合數(shù)量巨大，工作量大。
全對偶組合：保證每個參數(shù)和其他參數(shù)都有組合出現(xiàn)，即采用盡可能少的組合覆蓋盡可能對的參數(shù)。覆蓋性價比很高。比如上述的參數(shù)組合，大約只需25個用例即可覆蓋。
單點失效：單個參數(shù)使用非法或異常值，其他值保持正常取值。
多點失效：多個參數(shù)使用非法或異常值，其他采用正常取值。
5接口測試最佳實踐
5.1測試斷言的設(shè)計
測試斷言是自動化測試中的測試通過條件，用于判斷測試用例是否符合預(yù)期。斷言是單元測試xUnit框架的核心，最早是一般都通過Assert類的靜態(tài)方法提供。這里要講的斷言，是單元測試和接口測試中用到的，不是用在開發(fā)代碼中的。
斷言的形式
讓斷言去比較，輸入原始數(shù)據(jù)
assertEquals（expected,
actual, message）
自己做比較，輸入布爾表達式
assertTrue/assertFalse（boolean,
message）
斷言設(shè)計原則
形式保持統(tǒng)一
使用了assertTrue，就不要再使用assertFalse，保持一致性。
不要混用unittest和其他框架斷言。
使用明確的message
盡量選擇帶message參數(shù)的斷言方法
可以使斷言結(jié)果的可讀性更強。
使得測試代碼可讀性更強。
斷言不要放在公共方法中
公共方法只處理通用邏輯，不處理驗證邏輯。
斷言讓驗證只存在于業(yè)務(wù)邏輯代碼中。
不要使用恒對錯的斷言
比如assertTrue（true）類似這樣的斷言很可能讓你遺漏掉重要的斷言。期望返回異常
這種情況不使用raise，因為會拋出異常。
5.2接口測試分組策略
為什么分組
測試執(zhí)行失敗后可以迅速定位問題，并且重試執(zhí)行不會影響其他分組。提高持續(xù)集成反饋速度，對冒煙測試、回歸測試區(qū)分不同的分組，有的放矢。分組可以任意組合、排除，便于執(zhí)行不同的組合測試場景。
怎樣分組
根據(jù)測試粒度區(qū)分，冒煙測試、主干功能、全回歸測試。
根據(jù)功能模塊劃分，比如創(chuàng)建模塊、查詢模塊、清理模塊等。
根據(jù)功能是否正常：正常用例、異常用例。
5.3測試結(jié)果分析
測試結(jié)果
一般的測試框架，都會生成一份完整的測試結(jié)果報告。報告一般分為三個部分：
摘要信息
項目地址
測試環(huán)境
測試結(jié)果匯總
例執(zhí)行成功、失敗情況
用例執(zhí)行時間統(tǒng)計
用例的分組統(tǒng)計
測試結(jié)果詳情
每個用例的執(zhí)行詳情，包括方法名、請求參數(shù)列表
每個用例的執(zhí)行時間
測試結(jié)果分析
優(yōu)化執(zhí)行時間
如果某個分組、用例執(zhí)行時間過長，需要進行優(yōu)化調(diào)整。
及時處理失敗用例
對skip、failed用例，要及時處理，該修改的修改，該移除的移除，不要容忍失敗的用例存在于持續(xù)集成過程中。
