首先测试用例设计阶段，设计并维护一个各个功能入口的说明文档。其实这个文档的作用很大，一方面对于bug回归阶段的人来说，这是用于提醒的;另外一个方面，在随机测试的时候，随机程度也能有所提高，测试人员能够自己随意组合可能的路径。当然，一样一份文档也能提升文档设计人员，文档阅读人员对于模块的整体认识
在Bug提交阶段，评估阻塞用例说明。在项目初期，尤其是版本刚提交的时候，往往会出现功能无法使用或者没有实现的问题，这时候我们提交bug并不仅仅是说明预期没有实现，更重要的是我们如何备忘这件事情，如何保证没有实现的功能在最终版中实现，那么在提交bug的时候，我们需要注明，哪些case被阻塞，该功能没有验证会影响到哪些其他模块和功能的验证等
Bug提交阶段，在bug描述中备注回归时的路径说明。测试工程师提交bug时是在当时的环境下的，也就是说对测试目录，前后操作及路径都非常清楚，对于其他可能的入口或者操作，测试工程师是知道的，因而在提交bug的时候，测试工程师除了提交出现bug的操作步骤之外，如果能补充一下其他可能的路径说明，一方面开发在修复bug的时候可以作为参考，另外一方面测试工程师在bug回归的时候也能够进行更全面高效的回归
接着，在Bug提交完毕，对非用例内影响因素或路径更新到测试用例或者进行备忘。测试影响因素包括各个方面，因为测试工程师的经验，知识储备等各方面原因，测试设计往往会有一定的遗漏，这是不可避免的，在测试过程中我们往往会突然想到某个影响因素或者测试路径，这时候我们往往会去执行一下是否有问题，如果有问题，则会有bug提交，如果没有bug呢?往往我们会去继续去执行下一条case去了。实际上这种情况是对测试工程师脑力的一种浪费，不利于测试工程师经验的积累。
最后在自动化测试回归时，尽可能与开发沟通bug原因及修改方案。这个在实际操作时是有困难的，因为哪些bug需要与开发沟通，开发是否有时间等都是影响因素，当然有人会提出由开发在处理bug时提交修改说明，这当然是最好的方式，但是与国内实际环境是不符的，因而我们是尽可能的与开发了解bug原因及修改方案，然后在bug跟踪系统中或者其他什么方式进行一个简明的说明，例如是初始化数据错误这样的原因，那么在后期我们进行bug分析时，就能从一个统计意义上的数据来对测试的测试设计及执行进行一个指导