3、测试用例/大纲与需求检验
分成两个阶段：用例设计出来即将测试和测试即将完毕的时候，我们需要拿着产品需求文档或者我们自己维护的产品需求变更文档对照我们的大纲看是否每条产品需求都已经实现且符合产品逻辑。
4、随时更新文档
需求会因为发现的bug而发生变化，用例会因为需求的变化或者突然想到的影响因素而需要进行变更，那么及时更新文档，或者进行备忘，请相信我否则你会漏需求或者漏测！而且事后你会什么都忘记了！
那么我们需要及时更新或者备忘的是什么呢？
a）深挖出来的潜在需求：我们都会有一些理所当然的事情，需求也不例外。
b）需求变更
c）无效的测试用例
d）需要补充的测试用例
e）产品实现文档
5、清晰标记测试用例的执行情况
我们的测试过程往往会被一个bug或者某个讨论所中断，当我们继续缩执行的测试时，实际上用户环境已经发生了变化，衔接处的用例往往会因为重新进入状态而影响执行质量。
所以，我们在用例执行时，对每条case都需要标注当次的执行结果：成功，失败，阻塞。
6、尽可能了解实现
一个需求要实现，途径有多种，在时间比较紧的情况下，有些开发会使用一些取巧的实现方法，而不是最优的实现方法。当我们逐个执行case的时候发现逻辑正常，但是当执行稳定性，随机或者大数据量的测试时，问题出现了和我们之前执行结果不一致的地方。
一般来讲，这种环境下，我们至少要了解：
a）读写了哪些磁盘文件及注册表
b）数据流完整路径
7、对原有模块的流程测试
我们在测试中经常会遇到一个问题，就是要测试的需求中某块代码是现有的或者其他模块挪过来用的，我经常会对这些地方不够重视，而我经常会遇到这种地方有问题。所以面对这种问题时，我们应该将这个功能块进行路径覆盖。
上面是我暂时能想到的解决当前问题的方法，希望质量不断提升！
