软件性能测试的基本概念与一般过程
[摘要]：首先对性能测试中易混淆的且必须要掌握的概念进行了阐述，接着论述了性能测试的目的与主要性能指标等基本概念，然后着重讲述了软件性能测试的一般过程，为如何进行性能测试提供了一般的方法指导。
[关键词]：性能 性能测试 负载测试 响应时间 吞吐量业务建模
引言
在中国软件的“过去”，只要把功能实现，用户都会觉得满意。随着用户的成熟与软件在各行各业中的广泛使用，软件的性能已成为用户评判软件质量的重要衡量标准。不仅如此，软件的许多缺陷也只有通过性能测试才能容易揭露。软件的性能轻则失去客户，重则导致不可估量的严重后果。我相信许多人都看过发生在去年的一则闻：第29届奥林匹克运动会比赛预订门票网站在第一次开放当天就给撑爆了。中国官方不得不在第一时间向世界公布暂停网上预售。听说负责此项目的相关负责人均被“革职”。不论最终的原因如何，有一点是明确的，该网站的性能测试未能把好关。我想此项目的负责人不可能未做压力测试就上线了。也不可能对该项目未引起高度的重视。因此，该事件恰好证明了软件的性能测试不是一件十分容易的事情，它不但要求测试人员具备很强的技术能力，还要具备综合分析问题的能力。做好一个项目的性能测试，参与的角色很多，需要有系统工程师，项目研发工程师，DBA，测试工程师，而且性能测试所需要掌握的知识非常宽广，不仅需要计算机专业知识，还需要统计学的知识。本文希望通过作者自己对性能测试所了解的冰山一角，来达到抛砖引玉的作用，激发大家对做好性能测试更深入的兴趣与探讨。
1性能测试基本概念
性能测试的重要性勿用多讲，大家都已清楚。那么想要做好性能测试，首先要了解与性能测试相关的一些最基本概念。
性能：一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量[1]。
性能测试：就是用来测试软件在系统中的运行性能的。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。一个系统的性能瓶颈往往是系统中各个模块中最差的部分所决定。他的前提是要求在一定负载下，测试系统关键性能指标值是否符合用户需要与设计需求。
负载测试： 在一个确定的软硬件环境下，对所要测试的模块或系统，加载一个确定的负载（压力），对模块或系统进行测试，探测模块或系统在这个确定环境确定负载下的性能表现。它的主要目的是验证模块或系统在给定的负载条件下的处理性能。
压力测试：不断给系统或模块增加负载（离线增加）下的负载测试。它的主要目的是是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
强度测试：系统资源不足（内存不足，cpu不足,空间不足）下，正常负载下运行系统或模块下的系统性能。它的主要目的是考查系统或模块稳定运行所需要的最少资源。
大家最易混淆的几个概念就是性能测试，压力测试与负载测试。我们从网络上google这几个关键词，便会发现不同的人会给出不同的解释。这其中的原因，一来到目前为止还未形成一个统一权威的概念，二来这三个概念之间本身存在相互关联的地方，在一定条件下可以相互转换。从广义的性能测试来看，性能测试，负载测试与压力测试都属于性能测试。它们之间的区别主要是应用在不同的测试目的。
负载测试一定是一个明确的负载下的测试系统的性能。如测试网站同时登录60个人时网站的响应速度。一个系统在一个确定的环境下，它的综合性能是一定的。就像一个方程式：综合性能=压力数*性能指数。压力测试是为了得到性能指数最小时候（可以接受的最小指数）最大的压力数，性能测试是为了得到压力数确定下的性能指数。压力数指负载数，性能指数是指可以用计数器进行定性分析的一些指标。如应用在网络上的吞吐量，响应速度，通信领域的caps值等。
2性能测试的目的
执行性能测试，一般是基于以下4个方面的部分或全部。1）是验证系统在给定的条件下处理性能是否达到设计目标与用户要求。2）是探测系统在给定的条件下极限处理能力。3） 通过对系统各参数的调整，测试系统的最优性能配置。4 通过性能测试发现功能测试难以发现的缺陷。在我们日常的性能测试中，第1种测试目的是最多的。第3种要求较高，相对来说，较少用到。
3性能测试的主要指标与来源
软件性能测试常见的主要指标有：响应时间，吞吐量，并发用户数，资源利用率。
响应时间是指对请求作出响应所需要的时间。我们常说某个软件的性能好不好，从用户的角度来说，主要是指响应时间是否足够快。响应时间就是软件性能测试中用户最直接感受的性能指标。一般情况下，响应时间越短，系统的性能越好。然而，响应时间却没有一个标准的值来参考。合理的响应时间取决于实际的应用场景与人们可以接受的程度来确定，而不能依据测试人员自己的设想来决定。如我们点击一个网站上的新闻关键词，如在2秒内能迅速看到新闻内容，感觉性能是非常好了。如果我们的oce（online charging engine在线计费引擎系统）计费平均响应时间为2秒的话，相信移动早就将oce项目转给其它开发商了。
吞吐量：单位时间内系统处理的客户请求的数量。该性能指标直接体现了软件系统的性能承载能力。一般可以用请求数/秒或字节数/秒等来度量。
并发用户数：同时向系统（服务端）发送请求的数量。该性能指标直接体现了软件系统（服务端）承受最大的并发访问的能力。针对我们的oce，则用caps来度量。实质是并发用户数请求/秒在我们通信计费领域中的对应指标。
资源利用率：主要是指系统的各种资源使用状态。这里资源主要是指系统cpu占用率，内存占用率以及系统的I/O统计情况。通过这些资源占用率就可以评估所测系统对资源的要求以及相应可能出现的瓶颈。从而为系统调优提供方向指导。
一般来说，用户对各项指标提出的明确需求是性能测试指标的主要来源，如果用户没有明确提出性能指标，则要根据行业标准以及相关的经验并结合具体的实现过程，通过分析后提供适合的性能指标值。
4性能测试一般过程
性能测试工程师从接收到一个性能测试project后，一般要经过下面六个过程。即“性能测试需求分析→制定性能测试计划→测试设计→测试开发→测试执行→测试结果评估”这六个基本阶段。
性能测试需求分析：主要是明确我们性能测试的目的。通常情况下，性能测试工程师会接收到类似“给oce做一下性能测试，测试一下免费资源赠送进程的处理能力”等测试需求不是十分明确的测试任务。面对这样的测试任务，就需要我们对这样的测试需求进行分析，将非常抽象的测试需求转化为相应的性能指标值。获取相应的性能指标值就是我们的测试目的。如“测试一下免费资源赠送进程的处理能力”，根据我们免费赠送进程的设计与实现就应转化为“免费资源赠送进程每秒插入多少条赠送记录，免费资源进程运行时资源消耗等”测试目的。
制定性能测试计划：性能测试需求分析阶段主要是明确我们测试目的，性能测试计划阶段为实现这个目的而必须要做的规划与设计。它是整个性能测试过程的成功执行的指引、监控与保证。在性能测试计划中应包含测试目的（测试性能指标值），测试策略，测试环境的要求(软硬件)，测试数据准备，测试资源需求（人力与财力），测试进度，测试风险评估，测试需完成的相关文档等关键要素内容。其中的关键要素内容，可查阅相关文档。
测试设计：在本文主要是指测试用例设计。性能测试用例的设计依据是业务建模。业务建模是指对系统各种关键业务场景的抽取以及它们之间比例的确定。业务模型的成功建立是成功执行性能测试的关键。业务建模的方法一般是采用两种方法。一是借鉴相同系统已有的模型。二是分析历史数据。有时候，在这两个方法都无法展开时，根据2-8原则进行建立。
测试开发：性能测试一般是借助于性能测试工具进行的。但工具是需要通过开发相应的脚本才能完成相应的任务。即使有的项目可以采取录制的手段获得脚本，但在绝大多数情况下，需要对脚本进行相应修改与调试才能满足我们性能测试目的。另外，工具不是万能的，有些项目不适用于已有的工具。此时需要我们进行必要的软件与脚本开发，如开发动态库使目前的工具能支持我们的测试需求，或者是重新开发相关的模拟器与挡板程序以及相应性能统计分析工具。
测试执行：测试执行相对来说比较简单，在测试环境与测试数据准备妥当之后，根据业务模型建立的业务场景直接运行相应的测试用例。测试执行过程要注意的地方有3个，每次测试前的环境恢复，测试过程与结果的监控，测试后环境的清理。其中，测试过程的监控，主要是指系统资源使用情况的监控，如（cpu利用率，mem占用率，I/O频度），同时也包括特定要求的其它监控，如磁盘占用率等。
测试结果评估：根据每次测试过程中监控到的系统资源使用情况，以及借助于自动化工具给出的测试结果分析报告或采用脚本（或分析程序）对日志文件进行统计分析的结果分析报告，对照测试目的，从而得出测试的结果是否通过的结论。同时对测试分析与统计的结果要进行评估，评估测试结果与真实理论结果之间的偏差。并写成测试报告。如果测试结果与期望值差距太大，要在测试报告中分析原因并写出自己的改进建议供研发人员参考。
5总结
本文主要从性能测试的基本概念、测试目的、性能测试的指标以及性能测试的一般过程进行了相应的论述。重点阐述了几个易混淆的几个基本概念与性能测试的一般过程。因篇幅关系，性能测试的一般过程中的部分概念与内容没有进行更深入的探讨与实例说明。本文旨在明辨概念与如何进行性能测试提供一般的方法指导。与实践相结合的部分，准备在后续的小文中单独进行总结。另外，上述性能测试的一般过程是我在实际性能测试过程中的总结，有些小的项目不一定完全适合这个过程。因此，具体的性能测试项目可根据实际情况进行相应的裁剪。
参考文献
1段念.软件性能测试过程详解与案例剖析.北京：清华大学出版社, 2006
