簡述:喜歡的話麻煩大家點點關注,若沒人支持文章將沒有繼續往下寫的動力,從此大量博主會不願意再寫博客,導致行業資料大牛經驗無法流出。並不是說只針對我,大家看到任何一遍文章都是如此,喜歡就隨手點贊發表評論下自己的想法,如果感覺博主符合自己學習的類型也可以關注已便有新資料可以及時得知。謝謝!
接口測試概述:
在軟件進行測試時,爲了驗證軟件對外的接口服務是否可以正常提供服務及軟件在不同場景中執行路徑的安全性和可操作性,需要對接口進行測試。
接口測試(interface testing)的目的是測試與系統相關聯的外部接口,測試的重點是檢查數據的交互,傳遞和控制管理過程,提供測試質量和測試覆蓋,更好地重新軟件缺陷和定位錯誤。
接口測試主要考慮的問題是模塊接口和系統接口。
1.模塊接口的測試
模塊接口測試主要包括以下內容:
- 各個模塊連接集成起來的時候,穿越模塊接口的數據會不會丟失。
- 各個子功能組合起來,能否達到預期要求。
- 一個模塊的功能是否對另外一個模塊的功能產生不利的影響。
- 全局數據結構是否有問題。
- 模塊的積累誤差是否達到了不可介紹的程度。
- 系統環境的測試。
2.系統接口的測試
系統接口的測試主要包括以下內容:
- 服務器接口的測試。包括服務器與交換機接口,以及服務器與磁盤陣列的接口。重點測試在線的狀態,測試當服務器發送故障時,交換機或者磁盤陣列能否與備用服務器連接上。
- 交換機接口的測試,包括交換機與防火牆接口、交換機與磁盤陣列的接口,以及交換機與路由器接口的測試。
- 路由器與調制解調器的接口測試,包括路由器與單個調制解調器的接口,以及交換機與多個調制解調器的接口。
- 調制解調器與通信平臺接口的測試,包括調制解調器與通信平臺的DDN接口,調制解調器與通信平臺的ISDN接口, 調制解調器與通信平臺的X.25接口,以及調制解調器與通信平臺的FR(幀中繼)接口。
接口測試的內容:
接口測試主要包括兩項內容:
1.接口邏輯測試
接口邏輯測試是指根據業務邏輯、輸入參數、輸出值的描述,對正常輸入情況下所得的輸出值是否正確的測試,也就是測試對外提供的接口服務是否正常工作。
2.模塊接口測試
模塊接口測試是爲了保證數據的安全及程序在異常情況下的邏輯的正確性而進行的測試。
模塊接口測試的主要包括以下四個方面:
- 空值(Null)輸入,檢查模塊接口對空值(Null)的反應能力。
- 參數屬性的測試,輸入一個未賦值的參數會出現的情況。
- 異常的測試,製造一些異常的測試場景,測試異常描述是否清晰。
- 參數的個數設計與模塊接口參數的個數不一致時,檢查模塊接口的反應能力。包括以下兩種情況:
- 模塊接口參數的個數不一致(或多於原設計的參數個數,或少於原設計的參數個數);
- 模塊接口參數的類型不一致(字符型和數值型混用)
接口測試的測試項目:
接口測試的測試項目主要包括以下幾點:
- 數據類型問題,包括:
- 變量的數據類型是否錯誤。
- 是否存在不同數據類型的賦值。
- 是否存在不同數據類型的比較。
- 變量值問,包括:
- 變量的初始化或缺省值收到有錯誤。
- 變量是否發生上溢或下溢。
- 變量的精度是否足夠。
- 邏輯判斷問題,包括:
- 是否由於精度原因導致比較無效。
- 表達式中的優先級是否有誤。
- 邏輯判斷結果是否顛倒。
- 文件I/O問題,包括:
- 對不存在的或者錯誤的文件是否進行操作。
- 文件是否不以正確的方式打開。
- 文件結束判斷是否正確。
- 是否正確地關閉了文件。
Web的接口測試:
Web的接口測試主要討論:服務器接口和外部接口。
服務器接口測試
服務器接口測試是測試瀏覽器與服務器的接口。測試人員提交事務,然後查看服務器的記錄,並驗證在瀏覽器上所看到是操作是否正好是服務器發送的操作。
外部接口測試
有些web系統有外部接口,測試的時候要使用web接口發送一些事務數據,分別有效信用卡、無效信用卡和被盜信用卡進行驗證。
Web應用服務器還包括以下其他的測試:
- 實時通信服務器測試。
- 郵件服務器測試。
- 羣件服務器測試
- 文件/打印服務器。
接口測試策略:
由於平臺服務器是通過接口來與客戶端交互數據提供各種服務,因此服務器測試工作首先需要進行的是接口測試工作。測試人員需要通過服務器接口功能測試來確保接口功能實現正確,那麼其他測試人員進行客戶端與服務器結合的系統測試過程中,就能夠排除由於服務器接口缺陷所導致的客戶端問題,便於開發人員定位問題。以下便是個人的平臺服務器接口功能測試經驗總結:
一、接口測試範圍
根據服務器的測試需求,接口測試範圍主要分爲:1、新增接口的測試;2、新增業務功能接口測試;3、整個服務器的接口測試。所需測試測試接口依次增多,在測試時間足夠的條件下,當然需要對所有接口進行測試用例的設計,但如果測試較短的情況下,則應該首先根據用戶的典型操作對測試接口進行優先級劃分,對調用頻繁接口需要優先進行測試。
二、接口測試策略
在進行平臺服務器接口測試之前,首先需要整理服務器接口的測試方案,分析接口測試的要點,平臺服務器的接口測試內容主要有:
接口設計檢查
接口用於服務器與客戶端的數據交互,客戶端通過網絡協議傳遞的數據爲服務器接口的輸入數據,因此應該首先通過服務器接口文檔及客戶端數據約束文檔進行交互數據的有效性檢查:
n 整數型數據位數
n 浮點型數據精度
n 字符串數據範圍值
要求客戶端的整數型、浮點型、字符串數據以及其最大值和最小值都能作爲服務器接口的有效輸入。這些工作在服務器設計評審時就可以進行,以便確保不會出現客戶端上傳數據被服務器自動進行截斷或四捨五入的操作。
接口依賴關係檢查
以上策略只談到單個接口的測試方法,對於用戶來說,一個操作可能會造成服務器調用多個接口來進行完成,因此還需要從業務處理的角度,對各種業務操作所涉及的多個接口之間依賴調用進行測試。
接口依賴關係檢查主要是通過接口的輸出值爲另一接口的輸入值來實現的,因此在進行接口測試之前,需要分析所測試接口的輸入值是通過客戶端還是其他接口輸出來獲取的,在設計測試用例時,加入接口的依賴關係說明以便於測試。
接口輸入/輸出驗證
服務器接口功能測試類似於單元測試,在設計測試用例時,側重點在於接口模塊輸入/輸出項的正確性驗證,根據接服務器接口處理方式,對各種接口進行分類:
第一類:條件判斷接口
這類接口在接收到請求數據後,會根據輸入參數進行條件判斷,然後返回相應結果碼,通常涉及條件判斷的接口有:用戶鑑權接口、升級狀態上報、密碼修改/重置等接口。因此輸入/輸出項驗證的側重點主要集中在:
1)判斷條件的驗證
要對判斷條件進行驗證,則需要知道接口是根據哪些輸入項來進行判斷的,以密碼重置接口爲例:
密碼重置接口
『接口功能』:用戶登錄之後發起找回密碼操作,用戶輸入郵箱信息後,遊戲中心將向平臺服務器發送請求,平臺服務器將隨機爲用戶生成新的密碼,發到用戶的郵箱中。
『接口方向』:遊戲中心—>平臺服務器
『遵循協議』:HTTPS,請求消息使用Post方式
參數名稱 |
參數類型 |
參數長度 |
說明 |
userID |
Int |
10 |
用戶ID號 |
|
String |
60 |
郵箱地址 |
key |
String |
50 |
接口名稱 |
version |
String |
8 |
版本號 |
響應消息(sendMessageRes)
參數名稱 |
參數類型 |
參數長度 |
說明 |
resultCode |
Int |
5 |
結果返回碼,返回42000表示處理成功 |
此接口根據輸入的userID、email參數來進行數據正確性的判斷(key是接口名稱,如果錯誤服務器將不會處理,version是版本號,其值只是用於記錄,不參與判斷),設計接口測試用例時,應該首先對接口的判斷參數進行驗證,這些輸入項不能爲空,然後利用等價類劃分、邊界值方法來根據userID、email輸入項設計各種合法的數據,驗證接口是否可以正常處理。
2)異常數據的響應
只考慮正常情況,而不考慮異常場景是無法保證接口功能運行正常,對於密碼重置接口,用戶ID不存在、不合法,郵箱輸入格式錯誤、用戶郵箱信息不存在或未激活就是測試時需要考慮的異常場景,設計這類輸入值,並且檢查接口返回的響應碼,響應碼的正確才能保證客戶端根據異常情況來顯示相應的提示信息。簡而言之,條件判斷的接口其測試策略就是根據判斷條件來設計各種輸入值來檢驗接口的功能。
第二類:數據查詢接口
這類接口接收到請求數據後,首先會驗證請求是否合法,然後會根據請求項查詢數據庫相應表中數據返回給客戶端,通常涉及數據查詢的接口有:用戶基本資料/經驗值/賽事信息查詢、遊戲列表獲取、在線人數查詢等接口。以用戶經驗值查詢接口爲例:
用戶經驗值查詢接口
『接口功能』:用戶登錄遊戲中心後,可以查詢自己每個遊戲項目的經驗值信息,包括此項目的經驗值等級、等級稱號、今日經驗值上限等。
『接口方向』:遊戲中心—>平臺服務器
『遵循協議』:HTTP+XML,請求消息使用Post方式
參數名稱 |
參數類型 |
參數長度 |
說明 |
userID |
Int |
10 |
用戶ID號 |
webkey |
String |
60 |
當前分配給指定登錄用戶的密鑰 |
key |
String |
50 |
接口名稱 |
version |
String |
8 |
版本號 |
isAll |
Int |
1 |
是否查詢用戶所有的運動項目經驗值 0:是;1否 |
sportItemID |
String |
50 |
運動項目ID,當isAll=1時不能爲空,指定查詢某個運動項目的經驗 |
響應消息(sendMessageRes)
參數名稱 |
參數類型 |
參數長度 |
說明 |
sportItemID |
String |
50 |
運動項目ID |
sumExp |
Int |
11 |
運動經驗值總額 |
expLevel |
Int |
3 |
經驗值等級 |
minExp |
Int |
11 |
本級最小經驗值 |
expOrder |
Int |
11 |
經驗值排名 |
maxExp |
Int |
11 |
本級最大經驗值 |
todayExp |
Int |
11 |
今日獲得經驗值 |
todayExpLimit |
Int |
11 |
今日經驗值上限 |
designation |
String |
30 |
稱號(對應於經驗值) |
winCount |
Int |
11 |
勝利場次 |
lossCount |
Int |
11 |
失敗場次 |
isMaxExp |
Int |
1 |
總經驗值是否達到最大 0 否;1 是 |
此接口首先會根據webkey來判斷請求是否合法,然後根據請求參數中的userID、isAll、sportItemID來查詢數據表中相應數據。除了象條件判斷接口一樣根據判斷項webkey、請求參數userID、isAll、sportItemID設計合法/不合法和正常/異常測試值之外,還需要結合數據庫來對查詢結果進行驗證:
1)是否根據正確的關聯數據表進行查詢;
2)驗證查詢結果是否從數據表中正確項中獲取,涉及到多表聯合查詢時,不同表中的相同項設計不同測試數據進行驗證;
3)修改查詢結果在數據表中對應項中的數據,使其爲空值或客戶端相應項的範圍值的最大和最小值,查看接口輸出是否正確。
第三類:邏輯運算接口
這類接口在收到請求數據之後,會進行一系列邏輯運算,然後根據處理結果更新數據庫中的數據,通常涉及邏輯運算的接口有:比賽成績同步、商品支付、各種數據報表等接口。以比賽成績同步接口爲例:
比賽成績同步接口
『接口功能』:遊戲服務器將用戶每次的比賽成績傳給平臺服務器,平臺服務器根據用戶的比賽成績更新此用戶的賽事排名,然後存入數據庫。
『接口方向』:遊戲服務器—>平臺服務器
『遵循協議』:HTTPS+XML,請求消息使用Post方式
參數名稱 |
參數類型 |
參數長度 |
說明 |
userID |
Int |
10 |
用戶i-dong號 |
webKey |
String |
64 |
當前分配給指定登錄用戶的密鑰 |
key |
String |
50 |
接口名稱 |
version |
String |
8 |
版本號 |
gymkanaCode |
String |
30 |
當前比賽所參與的運動會,該參數爲空說明只是普通用戶的比賽 |
sportItemID |
String |
50 |
遊戲項目的ID |
sportItemName |
String |
50 |
遊戲項目名稱 |
sportServerID |
String |
50 |
遊戲服務器IP |
matchSystem |
Int |
3 |
競速跑賽制: 100米:1; 400米:2; 800米:4; 1500米:8; 4×100米:16; |
matchId |
String |
50 |
該場次比賽唯一id |
record |
double |
|
當前用戶成績 (如record=8.123456)。非正常結束比賽時,即isWinner=3或4,如果是單人跑,isWinner=5,record=-1 |
unit |
String |
20 |
成績單位 |
isWinner |
Int |
2 |
當前用戶是否贏了0=輸,1=贏,2=未完成,3=主動退出,4=被迫退出 |
competitorID |
Int |
10 |
對手idong號 |
competitorRecord |
double |
|
當前對手成績,規則同record |
competitorIsWinner |
int |
2 |
對手輸贏,規則同isWinner |
starttime |
String |
14 |
開始時間(yyyy-MM-dd HH:mm:ss) |
endtime |
String |
14 |
結束時間(yyyy-MM-dd HH:mm:ss) |
響應消息(sendMessageRes)
參數名稱 |
參數類型 |
參數長度 |
說明 |
resultCode |
Int |
5 |
結果返回碼,返回42000表示處理成功 |
score |
Int |
11 |
本次得分 |
preRank |
Int |
11 |
賽前積分在賽後的排名 |
rank |
Int |
11 |
積分排名 |
upRankFlag |
Int |
1 |
排名上升:1;排名不變:0;排名下降:-1 |
isUpLevel |
Int |
1 |
經驗值是否升級 0 否;1 是 |
exp |
Int |
11 |
本次增加的經驗值 |
expLevel |
Int |
3 |
經驗值等級 |
designation |
String |
30 |
稱號(對應於經驗值) |
cPreRank |
Int |
11 |
對手賽前積分在賽後的排名 |
cRank |
Int |
11 |
對手賽後積分排名 |
cUpRankFlag |
Int |
1 |
對手排名上升:1;排名不變:0;排名下降:-1 |
encourageWord |
String |
15 |
鼓勵語句 |
此接口比數據查詢接口又更加複雜,除了用條件判斷和數據查詢類接口的策略對此接口進行測試用例設計之外,還需要驗證對接口的算法規則進行檢查,因爲此接口涉及根據用戶比賽成績(record)進行排名然後返回其得分及排名情況(score、rank、upRankFlag、exp),通過對相關數據表中的數據進行查看方式,接口算法規則驗證包括:
1)用戶勝利、失敗、中途主動/被動退出、規定時間內未完成比賽情況下,此場比賽得分(scroe)是否正確;
2)用戶比賽成績比上次成績花費時間短、長、持平情況下,排名情況(upRankFlag)是否正確;
3)用戶比賽成績處於第一名、最後一名、比上次成績花費時間短/長/持平情況下,用戶積分排名(rank)是否正確;
4)用戶勝利、失敗、中途主動/被動退出、規定時間內未完成比賽,並且用戶經驗值在各種經驗等級範圍下,經驗值根據得分進行計算的公式是否正確。
邏輯運算接口由於還涉及插入或更新數據庫操作,因此測試時還需要考慮數據庫特性,如數據精度問題,在MySQL數據庫中,如果是浮點型數據,存入時會有精度誤差(131072.32插入float(10,2)類型的數據會變爲131072.31),因此對於需要用於金額計算、數據統計、成績比較的數據,最好使用定點型。
最後服務器接口的測試如果有足夠條件的話,還需要通過白盒測試來對接口代碼做進一步的測試,通過編寫關鍵代碼的測試樁,可以有效查找將字符數組當成字符串使用造成的讀越界這類不易通過黑盒測試發現的BUG。接下來的工作就是如何通過測試工具來執行服務器接口功能測試。