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

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

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

第八章  管理测试项目

如何管理测试项目？

经验157: 建设一种服务文化
测试员为整个项目团队提供服务。典型的服务就是发现并报告程序错误

经验158: 不要尝试建立一种控制文化

经验159: 要发挥耳目作用

经验160: 测试经理管理的是提供测试服务的子项目，不是开发项目

经验161: 所有项目都会演变。管理良好的项目能够很好地演变
项目团队要为集成新信息、确定下一步（可能）做什么、项目完成前的迭代工作提供某种框架。要把项目看作是有关下一步应该做什么的正在进行着的结构化对话。

经验162: 总会有很晚的变更

经验163: 让项目经理选择项目生命周期

经验164: 瀑布生命周期把可靠性与实践对立起来
瀑布模型是一种描述按阶段推进项目管理的具体生命周期方法

经验165: 进化生命周期把功能与时间对立起来

经验166: 愿意在开发初期将资源分配给项目团队

经验167: 合同驱动的开发不同于寻求市场的开发
在合同驱动的项目中，测试员的主要活动是对照一组规格说明测试软件。在寻求市场的项目中，测试员更可能根据不同客户的预期，来研究和测试产品

经验168: 要求可测试性功能
越早提出可测试性功能要求，程序员和项目经理越有可能把它列入预算和进度计划

经验169: 协商版本开发进度计划
制定版本进度计划，内容包括测试小组接受软件的频度，对提交的被测试软件的要求，以及在最近版本中发现的程序错误如何在新版本中重现

经验170: 了解程序员在交付版本之前会做什么（以及不会做什么）
如：冒烟测试

经验171: 为被测版本做好准备
当被测版本就绪时测试环境也应该就绪

经验172: 有时测试员应该拒绝测试某个版本

• 没有所需的关键功能
• 以前有的关键功能现在不能正常使用
• 收到一个版本，但是下一个版本会在几个小时后就会完成

经验173: 使用冒烟测试检验版本

经验174: 有时正确的决策是停止测试，暂停改错，并重新设计软件
如果不管进行了多少次的程序错误的修改，在同一个位置总发现问题，需停止测试，调试代码，可能需要重新设计或重写

经验175: 根据实际使用的开发实践调整自己的测试过程

经验176: 项目文档是一种有趣的幻想：有用，但永远不足
在使用规格说明时应要求提供特定补充信息以弥补这种差距。不要根据文档完备、一致或准确的假设设计测试或规划项目

经验177: 测试员除非要用，否则不要索要
如果测试员不需要用这些材料，但是索要了，导致开发人员花费时间编写

经验178: 充分利用其它信息源

经验179: 向项目经理指出配置管理问题

经验180: 程序员就像龙卷风

经验181: 好的测试计划便于后期变更

• 不要在测试之前开发大的测试包
• 不要编写维护成本很高的大量测试文档
• 不要把手工或自动化测试捆绑到特定的用户界面，除非想要专门测试该用户界面
• 通过最大化可维护性和跨平台可移植性来设计自动化测试
• 构建一组能够在不同程序中重复使用的通用测试
• 构建一组很强的冒烟测试，以快速检测被测软件中的基本失效
• 慎重考虑使用极限编程法开发自动化的测试
• 开发一种产品用户和用户要通过产品获得效益的模型
• 帮助程序员开发大的单元测试包，以及相对简单功能的其他测试

经验182: 只要交付工作制品，就会出现测试机会

经验183: 做多少测试才算够？这方面没有通用的计算公式

经验184: “足够测试”意味着“有足够的信息可供客户做出好的决策”

经验185: 不要只为两轮测试做出预算

经验186: 为一组任务确定进度计划，估计每个任务所需的时间

经验187: 承担工作的人应该告诉测试经理完成该任务需要多长时间

经验188: 在测试员与开发人员之间没有正确的比例

经验189: 调整任务和不能胜任的人员

经验190: 转换测试员的测试对象
两个测试员会以不同方式分析同样的功能，他们会有不同的查错理论，创建不同的测试，并发现不同的缺陷

经验191: 尽量成对测试
测试员结成对子一起工作，可以等于或优于熟练的差错高手

经验192: 为项目指派一位问题查找高手
问题查找高手是经验丰富、热心探索的测试员

经验193: 确定测试的阶段计划，特别是探索式测试的阶段计划

经验194: 分阶段测试

经验195: 通过活动日志来反映对测试员工作的干扰

经验196: 定期状态报告是一种强有力的工具

经验197: 要小心通过程序错误数度量项目进展

经验198: 使用的覆盖率度量越独立，了解的信息越多

经验199: 周状态报告的推荐结构

• 关键问题（所需的决策、所需的程序错误修改、预期的交付的工作制品、意外问题）
• 描述测试小组完成计划任务进展的情况
• 提供错误报告统计数字
• 列出本周被推延的程序错误

经验200: 项目进展表是另一种展示状态的有用方法

经验201: 如果里程碑定义得很好，里程碑报告很有用

经验202: 不要签署批准产品的发布

经验203: 不要签字承认产品经过测试达到测试经理的满意程度

经验204: 如果测试经理要编写产品发布报告，应描述测试工作和结果，而不是自己对该产品的看法

经验205: 在产品最终发布报告中列出没有排除的程序错误

经验206: 有用的发布报告应列出批评者可能指出的10个最糟糕的问题

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