摘 要: 在讨论软件缺陷管理过程和错误管理流程分析的基础上，提出了错误跟踪系统的模型和设计方法。

关键字: 软件缺陷；管理流程；错误跟踪；

1引言

随着社会的发展与进步，计算机的应用已深入到了社会的各个领域，软件的作用和影响也越来越广泛。同时，软件出错的范围和可能性也越来越大。如何有效的进行软件错误的跟踪、控制和管理，已成为提高软件质量，保证系统正常运行的一个重要手段。

错误跟踪系统（Defect Tracking System-DTS）的研发与应用，是为控制和减轻潜在的不利因素对软件项目的影响而采取的一项活动。它用于集中管理和控制软件测试过程中发现的错误，并进行版本控制。通过DTS系统，将帮助我们更好的收集、跟踪、反馈软件系统在测试、运行过程中的错误和问题。DTS作为项目管理的一个重要方法和手段，能有效的帮助人们建立科学的、规范化的项目管理机制。

2 软件错误跟踪与缺陷管理

软件中的缺陷（Defect或Bug）将导致软件系统在某种程度上不能满足用户的需要，甚至造成系统的崩溃。及时发现、妥善处理软件中的缺陷，是软件生存、发展的根本。一个完备软件缺陷管理过程通常包括如下几个方面：

（1）发现与提交缺陷；（2）分析和定位缺陷；（3）提请修改相应的软件
（4）修改相应的软件；（5）验证修改

2．1 错误管理流程分析

流程管理作为现代企业管理的先进思想和有效工具，随着市场环境与组织模式的变化，在以计算机网络为基础的现代社会信息化背景下越发显示出其威力和效用。流程管理不仅是一种管理技术，更体现了现代管理的思想。流程管理的重点是：理清和管理好所有主、支流程间的关系，使他们相互协调发挥应有的作用。流程管理增加了部门的透明度，管理的对象不是“部门”和“部门员工”的概念，而是以工序流程为管理对象，注重流程中每一个过程和效率以及和上下游工序的关系，管理重点在于整体流程的完整性和顺畅性。运用流程管理方法和技术进行软件错误跟踪与缺陷管理，可以有效地改变软件错误跟踪与缺陷过程管理混乱的局面。软件错误跟踪与缺陷管理流程如图1所示：

图1 错误管理状态流程图

在图1中，圆括号方框代表Bug的状态，方框代表操作，圆角方框代表操作附加的信息。A1表示测试人员，A2表示高级测试人员，A3表示开发人员，A4表示评审委员会。其基本过程为：

（1）根据测试人员（错误报告提交人）提交新的错误信息（Bug），系统将错误状态置为New；

（2）高级测试人员进行错误验证，如果确认是错误，分配给相应的开发人员进行处理，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态；

（3）开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态；

（4）对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可；

（5）测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

为了保证错误确认的正确性，需要有丰富测试经验的测试人员验证提交的测试结果是否真实，测试步骤是否准确，并可以重复。对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

项目经理，测试经理和设计经理共同决定对错误信息的处理拒绝或延期。错误修复后必须由错误报告提交人验证，并确认已经修复后才能关闭错误。

2.2 错误缺陷的几种状态

一般把缺陷的生存周期的各个阶段用“状态”来描述，状态的转换，反映了对错误处理过程的结果，对状态的控制是错误跟踪系统的主要功能。软件缺陷的几种常见状态如下：

(1) 新信息（New）：测试中新报告的软件缺陷。

(2) 打开（Open）：被确认并分配给相关开发人员处理。

(3) 修正（Fixed）：开发人员已完成修正，等待测试人员验证。

(4) 拒绝（Declined）：拒绝修改缺陷。

(5) 延期（Deferred）：不在当前版本修复的错误，下一版修复。

(6) 关闭（Closed）：错误已被修复或过期。

3 模型分析

3.1 基于角色的管理

由于传统访问控制方法DAC（自主式访问控制）和MAC（强制式访问控制）难以满足复杂的企业系统的环境需求，美国国家标准化和技术委员会（NISTNational Institute of Standards and Technology，）于90年代初提出了基于角色的访问控制方法（Role-Based Access Control，RBAC），它是一种强制访问控制形式，但它不是基于多级安全需求。在RBAC中，权限和角色相关，用户（User）被当作相应角色（Role）的成员而获得角色的权限（Permission）。角色针对组织中的各种功能创建，用户依据他们的责任和资历被指派角色。用户被指派的角色可以容易地从一个跳到另一个。用户对信息的访问在指派角色的基础上被管制。

由于RBAC实现了用户与访问权限的逻辑分离，因此它极大的方便了权限管理。在DTS中采用这种技术，将整个访问控制过程分成两步：访问权限与角色相关联，角色再与用户关联，有效的进行错误发现测试、记录、确认、修改、跟踪、控制和管理，从而实现了用户与访问权限的逻辑分离。

3.2 系统结构

错误跟踪系统的使用方式和架构可以有两种，即C/S（客户端/服务器）方式和B/S（浏览器/服务器）方式。

3.2.1 C/S模式

对于在本地开发的项目组，无疑C/S模式是最合适的方式了，但如果整个项目是由分布在全国范围内的各个实施点的话，问题就出现了。如何处理如此分散的错误提交点呢？

我们可以让在公司本部的人用C/S模式通过局域网使用错误跟踪系统，而出差在外的人可以用E-Mail的方式提交和查询报告。在由专门的管理人员将结果导入系统中。

2.2.2 B/S模式

显然，采用C/S方式在异地使用方式中比较繁琐，数据需要来回的导入导出，大大地降低了使用效率。

鉴于项目中各个实施点大部分时候都能够与网络连接，用户只要能够连接到互联网就可以通过浏览器提交和查询错误报告。采用B/S有利于系统的控制与管理，但由于查询的速度受到网络状况的制约，系统的网络安全性能也必须重点考虑，所以系统实现起来比较复杂。

2.2.3混合模式

对于分布范围广的项目，我们可以采用B/S的模式，而本地的开发项目可以采用C/S模式。或者直接将两者结合，在公司本部的人直接用C/S模式通过局域网使用，而出差在外的人只要连接到互联网就可以通过浏览器提交和查询报告，同时对于网络瘫痪的情况，可以使用C/S的导入导出功能来传递错误跟踪信息。

然而若采用混合模式，传统的二层C/S结构存在以下几个局限：1）单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet；2）软、硬件的组合及集成能力有限；3）难以管理大量的客户机。对此我们可以采用三层C/S结构。

三层C/S结构是将应用功能分成表示层、功能层和数据层三部分。其解决方案是：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为DBMS已经独立出来，所以关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。

这样C/S和B/S就可以使用共有的数据库来共享数据，并且保持了各自的优势，但相对开发周期会延长。

3.3缺陷管理数据库

软件缺陷管理数据库是管理软件测试缺陷的专用数据库系统，通过它可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。

据调查，很多从事多年软件测试的公司都有内部的软件缺陷管理数据库，这些内部数据库大部分是公司内部开发的，也有一些是直接从市场上购买的。公司内部开发的功能更符合公司实际要求、具有良好的扩展性。直接购买的数据库节约了开发成本，但是往往购买价格较高，很多功能根本用不上，造成经济上的浪费。

数据安全性方面主要是使用数据库加密技术，防止未授权或非正规的数据库访问。系统检索方式采用二分法查找，并且在数据库中各种信息是分类放置的，这样也会加快检索效率。同时，作为一个数据库系统也要有专人定期对其进行维护，删除冗余或过期的信息，保证检索的效率。

4．模型的设计

为了满足和规范项目组的错误跟踪和技术支持服务流程，提高错误跟踪和技术支持的效率和服务质量，适应庞大规模服务请求的需求，专门成立一个客户服务中心。客服中心作为以后技术支持对外的统一接口，由客服中心对服务请求进行统一的登记、处理、分解、传递和反馈等。

对于实施队伍提出的服务请求，要求在和客服中心电话沟通前须先通过电子邮件以文字的形式将问题描述清晰后发送给客服中心。

服务请求首先提交给客服中心人员，客服中心进行登记、处理和反馈；客服中心不能解决的疑难杂症，先进行问题分解后，传递给技术支持人员。逐渐避免客户或实施人员直接请求技术支持人员。

客服中心人员按区域负责，技术支持人员按技术方向负责，责任到人。

由配置管理人员拟定监督管理机制，监督检查技术支持流程每个环节和人员，落实到位。

4.1 总体构架

后台服务器端存储数据库和专家库数据，以及错误跟踪系统的服务器程序。用户通过互联网络打开客户端web页面并在线提交数据，服务器端接受到数据后进行处理，然后将数据存入数据库或专家库，再把结果反馈回客户端，以web页面的形式呈现。系统的总体构架如图2所示：

图2 总体构架图

4.2 功能设计

错误跟踪系统的基本功能如下：

（1）错误处理记录：填写错误报告传入本系统，并将每次处理的记录都写入系统数据库。

（2）错误报警：当错误在一定周期内还没有被解决掉，系统会在相关人员登入系统后弹出告警信息，提示错误已经到期。

（3）督办：设置报警周期，催办错误报告。

（4）基础数据维护：对问题分类、企业分类、问题等级等基础数据进行维护。

（5）专家库管理：对技术支持中常遇问题的分析、汇总和维护，形成专家知识库，为技术支持人员提供帮助。

（6）数据分析：统计分析实施人员、合作伙伴、客户提出的各种问题，并根据问题的内容和性质做后续的处理，更好地支持项目实施。

4.3 错误状态设定

错误在生存周期内各个阶段的状态设定如下：

(1) 新错误（New）：测试中新报告的软件缺陷。

(2) 打开（Open）：被确认并分配给相关人员，正在处理。

(3) 已修正（Fixed）：开发人员已完成修正，等待测试人员验证。

(4) 拒绝（Declined）：拒绝修改缺陷。例如：缺陷等级太低，修正成本太大等。

(5) 延期（Deferred）：不在当前版本修复的错误，下一版修复。

(6) 关闭（Closed）：错误已被修复或过期。例如：软件版本号显示错误，但新的版本刚刚发布，此问题已经过期，被关闭。

(7) 重新打开（ReOpen）：已经修正的错误再次发生。例如：修正新的错误造成已经解决的错误再次发生等。

(8) 挂起（Hang）：暂时不处理。例如：处理人员正忙于处理更紧迫的任务时，而这个错误级别较低，这时错误被挂起，处于一种等待状态。

4.4 错误等级设定

错误的等级在后台进行维护，初始设定按错误程度设为5级：

(1) 重大错误：错误会引起操作系统崩溃。

(2) 严重错误：错误会引起应用系统崩溃，但不危及操作系统。

(3) 功能错误：错误会引起应用的某个功能不正常。

(4) 告警：不影响应用系统功能的一般错误。

(5) 建议：对程序提出的功能改进意见。

4.5 角色权限设计

4.5.1权限点

对于角色权限管理部分，在系统中设立若干权限点，建立角色，根据角色的职位特点，分配其适当的权限点。然后建立用户，根据需要用户职位特征，分配相应角色。

权限点是系统中最小的权限单位，不可以再分。角色是权限点的集合，管理员可以根据需要创建不同的角色。用户是最终使用人员登陆系统所使用的身份标识ID，根据人员所处职位的特征，用户可以担当一个或多个角色，并拥有相应角色的权限，如图3所示。

图3 权限分配示意图

系统管理员对用户、角色和权限点进行分配和管理。由于用户与角色衔接，所以当要更改某一组用户的权限的时候，只要更改这一组用户所属角色的权限即可，而不用每个用户都去更改。

4.5.2 系统角色设置

系统初始设计的角色主要有以下几种：

（1）实施人员：现场的实施人员，对本人测试到的错误信息进行错误报告建立、读取、删除、修改的权限。同时也可以读取技术支持人员的问题反馈。

（2）测试人员：权限同实施人员，但其提出的问题直接由错误分配人进行分配。

（3）错误分配人：根据错误性质进行分类的人员，具有读取错误报告和错误处理记录的权限，并且可以分配错误处理人。

（4）技术支持人员：可以查阅错误报告、专家库，并能创建修改错误处理记录。

（5）专家库管理员：具有对专家库进行操作的权限。

（6）系统管理员：维护基础代码，包括角色权限设置和创建用户等。

结束语

错误跟踪系统的建立和应用，涉及到软件开发、实施、维护的各部门，它贯穿软件生命周期的全过程。要想真正做好错误的跟踪、修改、控制与管理，除了要有一套好的系统外，项目管理的规范化和制度化是系统成功的基本保证。

参考文献

1 Brian White，统一变更管理的威力，X-Programmer，2001，5（9）：102～105
SEI，Capability Maturity Model for Software，Version l.1，1992

2 Frederick P. Brooks, Jr.，The Mythical Man-Month，1995

3王如龙．企业实施信息化工程成功因素探讨．[J]．企业信息化集成，2003，(4):9-10

4 Michael E. Shin，Gail-Joon Ahn，基于角色访问控制的UML表示，X-Programmer，2003，25（5）：20～27

5罗铁清,王如龙.软件项目管理的研究及在项目开发中的应用[J]．项目管理技术,2005,(3): 66-70