欢迎来到
扫码阅读
手机扫码阅读
测试投入度量元的选择
281 2024-10-02
我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。
查看原文：测试投入度量元的选择
文章来源：
麦哲思科技任甲林
扫码关注公众号
项目在讨论测试是否结束时常常关注缺陷的数量、严重级别和关闭情况，而忽略了测试投入是否充分。测试投入可以通过多个方面量化，例如测试用例的密度、工作量、工期和人数等。
选择合适的测试投入度量元需要根据产出来定，通过收集多个项目的度量数据并分析其与测试产出的相关性来判断。如果度量元与测试产出相关，则可作为测试投入的度量元；否则应舍弃。
系统测试用例密度是一个合适的度量元，如图二所示。而图三显示，缺陷逃逸率与测试工作量/开发工作量不是合适的度量元，这一点在不同公司可能不同。
在其他条件相同的情况下，测试投入充分时，发现的缺陷多意味着代码质量差，缺陷少则代码质量好。图四说明，当测试投入达到8人天/KLOC，缺陷密度趋于平稳，此时可认为测试投入充分，无需进一步测试。
想要了解更多内容？
查看原文：测试投入度量元的选择
文章来源：
麦哲思科技任甲林
扫码关注公众号
相关推荐
359这个问题客户问过我，我也解答过多次，但是我一直没有更直接的理由说服我自己，认为必须先做规模估计再做工作量估计。 比如：对维护类的项目，或者是维护类的活动，为什么要估计规模呢？项目组的人没有技术风险，对需求很熟悉。 我总结了如下的理由： （1） 以规模来估计工作量与成本 （2） 规模估计与实现的人与技术无关，比较客观 （3） 可以度量项目的开发效率：规模/工作量 （4）
麦哲思科技（北京）有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员，中国分部主席
425 篇文章
浏览 237.7K
麦哲思科技任甲林的其他文章
如何比较两种估算方法的准确性？
有公司在做软件规模估算时，采用了经验法估计了代码行，又设置了难度系数，重用率，重用规模系数三个调整参数。如果初始估计规模为1KLOC，难度系数为1.1，重用率为20%，重用规模系数为50%，则调整后的规模为：1*1.1*（1-20%）+1*20%*50%=0.88+0.1=0.98KLOC。我看到该估算方法后认为有些复杂，而且不好理解，有可能是做了无用功了，所以我想通过数据进行检验看看调整后的规模是否比初始的规模估计更准确，如果不如初始的规模估计更准确，则可以放弃三个调整系数。该公司A部门有11个历史项
EPG如何应对企业政治？
流程的改进，总是会涉及到人的利益。有的人不愿意放权，有的人不愿意暴露自己的问题，有的人不愿意改变工作习惯，有的人不愿意被束缚，有的人就是看EPG不顺眼，有人的地方就有政治，有的人希望借助过程改进获得更多的利益，如何应对呢？
1 坚持正道。
何谓正道？
公司的规章制度即为正道。公司的规章制度定义了做事的原则、方法，是公司的法律，循规蹈矩，别人无法指责你的错误，这样才能立于不败之地。否则，你不遵纪守法，则反对你的人就很容易否定你，我不犯错，你耐
软件项目宏观管理策略点睛
根据国际知名调查机构standish集团的统计，真正成功的项目仅有26%，而其他项目都可以算作失败项目。为什么这么多的项目都失败呢？问题出在哪里呢？依据笔者的经验，很多项目实际上是败在了初期，败在了启动时，败在了项目的宏观管理策略上。即，没有根据项目的特点采用合适的管理策略，即使后续的管理方法再细致也没有用了。我推荐如下八个感触颇深管理策略，供软件项目的管理者借鉴：
多团队协同开发的18条实践
本文总结了18条多团队协同开发的实践。
如何理解别人写的需求规格说明书？
在开发过程中，开发人员、测试人员都需要阅读其他人写的需求规格说明书，当阅读别人的需求文档时，我们需要关注什么呢？参见下图的要点： 首先需要了解关于该系统的总体信息，主要包含2条： 1 明确出该软件与其他系统、人、设备的交互关系。可以通过环境图，帮我们梳理清楚该软件与周边环境的关系，从宏观上对软件所处的位置有所理解。如下图所示： 2 系统的目标是什么，即解决了客
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线
