odc缺陷分析方法有哪些

㈠ 软件缺陷的有效管理

本文首发于【 林子的空间 】

“这次发布之前怎么这么多的缺陷，是不是需要分析一下啊？” 

答案是肯定的，可是这个时候才想起要分析已经有点晚了，有可能这些缺陷很难分析了。这是发生过的一个真实场景，所记录的缺陷包含信息很有限，很难有效的做好分析！本文就来聊聊如何有效的管理和分析缺陷。

缺陷是一项非常有价值的资产，软件缺陷的管理分为两个部分：缺陷信息收集和缺陷分析。

无效的缺陷记录

信息繁冗

有的项目团队要求详细记录缺陷的多个维度信息，而且大部分都是必填字段，比如详细的重现步骤，对于有些特别简单的缺陷来讲是没必要的，关键是信息能够说明缺陷即可，过分详细的要求会带来更大的浪费。

曾经有个项目是在QC(Quality Center)里记录缺陷，需要填写很多必填属性字段，没有办法灵活根据具体缺陷调整，加上QC服务器在国外，访问速度非常的慢，每次记录缺陷成为了大家极其痛苦的一件事情。

信息缺失

也有的项目对缺陷的格式和属性没有严格要求，记录的时候很简单也很自由，这样记录的缺陷由于很多必要信息的缺失，对后续的跟踪和分析也是极为不利。

比如前面提到的在QC里记录缺陷的那个项目，由于太痛了，很多时候，QA发现了缺陷也不愿意往QC里填，而是直接写个纸条简单记录下，验证完了它的生命周期就结束了，这样后面就没办法去很好的跟踪和分析了。（题外话：当时采用脚本往QC里记录缺陷，稍微减轻了点痛苦。）

无效信息

还有一种情况就是记录缺陷时同样有一些属性要求填写，但是这些属性值可能不是那么有意义，导致存储的信息不仅没用，反而添加混乱，也是不利于跟踪和分析的。

比如，其中的“根因（root cause）”属性的值如下表所示，这些值根本就不是根因，这是一个没有意义的捣乱属性。

缺陷信息收集的正确做法

缺陷信息收集应该做到尽量简单，且包含必要的信息。

- 标题：言简意赅，总结性的语句描述是什么缺陷

- 详情：包括重现步骤、实际行为、期望结果等，根据具体情况确定其详细程度，必要时可以添加截图、日志信息等附加说明。

- 重要属性：优先级、严重性、所属功能模块/产品、平台（OS、Web浏览器、移动设备的不同型号等）、环境、根因等，这些属性对应的值需要根据不同项目的情况自己定义，其中“根因”是相当关键的一个属性，后面有示例可以参考该属性对应的值有哪些。

- 其他：每个项目对应的还会有其他信息需要记录的，自行定义就好。

缺陷报告时机

在敏捷开发环境中，测试人员可能随时在测试、随时都会发现缺陷，包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢？通常情况下，有以下几种情况：

- 开发还没完成的用户故事（story），测试人员发现缺陷只需要告诉开发修了，在该故事验收的时候一起检查就好了，无需单独记录；

- 在开发已经完成，交到测试人员手里正式测试的故事，再发现缺陷就需要记录来跟踪了；

- 后续的所有阶段发现的缺陷都需要记录。

比较推荐的一种缺陷分析方法是鱼骨图分析法，可以将跟缺陷相关的各个因素填写到鱼骨图里，对缺陷进行分析，如下图2示：

缺陷相关的各属性拿到了，就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量，分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图：

分析完得到统计的结果就要采取对应的措施，从而防范更多的缺陷产生。比如：

- 修缺陷（上面示例中的“bug fixing”）引入的新缺陷比较多，可以在修复缺陷后添加对应的自动化测试；

- 浏览器兼容性问题相关的缺陷较多的话，可以在开发完成验收的时候在各个主流浏览器上验收等等。

什么时候该进行缺陷的分析也是需要搞清楚的一个问题。通常，推荐每个迭代周期分析一次，并且跟以往各个迭代进行对比，进行趋势对比。当然，有时候可能一个迭代发现的缺陷非常少，分析的周期可以适当延长，两个迭代合并分析一次也是可以的。还可能某个迭代突发紧急缺陷，那就可能需要立马分析。

缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目都把缺陷分析作为常规实践开展起来。

缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目定期都要做做缺陷分析。

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

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

㈢ odc缺陷属性分类是什么

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

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

简介

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

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

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

㈣ E-C缺陷分析方法适用的场景

你好，你要问的是E-C缺陷分析方法适用的场景是什么吗？E-C缺陷分析方法适用的场景是：
1、改进类型纠正修改；
2、排查清零；
3、负向需求；
4、设计准则；
5、场景库；
6、测试经验。以上场景用E-C缺陷分析方法可以有效的发现软件的缺陷，及时清楚缺陷。E-C全称Effect-CauseDiagram，是一种故障分析的常用方法。

㈤ e-c缺陷分析方法通常采用什么方式进行分析

第一步：先两端（首：诱发时间 尾：故障症状）
第二步：再中间（导致的直接缺陷）
第三步：补节点（补充场景的事件及中间流程）
第四步：加强防护措施（包括正向和失效防护措施）
第五步：找隐患，总结负向经验（问题/隐患、改进措施、改进类别、完成时间、责任人）
注：改进类型纠正修改、排查清零、负向需求、设计准则、场景库、测试经验。

㈥ 软件缺陷分析方法有哪些

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