性能测试知多少---性能需求分析

性能测试知多少---性能需求分析

　　需求分析是个繁杂过程，它并非我们想象的那么简单，而性能测试需求除了要对系统的业务非常了解，还需要有深厚性能测试知识。才能够挖掘分析出真正的性能需求。

　　如何获得有效的需求

　　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（虚拟用户）

　　如何把需求转换成性能指标

　　我们把200万vu转换成一系列的指标

　　™响应时间：根据国外的一些资料，一般操作的响应时间为2，5，10秒，2秒内优秀，5秒内良好，10秒内可接受，其它一些特殊的操作，如上传，下载可以依据用户体验的情况，延长响应时间。

　　™吞吐量：可以根据已经上线的类似产品进行估计。或者，采用80/20原则进行估计。我们经常使用的是80/20原则。

　　80/20原则：又称帕累托效应，比如，80%的社会财富掌握在20%的人手里。

　　应用于测试：从vu计算吞吐量？根据80/20原则，80%的用户会在20%的繁忙时间内登陆。则繁忙时间每秒大概会有（2000000*80%）/（24*3600*20%）=100个用户登陆 ，也就是说，登陆操作的吞吐量是100TPS

　　如何根据性能需求进行测试

　　其实我们上面得到的需求指标仍然是不明确的：

　　是验证当前硬件和软件配置能否支撑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

　　----------------------

　　上面的小案例算是抛出的一块砖，需求开发难度要远远大于需求管理，在实际工作中常常需要我们为客户开发这部分性能需求。所以，在追求技术的基础上，请更多的了解分析你的项目及行业指标。

相关链接：

性能测试知多少----性能测试分类之我见

性能测试知多少---并发用户

性能测试知多少---吞吐量

性能测试知多少---响应时间

性能测试知多少---了解前端性能

性能测试知多少---性能测试工具原理与架构

性能测试知多少---性能测试流程