测试主管和经理们，让你的性能测试团队走出困境，立于不败之地！
介绍
作为一项工作，性能测试被人们，尤其是那些测试主管和经理们的普遍误解。这种误解会带来很多麻烦——包括项目彻底的失败。本文详细的谈一谈我在给那些测试主管和经理们上课时一遍又一遍谈到的话题。学习，理解，并将这些知识应用于你的性能测试项目中，会让你很快的走向成功！
重视经验
经验丰富的性能测试员会用你能听得懂的话，指导你实现你的目标，即使你还无法描述那些目标。经验丰富的性能测试员不仅知道如何用商业危机，短、长期成本以及计划变动的影响等术语和测试主管打交道，他们更知道如何避免用行话，和技术语言解释自己的工作。经验丰富的测试员习惯于解释最新的“ performance buzz ”与你的系统的相关性。他们花了几年的时间从一些孤立起来毫无意义的单词，比如：“快速”，“最大吞吐量”，“ *** 同时在线用户”，提取测试目标。看一下这个例子：某个测试主管要求，“每一页都要百分之百的在 * 秒内显示。”虽然这是可以量化和测试的，但是这句话本身没什么意义。性能测试员的工作就是确定目标应用在什么样的环境下，换句话说，就是确定目标的所属的环境。为了使目标有意义，它必须注明诸如用户连接速度，登陆到网站的用户有多少，以及这些用户在从事什么样的活动等。这些都是影响网页反应速度的变量。一个完整一些的测试目标应该用这种格式写：
在“ peak order ”工作量模式下，在每小时 500 用户量负载的情况下，静态网页反应时间在 * 秒内，动态网页的反应时间在 ** 秒内，而搜索、排序的网页会在 ** 秒内，当通过企业局域网登陆时百分之 95 的时间是不出错误的。
另外，经验丰富的性能测试员知道如何收集数据，并且会用以这种方式：“系统是否达到目标，在那些方面达到或偏离目标，偏离多少”，向那些观察者说明。而且不要求这些观察者掌握多少关于被测系统的专门的技术知识。
注意，在谈到性能测试时我用了“目标”并非“需求” 一词。我之所以这么做是因为，我从来没有经历过因为测试结果未能达到设定的要求而被迫延迟或取消发布的性能测试项目。我选择“目标”一词的另一个原因是实际上在新版本发布之前没人期望它的性能和想象中的一样优秀，人们只是希望“现在够好”就行了。有人认为性能会在测试中得到优化，开发环境会解决测试环境中发现的性能问题，或者说当性能问题随着开发过程出现时，采纳上述方法可以很好的解决这些问题。一位经验丰富的性能测试员会帮助把你对性能测试的感觉转换成目标和项目计划。总之，作为一名测试主管，性能测试员要求你领会理解性能测试，这样你才能做出明智、有见地的决定。作为一名测试主管你要在程序处于开发周期时做出很多重要决策，大部分决策围绕一下三个基本问题：
1、它为什么目的而开发，能否满足需求？
2、对系统用户来说，程序功能是否足够？
3、系统用户能否轻松试用此程序？
有经验的性能测试员知道这三个问题的重要性，并且知道如何回答，他们会和你并肩工作（有时的确是在你旁边），帮助你用性能测试的术语回答以上问题。
首先也是最重要的就是你要让人知道你期望有经验的性能测试员在项目里做什么，而并非人们称呼他们的“拿着工具的傻瓜”。尽早的设定你的期望，这样性能测试员才会和你互动，给你提供足够的信息，让你对性能问题和风险做出明智的决策。无论何时，都要对性能目标有个人的看法，保证有个完整的环境使此目标对于领导层做出决策有意义。
审查性能测试计划和交付产品，然后问自己一下几个问题：
1、这有助于决策吗？
2、此计划的结果是否会给终端客户带来全新的体验
3、是否能代表真实的生产环境
4、如果需要调整，对开发人员来说是否依然有用
5、是否为每一个专门的需求、目标、或者服务等级协议提供相应的解决办法
6、是否是基于计划的结果而采取行动
最后，邀请性能测试员在工作中不断指导你。在帮助你增加对性能测试的了解的同时，测试人员自己也会非常清楚的知道在系统性能上，对你来说最重要的是什么。这种相互的理解和开放的交流是对系统综合测试最有益的事情。
在功能完全实现之前进行性能测试
人们对性能测试有个普遍的认识，那就是在软件稳定，大部分功能实现之前，进行性能测试是没有效果的，测试版或正式版发布之前是无法收集测试数据的。实际上这样做的话，一旦产品性能没有预想的那样好的话，我们是没有时间对此做出任何反应。
实际上，早在功能测试团队接到第一份测试版本之前，有经验的性能测试员就能完成大量测试任务，并且生成大量测试数据了。他会争得用户社区模式的同意，测试数据，并且能够收集一下类型的数据：
1、网络或网路服务器的吞吐量的限制
2、各种负载下，单个服务器的资源利用情况
3、搜索速度，查询最佳化，表格 / 行锁，以及数据库容量测试速度
