性能测试之清单革命

首先推荐一本书——《清单革命》,书的作者并不是测试人员,也不是开发人员,甚至都不属于软件行业从业人员,而是一位美国医生。医生这个职业经过漫长的发展,如今它的复杂程度早已超出任何人的想象。我们的身体能够以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长按识别,感谢关注

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180821G1184K00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券