06缺陷管理61766.pptVIP

6.5.4 不同软件组织的缺陷管理过程(续) 项目行为 　　在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：　　（1）提交缺陷　　（2）分析和定位缺陷　　（3）提请修改相应的软件　　（4）修改相应的软件　　（5）验证修改 　　项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。 6.5.4 不同软件组织的缺陷管理过程(续) 组织行为 　　CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。 　　从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。 6.5.4 不同软件组织的缺陷管理过程(续) 量化管理 　　CMM第四级（或称为已管理级）的软件组织会根据已收集的缺陷数据，采用SPC的方法建立软件过程能力基线（Process Capability Baseline）。对于缺陷管理，可以缺陷密度为例，过程能力基线通常包括期望（Mean），能力上限（Upper Control Limit，UCL），能力下限（Low Control Limit，LCL）。其中，期望描述了未来项目的缺陷密度的预期值，而UCL和LCL描述了未来项目的缺陷密度的合理变化范围。 　　这样的过程能力基线可以用来：(1)帮助未来的项目设立量化的项目质量目标；(2)理解和控制未来项目的实际结果。 6.5.4 不同软件组织的缺陷管理过程(续) 6.5.4 不同软件组织的缺陷管理过程(续) 持续优化　　与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。 　　就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。 　　缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。 6.5.4 不同软件组织的缺陷管理过程(续) 问题与讨论 如果你是一个测试经理，你最关心的缺陷数据是什么？ * 缺陷管理流程图 第6章 缺陷管理 本课教学目标 了解缺陷的严重级和优先级分类 正确理解缺陷跟踪管理流程 了解缺陷管理流程的要点 正确理解缺陷数据分析的重要性 课程内容 6.1 软件缺陷概念回顾 6.2 缺陷的严重性和优先级 6.3 缺陷跟踪管理 6.4 缺陷书写规范 6.5 缺陷数据分析 6.1 软件缺陷概念回顾 软件缺陷的定义： （1）软件未达到产品说明书中已经标明的功能； （2）软件出现了产品说明书中指明不会出现的错误； （3）软件未达到产品说明书中虽未指出但应当达到的目标； （4）软件功能超出了产品说明书中指明的范围； （5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。 软件缺陷概念回顾（续） 软件缺陷的特征： “看不到” ——软件的特殊性决定了缺陷不易看到 “看到但是抓不到” ——发现了缺陷，但不易找到问题发生的原因所在 软件缺陷概念回顾（续） 其他 10% 软件产品说明书（需求） 56% 编写代码 7% 设计27% 图 软件缺陷产生的原因分布 缺陷分布情况： 6.2 软件缺陷严重性和优先级 重要软件缺陷会导致重大经济损失与灾难 测试员应对软件缺陷分类，以简明扼要的方式指出其影响，以及修改次序 划分软件缺陷严重级和优先级的通用原则 表示软件缺陷所造成的危害的恶劣程度 优先级表示修复缺陷的重要程度与次序 软件缺陷严重性和优先级（续） 严重级 严重：系统崩溃、数据丢失、数据损坏 较严重：操作性错误、错误结果、遗漏功能 一般：小问题、错别字、UI布局、罕见故障 建议：不影响使用的瑕疵或更好的实现 软件缺陷严重性和优先级（续） 优先级 最高优先级：立即修复，停止进一步测试 次高优先级：在产品发布之前必须修复 中等优先级：如果时间允许应该修复 最低等优先级：可能会修复，不修复也能发布 一般严重性和优先级的划分用数字１～４表示，有的小数字表示的级别最高，而有的用大数字表示级别高。 另外严重级和优先级的划分并不唯一 ，可适当修改 缺陷等级划分（ SZSTC ） 等级 描述 说明 5-紧急 发现可重复出现的致命问题 ——导致系统崩溃； ——导致程序模块丢失