软件产品质量度量

软件产品质量度量张奭（KellyZhang）[e-mail]软件开发测试主管MicrosoftOffice国际服务测试部美国微软总部2自我简介•张奭(ZhangShi)，英文名是KellyZhang•软件开发测试主管。美国微软总部，MicrosoftOffice国际服务部。•教育背景:北京师范大学获得学士和硕士学位。美国纽约州立大学获得博士学位•工作经验:近九年软件测试，测试项目主管，和发布协调总管工作经验3主要议程一．为什么软件质量需要有度量？（必要性）二．使用软件测试的质量度量的挑战三．评价软件质量的优秀度量的特征四．制定软件质量度量时注意事项五．微软软件质量测试常用度量六．使用软件质量度量的注意事项问题解答4一为什么软件质量需要有度量？有效产品质量管理改进用户满意度改进产品质量减少产品开发和售后服务支持费用没有质量度量，等于没有质量标准！5软件测试的质量需要有度量有效实行测试质量分析和管理可及时检查测试进度和质量帮助发现测试漏洞比较测试质量变化趋势，风险分析帮助找出最佳实践6二使用软件产品质量度量的挑战无公认准确和科学的度量产品性质不同，很难有通用的度量最佳实践实际上是经验积累总结涉及不定因素和人为因素片面理解和使用可以造成负面影响和效果7三评价软件质量的优秀度量的特征准确性稳定性可验证性有针对性有说服力重复使用性可追踪性简单实用性8四制定软件质量度量时注意事项跟踪度量的变化的一致性提供基础数据以便杜绝滥用数据讨论会或所有有关方面认可体现产品质量结果是否满足质量标准明确谁是使用者9五微软软件质量测试常用度量1.产品设计规范(Spec或设计文档)质量状态2.缺陷（bug）数据有关度量3.测试案例度量4.测试规范度量5.测试过的系统数量6.自动化测试度量7.CodeCoverage（代码覆盖）8.单一功能测试验收质量度量101.产品设计规范质量状态分类常用的五种状态一页(Onepage)–用于安排时间和分配人员草稿(Draft)–用于提出疑问和初步设想以供讨论审阅(Review)–有所有的设计技术细节，可以供审阅提交审核会(Inspection)–所有的设计技术细节到位、没有明显遗留疑问、漏洞等开始编码(Coding)–开发人员可以开始便写代码来实现该设计功能规范11产品设计规范质量到位状况五种状态中各占的%是多少?按事先计划日程完成的比例是多少？多少%开发人员至少有一个指派给他的功能可以进行编码？122.缺陷统计数据的度量(I)所有缺陷数量的时间走势或趋势统计(BugTrendsByTime)未被处理的缺陷按照严重程度的统计(ActiveBugsBySeverity)未被处理的缺陷按照优先程度的统计(ActiveBugsByPriority)未被处理的缺陷数量的时间走势或趋势统计（ActiveBugsOverTime）所有的缺陷按照严重程度的统计(AllBugsBySeverity)新被发现的缺陷按严重程度的统计(OpenedBugsBySeverity)已处理的缺陷按照严重程度的统计(ResolvedBugsBySeverity)被修复的缺陷按照严重程度的统计(FixedBySeverity)13时间缺陷数量所有的缺陷按照严重程度的统计(AllBugsBySeverity)142.缺陷统计数据的度量(II)已发现缺陷的数量和已修复的缺陷的数量的比率(Fixed/Found)。也被称为修改率或纠错率(FixRate)未处理的缺陷数量和已处理的的缺陷数量的比率(active/resolved)已处理的被修复的缺陷数量和已处理的缺陷数量的比率（ResolvedasFixed/resolved）重新被激活的已修复的缺陷数量(Bugre-activationrate)通过测试找到的缺陷的统计(Bugsopenedbytestingactivity)152.缺陷统计数据的度量(III)不同语言版本缺陷数量的统计(BugsopenedbyLanguageversion)被报告存在缺陷的各功能统计(Whereyourbugswerefound)处理缺陷的平均时间的统计(AverageTimetoResolve)关闭缺陷的平均时间的统计(AverageTimetoClose)被处理缺陷的不同结论统计(ResolvedBugsByResolution)16里程碑编程阶段缺陷变化趋势CumulativeBugcount(OpenedandResolvedBugsonSecondaryaxis)01000200030004000500060007000800090001000012/4/200312/18/20031/1/20041/15/20041/29/20042/12/20042/26/20043/11/20043/25/20044/8/20044/22/20045/6/20045/20/20046/3/20046/17/20047/1/20047/15/20047/29/20048/12/20048/26/20049/9/20049/23/200410/7/200410/21/200411/4/200411/18/200412/2/200412/16/200412/30/20041/13/20051/27/20052/10/20052/24/20053/10/2005WeekEndingBugs0100200300400500600700TotalBugsClosedBugsActiveBugsResolvedBugsOpenedBugs173.测试案例度量运行测试案例数量和通过测试的案例数量之比不同产品开发阶段该比率变化测试案例包括的范围运行测试案例的频率有测试案例的功能数量184.测试规范度量测试规范数量和所有功能数量之比满足撰写要求的测试规范数量和所有测试规范数量之比必要的内容遗漏的比率测试规范:微软把针对怎样测试某功能的，有细分功能后的具体测试条例等细节的测试文档叫做测试规范（TestDesignSpecification或简称TDS）。195.测试过的系统数量所支持的不同语言系统的总数与测试过的语言系统数量所支持系统的总数与测试过的系统数量Windows2000(SPx)WindowsXP(SPx)Windows2003Server(SPx)TabletPC新的系统平台206.自动化测试度量测试的可自动化程度能自动化的和实现自动化的比率运行通过的自动化脚本比率不同产品开发阶段该比率变化217.CodeCoverage（代码覆盖）代码覆盖度量定义和目的代码覆盖种类代码覆盖的有效使用开发人员：单元测试(unittesting)测试人员：系统测试(systemtesting)和自动化测试22代码覆盖是什么？动态白盒测试评价技术已经执行（测试）了什么（whathasbeenexecuted）没有执行的（测试）有什么whathasnotbeenexecutedandstillremainstobetested.需要有源代码内部辅助工具23使用代码覆盖度量的目地经验总结：大约的20%代码囊括缺陷总数的80%目的不是要达到某个神奇的数字，而是要发现测试中的漏洞达到比较广泛的覆盖率相对容易，但要达到100%覆盖常需要多得多的成本平均目标65%理想目标75%24代码覆盖度量种类1.代码函数覆盖数量2.代码运行使用到的功能覆盖数量3.代码数据种类覆盖数量4.代码函数条件覆盖数量5.代码通路(path)覆盖数量25代码覆盖结果分析26使用代码覆盖度量改进测试代码覆盖度量只能揭示测试的漏洞，并不能直接改进测试为什么有些代码没有执行到？脚本运行时执行到了代码不意味着测试的深度和全面性先查功能代码覆盖率，再计划写自动化脚本的优先顺序撰写测试用例已覆盖所有要测试的功能行为，然后编写自动化脚本加以验证添加新自动化脚本覆盖找到的漏洞27使用代码覆盖度量结果分析没有覆盖代码的可能原因和改进措施：遗漏的功能行为：追加测试程序中有‘死角’代码，没有功能行为可以执行该代码：删除？很难模拟的出错条件：可否有其他方法？过时的功能规范？--更新功能规范288.单一功能测试验收质量度量预先计划的详细测试：100%完成？自动化测试覆盖率：≥65%？自动化测试运行结果：0%失败率？发现缺陷的难易程度：4小时发现缺陷≤2缺陷严重度和数量变化趋势：近期无高严重度缺陷功能稳定程度：近期代码无需改变、自动化运行一直保持100%通过29六使用软件质量度量的注意事项和建议应当加以分析后挑选适当度量不应作为唯一的测试质量衡量标准考虑人为因素和不定性因素的影响同一产品不同功能也应使用统一衡量标准分析度量结果以指导测试和开发过程研发适合自己产品使用的质量度量30问题解答？谢谢大家！欢迎交流！31