麦哲思科技

系统测试的缺陷密度越大越好，还是越小越好呢？不同的人可能观点不一致。推而广之，每个度量指标都存在这个问题，那结论到底是啥呢？

本文列举了分析时长数据时的注意事项，并结合实例给出了时长数据的常用分析方法。

如何对问题进行原因分析？如何识别出应急措施、纠正措施、管理措施、固化措施？做到技术与管理的双归零，本文将给出两个案例供大家参考。

抓大控小、减少浪费、保证质量、快速流动。

在度量工程师认证训练营的首次课程中，布置了设计先行指标与滞后指标的作业，我对作业结果做了点评，希望这些点评能够让大家领悟到设计度量指标的要点。

测试投入不足是大多数项目都面临的棘手问题。在此前提下，如何最大限度的提升软件的可靠性呢？本文给出了一个简单框架，帮助组织与项目组定义自己的测试策略、测试重点。

本文针对TMMi的每个PA，用简单扼要的一句话概括了其核心内容，便于大家在最短的时间内了解TMMi的要求。

如何度量交付后的产品质量？本文给出了四个参考度量指标，并简要分析了其优缺点，并给出一个具体场景的案例。

最后一个可控原因就是根因！何谓可控原因？即在原因分析的责任主体内可以改变的因素就是可控原因，反之责任主体无法改变的因素就是不可控因素，不可控因素应该做为原因分析的外部条件，前提条件。

硬件的生产过程是可重复的。因为对产品功能、质量的要求是相同的、生产设备是相同的，生产流程也是相同的，硬件的生产力来自于设备，因此硬件的生产可以要求生产能力又准又稳，要求生产系统可以持续地生产出满足需求的产品。而每个软件项目的需求是不同的、人员的经验与数量是不同的、开发方法与开发过程是不同的、外部干扰的频次是不同的，软件的生产力来自于人，因而软件过程满足需求的能力相对于硬件的生产过程是偏弱的。人操作硬件，硬件生产产品，人对生产质量有影响，但更重要的是硬件。需求是原材料，是抽象的，每个项目的原材料是不同的。

确认是确保做了正确的事情，方向不偏。确认可以在项目前期做，也可以在项目后期做，提倡持续确认、质量左移。在前期主要是检测需求的质量，在后期是检测完成的系统是否真的是客户所需。本文概要归纳了开发过程中常见的八种确认手段。

要降低返工成本，有两种方法：1）少犯错。2）提高缺陷修复的效率。

软件研发管理的三部曲：《以道御术》系统解释了软件研发管理的what to do。《术以载道》讲解了软件研发管理的Howto do。《数以达理》系统解释了量化研发管理的how to do。

采用Gompertz预测缺陷总数是一个简单易用的模型，准确率也比较高。在ZenDAS中可以一键触发进行分析。

原因分析是对选定的现象进行全面深入的研究，找到现象背后的真正原因与深层次原因，然后采取合适的措施纠正问题、预防问题。如果没有找到真正的根因就采取措施，往往事倍功半，浪费了投入。那么在原因分析时，有哪些成功要点呢？基于我多年的咨询与引导经验，我总结了如图1所示的十个要点。

在工作中领导最讨厌的人就是总把简单的事情做错的下属，在绝大多数人不会犯错的地方犯错，在领导眼中会判定为是基本素质问题，是不可原谅的。如果组织要裁员，那优先裁掉的就是哪些总是犯低级错误的人。那如何确保能够把简单的事情一次做对，提升自己的职场竞争力呢，请参考如下的七步工作。

在设计度量体系时，可以把度量指标分为滞后指标与先行指标，二者的区别是什么呢？

ChatGPT自推出以来，迅速风靡全球，做为质量管理人员，如何利用ChatGPT更好的进行质量管理呢？以下我们通过9类实例来看看它能起到哪些辅助作用。

CMMI模型有很多实践，如何准确理解其含义呢? 下面分享一下我多年的研读经验。

在对质量数据分析时，应该对哪些活动，采集哪些度量数据，采用什么方法进行分析呢?请参考本文给出的系统归纳。

ChatGPT刮起了一阵旋风，ChatGPT到底能做什么？做到什么程度？真的会让咨询顾问失业吗？

总结了一下在咨询过程中看到的测试过程的常见问题，梳理出来进行测试过程改进的关注点

年度总结报告怎么写？掌握以下九个要点!

需求用户需求时，应该有几个人参与呢？分别承担什么职责呢？怎么和用户澄清需求呢？三驾马车的做法可以帮你更高效地获取需求！

实施了代码走查，效果如何呢？我们可以通过定量的数据进行分析！数据中隐藏着结论，我们要努力发现它！

初创团队，迭代总结会议以后，有哪些可以改进的地方呢？

采用Gompertz模型预测缺陷的收敛趋势，简单易行，拟合效果很好！

采集了客户满意度的数据后，可以从哪些维度进行统计分析呢?本文给出了一个具体案例，通过七张图分析客户满意度的数据！

测试用例评审应该如何做？

澄清一下关于流程的基本概念与理念。

这是一个很有意思的话题。很多人对此困惑。困惑在什么地方呢? 从开发的角度看，是希望系统测试发现的缺陷越少越好，那意味着在开发阶段都把缺陷找干净了。 从测试的角度看，是希望系统测试时把缺陷找干净了，不要遗留给客户去发现。在潜在的缺陷数恒定的前提下，找到的缺陷越多越好。 在组织级确定质量目标时，这个系统测试缺陷检出密度到底是定义为越高越好，还是越小越好呢？系统测试缺陷检出密度的大小能代表产品质量吗？ 产品质量只能通过上线后的缺陷多少来衡量，上线后的缺陷密度越小越好...

在SPC中，对过程的偏差区分了信号与噪音，信号是特殊原因造成的偏差，噪音是普通原因造成的偏差。这两类原因有啥区别呢？我归纳整理如下：　 普通原因 特殊原因 定义 普通原因指的是造成随着时间的推移具有稳定的且可重义的分布过程中的许多变差的原因，我们称之为:“处于统计控制状态”、“受统计控制”，或有时简称“受控”。普通原因表现为一个稳定系统的偶然原因。只有变差的普通原因存在且不改变时，过程的输出才是可以预测的。 特殊原因(通常也叫查明原因)指的是造成不是始终作用于过程的变差的原.

自20世纪70年代以来，M. M. Lehman通过对软件系统演化现象的观察，陆续总结了8条定律，称之为定律并非那么严谨，但是对于认识软件维护的规律，改进软件维护的过程具有很好的指导意义。1 （1974年）持续变更定律。系统必须持续调整以适应各种变化，否则这些系统将变得越来越不令人满意。2 （1974年）复杂度增长定律。随着系统的演化，其复杂度会逐渐增加，除非采取措施来降低或保持其复杂度。3 （1974年）自我调整定律。软件演化过程的是自调整的，每次演化版本的度量数据近似正态分布。4 .

CMMI V2.0中GOV与II两个PA比较抽象，我通过实施案例来帮助大家解释一下这2个PA中每条实践的含义。PA 实践编号 Measures校对后的中文翻译 针对培训过程的实施案例 针对编码过程的实施案例 GOV 1.1 高级管理者识别开展工作的要点，并定义实现组织目标所需要的方法 老板要求每个部门有人负责培训工作。 每个部门每个月至少要有1次技术培训。 每个部门每2个月至少要有2次管理培训。 每次培训应该制作录像，便于重复培训。.

1 预测区间与置信区间的差别 预测区间估计(prediction interval estimate)：利用估计的回归方程，对于自变量 x 的一个给定值 x0 ，求出因变量 y 的一个个别值的估计区间。变量的估计叫预测区间，预测区间反映了单个数值的不确定性； 置信区间估计(confidence interval estimate)：利用估计的回归方程，对于自...

某企业积累了10个项目的历史度量数据，积累了5个阶段的缺陷密度，即从需求评审的缺陷密度，直至交付后3个月内的缺陷密度，计量单位统一为缺陷数/KLOC。 需求评审缺陷密度 设计评审缺陷密度 代码评审缺陷密度 测试发现缺陷密度 交付后缺陷密度 P1 ...

我梳理了一下，整理成下表给大家参考，也比较好记忆，回归之前六条，回归之后六条：检查回归方程的有效性 回归分析之前 1 对y进行正态分布的检验,如果y不服从正态分布，则需要进行变换。 2 通过相关性分析，判断x与y的相关性，如果不相关，则不需要纳入此x到方程中。 3 通过相关性分析，判断x与x之间的相关性，相关的x不能出现在同一个方程中。 4 通过散...

当我们对一些现象进行回归分析之后，可以得到回归方程y=ax+b，很简单的一根直线，如果结合我们的实际应用场景，则可以从该方程的2个系数中发现很多问题：1 当b比a大很多时，如何理解？比如，工作量=10*规模+10000此时：b=10000为固定成本， a=10为变动成本。说明在这家公司中，项目一立项就有比较高的固定成本！需要减少无用功，降低很多与直接生产无关的...

在研究Y与X之间的因果关系时，如果Y不是一个定比或定距变量时，就需要进行logistic回归。logistic回归是一种广义线性回归（generalized linear model）。logistic回归根据Y的取值分为三类： logistic回归分析类型 因变量Y的特征 举例 二元logistic...

项目级的目标要与组织级的目标相匹配，他们关注的是同一件事情，但未必是同一个度量元，请看下边的案例。 某公司积累了2013年到2018年期间66个里程碑的工期偏差率数据如下： 序号 里程碑工期偏差率 序号 里程碑工期偏差率 序号 里程碑工期偏差率 ...