核心内容摘要
四川“少如”：一场穿越时空的味蕾与心灵之旅
点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快
需求分析
测试目的为什么测目的在于测试系统相关性能能否满足业务需求。
通常分以下两种情况1新项目上线2老项目优化如果是老项目优化可考虑是否存有历史测试方案如果有可以参考或许可以省事很多。
测试对象要测啥测试对象可以归结为“业务功能”。
测试前需要了解我们需要测试的业务功能不深入细节有哪些比如“购买商品”、“寄送快递”。
有没有必要测需求来源哪里有没有数据支撑测试这个需求的必要性通常可以从以下几个方面考虑1是否核心功能是否要求严格的质量2是否常用、高频使用的功能3可能占用系统较多资源的功能4使用人数多还是少5在线人数多还是少
拆分对象先从业务上来分实现这个完整的功能包含哪些流程、环节举例购买商品登录-搜索商品-提交订单-支付订单-退出
指标分析分析性能需求指标如“支持300人并发登录”是否合理有必要测试这个需求考虑需求指标是否合理有没有数据支撑通常支撑数据可以从以下方面考虑1采样时间段内系统使用人数2采样时间段内系统在线人数3采样时间段内系统(页面)访问量4采样时间段内请求数…常用分析思路12/8法则2/8法则80%的业务量在20%的时间里完成。
这里业务量泛指访问量请求数数据量等2正态分布3按比例倍增4响应时间
原则就是说一般情况下当用户能够在2秒以内得到响应时会感觉系统的响应很快当用户在
秒之间得到响应时会赶紧系统的响应速度还可以当用户在
秒以内得到响应时会赶紧系统的速度很慢但是还可以接受而当用户在超过8秒后仍然无法得到响应时会感觉系统糟糕透了或者认为系统已经失去响应。
注意这个要根据实际情况有些情况下时间长点也是可以接受的好比12306举例某公司后台监控根据一段时间的采样数据分析得出日高峰时段(11:
:
用户下单请求数平均为1000峰值为1500根据这个计算并发请求数时段3个小时- 3 x 60 x 60 1080s业务量1500吞吐量1500 * 80% / (1080 * 20%)
56请求数/s假设用户下单遵循正态分布那么并发请求数峰值会肯定大于上述估算的吞吐量注意:
2/8原则计算的结果并非在线并发用户数是系统要达到的处理能力吞吐量
如果要求更高系统性能根据实际情况也可以考虑1/9原则或其它更严格的算法
以上估值只是大致的估算不是精确值举例想了下暂时没想到啥好的例子大致就说一些涉及到数据量的性能测试比如报表统计或者是大数据挖掘查询等怎么去估算数据量数据生命周期一般来说数据都是有一定的生命周期的时间的选取需要结合数据周期考虑。
这里假设3年后系统性能仍然需要满足业务需求。
数据增长率如果是老项目可以考虑对应功能主表历史数据存放情况这里假设按年统计比如第一年10000第二年15000第三年20000第四年25000那么我们得出以第一年为基准数据增长率分别为
0.
5
5每年在上一年的基础上以5000的速度增长预估3年后数据增长率为3需要测试数据量为13x 10000 40000注意
实际数据一般是没上面举例那么规律的只能大致估算数据增长率。
一些大数据量的性能测试除了和数据量相关还涉及到数据分布等比如查询构造数据时需要结合实际尽量贴近实际。
不同业务模块涉及表不一样数据量要求也是不一样的需要有区别的对待。
如果是新项目那就比较不确定了除非能收集相关数据。
系统分析结合需求分析中第3点分析系统架构。
从功能实现上来看怎么实现这个完整功能的。
通常这些业务功能操作都对应着一个或多个请求(可能能是不同类型的请求比如http, mysql等)我们要做的是找出这些1请求顺序、请求之间相互调用关系2数据流向数据是怎么走的经过哪些组件、服务器等3预测可能存在性能瓶颈的环节组件、服务器等4明确应用类型IO型还是CPU消耗性、内存消耗型-弄清楚重点监控对象5关注应用是否采用多进程、多线程架构-多线程容易造成线程死锁、数据库死锁数据不一致等6是否使用集群/是否使用负载均衡了解测试环境部署和生产环境部署差异是否按1:1的比例部署通常建议测试时先不考虑集群采用单机测试测试通过后再考虑使用集群这样有个比较比较能说明问题
业务分析1明确要测试的功能业务中功能业务占比重要程度。
目的在于1明确重点测试对象安排测试优先级2建模混合场景中虚拟用户资源分配针对不同业务功能施加不同的负载。
2明确下“需求分析-指标分析”中相关业务功能所需基础数据及数据量问题因为那块需求分析时可能只是大致估算下评估指标是否合理需要认真再分析下
用例设计1用例设计通常是基于场景的测试用例设计1单业务功能场景运行测试期间所有虚拟用户只执行同一种业务功能某个环节、操作2混合业务功能场景运行测试期间部分虚拟用户执行某种业务的某个环节操作部分虚拟用户执行该业务功能的其它环节或者运行测试期间部分虚拟用户执行某种业务功能部分虚拟用户执行其它业务功能注这里用例没说到多少用户去跑跑多久等这里只是把他当作相同场景用例下的的一组组测试数据了。
2事务定义根据用例合理的定义事务方便分析耗时特别是混合业务功能场景测试进而方便分析瓶颈。
比如购买商品我们可以把下订单定义为一个事务把支付也定义为一个事务。
3场景监控对象针对每条用例结合“系统分析”第4点明确可能的压力点比如数据库、WEB服务器需要监控的对象比如tps耗时CPU内存I/O等
测试策略1先进行混合业务功能场景的测试在考虑进行测试单业务功能场景的测试2负载测试-压力测试-稳定性测试-强度测试注如果测试稳定性时间建议至少8小时3逐步加压比如开始前5分钟20个用户然后每隔5分钟增加20个用户。
好处不仅比较真实的模拟现实环境而且在性能指标比较模糊且不知道服务器处理能力的情况下可以帮我们确定一个大致基准因为通常情况下随着用户数的不断增加服务器压力也会随着增加如果服务器不够强大那么就会出现不能及时处理请求、处理请求失败的情况下对应的运行结果图形中运行曲线也会出现对应的形态比如从原本程一条稳定直线的情况到突然极限下降、开始上下波动等通过分析我们就能得出服务器大致处理能力供后续测试参考。
4单点并发比如使用集合点单独针对某个环节的并发测试通常是针对某个环节的性能调优时使用。
常识a)负载测试保证系统能正常运行(通常是满足某些系统性能指标)的前提下让被测对象承担不同的工作量以评估被测对象的最大处理能力及存在缺陷而进行的测试b)压力测试不保证系统能否正常运行的前提下让被测对象承担不同工作量以评估被测对象能提供的最大处理能力及存在缺陷而进行的测试c)稳定性测试测试系统的长期稳定运行的能力。
同疲劳强度测试的区别是稳定性测试的压力强度较小一般趋向于客户现场日常状态下的压力强度当然在通过时间不能保证稳定性的状态下需要加大压力强度来测试此时的压力强度则会高于正常值。
d)强度测试通常模拟系统在较差、异常资源配置下运行如人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以评估被测对象在资源不足的情况下的工作状态注疲劳强度测试是一类特殊的强度测试主要测试系统长时间运行后的性能表现例如7x24小时的压力测试。
工具选取1协议分析一般性能测试工具都是基于协议开发的所以先要明确应用使用的协议2工具选取1类型开源工具、收费工具、自研工具2分析工具1理解工具
实现原理2采用用异步还是同步常识1同步请求发出一个调用请求在没有得到结果之前该调用就不返回。
异步请求发出一个调用请求在没有得到请求结果之前该调用可立即返回。
该调用请求的处理者在处理完成后通过状态、通知和回调等来通知调用者。
3使用长连接还是短连接
软件配置1操作系统内核版本、32 or 64位?2应用版本应用版本要和线上保持一致特别是中间件、组件等的版本因为不同版本其性能可能不一样3参数配置1负载均衡、反向代理参数配置2 Web服务器参数配置3数据库服务器参数配置
网络分析1网络路由通常为了排除网络型瓶颈通常建议在局域网下进行测试。
通常这里我的分析思路是这样的1检查hosts文件的配置从终端压测机(负载生成机)开始到请求目的服务器器机器的hosts文件配置通常hosts文件位于如下WindowsC:\Windows\System32\drivers\etc\hostsUnix/Linux/etc/hosts小常识
通常域名访问站点首先要通过DNS域名服务器把网络域名形如www.xxx.com解析成XXX.XXX.XXX.XXX的IP地址然后继续后续访问。
hosts存放了域名和ip地址的映射关系如下使用hosts可以加快域名解析在进行DNS请求以前系统会先检查自己的hosts文件中是否有这个地址映射关系如果有则把域名解析为映射的IP地址不请求网络上的DNS服务器如果没有再向已知的DNS服务器提出域名解析。
也就是说hosts的请求级别比DNS高可加快域名解析。
2检查DNS配置不同DNS其速度和准确率是不一样的比如
114.
114.
1
114速度远比
8.
8.
8快如果有用到DNS特别是压测机需要考虑下是否适当3确保路由正确设置2网络带宽如果没条件在局域网下测试可能需要估算所需大致带宽。
如果测试时是基于UI层操作的操作那么得估算页面平均大小这个可以通过浏览器自带工具查看打开单个页面服务器返回的请求数据大小。
如果是测试时是基于接口层的请求测试可以通过工具查看服务器响应数据大小。
然后根据采集的页面PV峰值、请求数峰值进行计算。
假设在PV峰值、请求数峰值 1000峰值时段8:00 - 12:00平均页面、请求大小200k带宽 1000 x 80% / (20% x 4 x 3600s) x 200KB x /1024 x 8bit ,单位MBps注意这里涉及到浏览器缓存等因素估值可能不准大致估算。