我想强调一下，有用性（如质量）是主观的和个人/组织的事情。换句话说，一般性问题“有用吗？” 需要上下文，其中某些人是最重要的部分。我之所以做出区分，是因为我发现人们以一种我认为*无*有帮助的方式将检查纳入测试。

例如，在上述 DuncN 的情况下，人们将检查视为测试的一部分。这很酷，我同意。当人们将检查视为等同于测试时，麻烦就开始了，但显然并非如此，除非您决定将测试简化到失去大部分信息价值的程度。正如我的同事 James Bach 喜欢指出的那样，就好像人们将编译（可以自动化）视为编程中唯一有趣和有用的部分。任何对编程有所了解的人都会告诉你，编译可能是编程中最不有趣的部分。我认为，类似地，运行检查是测试中最不有趣的部分。然而，有些人似乎对它着迷。

这是关于那个的故事：http: //www.developsense.com/blog/2009/08/testing-vs-checking/和http://www.developsense.com/blog/2009/11/merely-checking-or - 只是测试/

@布鲁斯...

这么多认真考虑测试的人拒绝 ISTQB 的原因是因为它的材料无法做出这样的区分。

与其让 ISTQB 告诉您某些东西是否有用，您可以自己检查并做出自己的评估。然后，如果它对您没有用，那非常酷。

---迈克尔 B.

测试和检查之间的区别除了围绕水冷却器进行诙谐的哲学玩笑之外，并没有为测试行业增加任何重要价值，或者导致我们的 SDLC 流程发生变化。

如果检查与测试的概念使测试人员反思测试的目的或意图，那么检查与测试的概念可能会增加价值。但是，这会导致我们的专业术语发生变化吗？恕我直言，这种区别充其量是微不足道的。

我同意“测试是我们为了寻找新信息而做的事情。” 有时甚至“探索性测试”也不会揭示对利益相关者很重要的新信息，有时设计良好的自动化测试会揭示以前通过其他测试方法未发现的新信息。此外，当产品发生变化时，一些测试（可能称为检查）将揭示新信息。

测试不是“尝试”然后思考结果是否有问题。Boris Beizer 说：“在儿童测试中，测试人员说，事实上，观察到的测试结果是（或不是）预期结果。在实际测试中，结果是预测的......”换句话说，当我在测试中，我至少应该能够在某种程度上预测在我执行一组操作后会发生什么或我将处于什么状态；否则我们只是在猜测“这里有问题吗？” 所以，如果有人真的想区分检查和测试，那么他们也应该区分测试和猜测。我有时会看到大量的猜测正在发生。

大多数情况下，我在区分“智能测试人员”的人时会听到这些术语，这意味着他们了解很多测试理论，并且可以创建自己的测试用例等（通常与探索性测试一样在飞行中）和仅仅跟随的人其他人编写并“检查”结果的脚本（如果没有将其作为要检查的结果之一，可能会错过在此过程中发生的任何错误。对我来说，前一个人是有能力做真实的人“测试”，而后者大多只是“基于人的测试自动化”

我有时听说（并自己使用过这个词）后者被称为“猴子测试员”，因为他们的技能水平比训练有素的黑猩猩好不了多少。但是我认为这不是一个很好的术语，因为它可能被解释为种族主义（我不认为它是，或者至少我在使用它时从未打算这样做。这有点侮辱也许，但真的不应该被视为对个人的侮辱，（我们都必须从某个地方开始）而是对雇用这些人进行“测试”的组织。我遇到过一些声称自己头衔的人一个“测试专业人​​员”，但他们没有得到雇主的教育或培训，也没有自己寻求，并且基本上只是做了长达 2 年的“检查”，并且诚实地认为他们了解 QA。

我认为种族影响的出现是因为许多担任“检查员”角色的人似乎在为离岸测试外包公司工作，因此一种不公平的刻板印象开始出现。

我遇到过一些从事过跳棋工作的人，但他们对学习测试理论很感兴趣，并真正开始使用他们的大脑和智慧来进行“真正的”测试。这实际上是相当令人欣慰的，我很高兴看到越来越多志同道合的人聚在一起进行自我教育（因为他们的雇主似乎对此不感兴趣）自己学习真正的测试，并开始能够创建自己的测试案例，了解何时/何地适合进行哪些测试等。

我在这里和那里提供了一些指导，我知道像迈克尔·博尔顿和詹姆斯·巴赫这样的人非常慷慨地帮助这些团体开始并教人们将批判性思维应用于测试过程，而不仅仅是运行其他人创建的清单。

（对不起，长篇大论，但我认为这实际上是一个非常重要的话题）

我相信我明白你在说什么。至少对我自己来说，支票绝对是测试的一部分。

检查确定系统是否在特定状态下给定特定输入产生所需的输出。这些检查用于帮助您决定测试是通过还是失败。

稳定性测试、性能测试等很少说测试通过或失败，因为它通常会返回一组值供人类阅读并决定测试是通过还是失败，因为您使用的自动化可以很少确定它所处环境的状态。假设您正在为 Web 应用程序运行性能测试。通过非常小的代码更改，您会看到页面加载时间增加了 500 毫秒。根据您的自动检查，这似乎是一场灾难性的失败。然而，当您查看结果并询问其所在服务器的状态时，您会发现另一个团队正在同一服务器上的另一个密集型应用程序上运行负载测试。就其本身而言，这也可能不会提供任何细节，但是，

根本不是相同的类比，但是，我通常喜欢引用迈克尔博尔顿的以下内容，这与您所描述的非常相似。