软件测试【01】-软件缺陷

转载请注明出处：http://blog.csdn.net/YoungDou/article/details/66616964

什么是软件缺陷：

IEEE 729‐1983：

• 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在 的错误、毛病等各种问题；
• 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违 背。

Ron Patton (Software Testing, 2005)：

至少满足以下5个规则之一，才称为发生了一个软件缺陷

1. 软件未实现产品说明书要求的功能
2. 软件出现了产品说明书指明不应该出现的错误
3. 软件实现了产品说明书未提到的功能
4. 软件未实现产品说明书虽未明确提及但应该实现的目标
5. 软件难以理解，不易使用，运行缓慢或者—从测试员的角度看—最终用户会认为不好

软件缺陷的主要类型/现象

• 约定的功能、特性没有实现或者只是部分实现
• 设计不合理
• 实际结果和预期结果不一致
• 运行出错，包括运行中断、系统崩溃、界面混乱
• 数据结果不正确、精度不够
• 用户不能接受的其他问题，如存取时间过长（一半不应该超过10s的等待时间）、界面不美观

软件深入到了工业控制领域，特别是军工企业的控制领域，软件测试的地位愈加重要

软件缺陷的分级体系

• Fatal：致命的错误。造成系统或应用程序崩溃、死机、系统挂起，或 造成数据丢失、主要功能完全丧失等。
• Critical：严重错误。某些功能或特性没有实现，主要功能部分丧失，次 要功能完全丧失，或致命的错误声明
• Major：不太严重的错误。虽然不影响系统的级别使用，但没有很好地 实现功能，没有达到预期效果。如次要功能丧失，提示信息不 太准确，或用户界面差，操作时间长等。
  
  

  该分级的可操性不强

软件缺陷状态

缺陷状态	描述
激活或打开 Active or open	缺陷还没有解决，在等待处理中，如新报告的缺陷
已修正或修复 Fixed or Resolved	缺陷已被开发人员检查、修复过，通过单元测试，但还没有被测试人员验证
关闭或激活 Closed or Inactive	缺陷经测试人员验证后，确认已经修复 、或不存在之后的状态
重新打开 reopen	缺陷经测试人员验证后还依然存在，等待开发人员进一步修复
推迟 deferred	这个缺陷可以在下一个版本中解决
保留 on hold	由于技术原因或第三方软件的缺陷，开 发人员不能修复的缺陷
不能重现 can not duplicate	开发者不能复现这个缺陷，需要测试人员检查缺陷复现的步骤
需要更多信息 Need more inforn	开发能复现这个缺陷，但开发者需要一些信息，如：缺陷的日志文件，图片等
重复 Duplicate	这个缺陷已经被其他的软件测试人员发现
不是缺陷 Notabug	这个问题不是软件缺陷
需要修改软件规格说明书 Specmodified	由于软件规格说明书对软件设计的要求，软件开发人员无法修复这个缺陷，必须修改软件规格说明书

– 需要修改规格说明书：很容易出现在敏捷开发当中 – 保留问题对一些小企业来说是很大的打击，架构工程师对此负主要责任

软件缺陷生命周期

软件缺陷的产生原因：

• 团队协作问题
• 技术问题
• 软件本身问题

软件缺陷的术语

• Error 错误
• Defect 缺点/缺陷
• Fault 故障
• Failure 失效
• Anomy 异常
• Variance 偏差
• Incident (小)毛病
• Inconsistency 矛盾/不一致
• Problem 问题

实际上，不要认为以上的术语是近义词，他们代表着不同的软件缺陷程度

软件失效周期

Software Error ‐> Software Fault ‐> Software Failure

对比一下Faults，Error和Failure

我们不妨使用病人来类比一个有缺陷的软件
– Error 出错
软件内在状态的不正确，类似于病人的病因：例如高血压，心律不齐，感染病毒
– Fault 故障
譬如硬件设计错误（design mistakes in hardware）类似于病人的“病”，例如心脏病
– Failure 失效：故障的现象
软件的行为和原本设计的不一致，类似于病人的一系列症状
– Bug 这个词在软件测试当中不是一个常用的词，它的描述不准确，它甚至包括了Error，Fault，Failure或者其他的软件不正确状态。

很让人惊讶的是软件缺陷很大程度上是由客户需求造成的，前期的需求没做好，或者是在后期的需求变更都会导致很大的软件缺陷问题。那么规格说明书缺陷造成的主要原因是什么呢/p>

客观原因

1. 需求分析阶段的沟通障碍

• 产品功能：软件开发人员和非计算机专业用户对要开发的产品 的功能理解不一致
• 产品特性：由于软件产品还没有设计、开发，对于产品的表现 只能凭经验去估计和想象，有些特性还不够清晰

2. 用户的需求变化

• 用户的需求总是在不断变化的，这些变化如果没有在产品规格 说明书中得到正确的终描述，会引起说明书上下文矛盾

主观原因

• 对规格说明书重视不够，在设计和写作上投入不足
• 经常只有设计师或项目经理得到比较全面的规格信息

软件缺陷在不同阶段的分布

有的企业因为项目软件有过多的缺陷，为了节省修复精力，会选择放弃重来的策略，例如win8.0和win8.1（其实是两个不同的团队做的内核），因为早期win8.0的过多缺陷，微软放弃win8.0而选择了另外一个团队做的win8.1内核。ps:据说迅雷两年以内出了十多个版本的下载器是为什么呢)

来源：YoungDou