下面我们主要介绍性能测试、负载测试和压力测试。
效率作为ISO 9126内部和外部质量的重要质量属性之一，其含义是在规定条件下，相对于所用的资源的数量，软件产品可提供适当性能的能力。资源可能包括其他软件产品或系统的软件和硬件配置，以及其他相关的资源（例如：打印纸、磁盘等）。
效率测试主要关注产品的时间和资源相关的特性。时间相关的特性是指在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐量的能力，例如：用户打开某个网页需要等待的时间；资源相关的特性是指，在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力，例如：用户在进行相关操作时，系统的内存和CPU的变化情况。
根据产品的时间特性和资源特性，效率测试可以包括不同的测试类型，例如：性能测试（Performance Test）、负载测试（Load Test）和压力测试（Stress Test）。这三种效率测试类型，不仅在具体定义上面有不同的侧重点，同时相互之间又是密切关联的。
1）性能测试
性能测试主要评价系统或组件的性能是否和具体的性能需求一致，例如：对访问速度的性能需求或对内存使用情况的需求。特定性能测试的关注点在于组件或系统在规定的时间内和特定的条件下响应用户或系统输入的能力。
不同的性能的度量方法取决于不同的被测对象。对于一个单独软件组件，其性能可以根据CPU主频来判定。而带客户端的系统，其性能则要根据系统处理特定用户请求的响应时间来判定。对于那些由多种组件（如客户端、服务器、数据库）构成的系统，则要进行各组件之间的性能测试。
产品的性能对用户是否会持续使用该产品影响很大。表1所示是一个用户对访问一个独立页面时等待不同时间的态度分布。可以看到，当页面加载时间在10秒的时候，有84%的用户愿意等待；但是当页面加载时间达到30秒的时候，只有5%的用户愿意等待。
表1 用户愿意等待时间分布
表1中的数据考虑了网络的延迟。而如果在测试环境中，整个网络是被测试系统所独占的时候，对系统性能的要求要高的多。对于愿意等待的时间，每个用户的承受范围是不同，而且用户对不同的应用程序愿意接受的等待时间也是不一样的。下面是一组关于响应时间的性能需求描述：
- 对于多媒体交互系统，在90%的时间内系统响应时间应该不超过0.1秒；
- 对于每个用户同时只有一项任务的在线系统，在90%的时间内系统响应时间应该不超过0.5秒；
- 对于每个用户同时有多任务的在线系统，在90%的时间内系统响应时间应该不超过1秒。
性能测试关注的是系统性能是否和具体的性能需求相一致，而当系统性能超过性能需求的时候，系统的表现并不是测试人员关心的重点。
例如：性能需求中要求系统应该支持最大同时在线用户为5000个，那么在性能测试过程中重点测试系统是否能支持5000个用户同时在线；当有5000个用户同时在线后，性能测试需要关注整个系统的运行是否符合要求；而对于在线用户超过5000人的时候，系统的表现行为并不是性能测试需要关注的。
2）负载测试
负载测试是一种通过增加负载来评估组件或系统的性能的测试方法。例如：通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。负载测试和性能测试的主要区别在于负载测试时，系统负载是逐渐增加的，而不是一步到位，负载测试需要观察系统在各种不同的负载情况下是否都能够正常工作。
下图是某网站随着用户数量的增加，对应的响应时间也在增加的趋势图。具体趋势如图1所示。
图1 某网站负载测试中用户数量和响应时间关系图
通过观察图1，可以发现随着用户数目的增加，系统响应时间也跟着增加。当在线用户数到700以后，系统响应时间增速明显加快。当然响应时间只是需要观察的数据之一，随着测试负载的增加还需要观察系统资源等占有情况。
3）压力测试
压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。在压力级别逐渐增加时，系统性能应该按照预期缓慢下降，但是不应该崩溃。压力测试还可以发现系统崩溃的临界点，从而发现系统中的薄弱环节。
例如：系统最大支持的同时在线用户数是1000个，压力测试需要测试在1000个用户甚至2000个用户同时在线时系统的表现。虽然测试时负载已经超过了系统的设计能力，但是在这种情况下被测试系统也不应该发生崩溃。压力测试也可以针对系统资源进行测试，例如：在系统内存耗尽情况下，测试系统的运行情况，这种情况下被测试系统也不应该崩溃。
前面分别介绍了性能测试、负载测试和压力测试三种效率测试类型。目前在软件测试领域，对这三种测试类型的定义并不统一。在实际的测试工作中，性能测试这个词被广泛的使用。在很多场合，性能测试是上述三种测试类型的通称；在有的书籍或者参考资料中，性能测试的范围甚至更加广泛。
~~~~~~~~~~~~~~~~~~~~~~~~~
- 吞吐量（throughput）
吞吐量，是指单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数。吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标，一般吞吐量越大，系统单位时间内处理的数据越多，系统的负载能力也越强。
- 并发（concurrency）
并发，是指多个同时发生的操作。并发和并行不是一个概念，并发是同时发生，并行是同步运行。
- 稳定性测试（reliability testing）
稳定性测试，也叫可靠性测试（reliability testing），是指连续运行被测系统，检查系统运行时的稳定程度。我们通常用mtbf（mean time between failure,即错误发生的平均时间间隔）来衡量系统的稳定性，mtbf越大，系统的稳定性越强。稳定性测试的方法也很简单，即采用24*7（24小时*7天）的方式让系统不间断运行，至于具体运行多少天，是一周还是一个月，视项目的实际情况而定。
- 负载测试（load testing）
负载测试，是性能测试的一种，通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
可以看出负载测试和稳定性测试比较相似，都是让被测系统连续运行，区别就在于负载测试需要给被测系统施加其刚好能承受的压力，比如我们还是测试163邮箱系统的登录模块，我们先用1个用户登录，再用两个用户并发登录，再用5个，10个…在这个过程中，我们每次都需要观察并记录服务器的资源消耗情况（可以通过任务管理器中的性能监视器或者控制面板中的性能监视器），当发现服务器的资源消耗快要达到临界值时（比如cpu的利用率90%以上，内存的占有率达到80%以上），停止增加用户，假如现在的并发用户数为20，我们就用这20个用户同时多次重复登录，直到系统出现故障为止。
负载测试为我们测试系统在临界状态下运行是否稳定提供了一种办法。
- 压力测试（stress testing）
压力测试，是性能测试的一种，通常是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。
比如我们不断增加并发的登录用户数，20，30，50…比如，当增加到70个用户并发登录时，系统崩溃了，我们就可以知道163邮箱所能承载的最大登录并发数为70个左右。
我们把上面的思路整理一下，编写一下163邮箱登录模块性能测试用例，供大家参考（假设163邮箱要求登录的时间最多不超过10秒，测试环境略）
关于性能测试的分类，可以举一个比较通俗的例子方便大家理解：
假设一个人很轻松就能背1袋米，背2袋米很吃力，最多就能背3袋米
稳定性测试-我让他背1袋米，但是让他去操场上跑圈，看多久累倒。
负载测试-我让他背2袋米去操场上跑圈，看多久累倒。
压力测试-我让他背2袋米，3袋米，4袋米…发现他最多就能背3袋