再谈性能测试
前言
前几天Jackie发起了一个关于“要做好性能测试，该掌握些什么？”话题的讨论。发言者很多，而自己又有些偏激的发表了一些相反的看法，这几天不断收到一些朋友的问询。昨天和老公闲聊此事，老公也发表了一些自己的看法。总结及思虑了一晚上，决定写下这篇文章。
什么是性能测试？
性能测试（在此主要指软件的性能测试）的定义各家各门派的定义很多，个人比较认同Wiki上面的解释：
In software engineering, performance testing is testing that is performed, from one perspective, to determine how fast some aspect of a system performs under a particular workload.
It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. Performance testing is a subset of Performance engineering, an emerging computer science practice which strives to build performance into the design and architecture of a system, prior to the onset of actual coding effort.
译：在软件工程里，性能测试是指从一个角度出发用于测定系统的一些地方在特定负载下运行的速度。
它也可以用于验证和校验系统的其他质量特性，例如可伸缩性，稳定性和资源使用率。性能测试是性能工程的一个子集。性能工程是一门新兴的计算机科学实践，它致力于构建性能于系统的设计和架构中。
随着计算机技术以及软件产业的不断发展，性能测试的范围已经从最初简单的范畴衍生到一个非常广的领域，业界叫法也是五花八门，例如压力（强度）测试，负载测试，并发测试等。就我看来，他们之间有差别，但是由于其在测试的手段和技术上的相似性，更多的被看成是广义性能测试的几个子集。
-
性能测试：在一个特定的基准下（相对较轻的负载），测试系统的性能表现
-
负载测试：测试系统在多种负载组合下（相对较重的负载）的性能表现。
-
压力（强度）测试：测试系统在高或很高强度负载情况下的性能表现。
-
容量测试：测试系统在高或很高数据量的情况下的性能表现。
假如预期系统的最大负载为1000的话，性能测试的负载大致为30～100，负载测试为101～800，压力（强度）测试为801～1200。这个预期的最大负载来源于系统各层的最大连接数的设置。容量测试的重点是系统的高数据量，基本不考虑并发用户数，一般测试时会注入数据库最大容量的70～90％。
下面举个简单的例子，假设客户对系统的性能要求为系统中的主要交易响应时间不超过8秒。那么一般如何执行性能测试呢？下面是一个简单也有代表性的性能测试过程。
|
性能测试 |
|
|
|
1.收集性能要求 |
|
|
|
2.编写性能测试计划 |
|
|
|
3.编写性能测试方案或用例（转换性能需求，确定性能测试点及性能接收标准） |
|
|
|
4.配置测试环境 |
|
|
|
5.实现测试设计 |
|
|
|
6.执行性能测试 |
|
|
|
7.分析测试结果 |
|
|
|
8.报告测试结果，如果性能未达到要求，提交bug |
|
|
|
9.开发人员修复bug，重新执行步骤6~8，直至测试通过 |
|
|
（表一）
去掉列1中的关键词“性能”，再加上“功能”看看。
|
性能测试 |
xx测试 |
功能测试 |
|
|
1.收集性能要求 |
1.收集xx要求 |
1.收集功能要求 |
|
|
2.编写性能测试计划 |
2.编写xx测试计划 |
2.编写功能测试计划 |
|
|
3.编写性能测试方案或用例（转换性能需求，确定性能测试点及性能接收标准） |
3.编写xx测试方案或用例（转换xx需求，确定xx测试点及xx接收标准） |
3.编写功能测试方案或用例（转换功能需求，确定功能测试点及功能接收标准） |
|
|
4.配置测试环境 |
4.配置测试环境 |
4.配置测试环境 |
|
|
5.实现测试设计 |
5.实现测试设计 |
5.实现测试设计 |
|
|
6.执行性能测试 |
6.执行xx测试 |
6.执行功能测试 |
|
|
7.分析测试结果 |
7.分析测试结果 |
7.分析测试结果 |
|
|
8.报告测试结果，如果性能未达到要求，提交bug |
8.报告测试结果，如果xx |