大家好,又见面了,我是你们的朋友全栈君。
- 目的:
- 描述此次测试的目的:(以下目的请做参考)
验证改进的性能效果,需要和以前的测试结果进行比对。
新的业务上线,验证新系统能够满足系统的上线指标。
验证系统稳定性
验证系统的架构是否存在瓶颈
- 测试环境:
提供网络拓扑图
可以使用visio来花图,描述清楚几个要点:
几台测试服务器,每台都有什么服务,前台web服务、memcache、数据库?
几台服务器的连接关系
服务器软件信息说明:
服务器IP地址 | 服务器角色 | 数据库说明 | Cache说明 | 备注 |
---|---|---|---|---|
xxx.xxx.xxx.xxx | 前台服务器 数据库服务器 Cache服务器 | 数据库类型、版本 核心参数: 连接数、数据库缓存大小 | Cache的类型和版本 | |
服务器硬件信息说明:
服务器IP地址 | CPU类型 | 内存大小 | 硬盘大小 | 分区类型 | 网卡 |
---|---|---|---|---|---|
xxx.xxx.xxx.xxx | 主频 核数 | 百兆或千兆 | |||
- 测试数据说明:
数据库包含的基础数据:
被测试系统中的数据库的每个表有多少数据,以及数据的类型和大小分布的说明
其他基础数据的说明:
配置文件参数的一些特殊说明
Cache预load的数据说明
- 测试工具说明:
Loadrunner 版本
自写程序
其他第三方工具说明
- 测试范围:
哪些接口要进行性能测试和稳定性测试
哪些页面业务逻辑要进行性能测试和稳定性测试
- 测试目标:
如何界定性能测试的结果满足预定的目标,一般有如下几个标准:
1 新上线的测试系统没有明确的数字标准比对情况下,被测试系统已经被测试到了系统极限(系统的某些资源已经耗尽,cpu,句柄、内存,数据库出现大量的slow query,系统有些处理已经变慢),并且系统证明是可以水平扩展的,则可以上线。
2 有以往测试结果进行比对,只要证明类似的测试条件下,此次的结果比以往的测试结果更好即可(每秒处理个数更多、单次请求的处理速度更快)
3 没有可以比较的测试结果,但是产品已经上线一段时间(至少3个月),有一些运营数据,则需要分析运营的数据来作为比对的基准,只要被测系统达到3个月内系统并发峰值的4倍就可以认为是可以接受的。(如果是接口为测试对象,则需要混合主要的接口来进行性能测试)
4 开发人员提供经验值作为比对的基准,则被测对象只要证明满足开发人员提出的经验值即可。
如果选择以上的某一种策略,则必须明确系统的每秒处理个数和每次请求的平均时间的具体数值。
- 测试用例:
性能测试:
测试用例1
接口名称或者(页面业务逻辑):
1) xx个并发,测试时间,加载并发线程的方式
………………………………….
稳定性测试:
- xx个并发,测试mm对象,连续运行yy个小时 。
- 测试数据记录:
测试用例1:
接口名称或者(页面业务逻辑):
测试工具数据统计:
测试用例编号 | 测试时间 | 并发数 | 成功请求数 | 失败请求数 | 平均每秒处理个数 | 平均每个请求处理时间 | 方差 | 备注 |
---|---|---|---|---|---|---|---|---|
响应时间的具体统计(如果可以分析后台处理时间的log则可以统计出下面的数据),此项可选):
响应时间小于1秒的请求个数 | 响应时间超过1秒小于2秒的请求个数 | 响应时间超过2秒小于3秒的请求个数 | 响应时间超过3秒小于4秒的请求个数 | 响应时间超过4秒小于5秒的请求个数 | 响应时间超过5秒的请求个数 | 备注 |
---|---|---|---|---|---|---|
系统资源占用信息:
使用loadrunner记录在性能测试期间的cpu和load变化图像
Load的含义: linux load average后面分别是1分钟、5分钟、15分钟的负载情况,通常情况下8核的操作系统load值小于8都是比较合理的,超过8则说明负载已经开始排队了。
方差:loadruner的统计数据,这个概念是刻画波动大小的一个重要的数字。与平均数一样,仍然采用样本的波动大小去估计总体的波动大小的方法,方差越小则波动越小,稳定性也越好。在有些情况下,需要用到方差的算术平方根,即为标准差。它也是用来衡量一组数据的波动大小的重要的量,其单位和已知数据的单位是一致的。
测试用例编号 | xxx.yyy.mmm.nnn机器的cpu占用率 | xxx.yyy.mmm.zzz机器的cpu占用率 | ||
---|---|---|---|---|
1 | Cpu占用率(平均) | Load(平均) | Cpu占用率(平均) | Load(平均) |
测试数据分析:
- 系统资源哪些为瓶颈
- 发现的问题和确定的最终问题原因,是否最终解决
- 其他测试数据的分析说明
此分组结论:
是否可以满足比对的基准。
性能测试用例2:
。。。。。。。。。。
稳定性测试用例1:
测试工具数据统计:
测试项 | 测试时间 | 并发数 | 成功请求数 | 失败请求数 | 平均每秒处理个数 | 平均每个请求处理时间 | 方差 |
---|---|---|---|---|---|---|---|
系统资源占用信息:
Jboss的内存占用情况:(如果系统允许,请提供jvm的内存占用情况,如下图所示)
测试用例编号 | 10.8.8.111占用率 | 10.8.8.112 CPU占用率(平均) | ||
---|---|---|---|---|
2 | Cpu占用率(平均) | Load(平均) | Cpu占用率(平均) | Load(平均) |
测试数据分析:
1 每个请求的处理时间是否满足比对基准,系统的内存是否比较平稳,是否被耗尽?
此分组结论:
1 是否可以上线
- 性能测试(和稳定性测试)优化的说明
请描述在原有设计的基础上进行了哪些优化?
- 测试数据汇总:
性能测试:
(请将所有测试结果的主要数据汇总在这里)
测试项 | 测试时间 | 并发数 | 成功请求数 | 失败请求数 | 平均每秒处理个数 | 平均每个请求处理时间 | 方差 |
---|---|---|---|---|---|---|---|
稳定性测试:
测试项 | 测试时间 | 并发数 | 成功请求数 | 失败请求数 | 平均每秒处理个数 | 平均每个请求处理时间 | 方差 |
---|---|---|---|---|---|---|---|
- 测试结论:
接口性能测试:
Xxx接口性能(页面业务逻辑)是否满足上线要求
………
稳定性测试:
稳定性测试结论:是否满足上线要求
其他说明:
系统是否有潜在风险?
日常运营和系统维护需要监控哪些内容?
………..
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。