软件错误跟踪处理流程

　　大型本地化软件测试需要进行充分的测试准备，需要科学的测试流程管理。为了跟踪和控制测试质量，便于管理测试发现的Bug，需要为每一个测试项目配置一个专用缺陷跟踪数据库，以便报告、查询、分类、跟踪、处理和验证错误。

　　为了保证发现和报告的错误质量，需要首先由经验丰富的测试人员，在缺陷跟踪数据库中对新发现的错误进行确认，如果确实属于错误，再由错误修复工程师进行修复处理。

　　1、软件错误的状态

　　新错误(New)：测试中新报告的软件缺陷。 更多新信息(New More Info)：错误修复工程师认为报告的错误信息不完整，要求错误报告者添加更准确的错误信息。 打开 (Open)：错误被确认并分配给相关错误修复工程师处理。 拒绝(Declined)：拒绝修改缺陷。包括两种情况： 拒绝-不是错误(Declined-Not Bug)：报告的错误不术语错误。 拒绝-重复(Declined-Duplicated)：以前已经报告过这个错误，需要指出已经报告过的错误标识编号。 修正(Fixed)：错误修复工程师已完成修正，等待测试人员验证。 重新打开(Reopen)：没有正确修复的错误，需要进一步修复。 延期(Deferred)：不在当前版本修复的错误，以后的版本修复。包括两种情况： 延期-下个版本(Deferred –Next Build)：本项目的下一个新版本修复。 延期-下个主要版本(Deferred –Next Main Release)：本项目不修复，本软件下一个项目的版本修复。 关闭(Closed)：错误已被修复。

　　2、Bug管理的一般流程

　　测试人员提交新的错误入库，错误状态为New。

　　高级测试人员验证错误，如果是重复报告的错误，则设置为Declined- Duplicated状态，并指出与哪个已经报个错误重复(注明标识编号ID#)。否则，如果确认是错误，分配给相应的修复工程师，设置状态为Open。如果不是错误，则拒绝，设置为Declined-Not Bug状态。

　　错误修复工程师查询状态为Open的错误，如果因为错误的信息不完全，没法重现错误，则设置状态为New More Info;如果不是错误，则设置状态为Declined-Not Bug;如果是错误则修复，设置状态为Fixed。对于当前版本不能解决，准备本项目的下一个新版本处理的错误，要留下处理注释，设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决，要留下处理注释，设置错误为Deferred –Next Main Release状态。

　　对于不能解决和延期解决的错误，不能由软件修复工程师自己决定，一般要通过某种会议(评审会)通过才能认可。

　　测试人员查询状态为Fixed的错误，然后验证错误是否已修复，如果已经修复，设置错误的状态为Closed，如没有解决置状态为Reopen。

　　下面以一个错误的处理过程为例，给出一般的处理流程图。

　　3、软件错误流程管理要点

　　为了保证错误的正确性，需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误，测试步骤是否准确、简洁、可以重复。 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解，对测试报告的个别软件错误，可能无法确认是否属于真正的软件错误，本地化服务商需要与软件供应商交流并确认。 每次对错误的处理都要保留处理信息，包括处理者姓名，时间，处理方法，处理步骤，错误状态，处理注释等。 对错误的拒绝不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。 对错误延期处理不能由本地户服务商决定，应该由软件供应商决定。 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。

原文转自：http://www.uml.org.cn/Test/200701175.asp