您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 缺陷管理 > 正文

简单易懂的缺陷分析笔记

发表于:2018-10-15 作者:某种意义 来源:简书
缺陷分析的基础是数据质量,该如何保证数据质量?

高质量的数据,是缺陷分析的基础,可以从两个方面大的方面来保证数据质量:一、利用管理系统保证(建立系统间的关联 ,统一的源数据管理)二、减少犹豫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,是否有远程调用。