轉自：http://www.cnblogs.com/xunmi/archive/2011/10/17/2215374.html
由於平台服務器是通過接口來與客戶端交互數據提供各種服務，因此服務器測試工作首先需要進行的是接口測試工作。測試人員需要通過服務器接口功能測試來確保接口功能實現正確，那么其他測試人員進行客戶端與服務器結合的系統測試過程中，就能夠排除由於服務器接口缺陷所導致的客戶端問題，便於開發人員定位問題。以下便是個人的平台服務器接口功能測試經驗總結:
一、接口測試范圍
根據服務器的測試需求，接口測試范圍主要分為：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。接下來的工作就是如何通過測試工具來執行服務器接口功能測試。
樓主寫得非常好，不過本人認為，只要是接口測試就應該關注數據庫的數據，所以第一類接口測試應當加入數據庫里數據的校驗。比如修改/重置密碼后，要去看下數據庫的密碼是否是修改后的數據，而不是僅僅只憑返回碼來判斷接口是否正常。