七种性能测试方法

根据在实际项目中的实践经验，我把经常使用的性能测试方法分为七大类：后端性能测试（Back-end Performance Test）、前端性能测试（Front-end Performance Test ）、代码级性能测试（Code-level Performance Test）、压力测试（Load/Stress Test）、配置测试（Confguration Test）、并发测试 （Concurrence Test），以及可靠性测试（Reliability Test）。接下来，我将详细为你介绍每一种测试 方法。

第一，后端性能测试
其实，你平时听到的性能测试，大多数状况下指的是后端性能测试，也就是服务器端性能测试。
后端性能测试，是经过性能测试工具模拟大量的并发用户请求，而后获取系统性能的各项指标，而且验 证各项指标是否符合预期的性能需求的测试手段。
这里的性能指标，除了包括并发用户数、响应时间和系统吞吐量外，还应该包括各种资源的使用率，比 如系统级别的CPU占用率、内存使用率、磁盘I/O和网络I/O等，再好比应用级别以及JVM级别的各种资 源使用率指标等。
因为须要模拟的并发用户数，一般在“几百”到“几百万”的数量级，因此你选择的性能测试工具，必定不 是基于GUI的，而是要采用基于协议的模拟方式，也就是去模拟用户在GUI操做的过程当中实际向后端服 务发起的请求。
只有这样才能模拟很高的并发用户数，尽量地模拟出真实的使用场景，这也是如今全部后端性能测试 工具所采用的方法。
根据应用领域的不一样，后端性能测试的场景设计主要包括如下两种方式：
基于性能需求目标的测试验证； 探索系统的容量，并验证系统容量的可扩展性
随着系统并发用户数的增加，系统处理能力达到过饱和状态。此时，若是继续增长并发用 户数，最终全部用户的响应时间会变得无限长。相应地，系统的总体吞吐量会降为零，系 统处于被压垮的状态。咱们每每把这个阶段称为“过饱和区间”。

第二，前端性能测试
前端性能测试并无一个严格的定义和标准。
一般来说，前端性能关注的是浏览器端的页面渲染时间、资源加载顺序、请求数量、前端缓存使用情 况、资源压缩等内容，但愿借此找到页面加载过程当中比较耗时的操做和资源，而后进行有针对性的优 化，最终达到优化终端用户在浏览器端使用体验的目的。
目前，业界广泛采用的前端测试方法，是雅虎（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天。