【任务描述】：企业网站内容管理系统的文章新增功能测试脚本设计完之后，如何实现性能测试需求分析中的测试场景呢，以及测试完成后如何分析测试结果？ 

【任务目标】：通过完成企业网站内容管理系统的文章新增功能性能测试，掌握JMeter性能测试工具的场景设计、测试执行和结果分析。 

【任务储备】：

1、场景

场景是用来尽量真实地模拟用户操作的工作单元，场景设计源自于用户真实操作，JMeter的场景设计主要通过线程组设置来完成。JMeter线程组实际上是建立一个线程池，JMeter根据用户的设置进行线程池的初始化，一个线程对应一个模拟用户，在运行时做各种运行逻辑处理，线程组的配置界面如下图所示。

重要的配置信息如下所示：

v 在取样器错误后要执行的动作：其中的某一个请求出错后的异常处理方式：

    ü 继续：请求（Sampler元件模拟的用户请求）出错后继续运行。在大量用户并发时，服务器偶尔响应错误是正常现象，比如服务器由于性能问题不能正常响应或者响应慢，此时需要将错误记录下来，作为有性能问题的依据。

    ü 启动下一进程循环：如果出错，则同一脚本中的余下请求将不再执行，直接重新开始执行。

    ü 停止线程：如果遇到请求（Sampler元件模拟的请求）失败，则停止当前线程，不再执行。比如配置50个线程，如果其中某一个线程中的某一个请求失败了，则停止当前线程，那么就只剩下49个线程在运行，如果失败的事务增多，那么停下来的线程也会增多，运行状态的线程就会越来越少，最后负载不够（对服务器的压力不够，测试结果不具参考性），所以一般不会这样设置。

    ü 停止测试：如果某一个线程的某一个请求失败了，则停止所有线程，也就是停下整个测试。但是每个线程还是会执行完当前迭代后再停止。

    ü 立即停止测试：如果有线程的请求失败了，那么马上停止整个测试场景。

v 线程数：运行的线程数设置，一个线程对应一个模拟用户。

v Ramp-Up时间（秒）：线程启动开始运行的时间间隔，单位是秒，即所有线程在多长时间内开始运行。比如设置线程数为50，此处设置10 s，那么每秒就会启动50/10，5个线程。如果设置为0 s，则开启场景后50个线程立刻启动。

v 循环次数：请求的重复次数。选择“永远”复选框，那么请求将一直运行，除非停止或崩溃，或者时间已经超过设置的持续时间；如果不选择“永远”复选框，而在输入框中输入数字，那么请求将重复指定的次数，如果输入1，那么请求将执行一次。

v same user on each interation：选择每次运行是是否使用同一个用户，若勾选则表示每次循环都是同一个用户，若不勾选则表示每次循环都是新的用户。

v 延迟创建线程直到需要：若勾选，线程在Ramp-Up时间（秒）的间隔时间启动并运行。比如50个线程10s的Ramp-Up时间（秒），那么间隔1 s启动5个线程并运行后面的取样器。不勾选，测试计划开始后启动所有线程，但不立即运行取样器。

v 调度器：勾选“调度器”复选框后，可以编辑持续时间和启动延迟时间。

    ü 持续时间（秒）：测试计划持续多长时间，和循环次数配合使用，必须勾选“永远”复选框。

    ü 启动延迟（秒）：单击“执行”按钮后，仅初始化场景，不运行线程，等待延迟到时后才开始运行线程。

2、场景运行

JMeter场景的运行方式可以通过GUI（图形界面）运行和命令行运行；运行架构可以在本地一台Jmeter机器运行，所有的请求通过该机器发送，也可以远程运行，用一台Jmeter控制机控制远程的多台机器来产生负载。GUI运行运行方式一般用于脚本调试，命令行运行方式一般用于实际的性能测试。JMeter命令行工具常用的参数说明如下所示：

v -n：非GUI方式运行。

v -t：指定运行的测试脚本地址与名称(后缀为.jmx文件)，可以是相对或绝对路径。

v -h：查看帮助。

v -l：记录测试结果到文件(后缀为.jtl)，指定名称与路径，可以是相对或绝对路径。

v -r：开启远程负载机，远程负载机列表在jmeter.properties文件中指定。

v -R：开启远程负载机，可以指定负载机IP，会覆盖jmeter.properties中的设置。

v -X：停止远程执行。

v -J：定义Jmeter属性，等同于在jmeter.properties中设置(参考下方命令行运行实战的第6个命令详解)。

v -G：定义Jmeter全局属性，等同于在Global.properties中设置,线程间可相互共享。

v -e：在脚本运行结束后生成html报告。

v -o：保存html报告的地址。

v -g：指定已存在的测试结果文件。

3、运行结果分析

JMeter使用非GUI模式运行的结果可以存在jtl文件中，可以生成HTML报告，jtl文件文件可以用excel打开，里面记录了每个线程的详细日志；HTML报告主要分为两个部分：Dashboard与charts。Dashboard显示本次测试的基本测试信息，包括测试报告基本信息、应用程序性能指数表、请求摘要图、统计信息和请求异常信息五部分。

（1）Dashboard组成部分

1）测试报告基本信息显示了测试的开始时间和测试时间等信息

2）应用程序性能指数表（APDEX），计算每个事务的基于容忍和满足阈值的可配置值，范围在 0-1 之间，1表示达到所有用户均满意。

3）请求摘要图（Requests Summary），显示成功和失败请求（不考虑事务控制器样本结果）百分比

4）统计信息（Statistics），提供每个事务的所有指标的摘要，表头信息从左往右分别为：请求名称、请求数目、失败请求数目、错误率(本次测试中出现错误的请求的数量/请求的总数)、平均响应时间、最大响应时间、中间响应时间、90%用户响应时间、95%用户响应时间、99%用户响应时间、吞吐量(吞吐量——默认情况下表示每秒完成的请求数Request per Second，当使用了事务控制器时，可以在列表中找到对应事务的请求数，则其含义为Transaction per Second 数)、Kb/sec(网络吞吐量，表示每秒从服务器端接收到的数据量)。

5）请求异常信息（Errors），所有错误及其在总请求中所占比例的摘要

（2）charts

Charts包含了Over time（运行时间相关图表）、Througput（吞吐量相关图表）、Response time（响应时间相关图表）三类图表，具体如下图所示。

 

1）Over time（运行时间相关图表）,包含Response Time Over Time（响应时间时序图）、Response Time Percentiles Over Time (successful responses)（90%、95%、99%等线程在各个时间段的响应时间，跟聚合报告里面的90、95、99%差不多）、Active Threads Over Time（活跃线程时序图，线程多的时候看比较有意义）、Bytes Throughout Over Time（吞吐量时序图）、Latencies Over Time（请求延迟时序图）、Connect Time Over Time（连接时长时序图）等图表。

2）Througput（吞吐量相关图表），包含Hits Per Second(每秒点击率)、Codes Per Second（每秒状态码数量）、Transactions per second（每秒事务量）、Total Transations Per Second（每秒总事务量）、Response Time Vs Request（响应时间点请求的成功/失败数）、Latency Vs Request: 延迟时间点请求的成功/失败数等图表。

3）Response time（响应时间相关图表）,包含Response Time Percentiles(响应时间百分比)、Active Threads Over Time(活跃线程数时序图)、Time Vs Threads(测试过程中的线程数时续图)、Response Time Distribution(响应时间分布)等图表。

【任务实施】

1、将企业网站内容管理系统的文章新增功能测试脚本设计如下场景：60个线程在10s内启动，持续运行300s。

2、以非GUI模式运行文章新增功能测试脚本，测试数据保存到text.jtl，HTML报告保存到result文件夹中。

3、分析HTML报告，获取响应时间、TPS、事务失败率、并发用户数等性能指标。 

完整操作视频如下所示。