性能测试计划书

在测试过程中我们如果编写一份性能测试计划书，需要一下几个背景板块及要点
性能测试的流程：
确认需求（确认正确的需求) —>编写测试方案（准备怎么动手）测试环节—>（尽量与生成配置一致）—>执行测试
分析测结果（重点）—>性能优化–>回归分析—>性能测试报告

性能测试的时机：
如果把系统比喻成一匹马，载人载货
目标：想要知道这匹马能载多少货物 ––负载测试 ，找到瓶颈值，上线前 知道容量（不断增加并发数，直到系统崩溃）
目标：想知道这匹马能带着货跑多远–– 压力测试 系统能否支撑长时间的高压运行（如一个接口的瓶颈值是300，并发的请求接口在250～299之间时，系统能运行多久）
出现问题，比如马受伤了，给马治病 ––性能优化 系统比较慢

测试背景：
1、项目概述：项目是什么？读书屋是一个提供小说阅读的系统，功能有。。。。
2、市场调研：市场上的竟品：七猫
3、开展性能测试原因：目的是为了面向社会推广、当前用户日益增加，需确认访问量，
4、意义；需要进行性能测试来评估 读书屋性能、分析性能变化趋势，分析系统瓶颈风险，帮助规划系统容量，为了硬件采购提供意见

测试范围：
无需一上来就测试系统的所有流程，而是需要分析哪些功能是高频使用的板块，将这些高频使用的板块接口进行性能优化
分析： 1、用户行为（剔除掉用户可能只反问一次的接口）先找到高频接口，开发才有可能做优化，高频接口意味着极有可能是当前项目的核心业务接口 2、产品经理的帮助 3、架构师、技术负责人––提供数据支持 4、强资源占用行为（上传/下载）一般情况下，
我们会按场景去测试对应的性能，比如：七猫小说网站，打开首页，登录、查看书架，这个流程有多少接口

性能需求分析：
预估：业务流程节点––数据流程「数据库表」每天会新增多少？
1、业务量：首页，日均UV（访问量）用户访问 独立访问的意思 ––5000用户
2、日均PV页面浏览量 ––50000浏览量
性能目标：
1、响应时间-可通过竞品对比或咨询产品设计评估响应时间为多少合适
2、后续会增长的目标量
3、从并发量设计，总访问数据 来推导并发量，通常遵循二八原则
4、可靠性/错误率分析：默认允许0.05%错误率容度度，但一般由公司决定
资源占用：
1、服务器资源 80～85%左右
2、太高，有崩溃的风险
3、太低，浪费资源

风险分析：
1、由于本次测试没有采用与生产环节相同配置，所以有可能和实际运行中性能有一定的差距
2、本次测试数据都是有人工生成，可能与实际数据分布有一定的差距

术语约定
并发量
负载测试：不断加大负载（不同虚拟的用户数）能找到拐点
压力测试

以上是一个性能测试计划书所要包含的板块。

测试实操：测试范围描述：七猫小说 登录 ––>查看书架

难点：可不可以用一个用户之间性能测试 查看书架？
如何让那么多用户一起登录来测试？
答：最简单的方式––>注册成功的用户都在数据库里––从数据库拿数据jmeter连接数据库：jar包+jmeter中 jdbk configuration
操作步骤：
1、导入mysql.jar包
2、创建配置元件––jdbk connection configuration
3、在jdbc connection configuration 里，配置数据库地址，和用户密码

我们复用上篇文章留下的Jmeter测试数据，然后创建连接数据库的配置元件这里需要去填写数据库名词、数据库ip地址、数据库类型、账号及密码，这个详细讲解在我另外一篇文章中，自取

然后我们需要添加一个setUp线程，这个线程在jmeter中会被优选执行的，为什么我们要使用这个优先执行的线程组，因为我们需要提前把数据库中的1000个用户提取出来

然后我们在这个线程组中添加JDPC request来查询数据库信息

输入对应sql查询语句，找到我们想要提取的用户名，并设置变量名称U

添加结果树，然后我们点击运行，可以看到数据库的用户名称被我们提取出来了

然后我们再去添加登录接口的hppt请求，并输入请求参数，username及passport，用户名称与密码，这里我们需要添加仅一次控制器，并把请求接口及查看结果树放在这个目录下，每次登录仅提起一次用户名，

输入请求参数用户名称及密码，然后点击添加结果树看看是否正常运行成功

可以看到运行成功了了（登录成功）

这是登录一次的效果实现，如果我们需要登录1000次呢，把线程循环改成1000

但是如果我们现在进行线程轮循，每次登录的都是同一个用户，那我们怎么实现模拟不同的用户进行登录
添加计时器，统计提取出来的U下划线的数字

然后将登录请求中的用户名称改成函数变量值
可通过函数助手生产变量值

由于每次登录都需要token，所以我们将token也提取出来

添加一个beanshell后置处理器将token设置为全局变量

这里有个小问题就是我们的U值获取不到，为什么获取不到，因为我们前面设置的计数器是全局变量可以看到是拖拽到最前面了，第一个目的
这里我们可以尝试再加一个计时器，用于当前线程也就是给到用户的计时器-U这里我们的登录接口就处理完了，然后我们去做查看书架线程组的基准测试

添加对应的http请求及查看结果树

这里我们需要拿到上个接口提取出来的token，所以我们添加http信息头管理，通过–P函数来拿到token

接口调通之后，我们就可以去轮循线程了，修改线程的属性

基准测试完成之后，我们就可以进行负载测试，找到接口瓶颈值（详情参考上篇文章）