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

性能测试的目的

一个

性能调整

开发人员调优系统后，需要测试人员配合做性能测试，验证优化是否有效。如果性能指标优于以前的性能指标，则系统优化是有效的。相反，调谐并不理想

2

新服务和新界面上线

从零开始到上线，验证新系统的能力在一定时间内是否能满足系统的要求，否则，到了高峰期，系统可能会崩溃。

三

验证系统稳定性

通常只需要一两个小时或者几十分钟就可以做性能测试，但是系统的稳定性和系统能否长时间稳定工作是不够的。系统的稳定性问题一般包括内存泄漏、连接数泄漏、死锁、游标不足等。这些问题可能短时间内不会暴露。为了验证系统的稳定性，一般认为在性能峰值并发*7天*24小时，系统吞吐量、平均响应时间等性能指标正常时，系统的稳定性是可以的。根据系统的重要性，运行时间可以适当调整，但至少需要一夜的压力测量。

四

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

架构师会为同一个系统提供不同的架构方案。那么不同的设计方案中哪一个更好呢，我们可以通过性能测试来验证不同方案的性能。其次，我们知道系统会有什么样的并发级别，当系统架构达到性能峰值时，哪个块会出现瓶颈，从而帮助开发有针对性的系统调优。

性能测试范围的定义

-系统中常用的功能和调用的接口等

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

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

一般来说，性能测试的范围要考虑用户访问量大、数据库操作频繁、系统核心功能多的区域。

3+1原则

主要是性能测试设计、测试执行和数据分析。

数量:包括业务量、负载量、配置量、用户量、时间量。

All:主要针对测试用例。测试用例管理包括预设条件、测试步骤和预期结果。这个“全部”侧重于预设条件和测试步骤的测试结果的观察和数据。

深刻:一是要对制度有深刻的认识，二是要对缺陷有深刻的分析。

快:首先要固化测试经验，避免遗漏测试设计和观察。将经验固化成模板或工具，便于经验的继承，减少测试的重复和遗漏；二是性能测试的自动化，包括性能测试环境构建、测试执行和测试分析的自动化。自动化对于提高性能测试效率更有价值。

2-5-10原则

主要是反应时间。简单来说，当用户能在2秒内得到响应时，他会觉得系统响应很快；当用户在2-5秒内得到响应时，会觉得系统的响应速度还可以；当用户在5-10秒内得到一个响应时，会觉得系统响应速度慢，但可以接受；当用户超过10秒钟仍然得不到响应时，他会觉得系统很糟糕，或者认为系统失去了响应，选择离开此网站或发起第二次请求。

80/20原则

用来降低风险，专注于更多的测试:80/20原则是帕累托原则，用户80%的时间都在使用软件产品中20%的功能。“关键测试”是测试这20%的功能，而其他80%的功能属于低优先级的测试范围，占测试资源的20%。

基本概念:每个工作日20%的时间完成80%的业务。

比如你一天工作8小时，你80%的业务会在8 * 20% = 1.6小时内完成。

例如，去年处理了大约100万个事务，其中15%的事务需要向应用服务器提交7个请求；在70%的业务处理中，每个业务需要向应用服务器提交5个请求；在剩下的15%的业务处理中，每个业务向应用服务器提交三个请求。根据之前的统计结果，年业务增量为15%。考虑到未来三年业务发展的需要，测试应以现有业务量的两倍进行。

强度估计如下:

每年的请求总数是:

* 2 = 1000万次/年

每天的请求数是:

1000/160 = 62，500/天:

每秒请求数:/ = 8.68次/秒

性能测试环境的建立

保证性能测试与实际生产环境的一致性，具体从以下三个方面着手:

一个

硬件环境

如服务器的型号，是否与其他应用共享，是否在集群环境中，是否由BIGIP进行负载均衡，客户的硬件配置，使用的交换机型号，网络传输速率等。

2

软件环境

版本一致性

包括操作系统、数据库和中间件的版本，以及被测系统的版本。

配置一致性

系统参数的配置是一致的，可能对系统有很大影响。因此，除了要保证测试环境中使用的软件版本与真实环境中的软件版本一致外，还要注意其参数的配置是否一致。

三

使用场景的一致性

基础数据的一致性

包括预测的业务数据量和数据类型的分配。这是一个简单的专栏。一个系统数据库只有10个数据，一个数据库有几千万个数据。当我们测试它的性能时，得到的性能指标可能会有很大的不同。

为了保证每个测试环境的一致性，磁盘使用和磁盘碎片或多或少都会影响性能。

使用模式的一致性

尽量模拟用户在真实场景中的使用情况。其实我们在做性能测试前期的需求分析，其主要目的是为了更逼真地模拟用户的使用情况。