性能测试之清单革命

首先推荐一本书——《清单革命》，书的作者并不是测试人员，也不是开发人员，甚至都不属于软件行业从业人员，而是一位美国医生。医生这个职业经过漫长的发展，如今它的复杂程度早已超出任何人的想象。我们的身体能够以13000多种不同的方式出现问题，医生们需要在上千种治疗方案中选取正确一种，另外过程中还涉及上万种治疗工具。为什么本该在90分钟内完成的心脏急救检查，成功率不到50%？　　或许我们犯错，是因为没有掌握相关的知识；或许我们犯错，不是因为没有掌握相关的知识，而是没有正确的使用这些知识。一张小小的清单，让约翰霍普金斯医院原本经常发生的中心静脉置管感染比率从11%下降到0。清单从来不是大而全的操作手册，而是理性选择后的思维工具。　　回想第一次接到性能测试任务时，除了斗志满满之余，更多的却是不知所措。不知道如何开始、如何推进，如何结束。不管那么多，一拍脑袋开始写脚本、调试、执行、截图，报告...当自以为已经完成任务后，却发现原来忽略了很多问题：脚本问题、环境问题、网络问题、参数问题、数据问题等等。再反观所谓的测试报告，很可能只是一堆毫无意义的错误数据，对于性能的真实体现毫无帮助。性能测试也需要一份清单：

需求调研

首先就是要掌握被测应用的软件架构，各系统间是同步调用还是异步调用，掺杂了异步调用的响应时间是没有参考价值的。还有使用的编程语言，是JAVA、PHP、NodeJS，还是其他什么语言，不同编程语言的性能表现是不一样的，后期的监控手段也不一样，你非要用Jconsole去监控PHP，我会告诉你不可以么？　　是否拥有独立的测试环境，没有条件那就尽可能排除干扰吧。性能测试对服务器会产生的巨大压力，为了不影响他人正常使用，从这个角度考虑，独立的测试环境也是利大于弊。　　询问并掌握开发进度，对功能尚未完善的软件进行性能测试是浪费资源的，因为任何对业务流程的改动，对性能的表现都是呈几何倍放大的。　　统计历史峰值，如果有的话，那会是最有价值的参考标准，因为我们要解决的问题就是要满足这些人的访问需求。如果没有，那也一定要制定一个准出标准。谁会愿意攀登没有顶的山峰呢？ 　　最后一条很多人都会忽视的上线时间，有难度可以提出异议建议延迟；但是你不问，还要整个团队等着你，这就不厚道了。

工具选择

Loadrunner，商业软件，功能强大，录制回放、脚本编辑、场景设计、执行测试、生成报告流程清晰完整。收费较贵，破解使用会有一定的法律风险。　　Jmeter，开源软件，对于WEB端应用而言，功能全面，可自定义函数、采样器、监视器，自由度高，自带监控功能有限，第三方插件众多，平台化趋势明显。没有法律风险。　　根据实际情况选用即可。另外，再推荐几个工具，当Jmeter请求失败或者返回结果有误，可以使用fiddler截取浏览器请求和响应包，或者使用Postman编写同样的请求，然后作为比对和参照，反过来修改和完善Jmeter脚本。

脚本编写

询问开发人员，由他们提供请求的方式（GET、POST）、协议（HTTP、HTTPS）、主机（域名、IP）、端口号、编码、参数名、参数类型、参数规则等等。 　　注意事项：

参数规则：在某些项目中中，参数会有一些生成规则，位数、数字、字母等，比如：身份证号码、手机号码等；还会有一些业务规则，比如：唯一性、一次性等。这里推荐使用EXCEL加上一些简单函数来生成参数，编程能力可以的话也可使用JAVA、PYTHON来实现。

验证开关：在某些涉及金融交易的项目中，用户的访问权限至关重要，有些较为严格的安全业务逻辑，比如：短信验证码、动态验证码、滑动验证码，可以关闭尽量关闭；AccessToken、csrf_token等校验使用固定的或者随机值，且不做校验也能接受。安全问题应该通过功能测试进行，性能测试中花时间解决它们得不偿失。理想的方案是通过全局变量控制安全等级，或者白名单机制也是不错的选择。

对外通信：业务流程中若包含短信发送、邮件发送，广播消息等对外功能，墙裂建议增加白名单功能。测试过程中可能瞬间发送上万条信息，避免测试信息发送到真实的用户端。

外部功能：业务流程中包含外部团队调用逻辑，可以通知开发人员编写Mock程序替代，外部应用的性能问题（必须向其提供报告的情况除外）即使提出问题，开发人员也没有权限修改。

脚本调试

记得曾经有一个项目：脚本也完成了，场景也组织好了，执行过程也正常，性能指标看上去也挺好，似乎一切都挺顺利。开发人员却问了：为什么服务器一点压力都没有？于是返回查看响应结果和数据库的记录才发现，原来请求时的参数错了，虽然返回了正确的响应，但业务流程在第一步就结束了。所以单独列出调试一项以体现其重要性，脚本错误了，执行报告也就没有参考意义了。调试的时候反复问问自己以下几个问题吧：

请求发送成功了吗？返回结果正确吗？请检查后台日志、数据库记录；

响应返回了，结果也没报错，但并不是我想要的。请检查请求参数并调整；

使用的参数是否达到随机性，反复查询一条记录可能不会产生多大的压力；

返回的响应时间是不是真实有效，如果链路中存在异步环节，那就没有意义了；

网络带宽多少？网段是否一致？性能不好不一定就是代码问题，网络阻塞性能怎会良好；

场景设计

之前需求调研部分已经讲过：如果拥有历史峰值作为参考，那么场景设计将非常方便，模拟历史峰值，或者高于历史峰值进行压测即可。　　如果没有呢？那么介绍几个方案：　　方案一：根据已知系统使用人数推算峰值。

假设系统OA，每天会有800人访问，每个用户从登录到退出平均耗时2小时，在1天时间内用户仅会在白天的8小时内使用该系统。 C = nL/T = 800 * 2 / 8 = 200 C^ = C+3*(C的平方根) = 200 + 3 * (200的平方根) 约等于 130 其中C=并发用户数，n=使用系统的用户数，L=操作时长，T=考察时间长度,C^=根据泊松分布估算获得的峰值

方案二：建设一个能够承受500万PV/天的网站，TPS需要达到多少。

PV是指页面访问次数，每打开或刷新一次页面，都记为一个PV 计算公式：单服务器TPS=((80% * PV)/(24小时60分60秒*40%))/服务器数量 80%，40%表示一天中80%的请求发生在一天的40%的时间内。 TPS = ((80% * 500万)/(24 * 60 * 60 * 40%)) / 1 = 115.7个/秒 当然，从小到大多次考试经验告诉我们：考试考你一碗水，自己要有一桶水。115.7个/秒理论上能支撑500万PV，实际突发情况数不胜数。 稳妥的做法：115.7 * 2 = 231.4个/秒 或 115.7 * 3 = 347.1个/秒 然后我们就可以充满自信的说：当服务器处理能力达到231.4/347.1个/秒时，一定能够支撑500万PV/天的流量。

场景执行

记得最初接触到性能测试时，听过这么一种说法：性能测试可以无人值守执行，开始执行脚本后，安安心心回家休息，第二天拿报告即可。可以很负责人的告诉你，这绝对是忽悠你的！第二天打开报告一看——错误率100%——然后呢，再无人值守一天吗？ 　　　　我们在上一步中反复调试修改了脚本，但是那只是在单线程情形下，一旦开启多线程，仍然有可能产生这样或那样的问题。所以还是老老实实看着，一旦有错立即反馈是很有必要的。钱可以赚，浪费的时间是回不来的。

采集指标

这里的指标分为两类：一类是请求指标，包括响应时间，TPS等；另一类是硬件指标，包括压力机硬件指标、服务器硬件指标（CPU、MEM、NET、I/O）。有时性能表现不佳，可能是压力机本身存在压力，并不是应用或服务器有问题；而服务器指标是要拿来和请求指标结合分析。　　推荐采集工具：

nmon，使用方法自行百度

jconsole、jvisualvm、jprofile；JAVA后台监控

zabbix+grafana，高端大气上档次，搭建教程请自行百度

云压测平台，简单直观；例如ZPTP

报告分析

为什么要获取两类指标呢？这就好比一辆赛车，时速和马力就好比第一类指标；发动机的转速和发热量就是第二类指标。看到一辆赛车时速300-400公里/小时，行驶一小时后发动机冒烟着火了，你敢开么？ 　　　　所以TPS高达300个/秒，但是服务器的CPU、MEM长时间占用90%+，对服务器而言并不是一个良好的状态。在执行场景的短短几分钟内这也许并不算什么问题，投入生产后，以这个状态运行7天 * 24小时，你敢保证不出问题么？这里给出一个大致的评价标准：

清单革命

需求调研：软件架构，编程语言，独立环境，开发进度，历史峰值，上线时间工具选择：Loadrunner，Jmeter，Fiddler，Postman脚本编写：参数规则，验证开关，对外通信，外部功能脚本调试：结果校验，参数随机，缓存异步，网段带宽场景设计：历史峰值，推算并发，推算TPS场景执行：坚守岗位，关注结果，及时汇报，及时调整采集指标：响应时间，TPS，CPU，MEM，NET，I/O报告分析：结果报告，分析瓶颈，提供建议，规避风险

End长按识别，感谢关注