3. 如果我们为每一个补丁提供发行信息，那么这些补丁的新错误是非常容易跟踪的。

　　从上述内容可以看出，回归测试充分表明，测试是一个反复的过程。我们需要反复进行这个过程：测试、修正、再重新测试，直到系统达到我们的要求为止。

　　(7) 用户验收测试

　　一但我们系统测试完成，这意味着已经达到了所有要求，而后一步还必须由用户来验证。这是因为终使用系统的是我们的客户，而不是开发人员或测试人员。因此，这一步是必须的。

　　如果在这一步测试失败，很可能是我们的需求出了问题，那么我们必须将需求文档找出来和用户一起商讨。看是否需要改变需求文档或是修改系统。

　　三、报告和错误核对

　　一但我们的系统完全通过测试，我们还需要处理并确认在每一步所产生的Bug和修改记录。

　　一种常用的方法是使用一个中心数据库，在这个数据库中保存了每一个新的错误和处理纪录。所保存的主要信息如下：

　　1. 一个ID号

　　2. 状态（是新的错误，还是正在处理中，或是已经被解决）

　　3. 优先级

　　(1) 红色（Red）：表示非常严重和致命的错误，必须修改

　　(2) 黄色（Yellow）：一般的功能性错误，在发行前应该修改

　　(3) 绿色（Green）：这种错误只有使用非常极端的操作才可能出现，这在系统发行前再确认是否需要修改

　　4. 解决错误的补丁号

　　5. 修改人：表示这个错误是由谁后修改的

　　6 一个错误细节描述：这个可以是任何错误的信息或是屏幕截图，当然也可以是其他的错误信息

　　在错误报告更新后，我们还应该记录报告是由谁，什么时间创建或修改的。