性能测试的一点吐槽

零、吐槽   

        说起来，我也算是性能测试的一员老兵了，但Loadrunner只是会使用，Jmeter基本没怎么用过。对一些大型系统做过性能测试，但由于第三方测试的原因，更多时候是方案写得天花乱坠，实际操作时大家都简化到做个压测拉倒。和面向公众的电商平台不同，第三方测试检测的大都是政府、机构的系统，测试就是履行个手续。因此大多数就是简单地做个压测，连用户的容量、用户业务模型、大数据测试、可靠性（时间强度）这些基本的内容都不会测试。个人也就基本停留在学了一些理论上的屠龙技，实操上还是一团浆糊的层次。一些嵌入式系统，基本上和设备结合紧密，提的性能指标很多是芯片来保证的，剩下大多也就是支持XX个用户和操作响应时间XX秒之类，由于系统小，基本就是人工搭个简单环境，搞定。但终归这些年下来，对性能测试这块还是有了点感悟，结合最近回炉的一些课程，写点心得吧。

         总结，什么样的客户、什么样的需求，决定你的高度。外部需求驱动技术发展，而不是相反。好了，吐槽完毕，开始正文。

一、性能测试的重点（或：策略、分析方法）

       先从压测说起吧。我们现在的性能测试人员，对此的直接理解就是，找到依据文件（合同、标书、SRS等等），然后对照着摘出性能指标要求，用Loadrunner录个脚本，压，压完得到个数据，通过、不通过一目了然，OK，测试结束。因此，性能测试的关键，就是如何使用Loadrunner。具体业务会话中集合点/等待时间/业务配比设置，会对照工具调一下，以便测试结果能够通过。这就是真实的操作过程，最有技术含量的，就是我会录制脚本，会调session中的参数了。OK，Loadrunner用得飞起，性能测试完事了。这样的搞法，弄到最后，两三年下来，loadrunner的analysis都只会进去截个图，入门没有自己都不知道。好了，吐槽完毕，谈点个人体悟。

         1、性能指标肯定是对不同的人群有不同的要求的。

         依据文件的指标当然是关键，但是一般都是写得很成问题的。常见的一般是：系统支持10万个用户使用。系统在高峰期访问时间小于5秒。 但是实际使用时，一问就知道：10万个是系统最大的注册用户数，和同时在线用户、并发访问用户实际上远远小于10万，大概1000个。写这个指标是为了方便向政府申请财政资金，10万用户需要的服务器、存储可比1000个大太多了。至于系统在高峰期访问时间小于5秒，并没有要求什么业务，于是测试的人员直接使用最简单的登陆来糊弄，当然不用设集合点，最后大家皆大欢喜。系统达标、项目顺利结项、测试不用一轮轮回归，实际使用当然也不会出什么问题。

      各种系统，性能指标最常见的就是，响应时间、并发用户数、吞吐量。从不同用户层面来分析大家对性能指标的关注点，实际指标还是有很大差别的：

•  终端用户（实际用户）：关注的是业务响应速度。注意，不是实际处理速度，更关注体验。实际测试时，大家还是一般主要是压测最简单的简化模型就是：发出请求+网络传输+后台处理+网络传输+前端渲染。用户关注的是发出请求到看到响应，因此如果前端渲染时间长的，肯定要采用用户体验提升措施了，包括边渲染边接收的方式、分解步骤展现、提示条和等待画面等。
• 系统运维人员：更关注后台系统的可线性扩展性、可靠性、整体的响应程度。慢点无所谓，容易扩容、不会崩溃才是关键。
• 系统开发人员：具体的编码人员，跟老子的模块关联的是最重要的。这个模块的单独性能很关键啊。系统架构师不得不负责整个性能设计，不得不去考虑怎样设计合理。于是，出问题就是架构不合理，开发过程中的算法优化、前端调优的措施、数据库访问的优化等，一般要到上线前压测不过才会真正被提出来。
• 系统测试人员：直接对标系统架构师，但是地位没人家高啊，薪水也少。我就关注三大块： 响应时间、并发用户数、吞吐量。再进一步的，会关注一下前端响应、性能瓶颈在哪儿。          

   2、压测过程中系统业务处理与指标的关联

        首先，起始阶段。当然是用户少，业务量少。这个并发用户少，响应时间快，吞吐量小。一个字：爽。

        然后，线性增长阶段。用户量上升，业务量成比例上涨，吞吐量同样上涨。好用。

        再后，业务饱和阶段。用户量上升到某个拐点，处理不及时，出现排队现象，业务量缓慢上涨，吞吐量基本停滞。

        终于，系统崩溃阶段。用户量持续上涨，系统某个处理资源率先耗尽，处理时间急剧延长，出现大量错误，业务量不但不上涨还下降。一般，设计者都会做过载限制或分流措施，保证已经进入的用户业务处理正常，避免崩溃。在压力下降后，错误率降低，逐渐恢复回前面的阶段。但设计不好的，基本就崩溃，等待运维人员重启了。 

二、性能测试的种类和目的

        性能测试当然有很多用途，比如性能评估、性能调优、缺陷发现。一般实际工作中，涉及的性能测试当然不止压测，常见的比如：

• 后端性能测试：主要针对服务器，也是最常见和最重要的；
• 前端性能测试：主要针对前端性能调优；比较有名的是雅虎前端团队总结的7大类35条前端优化规则。
• 代码级性能测试：这个一般是开发者在单元和集成阶段针对性测试；
• 性能指标测试：其实各级别都有验收测试之要求，常见问题就是场景划分不清晰，带来实际性能指标定义不明确
• 配置测试：这个就是评估不同硬件、软件配置下性能表现，确定配置要求或调优方向
• 系统级可靠性测试。

通常采用的手段都是压力测试，当然，这个的变种就多了，各种不同目的催生了不同的叫法，但是实际都一类：大量用户并发测试系统的并发处理能力；施加足够压力来进行压力测试（保持在正常工作状态）；强度测试，持续施加压力到崩溃，然后减压恢复的过程；针对数据IO业务量大的内容开展大数据量测试；探测系统某个指标的最大能力的容量测试；持续长时间保持多用户多业务组合的相当压力情况下开展可靠性测试，检验系统内存和各类资源是否泄漏，是否存在系统的各类垃圾积累影响性能，是否存在预料不到的异常带来工作不稳定。

  三、结束语

实际性能测试需要重点考虑的一些内容：

• 性能测试很重要的一点就是：测试环境的安排。大规模压测一般不可能全面复制生产环境。最好的是，成比例地缩减，构建测试环境，方便估算实际环境的能力。
• 测试场景设计等当然很重要，其中关键就是用户业务模型的理解和设计。已有运行系统可以通过日志收集；没有历史版本的，通常参考同类产品，或者就是自己推演了。
• 测试数据准备也是一个难点。特别是灰度测试的情况下，测试数据不能污染实际数据，是个基本常识。最好的策略是使用实际数据，但这并不是每次都能如愿的。一般还是会通过脚本来大批量产生。        
•  最后，性能测试是手段。首要的是把系统在满足一定非功能需求的情况下实现出来，而不是忙着做性能测试和性能优化。大规模进行性能测试进而开展必要的性能优化，时机和关键点是很关键的。引用Donald Knuth的话：在97%的时间里，都应该忘记哪种小的效率提升：过早优化是罪恶之源。然而，我们也不能让另外非常关键的3%的机会与我们插肩而过。

       说到底，性能测试对标系统架构师，真的能拆开揉碎了，瓶颈和压力点能找到，自然测试轻松搞定，顺带就把调优也做了。当年看了郭欣的《构建高性能web站点》（一个简要的笔记见：https://book.douban.com/review/9324170/），对这类网站系统的整个建构过程涉及的技术都加深理解，对应的测试方案也写得顺了很多。只有真的潜进去，深入浅出来回折腾，才能干出些水花来。但是，往往受到各类主客观限制，内部研发测试可能资源不够，第三方测试终归是难以深入，最后都没法潜进去，真正克服困难进去的，都有回报了。