软件测试是一种以观察和实验为依据的调查过程(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 也发布了一篇新闻《热衷敏捷测试的十大理由》，有兴趣的同学们请参阅。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论