关于手工测试与自动化的两难问题

 从今年年初的版本开始，项目要求各特性测试用例的自动化百分比要达到80%以上，于是乎我们花了很多时间在写自动化脚本上。最近的一个项目，因为考虑到后面还有好多轮迭代以及回归，因此我们鼓励尽早做自动化，甚至在第一版本转测的时候，我就开始埋头写自动化了，而不是先把用例手工执行一遍。

        自动化的时机，到底在什么时候做自动化，其实，这涉及到一个两难的问题。

        一种做法是一开始早就做自动化，这样做的好处是后面的多轮迭代可以充分利用这些自动化的成果，使你后面的测试工作更轻松。但是它的缺点就是干开始要耗费太多的时间，以至于第一轮测试你没办法去做一个充分的漫游和发散，错过了及早发现BUG的机会。

       另一种做法是，一开始你就先手动测试，等手动测试完成后有闲暇时间再开始写自动化脚本。这样做刚好和上面相反，它有助于你及早发现错误，但是由于你前面自动化的用例太少，导致你第二轮第三轮测试可能还要做大量的重复性的手工测试。

       这个问题困扰了我一段时间了，期间我基本上采用的是第一种方法。但后来在实践中证明，这并不是一种很好的方法，这种方法不但找到的BUG更晚一些而且更少一些。晚一些的原因上面已经说过。少一些有以下原因，原因一：杀虫剂效应，当这些用例一遍又一遍地执行的时候，已经很难再找出新BUG了；原因二：我一直在想自动化完成后，后面有的是时间，我可以进行一些发散测试，不过实践证明我并没有我想的那么勤劳，经常是把用例自动化完了就停滞不前了。

        鉴于越早发现BUG修复的代价越小以及我不是个很勤劳的人这两点来看，第二种做法可能会更合适一些。最近也接触了一些探索测试的东西，现在总体的想法是，在第一轮测试的时候，先用探索测试的方法在已有用例基础上进行一些探索测试，快速将特性测试一遍。以便尽早地找出一些严重或显而易见的BUG。在这期间，每天还要安排一部分时间来写一点自动化用例，这可能需要我多付出一些时间和精力，但从对后面的工作提供的帮助来说，这绝对是值得的。总得来说，是更倾向于第二种方法，并把探索测试融合进来，但也要预留一定时间来写自动化。至于之间的时间分配比例，没有一个万能的值，实践出真知吧。