測試測試？誰看著守望者？

無論您是為大型企業、初創公司還是自己工作，單元測試不僅有用，而且通常是不可或缺的。我們使用單元測試來測試代碼，但是如果我們的測試錯誤或不完整怎麼辦？我們可以用什麼來測試我們的測試？ 誰來監督監察員？

關鍵要點

• 變異測試是一種通過少量修改測試來評估其質量的技術，可用於測試測試本身。它涉及創建原始測試的“變體”或變體，並檢查這些更改是否被測試檢測到。
• 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中文網其他相關文章！