缺陷分析方法分类

A. 缺陷分析方法主要有哪些各有什么特点

inner part of zipper ledge

B. 常用软件缺陷预防技术和缺陷分析技术有哪些

一般常用的缺陷预防有几个阶段，需求阶段，设计阶段，编码阶段。 第一，在需求阶段，最重要的事情是需求验证。一般验证的几个大项是，功能是否完整，是否考虑性能，有没有模糊需求，有没有考虑安全性，有没有冗余和错误的需求，需求是不是过于苛刻，需求是不是矛盾等方面。一般常用的方法是列出需求检查表，并进一步执行需求/测试 矩阵。 第二，设计阶段，这个阶段主要通过技术评审测试逻辑设计。常用比较规范的作法是建立过程/数据矩阵，也就是CRUD矩阵，把过程影射到实体，把整个程序的数据的生命周期（建立，更新，读取，删除）反映出来。 第三，编码阶段，这个阶段预防措施主要有统一编码规范，代码评审， 单元测试 。统一代码规范一般是开发经理统一要求，代码评审则是互相评审或者开发leader进行评审，最后最重要的则是单元测试，就是一般说的白盒测试。 再来说缺陷分析吧，很多很高深的分析技术也不很实用，我只介绍一点常用的分析方法。 1.模块的缺陷分布，一般用柱状图或饼状图，就是每一个功能模块发现bug的比例，发现bug最多的模块证明在发布以后需要更多的维护。 另外，历史数据可以参照，譬如上一个版本在哪个模块发现的bug比例对这个版本就是一个参考。如果，某个模块发现bug的比例比上个版本大幅下降，则很可能说明该模块还需要更多测试。 2.缺陷的起因分布，一般用柱状图或饼状图，一般可分为架构缺陷、功能缺陷、易用性缺陷、性能缺陷、安全性缺陷、界面文字缺陷。一般如果架构缺陷占的比例较大，则说明设计有很大问题。 3.按照不同发现人员的缺陷分布，一般用柱状图或饼状图，一般分为测试人员发现，开发人员发现，beta测试发现，外部客户发现。如果测试人员发现的bug低于某个比例，证明质量保证测试不足。 4.按照不同方式的缺陷分布 ，一般有需求审查，设计测试，代码走查，JAD，手工测试， 自动化测试 ，白盒测试。一般来说，如果通过需求审查，设计测试，代码走查，JAD发现的bug比重很低则说明测试前期重视不够，另外，在手工测试和自动化测试之间的比例也能说明自动化测试的贡献度。 5.缺陷差额分析，就是已经发现的和已经解决的曲线关系，以时间为横轴，两者越接近说明产品质量越高 6.按照时间段的缺陷分布，一般用时间为横轴的曲线图表示，主要说明在哪个阶段发现的bug最多，对测试总结有指导意义 7.Rayleigh分析，就是俗称的零缺陷追踪法，一般截至某个时间点发现的缺陷总数和时间有一个函数关系（一个复杂的数学函数），一般用这个函数来推测经过多少天测试之后软件中大概还有多少个bug，以及交付到用户手中之后大概还能出现多少个bug。不过由于本人严重怀疑该方法的实用性，我还没用过。 一不小心，罗罗嗦嗦这么多，希望对大家有帮助，哪怕是一点点，也希望大家多探讨探讨。

C. 软件缺陷可以划分为哪几个等级

一旦发现软件缺陷，就要设法找到引起这个缺陷的原因，分析对产品质量的影响，然后确定软件缺陷的严重性和处理这个缺陷的优先级。各种缺陷所造成的后果是不一样的，有的仅仅是不方便，有的可能是灾难性的。一般问题越严重，其处理优先级就越高，可以概括为以下四种级别：
（1）微小的（Minor）。一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。
（2）一般的（Major）。不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。
（3）严重的（Critical）。严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
（4）致命的（Fatal）。致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。
除了严重性之外，还存在反映软件缺陷处于一种什么样的状态，以便于及时跟踪和管理，下面是不同的缺陷状态。
·激活状态（Open）：问题没有解决，测试人员新报告的缺陷或者验证后缺陷仍旧存在。
·已修正状态（Fixed）：开发人员针对缺陷，修正软件后已解决问题或通过单元测试。
·关闭状态（Close）：测试人员经过验证后，确认缺陷不存在之后的状态。
以上是三种基本的状态，还有一些是需要相应的状态描述，如“保留”，“不一致”状态等。

D. odc缺陷属性分类是什么

odc缺陷属性分类是ODC工作流程中的第一步，即需要测试和开发人员分别对每一个缺陷填写ODC属性。对于团队成员来说，正确的了解每个属性的值尤为重要，这样才能保证他们在分类时尽量选择正确的选项。

原则：它通过给每个缺陷添加一些额外的属性，利用对这些属性的归纳和分析，来反映出产品的设计、代码质量、测试水平等各方面的问题。从而得到一些解决办法来进行改进。

简介

正交缺陷分类法，Orthogonal Defect Classification（简称ODC）是一种缺陷分析方法，由IBM在1992年提出。它通过给每个缺陷添加一些额外的属性，利用对这些属性的归纳和分析，来反映出产品的设计、代码质量、测试水平等各方面的问题。

从而得到一些解决办法来进行改进。例如对于测试团队，通过ODC可以知道测试工作是否变得更加复杂；每一个测试阶段，是否利用了足够多的触发条件来发现缺陷；退出当前测试阶段有什么风险；哪个测试阶段做得好，哪个测试阶段需要改进等。

对于开发团队，利用ODC可以知道产品设计和代码编写的质量情况。而给产品用户带来的好处就是提高客户满意度，减小产品投入市场后的维护花费。

E. 如何划分缺陷【类型】【等级】【原因】

我先抛块砖，希望大家砸回些玉来：）首先要说的就是缺陷等级、类型、原因的划分会因公司或项目管理需求的不同、业务类型的不同而不同，公司EPG在参考其它公司分类情况的基础上，关键任务是要根据自身的需求和业务情况总结出适合自己的分类情况。接下来聊聊缺陷等级，个人认为缺陷等级的划分要看公司或项目组关心哪个纬度的数据，比如关心缺陷的严重程度，那等级可能可以分为致命、严重、中等、一般等几个级别；如果比较关心缺陷影响范围，那等级可能可以分为很大、大、中、小等级别；如果比较关心缺陷的处理的紧急程度，那等级可能可以分为紧急、高、中、低等级别……。当然，纬度还有很多种，关键是看你关心什么数据，而且这些纬度也可以结合在一起，以加强对问题的管理。等级的划分虽说很多是定性的，但最好也能够有个比较清晰的定义，以方便推广和选择，减少歧议。再有就是上面提到的“为了建立各项目工作产品质量的比较，是不是得有一个统一的缺陷基准？如1致命缺陷=2严重缺陷=4一般缺陷=？？？”这样做的目的是为了做项目绩效考核吗？一般很少有公司会这样做吧，个人认为等级划分是为了更好地对问题进行管理和分析，而不适合用定量的方法去转换各不同级别缺陷的数量。

F. 缺陷分析漏斗模型

做缺陷分析需要投入不少的人力和时间，所以在缺陷分析之前首先我们必须明确我们为什么要做缺陷分析，缺陷分析能给我们带来什么。是效率的提升还是开发质量的提高。

接下来我们要确定缺陷分析的粒度，如果粒度太大，无法分析出具体有用的结果，如果粒度太小，投入的人力时间太多，与最终得到的成效相比，代价过大。

缺陷分析主要不是解决缺陷，而是防止缺陷的再次发生。正如我们应该提高自身身体素质，防止生病，而不仅仅是治病。

进行缺陷分析首先我们要从缺陷的来源下手，来源主要分成两类：

1.产品发布以后的缺陷

数据：产品发布以后的缺陷主要来源于用户报的问题，当然也有一部分是自己内部员工发布的问题，可以是产品经理，测试，开发或者其他的员工。

目的：分析这部分缺陷能让我们知道我们测试工作中的不足，找到相关的原因，提高测试工作的质量。同时，可以发现用户遇到的问题，在之后的开发工作中避免这种问题再次出现，提升用户体验。

指标：计算出平均修复时间指标，知道我们维护阶段处理缺陷的效率。提高效率，提升用户的满意度。

2.产品发布之前的缺陷

数据：产品发布之前的缺陷主要来源是测试开的bug。

目的：分析这部分的缺陷，能发现需求上描述不清楚或者不合理的地方，编码容易出错的地方，流程上不合理需要改进的地方，软件薄弱的地方等。我们逐个击破，提高整个开发团队的素质。

指标：同时通过缺陷分析，计算出缺陷指标，评估风险以及开发阶段软件的质量和需要的工期。

下面我们要重点介绍的缺陷分类方法叫漏斗模型缺陷分析法。模型从上到下是一个逐渐缩小的过程，让我们从一开始的缺陷到最后找到导致这个缺陷的部门和生产过程，以便有针对性的进行改进。

模型从右到左是生产的反向过程，在右边的生产活动如果缺陷过多，就会掩盖掉其左边的生产活动，我们必须先解决掉右边活动存在的问题，减少它产生的缺陷，这样才能看到模型左边的生产活动存在的问题。 模型如下图，绿色的是缺陷的分类，蓝色的是生产活动，红色的是对应的责任职位。

我们如何利用这个模型进行分类呢。可以分为以下几步。

1.对缺陷进行分类

把所有的缺陷按照模型的最上面一层进行分类。如果是老的缺陷，那会比较麻烦，需要重新分析老的缺陷，然后给老的缺陷分类。如果打算忽略老的缺陷，直接在之后的缺陷里进行统计，那可以直接在创建缺陷的时候加入一栏“缺陷类别”，而类别就是模型里的第一层，之后的统计中就会方便很多。

2.计算出每个类别的缺陷数目，然后对应到生产活动。

我们的生产活动主要有：

-- 编写需求

-- 理解需求

-- 系统设计

-- 编码

-- 设计测试用例

-- 功能测试

-- 回归测试

-- 性能测试

-- 实施

然后按照缺陷个数的高低进行分析每一个生产行为，分析产生缺陷的原因，是因为人还是因为制度还是因为流程。然后进行相应的改进。

以我目前的一个项目来举例，首先我提取了最近一个月发布前的缺陷。（这里主要的是，缺陷数目越多，能发现的问题更多，也更具有代表性。我这里取一个月的缺陷，只是为了说明，因为数据量太小实际参考效果不佳。）

先根据缺陷类别统计每一个类别的缺陷个数，然后对应到生产活动。我们发现排名第一的是编码，第二的是需求，需求产生的缺陷个数居然有29个，占比32.6%。需求的缺陷占比如此之高是不太常见的。从另一方面来说如果解决了需求这一块存在的问题，在效率的提高和产品质量的提高上会有很大的帮助。一般如果是由于需求导致的缺陷，如果找到原因并且采取有效措施后会比较容易在以后的工作中避免。

那我们来具体分析下为什么会有这么多需求的缺陷。需求缺陷中，其中主要的问题是需求描述不清楚，其次是多语言翻译，最后是用户体验。 

需求为什么会描述不清楚，一是因为产品人员没有真正理解产品，很多情况没有考虑全面。 二是描述语言不够清晰，逻辑不够清楚。三是业务上没弄清楚真正需要的是什么。对于第一点，一方面产品人员要加强对于自身产品的理解，测试人员也可以在这方面给产品人员把关，尽量保证需求考虑足够全面。 对于第二点，产品人员在写需求的时候尽量理清思路再写。对于第三点，这一点比较难，需要产品人员多提升专业知识。 

对于多语言翻译，一开始产品人员就应该明确哪些语句需要支持多语言，并且列在一个表里，保证他们都翻译了。而不是通过测试，发现问题，报告缺陷，然后解决，再去验证。这样对于测试资源是一张浪费，特别是在测试资源紧缺的时候，更是雪上加霜。

对于用户体验方面，希望产品人员多提升在用户体验方面的认知，在设计产品的时候时刻注意，不能是一拍脑门做决定。

总结下来。对于需求产品的缺陷，只要产品人员在平时工作中多加注意，相信这一方面的缺陷会少很多。整个组的效率也会提升很多。

接下来我们来分析下编码导致的缺陷，编码导致的缺陷中占比比较大的是，逻辑错误，遗漏功能，和不同组直接的依赖。这里面我们能努力的方面是遗漏功能和不同组之间的依赖。

遗漏功能一方面是对于需求没有了解清楚，另一方面是没有考虑全面，比如特殊的数据处理，特殊场景的处理等。改进的方向是，在做之前确认自己是否真的理解了需求，还有就是积极参加测试用例评审大会，听一听测试人员的测试用例，看自己有什么遗漏的地方。 另外就是自己整理一份特殊数据，特殊场景的情况，每次做到有关的内容的时候，都提醒下自己是否考虑到了。

不同组之间的遗漏，在于组之间的不透明。对于相互影响的模块，可以考虑创建一个组之间模块依赖表，每一个组设置一个接头人，一旦有依赖的模块发生变化了立刻通知到其他组。对于上下游的模块，每次下游测试前要和上游确认所有的需要的准备工作已经完成。

前面的这些分析都是按照缺陷个数进行的分析。当然有些缺陷个数很少，可是影响却很恶劣，对于这种缺陷我们必须强烈避免，按照漏斗模型找到对应的生产活动对应的负责人，case by case的处理。坚决避免此类情况再次发生。

在我们日常的工作中，大家对于缺陷分析的重视度并不够。一方面是不知道该如何利用缺陷的价值，如何进行分析，另一方面是记录的缺陷不规范，要进行缺陷分析难度太大。我所处的项目组由于业务多，时间上紧，所以大家都很忙很累，大家都意识到流程上业务上存在问题，可是却无法知道具体问题出在哪里，如何改进，更没有数据可以用来说服老板或者其他人进行改变。直到某天我意识到，缺陷就是开发过程的产物，它最能说明我们的开发过程到底存在什么问题，然后我就开始进行缺陷分析，不过一开始没想好从哪个维度入手，也不清楚缺陷该如何分类，分类的粒度应该多大。于是慢慢的尝试，最终整理出来的漏斗模型里面列的那些分类，因为整个图很像漏斗加上分析的过程就像用漏斗一样，一遍遍的过滤信息，最终找到根本问题，所以我把它叫做漏斗模型。希望大家能从我这篇文章中得到帮助。

G. 软件缺陷分析方法有哪些

已经修改的错误重复出现；
无法清晰的描述当前版本的缺陷状态；
对测试中发现的问题,主要依靠记忆得方式来记录;能记录的数量有限,并且经
常遗忘；
采用了记录单或问题表单的方式来记录缺陷,但只是简单的记录了错误内容,没
有分析和流程跟踪能力；
研发经验教训得不到继承,重复同样的错误；
缺陷跟踪管理系统可以规范项目中开发、测试、缺陷处理的流程。

H. 在超声波探伤中把焊缝中的缺陷分几类怎样进行分类

焊缝探伤一般指无损检测，包括射线探伤、超声波探伤、磁力探伤、渗透探伤等。无损检测的常规方法有直接用肉眼检查的宏观检验和用射线照相探伤、超声探伤仪、磁粉探伤仪、渗透探伤、涡流探伤等仪器检测。肉眼宏观检测可以不使用任何仪器和设备，但肉眼不能穿透工件来检查工件内部缺陷，而射线照相等方法则可以通过各种各样的仪器或设备来进行检测，既可以检查肉眼不能检查的工件内部缺陷，也可以大大提高检测的准确性和可靠性。超声波探伤在无损检测焊接质量中的作用1、探测面的修整：应清除焊接工作表面飞溅物、氧化皮、凹坑及锈蚀等，光洁度一般低于▽4。焊缝两侧探伤面的修整宽度一般为大于等于2KT+50mm，（K:探头K值，T：工件厚度）。一般的根据焊件母材选择K值为2.5探头。例如：待测工件母材厚度为10mm,那么就应在焊缝两侧各修磨100mm。 2、耦合剂的选择应考虑到粘度、流动性、附着力、对工件表面无腐蚀、易清洗，而且经济，综合以上因素选择浆糊作为耦合剂。 3、由于母材厚度较薄因此探测方向采用单面双侧进行。 4、由于板厚小于20mm所以采用水平定位法来调节仪器的扫描速度。 5、在探伤操作过程中采用粗探伤和精探伤。为了大概了解缺陷的有无和分布状态、定量、定位就是精探伤。使用锯齿形扫查、左右扫查、前后扫查、转角扫查、环绕扫查等几种扫查方式以便于发现各种不同的缺陷并且判断缺陷性质。 6、对探测结果进行记录，如发现内部缺陷对其进行评定分析。焊接对头内部缺陷分级应符合现行国家标准GB11345-89《钢焊缝手工超声波探伤方法和探伤结果分级》的规定，来评判该焊否合格。如果发现有超标缺陷，向车间下达整改通知书，令其整改后进行复验直至合格。 一般的焊缝中常见的缺陷有：气孔、夹渣、未焊透、未熔合和裂纹等。到目前为止还没有一个成熟的方法对缺陷的性质进行准确的评判，只是根据荧光屏上得到的缺陷波的形状和反射波高度的变化结合缺陷的位置和焊接工艺对缺陷进行综合估判。 对于内部缺陷的性质的估判以及缺陷的产生的原因和防止措施大体总结了以下几点： 1、气孔： 单个气孔回波高度低，波形为单缝，较稳定。从各个方向探测，反射波大体相同，但稍一动探头就消失，密集气孔会出现一簇反射波，波高随气孔大小而不同，当探头作定点转动时，会出现此起彼落的现象。 产生这类缺陷的原因主要是焊材未按规定温度烘干，焊条药皮变质脱落、焊芯锈蚀，焊丝清理不干净，手工焊时电流过大，电弧过长；埋弧焊时电压过高或网络电压波动太大；气体保护焊时保护气体纯度低等。如果焊缝中存在着气孔，既破坏了焊缝金属的致密性，又使得焊缝有效截面积减少，降低了机械性能，特别是存链状气孔时，对弯曲和冲击韧性会有比较明显降低。防止 这类缺陷防止的措施有：不使用药皮开裂、剥落、变质及焊芯锈蚀的焊条，生锈的焊丝必须除锈后才能使用。所用焊接材料应按规定温度烘干，坡口及其两侧清理干净，并要选用合适的焊接电流、电弧电压和焊接速度等。 2、夹渣： 点状夹渣回波信号与点状气孔相似，条状夹渣回波信号多呈锯齿状波幅不高，波形多呈树枝状，主峰边上有小峰，探头平移波幅有变动，从各个方向探测时反射波幅不相同。 这类缺陷产生的原因有：焊接电流过小，速度过快，熔渣来不及浮起，被焊边缘和各层焊缝清理不干净，其本金属和焊接材料化学成分不当，含硫、磷较多等。 防止措施有：正确选用焊接电流，焊接件的坡口角度不要太小，焊前必须把坡口清理干净，多层焊时必须层层清除焊渣；并合理选择运条角度焊接速度等。 3、未焊透： 反射率高，波幅也较高，探头平移时，波形较稳定，在焊缝两侧探伤时均能得到大致相同的反射波幅。这类缺陷不仅降低了焊接接头的机械性能，而且在未焊透处的缺口和端部形成应力集中点，承载后往往会引起裂纹，是一种危险性缺陷。超声波探伤在无损检测焊接质量中的作用其产生原因一般是：坡口纯边间隙太小，焊接电流太小或运条速度过快，坡口角度小，运条角度不对以及电弧偏吹等。 防止措施有：合理选用坡口型式、装配间隙和采用正确的焊接工艺等。 4、未熔合： 探头平移时，波形较稳定，两侧探测时，反射波幅不同，有时只能从一侧探到。 其产生的原因：坡口不干净，焊速太快，电流过小或过大，焊条角度不对，电弧偏吹等。 防止措施：正确选用坡口和电流，坡口清理干净，正确操作防止焊偏等。 5、裂纹： 回波高度较大，波幅宽，会出现多峰，探头平移时反射波连续出现波幅有变动，探头转时，波峰有上下错动现象。裂纹是一种危险性最大的缺陷，它除降低焊接接头的强度外，还因裂纹的末端呈尖销的缺口，焊件承载后，引起应力集中，成为结构断裂的起源。裂纹分为热裂纹、冷裂纹和再热裂纹三种。

I. 如何划分缺陷【类型】【等级】【原因】

1. 缺陷等级、类型、原因的划分会因公司或项目管理需求的不同、业务类型的不同而不同，公司EPG在参考其它公司分类情况的基础上，关键任务是要根据自身的需求和业务情况总结出适合自己的分类情况。

2. 个人认为缺陷等级的划分要看公司或项目组关心哪个纬度的数据，比如关心缺陷的严重程度，那等级可能可以分为致命、严重、中等、一般等几个级别；如果比较关心缺陷影响范围，那等级可能可以分为很大、大、中、小等级别；如果比较关心缺陷的处理的紧急程度，那等级可能可以分为紧急、高、中、低等级别……。当然，纬度还有很多种，关键是看你关心什么数据，而且这些纬度也可以结合在一起，以加强对问题的管理。等级的划分虽说很多是定性的，但最好也能够有个比较清晰的定义，以方便推广和选择，减少歧议。再有就是上面提到的“为了建立各项目工作产品质量的比较，是不是得有一个统一的缺陷基准？如1致命缺陷=2严重缺陷=4一般缺陷=？？？”这样做的目的是为了做项目绩效考核吗？一般很少有公司会这样做吧，个人认为等级划分是为了更好地对问题进行管理和分析，而不适合用定量的方法去转换各不同级别缺陷的数量。

J. 如何划分缺陷【类型】【等级】【原因】

1.
缺陷等级、类型、原因的划分会因公司或项目管理需求的不同、业务类型的不同而不同，公司EPG在参考其它公司分类情况的基础上，关键任务是要根据自身的需求和业务情况总结出适合自己的分类情况。
2.
个人认为缺陷等级的划分要看公司或项目组关心哪个纬度的数据，比如关心缺陷的严重程度，那等级可能可以分为致命、严重、中等、一般等几个级别；如果比较关心缺陷影响范围，那等级可能可以分为很大、大、中、小等级别；如果比较关心缺陷的处理的紧急程度，那等级可能可以分为紧急、高、中、低等级别……。当然，纬度还有很多种，关键是看你关心什么数据，而且这些纬度也可以结合在一起，以加强对问题的管理。等级的划分虽说很多是定性的，但最好也能够有个比较清晰的定义，以方便推广和选择，减少歧议。再有就是上面提到的“为了建立各项目工作产品质量的比较，是不是得有一个统一的缺陷基准？如1致命缺陷=2严重缺陷=4一般缺陷=？？？”这样做的目的是为了做项目绩效考核吗？一般很少有公司会这样做吧，个人认为等级划分是为了更好地对问题进行管理和分析，而不适合用定量的方法去转换各不同级别缺陷的数量。