51Testing软件测试论坛
标题: 《LoadRunner没有告诉你的》之六——获取有效的性能需求 [打印本页]
作者: jackei 时间: 2006-12-12 01:03
标题: 《LoadRunner没有告诉你的》之六——获取有效的性能需求
版权声明：本文可以被转载，但是在未经本人许可前，不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载，请在转载是保留此版权声明，并保证本文的完整性。也请转贴者理解创作的辛劳，尊重作者的劳动成果。
作者：陈雷 (Jackei)
邮箱：jackeichan@gmail.com
Blog：http://jackei.cnblogs.com
本文是《LoadRunner没有告诉你的》系列的第六篇，我将继续保持“无废话”的原则，用尽可能简洁、明确的语句来表述我对性能测试的看法和经验。在这篇文章中，我们要讨论的是如何获取“有效的”性能需求。
一个实际的例子
为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。
这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的 ^_^
l 系统总容量达到日委托6000万笔，成交9000万笔
l 系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔
l 实际股东帐号数3000万
这个例子中已经包括几个明确的需求：
l 最佳并发用户数需求：每秒7300笔
l 最大并发用户数需求：峰值处理能力达到每秒10000笔
l 基础数据容量：实际股东帐号数3000万
l 业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型
什么是“有效的”性能需求？
要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。
1. 明确的数字，而不是模糊的语句。
结合上面的例子来看，相信这个应该不难理解。但是有的时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。关于这方面的内容，在下面两篇文章中的留言内容中有精彩的讨论：
2. 有凭有据，合理，有实际意义。
通常来说，性能需求要么由客户提出，要么由开发方提出。对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。
3. 相关人员达成一致。
这一点非常关键。如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认，那就把这个责任交给你的直属领导；如果你就是领导了，那这领导也白当了 ^_^
如何获得有效的性能需求
上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：
1. 客户方提出
这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。
2. 根据历史数据来分析
根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。
3. 参考历史项目的数据
如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。
4. 参考其他同行类似项目的数据
如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。
5. 参考其他类似行业应用的数据
如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。
6. 参考新闻或其他资料中的数据
最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。
又一块砖抛出来了，希望大家在看完之后也有更多的玉丢过来 ^_^
点击这里了解整个系列的创作进度，查看文章目录，或浏览已经完成的文章。
[ 本帖最后由 jackei 于 2006-12-12 01:05 编辑 ]
作者: dingle_lily 时间: 2006-12-12 10:47
不错，学习中
这段时间也在做性能测试，但是苦于没有任何的指标
作者: wuhuawu09 时间: 2006-12-12 11:23
又有新的了,在学习,还是不太理解..谢谢楼主.......
作者: jackei 时间: 2006-12-12 13:15
原帖由 wuhuawu09 于 2006-12-12 11:23 发表
又有新的了,在学习,还是不太理解..谢谢楼主.......
有哪些地方不明白的？说说，大家讨论一下 ^_^
作者: wuhuawu09 时间: 2006-12-12 15:46
一个实际的例子 中数据很明确,但就是不知道怎么对应到LR结果中...
BLOG上的讨论也看了,还在学习中......没做过性能测试呢.也没有真正的需求..
哈.初学中,有问题了再来请教...
作者: beiyu95 时间: 2006-12-13 15:23
经验之谈，难得一见的好帖。有些事情看起来容易，做起来难，能有条理的讲给大家就更需要水平了。
作者: picture 时间: 2006-12-13 16:48
楼主能不能讲点LR实际操作的东西啊!理论的东西不能当工作做啊!实际工作中还只要靠工具测出来数据后再分析的啊,我觉得这个论坛里新手还是多点,所以讲点实际操作的技巧或是使用经验比理论要好点!个人观点
作者: zhaoxu2003 时间: 2006-12-17 16:08
谢谢了
作者: jackei 时间: 2006-12-17 23:00
感谢楼上各位的支持 ^_^
原帖由 picture 于 2006-12-13 16:48 发表
楼主能不能讲点LR实际操作的东西啊!理论的东西不能当工作做啊!实际工作中还只要靠工具测出来数据后再分析的啊,我觉得这个论坛里新手还是多点,所以讲点实际操作的技巧或是使用经验比理论要好点!个人观点
我想你需要有更多工作经验以后才能真的理解这篇文章中所讲解的东西。——就像编写会自动化测试脚本不能算作会作测试一样，LR 用的熟练并不代表性能测试做得好。
作者: picture 时间: 2006-12-18 09:23
标题: 回复 #9 jackei 的帖子
我知道能编写自动化测试脚本不能算会做测试,但还有一点我也是知道,不会使用测试工具的人肯定不能算是会做自动化测试的人!
作者: jackloo 时间: 2006-12-18 09:39
呵呵，对这一章我提一点批评意见啊，因为我觉得你在这章里讲浅了。
在软件开发过程中，需求管理要远远简单于需求开发，CMMI中也体现了这一点，并且实际工作中也常常需要我们为客户来开发这部分的性能需求。
还希望你能考虑一下，如何根据客户的实际使用或粗线条的性能要求来开发满足客户需要的性能需求来。
作者: jackei 时间: 2006-12-19 00:07
标题: TO jackloo
嗯，jackloo 兄的意思是应该把每一条再细化下去，让它们更具有可操作性一点，是吧？
作者: jackloo 时间: 2006-12-19 04:53
可能是我说得不太清楚。
就拿你文中例子来说，客户告诉我们“系统总容量达到日委托6000万笔，成交9000万笔；系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔”，那我们将客户的这个要求管理起来并实现了这一点，这叫需求管理；而如果我们根据以下2个假设：
1。采用2/8比例，即80%的业务在20%的峰值时间内完成，20%的业务在80%的非峰值时间内完成，那么我们可以得到峰值处理业务量1.5亿的80%为1.2亿，非峰值处理业务量1.5亿的20%为3000万；
2。1天系统运行时间为20小时，另4小时为非营业的后台处理时间，那么峰值时间20小时的20%为4小时，非峰值时间20小时的80%为16小时。
我们可以计算到：
1。平均峰值处理速度1.2亿/4*3600秒接近9000个/秒；
2。平均非峰值处理速度3000万/16*3600秒约500个/秒；
考虑到特殊情况的发生，我们建议实际峰值处理速度要能达到理论计算的平均峰值处理速度的1.5到2倍，所以最终确定下来的建议峰值处理速度为9000个/秒*2=18000个/秒。我们拿这个结果向客户说明，告诉他们原来的需求很可能在发生特殊情况时无法有效处理，客户最终接受了我们的说法并调整了他们的需求。
这叫需求开发，通过分析修正了客户的不合理需求，满足了他们最根本的需要“系统总容量达到日委托6000万笔，成交9000万笔”，而处理速度是他们根据自己的需要估算出来的，并不准确。
所谓需求开发，也就是根绝客户的核心需求，为客户设计完整的需求体系，甚至根据客户的业务发展需要，为客户设计核心需求和需求体系。
在我说的这个例子中只用了1个计算，而实际的需求开发中需要做调研、出可研报告、做需求方案、设计等一整套的工作。
作者: jackloo 时间: 2006-12-19 04:58
这里的设计不是后面阶段的系统设计，而是根据需求方案进行需求分解，设计整个需求体系。
作者: jackei 时间: 2006-12-19 10:58
原帖由 jackloo 于 2006-12-19 04:58 发表
这里的设计不是后面阶段的系统设计，而是根据需求方案进行需求分解，设计整个需求体系。
感谢，受教了 ^_^
作者: yongchengy 时间: 2006-12-24 20:22
标题: 不错，但还不够完美哦
不错，但还不够完美哦
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) |
Powered by Discuz! X3.2 |