软件性能测试方案-性能测试准备

发布于 2021-05-10 12:20 ，所属分类：软件测试工程师学习资料

这里有爱，有分享，有工程师们的成长日记，点蓝字“软件测试面试汇总”进行,gongzhong号TestMadman

性能测试目的

性能调优

开发人员对系统调优后，需要测试人员配合去做性能测试，验证这次优化是否有效果。如果性能指标相比较之前的性能指标更好了，说明系统优化的有效果。反之说明调优不理想

新业务、新接口上线

系统从无到上线，验证新系统的能力是否能够满足某段时间系统使用要求，否则当高峰期来临，系统可能会崩溃。

验证系统稳定性

做性能测试经常跑一两个小时或者几十分钟就可以了，但系统的稳定性，系统能否长期稳定的工作，这个是不够的。系统出现的稳定性问题，一般有内存泄漏、连接数泄漏、死锁、游标不够用等，这些问题短时间内可能不会暴露出来。为了验证系统稳定性，一般用性能峰值并发数(即系统支持的最大并发数)*7天*24小时，系统的吞吐量，平均响应时间等各项性能指标均正常则认为系统稳定性是ok的。根据系统的重要程度，可以适当调整运行的时间，但至少要压测一个晚上的时间。

验证系统架构是否存在瓶颈

同一系统，架构师会提供不同的架构方案。那么不同的设计方案到底哪个好，我们可以通过性能测试验证不同方案的性能，其次了解系统大概达到什么量级的并发后系统就会出现问题，了解系统架构在达到性能峰值时哪块会出现瓶颈，帮助开发针对性地进行系统调优工作。

性能测试范围定义

一般考虑的点有如下几点：

- 系统中被频繁使用的功能、调用的接口等

- 系统中涉及大量数据库读、写的功能

- 大量读写系统缓存部分的功能，验证缓存是否生效

总得来说应该将用户访问量大的，频繁操作数据库的，系统核心功能这些地方考虑到性能测试范围内。

性能测试原则

3+1原则(指量、全、深+快)

主要对性能测试设计、测试执行以及数据分析。

量：包括业务量（业务类型），负荷量（系统处理的流量），配置量（软件配置和硬件配置），用户量（静态用户和动态用户），时间量（测试的时间）。

全：主要是针对测试用例而言。测试用例里包括预置条件，测试步骤和预期结果三部分，这个“全”重点针对预置条件和测试步骤的测试结果观察和数据而言。

深：一是对系统的了解要深，二是对缺陷的分析要深。

快：一是测试经验的固化，避免测试设计，观察等遗漏。将经验固化成模板或工具便于经验的传承，减少测试的重复和遗漏；二是性能测试的自动化，包括性能测试环境构建和测试执行以及测试分析的自动化，自动化对性能测试效率的提升价值更大。

2-5-10原则

主要针对响应时间。简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。

80/20原则

用于减少风险，抓住重点进行更多的测试：80/20原则即帕累托法则（Pareto Principle），用户80％的时间在使用软件产品中20％的功能。“重点测试”就是测试这20％的功能，而其他80％的功能属于优先级低的测试范围，占测试20%的资源。

实例：对测试强度估算

基本概念：每个工作日80％的业务在20％的时间内完成。

例如：每天工作8个小时，那么每天80％的业务在8*20％＝1.6小时内完成。

例如：去年全年处理业务约100万笔，其中，15％的业务处理中，每笔业务需对应用服务器提交7次请求；70％的业务处理中，每笔业务需对应用服务器提交5次请求；其余15％的业务处理中，每笔业务对应用服务器提交3次请求。根据以往的统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

强度估算如下：

每年的总请求数为：

（100*15％*7+100*70％*5+100*15％*3）*2＝1000万次/年

每天的请求数为：

1000/160=6.25万/天<备注：每个月为20个工作日，所以1年为160天>

每秒请求数：（62500×80％）/（8*20％*3600）＝8.68次/秒

性能测试环境搭建

保证性能测试与真实生产环境的一致性，具体从以下三方面看：

硬件环境

如服务器的型号，是否与其它应用程序共享此服务器，是否在集群环境下，是否通过BIGIP进行负载均衡，客户使用的硬件配置情况，使用的交换机型号，网络传输速率。

软件环境

版本一致性