基于缺陷模式的软件测试(第12章).ppt

* 12.4.4 定量管理级的缺陷管理 没实现缺陷预防的缺陷密度 CMM4（已管理级）：建立软件过程能力基线 * 12.4.5 持续优化级的缺陷管理 实现了缺陷预防的缺陷密度 CMM5（持续优化级）：强调对组织的过程进行持续性改进 * 12.5 报告软件缺陷 12.5.1 报告软件缺陷的基本原则 准确报告软件缺陷是非常重要的，因为： 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量； 提高软件缺陷修复的速度，使每一个小组能够有效的工作； 提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应； 加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作； * 软件缺陷的有效描述规则 软件缺陷的有效描述规则，主要包括： 单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。 可以再现。提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。 完整统一。提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。 短小简练。通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。 特定条件。许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。 补充完善。从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。 不做评价。在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。 * 12.5.2 IEEE软件缺陷报告模板 * 12.6软件缺陷管理 12.6.1 缺陷管理目标 由于不同的软件开发组织在软件开发过程、质量保证体系的不同，缺陷管理的方式和处理流程也不尽相同。但其目的都是对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准。一般而言缺陷管理应当具有以下目标： 及时了解并跟踪每个被发现的缺陷； 确保每个被发现的缺陷都能够被处理。这里处理的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正）。对于每个被发现的缺陷的处理方式应当在开发组织内中达成一致。 收集缺陷数据并根据缺陷趋势曲线来识别测试过程是否结束。决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。 收集缺陷数据并在其上进行数据分析，作为组织的过程财富。 * 12.6.2 人员职责 参与缺陷管理过程人员角色包括项目经理、项目测试负责人、测试人员、项目相关开发人员、质量保证人员，其职责描述如下： 项目经理（PM）： 负责指派缺陷给相关责任人。 项目测试负责人（TM）: 决定缺陷管理方式和工具，拟定决策评审计划； 管理所有缺陷关闭情况； 审核测试人员提交的缺陷； 对测试人员的工作质量进行跟踪与评价。 测试人员（TE） 负责报告系统缺陷记录，且协助项目人员进行缺陷定位； 负责验证缺陷修复情况，且填写缺陷记录中相应信息； 负责执行系统回归测试； 提交缺陷报告； 负责被测软件进行质量数据和分析。 项目相关开发人员（DE） 修改测试发现的缺陷，并提交成果物做再测试； 负责接收各自的缺陷记录，并且修改； 负责提供缺陷记录跟踪中其它相应信息。 质量保证人员（SQA） 监控项目组缺陷管理规程执行情况。 * 12.6.3 缺陷生命周期 软件缺陷的状态在其生命周期中变化如下： 缺陷从隐藏在产品中被发现，这时缺陷状态为“创建”。 得到缺陷修复请求以后，开发经理将缺陷修复任务分配给相应的开发人员进行修复，这时缺陷的状态变为“已分配”。 开发人员得到缺陷修复任务以后，根据缺陷的描述重现缺陷的症状、修复缺陷，然后提交测试人员验证修改，这时缺席的状态变为“已修复”。 测试人员验证修改的有效性，若缺陷的修正得到最终确认，其状态变为“已确认”。 最终缺陷提交者或者测试人员，关闭这个缺陷，结束其生命周期。这时缺陷状态变为“已关闭”。 基本的软件缺陷生命周期 * 实践中的软件缺陷生命周期 实践中的软件缺陷生命周期 * 12.6.4 缺陷管理系统 缺陷管理系统是用来管理软件缺陷整个生命的工作流系统，跟踪缺陷从发生到被修正并发布的整个过程。 它能够加强缺陷修正的过程控制，是缺陷管理的实现工具。缺陷跟踪系统能否成功的实施取决