测试积木-如何确定性能指标(1)

2014-05-29   出处: cnblogs.com  作/译者:skytraveler

 经常有性能测试人员吐槽他的困扰:我无法从项目组获得性能指标。我是测试的,你不告诉我性能指标是什么,我怎么给你测啊?我给你跑压力脚本,跑出来的结果是不是满足你要求啊?项目组的同学有时候也很郁闷:你不测我怎么知道它能跑成什么样啊。于是,在双方的扯皮中,工作磕磕绊绊的开始,磕磕绊绊的结束,有的时候最后大家还算搞明白了。有的时候工作完成后留下很多遗憾。这些典型场景,很多新手都会经历过。第一个真正困扰性能测试人员的问题就是:我该如何确定性能指标呢?

      指标,在百度百科中对指标二字的解释是:衡量目标的方法;预期中打算达到的指数、规格、标准,一般用数据表示。因此性能指标肯定是预期中性能应该达到的指数、规格、标准。那么这些标准又是什么呢?首先,我们抛弃占据脑子的那些还不太熟悉的概念(TPS,响应时间什么的),先想一想性能指标的本质。先举一个例子,有一个电信计费系统,它有一个业务需求:在月的最后一天平账,必须在一天内完成每个手机账户的账单计算。在这个例子中一天内完成就是一个明显的性能指标。另一个例子:经过研究发现当一个web页面打开时间需要10秒钟以上后,用户会感到不耐烦而停止浏览。因此项目经理要求网站首页完全加载时间小于10秒。第三个例子:某社交网站的一个需求是“1000万用户同时在线,用户不会感到系统变慢”。这3个例子的共同特点是什么呢?它们都是业务需求!按照很多需求分类模型,这类业务需求也被叫做非功能需求。我们的性能指标一般都是从这些非功能需求转化而来的。如何转化呢?实际就是问题的精化,我会使用上面的例子展开给大家讲解。在这之前,大家可以先参考我以前写的一篇文章《需求工程》阅读随笔-1.做什么和怎么做》来预热一下(例子会依照这个思路来)。

第一个例子:电信计费系统,它有一个业务需求,在月的最后一天平账,必须在1天内完成每个手机账户的账单计算。

作为性能测试人员,得到这样一个信息,其实还是不错的开始状态,因为这项业务指标很明确了。知道了What,我们来看一下How。

步骤1:我们有了“必须在1天内完成每个手机账户的账单计算”这个业务指标,随之而来的是2个问题:账单计算是什么?每个手机账户是多少?这样你就可以找到干系人问出你的问题了。

步骤2:我们找到了需求人员得到了这些信息“所有的账户数约1000万个”;账户账单包括“通话费用+增值服务费用”。到这里,我们对业务场景有了一个基本的了解,但又会出现两个问题:账户是如何存储的呢?账单是怎么算出来的呢?

步骤3:我们从开发人员那里要来了系统架构图,知道了系统的技术架构是如何设计的,并且知道了两个细节:采用了oracle数据库存储账目信息,通话费用和增服务费用存储在1个数据库中,开发人员编写了一个oracle的存储过程来完成所有用户的账单计算。我们这里又有一个问题:运行oralce的机器配置是什么呢?

步骤4:最后这个问题有点像先有鸡或者先有蛋的问题。就这个例子来说,机器的配置决定了用什么样的机子。我们选用什么样的软硬件环境来做这个测试呢?在实际的软件开发过程中,成熟的企业会先定义只要场景,并且找主要厂商做benchmark的POC测试。如果没有能力做测试,也可以从网上参考一下主流数据库的性能指标,如oralce的这个页面http://www.dba-oracle.com/t_benchmark_testing.htm 。如果找不到可对比的指标,就只能先在条件允许的情况下拿与生产环境相近的硬件配置先试试看了,试试看的过程其实是个测试过程,也可能变成了调优过程:)

步骤4-续:OK,这里我们比较顺利的从项目经理那里拿到了他的打算:“我们会把这个存储过程跑在两个 Xeon E7-8830*8 带有128G内存服务器做的RAC上,对了,是高端存储。这个报表太耗费计算资源了,每月最后一天出报表,客户要求结算的时间段是每月1号0点的数据到每月倒数第一天0点的数据,但机子白天还要抗生产压力,只能晚上人少的时候跑这个存储过程。我们打算晚上11点开始跑,早上6点跑完,因此不能超过7个小时。”

 

到这里,我们有了一个粗略的性能指标了:

1.硬件: Xeon E7-8830*8 带有128G内存服务器做的RAC,高端存储(需要细化)

2 软件:可以依葫芦画瓢问出来,如Oracle11g ,RHL6.3等等(需要细化)

3.场景:非生产高峰时间(需要细化,查看晚11点到次日早6点这个时段生产压力对cpu,内存,io等带来的影响。)执行出报表的存储过程,在7小时内执行完成。

4.数据:一千万左右的账户,基础业务和增值业务都有消费(需要细化)

btw,这是个简化版本。实际情况中,业务模型和技术架构会更加复杂。

 

做一个小结:性能指标是从业务需求中提取出来的,要考虑IT支撑(软、硬件),要有特定的场景,要包含数据,这些信息要不断的沟通才能获得(当然软件成熟度越高沟通越省事),这个阶段性能测试人员更像-----------记者。

看到这里可能大家还有很多疑惑,这样就行了? 当然不是,今天只是开了个头,还有2个例子呢,它们会cover其它情况,天太晚了,下次继续道来。

最后推荐大家一本书,是我看的写性能测试最好的,尤其是第三章和第四章。里边的2个实例也非常棒!可惜没有被翻译过来,大家有兴趣可以买来电子版读:


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
309° /3093 人阅读/0 条评论 发表评论

登录 后发表评论
最新文章