性能测试最开始的需求分析工作细致与否,与后面的性能测试结果息息相关。需求分析是一个繁杂的过程,它并非我们想象的那么简单。做需求分析除了要对系统的业务非常了解,还需要有深厚的性能测试知识,这样才能够挖掘分析出真正的性能测试需求。
很多时候,性能测试的需求是比较模糊的,需要性能测试工程师去挖掘和分析。在工作中,作者经常被问到的一个问题是:应该设置多少个JMeter线程去压测?还有不懂技术的客户提出想要做性能测试,但是没有提供指标,只说系统支持100万用户。这些都是我们日常工作中司空见惯的泛泛的需求。
此时,我们可以通过“3步法”对产品进行正确的需求分析和用户业务模型建立。
1.剖析被测系统
(1)了解系统架构。首先我们需要与开发人员沟通,了解清楚系统的部署架构釆用了哪些中间件、数据库、容器、缓存等,以及它们之间的架构关系,并画出对应的网络拓扑图和系统部署架构图。
(2)了解业务模型。首先我们需要采用用户行为分析,分析用户使用产品的习惯,确定系统的典型业务及发生时间。很多大型系统的业务使用都有流量高峰。这类系统业务使用的流量高峰可能出现在一天、一月、一年中的某个时间点上或时间段内。对于新浪、网易等门户网站,在周一到周五的早上刚上班时,可能使用邮件系统的用户比较多,而在中午休息时间浏览热点新闻的用户较多;对于一般的OA系统,早上阅读公告的用户较多,在其他时间可能没有用户使用系统或者仅有少量的用户,比如秘书或领导使用系统起草和审批公文;对于电信缴费系统,在月末很可能会出现用户集中使用交费业务的情况。
然后是调研历史统计数据,通过分析数据确定热点模块。如果产品已上线,可以统计和分析线上历史数据。对于Web类产品,我们可以获取和分析独立用户数、页面访问量和最大在线用户数;对于后台类产品,则可以分析如Nginx的Accesslog,从而得出最大的访问量;对于数据库类产品,我们还可以分析出热点SQL等。如果产品未上线,有同类产品参考,可以参考公司内同类产品或者同行的同类产品进行热点模块预估,虽然不能完全照搬,但可以根据业务增长数据进行统计分析,输出用户访问热点轨迹图。
2.选取性能测试点
选取性能测试点是性能测试需求分析中非常重要的一个环节。面对一个功能繁杂的系统,要设计出有效的测试场景,最大程度上覆盖系统的性能问题和瓶颈,需要较多的经验积累。目前我们可以按照以下原则来进行性能测试点的选取:
(1)核心业务模块,例如支付业务、核心算法;
(2)并发量较高的业务模块;
(3)逻辑较复杂的业务模块;
(4)有复杂数据库操作或事务的模块;
(5)有较频繁的磁盘读写操作的模块。
然后根据不同类型的系统应用,选取的原则也可以进一步细分。
对于Web应用,其性能测试点的选取原则为:
(1)依据业务数据统计中几种典型业务的用户使用数比例;
(2)调用频繁、占用空间大的数据库表的交易;
(3)占用最大存储空间或其他资源的交易;
(4)对磁盘、常驻内存的数据过度访问的交易。
对于后台类应用,其性能测试点的选取原则为:
(1)读(査询)、写(增删改)、读写(增删改查)混合的业务模块;
(2)配置服务器的业务模块;
(3)功能的实现方式,如同步和异步,轮询和notify等;
(4)分布式业务模块,如单客户端和多客户端,单节点和多节点;
(5)数据规模,如数据库已存在大量记录,存储可用空间少;
(6)缓存,如对文件系统缓存和数据库缓存的利用等;
(7)负载均衡,如多节点情况下是否负载均衡。
对于分布式数据库,其性能测试点的选取原则为:
(1)数据库读写混合业务模块;
(2)数据库之间数据同步;
(3)SQL语句;
(4)数据规模。
此外,当系统应用包含长连接消息服务时,其性能测试点的选取原则为:
(1)单机能支撑的最大并发长连接数;
(2)并发一定数量的用户时的消息推送情况,包括消息到达时间、消息丢失率等。
3.量化测试目标
梳理出来性能测试场景后,就需要进一步明确各个场景的测试指标,而大部分的产品经理给出的指标都是不完整的,通常情况下可以结合上面釆集的数据和二八定律进行具体量化,让性能测试指标更明确。
下面举个例子说明性能测试指标量化方法。
例如,某互联应用,预计推广群体达500万人,用户使用应用的时间是每天早上8点至晚上8点,共12h。
分析建模过程如下:
(1)注册用户转化率预估为5%,那么注册用户数为5000000x5%=250000;
(2)高峰时段(比如有活动时)每日在线用户活跃率预估为10%,那么活跃用户数为250000X10%=25000;
(3)用户常用下单到成功触发20个请求,总请求量为25000x20=500000;
(4)利用二八定律计算,得出的吞吐量为500000x0.8/(12x3600x0.2)=46.7个每秒。
若是更新需求,如发布新产品,定时抢购优惠活动(某日10点开始抢购,12点结束)。
重新建模如下:
(1)注册用户数为25万不变;
(2)高峰时段在线用户在线率预估为20%,那么这2h的在线用户数为250000x20%=50000;
(3)用户常用下单到成功触发20个请求,总请求量为50000x20=1000000;
(4)利用二八定律计算,得出的吞吐量为1000000x0.8/(2x3600x0.2)=555.6个每秒;
由此可见,评估出来的TPS值和需求业务模型息息相关。
在性能测试的前期,通过上述“3步法”整理分析的详尽程度将直接决定后续性能测试的有效性和准确性。
注意
在评定服务器的性能时,应该结合TPS和并发用户数,以TPS为主、并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量的话,则需要一个前提,那就是交易在多长时间内完成,因此只用并发用户数来衡量系统的性能没太大的意义。
提示
响应时间:根?据国外的资料,一般操作的响应时间为2秒、5秒、8秒,即2秒内为优秀、5秒内为良好、8秒内为可接受;对于其他一些特殊的操作,如上传、下载,可以依据用户体验的情况延长响应时间。
二八定律:又称帕累托效应,例如,一些系统一天中80%的访问量集中在20%的时间内。