缺陷管理知识宣讲.pptVIP

缺陷管理;本课教学目标;课程内容; 6.1 软件缺陷概念回顾;软件缺陷概念回顾（续）;软件缺陷概念回顾（续）; 6.2 软件缺陷严重性和优先级; 软件缺陷严重性和优先级（续）; 软件缺陷严重性和优先级（续）;缺陷等级划分（ SZSTC ）;问题与讨论; 6.３ 软件缺陷跟踪管理; 6.3.1 缺陷跟踪管理目标; 6.3.2 缺陷跟踪管理;缺陷跟踪管理（续）;软件缺陷的主要状态包括以下的内容 新建(New)： 测试中新报告的软件缺陷； 打开 (Open)： 被确认并分配给相关开发人员处理； 修正(Fixed)： 开发人员已完成修正，等待测试人员验证； 拒绝(Declined)： 拒绝修改缺陷； 延期(Deferred)： 不在当前版本修复的错误，下一版修复 关闭(Closed)： 错误已被修复。;测试人员提交新发现的缺陷入库，缺陷状态为“New” 高级测试人员验证错误 如果确认是错误，则分配给相应的开发人员，设置状态为“Open” 如果不是错误，则拒绝，设置为“Declined”状态 开发人员查询状态为“Open”的缺陷，对其进行处理 如果不是错误，则状态置为“Declined” 如果是错误，则修复并置状态为“Fix” 如果不能解决，要留下文字说明并保持缺陷状态仍为“Open” 对于不能解决或者延期解决的缺陷，不能由开发人员自己决定，一般要通过某种会议（评审会）才能认可 测试人员查询状态为“Fix”的缺陷，验证缺陷是否已解决，做如下处理 如果问题解决了，置缺陷的状态为“Closed” 如果问题没有结果，则置状态为“Reopen”;问题与讨论;缺陷流程管理应遵循以下原则 为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。 每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug 状态。 拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。 加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。 ;6.4 缺陷书写规范（一）;复现步骤的正确书写方??： 提供测试的环境信息； 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多； 每个步骤前使用数字对步骤编号； 尽量使用短语或短句，避免复杂句型句式； 复现的步骤要完整、准确、简短； 将常见步骤合并为较少步骤； 按实际需要决定是否包含步骤执行后的结果。 实际结果：是执行复现步骤后软件的现象和产生的行为。 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。;期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。 附件：对缺陷描述的补充说明，可以是以下一些类型： 缺陷症状的截图； 测试使用的数据文件； 缺陷交流的记录，例如相关邮件等； 解决缺陷的补丁程序 其它： 选择合适的缺陷严重性属性； 按相应的规定，填写相应的字段信息;避免常见的错误： 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替 避免使用情绪化的语言和强调符号； 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果； 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息； 避免提交不确定的测试问题，自己至少需要重现一次再提交。;问题与讨论;问题与讨论;6.5 缺陷数据分析;6.5.1 缺陷数据分析关注的问题;6.5.2 缺陷数据分析的重要性;6.5.3 缺陷数据分析的数据指标;6.5.4 不同软件组织的缺陷管理过程;6.5.4 不同软件组织的缺陷管理过程(续);6.5.4 不同软件组织的缺陷管理过程(续);6.5.4 不同软件组织的缺陷管理过程(续);6.5.4 不同软件组织的缺陷管理过程(续);6.5.4 不同软件组织的缺陷管理过程(续);6.5.4 不同软件组织的缺陷管理过程(续);问题与讨论