软件失效分类与管理
软件失效分类与管理
软件失效分类
软件测试使用各种属于描述软件出现的问题，通用的术语如下：
-
软件错误（software error）：是指在软件生存期内的不希望或不可接受的认为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。
-
软件缺陷（software defect）：是指存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。
-
软件故障（software fault）：是指软件运行过程中出现的一种不希望或不可接受的内部状态。比如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无适当措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。
-
软件失效（software failure）：是指软件运行是产生的一种不希望或不可接受的外部行为结果。
总的来说，如那件失效机理可描述为：软件错误→软件缺陷→软件故障→软件失效
综上所述，软件错误是一种认为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有及时的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。
2001年，在《软件测试》一书中对软件缺陷进行了定义：
①软件未达到产品说明书中标明的功能；
②软件出现了产品说明书中指明的不会出现的错误；
③软件功能超出了产品说明书指明的范围；
④软件未达到产品说明书虽为指出但应达到的目标；
⑤软件测试人员认为软件难以理解、不易使用、运行速度慢，或最终用户认为不好使用。
实践表明，大多数软件缺陷产生的原因并非源自编程错误，主要来自于产品说明书的编写和产品方案设计。产品说明书成为软件缺陷的罪魁祸首，是因为产品说明书编写得不全面、不完整和不准确，而且经常更改，或者整个开发组没有很好地沟通和理解，或开发人员会需求说明书的理解与沟通不足。
关于概念不可能彼此分得很清楚，实际上也没有太大的必要。目前软件测试界一般主要使用缺陷（defect）和错误（error）这两个词。在测试过程中，我们找到的错误会有不同的类型，对错误的分析与管理是十分重要的。
缺陷与错误分布
通过对错误分布情况的仔细分析，可以帮助我们将测试的主要精力更好地集中到最有价值的地方，如图2-20
缺陷与错误严重性和优先级
软件缺陷与错误划分严重性和优先级的通用原则：
①表示软件缺陷所造成的危害的恶劣程度
②优先级表示修复缺陷的重要程度与次序
-
严重级
①严重：系统崩溃、数据丢失、数据毁坏
②较严重：操作性错误、错误结果、遗漏功能
③一般：小问题、错别字、UI布局、罕见故障
④建议：不影响使用的瑕疵或更好的实现
-
优先级
①最高优先级：立即修复，停止进一步测试
②次高优先级：在产品发布之前必须修复
③中等优先级：如果时间允许应该修复
④最低等优先级：可能会修复，但是也能发布
在不同的开发过程或软件的不同部分，严重性和优先级将有所变化，要具体情况具体分析。
软件错误跟踪管理
软件测试的主要目的在于发现软件存在的错误（Bug），如何处理测试中发现的错误，将直接影响到测试的效果。在实际的软件测试过程中，每个BUG都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。
（1）错误跟踪管理
为了正确地跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条记录输入指定的错误跟踪管理系统。
【1】BUG记录信息：
-
测试软件名称
-
测试版本号
-
测试人名称
-
测试事件
-
测试软件和硬件配置环境
-
发现软件错误的类型
-
错误的严重等级
-
详细步骤
-
必要的附图
-
测试注释
【2】BUG处理信息：
-
处理者姓名
-
处理时间
-
处理步骤
-
错误记录的当前状态
（2）软件错误的状态
软件错误的主要状态包括以下内容：
-
新信息（New）：测试中新报告的软件BUG
-
打开（Open）：被确认并分配给相关开发人员处理
-
修正（Fixed）：开发人员已完成修正，等待测试人员验证
-
拒绝（Declined）：拒绝修改BUG
-
延期（Deferred）：不在当前版本修复的错误，下一版修复
-
关闭（Closed）：BUG已被修复
（3）错误管理流程
错误管理的流程可以概括以下几项内容：
-
测试人员提交新的错误入库，错误状态为“New”
-
高级测试人员验证错误
①如果确认是错误，分配给相应的开发人员，设置状态为“Open”
②如果不是错误，则拒绝，设置为“Declined”状态
-
开发人员查询状态为“Open”的错误，做如下处理：
①如果不是错误，则置状态为“Declined”
②如果是错误，则修复并置状态为“Fixed”
③如果不能解决的错误，要留下文字说明并保持错误为“Open”状态
④对于不能解决和延期解决的错误，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可
-
测试人员查询状态为“Fixed”的错误，验证错误是否以解决，做如下处理：
①如问题解决了，置错误的状态为“Closed”
②如问题没有解决，则置状态为“Reopen”
（4）错误流程管理原则
错误流程管理遵循以下原则：
①为了保证错误处理的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
②每次对错误的处理都要保留处理信息，包括处理姓名、时间、处理方法、处理意见、BUG状态
③拒绝或延期处理错误不能由程序员单方面决定，应该由项目经理、测试经理和设计经理共同决定
④错误修复后必须由报告错误的测试人员验证，确认已经修复后，才能关闭错误
-
加强测试人员与程序员之间的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。
