浅述软件测试缺陷跟踪管理

课程名称：软件测试技术课程编号：SZ0051F08课程类型：学位课、非学位课考核方式：考试、考查学科专业：计算机技术年级：2012级研一姓名：XXX 学号：XXXXXX

河北工程大学2012～2013学年第二学期研究生课程论文报告

浅述软件测试缺陷跟踪管理

XXX

（计算机技术 XXXXXXX）

摘要：本文阐述了软件缺陷的基本概念，缺陷跟踪管理的意义，并对传统的缺陷跟踪技术和目前缺陷跟踪管理工具使用的技术进行比较。在软件测试过程中使用缺陷跟踪管理技术可以使软件开发过程中各阶段所产生的缺陷都能得到有效管理，并能支持各个阶段、不同人员之间的协同工作，使软件测试更加有效，可以尽旱发发现缺陷，减少后期维护工作的工作量，降低软件开发与运行的成本。关键词：软件测试；缺陷；缺陷跟踪管理

Abstract:This paper studies the basic concepts of software bug, the significance of bug tracking management, and compares the traditional bug tracking technology with the bug tracking management tools used at present. Using the bug tracking in the process of software testing can make the bugs be effectively generated in different stages of software development process, and can support all stages, between different people work together, make the software testing more effective, can find bugs as soon as possible, reduce the maintenance workload, reduce the cost of software development and operation.

Keywords: software testing;bug ;bug-tracing management

1 引言

缺陷存在于软件生命周期的各个阶段，并且某个阶段产生的缺陷可能是由于上一阶段的工作失误所造成的，因此，在整个软件开发过程中对缺陷进行跟踪管理是十分必要的，缺陷跟踪管理是提高软件测试工作效率的重要手段。如果能使用设计良好的工具对缺陷进行跟踪管理，不仅可以规范团队的工作流程，使其以缺陷为核心，记录和控制软件的进展情况，把握产品质量，而且可以有效地跟踪项目的状态，简化和加速变更请求的协调过程，从而提高工作效率。

2 软件缺陷的基本概念

软件缺陷是发生在软件中的会导致软件产生质量问题的不被接受的偏差。根据传统的定义，只要符合下面五种情况中的一种，我们就可以称其为软件缺陷。这五种情况是[1]:

⑴软件未达到软件规格说明书中规定的功能;

⑵软件超出了软件规格说明书中指明的范围;

⑶软件未达到软件规格说明书中应达到的目标;

⑷软件运行出现错误;

⑸软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。

缺陷类型可以分成五种，即输入／输出缺陷，逻辑缺陷，计算缺陷，接口缺陷和数据缺陷。

3 缺陷跟踪管理的意义

测试的最终目的是发现软件中存在的缺陷，但是软件缺陷被发现后，最困难的往往不是如何去记录，缺陷的解决和跟踪是测试过程中最难以控制和解决的。对缺陷进行跟踪管理就可以确保每个被发现的缺陷能够被及时的处理，也就保证了测试工作的有效性。

没有进行缺陷跟踪管理，软件开发过程中就很容易出现下列问题[2]：

⑴对测试中发现的问题，随手记录或依靠记忆的方式来记录，能记录的数量有限，并且常常会被遗忘：

⑵测试过程中发现的缺陷需要反馈给开发人员进行修改，没用详细的跟踪记录很难保证缺陷全

部被解决；

⑶缺乏记录缺陷状态的文档，对于开发人员不知道修改后的程序是否通过测试，而对于测试人员也不知道缺陷是否已经被修改，需不需要再进行测试；

⑷没有直观的图表，项目管理人员不能够及时了解测试工作的进展，影响整个项目的进展；

⑸软件提交的测试报告缺乏过程性的文件，用户不确定软件的质量，一旦使用中出现问题，测试人员和开发人员的责任很难划分；

⑹没有相关缺陷记录，团队研发的经验教训得不到继承，在开发的过程中就会重复同样的错误。

当这些问题频繁的出现在开发过程中后，项目管理过程中就引入了缺陷跟踪管理来解决这些问题。

4 传统的缺陷跟踪技术

传统的缺陷跟踪是使用Word、Excel类型的文档工具进行管理。测试人员在需求分析阶段首先将软件的需求规格说明书中的需求分解测试的需求，然后按照测试的需求编写测试用例，用例形式多为表单，如表1所示[3]：

表1 测试用例表

测试用例编写完成后，测试过程中，测试人员只需按照测试用例中的测试步骤进行，然后填写实际的情况完成表单，测试人员可以将完成的表单提交给开发人员，虽然这种方法将缺陷进行了文档化的记录，实施起来也比较简单，但是这种方法管理缺陷的效率不高，在复杂的测试过程里频繁的交互和人员的交叉常会带来如下问题：

⑴测试人员发现缺陷后，由于各种原因没有及时提交Word、Excel文件，导致缺陷被遗忘；

⑵为保证文件的唯一性，一份表单文件不允许多人同时进行修改；

⑶对于多次的测试结果，Word、Excel文档不能详细的记录，缺乏对缺陷修改过程的跟踪；

⑷对于地域分散的开发团队，通过文档交流，相关人员很难及时获得最新变更信息，也容易造成文档中记录的缺陷状态的混乱；

⑸测试人员最终提交给用户的测试报告需要整理大量的Word、Excel文件。

5 缺陷跟踪管理工具

为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统，使用该系统可以加强软件测试过程中人员的沟通和协作，提高管理层监控、管理的透明度，加快软件缺陷的处理进程。

一个完善有效的缺陷跟踪管理工具是软件质量控制的基础，对于测试的成功实施是非常重要的。缺陷跟踪管理工具可以对产品在整个开发周期内产生的缺陷和变更请求进行管理，完成对缺陷报告的记录、分析和状态更新等管理，同时可以规范项目中开发、测试、缺陷处理的流程。简化了地域分散的团队信息共享流程，实现工作流程的自动化，最大限度减少重复劳动．缺陷跟踪管理工具在保证缺陷文件的唯一性的前提下，允许多人同时修改不同的缺陷状态或内容，并且通过对文档查看

都能够及时直观地了解到文档修改的情况。

通过使用缺陷跟踪管理工具，项目组的开发人员、测试人员可以很容易地跟踪到那些应该由他们负责的缺陷，随时掌握缺陷的提交、解决到关闭的整个过程，不必担心遗漏某个缺陷的变化信息。项目管理人员可以通过中心数据库方便及时获取正确、足够的信息，掌握整个测试工作的计划和进度。另外，这一类的工具还可以制作各种缺陷分析图表，从而预测项目风险或解释测试结果，更加准确地度量项目的开发质量。

目前在世界上较有名的商业缺陷跟踪管理软件有Mercury InterActive公司的TestDirector、Mozilla公司的Bugzilla、IBMRational公司的ClearQuest以及微创公司的BMS软件等。这些系统可以与需求管理、自动化测试工具、测试管理工具进行集成，同时也具有定制工作流和输入域以及电子邮件通知等功能，根据项目的流程和企业的特点选用这些软件可以大大提高缺陷报告和跟踪过程的自动化。无论采用哪种工具，应该具备以下几种基本功能[2]：

⑴支持流程自定义

每个公司的开发和测试流程都不尽相同，使用管理软件后可以规范组织的工作流程，使得工作流程更加科学化、正规化，同时流程的改变也会提高项目组的工作效率，但是每个组织的项目不同，人员数量不同，地域不同，生搬硬套所谓的科学规范的流程只会带来负面的结果，缺陷管理软件的流程自定义可以帮助项目开发组织解决这一问题，使得软件企业能够真正的提高工作的效率和工作的质量。

⑵严格的用户权限分级管理

开发人员、测试人员、测试经理、项目经理等都是组织中的不同级别的角色，他们工作内容的不同决定了在使用各类资源的权限上的不同，缺陷管理软件对测试过程中的人员进行了严格的缺陷划分，通常是将各类人员进行用户组的划分，管理员可以对这些用户组赋予不同的缺陷，例如开发组有查看缺陷详细内容的缺陷，有修改缺陷状态的缺陷的权限。但是不能够对系统中缺陷的记录进行删除。用户组的权限定义好以后，管理员就可以将实际工作中的人员划分到不同的用户组，这样管理员就不必在对单个的人员进行权限的管理，提高了人员的管理效率。

⑶缺陷具有可跟踪的信息

为了跟踪记录的缺陷，在管理软件中缺陷被增加了一些可跟踪的信息，例如ID、标题、状态、严重程度、优先级、修改人、修改时间等，这些信息的加入使得缺陷的状态随时都能被查看被了解。

⑷将缺陷按照严重程度进行划分

对缺陷严重程度的划分，为缺陷的修改时间提供了依据，通常被划分为以下几种情况：“致命” 指系统无法运行或可能存在灾难性的后果，例如系统崩溃。

“严重” 指产生错误的结果，导致系统或数据库运行的不稳定，需求分析中为实现的功能。

“一般” 指不正确的但不影响系统稳定性的错误。例如计算结果错误，数据类型、长度错误。

“轻微” 指不正确的但系统使用不方便的错误，例如界面标题不一致，提示语不明确，不正确的大小写。

“建议” 指对有疑虑或需要改进的提出的修改建议，例如界面风格，界面颜色等。

⑸缺陷在系统中有完整的生命周期

New：指测试人员提交的一个新的缺陷，等待测试组长或经理进行确认。

Open：新的缺陷被确认后的状态。

Fixing：开发人员将属于自己修改的缺陷状态设置为Fixing后，表明正在修改。

Fixed：开发人员修改完成后的状态，此时测试人员可以对已修改的缺陷进行回归测试。

Reopen：测试人员进行回归测试后，发现问题仍然存在，可以将缺陷的状态设置为Reopen。

Rejected：开发人员拒绝修改缺陷可以将缺陷的状态设置为Rejected，但此时开发人员需要填写拒绝修改的原因。

Closed：缺陷已经解决，测试人员将其状态设置为Closed。

每一种状态都指明了缺陷在解决过程中的各种情况和对项目的影响，对于每个缺陷来说，必然要经历这些状态的转变，对于缺陷生命周期的处理流程如图1所示：

(Reopen)

图1 缺陷生命周期

⑹支持异地用户使用

现在越来越多的开发团队面临着跨地域的管理，缺陷管理软件构架一般采用的都是B/S结构，服务器安装在Web服务器上，不同区域的开发团队通过Intemet 就可以轻松实现协作和沟通，加速了信息的传递，加快了缺陷处理的过程。

⑺图表定制功能

这类的缺陷管理软件可以自动生成缺陷一览表、测试结果汇总表等各种分析统计图表，项目管理人员可以根据这些图表进行分析和判断，安排测试工作，解决缺陷处理中的问题，同时测试人员也不必花费大量的时间进行文档的整理，统一的文档格式多种图表形式可以满足不同用户的需要。

⑻可与其他工具集成。

不同的软件组织或多或少的都会使用一些自动化软件，缺陷管理工具提供了与这些软件的集成，例如与配置管理软件的集成，与负载测试工具的集成。这些软件的配合使用方便了测试人员的使用，充分利用了各种资源。

6 缺陷跟踪管理流程

缺陷管理和改错流程可参见图2，具体实施必须使用开发小组指定的缺陷管理工具。该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。一切测试工作都应有计划有步骤地进行，尽可能早地进行管理，并尽可能多的发现bug，保证测试工作得顺利进行。

图2 缺陷管理与改错流程

⑴流程中的角色：

①测试人员：进行测试的人员，缺陷的发起者；

②测试组长：缺陷的管理者；

③项目经理：对整个项目负责，对产品质量负责的人员；

④开发人员：执行开发任务的人员，完成缺陷的修改；

⑤评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力。

⑵缺陷管理中可跟踪的信息为：缺陷ID、缺陷状态、缺陷标题、缺陷的严重程度、缺陷的优先级、缺陷提交人、缺陷提交时间、缺陷所属项目/模块、缺陷指定解决人、缺陷指定解决时间、缺陷处理结果描述、缺陷处理时间、缺陷的详细描述、测试环境说明、必要的附件。

⑶异议管理

如果测试人员将bug提交给某个开发人员时，这个开发人员不承认是自己的错，让测试人员找另一人，测试人员找到另一人后，又被否认是自己的错，又让测试人员找第三人，当这种踢皮球的现象出现时，测试人员也不能确定是谁的错，可能这个错误确实是几个人共同的错，此时测试人员不能将bug提交出去，可以直接找开发组负责人或项目经理，让他们分析bug原因，然后再分配，这样被分配的开发人员就没有理由再拒绝。这样踢皮球的时间一长，就耽误了缺陷修复的时间，还让测试人员和开发人员之间的关系出现不融洽，只有找到更高级的领导定夺才能让责任到人，确保项目的顺利进行。从管理这个层次上讲，一旦bug被发现后，最困难的并不是如何去记录，分派人员去解决，并予以追踪，最困难的是决定对某些bug推迟解决，甚至不予解决。这样的bug往往是在产品开发的中后期发现的，而且是由于最初架构设计的缺陷所造成的，解决这样的bug需要大量的人力和时间，影响面大，可能会引入新的bug。对于这样的bug，项目经理要与客户端的其他部门和人员联系，比如市场部门，技术支持部门，甚至于早期介入的客户。如果从他们的反馈中，确认这种bug对决大多数客户和决大多数的使用者没有影响，就要果断决定推迟，或不予解决。对于这些已决定推迟，或不予解决的bug，还有一些后续工作非常重要。首先要详细的记录，以便在下一个版本中解决；其次要让有关技术支持人员深刻理解，准备应对方案。

⑷需求变更管理

当有些bug发现后，发现并不是开发人员的错，只是需求不明确，或需求出现前后矛盾的情况，

测试人员要及时找到需求人员，确认需求确实有误，需求人员则会立即提交需求变更单。测试人员在看到变更但后，立即通知相应的开发人员，让他尽可能早的知道变更情况，开发设计人员则会在变更单签上时间和责任人，说明已经收到变更通知，会及时按需求完成开发。开发人员完成后，将变更单转给测试人员，测试人员则可对新完成的开发进行测试，并在变更单上写上自己的姓名和时间，说明测试用例设计已完成，并已开始进行测试[4]。

7 结束语

缺陷能够引起软件运行对产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的。在软件测试过程中使用缺陷跟踪管理技术可以使软件开发过程中各阶段所产生的缺陷都能得到有效管理，并能支持各个阶段、不同人员之间的协同工作，使软件测试更加有效，可以尽旱发发现缺陷，减少后期维护工作的工作量，降低软件开发与运行的成本。

参考文献

[1]林璐.对软件测试中缺陷管理的研究和实践[D].上海:复旦大学,2011.

[2]杨洁.软件测试技术与缺陷跟踪管理的应用研究[D].北京:北京邮电大学,2007.

[3]王立娟.基于软件测试的缺陷跟踪技术的研究[J].开发研究与设计技术，2007,7(7):157.

[4]叶磊.缺陷管理技术在软件测试生命周期模型的应用[D].武汉:华中科技大学,2005.

[5]范本银.软件缺陷管理系统中缺陷跟踪方法的研究[D].武汉:华中科技大学,2007.

[6]吴鑫.缺陷跟踪管理的软件测试方法及应用研究[D].济南:山东大学,2007.

软件测试之缺陷管理

软件测试之缺陷管理也许你觉得作为测试提一个缺陷很简单，但是要提一个好的缺陷其实是非常难的。在这里其实还有个隐藏的属性，叫做缺陷的概念，也就是说什么是缺陷？一般来说缺陷有两种情况，一个是违反了所谓的规则，还有一种是我们无法接受这样的情况。比如对于美来说，每一个人心目中都有一种对美的定义，你会觉得她很美，但是换个人来看待就未必。所谓的情人眼里出西施应该是指个人需求下的狭义定义。而大众情人就是那种所谓的约定俗成的广义规则。我们做一个软件面向的对象是不同的，甚至我们需要超出用户需求来做一点东西的，所以对于缺陷的判断成为了一个非常困难的事情，这里只能说对于缺陷这种东西，不要用肉眼去看要用心眼去看。缺陷管理缺陷管理是最开始也是最基础的测试必备技能。在工作了很多年后仍然会发现大量的测试人员没有办法合理的做好缺陷管理。在我眼中的缺陷管理包含以下几层概念： 1：缺陷的描述 2：缺陷的定义 3：缺陷的跟踪 4：缺陷的度量分析缺陷的描述关于缺陷的描述，无非就是当别人看到你写了一堆关于这个缺陷的巴拉巴拉后，是不是明白了5w1h，然后能够根据你的建议开始进行缺陷的修改。本质上有一点就是缺陷的描述就像议论文，一定要有说服力。如果你写出来的东西都不能让别人觉得有道理，你又怎么让别人愿意按照你的逻辑去修改这个缺陷呢。为了方便把缺陷写的更容易理解，所以现在无论是Excel的记录方式还是使用系统的记录方式，我们都会将一个缺陷分割为很多个属性，来便于管理和理解，常见的属性包括：标题，详细说明，版本，环境，发现人，发现时间，修复人，修复时间，修复说明，状态，严重级别，优先级别等。本着不浪费笔墨和浪费阅读者理解的前提下，缺陷应该是写的越简单越说明问题是最好的。但是在我遇到的大多数情况下，作为小白写出来的缺陷往往是无法阅读和理解的，因为小白总会觉得自己写出来的东西别人肯定看得懂，而忽略了很多背景或者参考的说明，常见的问题无非是：我的xx功能出错了；点击某个按钮无效果；无法启动软件等。包括在各个QQ群的提问，也经常会出现这样的无头无脑，毫无内涵的提问，让别人完全无法回答。甚至常常让我想当你在工作几年后开始学习自动化或者性能测试的时候，连一个问题或者缺陷都无法合理明确的描述出来，你做自动化和性能测试能靠谱么？能解决问题么？

软件缺陷管理流程

软件缺陷管理办法 1. 目的本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 2. 适用范围适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。 3. 定义 3.1 术语缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。 Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义（1）软件未达到需求规格说明书的功能；（2）软件出现了需求规格说明书指明不会出现的错误；（3）软件功能超出需求规格说明书的范围；（4）软件未达到需求规格说明书未指出但应达到的目标；（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。 4. 缺陷生命周期 4.1 缺陷生命周期图 4.2 缺陷状态说明

5. 缺陷处理过程 5.1 正常处理过程（1）创建问题在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。（2）指派问题创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。（3）确认问题通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。（4）解决问题此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。

工作中遇到的软件测试管理问题

工作中遇到的软件测试管理问题 1、测试负责人要进行严格的测试进度跟踪吗？很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作：测试用例执行情况；每个测试员提交的缺陷情况；测试中是否发生突发问题。 2、测试也有版本控制吗？这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。 3、如何处理测试人员的流动问题？人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。 4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么

软件测试缺陷(Bug)写作注意点

软件测试缺陷(Bug)写作注意点提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。遗憾的是，一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。由此导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，首先要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。本文将阐述软件测试缺陷报告的读者，描述软件缺陷报告的主要组成部分和各部分的书写要求，指出某些常见错误和实用改进方法，最后总结了缺陷报告的写作要点。 1. 缺陷报告的读者对象在书写软件缺陷报告之前，需要明白谁是缺陷报告的读者对象，知道读者最希望从缺陷报告中获得什么信息。通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。另外，他们不是软件测试人员，可能对于具体软件测试的细节了解不多。概括起来，缺陷报告的读者最希望获得的信息包括： ?易于搜索软件测试报告的缺陷； ?报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确； ?软件开发人员希望获得缺陷的本质特征和复现步骤； ?市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。软件测试人员的任务之一就是需要针对读者的上述要求，书写良好的软件缺陷报告。 2. 缺陷报告的写作准则书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。它也减少了工程师以及其它质量保证人员的后续工作。为了书写更优良的缺陷报告，需要遵守“5C”准则： ?Correct（准确）：每个组成部分的描述准确，不会引起误解； ?Clear（清晰）：每个组成部分的描述清晰，易于理解； ?Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； ?Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； ?Consistent（一致）：按照一致的格式书写全部缺陷报告。 3. 缺陷报告的组织结构尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同，但是基本组织结构都是大同小异的。一个完整的软件缺陷报告通常由下列几部分组成： ?缺陷的标题； ?缺陷的基本信息；

浅析软件测试管理及缺陷管理

收稿日期:2005—07—15 作者简介:殷广丽(1970— ),女,山东滨州人,讲师。浅析软件测试管理及缺陷管理殷广丽 (滨州职业学院计算机科学系,　山东　滨州　256624) 摘要:介绍了软件测试管理过程,着重分析了软件测试中的缺陷管理,缺陷管理流程、缺陷管理状态、缺陷管理生命周期。关键词:软件测试BUG;缺陷管理;角色中图分类号:TP315 文献标识码:A 文章编号:1008—2816(2005)05—0082—03 0　绪言随着信息技术的飞速发展,软件产品应用到社会的各个领域,软件产品的质量自然成为人们共同关注的焦点。不论软件的生产者还是软件的使用者,均生存在竞争的环境中,软件开发商为了占有市场,必须把产品质量作为企业的重要目标之一,以免在激烈的竞争中被淘汰出局。用户为了保证自己业务的顺利完成,当然希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加,还可能产生其他的责任风险,造成公司信誉下降。在一些关键应用(如自动飞行控制软件、军事防御和核电站安全控制系统等)中使用质量有问题的软件,还可能造成灾难性的后果。因而软件的质量愈来愈受到广泛的重视。软件测试在软件生命周期中占有非常重要的地位,是保证软件质量的重要手段。根据Boehm 的统计,软件开发总成本中,用在测试上的开销要占40%到50%。现代的软件测试不仅仅是在软件开发完成以后来做测试工作,而是将测试渗入到软件开发的各个阶段,全程控制软件质量。而软件测试最重要的目标之一是发现缺陷、管理缺陷、改正缺陷、消灭缺陷,因而,为保证软件项目按时、保质在预算范围内完成,加强对测试工作的组织和科学的缺陷管理就显得尤为重要。1　测试管理过程软件测试管理的过程如图1所示我们根据测试需求、测试计划,对测试过程中每个状态进行记录、跟踪和管理,并提供相关的分析和统计功能,生成和打印各种分析统计报表。通过对详细记录的分析,形成较为完整的软件测试管理文档,保障软件在开发过程中,避免同样的错误再次发生,从而提高软件开发质量。图1　测试管理过程 2　测试管理内容测试方案管理:单元测试、集成测试和产品测试的测试计划的录入、修改、删除、查询和打印。测试用例管理:测试用例的增、删、改、拷贝和查询;测试用例测试情况的管理,如测试状态包括:未测试、测试中、已测试;测试结果分为:通过、未实现、存在问题等;测试用例输入、编号和归档。测试流程管理:测试进度管理;测试流程标识;测试日志及状态报告。缺陷管理:测试中的缺陷处理流程、缺陷登记、缺陷分配、缺陷修复、缺陷复测、缺陷查询、缺陷统计分析以及缺陷与测试用例的关联。测试报告管理:生成单元测试、集成测试和产品测试的测试报告。除了以上这些,在测试管理过程中还包括对人员和环境资源进行管理。 2005年第5期山东教育学院学报总第111期

软件测试过程和管理(二)

[模拟] 软件测试过程和管理(二) 选择题第1题：下列哪个不是测试环境的组成要素______。 A.软、硬件 B.技术文档 C.测试工具 D.网络环境参考答案：B 第2题：以下活动中，不属于测试计划的内容是______。 A.为测试各项活动制定一个实现可行的综合的计划 B.确定测试过程中每个测试阶段的测试完成标准 C.识别测试活动中各种风险，并给出风险应对措施 D.分析测试需求，并制定测试方案参考答案：D 第3题：下列有关测试过程抽象模型的描述中正确的是______。 A.V模型指出，软件测试要尽早准备，尽早执行，只要某个测试达到了准备就绪点，测试执行活动就可开展 B.W模型强调，测试伴随着整个软件开发周期同步进行，而且测试的对象不仅仅是程序，需求、设计也同样需要测试 C.H模型指出，单元测试和集成测试应检测程序的执行是否满足软件设计的要求 D.X模型提出针对完整的程序进行集成的编码和测试参考答案：B 第4题：下列哪个选项不属于测试计划要达到的目标______。 A.为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的

对象、范围、方法、进度和预期结果 B.为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容 C.为测试执行活动设计测试方案，编制测试用例 D.确定测试需要的时间和资源，以保证其可获得性和有效性参考答案：C 第5题：下列有关软件测试设计的说法中，正确的是______。 A.测试方案应考虑是否可行、是否有效和是否能够达到预期的测试目标 B.基于判定表的测试用例设计方法是白盒测试用例设计方法 C.测试方案设计中可以忽略软件系统的实际使用环境 D.测试开发不是测试用例设计的工作内容参考答案：A 第6题：下列有关测试项目结束与定稿测试报告的说法中，正确的是______。 A.测试执行完成，测试人员向测试负责人提交测试报告后，测试项目就可以结束了 B.对当前软件产品存在的缺陷进行逐个分析，认定剩余缺陷对产品质量无重大影响后，即可定稿测试报告 C.审查测试全过程，检查测试计划和内容无遗漏后，即可定稿测试报告 D.当所有测试计划内容完成，测试覆盖率达到要求及产品质量达到定义的标准，即可定稿测试报告参考答案：D 第7题：下列哪项工作与软件缺陷管理和追踪无关______。 A.对缺陷应该包含的信息条目、状态分类等进行完善设计 B.通过软件系统自动发送通知给相关开发和测试人员，使缺陷得到及时处理 C.对测试用例的执行结果进行记录和追踪 D.通过一些历史曲线和统计曲线来分析和预测未来的缺陷发展情况参考答案：C

软件缺陷管理

————————————————————————————————作者：————————————————————————————————日期：

软件缺陷管理 1.什么是缺陷管理世间万物都有着自己的生命历程,任何产品在生产过程中,从一开始创建它的过程中,产品缺陷就会逐惭产生,并可能缺陷数量越来越多,若在产品生命周期过程中不建立缺陷检测制度,对已发现的缺陷不采取有效的控制措施,最终可能导致产品无法具有相应的使用功能,产品生命周期就会提前结束,产品的生产是失败的.因此,必须建立一套完整的产品缺陷管理制度,针对具体的产品生产特征制定相应的缺陷检测、缺陷签定、缺陷处理、缺陷验收等一系列技术措施，不断的避免或纠正产品缺陷，使终使产品在其生命周期中处于可控状态。 2．缺陷管理的过程及方法 2．1缺陷的检测：由检测人员在产品的生产加工过程中，按照本行业的质量要求及检测手段随时对产品的全部或某项设计功能进行检查，如果不能达到设计要求（可能要求在某一范围内可认为是合格的），则认定这一环节存在缺陷，缺陷生命周期开始。 2．2 缺陷的签定：对部份产品的缺陷，由于检测人员还不能确定缺陷的全部相关信息，这时就应该组织缺陷的签定，通过采用专家评审、使用先进技术手段或设备等，得到缺陷的全部信息，为缺陷处理提供原始数据。 2．3缺陷的处理：生产人员从测试人员处得到缺陷信息后，就应根据缺陷所列内容结合产品的生产过程，检查缺陷可能出现在哪一个环节，应作如何改正，避免类似缺陷再度出现。已出现测试人员提出的缺陷的产品可否采用一定的方法可予纠正，并落实这些处理措施到生产过程中。 2．4缺陷的验收：生产人员将测试人员提现的缺陷处理完毕后，又反馈信息给测试人员，报告缺陷的处理情况，并请缺陷复测。测试人员根据以前的缺陷记录信息，对该缺陷再进行一次测试，如果测试结果在设计偏差范围内，则可认为该缺陷处理完毕，同时删除本产品的主条缺陷记录，该项缺陷的生命周期到此结束。若还不能达到设计偏差范围内，则将当前检测的信息形成新的缺陷记录提供给生产人员要求处理。 3．软件缺陷管理软件测试管理的一个核心内容就是对软件缺陷生命周期进行管理。软件缺陷生命周期控制方法是在软件缺陷生命周期内设置几种状态，测试员、程序员、管理者从每一个缺陷产生开始，通过对这几种状态的控制和转换，管理缺陷的整个生命历程，直至它走入终结状态。缺陷生命状态的定义: 每一个软件缺陷都规定了6个生命状态：Open、Working、Verify、Cancel、Close、Defer，它们的基本定义是： Open态---缺陷初试状态，测试员报告一个缺陷，缺陷生命周期开始； Working态---缺陷修改状态，程序员接收缺陷，正在修改中； Verify态---缺陷验证状态，程序员修改完毕，等待测试员验证； Close态---缺陷关闭状态，测试员确认缺陷被改正，将缺陷关闭； Cancel态---缺陷删除状态，测试员确认不是缺陷，将缺陷置为删除状态（不做物理删除）； Defer态---缺陷延期状态，管理者确认缺陷需要延期修改或追踪，将缺陷置为延期状态；

软件测试管理办法

软件测试管理办法（试行） 1. 职责划分 1.1测试组长 1.参与软件需求设计的评审及项目可行性分析，风险预估，测试资源的申请； 2.编制软件测试计划、软件测试用例，定期进行维护更新； 3.根据测试组的冒烟测试结果判定是否接受该测试版本；如果达到测试标准则进入测试； 4.实施软件测试并对测试过程进行跟踪监控，对软件质量进行控制； 5.参与搭建测试环境； 6.编写测试脚本； 7.与其他部门的协调和合作。 1.2软件测试工程师 1.按照测试计划进行测试用例的执行，维护； 2.测试记录的整理，提交、验证、关闭缺陷； 3.跟踪缺陷退回的问题，必须有详细的原因分析我们才可以进行缺陷退回缺陷的否决； 4.完成性能与压力测试。 1.3质量保证QA组 1.对测试过程进行质量监督； 2.保证项目按照正常的计划执行； 3.并进行阶段性的质量评估。 2. 作业流程详细规定了测试组在整个项目中各个阶段的职责及相关测试输出文档：

3. 测试类型和策略按照目前的产品类型和规模，需要执行的测试类型及策略如下：

4. 缺陷级别定义 5. 缺陷管理流程 1.缺陷描述中要包括详细、准确的操作步骤、预期结果、实际结果、测试环境。 2.缺陷提交时在“实际结果”栏目中填写测试数据、执行结果内容，尽量将缺陷的界面截图作为附件上传至对应的记录。 3.“否决缺陷”、“暂缓处理”此两类缺陷要求在缺陷“注释”中注明否决原因或后续处理方案。 4.对“紧急”级别的缺陷，测试人员应进行随时地检查并验证，及时修改对应缺陷的状态。 5.缺陷跟踪遵循：谁发现谁跟踪；开发管理组进行确认、分配缺陷；开发人员及时修改缺陷或反馈意见。 6.开发管理组人员在自己无法及时分配缺陷的情况下要提前找到代理人员完成该工作，避免缺陷在此环节滞留。 7.开发人员必须对缺陷进行及时修改，缺陷提交后，24小时内必须进行处理。如果开发人员没有及时修改缺陷，则将缺陷严重程度的等级升级（低级->中级，中级->高级，高级->紧急）。 8.如果缺陷经开发人员多次修改（修改次数>2次），测试验证后仍存在问题，则将缺陷的严重程度的等级升级（低级->中级，中级->高级，高级->紧急）。 9.开发人员必须随时查看QC中的缺陷状态变化信息，每天最低查看次数不得少于5次。

软件测试缺陷报告

测软件名称XX测试缺陷报告书

目录 1引言 (3) 编写目的 (3) 背景 (3) 定义 (3) 参考资料 (3) 2测试环境 (4) 硬件环境 (4) 软件环境 (4) 3冒烟测试（在此以冒烟测试为例） (4) 被测软件 (4) 测试策略 (4) 执行步骤 (4) 缺陷表 (5) 3.4.1管理员 (5) 表 001-添加单个教师用户后页面不清空不跳转 (5) 表 002-添加单个教师用户时用户名重复提示信息错误 (6) 表 003-批量添加学生用户时无法导入xlsx格式的文件 (8) 表 004-添加单个学生用户时无法正常添加 (9) 结果分析和结论 (11)

1引言编写目的本文档记录在软件测试教学平台项目的系统测试过程中所发现的所有缺陷。预期的读者范围包括：项目经理测试经理开发人员背景说明：本软件是（此处说明软件的名称），采用（此处说明采用的开发软件平台）来开发。本软件名称：本项目的任务提出者：开发者：用户：实现网络：（此项可选）定义（此处主要对本文档中提到的一些术语进行解释，文档中未提到的术语不要给出了。）参考资料序号标题文件名称发表日期资料来源 1系统测试计划系统测试计划项目小组制定

2测试环境硬件环境 CPU、硬盘、内存、显示器等。软件环境操作系统，开发平台，数据库等。必要时，应指出网络环境。 3冒烟测试（在此以冒烟测试为例）被测软件（此处应说明被测软件的版本，存放位置等信息。）测试策略在各类用户的功能中，此冒烟测试仅针对测试优先级为“高”的测试项展开测试，且仅执行优先级为“高”的测试需求中的测试用例。（应根据实际的策略来撰写。）执行步骤（此处应具体说明执行的过程，包括从哪里获取被测软件，如何搭建测试环境（需要如何设置硬件，是否需要和如何打开相应的软件来支持对应类型的测试等）。

软件测试技术软件测试管理试题

第三章软件测试管理简答题 1.你是如何理解测试的层次和主要的管理活动？在软件测试的管理中，以下内容的定义反映测试工作的组织策略： a、软件测试遵循的标准； b、软件测试的工作范畴； c、软件测试环境； d、软件测试产品； e、适用于软件测试活动的软件资源标识规则； f、软件测试的进度安排。软件测试遵循的标准组织者在指定范围内选择软件测试遵循的标准，并结合本软件系统的具体要求，使之贯彻到整个软件测试的计划、实现和管理过程之中。根据标准，需要被明确的内容包括：测试阶段和测试文档类型。可以从三个角度来划分测试阶段：面向测试操作类型的阶段划分、面向测试操作对象的阶段划分、面向测试实施者的阶段划分。测试操作类型包括：调试、集成、确认、验证、组装、验收、操作等。测试操作对象可以是：单元、部件、配置项、子系统、系统等。测试实施者可以是：开发者、测试者、使用者、验收者等。各类标准从不同角度定义测试评审阶段，而测试组织者可以在符合所选标准的同时，结合多个划分因素规定本系统的测试阶段。各标准规定的测试文档类型也不尽相同。如国标《软件产品开发文件编制指南》规定了两类测试文档：测试计划、测试分析报告；国标《计算机软件测试文件编制规范》定义了八类测试文档：测试计划、测试设计说明、测试用例说明、测试规程说明、测试项传递报告、测试日志、测试事件报告、测试总结报告；《XXXX软件工程化技术文件》定义了三类测试文档：测试计划、测试说明、测试报告。我们认为最后这种规定较易操作：因为，太少的测试文档类型不利于有步骤有层次地定义测试内容，也不利于测试用例和测试例程的良好表达；太多的测试文档类型易使测试组织陷入到繁杂的文档规范和编制中去；而第三种定义较为适中。其中：测试计划在系统分析/设计阶段提交，着重定义测试的资源、范围、内容、安排、通过准则等；测试说明在测试计划明确后开始编制，针对软件需求和设计要求具体定义测试用

软件缺陷管理

软件测试缺陷管理考题

第五章一、软件缺陷 1. 计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷是属于（A）。 A. 缺陷 B. 故障 C. 失效 D. 缺点 2．问题还没有解决，测试人员新报告的缺陷，或验证后缺陷仍然存在，这些缺陷所处的状态是（A）。 A. 激活状态 B. 非激活状态 C. 已修正状态 D. 关闭状态 3. 下列关于缺陷产生原因的叙述中，不属于技术问题的是(A) A. 文档错误，内容不正确或拼写错误 B. 系统结构不合理 C. 语法错误 D. 接口传递不匹配，导致模块集成出现问题 4. 下面有关软件缺陷的说法中错误的是（C） A. 缺陷就是软件产品在开发中存在的问题 B. 缺陷就是软件维护过程中存在的错误、毛病等各种问题 C. 缺陷就是导致系统程序崩溃的错误 D. 缺陷就是系统所需实现的某种功能的时效和违背 5. 功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明，这属于软件缺陷级别中的（B）。 A. 致命缺陷 B. 严重缺陷 C. 一般缺陷 D. 微小缺陷 6. 以下哪一种选项不属于软件缺陷（D）。 A. 软件没有实现产品规格说明所要求的功能 B. 软件中出现了产品贵规格说明不应该出现的功能 C. 软件实现了产品规格说明没有提到的功能 D. 软件实现了产品规格说明所要求等功能但因受性能限制而未考虑可移植性问题7．下列不属于软件本身的原因产生的缺陷的是（C）。 A. 算法错误 B. 语法错误 C. 文档错误 D. 系统结构不合理 8．以下选项中不属于软件缺陷状态的是（C）。 A.激活状态 B.非激活状态 C.一致状态 D.已修正状态 9. 软件生存周期过程中，修改错误代价最大的阶段是（D）。 A. 需求阶段 B. 设计阶段 C. 编程阶段 D. 发布运行阶段 10. 软件缺陷产生的原因有(D)。 A. 技术问题 B. 团队工作 C. 软件本身 D. 以上全部 11、实施缺陷跟踪的目的是：（ABCD）【可多选】 A、软件质量无法控制 B、问题无法量化 C、重复问题接连产生 D、解决问题的知识无法保留 E、确保缺陷得到解决 F、使问题形成完整的闭环处理 12、导致软件缺陷的原因有很多，A—D是可能的原因，其中最主要的原因包括(ABD)。 A．软件需求说明书编写的不全面，不完整，不准确，而且经常更改 B．软件设计说明书 C．软件操作人员的水平 D．开发人员不能很好的理解需求说明书和沟通不足

软件测试-软件缺陷管理指南

缺陷管理指南

修订历史记录 1.0目的通过建立物理配置库的设立，规范各配置库目录的设立原则，确保配置库的统一与规范，确保项目产品得到有效的管理与运用，提高资源的共享与利用。

缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。细分为：1）从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决； 2）收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试过程是否结束； 3）在已收集到的缺陷数据的基础上进行统计分析。总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。本指南规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开发和维护成本。2.0参考文件无 3.0定义无 4.0职责 5.0资历及培训无 6.0入口 6.1 入口准则缺陷发生时 6.2 输入无 7.0 主要活动 7.1定义缺陷定义缺陷的要素，如下表（其中*为必选项）：

严重程度：

优先级： Bug类型：如何发现：解决方案：

7.2缺陷管理流程 7.2.1基于bugfree的缺陷管理流程： ●缺陷的提交发现的缺陷均提交给相关开发人员，如果不明确提交给谁则统一提交给项目经理，缺陷的状态为：Active。提交缺陷必须填写：缺陷的描述、优先级、严重程度、缺陷的状态、发现缺陷的阶段等信息。这些信息由提交缺陷的人负责填写。 ●缺陷的分配对于有异议的缺陷有项目组指定人员对缺陷评审，决定缺陷计划解决的版本、时间和负责人员。对于指派给项目经理的缺陷由项目经理确认指派给何人。分配缺陷后的状态为：Active 缺陷分配必须修改：指派人、评审信息（可选）。这些信息由缺陷的分配人负责填写。评审信息在“注释”中描述。 ●缺陷的解决缺陷由指定的开发人员解决后，填写缺陷修改完成时间和缺陷处理结果描述. 解决后的缺陷的状态为：Resolved 解决缺陷必须修改：解决方案、解决人、解决缺陷的版本、解决的分析、解决方案。这些信息由解决缺陷的人员负责填写。 ●缺陷的代码受控配置管理员筛选Resolved后的缺陷，将缺陷涉及到的代码统一受控。 ●缺陷的验证与关闭测试人员筛选状态为Resolved的缺陷，进行验证测试。验证通过后状态为：CLOSED 否则为：Active 缺陷的验证必须修改：缺陷的状态、解决人、解决的版本、实际关闭缺陷的版本等信息。这些信息由测试人员负责填写。 ●缺陷的激活验证关闭的确认，由于各种原因，需要重新激活进行重新修改确认时；解决的问题验证未通过时；由测试人员激活缺陷，缺陷状态为：Active 激活缺陷必须修改：缺陷状态，激活缺陷原因等信息。这些信息由测试人员填写。

Bug(缺陷管理)需求规格说明书

需求规格说明书 1. 引言 1.1编写目的软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个软件组织都知道必须妥善处理软件中的缺陷，这是关系到软件组织生存、发展的质量根本。所以我们要熟悉了解软件跟踪管理系统的基本流程。 1.2项目背景软件名称：软件缺陷跟踪管理系统软件。 1.3定义软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，处理意见，错误记录的当前状态。缺陷就是：不满足用户确定的需求；软件使用当中出现的问题；不符合设计要求。 2．任务概述 2.1缺陷管理的目标（1）确保被发现的缺陷能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；（2）收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式；（3）收集缺陷数据并在其上进行数据分析，作为组织的过程财富。 2.2 缺陷管理的一般流程缺陷信息提交后，会进行分配，进入待修正状态。通常情况下，被分配的开发人员会负责对它进行修复。然后由测试人员进行验证，验证通过后就会被关闭。如果没有通过验证，就会交给开发人员进行修复。但开发人员基于某种原因或理由，也可能会拒绝修改，这时会交给评审委员会进行评审，如果通过评审，则这个缺陷会被关闭，否则开发人员还是要继续进行修复。

测试缺陷管理规范

测试缺陷管理规范 1.目的 1.1.缺陷是产品与规定要求不相符的部分，会存在于软件产品的整个生命周期中，本文规范软件测试过程中的出现的缺陷，通过测试活动及早发现软件系统中的缺陷，并确保缺陷被有效标识、跟踪、和修改，保证软件系统能够达到要求的质量。 2.适用范围 2.1.适用于软件的整个生命周期。 2.2.不限于测试过程发现的缺陷。评审，用户使用等过程中发现的缺陷都是应当按照本流程进行登记跟踪管理。 3.术语和定义 3.1.软件缺陷：软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。 3.2.严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。 3.3.优先级：缺陷必须被修复的紧急程度。 4.职责 4.1.技术部 4.1.1.测试工程师：主要是指发现缺陷和报告缺陷的测试人员。在一般流程中，需要对这个缺陷后续相关的状态负责：包括相关人员对这个缺陷相关信息的询问回答，以及验证测试。 4.1.2.开发工程师：主要是指对这个缺陷进行研究和修改的开发人员。同时，需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。 4.1.3.其他参与人员：项目负责人、用户组等，他们对缺陷进行优先级划分，负责人进行确认并调节争议。 4.1.4.配置管理员：负责缺陷库的创建和权限管理，并监督指导缺陷库的定制。 5.缺陷流程 5.1.登记 5.1.1.缺陷发现后，由测试人员或者其他发现缺陷的人员登记到缺陷库。 5.1.2.缺陷登记后，提交前可以反复编辑，补充缺陷记录的信息。 5.1.3.登记缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、可再现、复杂问题有