性能测试的需求分析——大话性能测试(09)

发表于:2022-6-24 09:37

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:胡通    来源:51Testing软件测试网原创

#
Jmeter
分享:
  1.2.2性能测试需求分析
  性能测试最开始的需求分析工作细致与否,与后面的性能测试结果息息相关。需求分析是一个繁杂的过程,它并非我们想象的那么简单。做需求分析除了要对系统的业务非常了解,还需要有深厚的性能测试知识,这样才能够挖掘分析出真正的性能测试需求。
  很多时候,性能测试的需求是比较模糊的,需要性能测试工程师去挖掘和分析。在工作中,作者经常被问到的一个问题是:应该设置多少个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%的时间内。
版权声明:51Testing软件测试网获得作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任
21天更文挑战,赢取价值500元大礼,还有机会成为签约作者!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海漕溪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2022, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号