经常有性能测试人员吐槽他的困扰：我无法从项目组获得性能指标。我是测试的，你不告诉我性能指标是什么，我怎么给你测啊？我给你跑压力脚本，跑出来的结果是不是满足你要求啊？项目组的同学有时候也很郁闷：你不测我怎么知道它能跑成什么样啊。于是，在双方的扯皮中，工作磕磕绊绊的开始，磕磕绊绊的结束，有的时候最后大家还算搞明白了。有的时候工作完成后留下很多遗憾。这些典型场景，很多新手都会经历过。第一个真正困扰性能测试人员的问题就是：我该如何确定性能指标呢？
指标，在百度百科中对指标二字的解释是：衡量目标的方法；预期中打算达到的指数、规格、标准,一般用数据表示。因此性能指标肯定是预期中性能应该达到的指数、规格、标准。那么这些标准又是什么呢？首先，我们抛弃占据脑子的那些还不太熟悉的概念（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个小时。”
