六：测试报告编写(ps：测试报告不仅仅是给领导看的 尽量把图表做的漂亮些)
6.1测试目标1.1.1：评估禅道(开源版8.0.1)是否满足公司使用。
1.1.2：评估禅道(开源版8.0.1)最大负载。
6.2参考文档《禅道开源版操作手册》
6.3测试环境说明6.3.1硬件配置服务器名称
配置/详细信息
数量
IP
Web&数据库服务器
Cpu:i5
Disk:500G
Memory：8G
1
192.168.10.206
负载机
Cpu:i3
Disk:500G
Memory：8G
DB:MySQL 5.5
1
192.168.10.188
负载机
Cpu:i5
Disk:500G
Memory:8G
Net:100Mbps局域网
1
192.168.10. 118
6.3.2软件配置序号
软件名称
Web服务器
数据库服务器
负载机
1
操作系统
Win7 旗舰版 SP1
Win7 旗舰版 SP1
Win7 旗舰版 SP1
2
数据库
--
MySQL 5.5
--
3
浏览器
--
--
IE11 Chrome45
4
WebServer
Apache Apache2.4
--
--
5
Application
禅道(开源版8.0.1)
--
--
6
其他工具
HttpWatch 9.4
LoadRunner 11
6.4测试策略6.4.1人力资源测试轮次
测试时间
测试人员
运维
架构师
起始时间
结束时间
第1轮测试
2021-01-11
2021-01-15
姜林斌
小胡
卡特
第2轮测试
2021-01-18
2021-01-21
姜林斌
小胡
卡特
第3轮测试
2021-01-25
2021-01-29
姜林斌
小胡
卡特
6.4.2测试方案测试过程按两个步骤进行，即单独场景压力测试、负载测试。
单独场景压力测试：针对某个功能点进行压力测试，分析测试结果是否满足用户要求的指标；
负载测试：选择某些业务场景对系统持续增压测力，持续运行一段时间，根据并发量或系统监控等来观察系统的最大负载(响应时间<3s&CPU使用率<80%&内存使用率<80%)。
6.4.3测试场景具体请参考《禅道性能测试方案》
6.4.4测试用例6.4.4.1 团队需求符合性验证基准测试用例登录禅道(LoginZentao)用例名称
查看客户/合同详情+创建跟进记录
用例编号
003
测试步骤
1：处理请求报文替换客户的dataId，以支持随机查看不同客户详情。
2：处理请求报文替换合同的dataId，以支持随机查看不同合同详情。
3：处理跟进记录创建请求报文中客户的dataId，已支持对不同客户的跟进。
4：Jmeter中使用3个Stepping Thread
Group线程组分别对应3种业务场景，
3种业务请求比例1:1:1。
场景设计
1、设置每个线程组虚拟用户数量为150。
2、Start Users：每隔1秒自动增加3个用户登录系统，直到增加至150个。
3、Duration方案：在450Vusers负载下 持续压测20分钟。
4、Stop Users：每隔1秒停止3个用户，直到停止所有用户。
执行时间
30分钟
预期结果
预估线上峰值QPS值*3<实际压测值
RT峰值<=200ms
峰值错误率(统计非200)<=0.1%
单核平均峰值cpu利用率<=70%
单核平均峰值load1<=0.8
峰值内存利用率<=80%
添加用例(AddTestCase)用例名称
添加测试用例
用例编号
002
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
3：设置登录事件为事务“添加测试用例”
场景设计
1、设计用户数量为10
2、Start Users：每隔30秒自动增加1个用户，直到增加至10个
3、Duration方案：在10Vusers负载下 持续压测10Mins
4、Start Users：每隔30秒自动增加1个用户，直到增加至20个
5、Duration方案：在20Vusers负载下 持续压测10Mins
6、Stop Users：每隔30秒停止1个用户，直到停止所有用户
执行时间
38分钟
预期结果
1、 事务响应时间平均值不能超过5秒
2、 CPU使用率平均值不能高于75%
3、 物理内存使用率不超过70%
执行用例(ExecuateCase)用例名称
执行用例
用例编号
003
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
3：设置测试执行用例的事件为事务“执行用例”
场景设计
1、设计用户数量为10
2、Start Users：每隔30秒自动增加1个用户，直到增加至10个
3、Duration方案：在10Vusers负载下 持续压测10Mins
4、Start Users：每隔30秒自动增加1个用户，直到增加至20个
5、Duration方案：在20Vusers负载下 持续压测10Mins
6、Stop Users：每隔30秒停止1个用户，直到停止所有用户
执行时间
38分钟
预期结果
1、 事务响应时间平均值不能超过5秒
2、 CPU使用率平均值不能高于75%
3、 物理内存使用率不超过70%
提交Bug (提交Bug)用例名称
提交Bug
用例编号
004
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
3：设置测试新建bug的事件为事务“提交Bug”
场景设计
1、设计用户数量为10
2、Start Users：每隔30秒自动增加1个用户登录系统，直到增加至10个
3、Duration方案：在10Vusers负载下 持续压测10Mins
4、Start Users：每隔30秒自动增加1个用户登录系统，直到增加至20个
5、Duration方案：在20Vusers负载下 持续压测10Mins
6、Stop Users：每隔30秒停止1个用户，直到停止所有用户
执行时间
38分钟
预期结果
1、 事务响应时间平均值不能超过5秒
2、 CPU使用率平均值不能高于75%
3、 物理内存使用率不超过70%
解决Bug(FixBug)用例名称
解决Bug
用例编号
005
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
3：设置开发更改bug为fixed状态的事件为事务“解决Bug”
场景设计
1、设计用户数量为10
2、Start Users：每隔30秒自动增加1个用户登录系统，直到增加至10个
3、Duration方案：在10Vusers负载下 持续压测10Mins
4、Start Users：每隔30秒自动增加1个用户登录系统，直到增加至20个
5、Duration方案：在20Vusers负载下 持续压测10Mins
6、Stop Users：每隔30秒停止1个用户，直到停止所有用户
执行时间
38分钟
预期结果
1、 事务响应时间平均值不能超过5秒
2、 CPU使用率平均值不能高于75%
3、 物理内存使用率不超过70%
关闭Bug (CloseCase)用例名称
关闭Bug
用例编号
006
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
3：设置测试更改bug为close状态的事件为事务“关闭Bug”
场景设计
1、设计用户数量为10
2、Start Users：每隔30秒自动增加1个用户登录系统，直到增加至10个
3、Duration方案：在10Vusers负载下 持续压测10Mins
4、Start Users：每隔30秒自动增加1个用户登录系统，直到增加至20个
5、Duration方案：在20Vusers负载下 持续压测10Mins
6、Stop Users：每隔30秒停止1个用户，直到停止所有用户
执行时间
38分钟
预期结果
1、 事务响应时间平均值不能超过5秒
2、 CPU使用率平均值不能高于75%
3、 物理内存使用率不超过70%
确认Bug用例名称
查看待办事项
用例编号
007
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
场景设计
1、设计每组虚拟用户数量为20
2、Duration：持续压测20分钟
3、Stop Users：每隔30秒停止1个用户，直到停止所有用户
执行时间
38分钟
预期结果
1、 事务响应时间平均值不能超过5秒
2、 CPU使用率平均值不能高于75%
3、 物理内存使用率不超过70%
6.4.4.2负载测试负载测试选取的业务场景如下：
1:登录系统
用例名称
登录禅道
用例编号
008
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
场景设计
场景模式：使用百分比模式设置每台负载机承受50%的负载(Real-World模式)。
第一轮测试：
1初始化100个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至120个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第二轮测试：
1初始化140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至160个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第三轮测试：
1初始化180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至200个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第四轮测试：
1初始化220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至240个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至260个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
2：添加用例
用例名称
添加测试用例
用例编号
009
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
场景设计
场景模式：使用百分比模式设置每台负载机承受50%的负载(Real-World模式)。
第一轮测试：
1初始化100个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至120个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第二轮测试：
1初始化140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至160个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第三轮测试：
1初始化180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至200个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
3：执行用例
用例名称
执行测试用例
用例编号
010
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
场景设计
场景模式：使用百分比模式设置每台负载机承受50%的负载(Real-World模式)。
第一轮测试：
1初始化100个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至120个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第二轮测试：
1初始化140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至160个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第三轮测试：
1初始化180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至200个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第四轮测试：
1初始化220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至240个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至260个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
4：新建Bug
用例名称
新建Bug
用例编号
011
测试步骤
1：部署性能测试环境。
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本。
场景设计
场景模式：使用百分比模式设置每台负载机承受50%的负载(Real-World模式)。
第一轮测试：
1初始化100个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至120个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第二轮测试：
1初始化140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至160个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第三轮测试：
1初始化180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至200个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第四轮测试：
1初始化220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至240个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至260个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
5：修复Bug
用例名称
修复Bug
用例编号
009
测试步骤
1：部署性能测试环境
2：用loadrunner录制脚本 使用Port Mapping策略录制脚本
场景设计
场景模式：使用百分比模式设置每台负载机承受50%的负载(Real-World模式)。
第一轮测试：
1初始化100个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至120个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第二轮测试：
1初始化140个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至160个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
4 Stop Users：每隔5秒停止2个用户，直到停止所有用户。
第三轮测试：
1初始化180个Vusers(每5秒增加2个)，Duration持续压测10分钟；
2初始化至200个Vusers(每5秒增加2个)，Duration持续压测10分钟；
3初始化至220个Vusers(每5秒增加2个)，Duration持续压测10分钟；
Stop Users：每隔5秒停止2个用户，直到停止所有用户。
Stop Users：每隔5秒停止2个用户，直到停止所有用户。6.5测试结果及其分析{PS：性能分析相对于脚本开发和场景设计来说反而简单许多，为什么？别急，听愚兄为你们娓娓道来。
上面的篇幅中有介绍到OS,DB,网络，中间件的监控；我们可以把response time原子化 分割成独立的部分，比如我们执行一次压测的时候 监控OS，DB，网络，中间件，并在代码里作埋点处理(埋点其实很好理解，最简单的就是函数开始时计时，函数执行完后再次计时，从而得出函数执行时间)，这样一来，我们清楚地知道每一层的性能状况，从而分析性能问题上会事半功倍。这里不得不提一点：运维同学对监控的专业程度远非我们性能测试同学能想象的 哈哈~ 别说我没告诉过你”性能测试的实施不仅仅只要有测试工程师就够了”。
另：再次强调一下 不要以为掌握了LR的使用就表示会性能测试了，这不扯淡么！
LR它本身就只是一个工具，只不过我们可以用它很方便地来实施性能测试。
如果我们不用LR，而选择自己写脚本来达到模拟N多用户的并发请求 这不更好么？
But：做事情要考虑成本和回报！已经有这些很好用的工具了(LR，Jmeter,Gatling)就不要重复造轮子了，辛辛苦苦造出来，说不定到最后推行时阻力重重会被废掉。
当然，BAT这种怪兽团队除外，不差钱，不差人，不差时间，天时地利人和均得 那就没啥好说的了。咋整？play yourselves!!!
}
6.5.1登录场景结果分析
添加描述
6.5.2添加用例场景结果分析
添加描述
6.5.3执行用例场景结果分析
添加描述
6.5.4提交Bug场景结果分析
添加描述
6.5.5解决Bug场景结果分析
添加描述
6.5.6关闭Bug场景结果分析
添加描述
6.5.7确认Bug场景测试结果分析
添加描述
6.6测试结论6.6.1团队符合性评估
添加描述
分析结论：
测试过程中CPU使用率小于50%，平均响应时间远小于5s，且tps均大于目前团队业务量。
禅道(开源版v8.0.1)满足团队目前及未来5年内使用。
6.6.2负载测试登录场景负载测试结果：
添加描述
添加用例场景负载测试结果：
添加描述
执行用例场景负载测试结果：
添加描述
提交Bug场景负载测试结果：
添加描述
修复Bug场景负载测试结果：
添加描述
关闭Bug场景负载测试结果：
添加描述
负载测试结果汇总：
添加描述
分析结论：
各场景测试过程中 响应时间和CPU使用率和磁盘读写速率密切相关;CPU使用率为主要性能瓶颈点。
禅道部署优化建议：
为了禅道系统能达到更优的服务，建议将集成环境配置改为web服务和mysql数据库分开部署在不同的PC上 而不是使用现有的集成环境。
七：写给测试路上一起前行的同学们他山之石 可以攻玉
性能测试涉及到的知识域非常广，我们需要了解 网络，OS，系统架构，业务逻辑，协议报文，脚本开发，服务和系统的监控等等更方面的知识，这就要求我们在实施性能测试的时候需要和多方进行跨部门沟通协调~
其实，我们完全没必要在所有领域亲自操刀，数据库的监控和调优 我们肯定比不了DBA；
服务和系统的监控 我们也绝对的没运维熟悉；而代码级别的性能问题定位 我们更是没开发同学清楚；而配置的调优 更是运维同学们的拿手好戏~
So what？ 我们完全可以调动在专项领域里更专业的资源来做正确的事情。
最后，希望有机会看到此文的同学 不要眼高手低 光说不练，那样只会成为理论派的纯把式~
Actions speak louder than words~~~ 诸君共勉！
我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表