0-1性能测试需求分析
一、性能需求分析定义：了解系统非功能性需求，圈定性能测试的范围，了解系统性能指标。
1.性能测试指标：
（1）业务指标：每秒事务数TPS、响应时间RT、事务成功率等；
（2）硬件性能指标：CPU使用率、内存利用率、磁盘繁忙率等。
需求分析是个繁杂过程，它并非我们想象的那么简单，而性能测试需求除了要对系统的业务非常了解，还需要
有深厚性能测试知识。才能够挖掘分析出真正的性能需求。
如何获得有效的需求
1、客户方提出
客户方能提出明确的性能需求，说明对方很重视性能测试，这样的企业一般是金融、电信、银行、医疗器
械等；他们一般对系统的性能要求非常高，对性能也非常了解。提出需求也比较明确。
曾经有一个银行项目，已经到最后的性能测试极端，因为数据库设计不合理，导致性能出现很大的问题，
最终不得不把整合项目作废，对于这样的项目，其实从分析设计阶段就应该考虑系统的性能问题。性能测试也
一样，对于某些项目来说越早进行越好。当然，前期的性能测试为单元性能测试、接口性能测试，有别系统性
能测试。
有时候也会碰到不懂装懂的客户，提出一些无理的需求，比如只能2000人使用的OA系统，客户要求并发
用户2000，这显然是不合理的需求。这个就要看你怎么给客户沟通了。但是，千万别伪造数据欺骗客户。
2、根据历史数据分析
对于一些面向用户的独特产品，比较难定位市场的大小，可以先上一运营一段时间，通过运营可以搜集客户
资料，比如，每月、每星期、每天的峰值业务量是多少。用户以 什么样的速度在递增中。用户对系统的哪些功能
模块使用的最多，他们所点的比例等等。
收集到这些数据之后，我们就可评估系统的系统需求指标，从而进行性能测试。
3、需求分析与定位
这里根据前期的需求分析与定位，来分析确定系统性能指标。例如某省幼儿园管理系统。统计全省有多
少家幼儿园，系统的使用时间为幼儿到校之后，管理人员对幼儿的到校情况进行录入，以及幼儿的午饭，放
学情况的录入时间。经过与需求人员交流分析也能得到比较明确的性能指标。
4、参考历史项目或其它同行业的项目
如果公司之前有类似的项目经验，根据项目大小及上次性能测试的一些指标。从根据项目的规模可以制
定出相应的性能指标。
即使本公司没有类似的项目，但其它公司有类似的项目，例如做IPTV或者DVB计费系统的测试，可以参
考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项
目有哪些，应该考虑到的情况有哪些种。
5、参考其它资料数据
如果你做的是非常独特的产品，市场上没有此类型的产品，而且需求及市场也难以估计，那么只能从与
产品相关的资料中寻找痕迹了。不过，相信这样不确定性的产品，老板要承担的风险也是挺大的。^_^
需要说明的是，我上面介绍的方面并非是独立的，可以综合的使用，你可以根据客户提出的指标，再根
据历史数据以及参考同类型项目来进行。这样可以更确定你的性能指标是客户（或自己）真正需要的、最符
合项目需求的。
性能测试点的选取
* 发生频率非常高的（例如：某邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量
中占到90%以上）
* 关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）
* 资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，
或者一个查询提交请求时会检索出大量的数据记录）
对性能需求点的描述
准确
如**系统必须在不超过10秒的响应时间内,处理20起登录任务。再如发邮件时间最大不超过5秒以及平均时间
在2秒以内。
一致
用户和性能测试工程师对有关术语的理解要一致,如:并发用户数、在线用户数、注册用户数:
特定
性能测试的需求一定是有条件的。
检查系统后台关键业务数据10G、操作数据量为20K, 1500个用户、500个并发用户运行的负载下，连续运行
12小时过程中,业务操作是否满足性能需求。
常见性能需求
1、WEB首页打开速度5s以下，web登陆速度15s以下。
2、邮件服务支持50万个在线用户
3、计费话单成功率达到99.999%以上。
4、在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10TPS
5、系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时
6、这个系统能否支撑200万的vu（每天登录系统的人次）vu----Virtual user(虚拟用户)
"不成文"的性能需求指标：
响应时间：根据国外的一些资料，一般操作的响应时间为2，5，8秒，2秒内优秀，5秒内良好，8秒内可
接受，其它一些特殊的操作，如上传，下载可以依据用户体验的情况，延长响应时间。
Peter bickford在调查用户反应时发现：在连续27次即使反馈之后，第28次操作进，计算机让用户等待
2分钟，结果半数人在第8.5秒左右就走开或者按下种启键。使用了鼠标指针变成漏斗提示的界面会把用户
的等待时间延长到20秒左右，使用动画的鼠标指针漏斗提示界面则会让用户的等待时间超过1分钟，而进度
条则可以让用户等待到最后。Peter bickford的调查结果被广泛用到web软件系统的性能需求的响应时间定
义中。
第三方研究表明，如果网页是逐步加载的，先出现横幅，再出现文字，最后出现图像。在这样的条件
下，用户会忍受更长的等待时间，用户会把延迟在39秒内的也标识为“good”，超过56秒的才认为是“poor
”的。
80/20原则：又称帕累托效应，比如，某一些系统一天中80%的访问量集中在20%的时间内。
如何根据性能需求进行测试
其实我们上面得到的需求指标仍然是不明确的：
是验证当前硬件和软件配置能否支撑200万vu？
是测试当前的硬件和软件配置最多能支撑多少vu?
是帮助开发寻找性能瓶颈？
根据需求进行性能测试的过程：
首先，请你们当前软件和硬件配置下验证能否支撑200万vu。如果可以支撑200万，再增加到300万看
是否可以支撑。如果不能达到200万，那么就需要寻找一下是否有性能瓶颈，将主要的性能瓶颈解决后，再
看一下是否可以支撑200万，如果可以支撑，输出测试结果。仍然不能，请评估需要添加多少硬件设备。
通过上面流程的分析，那么我们对于需求实施过程就非常明确了。
下面看来分析某邮箱系统的需求：
按照 某某 邮箱20000万注册用户，其中日活跃用户数为1.5%的规模计算：
日活跃用户=20000*1.5%=300万
日活跃用户人均每天发6封邮件，用户使用客户端收发邮件比例20%，则：
每天发邮件投递量=300万*6*20%=360万封
如何得到每秒的邮件数？
方式一： 严格的根据2/8原则 ，80%的邮件集中在20%的时间发送。
集中发邮件数： 3600000*80%=28800000封
集中发送的时间：24*20%=4.8小时=17280秒
每秒发送邮件数：2880000/17280=166.7封/秒
方式二，根据 某某邮箱业务模型表，每天忙时集中邮件系数0.15，邮件平均峰值系数2,则：
峰值邮件量=3600000*0.15*2/3600=300封/秒
注：忙时集中系数=忙时业务量/全天业务量
在两种方式的分析中，方法二得出的结果是方法一的将近一倍，我们不要根据经验理所当然的去分析，要深
入的了解系统，我们要对行业指标及计算方式。如果按照第一种方式，性能测试达标了，但系统真正上线后
可能远远超出了我们的评估。2008年北京奥运运门票系统就是一个典型的案例。
再来分析系统的登录：
去年全年处理“WEB登录”交易约100万笔，考虑到3年后交易量递增到每年200万笔。
假设每年交易量集中在8个月，每个月20个工作日，每个工作日8小时，试采用80～20原理估算系统服
务器高峰期“WEB登录”的交易吞吐量应达到怎样的一个处理能力
200万/8=25万/月
25万/20=1.25万/日
1.25万*80%/(8*20%*3600)=1.74TPS
感谢分享
页:
[1]
