常见的软件缺陷分析方法

‘壹’ 软件缺陷度量方法简述

1.原则上来讲，我们更希望一种规范化开发的体系来规正这个命题，不需要为此伤脑筋。但在里程碑或计划的截止时间点能结束测试对大多数的软件项目仅仅是一种期望，而不是既定的现实。理想的情况下，我们可以严格执行计划，然后在计划要求的deadline或者里程碑点上提交交付件，以确认该里程碑是否达到要求，是否可以进行下一阶段的工作——但正如前提所言，这个仅仅是理想情况
2.现在让我们现实一点。我们为什么会有这样的问题(一个软件如何确定测试结束点)？往往就是因为我们不知道何时可以结束一个软件的测试。不管教科书上如何说明一个软件只要还在生命周期内，就无法结束测试，但现实要求我们在某一个时间点上，结束对软件某一阶段的测试。那么，这个问题实际上就已经转化为确定该阶段测试的结束点的方法了。这个方法可能是一种规范，一套流程，一些交付件，一些评审，一些由统计学原理得出的收敛曲线或者仅仅只是一些确认而已。而个人认为，无论这个方法是何种形式的，其基本的要求就是能达成一种协议，确认该协议生效——那么这个阶段的测试就结束了，至于这个点在什么时间，我想就是完成所有要求的这些确认的时间而已。
在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定：：
1.基于“测试阶段”的原则：
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。
2.基于“测试用例”的原则：
测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。
3.基于“缺陷收敛趋势”的原则：
软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。
4.基于“缺陷修复率”的原则：
软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。
5.基于“验收测试”的原则：
很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。
6.基于“覆盖率”的原则：
对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试” 和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。
7.基于“项目计划”的原则：
大多数情况下，每个项目从开始就要编写开发和测试的Schele，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员(开发，管理，测试，市场，销售人员)达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。
8.基于“缺陷度量”的原则：
这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。
9.基于“质量成本”的原则：
一个软件往往要从“质量/成本 /进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位，就要看是什么软件了。比如说是：人命关天的航天航空软件，那还是质量重要些，就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug的成本还高，也可以终止测试。
10.基于“测试行业经验”的原则：
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用

‘贰’ 软件缺陷的有效管理

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

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

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

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

无效的缺陷记录

信息繁冗

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

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

信息缺失

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

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

无效信息

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

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

缺陷信息收集的正确做法

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

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

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

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

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

缺陷报告时机

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

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

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

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

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

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

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

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

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

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

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

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

‘叁’ 记录软件缺陷有什么技巧

如果使用一个操作系统，可以采用下面的过程步骤：

1. 识别所有可能阻塞的系统调用，如Mutex_Lock()，每个受保护的共享资源总是有一些与访问它有关的阻塞调用。

2. 识别出获取共享资源的阻塞调用之后，在源代码中查找它们的各次调用情况。

3. 对于每次调用，记录下指向资源的线程名称和该资源的名称。通常调用本身将受保护的资源作为一个参数来传递，调用在源代码中所处的位置表明了哪个线程需要该资源。通过这种方式，可以识别出所有受保护的资源以及分配资源的线程。

4. 建立资源分配图，并检查是否有任何资源存在循环路径。当线程和共享资源较少时，画出资源分配图比较简单。在较为复杂的系统中，最好将这些信息输入分析表格，并编写一个宏来检查线程和资源分配结构，以识别潜在的死锁。编写好宏之后，就可以快速地对资源分配变化进行重新评估。编写宏时，可以忽略不会导致死锁的资源之间的循环。在表2所示的例子中，各种资源之间有许多循环，但只有线程6和线程7之间可能存在死锁。

在一些类型的系统中，预先确定每一个共享资源并建立分配图是不实际或不可能的。此时可以增加一些额外的代码，以便在系统运行时检测出潜在的死锁。许多不同的算法都致力于优化这个检测过程，但本质上它们几乎都动态地建立某种资源分配图。只要有线程请求、分配或释放资源，分配图就会被修改和检测，以确定是否存在表明潜在死锁的循环路径。

检测到某个死锁之后，唯一的克服方法是强迫线程释放关键的资源。通常，这意味着中断正保持着所需资源的线程。对于某些应用，这种方法可能是无法接受的。另一个有趣的解决方案是在运行时收集资源分配情况并进行事后分析处理，以确定在程序运行过程中是否有死锁情况发生。尽管这种方法并不能防止在运行时发生死锁，但它确实有助于在死锁出现后发现问题并进行修复。

还有一些工具也可以用来帮助发现代码中的死锁。例如，Solaris程序设计员可以采用Sun公司的LockLint工具来对代码进行统计分析。它可以发现对锁定技术的不一致用法，识别引起竞争条件和死锁的许多原因。

‘肆’ 软件缺陷分析方法有哪些

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

‘伍’ E-C缺陷分析方法适用的场景

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

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

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

‘柒’ 软件常见故障的现象,故障排除的方法

一、直接观察法

该方法就是通过看、听、摸、闻等方式检查比较典型或比较明显的故障。如观察机器是否有火花、异常声音、插头松动、电缆损坏、断线或碰线、插件板上元件发烫烧焦、元件损坏或管脚断裂、接触不良、虚焊等现象。对于一些时隐时现的瞬时性故障，除直接观察外，也可以用橡皮榔头轻敲有关元件，看故障现象有何变化，以确定故障位置。

二、高级诊断软件检查法

用高级诊断软件对电脑进行测试，即使用电脑公司专门为检查、诊断电脑而编制的软件来帮助查找故障原因，现在比较流行的有SiSoftsandra99、BurnInTest、Norton等。诊断软件在对电脑检测时要尽量满足两个条件：

第一，能较严格地检查正在运行的机器的工作情况，考虑各种可能的变化，造成“最坏”环境条件。这样，不但能够检查整个电脑系统内部各个部件的状况，而且也能检查整个系统的可靠性、稳定性和系统工作能力。

第二，如果发现问题所在，要尽量了解故障所在范围，并且范围越小越好，这样才便于寻找故障原因和排除故障。高级诊断软件检查法实际上是系统原理和逻辑的集合，这种软件为电脑用户带来了极大的方便。

三、交换法

“交换法”是把相同的插件或器件互相交换，观察故障变化的情况，帮助判断、寻找故障原因的一种方法。在电脑的内部有不少功能相同的部分，它们是由一些完全相同的插件或器件组成。例如内存条由相同的插件组成，在外部设备接口中，串行口也是相同的，其他逻辑组件相同的就更多了。如果在电脑内部没有相同的，那么也可以找一台工作正常的电脑，将怀疑有问题的部件交换。如故障发生在这些部分，用“交换法”就能十分准确、迅速地查找到。

四、插拔法

“插拔法”是通过将插件或芯片“插入”或“拔出”来寻找故障原因的方法。此法虽然简单，但却是一种非常有效的常用方法。如电脑在某时刻出现了“死机”现象，很难确定故障原因。从理论上分析故障的原因是很困难的，有时甚至是不可能的。采用“插拔法”就有可能迅速查找到故障原因。依次拔出插件，每拔一块，测试一次电脑当前状态。一旦拔出某块插件后，机器工作正常，那么故障原因就在这块插件上。

‘捌’ 软件的缺陷等级应如何划分

软件的缺陷等级划分方法如下：