4、负载平衡总量，容积，效力

　　5、安全措施的速度和搜索成本

　　有些开发人员的系统构建师认为，大部分的任务都要由他们完成。但是实际上，开发人员很少又能生成足够多的，能够有效的完成任务的负载。尽早的投入性能测试人员能够小化惊讶（？），并且提供大量数据，从而大大提高查找根本原因的速度，并且尽快修复日后在项目周期中发现的性能缺陷。

　　这一点是显而易见的。要配置一个性能测试工程师贯穿项目的始终。鼓励开发团队利用测试人员的技术和资源，并作为自己的开发工具，而不仅仅是一个开发完成后的验证工具。有一点不再赘述，在项目中，要让性能测试人员在百分之 50 到百分之百的时间里从事性能相关的活动。因为技术素质已经在边栏“技术与经验”里注明，所以此人可以作为一名辅助人员被每一个实际项目团队充分利用。这里有个警告：要清楚的知道，性能测试是此人的主要责任，而并非附加义务。二者严格区别，因为当性能测试到了关键时刻的时候，和测试工程师一起工作的其他团队也到了与紧要的关头。

　　不要混淆“交付”和“完成”

　　“交付”只是给予风险做出的合乎实际情况的决策，它不应该与“完成”混淆。每一个参与过一段时间测试的人都知道当主管觉得延迟发布比发布风险大时，要配置系统，即使这意味着发布一款存在未解决或者没测试到的性能缺陷。然而，发布这款软件根本不会影响性能测试。

　　很多软件都有个实施图和接受率，这些保证负载的峰值在发布之后在很长一段时间内不会出现。那是做性能测试的黄金时间：很少被打断，数据都是实际用户产生的而并非是预计或估算的，还能够监控软件在实际硬件上运行时的性能，一般都会或得更多的资源。如果在用户达到性能极限的时候还没有计划发布维护版本来修复以前的版本，那么马上起草一份这样的计划比起不断修复出现的性能缺陷来成本效率更高。

　　计划在原始版本发布后继续性能测试，计划在第一次预期的负载高峰前推出性能加强的维护版，把这些计划从一开始合并到项目中，能够让你发布的后期版本时，用户感觉早期的版本性能还不错。这要好过直到性能调整到能够应付更大的负载时才发布新版本。

　　寻找技术和经验

　　“性能测试员在项目团队中在技术和经验的宽度和广度上有资历”。可能你以前读到过这句话，但是我保证这并非是新瓶装老酒，当我被问到“我需要什么技术水平的测试员？”时，我回答说，“你想要的是那些什么技术都是中等水平的测试员。”“技术和经验”侧栏列出了性能测试员必备的专业技术。这成了一个求职咨询和自身技术培训的问题了。据我的经验，我觉得，一个的性能测试员应该能够回答面试人员经常问那些中等水平的开发人员，数据库管理员，系统管理员们的问题。显然，并非功能测试人员的标准，例如，当面试一名应聘功能测试员的人时，可能会问到“让你直接与代码打交道，你感觉能行吗？”，当面试一名应聘性能测试员的人时，完全可以这么问“哪个是你用代码写的复杂的自定义功能，并且能使你的负载生成脚本确切的模拟现实使用场景？是什么让这个功能这么复杂？你先在还有这些编码吗？你能否轻松的重新再写一遍呢？”

　　技术和经验

　　性能测试要求一种独特的技术素质，这种素质远高于对功能测试团队人员的要求，很多时候也比开发团队人员要求的更宽。除了要求对他们自身所选择的工具的掌握，我特别看重以下经验和技术（粗略的按照由重到轻的顺序排列如下）：

　　1、用户社区的建模和虚拟

　　2、被测系统的通信协议

　　3、网络搭建

　　4、数据统计

　　5、图解复杂信息

　　6、程序开发，比如问“如果在晚间备份开始前，我做 X 的同时别人做 Y 而且还有 20 个人做 Z ，那会怎么样？”

　　7、可靠，稳定，安全测试

　　8、系统监控，和管理

　　9、功能测试

　　10、作为一个培训者和帮手很有经验