性能测试的正确打开方式

回想第一次接到性能测试任务时——由于之前已自学有一段时间了，苦于没有实际项目可操作，所以不免有些兴奋，但更多的却是无措。因为不知道应该如何开始、如何推进，最后如何完成。于是不管那么多了，撸起袖子就开始写脚本，执行，截图报告...当自以为已经完成任务后，却发现原来忽略了这么多问题：脚本问题、环境问题、网络问题、参数问题、数据问题等等。再反观所谓的测试报告，很可能只是一堆毫无意义的数据，对于性能的真实体现毫无帮助。经过一次次的总结，整理出以下几个步骤作为今后工作的参考：

需求调研

首先就是要掌握被测应用的软件架构，各系统间是同步调用还是异步调用，异步调用时返回的响应时间是没有参考价值的。

还要知道开发语言环境，使用的是JAVA、PHP，还是NodeJS，或是其他什么语言，不同的编程技术监控的手段是不同的，用jconsole去监控nodejs，岂不是牛头不对马嘴。

时刻掌握开发进度，软件开发过程中的任何微小改动对最终性能提现都是呈几何倍放大的，所以对功能尚未完善的软件进行性能测试是浪费资源的。

拥有独立的测试环境当然是最好的，没有条件那就尽可能排除干扰吧。性能测试对服务器会产生的巨大压力，为了不影响他人正常使用——从这个角度考虑，独立的测试环境也是利大于弊。

统计历史峰值，如果有的话，那会是最有价值的参考标准，因为我们要解决的问题就是要满足这些人的访问需求。如果没有，那也一定要制定一个准出标准。谁会愿意攀登没有顶的山峰呢？

最后一条很多人都会忽视的上线时间，有难度可以提出异议建议延迟；但是你不问，还要整个团队等着你，这就不厚道了。

工具选择

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

脚本编写

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

注意事项：

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

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

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

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

脚本调试

单独列出这一项是想突出它的重要性，实际工作中调试和编写可能是交错进行的。调试什么？

发送的请求是否发送至服务器，且数据是否正确，可通过观察服务器日志校验；

服务器返回的结果是否正确，可与浏览器收到的响应进行比较；

响应也确实返回了，但并不是我想要的，可以添加响应断言判断；

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

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

性能表现不理想，是不是原本网络带宽不足导致；或者压力机和服务器根本就是不同的网段，即便是多次的路由跳转就已经花费了大量的时间，并不能以此认定就是代码问题。

场景设计

同之前需求调研中所述，如果拥有历史峰值作为参考，那么场景设计将非常方便——模拟历史峰值即可。如果没有呢？那么介绍几种方案：

方案一：根据已知系统使用人数推算峰值。

假设系统OA拥有用户1000人，每天会有400人访问，每个用户从登录到退出平均耗时2小时，在1天时间内用户仅会在白天的8小时内使用该系统。

C = nL/T = 400 * 2 / 8 = 100

C^ = C+3*(C的平方根) = 100 + 3 * (100的平方根) = 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）。有时性能表现不佳，可能是压力机本身存在压力，并不是应用或服务器有问题；而服务器指标是要拿来和请求指标结合分析。

TPS高达1000/秒，但是服务器的CPU、MEM长时间占用90%，对服务器而言并不是一个良好的状态。在执行场景的短短几分钟或半小时内也许这并不算什么问题，投入生产后，以这个状态运行7天 * 24小时难免不出问题。这里给出一个大致的评价标准：

报告分析End

长按识别，感谢关注