2、全新项目
单场景:
重要、核心的功能
常用功能
业务流程复杂的功能
资源占用严重的功能(比如多表查询或向多张表中插入数据)
混合场景:
根据一定的比例把所有重要的功能都加入混合场景
稳定性场景:
可以考虑用混合场景做长时间的稳定性测试。
三、性能测试数据确定
性能测试中很重要的一点就是场景数据的设计。比如一个数据查询场景,如果该场景对应的数据库表只有10条数据,那么查询结果肯定相对较快。但是,如果这个查询场景对应的数据库表有1000万条数据,那么查询结果肯定会比只有10条数据的查询结果要慢一些。如果性能测试不考虑数据量,那么性能测试的结果是不准确的,上线后由于未考虑数据量的因素而引发的性能问题几率会很大。
对于线上系统来说,各表的数据量可以根据线上系统的各表数据量以及增量来确定。而新系统需要根据开发文档以及和相关项目干系人(如:客户代表、项目经理、需求分析员、系统架构师以及产品经理一起调研和讨论来决定)
四、性能测试用例设计
1、单场景
场景描述:模拟用户进行登录操作
并发量:分别模拟并发用户数为1、10、50三种情况进行测试
压测时间:每次15分钟
数据量:MySQL的user表中有70万账户
集合点:不使用集合点
重点关注指标:响应时间、事物成功率、应用服务器资源使用情况(CPU、内存、IO)、MySQL数据库资源使用情况(CPU、内存、IO)、应用日志是否有死锁等错误、数据库日志是否有死锁等错误、JVM内存使用情况和GC情况
预期指标:响应时间在2秒内、事物成功率为100%、应用服务器和数据库服务器CPU使用率≤60%、没有内存泄漏、数据库死锁、线程死锁等现象
2、混合场景
混合场景不是把所有的测试场景糅合在一起形成一个大的场景,而应该先考虑不同的混合场景组合,如数据库查询操作的混合场景、数据库写操作的混合场景、数据库查询与写操作都包含的大混合场景。如下:
场景描述:模拟系统不用用户进行数据库读写操作的混合场景,场景包括用户登录、广告词默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排序。
并发量:总共模拟300个用户同时操作,其中登录操作占比20%、广告词默认查询占比25%、新建广告组占比15%、广告词默认创建8%、广告审核10%、广告生效15%、广告词按价格排序7%
压测时间:每次15分钟
数据量:MySQL的cpc表有150万条数据、plan表有10万条数据、group表有50万条数据、audit表有100万条数据,MongoDB的report表有1TB数据、user表有90万条数据。
集合点:不使用集合点
重点关注指标:响应时间、事物成功率、应用服务器资源使用情况(CPU、内存、IO)、MySQL数据库资源使用情况(CPU、内存、IO)、应用日志是否有死锁等错误、数据库日志是否有死锁等错误、JVM内存使用情况和GC情况
预期指标:登录、广告词默认查询、新建广告组等操作响应时间在2秒内,广告词默认创建、广告审核、广告生效、广告词按价格排序等操作响应时间在3秒内,事物成功率为100%、应用服务器和数据库服务器CPU使用率≤60%、没有内存泄漏、数据库死锁、线程死锁等现象
3、稳定性场景
场景描述:模拟系统不用用户进行数据库读写操作的混合场景,场景包括用户登录、广告词默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排序。
并发量:总共模拟300个用户同时操作,其中登录操作占比20%、广告词默认查询占比25%、新建广告组占比15%、广告词默认创建8%、广告审核10%、广告生效15%、广告词按价格排序7%
压测时间:持续2*24小时
数据量:MySQL的cpc表有150万条数据、plan表有10万条数据、group表有50万条数据、audit表有100万条数据,MongoDB的report表有1TB数据、user表有90万条数据。
集合点:不使用集合点
重点关注指标:JVM内存使用情况和GC情况
预期指标:无内存泄漏现象或迹象发生
五、性能测试环境准备与搭建
性能测试环境包括软件环境、硬件环境和网络环境。这三大环境不仅是指应用服务器环境,还包括数据库服务器、缓存服务器、文件服务器以及其他中间应用服务器环境。
硬件环境包括:CPU、内存、磁盘等基本因素。
软件环境包括:操作系统版本号、配置,Linux磁盘分区、JDK版本、位数、厂商,中间件版本号、位数,数据库版本号、位数,以及这些软件的安装路径也最好与线上环境一致。配置文件包括JVM配置、中间件配置、数据库配置文件等。
网络环境包括:网络协议及网络带宽。
集群环境包括:应用相关服务器的负载均衡环境、数据库的热备或主从环境、集群环境等。
申请线下仿真测试环境的时候,应遵循以下原则:
(1)硬件环境尽可能地保持与生产环境一致
(2)如果是集群环境,测试环境就不可能申请到那么多台服务器,那么可以考虑申请3台与线上生产环境一致的机器来作为线下的性能测试机器。在性能测试的过程中,可以分别测试单机、双机和三机负载均衡时候的性能表现,然后根据3种情况下性能表现计算出线上生产环境(比如说100台)进行负载均衡时的性能损耗率,从而较为真实的计算出线上100台机器进行负载均衡时候的性能指标。
(3)如果数据库集群环境太庞大,比如数据库是8组32台,那么线下测试不会申请32台机器进行性能测试。一般这种情况只会申请一组数据库(一主三从)作为性能测试的数据库即可。因为大型数据库的集群基本都是采用拆库分表策略,所以会导致数据库集群庞大。申请一组数据库机器就可以开展性能测试,只需要保证性能测试所用的用户数据都落在申请的这组数据库即可。
(4)如果实在无法保证硬件环境与线上一致,那么只能按照低配置环境进行测试,如果低配置环境测出的结果能满足线上要求,那么线上高配置环境肯定也能满足既定的性能要求。如果无法满足,则不建议做建模估算,因为如果CPU颗粒数、高速缓存、物理内存大小、磁盘转速不同,性能建模得出的性能结果也不够准确。如果在低配置的机器测试达不到要求,则要在测试报告中写明测试环境,并说明不能保证因为测试环境的提升而达到要求。
Mock Server准备:
在互联网行业叫Mock Server,在银行等金融行业叫做性能测试挡板。有时候系统的业务联调需要调用到其他系统的接口,但是其他系统的开发并未完成。对于这种情况,常见的解决方案是搭建一个临时的server,模拟那些服务,提供数据进行联调和测试。Mock Server的使用通常会带来以下好处:
(1)隔绝由其他模块或系统出错引起的本模块的测试错误。
(2)隔绝其他模块的开发状态,只要定义好接口,不用管开发有没有完成。
(3)一些速度较慢的操作,可以用Mock Object代替,快速返回。
六、做脚本
这里就不做详细描述。
七、跑场景
根据测试用例来跑测试场景。
八、做监控
在性能测试的过程中,先用命令来监控,发现有问题再连上工具进行监控。
九、分析调优
每一个调优后,配置信息及测试结果都需要详细的记录下来。
十、回归测试
回归测试后,全部的目标达成后编写性能测试报告并发送给项目组成员。
十一、出图写报告
1、测试目标
哪些场景、并发用户数、响应时间、TPS
2、测试结论
通过/不通过
3、本次测试的优化
某某场景:开始测试的时候TPS为5,优化后TPS达到30,发现了什么问题,怎么解决的。
4、优化改动项
代码
JVM
数据库
中间件
Linux服务器
5、具体测试情况
系统架构
测试环境
测试方法
测试结果
6、后续优化建议
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。