软件性能测试流程介绍

《软件性能测试流程介绍》由会员分享，可在线阅读，更多相关《软件性能测试流程介绍（10页珍藏版）》请在装配图网上搜索。

1、性能测试流程介绍性能测试什么时候开始：一般在系统功能稳定没有大的缺陷之后开始执行。但前期准备工作可以从系统需求分 析时就开始：性能目标制定、场景获取、环境申请等。一、制定性能测试目标 在特定的并发用户数下测试特定场景的响应时间 在一定的响应时间的要求下来测试特定场景的最大并发用户数 测试特定场景的 TPS1、线上系统对线上系统的日志进行分析以获取到这个系统每个功能的访问情况、最大的并发用户 量、平均/最大/最小响应时间。然后通过每日的增长趋势来确定最大的并发用户数、响应 时间参考日志分析的结果，即与平均响应时间相当。2、全新项目开发过程相关文档项目开发计划书、需求规格说明书、设计说明书等文档都

2、可能涉及性能测试的要求。 通过收集这些材料，可以找到初步的性能需求。但这些性能测试需求往往不够准确，需要 性能测试人员进行专业的引导。类似项目公司的其他产品或以往项目会累积出一些数据，可以作为参考。 用户使用模型 分析用户使用模型是获取性能测试需求的有效手段，考虑哪些用户使用系统的哪些典 型的业务，在什么时段有多少用户进行了什么功能的操作。例如：某OA系统每天早上 8:00会有 200 个用户在10 分钟内登录系统；每天查询交易的高峰是在9:0011:00和下 午的14:0016:0 0等，然后根据这个用户使用模型并结合80/20原则计算OA系统的登 录以及交易查询业务的并发量。80/20 原

3、则80/20 原理就是系统在每个工作日有80%的业务是在20%的时间内集中完成，或者 系统80%的用户会在20%的时间内集中进行应用操作。下面我们来举两个例子说明：(1) 某网站每日的总访问人数为10 万，其中浏览单品页占30% ，搜索业务占20% ， 登录+购买业务占50%。采用8020原则， 8小时的20%作为基准时间，计算各个业务 的并发数。搜索业务： (100000*20%*80%)/(8*3600*20%)=2.78取整为3浏览单品页： (100000*30%*80%)/(8*3600*20%)=4.17取整为 5 登录+购买： (100000*50%*80%)/(8*3600*20

4、%)=6.94取整为7(2) 系统每年的业务集中在8个月完成，每个月平均有20个工作日，每个工作日8 小时，按照80/20原则，即每天80%的业务在1.6小时完成。去年全年处理业务约100 万笔，其中15%的业务处理中每笔业务需对应用服务器提交7 次请求，其中70%的业务 处理中每笔业务需对应用服务器提交5 次请求，剩余15%的业务处理中每笔业务需对应用 服务器提交3次请求。根据以往的统计结果，每年的业务增长量为15%，考虑到今后3 年 的业务发展需要，测试需按现有业务量的两倍进行请求数来计算系统应该达到的TPS。每年的总请求数=(100 万*15%*7+100万*70%*5+100 万*15

5、%*3)*2=1000万TPS=(10000000*80%)/(8*20*8*3600*20%)=8.68，取整即 TPS=9响应时间标准2 秒以内，用户感受良好25 秒，用户觉得可以接受510秒，用户会觉得很烦躁，无法接收，会频繁刷新页面10秒以上，用户完全无法接收，直接离开二、性能测试场景获取1、线上系统单场景： 根据对线上系统的日志分析结果，访问量排在前面的功能、本次改动的以及可能会影 响到的功能、和钱有关的功能。为保险起见最好再和开发确认一下会影响到的功能。混合场景： 还是根据线上系统的日志分析结果，得到系统级别的最大并发数，再根据每日的增长 趋势做一个增量从而得到最终的最大并发数。然

6、后根据日志分析结果中的各个重要功能的 占比数来进行用户分配。稳定性场景：确定好单场景和混合场景后，还应该考虑稳定性场景。其目的是测试系统是否有内存 泄漏现象发生，同时也可以测试系统的平均无故障时间。所以，可以用混合场景做长时间 的稳定性测试。2、全新项目单场景：重要、核心的功能常用功能业务流程复杂的功能资源占用严重的功能（比如多表查询或向多张表中插入数据）混合场景：根据一定的比例把所有重要的功能都加入混合场景稳定性场景：可以考虑用混合场景做长时间的稳定性测试。三、性能测试数据确定性能测试中很重要的一点就是场景数据的设计。比如一个数据查询场景，如果该场景 对应的数据库表只有10 条数据，那么查询

7、结果肯定相对较快。但是，如果这个查询场景 对应的数据库表有1000 万条数据，那么查询结果肯定会比只有10 条数据的查询结果要慢 一些。如果性能测试不考虑数据量，那么性能测试的结果是不准确的，上线后由于未考虑 数据量的因素而引发的性能问题几率会很大。对于线上系统来说，各表的数据量可以根据线上系统的各表数据量以及增量来确定。 而新系统需要根据开发文档以及和相关项目干系人（如：客户代表、项目经理、需求分析 员、系统架构师以及产品经理一起调研和讨论来决定）四、性能测试用例设计1、单场景场景描述：模拟用户进行登录操作并发量：分别模拟并发用户数为1、10、50 三种情况进行测试压测时间：每次15 分钟数

8、据量：MySQL的user表中有70万账户集合点：不使用集合点重点关注指标：响应时间、事物成功率、应用服务器资源使用情况（CPU、内存、IO）、 MySQL数据库资源使用情况（CPU、内存、IO）、应用日志是否有死锁等错误、数据库日志 是否有死锁等错误、JVM内存使用情况和GC情况预期指标：响应时间在2 秒内、事物成功率为100%、应用服务器和数据库服务器CPU使用率60%、没有内存泄漏、数据库死锁、线程死锁等现象2、混合场景混合场景不是把所有的测试场景糅合在一起形成一个大的场景，而应该先考虑不同的 混合场景组合，如数据库查询操作的混合场景、数据库写操作的混合场景、数据库查询与 写操作都包含的

9、大混合场景。如下：场景描述：模拟系统不用用户进行数据库读写操作的混合场景，场景包括用户登录、 广告词默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排 序。并发量：总共模拟300 个用户同时操作，其中登录操作占比20%、广告词默认查询 占比 25%、新建广告组占比 15%、广告词默认创建 8%、广告审核 10%、广告生效 15% 广告词按价格排序7%压测时间：每次15 分钟数据量：MySQL的cpc表有150万条数据、plan表有10万条数据、group表有50万条数据、audit表有100万条数据，MongoDB的report表有1TB数据、user表 有 90 万条数

10、据。集合点：不使用集合点重点关注指标：响应时间、事物成功率、应用服务器资源使用情况（CPU、内存、IO）、 MySQL数据库资源使用情况（CPU、内存、IO）、应用日志是否有死锁等错误、数据库日志 是否有死锁等错误、JVM内存使用情况和GC情况预期指标：登录、广告词默认查询、新建广告组等操作响应时间在2 秒内，广告词默 认创建、广告审核、广告生效、广告词按价格排序等操作响应时间在3 秒内，事物成功率 为100%、应用服务器和数据库服务器CPU使用率60%、没有内存泄漏、数据库死锁、 线程死锁等现象3、稳定性场景 场景描述：模拟系统不用用户进行数据库读写操作的混合场景，场景包括用户登录、 广告词

11、默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排 序。并发量：总共模拟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情况预期指标：无内存泄漏现象或迹象发

12、生五、性能测试环境准备与搭建 性能测试环境包括软件环境、硬件环境和网络环境。这三大环境不仅是指应用服务器环境，还包括数据库服务器、缓存服务器、文件服务器以及其他中间应用服务器环境。硬件环境包括：CPU、内存、磁盘等基本因素。软件环境包括：操作系统版本号、配置,Linux磁盘分区、JDK版本、位数、厂商， 中间件版本号、位数，数据库版本号、位数，以及这些软件的安装路径也最好与线上环境 致。配置文件包括JVM配置、中间件配置、数据库配置文件等。网络环境包括：网络协议及网络带宽。集群环境包括：应用相关服务器的负载均衡环境、数据库的热备或主从环境、集群环 境等。申请线下仿真测试环境的时候，应遵循以下原

13、则：（1）硬件环境尽可能地保持与生产环境致（2）如果是集群环境，测试环境就不可能申请到那么多台服务器，那么可以考虑申 请 3 台与线上生产环境致的机器来作为线下的性能测试机器。在性能测试的过程中，可 以分别测试单机、双机和三机负载均衡时候的性能表现，然后根据3 种情况下性能表现计 算出线上生产环境（比如说100 台）进行负载均衡时的性能损耗率，从而较为真实的计算 出线上100 台机器进行负载均衡时候的性能指标。（3）如果数据库集群环境太庞大，比如数据库是8 组 32 台，那么线下测试不会申请 32 台机器进行性能测试。般这种情况只会申请组数据库（主三从）作为性能测试的 数据库即可。因为大型数据

14、库的集群基本都是采用拆库分表策略，所以会导致数据库集群 庞大。申请组数据库机器就可以开展性能测试，只需要保证性能测试所用的用户数据都 落在申请的这组数据库即可。4）如果实在无法保证硬件环境与线上一致，那么只能按照低配置环境进行测试，如果低配置环境测出的结果能满足线上要求，那么线上高配置环境肯定也能满足既定的性 能要求。如果无法满足，则不建议做建模估算，因为如果CP U颗粒数、高速缓存、物理内 存大小、磁盘转速不同，性能建模得出的性能结果也不够准确。如果在低配置的机器测试 达不到要求，则要在测试报告中写明测试环境，并说明不能保证因为测试环境的提升而达 到要求。Mock Server 准备：在互联

15、网行业叫Mock Server，在银行等金融行业叫做性能测试挡板。有时候系统的 业务联调需要调用到其他系统的接口，但是其他系统的开发并未完成。对于这种情况，常 见的解决方案是搭建一个临时的server，模拟那些服务，提供数据进行联调和测试。 Mock Server的使用通常会带来以下好处：（1）隔绝由其他模块或系统出错引起的本模块的测试错误。（2）隔绝其他模块的开发状态，只要定义好接口，不用管开发有没有完成。（3 ）些速度较慢的操作，可以用Mock Object代替，快速返回。六、做脚本这里就不做详细描述。七、跑场景根据测试用例来跑测试场景。八、做监控在性能测试的过程中，先用命令来监控，发现有问题再连上工具进行监控。九、分析调优 每一个调优后，配置信息及测试结果都需要详细的记录下来。十、回归测试 回归测试后，全部的目标达成后编写性能测试报告并发送给项目组成员。 十一、出图写报告1、测试目标哪些场景、并发用户数、响应时间、TPS2、测试结论通过/不通过3、本次测试的优化某某场景：开始测试的时候TPS为5，优化后TPS达到30,发现了什么问题，怎么 解决的。4、优化改动项代码JVM数据库中间件Linux 服务器5、具体测试情况系统架构测试环境测试方法测试结果6、后续优化建议