软件测试过程中，最基本的任务莫过缺陷管理，如果没有发现缺陷，也无法报告软件缺陷，消除缺陷也无从谈起。随着对缺陷管理的日益重视，越来越多的测试工具已经为我们发现软件中的缺陷打开了方便之门，那么，我们应该如何正确使用工具进行软件测试工作中缺陷的发现和汇报，有效的提升IT系统质量呢？
第一步：规划缺陷管理流程
实践证明，只有展开全面彻底地规划，才能让缺陷汇报和解决流程提供有价值
的信息，使IT流程合理化。以下部分所描述的步骤是在创建汇报流程、定义缺陷安
全等级、记录缺陷状态和跟踪所有修改的过程中会被采用的一些步骤。
发现“缺陷”
通过使用测试工具，在SDLC（软件开发生命周期）中未被发现的所有和项目有
关的差异及问题都将汇报到管理工具中。美科利TestDirector针对不同的差异，清
晰的定义了NEW、OPEN、CLOSED等级别。当工具中开放了一个新的缺陷问题，我们
就要陆续开始登录缺陷报告、定义缺陷安全等级、描述缺陷、指派相关人员展开最
初的调查、将差异转交给相关的测试主管等工作。
缺陷解决会议
召开缺陷解决会议能确保所有缺陷都能涉及并得到有效解决。这种定期会议由
来自开发、项目管理、产品管理、和项目相关的业务团队代表及测试主管共同参加
，就缺陷问题展开讨论。测试主管在会议期间对测试工具进行信息更新，会议的中
心议题是对缺陷报告进行审核。有了测试工具提升的完备的报告，我们就可以依据
其严重程度和状态情况，选择处理的优先权
缺陷修复
缺陷解决会议后，缺陷将被分配给合适的小组主管，以便着手解决。这些小组
包括：开发小组、环境支持小组，或是业务团队。通过管理工具对任务进行合理分
配，能更为高效地解决缺陷问题。
重复测试缺陷
被修复缺陷如果在环境缺陷中没有代码变更，将马上展开重复测试，并立即关
闭。需要代码变更的缺陷修复会涵盖在一个版本打包中，从而展开重复测试，接着
将根据测试结果或者关闭缺陷，或者将缺陷重新开放。
第二步：定义缺陷状态
每个缺陷都有一个状态显示，会在整个测试周期中得到随时地更新。每次当缺
陷状态有了更新，评论信息就会加入到缺陷的R&D评论栏中。测试工具中的缺陷状
态一般会有以下几种：
New：默认值，测试分析人员输入一个新的缺陷时，其状态为“New”。
Open：测试主管将缺陷状态从“New”改为“Open”，并在一定的时间内（根据
缺陷严重程度）更新R&D评论信息，接着指派给适合的小组。
Fixed：当缺陷被修复并通过了联合测试，开发人员将缺陷状态从“Open”改为
“Fixed”。缺陷修复的周期取决于缺陷的严重程度。
Ready for Retest：当缺陷已经修复，并在一个build中完成了系统测试和识别
，项目/产品/发布经理将缺陷状态更新为“Ready to Retest”。
On Hold：当该缺陷由于其它缺陷的阻碍而无法在build中实施重复测试时，测试
分析人员将缺陷状态从“Ready to Retest”更新成“On Hold”。
Closed：当缺陷在一个新建的应用中完成了重复测试，测试分析人员就将状态从
“Ready to Retest”改为“Closed”。
Reopen当缺陷重复测试失败，测试分析人员将状态从“Ready to Retest”更新
为“Reopen”。当以前已经关闭的缺陷又在测试过程中出现时，测试分析人员将把
状态从“Closed”改为“Reopen”。
第三步：用户操作的状态修改
通过对测试工具所允许的状态变更操作，可以为实现便捷的学习曲线和巩固一
种优化的工作流程提供帮助。状态变更包括：
根据适合的变更控制流程所进行的任何系统变更。
在进行修复操作之后，未通过测试或某个测试部分根据需要展开重复测试。
在流程中的任何时段，项目经理、系统分析人员、开发人员和测试工作人员可以
使用测试工具来恢复保存在存储器中的所有缺陷状态等。
最后：将新的流程配置到测试自动化工具中
最后，当所有流程都得到了及时改进后。我们就把一个杂乱无序的流程打造成
为一个有着杰出运作表现的项目，具有完备的信息记录；可重复的流程；可衡量的
成果；和一个改进程序。正确地运用软件去创建缺陷解决流程，实现开发环节中使
用的手动流程自动化，以创建稳固的测试计划及测试组合。
功能强大的美科利TestDirector通过一个独立的、基于Web的应用来支持整个测试
流程，包括需求管理；规划、创建、安排和执行测试；缺陷管理；项目状态分析等
。同时，它还可与行业中广泛使用的第三方应用相集成，有效保护企业现有解决方
案上的投资。有了可以在无人操作情况下自动地、24X7不间断运作的测试工具，我
们就能很好地达到提升IT系统质量，增强系统效益的目标。
