软件测试经验与教训--阅读笔记--06测试文档

文档是形式化测试过程的一个重要组成部分，IEEE软件测试文档标准829提供了一种很好的测试

文档描述，以及测试文档相互之间和测试过程之间关系的描述。

经验142-为了有效地应用解决方案，需要清楚地理解问题

经验143-不要使用测试文档模板，除非可以脱离模板，否则模板就没有用

经验144-使用测试文档模板：模板能够促进一致的沟通

经验145-使用IEEE标准829作为测试文档

经验146-不要使用IEEE标准829

经验147-在决定要构建的产品之前先分析需求，这一点既适用于软件也同样适用于文档

决定什么内容要包含到测试文档中，什么内容不包含，应该以项目需求为基础。

经验148-为了分析测试文档需求，可采用类似以下给出的问题清单进行调查

测试小组的使命是什么，测试这个产品的目标是什么？文档无太多用处的话，则没有价值。

自己的测试文档是产品还是工具？文档是产品一部分的话，则需要付费。软件质量是受法律问题驱动还是受市场驱动？如果需要管理审查，则需要文档；设计变更有多频繁？变更太频繁，则不要编写大量测试文档。反映设计变更的规格说明变更有多频繁？如果规格说明长期不完整并且过时，不能把测试文档捆绑在这种规格说明的内容上；在测试时，是希望证明与规格说明一致，还是希望证明与客户预期不一致？要采用的测试风格更依赖于预先定义的测试，还是探索性测试？

测试文档应该关注要测试什么，还是应该关注怎么测试？文档应该控制测试项目吗？如果文档控制部分测试项目，那么是在项目的初期还是后期进行控制？谁是这些测试文档的主要读者？这些读者有多重要？需要多强的可跟踪性？要反向跟踪哪些文档？谁来控制跟踪？测试文档要在多大程度上支持项目状态与测试进展的跟踪和报告？文档要在多大程度上支持向新测试员指派工作？

对新测试员的技能和知识做哪些假设？要使用测试文档记录项目团队的过程，以提供一套别人做测试可依据的产品模型或描述，或给出发现程序错误的结构吗？测试包应该提供预防、检测和预测收益。对于本项目来说，哪一种收益最重要？测试文档的可维护性有多高？这些测试文档在多大程度上能够保证测试变更能够跟上代码变更？测试文档会有助于标识程序风险模式的永久转移吗？

经验149-用简短的语句归纳出核心文档需求