在 IEEE Standard 829 中有定义测试文件的模板应该长得什么样子， 你可以从很多地方找到个模板

　　可是很多人看完后会说这个太复杂了， 有没有简单的方式， 连做事的时间都不够了， 哪有时间写这么长的文件. 我想是否要照着这个范本写并不重要， 重要的是你需要考虑以下事情
　　1. 什么东西你要测试
　　也是定义测试的目标物是什么. 有时候有些人会搞错测试的目标物， 明明要测的是你的系统， 可是却测到受测系统所用到的平台或是数据库. 有时候哪些东西不是你先要处理的重点， 可是你却一直在找他们的问题.
　　2. 你要测什么
　　列出你要测试的功能. 这是乎很直觉， 但是在某些状况下， 也许有些旧功能， 或是不是这次要注意的重点， 你是可以在这次的测试先忽略他们. 但是要先和相关利害人确认清楚.
　　3. 你要怎么进行测试
　　你需要描述你的测试策略. 像是范围， 单元或是整合或是 end to end ， 工具， 是否要自动化， 哪些东西先测...等等
　　4. 什么时候要测试
　　也是说明你什么时候要做哪些事情. 何时规划， 何时开立个案， 何时执行个案， 何时回归测试等等.
　　5. 可以进入测试的条件
　　并不是随便写个尸体可以来测试了， 开发人员要先对自己写的东西负责任， 准备好适当的文件， 或是经过适当 review 等等. 总之要定义好一些准则， 需要通过才能开始测试.
　　6. 可以结束测试的条件
　　你需要定义什么条件满足了， 测试才算结束. 像是没有严重的 bug， 平均无故障时间减少到某个范围， 或是当初计划的测试项目都已经测完， 效能已经达到某个水平... 等等.
　　我想如果你的计划已经能回答这些问题， 我想是否照着标准的模板并不重要. 因为你已经把重要的事情都考虑到了.