软件测试过程的度量

软件测试过程的度量

测试过程的度量

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

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

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

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

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

7)由谁来做度量

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

本文转自网络

谈一谈软件测试过程中的度量

最近和同事针对分中心要求的研发测试过程所能度量的指标进行了讨论，借着72小时定律输出下对测试度量的思考，和大家一起探讨下

度量是对产品研发过程、产品质量进行相关数据收集并分析的持续量化过程，目的是为了优化过程，提高质量，促进项目成功；

按照质量改进的模型来拆分下度量过程：定义度量指标-》收集指标数据-》分析数据-》改进-》控制

1、定义度量指标、数据收集

按当前所在项目的度量对象来区分：

产品质量，以产品属性、要求为对象来度量；比如：故障率、结果产出

根据当前所在项目的测试交付阶段来细分，以迭代为周期收集

测试交付阶段

度量指标

数据收集

数据评测

敏捷特性交付

测试设计条目数

自动收集

日均产出

测试自动化脚本数

自动收集

增长率

集成测试故障单

自动化收集

日均产出数

特性故障泄露率

手工收集

降低率

敏捷验收交付

验收特性个数

自动收集

增长率

验收测试故障个数

自动收集

增长率

验收偏移率

手工收集

降低率

系统测试交付

系统测试故障个数

自动收集

日均产出数

测试需求覆盖数

手工收集

增长率

版本故障泄露率

手工收集

降低率

测试管理，以测试本身为对象来度量，比如：按时交付率、交付周期

同样以当前所在项目的测试交付阶段来细分，以迭代为周期收集

测试交付阶段

度量指标

数据收集

数据评测

特性测试交付

特性全Feature  Done占比

手工收集

增长率

敏捷验收交付

验收交付周期

自动收集

减少时长

系统测试交付

整版本测试交付周期

自动收集

减少时长

2、数据分析

采集的度量数据，通过一定的指标来判断数据的合理性，以此推断出交付成果、测试质量、测试完整性、测试效率等

当前项目暂时还没有对每项的严格的量化指标；主要是以迭代为单位对比判断指标的合理性；比如：

交付成果：同等人力情况下，迭代的交付成果（测试设计、自动化数、故障数）情况，提升or下降

测试质量：测试设计命中故障率、需求发现故障数……

测试完整性：测试覆盖需求的百分比等

测试效率：同等任务量情况下，版本交付周期变化情况

3、改进+控制

分析后的数据形成相关的报告，和迭代复盘结合完成相关的改进；对应各项的异常数据指标，开会讨论出改进举措；定期跟踪、落地闭环
谢谢你能坚持看到这啊，每一份在看都是鼓励

为什么软件测试的质量需要有度量

在软件开发中，软件度量的根本目的是为了管理的需要。利用度量来改进软件过程。人们是无法管理不能度量的事物。对于管理层人员来说：没有对软件过程的可见度就无法管理;而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策，也无法进行优秀的管理。我们说软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科。这就需要使用度量。度量是一种可用于决策的可比较的对象。度量已知的事物是为了进行跟踪和评估。对于未知的事物，度量则用于预测。

软件测试中对软件质量进行度量的指标常用的有哪些？

你好！
有N多种指标：
缺陷统计数据的度量(I)
所有缺陷数量的时间走势或趋势统计 (Bug Trends By Time)
未被处理的缺陷按照严重程度的统计 (Active Bugs By Severity)
未被处理的缺陷按照优先程度的统计 (Active Bugs By Priority)
未被处理的缺陷数量的时间走势或趋势统计 （Active Bugs Over Time）
已发现缺陷的数量和已修复的缺陷的数量的比率 (Fixed/Found)。也被称为修改率或纠错率(Fix Rate)
未处理的缺陷数量和已处理的的缺陷数量的比率 (active/resolved)
已处理的被修复的缺陷数量和已处理的缺陷数量的比率（Resolved as Fixed/resolved）
重新被激活的已修复的缺陷数量(Bug re-activation rate)
通过测试找到的缺陷的统计(Bugs opened by testing activity)
所有的缺陷按照严重程度的统计(All Bugs By Severity)
新被发现的缺陷按严重程度的统计 (Opened Bugs By Severity)
已处理的缺陷按照严重程度的统计 (Resolved Bugs By Severity)
被修复的缺陷按照严重程度的统计 (Fixed By Severity)
不同语言版本缺陷数量的统计(Bugs opened by Language version)
被报告存在缺陷的各功能统计(Where your bugs were found)
处理缺陷的平均时间的统计(Average Time to Resolve)
关闭缺陷的平均时间的统计(Average Time to Close)
被处理缺陷的不同结论统计(Resolved Bugs By Resolution)
详细的信息你可以留下邮箱，我发给你文件！

以上就是小编为大家整理的关于软件测试过程的度量的全部内容，更多相关知识请持续关注学分高考!