“测试”与“检查”之间的区别有用吗？

#1 楼

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

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

这里的故事是：http://www.developsense.com/blog/2009/08/testing-vs-checking/和http：// www .developsense.com / blog / 2009/11 / merely-checking-or-merely-testing /

@Bruce ...

许多人认真思考的原因关于测试拒绝ISTQB的原因是，它的材料无法像这样区分。

与其让ISTQB告诉您是否有用，不如您自己检查一下并做出自己的评估。然后，如果对您没有用，那就太酷了。

--- Michael B.

#2 楼

测试与检查之间的区别对水冷式冷却器周围的机智的哲学嘲笑并不会导致我们的SDLC流程发生变化，这对测试行业没有任何重要意义。

如果“检查与测试”的概念引起测试人员对测试的目的或意图进行反思，也许它可以增加价值。但是，这会导致我们的专业术语发生变化吗？区别最多是微不足道的恕我直言。

我同意“测试是我们出于发现新信息的动机而进行的工作。”有时甚至“探索性测试”也不会揭示对涉众重要的新信息，有时，经过精心设计的自动化测试也会揭示以前通过其他测试方法未发现的新信息。另外，某些测试（有时也称为检查）会在产品发生更改时显示新信息。

测试不是关于“尝试”的事情，然后思考结果是否有问题。鲍里斯·贝泽（Boris Beizer）表示：“在进行小童测试时，测试人员说，事实上，观察到的测试结果是（或者不是）预期结果。在实际测试中，结果是可以预测的……”换句话说，当我在测试中，我至少应该能够在某种程度上预测在我执行一系列操作之后会发生什么或处于什么状态；否则，我们只是在猜测“这里有问题吗？”因此，如果某人真的想在检查和测试之间进行区分，那么他们也应该在测试和猜测之间进行区分。我有时会看到很多猜测。

#3 楼

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

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

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

我遇到了一直作为检验员，但对学习测试理论感兴趣并真正开始使用他们的大脑和智慧进行“真实”测试的人们。实际上，这很令人满足，我很高兴看到志同道合的人们聚在一起进行自我教育（因为他们的雇主似乎对此没有兴趣）的运动越来越多，他们能够学习真正的测试，并开始能够创建自己的测试案例，了解什么时候/什么地方合适的测试。

我在这里和那里为一些人提供了一些指导，我知道像Michael Bolton和James Bach这样的人对他们的时间很慷慨帮助此类小组入门并教会人们将批判性思维应用于测试过程，而不仅仅是运行其他人创建的清单。

（对不起，我想说这是很重要的话题）

#4 楼

我相信我了解您的意思。至少对我自己来说，检查绝对是测试的一部分。

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

稳定性测试，性能测试等很少说测试通过或失败，因为它通常会返回一组值。供人阅读并决定测试是通过还是失败，因为您使用的自动化很少能确定测试所在环境的状态。假设您正在为Web应用程序运行性能测试。只需很小的代码更改，您就会看到页面加载时间增加了500ms。根据您的自动检查，这似乎是灾难性的失败。但是，当您查看结果并询问其所在服务器的状态时，您会发现另一个团队正在同一服务器上的另一个密集型应用程序上运行负载测试。它本身可能也没有提供任何细节，但是，在再次运行性能测试并比较结果之后，它可以帮助您做出最终判断。通常喜欢参考Michael Bolton的以下内容，与您所描述的内容非常相似。

#5 楼

我同意Michael Bolton网站上的Lyndon。他是我遇到的“测试”与“检查”的最大倡导者。尤其是如果您遵循所有参考文献。大体上，术语“测试”被认为包含术语“检查”-检查是测试的一部分

#6 楼

我不熟悉常见的质量检查称谓中使用的“检查”一词，而且ISTQB词汇表中也未列出该术语，因此我想说，您的问题的答案是否定的。说，我要说的是，您如何使用该术语是指在执行测试用例时执行对期望和实际结果的确认的行为。

#7 楼

尽管我们不使用“检查”一词，但在我目前的商店中，我们确实对这两个概念进行了区分。我们从不查看用于创建输出的代码，它可以（并且经常）在批处理运行之间的任何时间进行更改。当我们发现问题时，手动修改输出而不是修复代码被认为是完全可以接受的。对我来说，这符合所谓的检查。

对于我们所有其他系统，我们做的是所谓的测试。我们通过一系列测试来驱动代码和模块，并且无处不在-不仅仅是输出。我们永远不会接受手动修复输出来解决错误。

对我们来说，这种区别很有用。

#8 楼

我发现区分测试和检查很有价值。也许不像某些人那么热情或学究。 :)我认为当您开始谈论自动化时，这是最重要的。自动化可以检查很多事情。因此，人们谈论用自动化代替动手（和动脑）测试。但是，我还没有看到在自动化套件中可以有效地捕捉到更多的人类思想和实验。出于这个原因，我觉得有必要提醒自动化成瘾者他们的检查很有用，但我们也需要进行测试。