谈谈性能测试的必要性

说起为什么要进行性能测试，前面已经多少谈到一些。下面，从“性能测试与功能测试关系”及“性能自动化测试优势”两方面给读者作答。

1. 性能测试与功能测试关系

       性能测试和功能测试是测试工作中两个不同的方面，只是在关注的内容上有差异而已。前者侧重“性能”而后者侧重“功能”。但殊途同归，它们的最终目的都是为了提高软件质量，以更好地满足用户需求。

    “功能”指的是在一般条件下，软件系统能够为用户做什么以及能够满足用户什么样的需求。比如一个论坛网站，用户期望这个网站能够提供浏览帖子、发布帖子、回复帖子等功能，则只有这些功能都正确实现了，用户才认为满足了他们的功能需求。但是，一个论坛除了满足用户的“功能”需求之外，还必须满足“性能”需求。比如：服务器需要能够及时处理大量用户的同时访问请求；服务器程序不能出现死机情况；不能让用户等待“很久”才打开想要的页面；数据库必须能够支持大量数据的存储以实现对大量的发帖和回帖数据的保存；论坛一天24小时都可能有用户访问，夜间也不能停止休息，它必须承受长时间的运转；等等。

       从上面的描述来看，软件系统“能不能工作”已经是一个基本的要求，而能够“又好又快地工作”才是用户追求的目标。“好”体现在降低用户硬件资源成本，减少用户硬件方面的支出上；“快”体现在系统反应速度上，用户在进行了某项操作后能很快得到系统的响应，避免了用户时间的浪费。这些“好、快”的改进都体现在软件性能上。换言之，“性能”就是在空间和时间资源有限的条件下，系统的工作情况。

        综上，功能考虑的是软件“能做什么”的问题；而性能关注的是软件所完成的工作“做得如何”的问题。显然，软件性能的实现是建立在功能实现的基础之上的，只有“能做”才能考虑“做的如何”。

        在了解功能和性能的区别之后，再理解功能测试和性能测试就很容易了。功能测试主要针对于软件功能开展检测，常常会依据需求规格说明书开展测试；性能测试主要针对于系统性能进行检测，通常会依据性能方面的一些指标或需求进行测试（对于如何获取性能需求请参考1.6小节）。性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，发现软件系统中存在的性能瓶颈以优化软件和系统。在理论上来讲，功能测试和性能测试没有先后顺序，都是系统测试的一部分。测试过程中，要随时注意性能方面的检测。但在很多企业的实际测试工作中，一般会先进行功能测试。所测软件在功能上不存在严重问题且其流程能够“跑通”之后再对它做性能测试。正如前面所说，任何一个产品首先要保证其最基本功能的实现，否则，其性能即使再好也失去了存在的意义。

2. 性能自动化测试优势

          性能测试可通过“手工”和“自动化”（自动化测试需要借助于自动化测试工具）两种测试手段实现。相比于“性能手工测试”而言，“性能自动测试”具有诸多优势。下面，首先阐述“性能手工测试的弊端”以使读者认识到引入自动化测试（或说学习自动化测试工具和方法）的必要性。

1. 性能手工测试弊端

         通过一个例子加以说明。假设要测试一个Web系统的性能，验证其是否能支持50个用户的并发访问，如图1.1所示。下面，采用“手工”方式实现这一测试需求。

        1）首先，准备足够的资源：50名测试人员，每人有一台电脑以进行操作支持。

        2）其次，准备一名“嗓音足够大”的指挥人员统一发布号令以调度测试人员对系统进行同步测试。每位参与测试的人员需要注意力集中，在听到指挥员“开始测试”的号令后进行“理论上的同时”操作（每个人反应速度不好控制，所以为理论上的“同时”）。

        3）再次，在50个测试人员“同时”执行操作后，对每台电脑上的测试数据和服务器中的测试数据进行搜集和整理。

        4）最后，在缺陷被修复后，要开展回归测试（是指在发生修改之后重新测试先前的测试以保证修改的正确性）。即需要再执行1~4步直到满足性能需求为止。

        不难看出，“手工”测试需求的人力量很大（上面只是假设了50个并发访问的情况，如果是5 万个呢，难道要准备5万个测试人员？）。此外，支持“理论上的同时”访问并不是真正想要的性能，我们需要的是“真正意义上的”并发访问。再者，回归测试往往需要在相同的“场景”下进行，在手工测试下，根本不可能“再现”上一次的测试场景。也就是说，第4步中的回归测试也不是真正意义上的回归测试。

         总归一句话，“性能手工测试”弊病诸多。

图1.1 性能手工测试弊端

2. 性能自动化测试优势

         性能自动化测试工具可轻松化解性能手工测试中暴露出来的一系列问题，如图1.2所示。其解决的方式如下。

         1）准备好性能测试工具和一台机器，而无需号召至少50个测试人员协助测试和50台机器。性能自动化测试工具能“虚拟”出任意多个用户（这些虚拟用户不会在工作中带上个人情绪和疲劳的状态），该工具可以在一台测试机上“模拟”出50个用户的同时访问。显然，相比于“手工测试”，自动化测试节省了大量的硬件资源和人力资源。

         2）无需指挥人员发布号令进行调度和同步测试用户，自动化工具可以帮助我们自动控制虚拟用户的运行与同步，实现严格意义上的并发操作。

         3）测试完毕后，工具将自动收集测试数据并分析测试结果而无需逐一收集各台机器（含服务器）上的测试数据和结果。

         4）测试完毕并缺陷被修复后，要开展回归测试。此时，只需要重新运行上一次测试操作的“录制”脚本即可，上一次的测试情景将立刻重现。可对两次测试结果进行自动比较，分析其中的不同之处。

        性能自动化测试工具能帮助测试人员模拟出很多真实复杂的业务场景，能够让系统持续运行几天几夜甚至更久的时间，还能捕捉到很多难以捕获的结果等，这些都是手工测试所不能完成的。

图1.2 性能自动化测试优势

          尽管读者对上面的描述可能还不尽理解，但有一点，读者是肯定理解了的，即：性能自动化测试值得我们推广和采用。

3. 性能测试定义与要点

        对性能测试的定义，仁者见仁，智者见智。尽管定义很多，但它们的核心内容是保持一致的。较常见的关于性能测试的定义如下：性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

       上述定义主要包含了3层含义：

       1）通常，性能测试需要借助工具实现。与功能测试主要借助手工开展不同，性能测试一定要借助工具来协助完成。

       2）性能测试除了关注普通的正常情况外（如：单用户短时间操作），还重点关注空间和时间上的很多峰值或异常的系统运行情况，如：多用户并发操作、大数据量积累、超负载运行、系统长期持续使用等情况，而这些情况下更容易暴露系统的性能问题。

       3）性能测试借助所监控和收集的各项指标来分析系统的性能。指标的范围很广阔，涵盖了系统软件指标（程序自身）和硬件指标（客户端性能指标、网络性能指标、服务器端性能指标）。它不仅关注程序性能，还要考虑数据库性能，同时也兼顾程序运行期间客户端、服务器（应用服务器、数据库服务器等）各项系统资源运行情况，如：CPU使用率、内存及磁盘使用情况等。

      上述定义强调了性能测试的很多重要信息。但是，仅依靠上述性能测试的定义来理解性能测试还是远远不够的。下面，我们再给读者补充一些性能测试的要点及其分析。

1. 性能测试通常在功能测试基本完成后进行。该要点主要强调性能测试开展的时间问题。虽然总是强调功能测试和性能测试同等重要，应同时开展。但在大多数实际工作中，性能测试的开展会滞后于功能测试。其原因主要在于性能测试属于综合性测试，只有在功能测试通过后，性能测试才会有较大意义。但是对于两类软件存在例外，其性能测试一般进行的较早，几乎伴随着单元测试同步进行。第一类是系统软件，如：操作系统或者数据库。这类软件的性能测试就需要尽早开展，否则在最后阶段发现性能问题的话，则很有可能导致整个系统被推翻。第二类是对性能要求较高的应用软件，如奥运会、银行、联通的系统，这类软件对性能的要求远高于一般软件，倘若在最后测试时发现性能问题，通常是系统架构或者某些关键算法设计不合理所导致，这时候再进行修复的话也会给整个项目带来很大的困扰，甚至也会推翻整个系统。
2. 性能测试计划、测试方案和测试用例大多情况统一在一个文档里。很多企业会将性能测试相关的内容作为一个“性能测试方案文档”专门编写，里面会涵盖了性能测试的场景设计、测试脚本、测试结果分析等，这样可以作为一个整体提供给其他部门或客户。
3. 性能测试环境应尽可能同用户生产环境保持一致。该条规则十分重要，直接影响着性能测试结果的真实性和有效性。强调测试环境的一致性主要从以下方面考虑：1）硬件环境，包括：客户端、服务器和网络三方面的环境要求。如：客户端系统硬件配置、服务器的各项配置、是否和其它应用程序进行资源共享、是否在集群环境下、是否进行负载均衡、网络速度等。2）软件环境，包括：软件版本、参数设置方面的一致性要求。如：操作系统或数据库的版本、被测的应用软件的版本以及使用到的第三方软件的版本、数据库的并发读写数、SGA/PGA设置、连接池参数设置等。3）测试使用场景的一致性。如：使用的基础数据、模拟用户真实使用场景的一致性等。
4. 性能测试工作的重点和难点在于前期数据设计和后期数据分析。这条规则强调千万不要认为借助工具可以代替我们做所有的测试工作。工具的使用很简单，但是前期的用例设计、场景分析需要花大量功夫去研究。工具帮助我们收集了大量的测试数据之后，重中之重的一项工作就是对数据进行分析，确定系统瓶颈所在，这一部分工作往往需要测试工程师具备丰富的项目经验和扎实的技术功底。
5. 性能测试用例通常基于系统整体架构进行设计，往往具备高复用性。通常不随系统某个功能点的修改而变更。但当系统发生较大变动（如系统业务流程修改）后，建议读者重新设计性能测试用例。