第1章 软件性能测试

当今，计算机和软件工程发展越来越快，新的概念名词和技术手段层出不穷，可谓日新月异。在软件性能测试范畴内就有很多，诸如并发测试、压力测试、基准测试、测试场景等概念和名词，这让刚接触性能测试的新手眼花缭乱，目不暇接。但我们如果能深入软件性能测试的本质，从哲学的角度看问题，找出其内在联系，比如因果关系、形式内容关系，甚至重叠关系等，理清思路之后，那么做软件性能测试就会如庖丁解牛，游刃有余。

1.1  什么是软件的性能

1.1.1  软件

计算机软件作为人类逻辑智慧的结晶，它可以模拟并替代人类的一些活动，替人“发号施令”。在计算机软件发展的短短几十年内，计算机软件以非常快的速度渗透到了人类社会的各个角落，比如现在我们在家上网，出门坐公交车刷卡，在工作中发电子邮件等，这些生活的背后都有大量的软件系统运行支持。

同时，有关软件的概念和名词也呈爆炸性增长，从google中搜索“软件”关键词，就有135 000 000条记录；软件的方向和领域也在不断细化，比如软件架构和平台、软件工程、软件应用，还有软件开发测试等，因此我们可以判断软件的发展趋势是系统化、复杂化，这个趋势使软件能够提供越来越强大的功能，但同时也为我们理解和把握软件带来困难。

但我们做事的原则应该是要把复杂的事情变简单，而不是更复杂，更难理解。当我们试图理解和分析一个复杂的事物的时候，最常用的方法是分而治之，就是要用一个或多个简单的概念去解释或描述这个复杂的事物，这符合我们人类的认知规律，人们对简单的概念能够理解，那么对简单进行综合和归纳，就形成了对复杂的认知。比如，我们想要让一个没有上过网的人明白什么是“电子邮件”，那就可以告诉他“通过网络发送的邮件”，当然他很有可能对“网络”也一头雾水，那么你可以继续向他解释“打鱼的网”。但在软件领域中，我们却经常搞不明白这个道理，一个刚入门有志于软件性能测试的菜鸟小心翼翼地向一个前辈高人请教什么是性能测试，前辈首先以威严的口气告诉他“性能测试是很复杂的”，然后徐徐道来“性能测试分为负载测试、压力测试、容量测试等”。到这里，我相信可怜的菜同学对性能测试已经更加糊涂了，他在请教问题之前，恐怕还能知道性能测试是测试软件性能的，在得到高手回答之后，他开始勤奋地请教google，没想到google回答他的是更多的名词概念（网上文章都是前辈仙人写的）。随着时间推移，菜同学升级成牛同学，他对性能测试名词概念烂熟于心（google功底深厚），并且牛同学又牢牢坚持与时俱进的思想，独立创新了N个性能测试概念，并开始向一群小菜粉丝们讲经布道，于是上一幕的画面和对白又开始回放，只是演员变了……这只是一个假想的故事，故事的结局就是通过“学习”，性能测试不仅没有简单，反而越来越复杂了。我们要真正掌握性能测试，那就要避免这样的事情发生，从本质上认识软件性能和软件性能测试。

辩证唯物主义哲学认为，时间和空间是运动着的世间万物的存在形式。大到社会形态，小到个人的活动，都是在一定的空间和时间内进行的。

因此，我们在试图把一件事情表述清楚时，通常要抓住事情的几个关键要素：时间、空间（地点）、人物（主体）、事件。比如“旅行者的一次长途旅行在两个月内从北京到西藏”，这句话中包含了关键要素，其时间是两个月，空间是北京到西藏，人物是旅行者，发生的事件是旅行者在两个月时间范围内发生空间中的转移；又如“一场足球赛”，这个名词看起来简单，但仍清楚地隐含了三个要素，即：时间，通常是90分钟（如果没有加时赛和伤停补时）；空间，足球场内；人物，足球运动员，事件就是在足球规则下可能发生的事情，如进球等。

计算机的出现是人类历史上一次伟大的革命，在哲学“物质”这个名词的外延中又多了一个新型事物——计算机软件。如果我们认识到计算机软件也是万物之一，分析其作为“物质”的性质也逃脱不了自然法则的“紧箍咒”，那么我们同样可以把软件作如下简单的理解：

主体：程序，是人类逻辑思维的物化，表现形式为一系列指令代码。

时间：即使计算机速度再快，任何软件程序每一段代码的运行都是需要时间的，例如从用户的感受来讲，就是程序将运行结果响应给用户的速度。

空间：软件运行的环境，以资源的方式存在，通常是软件以间接或直接的方式占用并使用硬件资源和其他软件资源。

硬件资源主要指运行该软件的硬件平台，有CPU、内存和存储系统等，如果软件是基于网络架构的，那么硬件还有网络硬件，如交换机、路由器等。

软件资源包括操作系统、开发平台、中间件和数据库等，它们以库文件和API的方式提供给应用软件使用。

事件：软件按照用户的要求运行，运行的同时必然要占用时间资源和空间资源。

由于软件代码是人的逻辑思想的表现，所以软件在设计思想和实现方法上也有很大差异。另外，随着软件的发展，产生了各种应用领域的软件，它们之间存在着千丝万缕的关系。从层次上看，有系统软件，应用软件和介于两者之间的中间件。因此一个软件的运行牵涉的因素很多，需要从各个方面分析。

1.1.2  软件性能的产生

用户能够看到的是软件越来越通用，功能越来越庞大，从哲学角度上看待软件本身，其发展是一个从简单到复杂，从低级到高级，从无序到有序的过程。

在计算机发展的初期，计算机软件对硬件有很强的依赖性，而且还没有广泛的通用性，只有少数的个人或机构才使用软件这个“奢侈品”，当时用户也没有软件性能的概念，通常为了实现软件的功能而不计一切代价。比如，1946年2月15日，世界上第一台通用电子数字计算机“埃尼阿克”（ENIAC）在美国研制成功。它当时由1.8万个电子管组成，是一台又大又笨重的机器，体重达30多吨，占地有两三间教室般大。它当时的运算速度仅为每秒5000次加法运算，在现在看来，它占用如此多的资源，又运行得如此慢，在当时却是相当了不起的成就，因为它已经实现了功能——能够做加法运算。可见初期的软件是简单的，当时用户的要求用现在的眼光来看真有点可怜巴巴，对软件的要求不高，只要能工作就OK了。

软件诞生后，短短几十年，软件业奇迹般的高速发展，逐渐走下了高高在上的神坛，广泛应用到人类社会的各个领域，用户也不再把软件看做神秘的玩意，而是普通的商品，开始从经济学的角度来考虑软件产品，这是一个意味深长的变化。讲经济就是要运用投入产出的关系分析和指导软件工程的各种活动和环节，软件运行不能以硬件不计成本为假设，要尽可能地少占用各种硬件资源，同时，软件运行的速度也要尽可能地快，每秒5000次加法运算是根本不可想象的，也是不可能被用户接受的。这些其实就是用户的最原始的性能需求。

1.1.3  功能与性能的关系

首先，软件的性能和功能的源头都是来自于用户的需求。

功能指的是在一般条件下软件系统能够为用户做什么，能够满足用户什么样的需求。拿一个电子邮件系统来讲，用户期望这个软件系统能够提供收发电子邮件、保存草稿、设置偏好等功能，只有这些功能实现了，用户才认为这是他想要的软件。但是随着软件市场竞争的激烈，软件技术的日益提高，系统能不能工作已经是一个最起码的门槛，能够“又好又快”才会得到用户的青睐，而性能则是衡量软件系统“好快”的一个重要考虑因素。“好”就是要为用户省钱，用最小的硬件成本运行软件系统；“快”就是软件响应时间要短，我们的用户都是急性子，最好一秒钟也不要等。简单地说，性能就是在空间和时间资源有限的条件下，软件系统还能不能工作。

如果把上面邮件的功能和性能需求量化，写成用户需求说明书可能是下面这个样子：

功能：

邮件系统能够支持收发以30种语言为标题和正文的邮件，并支持粘贴10MB的邮件附件。

性能：

邮件系统能够在2GB RAM/1GHz CPU的服务器上，支持10000注册用户，日均处理10000邮件，响应时间不超过5秒/封。

我们来对比一下功能需求说明和性能需求说明，发现两者有一些不同之处：

（1）功能需求中名词和动词多，描述软件主体和动作行为，比如“标题”、“正文”、“收发”、“粘贴”等；

（2）性能需求中对涉及容量和时间词汇多，如“2GB RAM服务器”、“1000注册用户”、“5秒/封”等。

相信我们的读者已经从上面的对比看出功能和性能的区别了，软件性能和功能区别的实质是，软件功能焦点在于软件“做什么”，关注软件物质“主体”发生的“事件”；而软件性能则关注于软件物质“做得如何”，这是综合“空间”和“时间”考虑的方案（资源和速度），表现为软件对“空间”和“时间”的敏感度。认识到性能的这个基本特征对于性能测试人员非常重要，因为在下面的章节中我们将要通过多个“空间”和“时间”的组合，来揭开性能指标的实质和提高的办法。另外，我们也要认清一个事实，软件的性能实现是建立在功能实现的基础之上的。

这就像一个人首先要能跑，这是一个健康的人的正常功能，然后才能参加百米比赛，这就如对人身体的性能考验。而百米比赛隐含了两个要素：一个是运动员有一个一百米的运动空间；另一个是比赛，要跑得足够快，要在短时间内跑完。因此我们说百米比赛其实就是一个空间和时间的综合结果。

“空间”和“时间”是一个哲学中抽象层次较高的概念，在不同的应用范围有不同的诠释。那么在软件理论和实践中，我们怎样理解“空间”和“时间”呢？所谓“仁者见仁，智者见智”，下面我们就分别从用户的角度和软件人员的角度来看一下软件的性能。

1.1.4  用户眼里的软件性能

软件系统在满足用户强大的功能需求同时，架构和实现上也变得复杂，软件系统经过单机系统时代、客户机服务器系统时代，到现在跨广域网的庞大分布式系统时代，这样的例子在金融、电信系统中随处可见。

系统的业务量大了，就要使用更多的时间和空间资源，在一般情况下不能出现的软件性能问题就暴露出来了，这些问题“不鸣则已，一鸣惊人”，轻则让软件对外不能正常提供服务，重则可能会导致系统的崩溃甚至数据的丢失，这都会给用户带来无法估量的损失。

 案例1

某西部大型油田使用钻井平台数据采集系统，在上线之前已经通过功能测试，但软件系统上线之后，在使用采集的电子数据勘探油层时，总是不能准确地找到油口，导致数百万元的损失。经过研究试验，发现软件从平台采集的数据和手工采集的数据有很大出入，性能测试后，找到根本原因：由于采集过程中产生的数据量非常大，导致软件系统在采集过程中线程死掉，丢失部分数据，最终产生的是一个错误的采集结果，为工程人员提供了错误的判断依据。

 案例2

日本第三大手机运营商——软银移动2006年10月遇到了麻烦，本指望通过降低手机资费来吸引用户，谁想大量用户蜂拥而至却导致自己的电脑系统陷入瘫痪，软银移动在10月29日不得不宣布暂停接纳新的用户，直接损失逾亿日元。

用户当然不想看到以上的场景发生在自己的软件系统上，“瘫痪”意味着响应时间过长，不能为客户正常提供服务；数据丢失则是一个不可接受的严重问题，损失几乎不可弥补。因此用户对软件性能的要求日益细化严格，可以说是“与时俱进”。

简单地说，在软件发展的初级阶段，“又要马儿跑，又要马儿少吃草”，这是当时很多用户对软件系统提出的性能要求，“跑”有关时间，“草”有关空间。马儿跑，就是软件系统给用户的响应要快，处理时间要短；马儿少吃草就是软件系统能够尽可能地少占用和消耗资源，诸如内存、CPU等。因此，测试人员在做性能测试时，往往要把响应时间、内存利用率、I/O占用率等写在最后测试报告里，因为这是用户最关心的东西。

随着用户的软件质量意识的增强，用户对软件的性能需求也越来越多，越来越细致。这时不仅要让马儿跑，还要马儿能快能慢（软件系统的伸缩性），“路遥知马力”（软件系统在长时间运行下的稳定性）等。细数起来，如下：

Ÿ 计算性能；

Ÿ 资源的利用和回收；

Ÿ 启动时间；

Ÿ 伸缩性；

Ÿ 稳定性。

计算性能——就是马儿要能跑，要有很快的速度，最好是“日行千里，夜行八百”。对软件系统来讲，计算性能是用户最关心的一个指标，即软件系统有多快。比如，用户会关注软件系统执行一个典型的业务需要花多少时间。我们要给出用户答案，我们的系统完成用户典型操作，比如业务的交易计算，数据的增、删、改、查时间是不是在用户可以接受的范围内。

资源的利用和回收——就是马儿少吃草。软件系统的“草料”就是其依存的硬件和软件资源，硬件资源包括客户端硬件、服务器硬件和网络硬件；软件资源包括操作系统、中间件和数据库等。其中要特别说的是，运行软件系统需要使用到的服务器内存数量，对于整个系统的性能表现是至关重要的。因此，软件系统能否在运行时有效地使用和释放内存是我们考察软件性能的一个重要因素。

对计算机来讲，计算机内存为程序提供运行空间（有代码区和数据区），如果内存不够大，CPU就不能把全部的数据和程序放到内存里，只好放一部分在内存，一部分放在硬盘中，现用现取，而读取内存和读取硬盘数据的速度要差好几个数量级，这就大大影响了计算机的工作效率。如果还不能理解内存的重要性的话，可以用个形象的例子来说明：

如果CPU是个画家，那么内存就是他的工作台。工作台上放着画布（被操作的数据），还有各种画笔、刷子等各种工具（运行的程序）。如果工作台（内存）不能足够大，容纳不下绘画所使用的所有工具，那么画家就需要不时地去储藏室（硬盘等存储设备）里取所需的工具，这就会大大影响绘画的速度。

所以在评价一个系统性能的时候，要特别关注这个系统对内存的使用。

启动时间——这是马儿的加速度问题。用户希望系统进入正常工作状态的时间越短越好，尤其在主备系统中，软件的启动时间直接影响主备的切换效率。而不同软件系统启动时间会不同的。J2EE系统在第一次启动的时候一般会比较慢，因为期间涉及缓存的加载、JSP页面的编译、Java class编译成机器指令等。所以在第一次启动应用感到非常慢是比较正常的，这也是J2EE或者Java应用的一个特点。而C/C++程序直接运行的是二进制机器代码，启动速度就要快一些。

伸缩性——马儿要能快能慢。伸缩性是分析系统性能经常被忽略的一个方面。比如一个系统在50个并发用户访问的时候表现正常，但是当并发用户达到1000的时候，系统表现如何？服务器的性能是逐渐下降呢，还是在某个拐点附近急剧下降呢？

如图1-1所示，该图是一个伸缩性不好的系统的表现，随着并发用户的增加，平均相应时间越来越长。系统最终会达到一个不可用的程度，没有一个用户会接受系统这样的性能表现。

图1-1  伸缩性不好的用户 - 响应时间图

如图1-2所示就是一个伸缩性较好的系统的表现，随着并发用户的增加，平均响应时间逐渐稳定下来。

图1-2  伸缩性良好的用户 - 响应时间图

稳定性——千里马能够“路遥知马力”，而黑马只能够一时跑得快。用户希望自己的软件系统是千里马，而不是黑马。尤其是金融和电信系统，这些系统基本上都是每天24小时运转，时时刻刻准备着为用户提供服务。如果它们在运行一段时间后出现了问题，不能响应用户的请求甚至破坏或丢失了数据，那么系统为用户带来的损失是巨大的。这种稳定性问题应该在软件系统上线之前就被考虑并得到解决。

“快”、“好”这只是用户的主观体验，如果能让这些感觉和要求被其他人正确地理解（尤其是对软件人员），那么就需要用数据把上述用户的感受量化并表达出来，这就是性能指标。

通常，衡量一个软件系统性能的常见指标有：

1．响应时间（Response time）

响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里展现计时结束的这一段时间间隔，看起来很简单，但其实在这段响应时间内，软件系统在幕后经过了一系列的处理工作，贯穿了整个系统节点。根据“管辖区域”不同，响应时间可以细分为：

（1）服务器端响应时间，这个时间指的是服务器完成交易请求执行的时间，不包括客户端到服务器端的反应（请求和耗费在网络上的通信时间），这个服务器端响应时间可以度量服务器的处理能力。

（2）网络响应时间，这是网络硬件传输交易请求和交易结果所耗费的时间。

（3）客户端响应时间，这是客户端在构建请求和展现交易结果时所耗费的时间，对于普通的瘦客户端Web应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端Web应用来说，比如Java applet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是要注意的一个地方。

那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上（何为性能瓶颈，下一节中介绍）。

2．吞吐量（Throughput）

吞吐量是我们常见的一个软件性能指标，对于软件系统来说，“吞”进去的是请求，“吐”出来的是结果，而吞吐量反映的就是软件系统的“饭量”，也就是系统的处理能力，具体说来，就是指软件系统在每单位时间内能处理多少个事务/请求/单位数据等。但它的定义比较灵活，在不同的场景下有不同的诠释，比如数据库的吞吐量指的是单位时间内，不同SQL语句的执行数量；而网络的吞吐量指的是单位时间内在网络上传输的数据流量。吞吐量的大小由负载（如用户的数量）或行为方式来决定。举个例子，下载文件比浏览网页需要更高的网络吞吐量。

3．资源使用率（Resource utilization）

常见的资源有：CPU占用率、内存使用率、磁盘I/O、网络I/O。

我们将在Analysis结果分析一章中详细介绍如何理解和分析这些指标。

4．点击数（Hits per second）

点击数是衡量Web Server处理能力的一个很有用的指标。需要明确的是：点击数不是我们通常理解的用户鼠标点击次数，而是按照客户端向Web Server发起了多少次http请求计算的，一次鼠标可能触发多个http请求，这需要结合具体的Web系统实现来计算。

5．并发用户数（Concurrent users）

并发用户数用来度量服务器并发容量和同步协调能力。在客户端指一批用户同时执行一个操作。并发数反映了软件系统的并发处理能力，和吞吐量不同的是，它大多是占用套接字、句柄等操作系统资源。

另外，度量软件系统的性能指标还有系统恢复时间等，其实凡是用户有关资源和时间的要求都可以被视作性能指标，都可以作为软件系统的度量，而性能测试就是为了验证这些性能指标是否被满足。

1.1.5  软件人员眼里的软件性能

用户恨不能让软件有无限的性能，但作为软件技术人员，我们需清楚地认识到，那种理想化的要求是不可能的。在软件性能方案中，没有什么万能钥匙，软件性能方案充满了辩证的各种矛盾。每种方案和方法几乎都有利有弊。只有把握设计系统的具体环境，明确设计目标，具体问题具体分析，合理平衡各种矛盾，牢牢抓住主要矛盾，才能产生出优化的软件系统性能方案。

在上面的分析中，我们得知软件性能是软件运行空间和时间综合考虑的解决方案。那么其实满足用户的性能需求，只有以下几种方案：

1．消除软件对空间和时间不必要的浪费

一个最明显的例子就是内存泄漏问题，它被开发人员看做是大忌。

严格地说，内存泄漏应该属于软件程序设计的一种缺陷，该缺陷直接导致了程序在运行过程中无法释放不再需要的内存空间，从而造成内存资源浪费，严重的会造成无可用内存，导致系统崩溃。具体来说，当用户程序在运行过程中需要动态获得内存时，操作系统总是从堆（heap）上分配相应的空间给应用，分配的结果是将该堆内存的起始地址通过指针返回给应用。正常情况下，使用完这块内存后，应通过系统调用主动通知操作系统回收这些堆内存以便重用。但是，如果由于设计缺陷导致在某些情况下程序没有主动地通知到操作系统，而后应用又失去了对这块内存的引用时，则该堆内存块将成为既不受程序控制，又不能被系统回收重用的“孤儿”内存，这便是我们所指的内存泄漏。

 案例1

void foo( )

{

   char *str;

   str = (char*)malloc(32*sizeof(char));

   strcpy(str, "hello world");

   return;

  /* str所指向的32个字节的内存没有被释放，当foo()返回时造成内存泄漏 */

}

解决：C语言中malloc和free函数要配对使用。

 案例2

void foo()

{

//定义string1指针，其指向一个堆上的100个字节的内存空间

char *string1 = (char*)malloc(100*sizeof(char));

//定义string2指针，其指向一个堆上的200个字节的内存空间

char *string2 = (char*)malloc(200*sizeof(char));

scanf("%s", string2);

string1=string2;/*string1原先指向的100个字节的内存没有被释放*/

/*而后又被指向string2所指的内存块，造成前面100个字节的内存泄漏*/

free(string2);

free(string1); /* 这个free()调用会失败，因为string1指向的内存地址与string2的相同，而那块内存已经被释放了 */

return 0;

}

解决：在程序堆上分配内存后，要在使用完后及时释放，同时避免野指针的产生，比如string1。

原理：内存是软件运行的重要的空间资源，内存泄漏实际上是浪费了软件的空间资源。因此，内存泄漏对软件的性能影响十分重要。

另外，对于程序在时间上的浪费，我们通常是采用优化算法和数据结构的解决策略。

 案例3

最近几年，很多知名软件公司在招聘软件测试人员，考察代码能力的时候，内存泄露和算法优化是经常的试题之一。这说明了用户对软件性能的要求越来越严格，已经传递到了软件公司。

2．以空间换时间

软件的高性能并不是凭空产生的，在解决了空间和时间浪费的问题之后，如果用户还有更高的性能要求，我们软件人员只好“偷梁换柱”，做一下调整，而这种调整往往是很灵活的。

空间换时间是软件人员解决性能问题最常见的方法。是在系统功能正常的前提下增大软件空间开销的方法来缩减运行的时间。一般的方法有算法调整、并行计算方法、体系结构方法和一些不是“办法”的办法。

通常的解决方案有Cache缓存、数据库的index等。

 案例4

一个动态网站服务器总发生CPU耗尽的问题，因此造成给用户的响应缓慢或者长时间没有响应，进而引起Server的宕机。经调查分析，网站首页是个PHP程序，每次用户访问都要多次查询数据库，也没有Cache机制，数据库查询负荷过高，耗尽CPU。

解决：改写网站首页以及部分频繁访问的程序，增加Cache机制，减少数据库访问。

原理：将常用数据放在服务器的内存中，虽然增加了内存的开销，但带来了时间上的优化，对用户而言，提高了处理速度。

3．以时间换空间

时间换空间的方案解决性能问题的情形比较少。有时会出现在对内存要求十分苛刻的地方，比如嵌入式操作系统中。

 案例5

程序设计的要求是不设中间变量，交换两个变量的值。

我们通常的中间变量的解决方案是：

Void swapOne(int *a, int *b)

{

   Int temp;

   Temp = *a;

   *a = *b;

 *b= temp;

}

但这里需要在程序中为temp变量在栈上分配一个空间。可不可以不用这个temp变量呢？

解决：

修改程序如下：

void swapTwo(int *a,int *b)

{

*a=*a+*b;

*b=*a-*b; 

*a=*a-*b;

}

原理：修改之后，多了运算复杂度，但没有使用第三方变量，减少了空间的占用。

以上是我们从简单的程序例子来理解性能解决方案，但现实要远远复杂得多，因为随着软件系统功能的复杂强大，软件的规模也在不断扩大，我们不可能完全自己开发程序，很多时候是利用已有的平台和中间件资源。在这种场景下，我们应该怎样考虑性能问题呢？

第一，软件系统设计的架构及技术平台

软件在设计阶段一旦决定采用哪种架构和技术，其性能也就注定只能在一定的范围内变动了。这就是“先天”因素。比如在上节讲到的一个删除/增加数据的业务操作，如果用户对时间非常苛刻，密集型计算、在线的大数据量统计和分析等应用，这些场景通常J2EE不能够很好地解决，使用C++或者其他平台搭建会更合理些。如果在这些场景下硬要采用J2EE架构，那么开发和设计人员如何绞尽脑汁，优化设计和程序，也不会满足用户的性能要求。

第二，中间件的设置和优化

这里的中间件是广义的中间件，是应用程序调用的第三方软件，包括操作系统、数据库、Web服务器、消息服务器等。我们不能改变中间件的程序，只能通过调优手段来提高它所支持的软件系统的性能。

第三，硬件的配置

这里包括服务器硬件配置和网络环境。服务器硬件包括内存、CPU等，网络环境有交换机、路由器等。

1.2  软件性能测试

在上一节中，我们知道软件系统的性能问题多种多样，这给用户带来巨大的风险，那么我们如何能够在软件系统上线之前，找出软件中潜在的性能问题呢？目前软件性能测试是发现软件性能问题最有效的手段，而完备有效的性能测试是最关键的，在本节中我们将从流程和技术的角度解析如何构建一个高效的性能测试模型。

1.2.1  性能测试在软件测试的周期位置

首先，软件性能测试属于软件测试范畴，存在于软件测试的生命周期中。一个软件的生产过程通常遵循V型图，如图1-3所示。

图1-3  软件开发-测试V型图

在通常的软件生产周期中，先由用户提出用户需求或经系统分析核定以后提出系统需求，开发人员再经过需求分析提出软件需求规格说明，进行概要设计，提出概要设计说明，进行详细设计，提出详细设计说明，最后就是对每个模块进行编码。到测试阶段，测试按照开发过程逐阶段进行验证并分步实施，体现了从局部到整体、从低层到高层逐层验证系统的思想。对应软件开发过程，软件测试步骤分为代码审查、单元测试、集成测试、系统测试。

而性能测试就属于软件系统级测试，其最终目的是验证用户的性能需求是否达到，在这个目标下，性能测试还常常用来做：

（1）识别系统瓶颈和产生瓶颈的原因；

（2）最优化和调整平台的配置（包括硬件和软件）来达到最高的性能；

（3）判断一个新的模块是否对整个系统的性能有影响。

系统瓶颈：

瓶颈本来是指玻璃瓶中直径较小并影响流水速度的一段，用它来比喻软件系统中出现性能问题的节点是很形象的，比如一个典型的分布式系统架构如图1-4所示。

图1-4  软件系统压力流动图

如果把软件系统看做是交通系统，那么网络就是一条条大道，客户端、防火墙、负载均衡器、Web服务器、应用服务器（中间件）、数据库等各个系统节点就是交通要塞，客户的请求和数据就像在道路上行驶的车辆，如果在某处发生堵车，那么整个交通系统都会不畅。在这个时候，我们就要分析是哪里出了问题，是道路不够宽，还是某处立交桥设计不合理而引起堵塞等。找到问题的关键点，那么此关键点就是本系统的瓶颈。软件系统也是如此，我们做性能测试的大部分工作都是为了寻找这个瓶颈到底在何处。

需要注意的是，软件的性能瓶颈可能不止一处。

作为软件测试的一种，软件测试的规则同样适用于性能测试中：

（1）确定预期输出是测试必不可少的一部分

如果事先无法肯定预期的测试结果，往往会把看起来似是而非的东西当作正确结果。必须提倡用事先精确对应的输入和输出结果来详细检查所有的输出。对于性能测试来说，预期输出就是用户的性能需求，一份明确的性能需求是成功性能测试的先决条件。

（2）必须彻底检查每一个测试结果

事实上，在最终发现的错误，有相当一部分在前面的测试中已经暴露出来了，然而由于人们未能细心检查先前的测试结果而遗漏了。

一段程序中存在的错误概率与在这段程序中发现的错误数呈正比。

这是pareto原则应用于软件测试，也包括性能测试，即性能测试发现的错误中的80%很可能集中在20%的程序模块中。

（3）穷举测试是不可能的

在性能测试中不可能覆盖每一个功能部分，这也意味着有性能问题的模块可能被忽略掉，这样的话，我们在设计性能测试案例时，应该采取一些策略和技巧，使用尽可能少的性能测试用例，发现尽可能多的bug。这方面内容我们将在本书的第10章中介绍。

在具有软件测试共性的同时，性能测试也有自身的一些特点。

1．性能测试不是功能测试

性能测试不要求也无法做到覆盖软件所有的功能，通常我们只是对系统中某些功能或模块做性能测试。一般的，我们在选择性能测试案例时需要遵循以下的原则：

（1）基本且常用的

比如，一个E-mail系统，基本且常用的功能有注册、登录、收邮件、查询邮件，用户使用这些功能的频率较高，要做性能测试。而高级查询、过滤器、邮件列表等功能被使用的次数较少，就可以不做性能测试，或者进行性能测试的优先级低一些。

（2）对响应时间要求苛刻的

这样的要求经常出现在金融和电信等对实时性要求比较高的系统中。比如，从手机呼叫开始，经过基站、核心网，再到被叫手机响铃，整个系统的处理时间应该在用户能接受的范围内。另外，一个负责和手机通信的基站在发生故障或掉电后，要能很快地恢复工作状态。这些功能都对时间有着严格的要求，一定要做性能测试，当然实际运作时，电信系统上线时所做的性能测试不仅仅限于这些功能。

将这些功能细分就是性能测试中的事务（Transaction）。关于事务这个概念我们在后面的章节中将详细阐述。

2．性能测试属于系统级测试

从V型图可以看到，性能测试属于系统级测试。那么性能测试是基于单元测试、集成测试、功能测试等都已经完成的基础上，站在用户的角度去测试整个系统的。这包含两个含义：

第一，性能测试是“两头在外”，软件性能需求不仅直接来自用户，最终目的也是服务于用户。通过性能测试这个过程，从上面我们讲到用户的需求和性能测试指标的对应关系，就可以看出。

第二，性能测试开始的必要条件是软件系统已经处于一个比较稳定的状态，系统架构、主要代码、中间件等都不再有大的变化，否则会给性能测试带来很大的风险。

 思考

基于以上事实，我们应该在软件流程什么阶段开始性能测试？结合自己的实际工作进行分析。

1.2.2  性能测试策略揭秘

谈到“策略”，这是如今很火、使用较多的一个词。不光在IT领域，其他各个行业中也都有各种各样的策略，如营销策略、风险规避策略等。策略即谋略、手段、方法，表现为权宜的行动路线、指导原则或过程。

做事情讲策略，这是一种智慧，是人们聪明起来的表现，但当越来越多的策略“概念化”的时候，我们不得不去思考我们到底要达到什么样的目标，什么样的策略才是我们需要的。

 案例

引用网上一位哲人说的话：“概念只是为了方便人们理解和研究世界万物事物而制造的工具，而最终结果将使概念不再需要，就如同庄子所说的得意而忘言”。语言就是一种包装材料，它包装的是某种含义。因为人类传递信息必须使用语言，所以我们在研究的时候不得不借助于这种包装，但是当人的思维能力具备了打开包装直接取得内部的含义的时候，语言就变得多余了。这时候再关注于语言和概念本身就成了买椟还珠的现代版了。

因此，我们应该关注的不是概念本身，而是概念背后的含义。理解了含义，再冠予它什么样的名词头衔，如“攻略“，对于我们都无关紧要了。而理解一个概念，我们可以靠WWH方法，即对概念的三个问题：Why、What、How。

好，言归正传，回到软件性能测试策略中来。在性能测试过程中，只要有事情做，就会有策略，如设计用例有设计策略，执行时有执行策略，调优时还有调优策略。为了不产生混淆，我们要说明的是，在本节中讨论的策略是性能测试设计策略。

Why（为什么会有不同的策略）

在软件性能一节中，我们看到软件的性能来自软件对空间和时间的综合方案，这种组合是很多的，因此用户的软件性能需求可能会多种多样。对于软件人员，我们做性能测试也要因地制宜，根据不同的性能需求，选择不同的测试策略。

What（什么是性能测试设计策略）

验证性能需求是测试目的，测试策略即已经被证明是行之有效的测试方法。

How（怎样实施）

常见的性能测试方法有以下几种：

1．负载测试

在这里，负载测试指的是最常见的验证一般性能需求而进行的性能测试，在上面我们提到了用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解：

（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。

（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。

2．压力测试

压力测试是为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。

例子：负载测试关心的是用户规则和需求，压力测试关心的是软件系统本身。对于它们的区别，我们可以用华山论剑的例子来更加形象地描述一下。如果把郭靖看做被测试对象，那么压力测试就像是郭靖和已经走火入魔的欧阳峰过招，欧阳锋蛮打乱来，毫无套路，尽可能地去打倒对方。郭靖要能应对住，并且不能丢进小命。而常规性能测试就好比郭靖和黄药师、洪七公三人约定，只要郭靖能分别接两位高手一百招，郭靖就算胜。至于三百招后哪怕郭靖会输掉那也不用管了。他只要能做到接下一百招，就算通过。

 思考

我们在做软件压力测试时，往往要增加比负载测试更多的并发用户和交易，这是为什么？

3．并发测试

验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。

4．基准测试

当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。

5．稳定性测试

“路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。

6．可恢复测试

测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。

每种测试有其存在的空间和目的。当我们接手一个软件项目后，在有限的资源条件下，选择去做哪一种测试，这应该根据当前软件过程阶段和项目的本身特点来做选择。比如，在集成测试的时候要做基准测试，在软件产品每个发布点要做性能测试。

1.3  如何做性能测试

一个项目要取得成功是困难的，因为成功的项目需要多个因素和条件来支持；而一个项目失败却很容易，只要若干因素之中的一个出现问题，就有可能导致项目失败。比如中途测试人员发生变化，性能指标未和用户达成统一理解等。笔者还曾看过一个例子，因为测试报告的格式与用户要求的格式不一致，而不得不重新再执行一次所有的性能场景，来采集用户要的数据。

实际上，当我们做过的性能测试项目越多，就会发现越多的因素可能会影响性能测试项目的成败，甚至可以是千奇百怪的。

在本节中，我们主要是寻找出不同性能测试项目的共性，而总结出一个具有普遍意义的性能测试过程。遵循过程做性能测试，在大多数情况下可以有效地规避风险，并能取得比较好的性能测试结果。这当然不是意味着我们有了这个过程，就不考虑其他因素了，只是说每个项目都会有自己的独特因素要考虑，尽管这些因素可能很重要，但它们并不在本节的讨论范围内。

在给出此过程模型之前，我们要澄清两点事实：

第一，性能测试过程从何时开始，又在何时结束？

这是一个基本而重要的问题。

在各种书籍和资料中，有关性能测试过程的描述不尽一样：

比如LoadRunner手册中提供的过程是：计划测试→测试设计→创建VU脚本→创建测试场景→运行测试场景→分析结果。

而在Segue中提供的性能测试过程，是一个try-check过程，即：评估需求→开发测试→建立基线→执行测试→分析结果→回归测试→测试结束。

上面LoadRunner和Segue描述各自的性能测试过程最大的区别不在于工具部分，而是在于两者过程的入口和出口条件不一致。这使得它们其实在描述两件事情，或者说是在描述一个事情的两个部分。

在CMM中，软件测试和软件设计、编码一样，隶属于软件工程过程，而需求分析过程在软件工程过程之前。这就隐含着一个默认的先决条件：在CMM这个体系下，产品在进入软件测试阶段的时候，软件需求是已经明确下来并文档化了的。

实际情况却经常并非如此，同样是软件需求，软件功能需求在进入测试阶段就已经产生了各种文档，包括需求文档和设计文档，确保功能需求是详细、明确、无二义性的；而软件性能需求往往进入了性能测试阶段还不明确（可参见Controller一章开篇的例子）。这会给性能测试项目带来很大的风险。

因此，我们应该突破已有的理论束缚，寻找更合适的性能测试过程模型。经过对多个性能测试项目的实践经验总结，我们在本节提出GAME（A）性能测试过程模型，其开始于软件需求分析阶段，非常符合目前国内的性能测试实践。

第二，性能测试本身有没有质量？

以前我们总是讨论软件产品的质量、开发代码的质量，但对软件测试的质量却鲜有提及。我们知道“一个好的测试用例是发现了一个原先未发现的bug”，这其实是对用例质量的度量。软件性能测试项目也有质量，并可以度量。下面是部分度量的方法：

（1）性能测试耗费的资源，包括时间、人力、物力。

（2）性能测试中发现的bug数目，以及各自的级别。

（3）软件系统交付用户，在生产环境运行后发现的性能bug数目、级别。

而一个好的性能测试过程模型对提高性能测试质量是很有帮助的。

GAME（A）性能测试过程模型：

Ÿ G：Goal，目标

Ÿ A：Analysis，分析

Ÿ M：Metrics，度量

Ÿ E：Execution，执行

Ÿ （A）：Adjust，调整。E执行失败后才进入A阶段，并且涉及的大多是有关开发和系统管理工作，因此A设为隐式。

性能测试过程模型如图1-5所示。

图1-5  性能测试GAME(A)模型

1.3.1  Goal（定义目标）

制定一个明确而详细的测试目标是性能测试开始的第一步，也是性能测试成功的关键。

本步骤的开始时间：需求获取阶段

本步骤的输入：性能需求意向

本步骤的输出：明确的性能测试目标和性能测试策略

常规的性能测试目标有以下几种：

（1）度量最终用户响应时间

查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设我们想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。图1-6显示了一个银行应用程序的负载和响应时间度量之间的关系。

图1-6  用户数-响应时间关系图

（2）定义最优的硬件配置

检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，您可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。

例如，您可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异：

Ÿ 配置1：1.2GHz、1GB RAM

Ÿ 配置2：1.2GHz、2GB RAM

Ÿ 配置3：2.4GHz、1GB RAM

（3）检查可靠性

确定系统在连续的高工作负载下的稳定性级别。强制系统在短时间内处理大量任务，以模拟系统在数周或数月的时间内通常会遇到的活动类型。

（4）查看硬件或软件升级

执行回归测试，以便对新旧版本的硬件或软件进行比较。您可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。注意：此回归测试的目的不是验证升级版的新功能，而是查看新版本的效率和可靠性是否与旧版本相同。

（5）确定瓶颈

您可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。将LoadRunner与新的网络和计算机监视工具结合使用以生成负载，并度量系统中不同点的性能，最终找出瓶颈所在的位置。

（6）度量系统容量

度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。如图1-7所示，要查看容量，您可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。

图1-7  用户数-响应时间拐点图

我们根据不同的测试目标去选择合适的性能测试设计策略。比如，“度量最终用户响应时间”可以采用负载测试策略，“检查可靠性”就可以用压力测试策略，等等。

1.3.2  Analysis（分析）

本步骤的开始时间：需求分析阶段和性能测试启动阶段

本步骤的输入：性能需求

本步骤的输出：达成一致的性能指标列表，性能测试案例文档

1．分析性能需求

在这里，要定义性能测试的内容，细化性能需求。

客户、需求分析人员和测试工程师一起起草一个性能需求标准，对此标准获得一致认同。此标准将用户的需求细化、量化，并能在测试中作为判断依据。

比如，对于负载测试来说，可以从以下角度来细化需求，逐步找出测试关键点。

测试的对象是什么，例如“被测系统中有负载压力需求的功能点包括哪些？”；“测试中需要模拟哪些部门用户产生的负载压力？”等问题。

系统配置如何，例如“预计有多少用户并发访问？”；“用户客户端的配置如何？”；“使用什么样的数据库”；“服务器怎样和客户端通信？”。

应用系统的使用模式是什么，例如“使用在什么时间达到高峰期？”；“用户使用该系统是采用B/S运行模式吗？”；“网络设备的吞吐能力如何，每个环节承受多少并发用户？”等问题。

最后得出的性能测试指标标准至少要包含测试环境、业务规则、期望响应时间等。

2．分析系统架构

对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。结合性能测试指标标准，生成性能测试用例。（可参看第10章“进阶LoadRunner高手”的用例设计部分。）

1.3.3  Metrics（度量）

本步骤的开始时间：性能测试设计阶段

本步骤的输入：细化的性能指标和性能测试案例

本步骤的输出：和工具相关的场景度量、交易度量、监控器度量和虚拟用户度量等

度量是非常重要的一步，它把性能测试本身量化。这个量化的过程因测试工具的不同而异。

（1）场景的定义，pass/fail的标准

测试场景包含了性能测试的宏观信息，有测试环境、运行规则和监控数据等。具体可表现为历史数据记录数、虚拟用户数、虚拟用户加载方式、监控指标等。

（2）事务（Transaction）的定义，pass/fail的标准

事务用来度量服务器的处理能力。事务定义应该从性能指标标准而来，是性能指标的具体体现。事务的定义是很重要的，不同的定义会导致不同的TPS结果。

使用性能测试工具执行性能测试之后，我们能看到的是pass/fail的用户数、pass/fail的事务数。而这些pass/fail的标准应该在执行性能测试之前就应该被定义好。比如，LoadRunner默认的pass/fail标准是基于协议层的，而我们要的pass/fail可能是业务级的，需要在业务层上进行判断来决定是pass还是fail。另外，还可能由于案例的关联性引起的pass/fail，如果两个案例之间有关联，A脚本负责向数据库插入数据，B脚本负责查询数据，A要是fail了，导致B也会fail，虽然B本身不一定有错。解决这个问题，一方面可以削弱脚本之间的关联性，另一方面也可以通过增强脚本的健壮性来达到。

（3）虚拟用户pass/fail的标准

虚拟用户是性能测试工具中的一个普遍的概念，虚拟用户负责执行性能测试脚本，在这里应该定义虚拟用户遇到何种情况，选择fail或pass，即退出或通过。

1.3.4  Execution（执行）

本步骤的开始时间：软件测试执行阶段

本步骤的输入：场景、交易、虚拟用户等设置信息

本步骤的输出：测试报告

执行测试包含两个工作：

1．准备测试环境、数据和脚本

测试环境：硬件平台和软件平台。

测试数据：包括初始测试数据和测试用例数据两部分。表现为SQL脚本、Excel文件等。

测试环境直接影响测试效果，所有的测试结果都是在一定软硬件环境约束下的结果，测试环境不同，测试结果可能会有所不同。需要注意：如果是完全真实的应用运行环境，要尽可能降低测试对现有业务的影响；如果是建立近似的真实环境，要首先达到服务器、数据库以及中间件的真实，并且要具备一定的数据量，客户端可以次要考虑。实施负载压力测试时，需要运行系统相关业务，这时需要一些数据支持才可运行业务，这部分数据即为初始测试数据。有时为了模拟不同的虚拟用户的真实负载，需要将一部分业务数据参数化，这部分数据为测试用例数据。

测试脚本：用性能测试工具生成脚本。

2．运行场景和监控性能

运行性能测试场景，并监控设定好的数据指标，最终生成测试报告。按照定义好的场景pass/fail标准来判断性能测试是否通过。如果未能通过，进入步骤5（Adjust）。

1.3.5  Adjust（调整）

本步骤的开始时间：第一轮性能测试结束后，而且没有通过的条件下

本步骤的输入：测试报告和测试结果数据

本步骤的输出：性能问题解决方案

调整包含两个意思：应用程序修改和中间件调优。

中间件调优可考虑如下因素操作系统调优：

Ÿ 数据库调优；

Ÿ 内存升级；

Ÿ CPU数量；

Ÿ 代码调优；

Ÿ Cache调优。

解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。

系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过度使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过度使用会造成大量进程等待CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销）。

从以上内容可以看出，目前GAME（A）模型有两个优势：第一，灵活，每个过程都有自己的关注点，可以根据不同的项目特点增加或删除关注点；第二，通用，不依赖于具体的工具。目前GAME（A）关注性能测试技术，比较简单，将来可以进行扩展，同样使用GAME（A）模型关注性能测试的时间、人力等资源问题。

1.4  性能测试工具的评估和选择

我们可以看到，性能测试和一般功能测试不同的是，性能测试的执行是基本功能的重复和并发，因此我们在性能开始之前需要模拟多用户，在性能测试进行时要监控指标参数，同时性能测试的结果不是那么显而易见，需要对数据进行分析。这些特点决定了性能测试更适合通过工具来完成。市场上涌现出越来越多的压力自动化测试工具，古人云“工欲善其事，必先利其器”，一个测试工具能否满足测试需求，能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。

我们这里讨论的主要是一些比较成熟的性能测试软件产品，都已经在市场上占有了一定的份额，得到了用户的认可。

如表1-1所示为主要的性能自动化测试工具。

表1-1  主要的性能自动化测试工具

对于测试人员来说，要么自己开发性能测试工具，要么选择购买市场上已有的性能测试工具。在这里，我们要讨论的只是在选择性能测试工具时，需要考虑哪些因素。这些因素都想清楚了，然后才可以做决定。

1.4.1  测试预算VS工具价格

性能测试的成本与收益比是选择性能测试工具的根本条件。这其实是在考虑“要不要用”的问题。如果购买一套价格几十万的性能测试工具只是为了去做一个几万元预算的性能测试项目，那么无论这个工具再强大，也不会被采用。

1.4.2  协议、开发技术、平台、中间件VS工具的支持

要确定性能测试工具是否支持我们的被测软件系统，这其实是在考虑“能不能用”的问题。考虑因素有被测软件系统使用的协议、采用的技术、基于的平台、调用的中间件。这些都需要性能测试工具有效的支持。

1.4.3  工具可使用的复杂程度VS项目计划的影响

熟悉并使用一个性能测试工具，是需要花费人力和时间等资源的，项目计划中要有相应的资源准备。这其实是在弄清“如何用”的问题。