需求和设计阶段确定的性能相关指标是性能测试需要确定的性能指标的首要来源，对我们的这个系统而言，在需求文档中确定的指标有三个：
　　　1、 “能在一小时完成话务报告的采集，在5分钟内完成报表的生成”；
　
　　2、 “具有600网元的告警和话务处理能力”；
　
　　3、 “告警要求在5秒内呈现”；
　
　　在设计文档中，对于告警处理能力有更详细的指标定义：
　
　　1、 “能处理平均每秒200次的告警”；
　
　　2、 “能处理峰值为每秒600次的告警”；
　
　　针对这两份文档中的描述，我们至少可以确定我们需要针对以下两种情况进行测试：
　
　　1、 针对600个网元话务报告的采集和处理进行测试，采集过程要求在一小时完成；报表生成需要在5分钟内完成；
　
　　2、 针对600个网元的告警处理能力进行测试，在告警产生的均值为200次/秒，峰值产生为600次/秒的情况下，告警从产生到呈现的时间间隔不超过5秒；。
　
　　粗看起来，这两个指标的定义已经很详细了，但仔细考究，其实这样的描述还是远远不够的，例如，对第一个指标，话务周期（多长时间产生一次数据）必须要指明，因为5分钟的话务周期和1小时的话务周期在处理速度上是有很大差别的；对第二个指标，必须说明在多少呈现告警客户端的条件下，因为多个告警客户端和单个告警客户端在性能上肯定会有不同。
　
　　除了从文档中获取的指标外，直接从用户处获取的指标也很重要，例如，在可客户的沟通中发现，客户对于实时性能数据的呈现时间也非常关注，但在需求中并未提到该需求，当然，通过和客户直接沟通获取的指标必须经过变更控制，在文档中变更体现后才能被正式纳入测试目标。
　
　　还有一个指标的来源是个人经验了，作为一门实践性的学科，个人经验在测试中发挥的作用也是不能忽视的，例如，根据系统的实现，在测试指标中增加“300用户并发时MQ服务器的MQ派生进程数不得超过200个”等。
　
　　本次测试终确定的需要验证的性能指标为14个，其中从文档中直接映射的为6个，从客户获得并经过变更控制认可的为2个，根据经验补充的为6个。
　
　　测试策略描述对整个测试采取的方法，本次测试的测试策略规定，测试少为2轮，每轮测试应该执行所有的测试用例至少一次，在一轮测试过程中程序需要保持“锁定”，不允许进行修改，每轮测试结束后需要形成测试结果记录文档；所有的待验证指标都达到后才能称为本测试结束，测试结束后需要提供完整的测试报告，记录整个测试过程和中间结果。
　
　　测试终止准则确定测试终止的原则，对本次测试，我们定义了每轮的终止准则“所有测试用例至少执行一次”，定义了整个测试的终止准则“所有待验证指标都达到”。
　
　　测试环境与测试工具确定本测试需要使用的测试工具和定义需要使用的测试环境，这部分的内容非常重要，对于测试环境，在计划阶段需要尽可能地考虑到各种可能的情况，设备资源限制的情况等，否则，在测试执行时才发现环境不完整很被动了；对于需要使用的测试工具，测试设计阶段也应该进行详细的规划，采用商用工具还是自己开发工具？到底需要哪些工具才能满足测试的需要？好的规划可以让你尽早安排相关人员的配合（例如，需要找开发人员协调开发测试工具），反之，把希望寄托在“我有XX测试工具”或是“XX测试工具据说很好用”一定会导致测试的失败。
　
　　测试资源配置描述执行本测试需要的人员和时间资源，一方面可以作为工作量的评估与项目经理和客户进行沟通，另一方面，也可以尽早规划工作安排。