高质量的数据，是缺陷分析的基础，可以从两个方面大的方面来保证数据质量：一、利用管理系统保证（建立系统间的关联 ，统一的源数据管理）二、减少犹豫KPI牵引导致的数据失真（例如KPI考核缺陷分类，开发就会有意识地选择某些分类）

数据质量的影响因素有哪些？

一、人为因素，不适当的KPI牵引 会导致数据质量差。二、管理系统 系统的不完善，信息孤岛会导致数据的一致性存在问题数据采集 主要分为人工和系统采集。前者效率低下，易错，质量差很多企业都是使用Excel在做一些管理。后者需要有完善的产品研发管理系统（比如 配置管理，项目管理。变更管理等）、需要做一些数据集成的工作。对企业的IT基础建设要求高。目前市面上的管理系统很多，基本上实现流程管理的自动化，但数据采集略差。需要有IT的支撑。

缺陷分析是种项目管理，监控的手段，不是目的。缺陷分析的结果更多的是要应用到发现问题，找出根音项目过程的改善。千万不要应用到考核中，这样大家会把分析过程当成差事去做。分析的效果会大打折扣。而且有些根本原因也无法找到。举个例子：之前我们要考核review发现问题的占比，因为系统测试发现的问题太比较多。为了降低这个比例。开发捏造了很多假的review数据。

正如大Q（全面质量管理） 提到的全员参与。缺陷分析 最好是多角色参与，从不同的角度发现问题：比如市场人员，系统设计，开发人员，测试人员，运维人员，质量管理人员。从各自不同的角度发现问题，比如质量管理人员去发现流程上的问题。开发发现实现上有什么问题，测试人员要去分析为什么在测试阶段没有发现这个问题等。强调一个全员的参与，这也符合分析的需要。分析本来就是一个问题题不是选择题。千万不能一言堂，要集各家之长去找到真正的问题。

在实际工作中发现：有些企业虽然定义了缺陷分析的流程，但是很多时候只是 质量部门一家在动，开发无动于衷。毕竟质量部门的业务知识相对欠缺。所以可想而知 这样的缺陷 就是流于形式，根本无法找到原因。后续的改善从而来。只能是为了分析而分析，实质作用并不是很大，所以所全员参与 是 有效缺陷分析的基础和保证。质量意识 要根植于 质量文化中。这一个需要长期不断培育，培养的。不是一朝一夕。

缺陷分析的指标体系。企业做大之后，一定不是手工作坊，一定是要标准化管理。所以很多企业在标准化的路上会去部署CMMI敏捷。那组织别定义一定的指标体系，可以让项目组 不需要从0开始。同时组织定义指标体系，可以帮助一些初级的项目经理有些参考，在此基础上可以做一些裁剪。定义符合项目组自身的指标分析体系。当然 企业在建立指标体系后，如果能够建立自动化的数据采集，数据呈现，数据预警，预测。这样项目管理者的分析活动会降低难度。可以更好地聚焦于业务。

指标体系的建立是一个长期的不断磨合的过程。需要不断地去优化，不断地去适应企业的项目。做的更好的企业会根据不同类型的项目定义不同的分析方法。一般在建立指标体系的时候 可以参考一些业界的实践书籍（PSM实用软件度量） 软件过程管理与度量等等。这里提到的体系 是属于初级的数据分析，更高级的可以 借助数据挖掘，机器学习。把企业内部的数据（代码提交，缺陷，人员从业经验，缺陷的log）进行一个自学习。建立一些模型，在过程中发现问题：比如 项目组某员工在提交代码前 没有做自验证活动，系统能够自动提示他风险的存在。再比如：测试发现问题后，能够根据log匹配到，这个问题可能的原因，最适合 哪位工程师去解。这些东西在国外 已经有大学在研究。不久的将来一定会传到中国部署到软件项目中去。

帕累托分析，就是所谓的28原则分析。基于此找出影响缺陷最大的原因。在此基础之上可以借助5why、鱼骨图去打破砂锅问到底，找到真正原因。因为我们知道，每个缺陷的产生，必然有其原因。要知其然更知其所以然。要不然 头痛医头 脚痛医脚 。只会带来更多的浪费。除了这些方法之外，业界还有ODC、IBM提出的缺陷正交分析法，这个方法的核心是将缺陷的分类更纯粹，各个分类之间是相互独立的。

还有CMMI评估师最喜欢用的 缺陷 移除引入 矩阵分析。所有的分析都是有成本的，业界还会使用投入产出 四象限分析法，在生产型企业还会借助统计学的分析方法，做一些假设检验，控制图的分析。

很多企业目前的分析，主要是侧重于系统测试，外场故障线上问题的分析。这些其实比较后端了。质量的理念是预防。防患于未然，有些企业还会及时分析需求review，设计review代码review测试用例review发现的问题。这样保证了分析的及时性，跟敏捷的理念是一样的，强调了分析的实时性，快速分析，快速反馈，第一时间发现问题。停下来解决问题。而不是等到缺陷发生了再去补救。 补救的成本是相当高的。缺陷小到会让开发人员疯狂加班。大到影响企业的经营，存亡。

要分析，设计，编码，测试用例的问题分析。要去权衡 找到一个合适的方法，毕竟分析 需要成本，如何去记录问题，如何去分析 都是项目组 企业需要去考虑的。分析并非面面俱到。而是要结合实际。

主要是涉及系统 工具，企业文化，流程，人 。缺一不可。所以说 缺陷分析的路 任重而道远。作为 一个工程工程师也好，项目管理人员，质量管理人员。都得发挥各自的光和热。只有这样，分析才会有效，才不会流于形式。当然，一切一定要以企业的商业目标为出发点。

线上缺陷或者事故应该怎么处理？

其中一个做法：首先线上问题的收集是独立部门在做。避免产品瞒报 少报 漏报的问题。这 是采集部分。 第二：对于数据分析 主要是为了发现问题。线上 问题会拆分到 系统设计部，开发部，测试部。这是定责。定责之后，就进入分析的流程。一般来说：分析从两个角度，这个问题如何解决，有什么好的避免方法。为了避免这类问题，现有的系统，工具，流程需要做什么改善。第三：因为人都是利益驱动，在一定的情况下，线上问题与管理者的绩效挂钩。迫使管理者重视起来。只有重视起来后，才会将分析做到位。第四：分析 对事不对人。这点在国内 特别难以开展。

技术上的话：主要是分析问题为什么会产生：主要需求，设计，实现，集成，运维的角度，去考虑。这些得结合您企业的产品特性去因地制宜了。

举一个案例：公司的核心网产品出了一个严重事故，运营商的系统升级无法继续，系统回退。立即展开调查。发现是：配置人员把代码发布到运营商做版本的时候，漏合了代码，导致功能不可用。

针对这种情况，从质量的管理的角度，需要规范化版本构建，验证流程。因为影响到客户的都是大问题。分析完后，就是惩罚。各级领导罚款，包括员工也罚款。

KPI的定义：一定要商业目标驱动（比如说：商业目标时提高上市的周期 那么 进度，问题解决效率这块都是重点考察的）

KPI的目标分解很有有讲究，局部的目标达成未必 整体绩效会提升（举个例子： 公司对里程碑的按时完成有要求，所有该里程碑发现的问题需要清0，公司的系统自动会转变问题的转台，但是某些人有权限可以自动改变状态。导致恶意为了缩短在开发这边时间。恶意修改状态 。

性能算不算缺陷。这就得谈谈缺陷的定义了：不符合需求都是缺陷。很显然 性能也是一种需求，属于非功能性需求。是呈现给用户最直接的东西，比如登录要在3s内完成，数据量多的时候支持分析显示异步加载。这种问题其实更影响用户的体现。尤其是哪些涉及人机交互的软件。

如何推动性能测试的解决：可以在初期定义KPI缺陷解决周期，缺陷及时解决率。以及缺陷一次性解决率。三者相互约束不怕你不解决。再不行就和奖金挂钩这个比较阴，但是很多企业是这么做的。以前我的领导每年被罚款要好几万。

每个迭代都做缺陷分析。体现敏捷的及时反馈。帮助项目及时发现问题，可以作为迭代回顾会的一个输入。流程不一定要很复杂

这个问题短期内无法解决的，首先要分析这个问题是否影响发布。如果不影响可以规划到后面的迭代。如果影响 得建立攻关小组集中火力去火拼。优秀员工的价值这个时候就可以提现出来了。

缺陷管理的坑：不好的KPI牵引 导致数据失真。系统的问题。这个前面提到过。

同一个迭代产品开发完还来不及做这个迭代的测试，可否这个迭代做上一个迭代的测试？老师有啥经验分享不？--这个问题： 可以适当调整每个迭代的backlog。确保每个迭代的输出是workable software。

当然有些企业是多个迭代后 再发布，不影响进度的情况下。到下一个迭代再测未尝不可。

考量测试的KPI要看组织目标：比如我们之前提倡及时尽早发现问题。那么我们定义了前几轮发现的问题权重大，后面的权重小。用权重后的数据来考量测试。

再比如：提倡发现严重的问题。会考量：加权后的缺陷数量A15 B->10 C-3 D-1

当然在定义KPI的时候一定要定义相互约束的KPI，另外KPI最好不要用于考核评价 。但是在国内企业氛围导致了无法做到这一点，敏捷的项目中，如何跟上项目的节奏保证质量：可以引入自动化测试TDD测试驱动开发。其次，引入一些自动化工具：sonar K9 prevent做静态动态的检查。借助软件帮助开发人员一些问题，开发人员及时解决这些问题，接口这块，可以从预防和补救两个方面来。

接口测试预防措施：

一、设计的时候 分析清楚 定义接口的 。开发过程中要多交流 及时讨论接口的变更。

二、做一些自动化接口测试 比如restapi，做些模拟，找一些模拟器，信号发生器。

三、及时做集成。 设计更多的用例 去覆盖接口测试这块 比如引入TDD。补救方面：出了问题及时响应，摆正态度。

安全测试：在公司会有一整套流程，需要从需求、设计、实现测试阶段把握。在需求阶段 会有一个检查表，让开发组自查。存在的安全隐患：比如网络访问是否使用HTTPS，是否有远程调用。