缺陷统计数据的度量.ppt

软件产品质量度量 张奭（Kelly Zhang） KellyZ@M 软件开发测试主管 Microsoft Office国际服务测试部 美国微软总部 自我简介 张奭(Zhang Shi)，英文名是Kelly Zhang 软件开发测试主管。美国微软总部，Microsoft Office 国际服务部。 教育背景:北京师范大学获得学士和硕士学位。美国纽约州立大学获得博士学位 工作经验: 近九年软件测试，测试项目主管，和发布协调总管工作经验 主要议程 为什么软件质量需要有度量？（必要性） 使用软件测试的质量度量的挑战 评价软件质量的优秀度量的特征 制定软件质量度量时注意事项 微软软件质量测试常用度量 使用软件质量度量的注意事项 问题解答 一 为什么软件质量需要有度量？ 有效产品质量管理 改进用户满意度 改进产品质量 减少产品开发和售后服务支持费用 没有质量度量，等于没有质量标准！ 软件测试的质量需要有度量 有效实行测试质量分析和管理 可及时检查测试进度和质量 帮助发现测试漏洞 比较测试质量变化趋势，风险分析 帮助找出最佳实践 二 使用软件产品质量度量的挑战 无公认准确和科学的度量 产品性质不同，很难有通用的度量 最佳实践实际上是经验积累总结 涉及不定因素和人为因素 片面理解和使用可以造成负面影响和效果 三 评价软件质量的优秀度量的特征 准确性 稳定性 可验证性 有针对性 有说服力 重复使用性 可追踪性 简单实用性 四 制定软件质量度量时注意事项 跟踪度量的变化的一致性 提供基础数据以便杜绝滥用数据 讨论会或所有有关方面认可 体现产品质量结果是否满足质量标准 明确谁是使用者 五 微软软件质量测试常用度量 产品设计规范(Spec或设计文档)质量状态 缺陷（bug）数据有关度量 测试案例度量 测试规范度量 测试过的系统数量 自动化测试度量 CodeCoverage（代码覆盖） 单一功能测试验收质量度量 1.产品设计规范质量状态分类 常用的五种状态 一页 (One page)– 用于安排时间和分配人员 草稿 (Draft)– 用于提出疑问和初步设想以供讨论 审阅 (Review)–有所有的设计技术细节，可以供审阅 提交审核会 (Inspection)–所有的设计技术细节到位、没有明显遗留疑问、漏洞等 开始编码 (Coding)– 开发人员可以开始便写代码来实现该设计功能规范 产品设计规范质量到位状况 五种状态中各占的%是多少? 按事先计划日程完成的比例是多少？ 多少%开发人员至少有一个指派给他的功能可以进行编码？ 2.缺陷统计数据的度量(I) 所有缺陷数量的时间走势或趋势统计 (Bug Trends By Time) 未被处理的缺陷按照严重程度的统计 (Active Bugs By Severity) 未被处理的缺陷按照优先程度的统计 (Active Bugs By Priority) 未被处理的缺陷数量的时间走势或趋势统计 （Active Bugs Over Time） 所有的缺陷按照严重程度的统计(All Bugs By Severity) 新被发现的缺陷按严重程度的统计 (Opened Bugs By Severity) 已处理的缺陷按照严重程度的统计 (Resolved Bugs By Severity) 被修复的缺陷按照严重程度的统计 (Fixed By Severity) 2.缺陷统计数据的度量(II) 已发现缺陷的数量和已修复的缺陷的数量的比率 (Fixed/Found)。也被称为修改率或纠错率(Fix Rate) 未处理的缺陷数量和已处理的的缺陷数量的比率 (active/resolved) 已处理的被修复的缺陷数量和已处理的缺陷数量的比率（Resolved as Fixed/resolved） 重新被激活的已修复的缺陷数量(Bug re-activation rate) 通过测试找到的缺陷的统计(Bugs opened by testing activity) 2.缺陷统计数据的度量(III) 不同语言版本缺陷数量的统计(Bugs opened by Language version) 被报告存在缺陷的各功能统计(Where your bugs were found) 处理缺陷的平均时间的统计(Average Time to Resolve) 关闭缺陷的平均时间的统计(Average Time to Close) 被处理缺陷的不同结论统计(Resolved Bugs By Resolution) 里程碑编程阶段缺陷变化趋势 3.测试案例度量 运行测试案例数量和通过测试的案例数量之比 不同产品开发阶段该比率变化 测试案例包括的范围 运行测试案例的频率 有测试案例的功能数量 4.测试规范度量 测试规范数