软件质量控制.pptVIP

本章内容提要 软件质量管理的基本概念 软件质量控制 缺陷预防 质量体系 软件项目质量管理计划（案例） 缺陷跟踪工具Bugzilla 第六节 缺陷跟踪工具Bugzilla Bugzilla是Mozilla公司提供的一个开源的缺陷跟踪工具，在全世界拥有大量用户。 它能够为软件组织建立一个完善的缺陷跟踪体系，包括报告缺陷、查询缺陷记录并产生报表、处理解决缺陷、管理员系统初始化和设置等。 Bugzilla的特点： 基于Web方式运行，安装简单，易于掌握。 缺陷从最初的报告到最后的关闭，都有详细的操作记录，确保了缺陷不会被忽略，并允许用户在检查缺陷状态时获取历史记录。 提供强大的查询匹配能力，能根据各种条件组合进行缺陷查询，并能够记忆搜索条件。 当缺陷状态发生改变时，会自动发送邮件通知相关责任人。 自带基于数据库的报表生成功能，主要生成两类图表：基于表格的视图和图形视图（条形图、线图、饼状图）。 Bugzilla的特点： Bugzilla的基本操作说明 报告缺陷 分配缺陷 处理缺陷 验证已解决的缺陷 本章内容小结 质量管理的基本概念 软件质量、质量属性、质量形成、质量成本 质量控制 技术评审、同行评审、代码评审 缺陷跟踪 常用质量度量 缺陷预防 质量体系 质量体系的构成、特征，TQM 质量管理计划（案例） 缺陷跟踪工具Bugzilla 本章内容小结 练习题 质量控制活动主要包括哪些？ 简述质量体系和项目质量管理计划的区别。 * 测试虽是必不可少的质量保证活动，但它一方面比较耗时耗力，另一方面只能在项目后期执行。因此从项目的早期开始就应该采用各种评审技术来检测软件产品中的缺陷。 * 一个缺陷被报告后，其状态被设置为“打开(Open)”，它被分配给一个开发人员进行修复，此时缺陷状态设置为“已分配(Assigned)”，然后开发人员开始修复缺陷，修复完毕后，将缺陷状态设置为“已解决(Resolved)”，此时测试人员可以开始回归测试，如果回归测试通过，确认缺陷已被修复，则将缺陷处理状态设置为“已验证(Verified)”，否则退回给开发人员重新进行修改。一个缺陷结束了其生命周期后，可将其关闭，其处理状态变为“已关闭(Closed)”。已被关闭的缺陷如果在某些情况下被发现仍有问题，可以将其重新打开，使其处理状态变为“重新打开(Reopened)”，以便再分配给开发人员进行修复。 * 软件质量是一个属性集合，没有单一的度量，而是存在多种度量指标。 * 无论是测试还是各种形式的技术审查，都是一种被动的措施，也就是在缺陷已被引入软件的情况下，再去检测和排除缺陷。 治病不如防病，应采取主动的措施防止缺陷被引入到软件中，即缺陷预防。 * 图中下方是项目级的DP活动。项目组首先根据组织的DP计划和历史数据制订本项目的DP计划；在每个项目阶段开始之前，缺陷预防协调员组织召开项目阶段启动会议（也称为Kickoff会议），将本阶段的缺陷预防措施和注意事项公布给所有项目组成员，使项目组成员明确本阶段的缺陷预防目标，从而更好地完成开发任务；在项目进行过程中，收集缺陷数据，定期召开缺陷原因分析会议，得到缺陷产生的根本原因并制订相应的预防措施，产生的缺陷原因分析报告将提交给组织级缺陷预防小组；项目组还要定期分析和评估缺陷预防措施的执行效果，产生DP效果分析报告，同样提交给组织级缺陷预防小组。 图中上方是组织级的DP活动。组织级缺陷预防小组须根据软件组织的成熟度和项目历史数据制订组织级DP计划，建立缺陷预防活动的基线和目标；定期举行DP会议，根据各项目组提交的缺陷原因分析报告和DP效果分析报告，评估组织的缺陷预防工作，筛选出富有成效的缺陷预防措施，在组织范围内公布和推广；如果缺陷预防措施涉及到组织范围内软件过程的更改，缺陷预防小组将与软件工程过程组及高级管理人员进行协商，对组织的标准软件过程进行更新，实现过程改进。 * 缺陷预防的核心任务是原因分析，也就是找到导致软件缺陷产生的根本原因和共性原因。 原因分析最早应用于制造业的产品质量控制活动中，后来由日本软件企业于20世纪80年代首先应用于软件开发过程。 对于中小规模的软件项目，缺陷数据的选择较为简单，可选择某一时期或某一项目阶段所发现和处理的所有缺陷作为待分析的数据集，但对于大型项目来说，由于缺陷数量庞大，而根本原因分析又是一个费时的任务，只能选择一个具有统计显著性的缺陷样本集合，选择时需考虑的因素包括缺陷的严重程度、复杂性、相对于软件模块和开发团队的分布等。 确定缺陷的触发条件、在哪一个开发阶段被引入以及为什么会引入等等，并最终得到缺陷的根本原因。随着软件组织经验的增长和数据的积累，可对根本原因进行分类，从而有利于更为快速和准确地进行分析，并针对每一类原因提出有效的预防措施。