多次度量响应时间和吞吐量

　　需要得到系统大吞吐量，佳响应时间、当响应时间正好符合要求时的负载量以及负载达到事先测量的大吞吐量的 80%和 90%时的响应时间等信息

　　有必要测试所有功能吗

　　对系统的所有功能进行测试基本上是不现实的。重点在于要覆盖常用的功能。 所以你需要识别出系统的主要使用场景，并针对这些场景创建不同的测试。

　　比如说，在线购物网站主要的使用模式应该是“浏览”和“购买”。来购物的人不全会浏览很多页面，浏览的时间通常也不都会太长。所以 你需要创建一个“浏览”的测试脚本和一个“购买”的测试脚本。为了让测试脚本更贴近真实 ，你需要知道用户浏览商品的平均数量、每次购买的平均商品数以及正常情况下时间内被浏览过的商品数占商品总数的百分比。

　　3.沟通

　　需要做的测试结果进行沟通。

　　根据讨论出的性能需求和目前的性能水平来解读测试结果。

　　指出系统性能与目标的接近程度(与目标的差距有多少，或是超出目标多少)

　　说明产品的性能是否发生了重大变化。

　　各个关键点时各种系统资源的使用情况

　　不同的人会对不同的信息感兴趣（客户，项目经理，开发者）。建议用一个网站向所有人展示新的性能测试结果。

　　4.流程

　　性能测试经常被放在项目结束前进行，这种安排严重影响了性能测试的效果。性能测试中重要的事是要定期地进行测试。如果直到项目后几周才做性能测试，那么你将有很多事要干，而时间却非常紧迫。大部分时间会被用于编写测试脚本，并得到一些和产品有关的数据。这时你会处于一种尴尬的境地，你大概知道系统运行得多快，但基本无从知道它是否足够快，而且也没有时间做任何改进。

　　当第一段代码被编写出来，性能测试应该开始了。虽然这时可能还没有任何可供测试的东西，但还是有很多事可以去做。你可以向开发者了解他们将要使用的技术，评估合适的工具，找出功能足以测试当前产品的工具。此外还需要识别出关注性能的客户，并且与他们一起启动需求采集的流程。

　　如何把各种工作连接起来

　　每周循环工作：1.每周开始时开会，讨论正在开发的功能的性能需求，介绍测试计划;2.编写新功能对应的脚本，维护已有脚本，执行测试；3.每周结束时开会，展示本周成果：脚本，测试结果等并进行讨论

　　如何确保不拖后腿

　　1.确定任务列表；2.确定优先级；3.时间确实紧张时按照前面2点来减少任务量(高难度，低优先级)或者增加人手

　　5.总结

　　这个流程大的好处在于它能确保你知道自己手上有什么、需要什么，而且你能肯定系统的每个部分都有测试覆盖，从而大大增加了发现问题解决问题的机会。让性能测试与开发同步，对每个功能都有测试覆盖，这样如果性能出了问题你有时间应对。有一份性能需求在手上，你能判断当前的系统是否需要改变。这份需求是客户根据业务流程和规模制订的，所以整个团队都对它有信心，大家也会乐于花时间来解决性能问题，因为他们知道这是一件有价值的工作。