接口功能测试策略
由于平台服务器是通过接口来与客户端交互数据提供各种服务，因此服务器测试工作首先需要进行的是接口测试工作。测试人员需要通过服务器接口功能测试来确保接口功能实现正确，那么其他测试人员进行客户端与服务器结合的系统测试过程中，就能够排除由于服务器接口缺陷所导致的客户端问题，便于开发人员定位问题。以下便是个人的平台服务器接口功能测试经验总结:
一、接口测试范围
根据服务器的测试需求，接口测试范围主要分为：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。接下来的工作就是如何通过测试工具来执行服务器接口功能测试。
