前言
测试文档是形式化测试过程的一个重要组成部分，现在网上我们可以搜索到很多测试文档模板。模板中也不乏内容项的描述，以及测试文档之间与测试过程之间关系的描述。但很多时候我们会在文档模板使用过程中遇到挫折和麻烦，最常见的就是花费大量的时间和精力投入到了填充格式的案头工作中，但最后输出的文档并不具有特别的价值。甚至在某些文档模板使用一段时间后，由于成本和文档效果的限制，逐渐放弃……最终成为一种依赖个人发挥的“奇迹式”测试管理方式……慢慢的进入一种恶性循环，期望着下一次会把工作做的更好，抱怨这次由于某种原因没有做好。
其实问题在于我们是否使用了符合公司需求的文档和方法。
本文通过分享一些个人的经验，提出有助于大家决定自己需要什么的问题，来帮助大家探索自己的测试文档需求。
经验1：为了有效的应用解决方案，首先清楚的理解问题
没有比使用和滥用测试文档更能表现出这个原则了。先考虑测试文档需要解决的问题，然后再运用一种适合解决方案的形式。
经验2：不要使用测试文档模板：除非可以脱离模板，否则模板就没有用
测试文档模板不能替代技能。
模板用起来很简单----填满所有内容或填空，就会得到自己的文档----但模板的问题是，编写的文档看起来不错但可能没有实际内容。因此，为了使用模板编写好的测试文档，必须理解文档每一部分的含义，理解为什么要有这一部分，什么时候可以删除。如果测试员对这些都能理解，就不需要测试模板了。如果不理解这些，就不要受模板的影响。很多时候模板使我们测试员的工作效率下降，其实是因为没有理解模板作者对需求和权衡所做的全面考虑。
如果不需要模板也可以编写有效的测试文档，那么模板有助于这样的人更快的写出有效的测试文档。
经验3：在决定要构建的产品之前先分析需求，这一点即适用于软件也适用于文档
决定什么内容要包含到测试文档中，什么内容不包含，应该以项目需要为基础。我做的模板只相当于大纲，有的需要，有的不需要。学会增减。
经验4：分析测试文档需求，可以这么干
- 测试小组的使命是什么，测试这个产品的目标是什么？
如果文档不能支撑这样的目标，就没有价值。
- 自己的测试文档是产品还是工具？
产品是给别人使用的东西。如果文档只是内部工具，则不必太完整、太多要求、太整齐，能在最低限度上有助于达成目标即可。
- 设计变更有多频繁
如果很频繁，则不要写太多细节，因为这些细节很快就过时。
- 反映设计变更的规格书变更有多频繁
如果设计书长期不更新，就不要把测试文档捆绑在这种设计上。
- 测试时是希望证明与设计不一致，还是与客户期望不一致？
- 要采用的测试风格更依赖于事先定义的测试还是探索式测试？如果更依赖探索式测试，则更需要战略和策略文档（有关如何在某个领域测试的想法，而不是测试用例）。
- 测试文档应该关注测试什么（目标）还是怎么测试（过程）？
- 文档应该控制测试项目吗？例如测试员是否需要查阅任务安排时间节点等。
- 如果文档控制测试项目，那么如何控制，初期or后期？
- 测试文档的目标读者是哪些人？他们的关注点是？这些读者有多重要？
- 需要多强的跟踪性？是否需要跟进哪些文档？
- 测试文档要在多大程度上支持项目状态与测试进展的跟踪和报告？
- 测试文档需要多大程度上支持向新测试员指派工作？
- 对测试负责人的知识和技能做哪些假设？测试负责人懂得越多，文档可以省略的越多。
- 测试时需要做的三方面工作（预防、检测、预测）哪方面占比更多？是否需要舍弃一些？
- 文档的可维护性？
记于3月24号 晨 张