APP bug 的正确解决方案

在项目初期，尤其是版本刚提交的时候，往往会出现功能无法使用或者没有实现的问题，这时候我们提交bug并不仅仅是说明预期没有实现，更重要的是我们如何备忘这件事情，如何保证没有实现的功能在最终版中实现，那么在提交bug的时候，我们需要注明，哪些case被阻塞，该功能没有验证会影响到哪些其他模块和功能的验证等

Bug提交阶段，在bug描述中备注回归时的路径说明。测试工程师提交bug时是在当时的环境下的，也就是说对测试目录，前后操作及路径都非常清楚，对于其他可能的入口或者操作，测试工程师是知道的，因而在提交bug的时候，测试工程师除了提交出现bug的操作步骤之外，如果能补充一下其他可能的路径说明，一方面开发在修复bug的时候可以作为参考，另外一方面测试工程师在bug回归的时候也能够进行更全面高效的回归

接着，在Bug提交完毕，对非用例内影响因素或路径更新到测试用例或者进行备忘。测试影响因素包括各个方面，因为测试工程师的经验，知识储备等各方面原因，测试设计往往会有一定的遗漏，这是不可避免的，在测试过程中我们往往会突然想到某个影响因素或者测试路径，这时候我们往往会去执行一下是否有问题，如果有问题，则会有bug提交，如果没有bug呢?往往我们会去继续去执行下一条case去了。实际上这种情况是对测试工程师脑力的一种浪费，不利于测试工程师经验的积累。

最后在自动化测试回归时，尽可能与开发沟通bug原因及修改方案。这个在实际操作时是有困难的，因为哪些bug需要与开发沟通，开发是否有时间等都是影响因素，当然有人会提出由开发在处理bug时提交修改说明，这当然是最好的方式，但是与国内实际环境是不符的，因而我们是尽可能的与开发了解bug原因及修改方案，然后在bug跟踪系统中或者其他什么方式进行一个简明的说明，例如是初始化数据错误这样的原因，那么在后期我们进行bug分析时，就能从一个统计意义上的数据来对测试的测试设计及执行进行。