性能测试方法，80%提高你的工作效率

根据在实际项目中的实践经验，把常用的性能测试方法分为七大类：后端性能测试、前端性能测试、代码级性能测试、压力测试、配置测试、并发测试、以及可靠性测试。

接下来，将详细为你介绍每一种测试方法。

第一：后端性能测试

其实你平时听到的性能测试，大多数情况下指的是后端性能测试，也就是服务端性能测试。

后端性能测试是通过性能测试工具模拟大量的并发用户请求，然后获取系统性能的各项指标，并验证 各项指标是否符合预期的性能需求的测试手段。

这里的性能指标，除了包括并发用户数，响应时间，系统吞吐量外，还应该包括各类资源的使用率，比如系统级别的cpu占用率、内存使用率、磁盘I/O和网络I/O等，再比如应用级别以及JVM级别的各类资源使用率指标等。

只有这样才能模拟很高的并发用户数，尽可能的模拟出真实的使用场景，这也是所有后端性能测试工具采用的方法。

根据应用领域的不同，后端性能测试的场景设计主要包含以下两种方式：

基于性能需求目标的测试验证；探索系统的容量，并验证系统容量的可扩展性；

随着系统并发用户数的增长，系统处理能力达到饱和状态。此时如果继续增加并发用户数，最终所有用户的响应时间会变得无限长。相应的系统整体吞吐量会降为零，系统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。

第二：前端性能测试

前端性能测试并没有一个严格的定义和标准。

通常来讲，前端性能关注的是浏览器端页面渲染时间，资源加载顺序，请求数量，前端缓存使用情况，资源压缩等内容，希望借此找到页面加载过程中比较耗时的操作和资源，然后进行有针对性的优化，最终达到优化终端用户在浏览器使用体验的目的。

目前，业界普遍采用的前端测试方法，是雅虎（Yahoo）前端团队总结的7大类35条前端优化规则，可以通过雅虎网站查看这些规则，以及对各规则的详细解读。

这里列出几个典型也是重要的规则，帮助大家理解前端性能测试优化的关注范围。

减少http请求次数：http请求数量越多，执行过程耗时越长，所有采用合并多个图片到一个图片文件的方法来减少http请求次数，也可采用将多个脚本文件合并成单一文件的方式减少http请求；

减少dns查询次数：dns作用是将url转化为实际服务器主机ip地址，实现原理是分级查找，查找过程需要花费20--100ms时间，所有一方面我们加快单次查找的时间，另一方面减少一个页面中资源使用多个不同阈的情况；

避免页面跳转：页面跳转相当于又打开了一个新的页面，耗费时间会较长，所以尽量避免使用页面跳转；

使用内容分发网络（cdn）：使用cdn相当于静态内容做缓存，并把缓存内容放在网络供应商（ISP）的机房，用户根据就近原则到ISP机房获取这些被缓存了的静态资源，因此可以大幅度提高性能；

Gzip压缩传输文件：压缩可以帮助减少传输文件的大小，进而可以从网络传输时间的层面来减少响应时间；

第三：代码级性能测试

代码级性能测试：是指在单元测试阶段就对代码的时间性能和空间性能进行必要的测试和评估，以防止底层代码的效率问题子啊项目后期才被发现的尴尬；

如果从事过性能测试相关的工作，一定遇到过这样的场景：系统级别的性能测试发现一个操作的响应时间很长，然后需要花费很长时间去逐级排查，最后发现罪魁祸首是代码中缪戈实现低效的底层算法，这种自上而下的逐级排查定位方法，效率通常很低，代价很高。

所以在项目早期，对一些关键算法进行代码级别的性能测试，防止此类在代码层面就可以被发现的性能问题，遗留到最后的系统性能测试阶段才发现。

但是从实际执行的层面来讲，代码级性能测试并不存在严格意义上的测试工具，通常做法是，改造现有的单元测试架构。

最常使用的改造方法是:

1：将原本只会执行一次的单元测试用例连续执行N次，这个N的取值范围通常是2000~5000；

2：统计执行N次的平均时间，如果这个平均时间较长（也就是单次函数调用时间较长）的话，比如已经达到了秒级，那么通常情况下这个被测函数的实现逻辑一定需要优化。

这里之所以采用执行N次方式，是因为函数执行时间往往是毫秒级的，单词执行的误差会比较大，所以采用多次执行取平均值的做法。

第四：压力测试

压力测试，通常指的是后端压力测试，一般采用后端性能测试的方法，不断对系统施加压力，并验证系 统化处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态时的主要瓶颈 点。所以，压力测试往往被用于系统容量规划的测试。

还有些情况，在执行压力测试时，我们还会故意在临界饱和状态的基础上继续施加压力，直至系统完全 瘫痪，观察这个期间系统的行为；然后，逐渐减小压力，观察瘫痪的系统是否可以自愈。

第五：配置测试

配置测试，主要用于观察系统在不同配置下的性能表现，通常使用后端性能测试的方法：

1.通过性能基准测试（Performance Benchmark）建立性能基线（Performance Baseline）；

2.在此基础上，调整配置；

3.基于同样的性能基准测试，观察不同配置条件下系统性能的差异，根本目的是要找到特定压力模式 下的最佳配置。

这里需要注意的是，“配置”是一个广义配置的概念，包含了以下多个层面的配置：

宿主操作系统的配置； 应用服务器的配置； 数据库的配置； JVM的配置； 网络环境的配置； …

第六，并发测试

并发测试，指的是在同一时间，同时调用后端服务，期间观察被调用服务在并发情况下的行为表现，旨 在发现诸如资源竞争、资源死锁之类的问题。

谈到并发测试，我就不得不和你说说“集合点并发”的概念了，它源于HP的LoadRunner，目前已经被广 泛使用了。那，到底什么是“集合点并发”呢？

假设我们希望后端调用的并发数是100，如果直接设定100个并发用户是无法达到这个目标的，因为 这100个并发用户会各自执行各自的操作，你无法控制某一个确定的时间点上后端服务的并发数量。

为了达到准确控制后端服务并发数的目的，我们需要让某些并发用户到达该集合点时，先处于等待状 态，直到参与该集合的全部并发用户都到达时，再一起向后端服务发起请求。简单地说，就是先到的并 发用户要等着，等所有并发用户都到了以后，再集中向后端服务发起请求。

比如，当要求的集合点并发数是100时，那么前99个到达的用户都会等在那里，直到第100个用户到了， 才集中向后端服务发起请求。当然，实际达到服务器的并发请求数，还会因为网络延迟等原因小 于100。

所以，在实际项目中，我建议在要求的并发数上进行适当放大，比如要求的并发数是100，那我们集合 点并发数可以设置为120。

第七，可靠性测试

可靠性测试，是验证系统在常规负载模式下长期运行的稳定性。

虽然可靠性测试在不同公司的叫法不同，但其本质就是通过长时间模拟真实的系统负载来发现系统潜在 的内存泄漏、链接池回收等问题。

由于真实环境下的实际负载，会有高峰和低谷的交替变化（比如，对于企业级应用，白天通常是高峰时 段，而晚上则是低峰时段），所以为了尽可能地模拟出真实的负载情况，我们会每12小时模拟一个高峰 负载，两个高峰负载中间会模拟一个低峰负载，依次循环3-7天，形成一个类似于“波浪形”的系统测试 负载曲线。

然后，用这个“波浪形”的测试负载模拟真实的系统负载，完成可靠性测试。同样地，可靠性测试也会持 续3-7天。