从网上看到，觉得挺不错的，所以拷贝过来了
[概述]
测试文档是测试过程中输出的测试工作产品，类似于软件工作产品。然而实践中经常面临有无数的测试文档需要撰写，而使用文档的效果却是非常有限。本文阐述了测试文档深度与广度选择需要考虑的一些因素。
[正文]
测试文档是测试人员在测试过程中输出的测试工作产品，类似于软件工作产品，是形式化测试过程的重要组成部分。IEEE829是软件测试行业内最有名的文档标准，它提供了一种很好的测试文档描述，同时描述了测试文档之间以及与测试过程之间的关系。
行业内不少公司在使用IEEE829测试文档标准，或者以IEEE829为基础开发自己公司的文档模板，但是实际的结果并不乐观，主要表现在：
1）成本较高：测试人员需要花费大量的时间投入到测试文档的编写，按照模板填充类似格式的案头工作；
2）效果较差：按照测试文档模板编写出的并不是特别有价值的大量原始材料，甚至由于时间的限制，测试文档几乎在测试过程中没有什么人看；
3）文档维护成本高：特别是在测试文档的输入软件工作产品变更的时候，不仅要修改捆绑到软件变更部分，而且还要搜索必须修改的其他有关联的内容。
因此，纯粹照搬使用IEEE829测试文档模板，或者公司内部开发的文档模板并不是提供测试文档的初衷。为了提高测试文档模板的效率和有效性，测试人员需要考虑测试文档需要解决什么问题，它的主要目的是什么。假如希望编写出好的测试文档，需要有测试文档模板的支持，而更重要的是测试人员需要了解模板没部分的含义，为什么需要有这部分，什么时候可以删除这部分内容，即测试人员必须能够根据公司特征和项目特点合理裁剪测试文档模板。
决定什么内容包含到测试文档中，什么内容不包含，应该以项目需求为基础。为了更好的确定测试文档模板的深度与广度，即合理裁剪测试文档模板，测试人员至少需要考虑下面的这些因素：
1）测试目标
测试人员测试该产品或者系统的目标是什么。假如测试文档不能支持这个目标，或者无助于达到这个目标，那么这样的测试文档（与所创建的所有其他软件工作产品一样）价值就会降低很多。
2）测试文档是产品还是工具
假如测试文档是软件系统或者产品的一部分，那么这些文档是需要发布给客户使用的，这时候测试文档就需要按照客户的要求遵循某种表尊。而假如测试文档只是内部使用的工具，那么就不必太完整、太整齐，能够在最低限度上有助于达到目标即可。
3）软件设计变更是否频繁
如果软件设计变更很频繁，则不要将许多细节写入测试文档中，因为这些细节很快就会过时。这种情况下，不要编写大量的测试文档，它们被修改或者放弃的速度太快，不值得在测试文档上投入太多。
4）采用的测试方法
假如目前采用的软件开发模型是V模型之类的线性模型，那么采用的测试方法通常是依赖于预先定义的测试，这时候需要详细的测试用例的操作和维护文档。假如采用的是探索性测试，则更需要策略方面的文档，例如：关于某个测试领域的想法，但不是具体的测试用例。
5）测试文档给谁看
假如测试文档是主要给新的测试人员或者没有经验的测试人员看，那么需要足够详细使得他们能够正常开展工作。
测试人员在裁剪测试文档的时候，上面的这些问题可以帮助测试人员思考，写出他们所需要的东西，以及内容的详细程度，以达到测试文档的目标。
