性能测试方案设计的方法和思路

Posted 2020-08-30 烟雨琼楼

第一步获取性能需求

 

 

需求一：用户数信息

 

       1）调查系统当前和未来使用的用户数

　　系统用户数=本系统目前注册的用户数，注册用户数并不代表他会每天并且无时无刻的使用着。

　　在线用户数=同时在线对系统进行操作的用户数量（相当于混合场景）

　　并发用户数=同时在线并且同时操作同一个功能（单场景添加集合点）

　　估算未来一到五年使用此用户的数量，可以根据一些日志数据估算出来的。

　　2）调查系统当前和未来的每日、月活跃用户数

　　当前活跃用户数，即某天大概有多少用户使用本系统：那么这部分数据一说来也就是当前真正对系统构成压力的数量。

　

 

需求二：业务数据量

 

       1）调查当前和未来背景数据量

　　因为从100条数据中查10条也许很快，但是未来数据量变成100w那你懂得...

　　2）调查当前和未来业务每天使用的总笔数

　　每个用户每天可能下多少笔单，平均需要多少次来执行这个操作？那么根据用户数，我们就可以确定每天下单的笔数。如50人，平均每人每天下10次，每次下100笔，那么总笔数就是50*10*100=50000笔。注意此数据根据TPS换算后，我们可以换算出系统的业务总处理量是否能达到这个数据，这也是一个很重要的指标。

　　3）调查当前和未来高峰时业务的总笔数

　　即上面所描述的特殊情况，这也是必须要考虑，并且拿到的数据。

 

 

 

需求三：场景业务的调查

 

        1）系统关键、核心的业务

　　从系统亮点出发，以主要的业务逻辑点为第一核心：这些功能对系统或公司来说往往具有举足轻重的地位，无论怎样都必须要优先执行满足这以功能的性能测试

　　2)高访问量的功能，经常承受压力的功能点

　　系统中表现在系统关键、核心业务前面必须要经过的地方：比如对于百度搜索来说，其核心业务是搜索功能，但是首先要面对的其高访问量对是搜索输入框加载的首页，百度首页加载即高访问量的请求

　　3)业务复杂度高

　　往往说来业务逻辑复杂度的都具备1、2点的要素，可能其功能使用的人数较少但是对系统有很严重影响：这些功能由于其业务逻辑具有的复杂度，往往出错的可能性也比较高，所以这些功能也是必须要进行测试的。

 

需求四、与性能指标指标相关的调查

 

        1、调查每秒事务数(TPS)

　　这是衡量系统处理能力的一个重要指标，同时这个指标在一定程序也关系到业务数量是否能够及时完成，所以需要获得。

　　估算方式一：BS类可以参考以下指标估算：Vuser*TRequest/RPS=TPS（注意1Requset的含义为Resource=0的请求）。Resource=0的含义其实就是保证此次请求能够真正到达服务器，去掉那些本地可以缓存的东西。

　　估算方式二：CS类可以参考每小时的业务数/3600s，这是没办法的办法。

　　估算方式三：API类往往要求是Vuser*1API=TPS，由于公司的API都是提供给机构用户的，所以API要求往往比较高，所以需要保证其远算得非常快。

　　注：Vuser：虚拟用户数；TRequest：事务中的请求数；RPS：平均响应时间。

　　2、调查90％（或95％）响应时间

　　只看平均时间是不太科学的，对于我们的系统来说需要保证绝大多数的用户其响应时间都是非常快的，所以我们从90％或95％用户响应时间为指标的标准。

　　如果拿不到，那么我们仍可以估算：

　　估算方式一．BS类，按通用的标准2一5一8的标准来进行。不同业务，不同客户类型要求不同，但对于我们的产品来说绝大多数是不能超过5s

　　估算方式二：CS类，根据处理的数据量其时间不同，但一般说来是不能超过15s的。

　　估算方式三：API类，从行业的角度来说，一般要求是毫秒级（<500ms)

　　3、平均响应时间和TPS的波动率

　　这是对响应时间的补充，要求其系统响应时间应尽量稳定，TPS的波动率受测试方法和思考、间隔时间的影响。可参考以下的计算方式：

　　T=（TPS标准差/TPS平均值）*100％一般说来小于10％

　　T= (RPS标准差/RPS平均值）*100％一般说来小于10%

　　----小知识：测试的分类-------------------

       第一类前端性能测试（客户端）

　　B/S：HttpWatch、FireBug、YSlow、JS内存泄漏、大数据量下的功能测试、浏览器长时间运行的稳定性测试等。

　　C/S：内存泄漏、CPU使用、显卡使用等：

　　网络性能测试：利用工具分析网络传输以及延时等，为宽带拓展做铺垫。

       第二类服务器端性能测试

　　性能测试，是指以性能预期目标为前提，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。（即：系统是否满足预定的性能目标？）

　　负载测试，是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到临界值，例如某种资源已经达到饱和状态等：（即，最大并发数是多少？在什么时候，响应时间不可接受”系统的服务器资源瓶颈是什么？）

　　稳定性测试，是指被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。（即系统在一般压力条件下，是否可以提供连接不断的优质服务？系统在长时间最大压力条件下，是否崩溃？）

        4、测试前环境的检查收集

　　环境检查包括服务器的架构以及部署方案，服务器的配置、中间件的参数配置，以及需求、功能测试报告、API调用方式等。

　　服务器的配置需要收集生产环境与实测试环境的服务器的配置。主要收集：

　　CPU：型号、核心、速度、核数、倍频、总线速度，己耗费平均CPU

　　内存：总物理内存、所在磁盘的虚拟内存、可用物理内存

　　磁盘：转速（如是旧有电脑，在执行前最好磁盘碎片整理一下）

　　网卡：一般是100Mb，专用网络可能在1000MB以上。

　　业务

　　跟据客户实际使用情况，划分业务比例：

　　某个功能在一段时间内的使用频率：每天使用此功能大概有多少次？在多长时间内会操作此功能？

　　如设计脚本用例为：登录>进入单表查询（70％）>通过目录导航（80％）>检索>下载（80％），根据功能的重要性，这个用例应该首先要测试单场景，并且并发数也可能比其它的功能大一些，所以需要设置集合点。

　　其它业务相对于使用得少一些的则可以将其与上面的用例组合成混合场景：其它场景也可以继续细分。

　　思考时间

　　观察、推测用户操作这一个过程的时间

　　以一个正常用户使用系统业务的角色，录制脚本随机产生，随后根据实际情况调整其值：在运行场景的时候，以50％至120％的比例随机使用思考时间

       5.持续时间

　　用户操作此功能的时间段，采用二八定理，取80％的场景时间：

　　注意用户操作此功能时间段，如果是业务类软件，中午的时间要去掉：

       6.加载和退出方式

　　一般采用缓慢登录的方式，以便观察当用户数降低时其服务器的资源情况。但登录和退出功能除外，更多的登录和退出是集中在一个时间段。

　　下图展示了如何将整个系统，按照用户操作业务的比例来构成一个整体的认识，通过功能的比例，我们很容易就可以得出其性能测试需求覆盖哪些功能

        监控方法

　　由于监控采集记数器也会消耗资源，所以初次测试的时候应尽量把适合的记数器加上，而当判断某个资源出现情况时需要添加更详细的记数器，：

　　建议初次测试的时候监控值

　　CPU:%ProcessorTime和%PrivilegedTime和ProcessorQueueLength

　　Memory：AvailableMbytes和PageFaults/Sec

　　PhysicalDisk：%DiskTime和Avg.DiskQueueLength

　　监控所有服务器，另外也需要监控压力机的资源。