摘要:性能测试需求的质量直接影响性能测试的效果,在分析web应用系统性能测试目的的基础上,提出性能测试需求描述要达到准确、一致和特定的要求,进一步明确性能测试需求必须要确定4w1h,即性能测试的需求必须包含where,what,when,who和how,并综述了几种有效的获取性能测试需求的方法。
关键词:性能测试;测试需求;需求获取
1 引言
基于web服务器的应用系统由于提供浏览器界面而无须安装,大大降低了系统部署和升级成本而得以普遍应用。目前,很多企业的核心业务系统均是web应用,但当web应用的数据量和访问用户量日益增加,系统不得不面临性能和可靠性方面的挑战。因此,无论是web应用系统的开发商或最终用户,都要求在上线前对系统进行性能,科学评价系统的性能,从而降低系统上线后的性能风险。
在很多性能测试项目中,由于不能合理定义系统的性能测试需求,不能建立和真实环境相符的负载模型,不能科学分析性能测试结果,导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。因此,性能测试需求分析的正确性是整个性能测试工作的最基本前提。若不能保证性能测试需求分析的正确性,即使性能测试工具使用的再正确,性能测试执行的再顺利,也无法保证性能测试达到预期的效果,即可能无法发现性能瓶颈、或者发现不了实际情况中应该出现的瓶颈。
本文从分析性能测试的目的出发,提出性能测试需求描述的三个要求,综述性能测试需求的获取常用方法。WWW.133229.cOm
2 性能测试的目的
性能测试的目的不仅是发现软件缺陷,还可能包括以下几个方面:
(1)验证能力。这是性能测试中最简单也是最常用的一个应用领域,典型的能力验证问题会采用这样的描述方式:“***系统能够在***条件下具有***能力?”。通常情况下,企业在进行项目验收阶段要求能力验证型的性能测试或者委托第三方软件测试机构开展独立的性能验证,其主要特点是在已确定的生产环境中实际使用被测系统,即这套系统能不能承受大量的并发用户同时访问?常以典型场景设计测试方案和用例。
(2)规划能力。这与(1)有较大的不同,以规划能力为目的的性能测试关注的是“应该如何才能使系统具有要求的性能能力?”或者“系统能否支持未来一段时间内的用户增长?”,因此,这种性能测试强调对系统当前性能的评估,通过评估可以在应用实际部署之前,预见系统负载压力的承受能力。
(3)调优性能。性能调优是以第一种或第二种为目的的性能测试实施后提供原始数据进而分析系统瓶颈和优化为目的,因此(3)常与其他的性能测试活动交杂在一起。该类性能测试需要在确定的基准环境下,采用基准负载,关注基准性能指标后,调整系统运行环境和实现方法,执行测试,记录测试结果进行分析,再调整、执行、分析,不断往复,直到系统性能达到要求为止。比如:用户提出业务操作响应时间长,如何定位问题,调整性能?
3 性能测试需求描述要求
(1)准确。如**系统必须在不超过 10 秒的响应时间内,处理 20 起登录和注销系统任务。再如**搜索时间最大不超过5秒以及平均时间在1～3秒以内。
(2)一致。开发工程师、用户和性能测试工程师对有关术语的理解要一致,如:并发用户数、动态用户数、静态用户数:
静态用户(注册用户):3500以上
动态用户(在线用户):1500以上
并发用户:500以上
(3)特定。性能测试的需求一定是有条件的,如:
检查系统在 200 个用户的负载下,所有业务动作是否可用及稳定;
检查系统在300 个用户的负载下,连续运行 72 小时过程中,订单上传、转单、详情单查询、发运等业务动作是否可用及稳定;
检查系统在 8.0 gb 业务数据、1500 个用户、500 个并发用户运行的负载下,连续运行 72 小时过程中,以上业务动作是否可用及稳定。
因此,性能测试需求必须要包含有多少用户(who)在什么时间(when)或者持续多久(when)进行了什么业务(what),最终需要关注怎样的指标(how)。除此以外,需要根据项目性质和性能测试的目标来获得性能测试需求的来源(where),归纳为4w1h。下面将介绍一些常用的性能测试需求获取的方法。
4 获取性能测试需求的方法
性能测试需求是应用需求的衍生,既需要借助于相关的理论知识,又要依靠测试工程师在相关领域的经验积累,根据前面4w1h的性能测试需求的要求,即对性能测试需求进行整理,确定恰当的并发用户数、在适当的时间进行典型的业务活动时,关注的性能指标有怎样的结果,笔者根据多次性能测试实践经验,总结获取性能测试需求的方法如下。
4.1 性能需求信息来源(where)
(1)开发过程相关文档。这是性能测试需求的主要来源,项目开发计划书、需求规格说明书、设计说明书、测试计划等文档都可能涉及性能测试的要求,通过收集这些资料,可以找到初步的性能需求。相关的项目干系人有客户代表、项目经理、需求分析员、系统架构设计师、产品经理等。
(2)相似项目性能需求。公司的其他产品或项目会累积出一些数据,如:**技术论坛一小时最多能发1000新帖;****博客平均每天新增800篇,以这些数据为确认新项目测试需求的基础。
(3)业界公认标准。如响应时间,根据服务器的不同和项目的具体情况可能有两类标准:
a类标准——
4秒以内,用户可以接受
4-9秒,30%用户离开
8-10秒,60%用户离开
超过10秒,90%用户离开
b类标准——
8秒,用户可接受
16秒,50%用户离开
32秒,90%用户离开
(4)用户使用模型。性能测试要通过一系列场景的执行来完成,分析用户的使用模型是获取性能测试需求的有效手段,即定义系统的典型使用方式,考虑哪些用户使用系统的哪些典型业务,在什么时间段和用户数量的估计值,因此需要和最终的用户有很好的沟通,最好能够实地考察用户的应用情况。如某oa系统的每天早上8:00会有200个用户在10分钟内登录系统;每天查询交易的高峰是在9:00-11:00和下午的14:00-16:00等。
4.2 80～20原则估算测试强度(how)
80～20原理:每个工作日中80%的业务在20%的时间内完成。
举例:
每年业务量集中在8个月,每个月20个工作日,每个工作日8小时即每天80%的业务在1.6小时完成。去年全年处理业务约100万笔,其中15%的业务处理中每笔业务需对应用服务器提交7次请求;其中70%的业务处理中每笔业务需对应用服务器提交5次请求;其余15%的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后3年业务发展的需要,测试需按现有业务量的两倍进行。
每年总的请求数为:
(100x15%x7+100x70%x5+100x15%x3)x2=1000万次/年
每天请求数为:
1000/(20x8)=6.25万次/天
每秒请求数为:
(62500x80%)/(8x20%x3600)=8.68次/秒
即服务器处理请求的能力应达到9次/秒。
4.3 任务分布图(what + when + who)
任务分布图是以一种直观的方式展示性能测试需求,描述一些交易任务在24小时内的交易情况,重点关注并发用户的数量以及典型的业务操作。如表1是某网上书店的任务分布图,从中可见:12:00~16:00的交易混合程度较高,“预定图书”任务的并发用户在14:00达到最大。
