为什么Cem Kaner认为测试不显示bug浪费时间？

在肯定的测试中确认功能，证明其有效该怎么办？我应该说这是浪费时间吗？这句话背后是什么概念？

测试失败，即没有发现错误的测试是浪费时间。

Web工程：引用Cem Kaner 的Web应用程序系统开发学科。

我在25年前写了大多数《测试计算机软件》。从那以后，我指出了书中我认为已经过时或完全错误的几个部分。参见http://www.kaner.com/pdfs/TheOngoingRevolution.pdf

您可以在我的网站上看到更多内容（当前视图，但没有明确指向TCS的指针），以访问Black Box软件测试课程（免费提供视频和幻灯片），网址为www.testingeducation.org/BBST

当时的测试文化在很大程度上是确定性的。

在现代测试中，单元测试的方法在很大程度上是确定性的-我们编写了大量的自动化测试，以简单地验证软件是否能够按预期运行。这些测试可以用作变更检测器-如果代码其他部分中的某些内容现在已经出现问题，或者如果现在在现实世界中无法实现的数据值正在到达应用程序，则变更检测器将触发并警告程序员遇到维护问题。

我认为，确认性思维方式适合于单元测试，但是可以想象一个世界，其中所有系统测试都是确认性的（对于有区别的人，请解释“系统集成测试”和“验收测试”，如我对系统的评论中所述）测试的重点是确认程序符合其规范，而主要的方法是构建不计其数（或至少几百个）的系统级回归测试，以将规范的某些部分映射到程序的行为。（我认为规范对行为的确认很有用，但我认为这只是一个较大目标的一小部分。）

仍然有以这种方式运行的测试组，但是它不再是主要观点。当时是。我着重写作，并提出了鲜明的对比，以指出那些一直接受这种思维方式训练的人们。今天，一些鲜明的对比（包括此处引用的对比）已过时。他们被误解为对错误观点的攻击。

如我所见，软件测试是一个学习有关软件产品或服务的质量相关信息的经验过程。

应该设计一个测试来揭示有用的信息。

那时，顺便说一句，没有人谈论测试作为一种揭示“信息”的方法。当时，测试要么是为了发现某个版本的bug，要么是为了发现某个版本的规范，以验证（检查）程序。我认为直到本世纪，测试词汇才一直被认为是用于揭示有用信息的断言。

想象一下根据信息价值进行的评级测试。如果一项测试很可能会教给我们一些我们不了解的软件知识，那么它将具有很高的信息价值。极有可能确认我们已经期望并且已经被多次证明的测试的信息价值较低。确定测试优先级的一种方法是先运行较高的信息价值测试，然后再进行较低的信息价值测试。

如果我过分简化了优先顺序，以便引起对软件测试一无所知的程序员，项目经理或流程经理的注意，我会说：“设计漏洞的测试是浪费时间。 。” 这不是一个完美的翻译，但是对于无法或不会理解任何细微之处或资格的读者而言，这将是接近的。

那时，我再次在这里看到它，一些不了解测试的人会回答说，与测试主要功能的主要用途相比，设计用于查找极端情况的测试是浪费时间。他们不明白两件事。首先，当测试人员抽出时间检查边界值时，已经对主要功能的主要用途进行了几次练习。（是的，有例外，大多数测试组会仔细注意这些例外。）其次，使用极值进行测试的原因是程序极有可能因极值而失败。如果它在极端情况下没有失败，则可以进行其他测试。这是一个有效的规则。另一方面，如果确实失败，则测试人员可能会停止并报告错误，或者测试人员可能会进一步排除故障，看看程序是否以相同的方式在更多正常值下失败。谁进行故障排除（测试人员或程序员）是企业文化的问题。一些公司为此花费了测试人员的时间预算，一些程序员则预算了他们的预算，而有些公司则希望程序员修复极端情况的bug，无论它们是否可以推广，以使故障排除不相关。常见的误解是，测试人员通过测试极端值在浪费时间（而不是最大化效率）是另一个原因，即“没有设计出能够发现错误的测试就是浪费时间”，这对于测试人员来说是适当的信息。这与一些程序员的鼓励相反（实际上）是从不运行可能挑战程序的测试。该消息过分简化，但整个讨论过分简化。

顺便说一句，“信息值”不能是唯一的优先级系统。设计单元测试套件时，这不是我的规则。设计构建验证测试（也称为健全性检查）时，这不是我的规则。在这两种情况下，我对覆盖率的类型都比对单个测试的功能更感兴趣。在其他情况下（例如，大量的自动化测试，安装，运行和监控成本低廉），单个测试的功能与我的设计完全无关。我相信您可以想到其他示例。

但是作为一般规则，如果我只能说一个规则（例如，与一名执行官交谈，如果他想处理多个句子，其主管就会爆炸），那将是信息价值低的测试通常是在浪费时间。

根据Kaner所说，这个想法是“由于在用完测试用例之前会用尽时间，因此必须尽可能有效地利用可用时间。”

Cem Kaner，Jack Falk和Hung Quoc Nguyen 在“ 测试计算机软件”文章中的“测试的目标和限制”一章中，详细介绍了要问的报价背后的概念：

所以，为什么要测试？

您找不到所有错误。您不能证明程序正确，也不想这样做。它昂贵，令人沮丧，并且没有赢得任何人气竞赛。那么，为什么要打扰测试呢？

测试程序的目的是查找其中的问题

发现问题是您工作的核心。您应该希望找到尽可能多的内容。问题越严重越好。

由于在用完测试用例之前会用完时间，因此必须尽可能有效地利用可用时间。第7、8、12和13章详细讨论了优先级。指导原则可以简单地说：

---

揭示问题的测试就是成功。没有发现问题的测试是在浪费时间。

---

考虑一下下面的类比，取自Myers（1979）。假设您出了点问题。你去看医生。他应该进行测试，找出问题所在，并提出纠正措施。他一次又一次的测试。最后，他找不到任何错误。他是一名出色的测试员还是一名无能的诊断专家？如果您真的病了，他就是无能的，而所有这些昂贵的检查都是在浪费时间，金钱和精力。在软件中，您是诊断专家。该程序是（肯定）患病的病人...

您会发现，以上几点是您应该明智地确定测试的优先级。测试预计将花费有限的时间，并且不可能在给定的时间内测试所有内容。

想象一下，您花了一天（一周，一个月）来运行测试，没有发现任何错误，并且漏掉了一些错误，因为您没有时间运行可以揭示它的测试。如果发生这种情况，您不能仅仅说“这不是我的错，因为我正忙于运行其他测试”来证明这种遗漏是正确的-如果您这样说，您仍将承担责任。

您浪费了时间运行没有发现错误的测试，因此，您错过了一个可以发现错误的测试。

^{（如果您不知道的情况下，像上面失误通常是不可避免的，无论你如何尝试，并有有办法对付这些，但是这将是一个多为SQA一个单独的问题，话题......，可能更适合。 SE。）}

好吧，我不认识坎纳先生，但是恕我直言

可能不会发现错误的测试

浪费时间。这包括您已经有一些测试的情况（测试是自动的还是仅存在于清单上都没有关系），并且您添加了新的测试，这些测试实质上验证了您已经拥有的相同案例。因此，您的新测试不会发现比现有测试更多的错误。

例如，如果您只是随机选择一个列表（我也可以“无脑地”说（请原谅我这个词）），则可以在您的程序中选择测试用例，而不考虑它们是否检查新的边缘用例，新的等效性输入数据的类别，或者它们是否增加了相对于已编写测试的代码覆盖率。

在我看来，此引用是指过于笼统或不可靠的测试。

如果您对验证电子邮件的功能进行测试，而在测试中您仅提供有效的电子邮件，则该测试完全没有用。您将必须测试此功能是否适用于任何可能的字符串，无效的电子邮件，过长的电子邮件，unicode字符（áêñç....）

如果您编写一个仅检查name@dom.com返回true且name @ com返回false的测试，则该测试与没有测试完全相同。