软件问题的分类与管理

 

软件问题的分类与管理

一、软件问题的定义与分类

1． 软件问题的分类

l       软件错误（software error）

l       软件缺陷（software defect）

l       软件故障（software fault）

l       软件失效（software failure）

定义：

（1）软件错误：指在软件生存周期内的不希望或不可接受的人为错误，其结果将导致软件缺陷的产生。

关注点：属于人为错误

（2）软件缺陷：存在于软件（程序、数据、文档）之中的那些不希望或不可接受的偏差。

关注点：欠缺或不完备的地方

一般情况下，满足以下五种情况中的一种，即可存在软件缺陷。

①   软件未达到产品说明书中标明的功能。

②   软件出现了产品说明书中指明的不会出现的错误。

③   软件功能超出了产品说明书指明的范围。

④   软件未达到产品说明书虽未指出但应达到的目标。

⑤   软件测试人员认为软件难以理解、不易使用、运行速度慢，和最终用户认为不好使用。

（3）软件故障：指在软件运行过程中出现的不希望或不可接受的内部状态，若此时无适当的措施（容错或异常处理机制）加以及时处理，便产生软件失效。

关注点：内部状态

（4）软件失效：指在软件运行时产生的一种不希望或不可接受的外部行为结果。

关注点：外部行为结果

2． 软件失效机理

l     软件错误——>软件缺陷——>软件故障——>软件失效

l     软件错误是一种人为的错误，一个软件错误必定产生一个或多个软件缺陷

l     当一个软件缺陷被激活时，便产生一个软件故障。

l     同一个软件缺陷在不同的条件下被激活，可能产生不同的软件故障。

l     软件故障若没被及时的使用容错加以处理，便不可避免的导致软件失效。

l     同一个软件故障在不同条件下可能产生不同的软件失效。

3． 产生软件错误、缺陷的原因

主要原因是开发的软件与需求说明书、软件设计说明书的不一致，以及在软件的实现中，未能达到用户潜在用户需求的目标。

 

二、软件错误的跟踪与管理

1．缺陷与错误严重与优先级

（1）   严重级别

l       严重：系统崩溃、数据丢失、数据破坏。

l       较严重：操作性错误、错误结果、遗漏功能。

l       一般：小问题、错别字。

l       建议：不影响使用的瑕疵或更好的实现。

（2）   优先级

l         最高优先级：立即修复，停止进一步测试。

l         次高优先级：在产品发布之前必须修复。

l         中等优先级：在产品发布之前应该修复。

l         最低等优先级：可能会修复，但是也能发布。

2．软件错误的跟踪管理

（1）错误（bug）信息的描述

①Bug记录信息

l       测试软件名称

l       测试版本号

l       测试人名称

l       测试事件

l       测试软件和硬件配置环境

l       发现软件错误的类型

l       错误的严重等级

l       详细步骤

l       必要的附图

l       测试注释

②Bug的处理信息

l       处理者姓名

l       处理时间

l       处理步骤

l       错误记录的当前状态

（3）   软件错误状态的描述

①   新信息（New）：测试中新报告的软件错误（Bug）。

②   打开（Open）：错误已经被确认并已经分配给相关开发人员处理。

③   修正（Fixed）：错误已经由开发人员修正完成，等待测试人员验证。

④   拒绝（Declined）：高级测试人员或开发人员认为不是错误，拒绝修改Bug。

⑤   延期（Deferred）：此错误不在当前版本中修复，而要到下一版本中修复。

⑥   关闭（Closed）：错误已经修复，并已经过验证。

（4）   错误管理流程

步骤：

第一步：测试人员提交新的错误信息，并输入到错误跟踪管理系统错误信息数据库中（如TD），错误状态置为初始状态“New”。

第二步：高级测试人员验证错误并做相应处理。

①   如果确认是错误，分配给相应的开发人员，把错误状态置为“Open”。

②   如果高级测试人员认为这个“New”状态的“错误”不是错误，则拒绝修改，把错误状态设置为“Declined”。

第三步：开发人员查询状态为“Open”的所有错误，并对错误做如下处理：

①   如果开发人员认为这个“Open”状态的错误不是错误，则拒绝修改，把错误状态设置为“Declined”。

②   如果是错误，则修复并把错误状态设置为“Fixed”。

③   如果是不能解决的错误，要留下文字说明并保持错误状态为“Open”。

④   如果需要延期解决的错误，要留下文字说明，把错误状态设置为“Deferred”。

注意：对于不能解决的和延期解决的错误，不能由开发人员自己决定，一般需要某种会议（评审会）通过才能认可。

第四步：测试人员查询状态为“Fixed”的所有错误，验证这些错误是否已经解决，并做如下处理：

①   如问题解决了，把错误状态设置为“Closed”。

②   如问题还没解决，重新把错误状态设置为“Open”。

 

错误状态转换图如下所示：

5.错误流程管理原则

①为了保证错误处理的正确性，需要有测试经验丰富的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。

②每次对错误的处理都要保留处理信息，包括处理姓名、时间、处理方法、处理意见、Bug状态等。

③拒绝或延期处理错误不能由程序员单方面决定，应由项目经理、测试经理和设计经理共同决定。

④错误修复后必须由报告错误的测试人员验证，确认已经修复后，才能关闭错误。

⑤加强测试人员与程序员之间的交流，对于“Deferred”状态的错误，需要互相交流意见，避免真正的错误被遗漏。对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。