一、接口測試範圍
二、接口測試政策
在進行平台伺服器接口測試之前,首先需要整理伺服器接口的測試方案,分析接口測試的要點,平台伺服器的接口測試内容主要有:
接口設計檢查
接口用于伺服器與用戶端的資料互動,用戶端通過網絡協定傳遞的資料為伺服器接口的輸入資料,是以應該首先通過伺服器接口文檔及用戶端資料限制文檔進行互動資料的有效性檢查:
● 整數型資料位數
● 浮點型資料精度
● 字元串資料範圍值
要求用戶端的整數型、浮點型、字元串資料以及其最大值和最小值都能作為伺服器接口的有效輸入。這些工作在伺服器設計評審時就可以進行,以便確定不會出現用戶端上傳資料被伺服器自動進行截斷或四舍五入的操作。
接口依賴關系檢查
以上政策隻談到單個接口的測試方法,對于使用者來說,一個操作可能會造成伺服器調用多個接口來進行完成,是以還需要從業務處理的角度,對各種業務操作所涉及的多個接口之間依賴調用進行測試。
接口依賴關系檢查主要是通過接口的輸出值為另一接口的輸入值來實作的,是以在進行接口測試之前,需要分析所測試接口的輸入值是通過用戶端還是其他接口輸出來擷取的,在設計測試用例時,加入接口的依賴關系說明以便于測試。
接口輸入/輸出驗證
第一類:條件判斷接口
這類接口在接收到請求資料後,會根據輸入參數進行條件判斷,然後傳回相應結果碼,通常涉及條件判斷的接口有:使用者鑒權接口、更新狀态上報、密碼修改/重置等接口。是以輸入/輸出項驗證的側重點主要集中在:
1)判斷條件的驗證
要對判斷條件進行驗證,則需要知道接口是根據哪些輸入項來進行判斷的,以密碼重置接口為例:
密碼重置接口
『接口功能』:使用者登入之後發起找回密碼操作,使用者輸入郵箱資訊後,遊戲中心将向平台伺服器發送請求,平台伺服器将随機為使用者生成新的密碼,發到使用者的郵箱中。
『接口方向』:遊戲中心—>平台伺服器
『遵循協定』:https,請求消息使用post方式
參數名稱
參數類型
參數長度
說明
userid
int
10
使用者id号
string
60
郵箱位址
key
50
接口名稱
version
8
版本号
響應消息(sendmessageres)
resultcode
5
結果傳回碼,傳回42000表示處理成功
此接口根據輸入的userid、email參數來進行資料正确性的判斷(key是接口名稱,如果錯誤伺服器将不會處理,version是版本号,其值隻是用于記錄,不參與判斷),設計接口測試用例時,應該首先對接口的判斷參數進行驗證,這些輸入項不能為空,然後利用等價類劃分、邊界值方法來根據userid、email輸入項設計各種合法的資料,驗證接口是否可以正常處理。
2)異常資料的響應
隻考慮正常情況,而不考慮異常場景是無法保證接口功能運作正常,對于密碼重置接口,使用者id不存在、不合法,郵箱輸入格式錯誤、使用者郵箱資訊不存在或未激活就是測試時需要考慮的異常場景,設計這類輸入值,并且檢查接口傳回的響應碼,響應碼的正确才能保證用戶端根據異常情況來顯示相應的提示資訊。簡而言之,條件判斷的接口其測試政策就是根據判斷條件來設計各種輸入值來檢驗接口的功能。
第二類:資料查詢接口
這類接口接收到請求資料後,首先會驗證請求是否合法,然後會根據請求項查詢資料庫相應表中資料傳回給用戶端,通常涉及資料查詢的接口有:使用者基本資料/經驗值/賽事資訊查詢、遊戲清單擷取、線上人數查詢等接口。以使用者經驗值查詢接口為例:
使用者經驗值查詢接口
『接口功能』:使用者登入遊戲中心後,可以查詢自己每個遊戲項目的經驗值資訊,包括此項目的經驗值等級、等級稱号、今日經驗值上限等。
『遵循協定』:http+xml,請求消息使用post方式
webkey
目前配置設定給指定登入使用者的密鑰
isall
1
是否查詢使用者所有的運動項目經驗值 0:是;1否
sportitemid
運動項目id,當isall=1時不能為空,指定查詢某個運動項目的經驗
響應消息(sendmessageres)
運動項目id
sumexp
11
運動經驗值總額
explevel
3
經驗值等級
minexp
本級最小經驗值
exporder
經驗值排名
maxexp
本級最大經驗值
todayexp
今日獲得經驗值
todayexplimit
今日經驗值上限
designation
30
稱号(對應于經驗值)
wincount
勝利場次
losscount
失敗場次
ismaxexp
總經驗值是否達到最大 0 否;1 是
此接口首先會根據webkey來判斷請求是否合法,然後根據請求參數中的userid、isall、sportitemid來查詢資料表中相應資料。除了象條件判斷接口一樣根據判斷項webkey、請求參數userid、isall、sportitemid設計合法/不合法和正常/異常測試值之外,還需要結合資料庫來對查詢結果進行驗證:
1)是否根據正确的關聯資料表進行查詢;
2)驗證查詢結果是否從資料表中正确項中擷取,涉及到多表聯合查詢時,不同表中的相同項設計不同測試資料進行驗證;
3)修改查詢結果在資料表中對應項中的資料,使其為空值或用戶端相應項的範圍值的最大和最小值,檢視接口輸出是否正确。
第三類:邏輯運算接口
這類接口在收到請求資料之後,會進行一系列邏輯運算,然後根據處理結果更新資料庫中的資料,通常涉及邏輯運算的接口有:比賽成績同步、商品支付、各種資料報表等接口。以比賽成績同步接口為例:
比賽成績同步接口
『接口功能』:遊戲伺服器将使用者每次的比賽成績傳給平台伺服器,平台伺服器根據使用者的比賽成績更新此使用者的賽事排名,然後存入資料庫。
『接口方向』:遊戲伺服器—>平台伺服器
『遵循協定』:https+xml,請求消息使用post方式
使用者i-dong号
64
gymkanacode
目前比賽所參與的運動會,該參數為空說明隻是普通使用者的比賽
遊戲項目的id
sportitemname
遊戲項目名稱
sportserverid
遊戲伺服器ip
matchsystem
競速跑賽制:
100米:1; 400米:2; 800米:4; 1500米:8; 4×100米:16;
matchid
該場次比賽唯一id
record
double
目前使用者成績 (如record=8.123456)。非正常結束比賽時,即iswinner=3或4,如果是單人跑,iswinner=5,record=-1
unit
20
成績機關
iswinner
2
目前使用者是否赢了0=輸,1=赢,2=未完成,3=主動退出,4=被迫退出
competitorid
對手idong号
competitorrecord
目前對手成績,規則同record
competitoriswinner
對手輸赢,規則同iswinner
starttime
14
開始時間(yyyy-mm-dd hh:mm:ss)
endtime
結束時間(yyyy-mm-dd hh:mm:ss)
score
本次得分
prerank
賽前積分在賽後的排名
rank
積分排名
uprankflag
排名上升:1;排名不變:0;排名下降:-1
isuplevel
經驗值是否更新 0 否;1 是
exp
本次增加的經驗值
cprerank
對手賽前積分在賽後的排名
crank
對手賽後積分排名
cuprankflag
對手排名上升:1;排名不變:0;排名下降:-1
encourageword
15
鼓勵語句
此接口比資料查詢接口又更加複雜,除了用條件判斷和資料查詢類接口的政策對此接口進行測試用例設計之外,還需要驗證對接口的算法規則進行檢查,因為此接口涉及根據使用者比賽成績(record)進行排名然後傳回其得分及排名情況(score、rank、uprankflag、exp),通過對相關資料表中的資料進行檢視方式,接口算法規則驗證包括:
1)使用者勝利、失敗、中途主動/被動退出、規定時間内未完成比賽情況下,此場比賽得分(scroe)是否正确;
2)使用者比賽成績比上次成績花費時間短、長、持平情況下,排名情況(uprankflag)是否正确;
3)使用者比賽成績處于第一名、最後一名、比上次成績花費時間短/長/持平情況下,使用者積分排名(rank)是否正确;
4)使用者勝利、失敗、中途主動/被動退出、規定時間内未完成比賽,并且使用者經驗值在各種經驗等級範圍下,經驗值根據得分進行計算的公式是否正确。
邏輯運算接口由于還涉及插入或更新資料庫操作,是以測試時還需要考慮資料庫特性,如資料精度問題,在mysql資料庫中,如果是浮點型資料,存入時會有精度誤差(131072.32插入float(10,2)類型的資料會變為131072.31),是以對于需要用于金額計算、資料統計、成績比較的資料,最好使用定點型。
最後伺服器接口的測試如果有足夠條件的話,還需要通過白盒測試來對接口代碼做進一步的測試,通過編寫關鍵代碼的測試樁,可以有效查找将字元數組當成字元串使用造成的讀越界這類不易通過黑盒測試發現的bug。接下來的工作就是如何通過測試工具來執行伺服器接口功能測試。
本文出自seven的測試人生公衆号最新内容請見作者的github頁:http://qaseven.github.io/