【jmeter】jmeter接口测试

注:

1)复杂的测试案例都是在这个简单的测试案例上进行扩展

2）一个子系统建议放在同一个测试计划中，流程测试可以通过线程组区分，便于设定不同的测试数据个数。比较独立的接口，可以统一放在线程组内，顺序完成测试。

3）流程性接口测试：如果要测试的接口可以组成一个流程，执行顺序添加多个http请求的sampler，各请求之间可以提取需要在上下文传递的数据作为参数，以保证流程中数据的一致性。

1. 开发接口测试案例的整体方案：

第一步：分析出测试需求，拿到开发提供的接口说明文档；

第二步：从接口说明文档中设计接口测试用例，包括详细的入参、出参数据，以及明确的格式和检查点。

第三步：和开发一起评审接口测试用例

第四步：结合开发库，准备接口测试案例中的入参数据和出参数据，并整理成csv格式的文件。

第五步：结合接口测试用例和csv格式的数据文档，做接口自动化开发。

2. 接口自动化适用场景

   1）测试开发接口用例，开发自测

   2）回归测试：开发自测通过后纳入回归测试中，配置到持续集成平台自动运行。

3. jMeter工具设计之初是用于性能测试的，它在实现对接口的调用方面已经做的比较成熟，本次使用jMeter工具实现http接口的测试。

1）打开jMeter：下载好jMeter后，双击bin目录下的jmeter.bat

2、线程组（TestPlan->Add->Threads(Users)->Thread Group）：

1）Number of Threads(users)：线程数。即虚拟用户数，一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。

2）Ramp-Up Period(in seconds)：准备时长。设置的虚拟用户数需要多长时间全部启动。如果线程数为20 ，准备时长为10 ，那么需要10秒钟启动20个线程。也就是每秒钟启动2个线程。

3）Loop Count：循环次数。每个线程发送请求的次数。如果线程数为20 ，循环次数为100 ，那么每个线程发送100次请求。总请求数为20*100=2000 。如果勾选了“永远”，那么所有线程会一直发送请求，一直到选择停止运行脚本。

3、取样器（Thread Group->Add->Sampler）
对于jmeter而言，sampler取样器是与服务器交互的单元，一个取样器通常进行三部分的工作：1）向服务器发送请求。2）记录服务器的响应数据。3）记录响应时间信息。

1）http request

-1）Name：名称。标识一个取样器，一般建议适用有意义的名字，如接口名称。
-2）Comments：注释。仅用户记录注释信息。
-3）Protocol[http]：协议。向目标服务器发送的HTTP请求时的协议，可以是http（默认）或https 。
-4）Server Name or IP：服务器名称或ip。http请求发送的目标服务器名称或ip地址，可-）以取用户定义的变量$(host) 。
-5）Port Number：端口。目标服务器端口号，可以取用户定义的变量$(port) 。
-6）Method：方法。发送http请求的方法，包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
-7）Path：路径。目标URL路径（不含服务器地址和端口）。
-8）Content encoding：内容编码方式。默认iso8859，可以设置为UTF-8 。

3）添加http cookie管理器（线程组右键-添加-配置元件）：

4）添加HTTP请求默认值（线程组右键-添加-配置元件）：当被测系统有唯一的访问域名和端口时，此组件很好用；填写被测系统的域名和端口，以及具体的协议类型。线程组里面的所有sampler的http request可默认此设置。

6）添加响应断言（被测http request右键-添加-断言）：设置检查点，添加对响应结果的正则表达式判断即可。

7）添加监听器（线程组右键-添加-监听器）：常用图形结果、查看结果树、聚合报告，方便查看运行后的结果。

查看结果树：可以定义返回结果的排版，如果JSON格式。

查看聚合报告：

Label：显示jMeter的每个element（如，http request）都有一个Name属性

#Samples：表示这次测试中一共发出了多少请求，如模拟10个用户，每个用户循环10次，这里就显示100

Average：平均响应时间–默认情况下是单个request的平均响应时间，当使用了Transaction controller时也可以以Transaction为单位显示平均响应时间。

Median：中位数，也就是50%用户的响应时间

90% Line：90%用户的响应时间。

注：关于90%和50%的并发用户数的含义，见：
LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。

为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？

假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？

假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

为了解答上面的疑问，我们先来看一张表：

在上面这个表中包含了几个不同的列，其含义如下：

CmdID 测试时被请求的页面

NUM 响应成功的请求数量

MEAN 所有成功的请求的响应时间的平均值

STD DEV 标准差（这个值的作用将在下一篇文章中重点介绍）

MIN 响应时间的最小值

50 th(60/70/80/90/95 th) 如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th 也是同样的含义

MAX 响应时间的最大值

我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下：

1.  90％用户响应时间在 LoadRunner中是可以设置的，你可以改为80％或95％；
   

2.  对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况；
   

3.  从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的；
   

4.  你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；
   

5.  如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；
   

6.  在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；
   

7.  上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无论是使用LoadRunner还是JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。
   

事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。

Min：最小响应时间

Max：最大响应时间

Error%：本次测试出现的错误的请求数量/请求的总数

Throughtput：吞吐量—默认情况下表示每秒的请求数（Request per second），当使用了Transaction Controller时，可以表示类似Loadrunner的Transaction per second数。

KB/Sec：每秒从服务器接收到的数据量，相当于Loadrunner中的Throughtput/Sec

8）添加用户定义的变量（测试计划右键-添加-配置元件）

可以添加测试服务器的IP地址${}_P(host,\mathrm{192.168.1.12})和端口${_P(port,8080)}