接口测试方法汇编.docx
《接口测试方法汇编.docx》由会员分享，可在线阅读，更多相关《接口测试方法汇编.docx（42页珍藏版）》请在冰豆网上搜索。
接口测试方法汇编
接口功能测试策略
分类：
java学习2012-04-1815:
301105人阅读评论（0）收藏举报
测试服务器数据库游戏平台网络协议
由于平台服务器是通过接口来与客户端交互数据提供各种服务，因此服务器测试工作首先需要进行的是接口测试工作。
测试人员需要通过服务器接口功能测试来确保接口功能实现正确，那么其他测试人员进行客户端与服务器结合的系统测试过程中，就能够排除由于服务器接口缺陷所导致的客户端问题，便于开发人员定位问题。
以下便是个人的平台服务器接口功能测试经验总结:
一、接口测试范围
根据服务器的测试需求，接口测试范围主要分为：
1、新增接口的测试；2、新增业务功能接口测试；3、整个服务器的接口测试。
所需测试测试接口依次增多，在测试时间足够的条件下，当然需要对所有接口进行测试用例的设计，但如果测试较短的情况下，则应该首先根据用户的典型操作对测试接口进行优先级划分，对调用频繁接口需要优先进行测试。
二、接口测试策略
在进行平台服务器接口测试之前，首先需要整理服务器接口的测试方案，分析接口测试的要点，平台服务器的接口测试内容主要有：
接口设计检查
接口用于服务器与客户端的数据交互，客户端通过网络协议传递的数据为服务器接口的输入数据，因此应该首先通过服务器接口文档及客户端数据约束文档进行交互数据的有效性检查：
n 整数型数据位数
n 浮点型数据精度
n 字符串数据范围值
要求客户端的整数型、浮点型、字符串数据以及其最大值和最小值都能作为服务器接口的有效输入。
这些工作在服务器设计评审时就可以进行，以便确保不会出现客户端上传数据被服务器自动进行截断或四舍五入的操作。
接口依赖关系检查
以上策略只谈到单个接口的测试方法，对于用户来说，一个操作可能会造成服务器调用多个接口来进行完成，因此还需要从业务处理的角度，对各种业务操作所涉及的多个接口之间依赖调用进行测试。
接口依赖关系检查主要是通过接口的输出值为另一接口的输入值来实现的，因此在进行接口测试之前，需要分析所测试接口的输入值是通过客户端还是其他接口输出来获取的，在设计测试用例时，加入接口的依赖关系说明以便于测试。
接口输入/输出验证
服务器接口功能测试类似于单元测试，在设计测试用例时，侧重点在于接口模块输入/输出项的正确性验证，根据接服务器接口处理方式，对各种接口进行分类：
第一类：
条件判断接口
这类接口在接收到请求数据后，会根据输入参数进行条件判断，然后返回相应结果码，通常涉及条件判断的接口有：
用户鉴权接口、升级状态上报、密码修改/重置等接口。
因此输入/输出项验证的侧重点主要集中在：
1）判断条件的验证
要对判断条件进行验证，则需要知道接口是根据哪些输入项来进行判断的，以密码重置接口为例：
密码重置接口
『接口功能』：
用户登录之后发起找回密码操作，用户输入邮箱信息后，游戏中心将向平台服务器发送请求，平台服务器将随机为用户生成新的密码，发到用户的邮箱中。
『接口方向』：
游戏中心—>平台服务器
『遵循协议』：
HTTPS，请求消息使用Post方式
参数名称
参数类型
参数长度
说明
userID
Int
10
用户ID号
email
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-ddHH:
mm:
ss）
endtime
String
14
结束时间（yyyy-MM-ddHH:
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。
接下来的工作就是如何通过测试工具来执行服务器接口功能测试。
编写接口测试的测试用例体会
分类：
测试用例2011-08-2319:
222680人阅读评论（0）收藏举报
测试数据库testing产品语言工作
来淘宝目前已经3周了，这三周只重复地做了一个事情，编写测试用例，修改测试用例。
不断地修改让我对自己的语言组织能力和逻辑思维能力产生了怀疑，同时，越来越觉得测试用例的写法扑朔迷离。
我问了3个人，结果每个人都告诉我不同的写法。
把我自己弄的不知所措。
但是问的多了，慢慢也就明白了，每个人都有每个人的编写风格，作为测试新人，我们要了解如何去编写测试用例，而不是copy别人的测试用例。
只有真正了解了如何去编写，才能写出有自己风格的测试用例。
测试用例基本上都包括以下五部分：
1.前置条件
2.输入参数
3.执行步骤
4.校验点
5.期望值
这这是书写用例的一种形式而已。
有些测试用例中，输入参数也可以省略掉。
重要的是设计测试用例、
刚接手工作还没有编写日常用例就跟进了一个项目，我负责的是实体管理和属性管理的增删改查，这样涉及到了页面。
我也最先接触到了功能测试和接口测试。
其实知道现在我还是没有完全区分开这两个测试。
我觉得在书写测试用例的时候两者是相似的。
只是功能测试一般是在页面上，接口测试则接触底层代码。
当然，在接口中我也按功能点书写了功能性的测试。
书写接口测试测试用例的考虑点：
1，充分滴熟悉PRD（产品需求设计）
了解PRD，熟悉业务规则，根据业务规则来确定测试点。
为了辅助理解产品的架构，可以画mm图，将需求分类。
在编写用例的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。
做到对需求的100%覆盖。
要明白哪些是核心功能！
2.以下转载自
（测试用例的有效性）测试用例应该包含清晰的输入数据以及预期输出，没有测试数据的用例更多的是具有指导意义，执行过程中更多的是靠个人根据指导的自由发挥。
但是看看我们的基线库更多的是这样指导意义的用例。
（但是输入数据又涉及到了维护的问题，以及环境或者业务发生变更后引起的有效性问题）。
对于预期的结果不能仅仅是页面上或者界面上的可见结果，如果和数据库发生了交互，必须包含数据库里准确的验证结果。
用例基于数据驱动。
（测试用例的可理解性）测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语，测试用例应该按照增删改的顺序进行安排，这样执行的时候效率比较高，避免不必要的重复测试，用例写完不是就ok了，我们最好通读2遍，进行修改，让单条用例流畅。
（测试用例的清晰性）测试用例的验证点必须明确清晰重点突出，按照最新的用例标准，一个用例进行一个功能点的验证，一个萝卜一个坑。
对于流程性的用例也是建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。
测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。
（测试用例的可维护性）我们的用例主要是基于web的，用例存在一定的变数。
因此在测试用例因为业务需求发生变更的时候，请及时修改，维护测试用例，做到测试用例的实时性与有效性，同时也方便后来的新人同学及时学习，不会产生误解与费解
【这里还应该有一个（测试用例的可重现性），这个在准备数据的时候要注意】
RossCollard在”UseCaseTesting”一文中说：
“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。
如果你在项目或者日常结束后，仔细的分析过我们的bug列表，那么你会觉的这句话非常适用。
合理提高我们的测试效率就是在编写测试用例时进行测试用例优先级的划分。
如何设计接口测试用例接口测试是项目测试的一部分，正如其名，它测试的主要对象是接口，是测试系统组件接口测试间接口的一种测试。
接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。
测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
如何设计接口测试用例测试用例？
测试用例首先，明确出发点。
和所有的测试一样，接口测试出发点是你要证明所测的程序是错误的。
以这个出发点为导向，你的设计行为就会尽量朝这个方向发展，更易发现问题，不会出现大方向的偏差。
其次，选择好测试对象。
对于一个系统做接口测试选择好的测试对象是接口测试关键。
一个系统有无数的接口，每个接口如果分别测试，那将是很痛苦的一件事情，不光繁琐浪费，而且任何一个内部接口的变动，都将导致我们用例的不可用。
这里推荐把整个系统作为一个整体，选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象，以此为测试对象的用例将有很好的健壮性，并且更高效。
另外，根据数据的流向，又可将这些最外层的接口分为两类：
一类是数据进入系统的接口；一类是数据流出系统的接口。
进入系统的接口实际是我们用例的执行调用的接口。
可通过变化参数对这些接口进行调用，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。
数据从哪里流出，流出时的状态如何，此时系统又是什么状态都是我们所应该验证的。
然后，确认完整的测试对象的功能：
确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。
此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。
最后当出发点、对象、功能都确定了，就可以真正设计用例了。
下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。
接口测试用例设计和其他其他测试用例设计一样，都应该本着尽可能的发现bug的目标。
用其他例设计的内容应该包括：
主要测试功能点、测试环境、测试数据测试数据、执行操作以及预期结果。
测试数据1）接口测试环境分为两种:
一种是程序内部的环境；一种是程序的所调用外部接口的环境。
用例在设计环境上有一个原则即：
设计真实而危险的环境，不忽视偶发环境。
真实，即你的用例在测试某种功能时，应该去思考这种情况发生时内部、外部环境是什么，通过各种手段将最准确的环境模拟出来。
危险，即在这种环境下系统出问题的概率会很大。
在设计用例环境时，如果两种环境都能达到你本用例的要求，更推荐选择更危险的环境。
所谓偶发，即这种环境出现的概率很小。
不要因为这种环境很少出现就无视它，开发很可能也是这种想法，此处很有可能隐藏着问题。
2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。
数据的设计学问大，
不要在设计、准备测试用例的数据上偷懒。
要通过好的测试数据使用例查错的功能充分发挥。
接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏了某些边界值和错误点的数据。
每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据，使用例更容易发现问题。
3）测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。
接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。
同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
4）接口测试用例执行操作非常简单，就是所测接口的调用。
5）预期结果验证，这也是接口用例设计的很关键的一步，应该细而不冗余。
所谓细，用例中应详细列出应该验证的点。
每个用例均需验证，不要因为前几个用例有验证就认为全部是正确的。
避免一个用例中重复做相同的验证，提高测试用例的效率。
关于接口测试的总结1.接口测试：
是测试系统组件间接口的一种测试。
主要用于检测外部系统于系统乊间以及系统内部各个子系统乊间的交互点。
重点测试的时数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等等，这要求对业务逻辑有一定程度上的理解，对数据流向有较好的定位。
2.接口测试的分类：
a）b）c）系统不系统乊间的调用（如分享时，微信会提供接口给“跑向珠峰”；）上层服务对下层服务的调用服务乊间的调用（如添加一条数据时，会先调用数据查询的服务，查询改数据是否是重复数据）；丌同类型的接口测试方法可能丌一致，但总体来说，丌管是哪种类型，被测接口即为服务方，测试手段为客户方，接口测试的目的就是：
通过我们的测试手段，去验证满足其声明提供的功能。
3.接口测试的原理：
通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程（request→response）4.接口测试的流程：
类似于功能测试，需求讨论→评审需求→确定需求→产出接口定义→根据需求文档及接口定义设计测试用例（测试用例主要从业务场景，功能以及异常测试几个方面考虑）→评审用例→执行测试5.接口测试的价值：
降低成本，提高效率。
接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。
它是一个完整的体系，还包括功能测试，性能测试等。
6.接口测试的适用范围：
一般用于多个系统间的交互开发，戒者拥有多个子系统的应用系统开发的测试。
接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统。
主要测试这些对外部提供的接口的正确性和稳定性。
它也同样适用于上层系统中服务层接口，测试难度随层级而上升。
即越往上难度越大。
7.需求的频繁变化，做接口测试的测试人员应该如何应对：
个人觉得此在于团队开发的流程，团队乊间的沟通和测试人员的警觉性。
、在开发阶段，需求的变更是一件极为频繁和正常的事情，对于此点团队中的任何一人都应该以正确的心态来面对。
团队需要规范的开发流程，良好的沟通方式，测试人员更需要及时跟迚软件迚度，和开发人员并迚齐行。
同时，测试不开发需要相对独立的工作环境，总结而言为乊知己知彼，亦敌亦友。
8.关于如何简单设计接口测试的设计用例a）明确出发点——测试的目的是为了让找出软件的缺口，修复并使乊更加完善。
在这一基础点上，接口测试也丌例外。
以找出软件的误漏为出发点，测试用例需紧贴此线，更容易找出问题所在。
b）明确测试点——选择好的测试对象。
系统内部层次繁复复杂，任何一个接口的变劢都将导致用例失效。
（可将这些最外层的接口根据数据的流向分为迚入和流出两类，迚入系统的接口实际上是我们用例的执行调用的接口。
可通过参数对这些接口迚行调用，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。
数据从哪里流出，流出的状态如何，此时系统的状态都是作为测试目的所要着重关注的部分）c）确认完整的测试对象的功能——确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要的时什么样的功能予以区别。
用例的设计要严格按照测试对象功能设计才是正确的用例。
9.设计（接口）测试用例有哪些要求：
结构好，可读性高，渗透性强。
10.（接口）测试用例包括的内容：
功能点，测试环境，测试数据，执行操作以及预期结果。
如下：
a）接口测试测试的功能点：
如果一个接
升级会员 