软件测试是一种以观察和实验为依据的调查过程(empirical investigation),该过程以测试为手段,为干系人提供产品或服务的质量信息。然而,这个定义并没有提到人类智慧的应用,而人类的智慧使得测试(testing)和检查(checking)之间产生微妙区别。 Michael Bolton 谈了两者的区别及其产生原因。
Michael 认为:
检查是指为了证实已经存在的理念而去做的事情。检查是一个证实(confirmation)、验证(verification) 和确认(validation) 的过程。当我们已经相信某些东西是正确的,我们会通过检查来核实这一点。当我们修改了代码又想确保一切功能照常运行,我们就需要检查。测试是指我们为了发现新信息而去做的事情。测试是一个探索(exploration)、发现(discovery)、调查(investigation)和学习的过程。当我们想通过配置、操作或者观察来评估一个产品时,或者当我们试图去识别一个没有预计到的问题时,我们就是在测试。
Michael 认为:检查要依赖机器完成,因为它们可以给出非此即彼的两个答案:通过或者失败。测试却需要智慧。测试是了解系统和解答问题的探索之旅:“这里有问题吗?”这也引出了测试人员和检查人员的区别。
需要有最新的、清晰、完整而且没有歧义的规范说明才能工作的人是检查人员,不是测试人员。同样,需要有测试脚本才能工作的只是检查人员,而不是测试人员。而仅仅根据参考文档来比较当前程序的人也是检查人员,不是测试人员。
George Dinwiddie 认为检查和测试都是需要智慧的。他觉得虽然Michael 认为“运行和观察结果”是检查,但是这仅仅是脚本测试的一部分。一旦测试失败了,就需要测试人员的智慧来弄明白到底发生了什么。这可能包括通过查看日志文档来获得信息,让其他人去看看别的系统是不是工作正常,以及很多其他探究性工作。所以这跟探索性测试没有区别,除了发生的时间有点延时而已。
Michael 一定程度上也同意这个观点,他认为仅仅检查点(check)本身是很微不足道的。往往检查之前或者检查之后,人类的智慧起到了很大作用。这也就是一个检查点(check)和检查(checking)的区别。
所以核心问题在于我们认为哪一个更有价值,是检查点(我们有 50000 个自动化测试)还是检查。只有检查点是不重要的,但是检查——涉及到构建、维护和分析每个检查点——却是很重要的。参照艾森豪威尔那句话(译者注:艾森豪威尔,二战欧洲盟军总司令,美国 34 任总统。他在诺曼底登陆以后有句名言:Plan is nothing, but planning is everything),就检查而言,检查点什么都不是,与之相比,检查这一系列过程才是王道 (with respect to checking, the checks are nothing; the checking is everything)。然而检查也不是万能的,测试也是如此。
Johanna Rothman 也发表了类似的看法,她认为测试需要技能和智慧并存。
敏捷项目需要真正的多面手来担当测试人员:拥有能读懂需求、设计和代码的技能的人。没有这些技能,他们就不能足够深入地去思考开发中的产品,他们也就有可能无法识别出足够多的各类测试用例。如果他们能够理解需求、设计和代码,他们就可以根据他们的理解设计出巧妙的测试用例。其中的一些测试是探索性的,甚至有些探索性的测试需要以自动化方式实现,以便以后重复运行。我曾经在敏捷项目中见过一些出色的测试人员,他们能够很快地编写出自动测试脚本来做一些探索。
Cem Kaner 则不同意敏捷测试人员需要是多面手一说。他认为既然探索性测试既需要测试又需要探索,那么为了能探索得当,还是很有必要运用些特定技能的。他说道:
程序员理解项目中很多的风险。相比非程序员出身的人,他们可能能更好地写出深入的测试来探测那些风险。而其他人可以更加专注于当前环境下的软件集成。相类似地,我们熟知的一些系统性能或者安全评估方面的专家,也能在他们的领域更好地表现。他们中的一些人是程序员,一些则不是。所有这些人和系统级别的软件测试人员(software validator)一起,才能做好自动脚本测试或者探索性测试。
George 认为这两种模型都有各自的利弊。检查和测试都能满足 Cem Kaner 关于测试的定义。关键不在于是不是测试脚本化,而是你做事的流程和方式。
两个都是测试,都在寻找新信息,都需要智慧。如果你不这么想,那么你的测试方式就错了。
前不久,InfoQ 也发布了一篇新闻《热衷敏捷测试的十大理由》,有兴趣的同学们请参阅。
评论