前言：html
在面试的时候，常常遇到有应聘者说本身的职业规划是向性能测试工程师发展。对此说一下个人见解，但愿对刚接触性能测试的同行有所帮助。前端
其实真正作过性能测试的都知道，平时遇到的性能测试需求大都比较简单，只要掌握一门性能测试工具的使用基本就能完成任务。那么掌握一种性能测试工具通常用多长时间呢？ 以loadrunner为例，大约5-10个小时我就能够教会一个稍微有点性能测试基础的人上手使用——换句话说，把十个小时就能达成的目标做为职业发展方向，是否是要求过低了点呢？并且，多数小公司都不作性能测试，只有规模较大的公司或者性质特殊的项目才有性能测试的需求，即便在大公司，性能测试团队的规模也很小，通常也就两三我的（这意味着很难锻炼管理能力）。以咱们公司为例，大多数时候都在作功能测试， 功能测试完了才作性能测试，并且性能测试是阶段性的，因此即便半数以上的项目都作性能测试，我也不会招专门的性能测试人员——由于工做不饱满。最后，就我我的而言，我以为性能测试作多了也挺无聊的——翻过来覆过去就是那么点东西。ios
因此，我以为性能测试适合作一个技能，但不适合作一个职业发展目标。面试
正文数据库
言归正传，要设定性能测试的目标避免不了要了解此次性能测试的目的（好比是测负载，测压力，测优化效果仍是测稳定性），以及测试侧重点，而后肯定使用的工具，好比测前端性能可使用findbugs、fiddler，测试后端的性能（也就是服务器端的性能）可使用loadrunner、soupui等。后端
我曾经见过作了一两年手机APP测试的同行，在被问到如何对手机APP进行压力测试时，只回答用monkey作。——其实monkey的官方介绍文档里很清楚的说明了它只能作客户端的压力测试，没法作对服务器端的压力测试。服务器
也曾见到一些刚接触性能测试的测试人员，虽然掌握了工具的使用，但却仍然不会作好性能测试，缘由之一是不清楚如何设定性能测试的目标。也就是今天要讨论的重点。微信
一个实际的例子
这是一个证券系统中某个业务的“实际需求”session
系统总容量达到日委托6000万笔，成交9000万笔并发
系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔
实际股东账号数3000万
这个例子中已经包括几个明确的需求：
最佳并发用户数需求：每秒7300笔
最大并发用户数需求：峰值处理能力达到每秒10000笔
基础数据容量：实际股东账号数3000万
业务数据容量：日委托6000万笔，成交9000万笔——能够根据这个推算出每周、每个月、每一年系统容量的增加模型
什么是“有效的”性能需求？
要想得到效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合如下三个条件。
1. 明确的数字，而不是模糊的语句。
结合上面的例子来看，相信这个应该不难理解。可是的时候了数字未必就不模糊。例如常见的一种需求是“系统须要支持5000用户”，或者“最大在线用户数为8000”。这些数字的需求仍然不够明确，由于还须要考虑区分系统中不一样业务模块的负载，以及区分在线用户和并发用户的区别（参考http://www.cnblogs.com/scios/p/5413666.html）。
2. 凭据，合理，实际意义。
一般来讲，性能需求要么由客户提出，要么由开发方提出。对于第一种状况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种状况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜想，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍得到可用的数据和计算公式的方法。
3. 相关人员达成一致。
这一点很是关键。若是相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，一般项目型的项目的须要与客户方的项目经理或负责人进行确认，产品型的项目须要与直属领导或者市场部进行确认。
如何得到效的性能需求？
1. 客户方提出
这是最理想的一种方式，一般电信、金融、保险、证券以及一些其余运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。
2. 根据历史数据来分析
根据客户以往的业务状况来分析客户的业务量以及每一年、每个月、每周、天天的峰值业务量。若是客户旧的系统，能够根据已系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不一样行业、不一样应用、不一样的业务是各自的特色的。例如，购物网站在平时的负载主要集中在晚上，可是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还周一到周五的一早一夜下班时间。
3. 参考历史项目的数据
若是该产品已其余客户使用，而且规模相似的，能够参考其余客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。
4. 参考其余同行相似项目的数据
若是本企业没作过相似的项目，那么能够参考其余同行企业的公布出来的数据——一般在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。
5. 参考其余相似行业应用的数据
若是没法找打其余同行的数据，也能够参考相似的应用的需求。例如作IPTV或者DVB计费系统的测试，能够参考电信计费系统的需求——虽然不能彻底照搬数据，可是能够经过其余行业成熟的需求来了解须要测试的项目有哪些，应该考虑到的状况有哪些种。
6. 参考新闻或其余资料中的数据
最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，一般能够经过各类新闻媒体找到一些可供参考的数据，可是须要耐心的寻找。例如咱们在IPTV和DVB系统的测试中，能够根据新闻中公布的各省、各市，以及国外各大运营商的用户发展状况和用户使用习惯来估算系统容量和系统各个模块的并发量
如何“去伪存真”？
在软件开发过程当中，需求管理要远远简单于需求开发，CMMI中也体现了这一点，而且实际工做中也经常须要咱们思考，如何根据客户的实际使用或粗线条的性能要求来开发知足客户须要的性能需求来。
还拿文中例子来讲，客户告诉咱们“系统总容量达到日委托6000万笔，成交9000万笔；系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔”，那咱们将客户的这个要求管理起来并实现了这一点，这叫需求管理；而若是咱们根据如下2个假设：
采用2/8比例，即80%的业务在20%的峰值时间内完成，20%的业务在80%的非峰值时间内完成，那么咱们能够获得峰值处理业务量1.5亿（6000w+9000w）的80%为1.2亿，非峰值处理业务量1.5亿的20%为3000万；
1天系统运行时间为20小时，另4小时为非营业的后台处理时间，那么峰值时间20小时的20%为4小时，非峰值时间20小时的80%为16小时。
咱们能够计算到：
平均峰值处理速度1.2亿/4*3600秒接近9000个/秒；
平均非峰值处理速度3000万/16*3600秒约500个/秒；
考虑到特殊状况的发生，咱们建议实际峰值处理速度要能达到理论计算的平均峰值处理速度的1.5到2倍，因此最终肯定下来的建议峰值处理速度为9000个/ 秒*2=18000个/秒。拿这个结果向客户说明，告诉他们原来的需求极可能在发生特殊状况时没法有效处理，客户可能就会接受咱们的说法并调整了他们的需求。
这叫需求开发，经过分析修正了客户的不合理需求，知足了他们最根本的须要“系统总容量达到日委托6000万笔，成交9000万笔”，而处理速度是他们根据本身的须要估算出来的，并不许确。
说明：1）所谓需求开发，也就是根绝客户的核心需求，为客户设计完整的需求体系，甚至根据客户的业务发展须要，为客户设计核心需求和需求体系。2）在我说的这个例子中只用了1个计算，而实际的需求开发中须要作调研、出可研报告、作需求方案、设计等一整套的工做。
“并发用户数”、“系统用户数”和“同时在线用户数”的计算公式
（1）计算平均的并发用户数：C=nL/T
（2）并发用户数峰值：C’≈C+3根号C
公式（1）中，C是平均的并发用户数；n是loginsession的数量；L是login session的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中获得的平均的并发用户数。该公式的得出是假设用户的loginsession产生符合泊松分布而估算获得的。
实例：
假设一个OA系统，该系统有3000个用户，平均天天大约有400个用户要访问该系统，对一个典型用户来讲，一天以内用户从登陆到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），能够获得：
C=400*4/8=200
C’≈200+3*根号200=242
说明：这个公式的真伪有待验证。
结束语
最后，从我了解的状况来看，多数公司作性能测试时只须要看看系统在不一样并发下的TPS和平均事务处理时间，以及支持的最大并发。那么做为测试人员，咱们只要给出三个指标便可：TPS，平均事务响应时间，是否支持横行扩展。
本文分享自微信公众号 - 软件测试经验与教训（udatest）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。