Jmeter接口测试Word下载.docx
《Jmeter接口测试Word下载.docx》由会员分享，可在线阅读，更多相关《Jmeter接口测试Word下载.docx（19页珍藏版）》请在冰豆网上搜索。
1.3为什么要做接口测试
早起的系统业务逻辑相对简单，基本的功能测试、性能测试、GUI自动化测试已经足以覆盖项目的需求。
而随着产品功能越来越多，系统架构越来越复杂，一些预想不到的Bug出现在我们面前，怎么办呢？
这时候急需要一种更有效的测试方法来适应当前的变化，来持续的保证我们产品的质量，因此接口测试的出现就是为了解决该问题。
从回归测试来说：
系统Ａ改了一个接口，相关联系统Ｂ的开发人员并不知道（当然系统Ａ的开发人员也不知道他会影响到Ｂ），导致Ａ发布后，Ｂ出错，Ｂ的用户开始抱怨。
此时如果有那么接口测试在持续集成运行的话，当Ｂ测试出错，Ｂ的开发一下就能发现，也就能立即改掉。
另一方面，在测试原则中有这么一条：
尽早的和不断的进行测试。
阐述的是尽早的持续的测试过程，当进行接口测试时，发现的问题一般都与业务相关，此类Bug造成的危害比UI上发现的问题更为严重，因此有利于Bug的早起修复。
1.4接口测试分类
接口测试分为模块接口测试和Web接口测试。
模块接口测试需要对代码有一定的掌握能力，可以划分到白盒测试中；
而Web接口测试分为服务器接口测试和外部接口测试。
服务器接口测试：
是测试浏览器与服务器的接口。
这个很容易理解，我们知道web开发一般分前端和后端，前端开发人员用HTML/CSS/JavaScript等技术。
后端开发人用PHP/JAVA/Python/Ruby等各种语言。
用户输入的数据是输入到的前端页面上，怎样把这些数据传递的后台的呢？
通过HTTP协议的GET与POST请求来实现前后端的数据传递。
这也可认为是接口测试，调用的登录接口还是查询接口，传参的是用户密码还是搜索关键字。
外部接口测试：
这个很典型的例子就是第三方登录，比如你做的新系统免于新用户重新注册的麻烦会提供第三方登录，那用户在登录的时候调用的就是第三方登录的接口，由第三方验证用户名和密码并且返回给当前系统。
1.5接口测试目的及方式
核心：
保证系统接口的功能正常
方式：
持续集成
目的：
提高测试效率，保证数据的准确性
文档：
接口测试对接口定义文档要求很高，所有的接口数据类型及业务分支导致的报文返回结构是需要事先定义好的，所以要形成文档的习惯，以方便查阅，尽量减少团队与团队间的沟通成本。
同样我们在接口测试中，也需要根据文档，整理出我们的接口测试数据及接口测试案例，有效的生成相关测试报告，方便其它人去审核、分析接口测试的成果。
2．接口测试用例设计
2.1测试用例设计流程
首先，明确出发点。
和所有的测试一样，接口测试出发点是你要证明所测的程序是错误的。
以这个出发点为导向，你的设计行为就会尽量朝这个方向发展，更易发现问题，不会出现大方向的偏差。
其次，选择好测试对象。
对于一个系统做接口测试选择好的测试对象是接口测试关键。
一个系统有无数的接口，每个接口如果分别测试，那将是很痛苦的一件事情，不光繁琐浪费，而且任何一个内部接口的变动，都将导致我们用例的不可用。
这里推荐把整个系统作为一个整体，选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象，以此为测试对象的用例将有很好的健壮性，并且更高效。
另外，根据数据的流向，又可将这些最外层的接口分为两类：
一类是数据进入系统的接口；
一类是数据流出系统的接口。
进入系统的接口实际是我们用例的执行调用的接口。
可通过变化参数对这些接口进行调用，模拟外部的使用；
而流出的接口则是我们用例真正该验证的点。
数据从哪里流出，流出时的状态如何，此时系统又是什么状态都是我们所应该验证的。
然后，确认完整的测试对象的功能：
确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。
此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。
最后当出发点、对象、功能都确定了，就可以真正设计用例了。
2.2测试用例设计原则
通常，设计接口测试用例需要考虑以下几个方面：
l是否满足前提条件。
有些接口需要满足前置条件，才可以成功获取数据。
l是否携带默认参数值。
带默认值的参数都不填写，必填参数都填写正确，其他不填写。
l业务规则、功能需求。
根据实际的业务规则和需求进行用例设计。
l参数是否必填。
异常情况，参数为空的测试。
l 参数之间是否存在关联。
若参数之间存在约束关系，则要设计相关用例进行测试。
l 参数数据类型限制。
参数值限制了数据类型，则输入非该类型进行测试。
l 参数数据类型自身的数据范围值限制。
根据边界范围设计边界值进行测试。
2.3测试用例设计举例
获取订单列表接口。
获取店铺指定期间的订单列表---多种条件组合，默认根据日期进行倒序排列。
消息请求:
字段列表如下：
字段名
数据类型
默认值
必填项
备注
shopid
Int
是
商铺编号
token
String
条件
设备令牌,Token鉴权方式必填
dateType
1
否
订单查询时间字段
1：
下单时间：
order_time
2：
订单完成时间：
order_finish_time
3：
结算时间：
shop_settle_time
startDate
Date
查询日期
endDate
查询结束日期
orderStatus
订单状态，不填表示所有状态
多个状态之间用英文逗号分割
0：
已预订；
已开单；
派送中；
已完成（原已结账）；
4：
退单中；
5：
已退单；
8：
自助下单；
9：
待确认
orderTransactionType
订单交易状态，不填表示所有
未完成；
已完成
payType
支付方式，不填表示所有
现金；
POS；
线上
cashierId
收银员
billerId
int
导购员
pNo
页码，从第一页开始，默认为1
pSize
10
每页记录数，默认为10
消息请求样例：
?
shopId=222222&
token=123456&
queryDate=2015-10-10
消息响应：
字段元素如下：
orderTotalPriceTotal
double
实际金额合计
platformTotalIncomePriceTotal
平台服务费合计
cashPayTotal
现金支付
posPayTotal
pos支付
onLinePayTotal
线上支付
lst
object
明细列表
部分测试用例如下：
以上测试用例可根据实际情况进行精简
3．接口测试工具
3.1接口测试工具介绍
接口测试常用的工具包括发包工具和抓包工具。
发包工具：
商业工具：
LoadRunner、Soapui；
开源工具：
Jmeter、Httpclient、python中的urllib2,urllib库。
抓包工具：
HTTP抓包工具：
HTTPAnalyzer、HTTPwatch、Fiddler、Firebug；
通用抓包工具：
Wireshark。
商业工具特点：
良好的图形操作界面，良好的技术支持，良好的脚本驱动模式，良好的结果报告，对测试人员的代码能力要求稍低等等，但其缺点也很明显：
贵、工具不开源、无法了解问题的本质。
开源工具的特点：
大量的资料可以查阅（因为用的人多，社区有大量的人一起贡献），有源码可以查阅，可以根据自已的业务特点进行定制化。
缺点就是对测试人员的代码能力有一定的要求，框架需要从零开始搭建。
3.2Jmeter介绍
Jmeter是一款优秀的开源的性能测试工具，然而它不单单可以用在项目的性能测试，同时可以用它来对Web进行接口测试。
下面介绍下在接口测试过程中用到的几个模块
3.2.1测试计划
首先打开Jmeter，在菜单左侧出现了“测试计划”。
在这里测试计划我们可以把它理解成新建的空白项目，在这个空白项目下面可以添加一系列的接口。
3.2.2线程组
添加方法：
测试计划--右键--Threads--线程组。
引用性能测试中的描述：
这个就是我们通常添加运行的线程。
通俗的讲一个线程组,，可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。
线程组中包含的线程数量在测试执行过程中是不会发生改变的。
在接口测试中我们可以把它看成一个接口或者一个业务流程组合而成的多个接口集、或者若干个不相干的接口。
在线程组中可以设置线程数和循环次数等。
3.2.3HTTP请求默认值
线程组-->
右键添加-->
配置元件-->
HTTP请求默认值。
HTTP请求默认值是为了方便填写后续内容而设置。
此处填写域名后，后续的HTTP请求中就不用填写地址前缀了。
HTTP请求默认值元件并不告诉JMeter来发送HTTP请求，它仅仅定义这个HTTP请求所用的默认值。
3.2.4HTTPCookie管理器
可以像浏览器一样存储和发送cookie，如果你要发送一个带cookie的http请求，cookiemanager会自动存储该请求的cookies，并且后面如果发送同源站点的http请求时，都可以用这个cookies。
3.2.5HTTP请求
Sampler-->
HTTP请求。
核心内容为HTTP请求部分，包括接口路径和参数，要注意的是如果参数里面用到了其他接口的返回值，这时候需要在BodyData中进行参数化。
3.2.6响应断言
添
升级会员 