Planning is everything. Plans are nothing! 这是艾森豪威尔将军的名言. 二次大战期间, 艾森豪威尔带领同盟国联军, 跨越英伦海峡反败为胜, 靠的就是缜密的情报搜集和灵活应变.
我想大家应该都赞同这样的理念, 项目一开始是要有计划, 但是更重要的是要随时随地在规划, 以因应各种突发状况.
同样地, 在测试方面也是一样, Testing is everything, tests are nothing. 这是什么意思呢?
很多时候, 我们要进行测试, 会先制定测试计划, 接着再开立测试个案, 然后再去执行测试个案.
不是吗? 大多数人不都是这样做的吗? 这有什么问题呢?
不是的, 测试 (testing) 应该是一个探索 (exploratory)和学习的过程.他要到处去看看, 去了解受测物的一切, 一边学习, 一边去找出问题.
哪我们现在在做的叫什么呢? 绝大多数的状况叫做 checking. 也就是说确认 (confirmation) 系统有没有照 test case 上写的的状况运作.
例如: 要测试一个安装程序. 你可能会开立一个测试个案, 测试以预设值的状况来安装是否正确. 因此你可能写:
[步骤]
执行 setup.exe
当画面出现时, 一切都使用系统预设值, 因此都是按下 OK 键, 让 setup.exe 来安装程序
[预期结果]
当 setup.exe 显示安装成功的讯息, 就代表系统已经被成功地安装.
因此, 如果你是 checking 的方式来进行测试, 你就会照上面所写的一步步执行. 并且照预期结果的项目来检查. 可是 ….
是否所有 process 安装完后都有执行起来吗?
是否所有的 registry key 都已经建立, 并且相关初值都正确?
是否 CPU 没有一直满载?
…
要确认的事情很多, 你可能要去摸索一段时间后, 才知道总共有哪些要检查. 并且随着学习到更多系统内部的知识, 你可能会要求做出更多的检验.
因此, checking 只是去确认你已经知道的东西对不对, 你只是确定以前检查过的是否还运作正常, 你只是把上面有写的照做一次, 没有写的你就没做.
你说, 这样能找出 bug 吗? 很难吧, 因为最多就是第一次执行有效; 或者是重新执行去抓到某些修改的 side effect, 否则还真的不容易看到新的问题.
所以, 你的测试应该是要以 testing 的方式来进行, 而非以 checking, 即使你是用自动化的方式来进行, 也无法让你找到更多 bug ….
因为绝大多数情况你只是在求心安, 因此在骗自己那些 case 跑完, 系统就没问题了.
