测试测试？谁看着守望者？

无论您是为大型企业、初创公司还是自己工作，单元测试不仅有用，而且通常是不可或缺的。我们使用单元测试来测试代码，但是如果我们的测试错误或不完整怎么办？我们可以用什么来测试我们的测试？谁来监督监察员？

关键要点

• 变异测试是一种通过少量修改测试来评估其质量的技术，可用于测试测试本身。它涉及创建原始测试的“变体”或变体，并检查这些更改是否被测试检测到。
• Humbug 是一个用于 PHP 的变异测试框架，可用于生成代码覆盖率。但是，它是 PHPUnit 专用的，对于使用不同测试框架的用户来说可能存在问题。
• 变异测试虽然很有价值，但也有其缺点，主要体现在性能方面。由于它依赖于许多因素，例如代码行之间的相互作用、测试数量、代码覆盖率级别以及代码和测试的性能，因此这是一个缓慢的过程。
• 随着应用程序复杂性的增加，保持 100% 代码覆盖率的重要性也随之提高。像 Humbug 这样的工具对于维护这种覆盖率至关重要，尤其是在企业生态系统中。

变异测试

不，不是那种变异。变异测试（或变体分析）是一种用于创建和评估软件测试质量的技术。它包括以非常小的方式修改测试。每个修改后的版本都称为变体，测试通过导致原始版本的行为与变体不同来检测和拒绝变体。变异是原始代码中的错误，分析检查我们的测试是否检测到这些错误。简而言之，如果测试在变异后仍然有效，则它不是一个好的测试。

使用 Humbug 进行变异测试

Humbug 是一个用于 PHP 的变异测试框架。为了使 Humbug 能够生成代码覆盖率，我们必须在我们的机器上安装并启用 XDebug。然后，我们可以将其安装为全局工具。

composer global require 'humbug/humbug'

之后，如果我们运行

humbug

命令，我们应该能够看到一些 Humbug 安装信息和一个指示我们没有 humbug.json 文件的错误。

引导程序

在我们配置和使用 Humbug 之前，我们需要一个可以测试的项目。我们将创建一个小型 PHP 计算器包，在其中运行我们的单元测试和变异测试。让我们创建一个 /Calculator 文件夹。在其中，让我们创建我们的 /src 和 /tests 文件夹。在我们的 /src 文件夹中，我们将拥有我们的应用程序代码；/tests 文件夹将包含我们的单元测试。我们还需要在我们的包中使用 PHPUnit。最好的方法是使用 Composer。让我们使用以下命令安装 PHPUnit：

composer global require 'humbug/humbug'

让我们创建我们的计算器。在 /src 文件夹中，创建一个 Calculator.php 文件并添加以下内容：

humbug

这是一个相当简单的程序。一个简单的计算器，具有基本的算术、百分比和对数运算以及返回 π 值的函数。接下来，在我们的 /tests 文件夹中，让我们为我们的计算器创建单元测试。如果您需要有关 PHP 中单元测试的帮助，请查看本教程。创建一个 CalculatorTest.php 文件并添加以下内容：

composer global require phpunit/phpunit

这将是我们的初始测试堆栈。如果我们运行 phpunit 命令，我们将看到它成功执行，并且我们的 4 个测试和 4 个断言将通过。重要的是所有测试都必须通过，否则 Humbug 将失败。

配置 Humbug

Humbug 可以通过创建 humbug.json.dist 文件手动配置，也可以通过运行以下命令自动配置：

<?php
namespace package\Calculator;

class Calculator {

    /**
     * 基本运算
     */
    public function add($a1, $a2) {
        return $a1 + $a2;
    }

    public function subtract($a1, $a2) {
        return $a1 - $a2;
    }

    public function multiply($a1, $a2) {
        return $a1 * $a2;
    }

    public function divide($a1, $a2) {

        if ($a2 === 0) {
            return false;
        }

        return $a1 / $a2;
    }

    /*
     * 百分比
     */

    // 这将返回 a1 的 a2 百分比
    public function percentage($a1, $a2) {
        return ( $a1 / $a2 ) * 100;
    }

    /*
     * π
     */

    // 返回 π 的值
    public function pi() {
        return pi();
    }

    /*
     * 对数
     */

    // 返回以 10 为底的基本对数
    public function log($a) {
        return log10($a);
    }

}

运行该命令将要求我们回答一些问题：

• 您要包含哪些源目录？ 在此，我们将使用 src/，即我们的源代码目录。
• 您要从源目录中排除哪些目录？ 在某些情况下可能很有用，例如我们不想测试的外部供应商目录。它不适用于我们当前的情况。
• 单个测试套件超时（秒）。让我们在此使用 30 秒。这可能太多了，但我们要确保一切都有足够的时间运行。
• 您想将文本日志存储在哪里？humblog.txt 作为默认值，我们将保留它。
• 您想将 json 日志存储在哪里（如果需要）？默认值为空，但我们将将其存储在 humblogjson.json 中。
• 生成“humblog.json.dist”？此文件生成后将包含我们刚刚提供的全部配置值。如果我们想更改某些内容，可以手动编辑它。

使用 Humbug

现在我们已经运行了应用程序并进行了测试，并且安装了 Humbug，让我们运行 Humbug 并检查结果。

<?php
use package\Calculator\Calculator;

class CalculatorTest extends PHPUnit_Framework_TestCase {

    public function testAdd() {
        $calculator = new Calculator();
        $result = $calculator->add(2, 3);
        $this->assertEquals($result, 5);
    }

    public function testSubtract() {
        $calculator = new Calculator();
        $result = $calculator->subtract(6, 3);
        $this->assertEquals($result, 3);
    }

    public function testMultiply() {
        $calculator = new Calculator();
        $result = $calculator->multiply(6, 3);
        $this->assertEquals($result, 18);
    }

    public function testDivide() {
        $calculator = new Calculator();
        $result = $calculator->divide(6, 3);
        $this->assertEquals($result, 2);
    }

}

结果应该接近于此：

解读 Humbug 结果

创建的变异数量只是 Humbug 引入的小更改的数量来测试我们的测试。被杀死的变异（.）是导致测试失败的变异。不要混淆，这是一个积极的结果！逃逸的变异 (M) 是测试仍然通过的变异。这不是一个积极的结果，我们应该回到我们的测试并检查缺少什么。未覆盖的变异 (S) 是发生在单元测试未覆盖的行中的变异。致命错误 (E) 和超时 (T) 分别是创建致命错误和创建无限循环的变异。

指标呢？

变异得分指标表示检测到的变异百分比。我们的目标是 100%。变异代码覆盖率表示被变异覆盖的测试百分比。变异得分指标可以让您了解现有测试的有效性。分析我们的 humbug 日志，我们可以看到我们有 9 个未覆盖的变异，以及一些非常糟糕的指标。查看 humblogjson.json 文件。此文件与 humblog.txt 文件一样是自动生成的，并包含有关失败原因、位置和原因的更详细的信息。我们没有测试我们的百分比、π 和对数函数。此外，我们需要涵盖将数字除以 0 的情况。让我们添加更多测试来涵盖缺失的情况：

composer global require 'humbug/humbug'

这一次，100% 表示所有变异都被杀死，并且我们具有完整的代码覆盖率。

缺点

变异测试以及 Humbug 的最大缺点是性能。变异测试是一个缓慢的过程，因为它依赖于许多因素，例如代码行之间的相互作用、测试数量、代码覆盖率级别以及代码和测试的性能。Humbug 还进行初始测试运行、日志记录和代码覆盖率，这会增加总持续时间。此外，Humbug 是 PHPUnit 专用的，对于使用其他测试框架的用户来说可能是一个问题。也就是说，Humbug 正在积极开发中，并将继续改进。

结论

Humbug 可能是维护应用程序寿命的重要工具。随着应用程序复杂性的增加，测试的复杂性也会增加——并且始终保持 100% 的测试变得非常重要，尤其是在处理企业生态系统时。本教程中使用的代码可以在这里克隆。您使用过 Humbug 吗？您是否以其他方式进行变异测试？请告诉我们您对此的所有想法！

关于“谁来监督监察员？”的常见问题 (FAQ)

“谁来监督监察员？”这句话的起源是什么？

“谁来监督监察员？”这句话源于拉丁语短语“Quis custodiet ipsos custodes？”，由罗马诗人尤维纳尔创造。这句话经常用于质疑当权者正直性和责任制的讨论中。它基本上是在问：“谁来守护卫兵？”或“谁来监视监视我们的人？”这句话已以各种形式的媒体出现，包括艾伦·摩尔、戴夫·吉本斯和约翰·希金斯创作的流行图画小说系列《守望者》。

在软件测试的背景下，“谁来监督监察员？”这句话是如何使用的？

在软件测试的背景下，“谁来监督监察员？”是一个隐喻性的问题，它解决了测试的可靠性和准确性。它质疑谁或什么正在监控测试以确保它们能够正常运行并产生准确的结果。这是软件开发的一个关键方面，因为它确保了正在开发的软件的质量和可靠性。

在软件开发中测试测试的重要性是什么？

测试测试，也称为测试验证，是软件开发的关键部分。它确保测试能够准确地衡量软件的功能和性能。如果没有测试验证，则存在测试可能产生误报或漏报的风险，从而导致对软件质量和可靠性的不准确评估。

我如何确保我的测试可靠且准确？

确保测试的可靠性和准确性涉及几个步骤。首先，您应该彻底检查您的测试以确保它们设计和实现正确。其次，您应该通过将测试结果与已知结果进行比较来定期验证您的测试。最后，您应该持续监控和更新您的测试，以确保它们在软件发展过程中保持准确性。

软件测试中有哪些常见的陷阱？

软件测试中的一些常见陷阱包括测试不足、测试错误的事物以及不了解测试的目的。其他陷阱包括过分依赖自动化测试而不了解其局限性，以及不定期审查和更新测试。

图画小说《守望者》与软件测试有何关系？

图画小说《守望者》使用“谁来监督监察员？”这句话来质疑当权者的责任制和正直性。在软件测试的背景下，这句话可以用来质疑测试本身的可靠性和准确性。正如“守望者”应该守护社会一样，测试应该守护软件的质量和可靠性。但是，正如“守望者”需要被监视一样，测试也需要被监视。

软件测试人员的角色是什么？

软件测试人员的角色是通过设计和实施测试来确保软件的质量和可靠性。这些测试用于识别和修复错误、验证功能和评估性能。软件测试人员还必须监控和更新这些测试，以确保它们在软件发展过程中保持准确性。

我如何提高我的软件测试技能？

提高您的软件测试技能需要持续学习和实践。您应该了解最新的测试方法和工具，并定期练习设计和实施测试。您还应该寻求对测试的反馈，并乐于从错误中学习。

学习更多关于软件测试的一些好资源是什么？

有很多资源可用于学习更多关于软件测试的知识。这些包括在线课程、书籍、博客和论坛。一些推荐的书籍包括格伦福德·J·迈尔斯著的《软件测试的艺术》、保罗·C·乔根森著的《软件测试：工匠方法》以及塞姆·卡纳、杰克·法尔克和黄·Q·阮着的《测试计算机软件》。

软件测试的未来是什么？

软件测试的未来可能会受到技术进步的强烈影响。这包括在测试中越来越多地使用自动化和人工智能，以及开发新的测试方法以适应虚拟现实和区块链等新兴技术。但是，软件测试的基本原则——确保软件的质量和可靠性——将保持不变。

以上是测试测试？谁看着守望者？的详细内容。更多信息请关注PHP中文网其他相关文章！