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)

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

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