如何证明你的性能测试结果可信?

经常和一些同行在网上交流,了解到现在很多公司都在做 性能测试 ,甚至有的在公司都没有成熟的性能测试人员情况下,就拉个稍微了解点性能测试工具的人员,跑个脚本就做起了性能测试。这时候都不约而同的抛出了一个问题,我们的性能测试结论是可信的吗?结合自己的性能测试经验,针对性能测试结论的可信度,谈谈个人的一点看法。

   确定测试结果可信度,指的是性能测试结果是否稳定可靠。也就是说,测试得到的各种指标数据是不是反映了系统真实性能的情况。例如,如果同一套脚本在对同 一测试对象(即被测对象本身没有变化,例如同一页面)进行的数次测试中,一般情况下页面响应时间指标忽高忽低的话,则说明该测试缺乏信度则得到的响应时 间并不能反映系统在真实生产环境的响应时间。测试的信度与测试的效度有着密切的关系。一般说来,只有信度较高的测试才能有较高的效度,效度较高的性能指标 才有较高的实际性能分析价值和对改进性能方案进行决策时的参考价值。测试的信度主要涉及到测试工具自身的可靠性和测试环境稳定性以及测试方案成熟性这三个 方面。

  第一,测试工具自身的可靠性。

  测试工具的可靠性,主要是指测试工具本身是否有Bug,性能计数器是否准确等和性能测试工具针对当前性能测试项目的场景进行的设置是否合理。

  解决办法:

   针对性能测试工具本身功能方面,要对要使用的性能工具进行评估,商业工具和开源工具以及自己开发的工具,甚至是一些简单插件,一些小的 Application等。虽然他们的性能测试原理都是相同的。但是还是要根据项目情况和工具情况进行整体评估,特别是一些特别项目,并不是一定商业工具 就更稳定可靠,但是相对而言,商业工具功能较为丰富,简单易学习,稳定性也可以。结合成本和项目情况可以选择自己开发工具,也可以定制工具,也可以对一些工具进行部分改进,例如自己做个更加精确的计数器。

   针对工具设置方面,结合项目情况选择最合理的设置,也许run脚本时候的很多问题,就是由于设置产生的。这部分需要对使用的工具很熟悉,清楚一些常用属 性的设置场景。例如一些基本的设置:Agent和Controller的设置,scenario设置,counter sets,run setting。

  第二,测试环境稳定性。

  测试环境的稳定性对性能测试结果的重要性,相信已经都深有感触。每个项目做性能测试方案时候都要梳理一遍可能影响request的开关,过期时间等设置。

  解决办法:

  首先要尽可能建立一个独立的性能测试环境,即使一些大型程序,例如大型的电子商务网站,数据库过于庞大,难以建立独立的性能测试数据库环境,也要对性能测试数据进行一些标识,建立环境时候,要确保web server上的版本和windows server版本相对应,即时根据测试方案要求更新测试版本。要对一些用的cache server、Application server,搜索引擎等server集群进行合理设置。以使其符合项目性能测试的要求。

  第三,测试方案成熟性。

  测试方案是对一个性能测试从始至终的所有工作的指导。性能测试相当于做一个精密的实验,方案的精密严谨性就直接会导致得到的性能测试指标准确性,合理性。

  解决办法:

   首先要熟悉该次性能测试的目的,和测试需求。深入分析需求,提取出一些关键点,熟悉涉及到相关部分的业务,特别是涉及到request的,是Html请 求,还是Ajax请求,请求中是否包含动态数据,例如一些cookie参数等。根据以上了解,提取出性能测试场景。给出详细的测试场景执行方案,以及测试 指标名称。给出性能指标分析策略。取数据的策略(例如重测法,交替形式法,对半法等)。

  测试执行过程中要时刻保持精密的思想,确保性能测试从始至终都要有据可依,有理论可考。最终才能得出具有很高参考价值的性能指标数据,这样才能得出有效的性能测试结论。


本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

某网站性能测试用例 某网站提供会员模板下载、上传、购买、支付等功能,目前进入性能测试阶段,通过性能需求可以了解到主要有以下几个性能指标需要进行测试:   ● 产品页面刷新性能   ● 产品上传性能   ● 产品下载性能   目前给出的指标为:   延迟:   测试项 响应时间 抖动 备注   产品页面刷新 <5秒 <2秒   产品下载相应时间 <4秒 <2秒   吞吐量:   编号 项 吞吐量   Perf.T.1 所有登录用户在线状态更改频率 每10分钟1次   Perf.T.2 每日页面平均访问量 60000次   Perf.T.3 每日下载量 50000   Perf.T.4 平均每日新增会员数量 500   Perf.T.5 高峰同一模板下载量 100用户并发下载   Perf.T.6 高峰不同模板下载量 150用户并发下载   容量:   编号 项 容量   Perf.C.1 用户数 <=100万   Perf.C.2 活动用户数 10000   Perf.C.3 模板中心总用户数 <=25万   根据如上性能需求及数据我们该如何设计性能测试用例及场景呢?(可以说给出的性能需求很垃圾,没有丝毫价值,但没办法还是点做啊)   首先,我不去在乎它要求的性能是什么,我只需要去做在一定的测试环境下对系统进行压力测试,找到各个性能指标的临界点就好了,至于是否达到性能指标,在和性能需求对照编写测试报告即可。   所以,针对这几个需要进行性能测试的页面,我们做一下分析,如何设计场景才能尽可能准确地体现出系统的性能:   先说一下搜索页面   搜索页面根据对项目的了解,搜索后,将所有符合条件的结果遍历出来,显示在前台,每页的显示数量是一定的,超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面,对于页面显示对性能的消耗我们可以忽略不计,主要的压力来自数据的传输、sql的执行及应用服务器的处理过程,所以我可以从两个方面设计场景:   a、虚拟用户一定,不同数据库数量级的情况下,搜索的性能   如何确定虚拟用户的数量成为一个关键,我们可以让客户提供一个常规情况下每天访问用户数(如果没有实际数据可参考,可以根据产品方案中期望的用户数来代替),我们就用这个用户数来进行测试;再来分析一下不同的数据库数量级,如果系统运营1年的产品数据量是5万条,那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试(具体的分法可以根据实际情况而定),所以对于这个测试目标,我们可以设计5个场景进行:   虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间   100 10000 搜索页面 随机产生 30分钟 加入思考时间   100 30000 搜索页面 随机产生 30分钟 加入思考时间   100 50000 搜索页面 随机产生 30分钟 加入思考时间   100 100000 搜索页面 随机产生 30分钟 加入思考时间   100 200000 搜索页面 随机产生 30分钟 加入思考时间   b、一定数据库数量级,不同量虚拟用户的情况下,搜索的性能   我们定下来一个常规的数据库数据量,在数据量不变的情况下逐步增加虚拟用户数,测试一下不同虚拟用户压力下系统的性能   虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间   50 50000 搜索页面 随机产生 30分钟 加入思考时间   80 50000 搜索页面 随机产生 30分钟 加入思考时间   100 50000 搜索页面 随机产生 30分钟 加入思考时间   120 50000 搜索页面 随机产生 30分钟 加入思考时间   150 50000 搜索页面 随机产生 30分钟 加入思考时间   产品上传   影响上传性能的主要因素有上传文件的大小和上传的请求数,所以我们就从这两个方面设计用例。   a、虚拟用户数一定,上传不同大小的文件   虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间   50 100k 上传页面 随机产生 30分钟 取消思考时间   50 300k 上传页面 随机产生 30分钟 取消思考时间   50 500k 上传页面 随机产生 30分钟 取消思考时间   50 800k 上传页面 随机产生 30分钟 取消思考时间   50 1M 上传页面 随机产生 30分钟 取消思考时间   b、上传文件大小一定,不同量的虚拟用户   虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间   20 300k 上传页面 随机产生 30分钟 取消思考时间   50 300k 上传页面 随机产生 30分钟 取消思考时间   80 300k 上传页面 随机产生 30分钟 取消思考时间   100 300k 上传页面 随机产生 30分钟 取消思考时间   产品下载   影响下载性能的主要因素有下载文件的大小和下载的请求数,所以我们就从这两个方面设计用例   a、虚拟用户数一定,下载不同大小的文件   虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间   50 100k 下载页面 随机产生 30分钟 取消思考时间   50 300k 下载页面 随机产生 30分钟 取消思考时间   50 500k 下载页面 随机产生 30分钟 取消思考时间   50 800k 下载页面 随机产生 30分钟 取消思考时间   50 1M 下载页面 随机产生 30分钟 取消思考时间   b、下载文件大小一定,不同量的虚拟用户   虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间   20 300k 下载页面 随机产生 30分钟 取消思考时间   50 300k 下载页面 随机产生 30分钟 取消思考时间   80 300k 下载页面 随机产生 30分钟 取消思考时间   100 300k 下载页面 随机产生 30分钟 取消思考时间
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值