1. 测试目的
【内容】
本节说明本次提出需求的目的所在，希望能够达到的目标。
【裁剪原则】
此部分内容不允许裁剪。
本测试报告为xxx系统的性能测试方案，目的是充分依据xxx系统建设实际，提供完整的高可用、高性能解决方案，建设高性能、高并发的集中式部署平台，并为项目的非功能需求（性能测试）进行了界定和细化，对今后软件测试人员、软件开发人员做出了引导作用。
2. 测试环境
2.1 系统环境标准配置
|
主机用途 |
机型/OS |
数量 |
CPU |
内存 |
IP |
|
应用软件服务器 |
Centosx |
虚拟机x台 |
Intel(R) Xeon(R) Gold 6161 CPU @ 2.20GHz |
64GB |
xx |
2.2 测试客户端配置
|
主机用途 |
机型/OS |
数量 |
CPU |
内存 |
浏览器版本 |
IP |
|
用于性能测试的机器 |
Win10 |
1 |
Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz 2.60 GHz |
16G |
Google Chrome 版本75 |
动态IP |
3. 测试场景用例设计
性能测试场景通常包括单业务基准测试、单业务压力测试、单业务负载测试、综合业务基准测试、综合业务压力测试、综合业务负载测试、综合业务稳定性测试等7种测试场景。
- 单业务基准测试：测试某个具体业务是否满足系统设计或用户期望的性能指标。比如用户期望首页查询支持300个用户并发查询，如果满足了，则认为基准测试完成，否则失败。
- 单业务压力测试：测试某个具体业务在最大负载下，持续服务的时长，以此验证被测业务的稳定性。压力测试过程中所涉及的负载，是以系统基准负载为标准，如系统基准负载为50个并发用户，则压力测试的负载设为50个，通过运行时长的变化，验证服务器在系统预设负载下持续服务的能力。
- 单业务负载测试：测试某个具体业务能够承受的最大负载，验证被测业务能够承受的最大负载数，在最佳负载下，系统仍需满足各项性能指标。
- 综合业务基准测试：与单业务基准测试类似，但综合业务需考虑业务与业务间的联系，如果相互之间存在资源争用，则需单独组合测试。假设系统需测试的业务有三个：A、B、C,综合业务基准测试是将ABC一起运行，那么加上ABC三个基准测试，共计4个基准测试场景，分别是ABC、A、B、C,但A与C存在资源争用，则需单独将A与C组合，构成一个单独的测试场景，则一共为ABC、A、B、C、AC5个基准测试场景。
- 综合业务压力测试：与单业务压力测试类似。
- 综合业务负载测试：与单业务负载测试类似。
- 综合业务稳定性测试：综合业务稳定性测试通常为核心业务在基准负载的基础上运行相对长的时间，验证服务器持续提供稳定服务的能力。稳定性场景测试的时间由需求方设定，一般为7*24小时不间断执行。
通过如上分析，根据盛世悦读确定本次性能测试的场景主要为首页查询并发基准测试、首页查询业务量基准测试、登录并发基准测试、登录业务量基准测试、盛世币订单并发基准测试、盛世币订单业务量基准测试六个场景。
|
登录业务并发基准测试场景用例 |
|||||
|
用例编号 |
|
||||
|
关联脚本用例编号 |
|
||||
|
场景类型 |
单脚本基准测试 |
场景计划类型 |
场景 |
|
|
|
场景运行步骤 |
线程数 |
|
|||
|
开始线程 |
|
||||
|
持续运行 |
|
||||
|
停止线程 |
|
||||
|
集合点 |
不设计 |
线程代理 |
不使用 |
数据监控 |
Jmeter自带 |
|
预期指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
实际指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
测试执行人 |
|
测试日期 |
|
||
|
登录业务量基准测试场景用例 |
|||||
|
用例编号 |
|
||||
|
关联脚本用例编号 |
|
||||
|
场景类型 |
单脚本基准测试 |
场景计划类型 |
场景 |
|
|
|
场景运行步骤 |
线程数 |
|
|||
|
开始线程 |
|
||||
|
持续运行 |
|
||||
|
停止线程 |
|
||||
|
集合点 |
不设计 |
线程代理 |
不使用 |
数据监控 |
Jmeter自带 |
|
预期指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
实际指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
测试执行人 |
|
测试日期 |
|
||
|
|
|
|
|
|
|
|
首页查询并发基准测试场景用例 |
|||||
|
用例编号 |
|
||||
|
关联脚本用例编号 |
|
||||
|
场景类型 |
单脚本基准测试 |
场景计划类型 |
场景 |
||
|
场景运行步骤 |
线程数 |
|
|||
|
开始线程 |
|
||||
|
持续运行 |
|
||||
|
停止线程 |
|
||||
|
集合点 |
不设计 |
线程代理 |
不使用 |
数据监控 |
Jmeter自带 |
|
预期指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
实际指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
测试执行人 |
|
测试日期 |
|
||
|
|
|
|
|
|
|
|
首页查询业务量基准测试场景用例 |
|||||
|
用例编号 |
|
||||
|
关联脚本用例编号 |
|
||||
|
场景类型 |
单脚本基准测试 |
场景计划类型 |
场景 |
|
|
|
场景运行步骤 |
线程数 |
|
|||
|
开始线程 |
|
||||
|
持续运行 |
|
||||
|
停止线程 |
|
||||
|
集合点 |
不设计 |
线程代理 |
不使用 |
数据监控 |
Jmeter自带 |
|
预期指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
实际指标值 |
|||||
|
测试项 |
响应时间 |
业务成功率 |
并发测试 |
CPU使用率 |
内存使用率 |
|
登录操作 |
|
|
|
|
|
|
测试执行人 |
|
测试日期 |
|
||
4. 测试数据说明
性能计划中，本次测试达到如下目标：
1） xxx首页-查询结果的响应时间<=3S，业务成功率为100%，并发数=300，CPU占用率<=80%,内存使用率<=80%。
2） 订单的响应时间<=5S,业务成功率为100%，并发数=300，CPU占用率<=80%,内存使用率<=80%。
3） 登录响应时间<=3S，业务成功率为100%，并发数=300，CPU占用率<=80%,内存使用率<=80%。
根据性能测试计划中的目标，我们在做登录的时候，为了更真实地模拟不同用户登录、首页查询等行为，需要针对登录用户名、首页查询等信息进行参数化设计，保证每次登录或者查询的信息都不近相同，尽可能模拟真实的业务行为。在此过程中，我们可利用Jmeter构造测试数据（可以通过连接数据库利用存储过程生成）。比如在本次测试中，测试工程师可以利用Jmeter模拟真实用户注册行为，设置线程，通过线程进行迭代的方式就可以完成对应数量的注册账号，便于后期测试使用。已经创建好的数据，我们需要定期进行数据库备份，便于回归测试。
5. 测试工具
|
工具 |
版本 |
用途 |
备注 |
|
Jmeter |
Apache JMeter3.1 r1770033 |
性能测试 |
|
Jmeter简介：
Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。 它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java 对象，数据库和查询，FTP服务器等等）的性能进行测试。它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
6. 测试方法概述
|
测试类型 |
目标 |
测试思路 |
|
性能测试 |
针对性能需求以满足系统在压力状态下的正常适用. |
使用Jmeter工具去模拟用户对xxx。 |
7. 脚本编写说明及场景执行设计
在本次编写的脚本中，主要涉及3个脚本的编写：用户登录脚本开发、首页查询脚本开发、xxx业务脚本开发。
1）用户登录脚本开发
- 利用badboy录制或自己编写脚本的方式进行用户登录过程，生成Jmeter脚本。
- 登录用户名进行参数化。
- 设置计时器
- 设置断言
- 添加”查看结果数”、“聚合报告”，便于统计测试脚本执行过程中的数据表现。
2）xxx的订单业务脚本开发
- 利用badboy录制或者自己编写脚本的方式，打开浏览器网页、输入用户名及密码，登录、点击充值、设置金额及支付方式，点击支付、退出系统等过程，生成Jmeter脚本
- 针对用户名进行参数化
- 分析请求脚本，获取需要的内容
- 设置计时器
- 设置断言
- 添加”查看结果数”、“聚合报告”，便于统计测试脚本执行过程中的数据表现。
3）用户登录脚本开发
- 利用badboy录制或自己编写脚本的方式进行浏览器登录，输入关键字进行查询，生成Jmeter脚本。
- 关键字进行参数化。
- 设置计时器
- 设置断言
- 添加”查看结果数”、“聚合报告”，便于统计测试脚本执行过程中的数据表现。
8. 监控对象
主要监控指标如下：
Running users
TPS
Trans response time(90%,标准差)
Hits per second
Throughtput
Connections per seconds
Linux resources(LoadAverage,CPU,MEM,IO,队列,网络)
9. 测试通过标准
|
测试项目 |
平均响应时间 |
业务成功率 |
CPU使用率 |
内存使用率 |
并发数 |
|
首页-查询 |
<=3S |
100% |
<=80% |
<=80% |
300 |
|
xxx |
<=5S |
100% |
<=80% |
<=80% |
100 |
|
登录 |
<=3S |
100% |
<=80% |
<=80% |
100 |
10. 测试限制与风险
测试限制条件主要存在于工具调用和人员能力问题：
- 测试工具：需要使用Jmeter在PC上模拟在线用户数量峰值和正常值。
- 测试人员能力：由于测试人员能力、精力有限，无法全覆盖所有的的情况条件组合，只对部分时间点进行性能测试。
测试风险如下：
|
风险 |
优先级 |
应对措施 |
|
需求变更 |
中 |
通过内部及时进行沟通，并做好版本管理、变更管理 |
|
人员变动 |
高 |
需要有熟悉需求的相关人员做补充 |
|
环境变动 |
高 |
预先留有后备测试环境，保证环境的稳定 |
11. 测试完成后的后续操作
1、恢复服务器内的设置，如果需要监控CPU、IO需要对Agent-server进行进程终止，且停掉该端口的使用。
2、回收脏数据，如果涉及到数据库对应的库表，我们需要数据库内的库表内容进行情况处理。
3、其他一些未知产生的文件等信息。