测试过程的度量

1）测试度量的作用（－）
　　 A:为制定测试计划时提供依据
　　　 需要多长时间?　需要什么物质条件？　 需要多少人，什么素质的人？ 在规定的时间内能完成到什么程度？
　　　　哪些模块及功能需要重点关注？ 测试工作量占整个项目的比例？ 测试结束后我们能达到什么样的目标 ？等等
( 这些数据是我们在项目启动过程中，制定测试计划，尤其在规划资源的过程中，一些必要的参考值。不同项目可能会有其特殊性，但从总体上看，他们还是有一些规律可寻的，过去的经验数据可以作为一个大概估算，如果项目经验丰富，那么可以从历史数据中找出和新项目 类似的情况，以能更为准确的完成计划。 )
　　B： 提高测试流程可控性
　　　　提高测试效率和质量
　　　　提高测试人员的成就感

2)在测试哪个过程做度量
（产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和 FOA 阶段）
我们需要在测试的几个关键阶段做度量，它们分别是：用例设计阶段、执行阶段和 FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等，测试执行阶段很明显，即我们测试的各个过程，如集成测试、系统测试、性能测试、回归测试等，也包括开发人员完成的单元测试的度量工作。 FOA 阶段是检验测试质量的第一步，通过 FOA 我们可以获得很多为产品质量做贡献的度量，这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。

3）测试度量的内容
两种度量类型：
　　　 A： 项目度量：规模、测试工作量、测试进度、测试生产率
　　　 B： 质量度量：缺陷率（阶段）、缺陷排除率、可靠性等
四个基本度量项：规模、工作量、进度、缺陷

4) 测试用例设计阶段的度量
　　　A：规模 ：测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
　　　 B： 工作量 ：文档的草稿编写工作量、评审前阅读工作量、评审工作量 、修改工作量
　　　C： 进度 ：每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
　　　 D： 缺陷 ：评审过程中出现的错误数量、缺陷数量，级别

5）测试执行阶段的度量：
? 测试用例执行率　　　　　　　? 测试用例通过率
? 测试用例问题发现率　　　　　? BUG数量
? BUG级别统计　　　　　　　　　? BUG分布统计（模块）
? BUG分布统计（阶段）　　　　　? BUG密度
? BUG关闭率　　　　　 　　　　? 人均BUG发现效率
? 测试用例执行工作量项目　　　? 回归测试执行工作量
? 发布文档数量　　　　　　　　? 发布文档缺陷数量、级别
? 现场发现的BUG数量　　　　　　? 回归测试现场BUG的工作量
? 版本发布过程中的验证周期　　? 版本发布过程中的验证工作量
? 测试用例覆盖率　　　　　　　? 功能的用户关注度
? 需求变化程度 　

6）测试的度量为项目实施做的贡献


度量项  含义 目的与意义
测试生产率 单位时间所测试的代码量、或者单位时间执行测试用例的数量  一个团队的测试能力  
工作量变化率  实际花费工作量相对于估计工作量的偏差百分比  提高估计技能、避免过载分配任务  
测试进度变化率  项目实际测试进度相对于计划进度的偏差百分比  监控项目以便适时采取纠正措施  
工作量  测试所做的工作小时数  测试为整个项目贡献的工作量  
缺陷密度  千行代码发现的缺陷数，千个功能发现的缺陷数  用于度量被测试系统的可靠性  
测试问题的严重性  测试发现问题的严重性分布  用于确定目前被测试系统的可靠性  
测试用例的问题发现效率  单个测试用例发现问题的数量  用于度量测试用例的有效性  
测试用例覆盖率  需求覆盖率、功能点覆盖率、代码覆盖率等  度量测试的充分性  
问题遗漏率  发布后市场反馈问题数/产品问题总数目  衡量内部测试质量  
COQ   为提升测试质量所付出的工作量  
COPQ    为不好的质量付出的代价  

7)由谁来做度量




8)怎样做度量?
PDCA方法：
　　　　　第一步：Plan 　　（ 计划、设置标竿） ( 计划－－制定我们想要达到的目标)
　　　　　第二步：do　　　　（执行）(日报－－记录数据)( 周报－－汇总数据，给出度量结果)
　　　　　第三步：check　　（ 检查和标竿有什么差距） (周例会－－针对度量结果，作出下一步工作建议)
　　　　　第四步：action　　（改进过程)( 阶段总结－－子系统、集成、系统测试等各测试阶段结束后做度量评估，为后续工
　　　　　　　　　　　　　　　　　　　　 作做出指导)
　　　　　第五步:return to plan