《软件测试经验与教训》读书笔记---第六章

《软件测试经验与教训》读书笔记--目录

第一章 测试员的角色
第二章 按测试员的方式思考
第三章 测试手段
第四章 程序错误分析
第五章 测试自动化
第六章 测试文档
第七章 与程序员交互
第八章 管理测试项目
第九章 测试小组的管理
第十章 软件测试职业发展
第十一章 计划测试策略

第六章  测试文档

探索自己的测试文档需求？

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

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

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

经验145: 使用IEEE标准829作为测试文档
如果测试员要创建过程脚本化的测试用例，标准829指出应该怎样说明这类测试用例，应该在文档的哪一部分描述。如果不想以这种方式编写测试用例，也不必仅仅为了满足标准还创建这种类型的文档

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

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

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

• 测试小组的使命是什么，测试这个产品的目标是什么？
• 自己的测试文档是产品还是工具？
• 软件质量是受法律问题驱动还是受市场驱动？
• 反映设计变更的规格说明变更有多频繁？
• 在测试时，是希望证明与规格说明一致，还是希望证明与客户预期不一致？
• 要采用的测试风格更依赖于预先定义的测试，还是探索式测试？
• 测试文档应该关注测试还是没（目标），还是应该关注怎么测试（过程）？
• 文档应该控制测试项目吗？
• 如果文档控制部分测试项目，那么是在项目的初期还是后期进行控制？
• 谁是这些测试文档的主要读者？这些读者有多重要？
• 需要多强的可跟踪性？要反向跟踪哪些文档（规格说明或需求）？谁来控制跟踪？
• 测试文档要在多大程度上支持项目状态与测试进展的跟踪和报告？
• 文档要在多大程度上支持向新测试员指派工作？
• 对新测试员的技能和知识做哪些假设？
• 要使用测试文档记录项目团队的过程，以提供一套别人做测试可依据的产品模型或描述，或给出发现程序错误的结构？
• 测试包应该提供预防、检测和预测收益。对于本项目来说，哪一种收益最重要？
• 测试文档（及其测试用例）的可维护性有多高？这些测试文档在多大程度上能够保证测试变更能够跟上代码变更？
• 测试文档会有助于标识（并修改或重新组织）程序风险模式的永久转移吗？

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

参考《软件测试经验与教训》