测试终止准则确定测试终止的原则，对本次测试，我们定义了每轮的终止准则“所有测试用例至少执行一次”，定义了整个测试的终止准则“所有待验证指标都达到”。
测试环境与测试工具确定本测试需要使用的测试工具和定义需要使用的测试环境，这部分的内容非常重要，对于测试环境，在计划阶段需要尽可能地考虑到各种可能的情况，设备资源限制的情况等，否则，在测试执行时才发现环境不完整就很被动了;对于需要使用的测试工具，测试设计阶段也应该进行详细的规划，采用商用工具还是自己开发工具?到底需要哪些工具才能满足测试的需要?好的规划可以让你尽早安排相关人员的配合(例如，需要找开发人员协调开发测试工具)，反之，把希望寄托在“我有XX测试工具”或是“XX测试工具据说很好用”就一定会导致测试的失败。
测试资源配置描述执行本测试需要的人员和时间资源，一方面可以作为工作量的评估与项目经理和客户进行沟通，另一方面，也可以尽早规划工作安排。
3. 测试用例与测试数据
确定了测试计划后，就可以针对测试计划中确定的需要测试的指标设计测试用例了。同样，设计的测试用例也需要向客户解释清楚并得到客户的认可。一般来说，客户比较关注的“这个测试用例怎么能说明系统达到了性能指标?”和“我怎么检验你的测试结果?”，因此需要通过会议或是其他方式与客户尽可能地沟通，在本项目的测试中，我们在第一轮测试中就出现了因为与客户沟通不够出现的问题，其实在测试用例执行之前，我们已经和客户进行了测试用例的确认，但在执行过程中，用户表示希望能看到更详细的中间结果，导致我们只能重新修改了部分测试工具和测试环境，导致测试执行未能按计划完成。第一轮测试完成后，我们就再次和用户对测试用例进行了详细的审核，包括每个用例的详细输入、输出，以及如何验证输出。
从已确定的测试指标产生测试用例没有单一的法则，这个就是测试设计员(Test Designer)的基本功了，在这里不进行描述。
关于测试用例的书写格式在51cmm和其他很多网站上都有讨论，我个人的感觉是不必要太多拘泥于测试用例的书写方式，一般只要测试用例描述清楚了测试步骤、输入、预期输 用例编号XXXX_NFT_PT_XX用例对应功能点
| 用例编号 | XXXX_NFT_PT_XX | 用例对应功能点 | ||
| 用例类型 | 性能 | 用例优先级 | ||
| 用例简要描述 | XXXXXXX | |||
| 用例依赖关系 | 无 | 用例依赖用例 | ||
| 用例创建人 | 用例执行时间 | |||
| 用例执行先决条件 | 1． 使用一台采集服务器作测试用； 2． 已通过模拟程序产生每秒300条告警的告警数据； 3． 所有告警产生和呈现时间记录在本地日志文件中。 | |||
| 检测方法 | 1． 由网元模拟程序产生特定告警（T1）； 2． 告警被上层应用呈现的时间由上层应用记录（T2）； 3． 计算T2－T1，结果小于5秒； | |||
| 修改记录 | ||||
| 〔修改人〕 | （修改时间） | （修改内容） | ||
| 用例描述 | ||||
| 步骤 | 操作 | 输入数据 | 预期输出 | |
| 1 | 用户启动主界面，进入告警监控界面 | |||
| 2 | 产生一个特定告警（便于识别），发送至系统 | XXXX（特定告警的详细内容） | 特定告警的发送时间记录在文件XXXX中 | |
| 3 | 在告警监控界面上查看特定告警 | 观察到特定告警出现的时间（记录在文件XXXX中）和告警实际发生时间相差不超过5秒 | ||
| 测试结果描述： | ||||
| 测试 http://www.csai.cn | 测试结论： | 签名： | ||
设计测试用例的过程中，同时需要关注的是测试数据的产生和维护。
文章来源于领测软件测试网 https://www.ltesting.net/
