再谈性能测试

前言

        前几天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.

        译：在软件工程里，性能测试是指从一个角度出发用于测定系统的一些地方在特定负载下运行的速度。

        它也可以用于验证和校验系统的其他质量特性，例如可伸缩性，稳定性和资源使用率。性能测试是性能工程的一个子集。性能工程是一门新兴的计算机科学实践，它致力于构建性能于系统的设计和架构中。

         随着计算机技术以及软件产业的不断发展，性能测试的范围已经从最初简单的范畴衍生到一个非常广的领域，业界叫法也是五花八门，例如压力（强度）测试，负载测试，并发测试等。就我看来，他们之间有差别，但是由于其在测试的手段和技术上的相似性，更多的被看成是广义性能测试的几个子集。

1. 性能测试：在一个特定的基准下（相对较轻的负载），测试系统的性能表现
2. 负载测试：测试系统在多种负载组合下（相对较重的负载）的性能表现。
3. 压力（强度）测试：测试系统在高或很高强度负载情况下的性能表现。
4. 容量测试：测试系统在高或很高数据量的情况下的性能表现。

        假如预期系统的最大负载为1000的话，性能测试的负载大致为30～100，负载测试为101～800，压力（强度）测试为801～1200。这个预期的最大负载来源于系统各层的最大连接数的设置。容量测试的重点是系统的高数据量，基本不考虑并发用户数，一般测试时会注入数据库最大容量的70～90％。

        下面举个简单的例子，假设客户对系统的性能要求为系统中的主要交易响应时间不超过8秒。那么一般如何执行性能测试呢？下面是一个简单也有代表性的性能测试过程。

（表一）

去掉列1中的关键词“性能”，再加上“功能”看看。

（表二）

    看，是不是一样的。所以说基本上所有类型的测试过程都是一样的，不同的就是它们分别针对的是不同的系统特性。

性能测试为什么难？

        虽然从上面的表二看上去性能测试和一般的功能测试没有什么区别，但为什么大家都觉得性能测试难做呢？难点主要体现在一下几个步骤中。

1． 选择性能测试功能点及确定性能接收标准

有些客户的需求可能比较模糊，对于那些简单而概括的性能要求（如“系统主要交易的响应时间不超过8秒”）我们必须有针对性的重点的进行选择。当然如果客户很清楚的表明具体需要测试的地方，这个步骤可以轻松很多了。

2． 配置及维护测试环境

由于性能测试针对的是系统的性能问题，所以需要一个相对独立的环境。加上对并发用户数的要求，对网络，服务器（应用，数据库等）和客户机的真实模拟，要求负责测试的人员具备良好的网络，数据库，系统架构，操作系统的等知识。

3． 实现测试设计

测试环境搭建好后，需要根据测试计划，测试用例进行实现。常见的主要是系统的部署，数据的插入及校验，工具的安装及检查等。所以又要求负责测试的人员不但要具备良好的网络，数据库，系统架构，操作系统等知识，还要了解系统的组成，熟练的掌握测试工具。

4． 繁琐的测试运行及大量的报告处理

测试运行时及之后，负责测试的人员要非常的小心仔细的保留要所有的报告，耐心的多次运行以获取比较准确的结果。

这里还有一个需要注意的地方，随着测试工具和技术的不断发展，如同功能测试一样，大家越来越不满足简单的结论，如“用户登陆的响应时间超过客户要求的响应时间－8秒”。责任方越来越多的要求测试方可以提供更准确的资料以方便他们定位问题，所以测试方不单单分析客户机上的数据，各个服务器也是分析的对象，以期能够使修复方更快的定位问题。

5． 分析测试结果

测试结果收集以后，就该处理，并得出结论。象所有的行业一样，下结论是应该很慎重的，它需要多种工具或方法来辅助。常用的有统计学，还有概率。当然最后的结论必须是有根据的，也就是说你的结果应当象功能测试发现的bug一样可以重现，否则单凭一两次的异常就下结论，是无法说服别人的。

        当然贯穿性能测试始终的是对性能测试流程，方法，工具等知识的掌握，测试方所应有的公证。

谁做性能测试？

        首先，系统的各个特征（功能性，性能，可用性等）的实现及保障是整个团队的事情，不是一个人的事情。性能测试简单说来都是测试人员的工作，但是在实现的过程中，肯定需要开发人员，数据库管理人员，项目经理，MIS部门的多方配合和帮助。如果有有意愿做测试，对系统了解的高级开发工程师最好不过了。

后记

        当时自己在Jackie的那个文中的评论提出“本人的观点是白盒测试和性能测试都应该由开发人员做，至于负责人员是属于测试部门还是开发部门看公司的需求和架构。”其实自己的观点很简单，开发人员因为他丰富的开发知识（当然排除刚入行或比较初级的开发人员）和对系统架构及设计的了解，可以极大的保证性能测试的质量。而且当发现问题后，可以帮助开发人员做后续的系统调优。而且性能测试也应该摒着“尽早开始”的原则尽可能的早些在开发早期执行。我也因此将此划入了性能测试的范畴，但是查找资料发现那其实是性能工程的内容，早已超越了性能测试的范围。性能测试只是性能工程的一个子集。回到最初，性能测试和功能测试其实都是一样的，计划，设计并实现测试，发现问题，在问题解决后继续确认问题是否修复，给出评估。

发表于 @ 2008年07月08日 12:15:00|评论(loading...)|收藏