软件测试过程的度量
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