测试投入度量元的选择

发布于 2024-10-02
1621
版权声明

我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。

查看原文：测试投入度量元的选择
文章来源：
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
测试投入度量元摘要

项目在讨论测试是否结束时常常关注缺陷的数量、严重级别和关闭情况，而忽略了测试投入是否充分。测试投入可以通过多个方面量化，例如测试用例的密度、工作量、工期和人数等。

选择合适的测试投入度量元需要根据产出来定，通过收集多个项目的度量数据并分析其与测试产出的相关性来判断。如果度量元与测试产出相关，则可作为测试投入的度量元；否则应舍弃。

系统测试用例密度是一个合适的度量元，如图二所示。而图三显示，缺陷逃逸率与测试工作量/开发工作量不是合适的度量元，这一点在不同公司可能不同。

在其他条件相同的情况下，测试投入充分时，发现的缺陷多意味着代码质量差，缺陷少则代码质量好。图四说明，当测试投入达到8人天/KLOC，缺陷密度趋于平稳，此时可认为测试投入充分，无需进一步测试。

麦哲思科技任甲林

查看原文：测试投入度量元的选择
文章来源：
麦哲思科技任甲林
扫码关注公众号
相关推荐
质测攻坚：智慧客服软件质量保证体系精进之路
2284
系统思考，以点破局，锁定要害，别出机杼，从测试流程、测试设计、测试策略、风险预警、版本交维、自动化测试等多方面进行攻坚，开启了全方位提效保质体系建设之路。
为什么必须首先做规模估计?
1519
这个问题客户问过我，我也解答过多次，但是我一直没有更直接的理由说服我自己，认为必须先做规模估计再做工作量估计。 比如：对维护类的项目，或者是维护类的活动，为什么要估计规模呢？项目组的人没有技术风险，对需求很熟悉。   我总结了如下的理由： （1）     以规模来估计工作量与成本 （2）     规模估计与实现的人与技术无关，比较客观 （3）     可以度量项目的开发效率：规模/工作量 （4）
5步法助力自动化转型
1785
测试 自动化
手动测试人员应该权衡测试自动化相对于手动测试的好处，并且即可开始行动。
大话敏捷测试
2185
测试 敏捷 团队 测试人员
敏捷测试既是整个敏捷团队的活动，又是测试人员在敏捷背景下如何测试的理念和方法。
Jmeter的基础使用（图解）
1363
坚持，所以从不畏惧
先选对测试，再决工具
162
测试 自动化 团队 流程
大多数工程团队都知道需要测试自动化。理由并不难
麦哲思科技任甲林

麦哲思科技（北京）有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员，中国分部主席

471 篇文章
浏览 1147.8K

还在用多套工具管项目？

一个平台搞定产品、项目、质量与效能，告别整合之苦，实现全流程闭环。

查看方案
麦哲思科技任甲林的其他文章
迭代策划会议（Sprint Planning） 的实际案例
某项目组第一次采用敏捷方法进行开发，确定了迭代周期为三周。该项目组投入的资源如下：前端开发工程师一名；后端开发工程师一名；测试工程师一名；PO一名；SM一名；前后端开发采用不同的技术，熟悉前端开发的工程师不熟悉后端的技术，后端开发的工程师也不熟悉前端使用的技术。当第1周结束后，由于前端开发人员使用的是新技术，需要熟悉新技术，而后端工程师与测试工程师的投入都不到位，因此估算工作量与实际工作量差别比较...
如何学习CMMI
很多朋友问我关于CMMI模型中的问题，却很少有朋友问我如何学习CMMI，这便是鱼与渔的问题。就事论事，学会一个的知识点，不如去掌握方法，可以解决很多的问题，学习到无限的知识。   那么，究竟如何学习CMMI呢？我的体会如下：   （1）       通读模型 模型是众多的专家总结的经验教训，历时多年，讨论了N遍才写成的，模型里包含的信息量很大，描述的
实施敏捷的四个致命障碍
敏捷方法在中国推行的如火如荼，我也为多家公司做了敏捷的导入咨询，在实践中遇到了几个致命障碍，限制甚至阻止了敏捷方法的推行，我把有深刻体会的障碍总结出来，供大家在实践中规避之。障碍一：没有建立组织级的敏捷价值观与环境。 很多公司在导入敏捷时，先从一个项目开始尝试敏捷方法，试图在单项目内成功了，再推广到其他项目。这种初衷是好的，但是往往事与愿违，为什么呢？因为缺乏组...
敏捷方法开发总结的点评记录
某项目组采用敏捷的方法完成了一个项目，在此过程中，每次迭代结束后，项目组的每个成员都总结了本次迭代的经验教训，我汇总这些经验教训后，点评如下：
例解:目标驱动的度量元识别方法
(1)识别需要数据的人(Person）: 服务经理(2)识别管理目标（Goal）/要解决的问题(Problem)：提高客户请求的处理速度(3)定义如何量化管理目标/要解决的问题：（3.1）识别被度量的对象(Object)：待处理的客户变更请求(3.2) 识别被度量对象的属性(Attribute)：待处理的变更请求的个数      待处理的变更请求的计划工作量(4)识别如何展示度量数据(Indica
随机阅读
理解用户，靠算法还是人性？
07-12
产品代办列表梳理的艺术
08-17
为何你学习的时候记住了这个,忘记了那个？你需要知道你的《认知天性》
08-17
点击即得：敏捷价值流管理攻略！
08-21
PDCA循环：快速提升软件质量的必备工具
08-21
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
去下载