5.1.2 不同阶段的性能测试
对应于软件生命周期的不同阶段，性能测试可以分为单元性能测试、集成性能测试、系统性能测试、多系统性能测试以及容量评估；另外还有一类比较特殊的性能测试。接口性能测试，它可能存在于软件生命周期的几个阶段中，而从测试方法上来说，接口性能测试又部分与单元性能测试相似，但又有其特有的一些测试方法。无论如何，接口性能测试是重要而不可缺少的。
1．单元性能测试。在把软件的独立单元提交到集成阶段之前，对其进行的性能测试称之为单元性能测试。单元性能测试的对象是软件的独立单元，这在C这样的语言中是函数或子过程，而在C++、Java这类面向对象的语言中则是类或者类的方法。通常单元性能测试需要借助于各种工具，也可以结合单元测试框架来做，形成一个统一的过程。当然，也可以不借助任何工具，但是这意味着必须自己写代码以完成单元性能测试，这样的代价是很高昂的。这种测试主要用来发现被测单元在执行耗时、多线程并发、内存使用等方面存在的问题，以保证被测单元本身的性能，从而降低软件系统存在性能问题的风险，并有效减少后期性能调优的工作量。同时，对于算法的选择、第三方组件的选择等，单元性能测试也是一个重要的手段。
2．集成性能测试。在软件的独立单元通过单元测试（包括功能与性能测试），被认为可以满足要求，而被集成到一个应用中后，这阶段对集成后的应用所进行的性能测试即为集成性能测试。针对不同的集成策略，集成性能测试可能是一个反复迭代的过程（对应于增量式集成策略），也可能是一个一次性的过程（对应于一次性集成策略）。这种测试的目的不是分析应用是否能满足预期的业务目标，而是为了发现应用的问题（要发现的问题与单元测试类似，执行耗时、多线程并发、内存使用等），确定不同的组件是否可以一起发挥作用。集成性能测试的结果是能否进行系统性能测试的一个重要依据。
3．系统性能测试。这是人们最为熟悉的一种性能测试，通常性能测试指的都是这种测试。这个阶段软件系统已经经过确认，并仿照生产环境的方式进行部署，包括硬件系统、操作系统、网络、中间件，等等，然后根据计划的用户量（上线后将最终支持的用户量），使用虚拟用户发送各种服务请求来模拟真实用户使用软件系统，分析应用是否能满足预期的业务目标，识别性能瓶颈（可能是代码问题、硬件问题、网络问题、操作系统问题、中间件配置问题，等等），并进行性能优化。注意这阶段的测试对象已经不仅仅是所开发的软件了，而是包括软件、硬件、网络、操作系统、中间件等，即整个计算机系统中的所有元素。对于这点不少人存在误解，认为性能测试仅仅是测试程序的性能，性能优化只是对代码进行优化，这是不完全的。
4．多系统性能测试。多系统性能测试分为两种情况。
由于硬件和软件License都是很昂贵的，很多情况下不得不将多个应用部署在一个共享的环境中，这意味着即使经过系统性能测试，也可能因为各个应用对共享资源（例如堆、线程池、JDBC连接池等）的竞争，而产生性能问题。特别是当添加一个新的应用到原有的共享环境中时，可能需要调整原有的共享环境，并进行性能测试，以确保添加了新的应用后，原有应用的性能不会下降。
在软件互联已经成为一种趋势的今天，多个异构系统共享某些公共服务已经越来越常见，各个系统之间必然存在对公共服务的竞争。当然公共服务本身的性能测试是需要做的，但是这并不能完全保证各系统对公共服务的竞争不会产生问题；比较严谨的做法是，尽可能地模拟真实情况进行多系统性能测试。
5．容量评估。在进行容量评估之前，需要做一些准备工作，包括了解用户的操作以及操作的百分比、期望支持的并发用户数量、关键服务的SLA（服务品质保障，对提交的各种服务品质作出规定，例如单封邮件发送延迟最多不超过10分钟）、系统资源利用率监测等。掌握了所有这些数据以后，逐步对系统增加负载，在将负载增加到期望负载的过程中，采集服务请求的响应情况并基于它们的SLA进行评价。
当达到期望负载后，根据定好的粒度每次增加一定量的用户（比如每次增加10个用户），直到服务请求的响应情况无法满足它的SLA。此时，应缩小粒度进一步观察服务请求的响应情况并做好记录，同时在整个过程中应一直监测系统的资源利用率，最后根据测试记录的结果得到系统的饱和点。容量评估的目的就是找到饱和点在哪，并且通过扩容或采用新的架构，来保证永远不会达到饱和点。
6．接口性能测试。接口的种类有很多，第4章中介绍的Web Service接口就是目前广泛使用的一种接口。由于很多时候接口都是先开发出来，预备以后供其他系统调用，因此有必要对接口的性能进行专门的测试。不同类型的接口可能需要使用不同的测试工具来进行测试。接口性能测试是比较特殊的，从使用的测试工具和测试的方法来说，接口性能测试更接近单元性能测试，然而接口性能测试的目的是通过模拟外部系统调用接口，来分析接口的性能是否能满足预期的业务目标，这一点又跟系统性能测试相似。实际上，接口性能测试具有前面5种性能测试的特点，可以认为接口就是一类软件，只是这类软件的使用方法比较特别，没有GUI可以使用，需要自己编写代码来使用。
5.2 单元性能测试基本概念
前面已经简单介绍了单元性能测试主要做什么，接下来就将进入本章的核心，在此之前，先阐述一下单元性能测试的一些基本概念。
5.2.1 为什么要开展单元性能测试
性能优化是一项烦琐而复杂的工作。在这个过程中，可能需要根据性能测试的结果调整大量的参数，修改代码，然后再次运行测试，根据测试的结果再重复这些工作。有时候可能需要运行很多次测试，才能定位到一个性能问题的真正所在，而解决一个性能问题往往会暴露出更多的性能问题。传统的性能测试（即前文提到的系统性能测试，后文如无特别说明也均指系统性能测试）以及相应的性能优化工作更多的时候让人们感到很痛苦，为了解决一个性能问题往往要花费一天、一周甚至于数周的时间，这一点从事过性能测试和性能优化的人应该都深有体会。
既然传统的性能测试和性能优化让人们如此痛苦，那么当然有必要改进传统的性能测试，让性能问题能更快更方便地被定位，使得性能优化工作变得更容易。这个目标是很显然的，但是关键在于应该如何来改进，才能实现这个目标？熟悉软件测试基本理论的人都知道，软件功能缺陷越早被发现，其解决的成本就越低，每经过一个阶段，解决缺陷的成本大约会增加10倍。
缺陷越早被发现越容易解决，这点同样适用于性能问题。当测试人员能在单元测试时发现性能问题，很可能只需要几分钟就能定位到问题所在，因为问题肯定在所测的单元内，而一个被测单元的规模跟整个系统的规模显然是有天壤之别的，然后可能很快就能解决性能问题。而这样的性能问题如果一直留到系统测试阶段，通过传统的性能测试，无法直接找到问题，因为这时只能根据测试结果，凭经验去推断、去猜测问题究竟在哪，然后就是不知何时才会结束的性能优化。
这道理似乎是很简单的，然而以往在单元测试时人们通常只关注被测单元的功能是否正确，很少有人会去关注被测单元是否存在性能问题。导致这一问题的一个可能的原因是，人们不清楚应该如何去测试单元的性能，也不清楚哪些性能问题是能够在单元测试时被发现的，因为对于被测单元来说，缺乏明显的性能指标。性能指标通常来源于预期的业务目标，以及所承诺的SLA。这些宏观的指标对于被测单元来说基本是没有意义的，也很难将系统的性能指标分解成单元的性能指标。
这就需要换一种角度来思考。根据性能优化的经验可以知道，系统在宏观上表现出来的性能问题，追本溯源到单元时，这个问题的表现是什么。例如系统存在内存泄漏，通常是由于单元中的对象在被使用完后，由于疏忽而被留在堆中，一般称这样的对象为游离对象。那么这就成为一个单元性能测试的性能指标，即所有被测单元在测试完成后，不能产生游离对象。通过这样的思考，可以得到一系列单元的性能指标。有了单元的性能指标，在单元测试过程中，就可以发现一部分性能问题，并以较低的成本解决。当然，单元性能测试不可能发现所有的性能问题，但它确实能有效帮助减少系统测试阶段性能优化的工作量。
另一个进行单元性能测试的理由是，它能帮助挑选适合于所开发系统的第三方组件。现在是一个开源的时代，很多时候让人们感到苦恼的不是找不到第三方组件来提供所需要的功能，而是如何从几个提供相同功能的第三方组件中挑选最适合于所开发系统的。既然功能上都能满足需求，那自然是通过比较性能来决定选用哪个。不同的组件可能在不同的数量级下会有不同的性能表现，而挑选第三方组件者要做的是，根据预期的业务目标，得到所开发系统的数量级，在此数量级下对不同的组件进行单元性能测试，找出性能最好的那个。更全面的做法是，通过测试得到不同组件在不同数量级下的性能曲线，也即了解了不同组件的性能特性，再根据系统的特点选用最合适的组件。当然，如果测试的结果是所有的第三方组件都不能满足系统的性能需求，那么就自己写一个。同样地，对于关键算法的选择也可以采用这种策略。
本文选自：《51Testing软件测试作品系列》之三的《互联网单元测试及实践》 ，本站经电子工业出版社和作者的授权，近期将进行部分章节的连载，敬请期待！
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
