突變測試

最近，我反復提到“突變測試”一詞。 因為可以說這種方法能夠以超出代碼覆蓋范圍的方式檢測測試安全網的空白，所以我花了一些時間來追趕這個話題，然后嘗試一下。 這篇文章總結了我的發現，作為對該主題的快速介紹。

什么是變異測試？

變異測試評估現有軟件測試的質量。 想法是以較小的方式修改(變異)測試所涵蓋的代碼，并檢查現有測試集是否將檢測并拒絕更改[MUTTES]。 如果不符合，則意味著測試不符合代碼的復雜性，并且其一個或多個方面未經測試。

在Java中，將變量視為與原始代碼相比具有單個修改的附加類。 可能是如下所示的if子句中邏輯運算符的更改。

if( a && b ) {...} => if( a || b ) {...}

通過現有測試檢測并拒絕這種修飾稱為殺死突變體。 當然，有了完善的測試套件，沒有任何類別的變異體能夠生存。 但是創建所有可能的變體的成本很高，這就是為什么在現實世界中手動執行此方法不可行的原因。

幸運的是，有一些工具可以即時創建突變體，并針對每個突變體自動運行所有測試。 變異創建基于一組所謂的變異算子，這些變異算子用于揭示典型的編程錯誤。 在上面的示例中將采用的一個稱為條件突變算子。

使用JUnit進行測試

使用JUnit進行測試是Java開發人員可以學習的最有價值的技能之一。 無論您的背景是什么，無論您是只是想建立一個安全網以減少桌面應用程序的退化，還是要基于健壯且可重用的組件來提高服務器端的可靠性，都需要進行單元測試。

弗蘭克(Frank)寫了一本書，為使用JUnit進行測試的基本知識提供了深刻的切入點，并為您準備了與測試有關的日常工作挑戰做好了準備。

學到更多…

它與代碼覆蓋率有何關系？

正如馬丁·福勒(Martin Fowler)所說， “測試覆蓋率是查找代碼庫中未經測試的部分的有用工具”。 這意味著覆蓋率不佳表明測試套件的安全網中存在令人擔憂的漏洞。 但是，僅覆蓋范圍就不能證明基礎測試的質量！ 得出的唯一合理結論是，顯然沒有發現斑點。

為了闡明這一點，例如，考慮一組測試，這些測試完全省略了驗證階段。 盡管這樣的捆綁包可能會實現完整的代碼覆蓋，但是從質量保證的角度來看，這顯然是毫無用處的。 這就是突變測試起作用的地方。

測試套件殺死的突變體越多，生產代碼的行為被良好構想并被可靠測試完全覆蓋的機會就越大。 聽起來誘人？ 然后，讓我們繼續看一個例子，以了解實際應用。

如何使用？

我們從我從《用JUnit測試》一書中借來的清單開始，然后針對實際上下文對其進行一些修改。 例如，可以將時間軸視為UI控件的模型組件，該控件可以按時間順序顯示列表條目，例如Twitter界面。 在此階段，我們只關心狀態變量fetchCount ，其初始值可以通過正整數來調整。

public class Timeline {static final int DEFAULT_FETCH_COUNT = 10;private int fetchCount;public Timeline() {fetchCount = DEFAULT_FETCH_COUNT;}public void setFetchCount( int fetchCount ) {if( fetchCount <= 0 ) {String msg = "Argument 'fetchCount' must be a positive value.";throw new IllegalArgumentException( msg );}this.fetchCount = fetchCount;}public int getFetchCount() {return fetchCount;} }

盡管這里沒有什么復雜的，但是我們對下面的測試用例感到放心(讓我們使用JUnit內置org.junit.Assert類的各種assert方法進行驗證)，為了簡化起見，使用了靜態導入)。

public class TimelineTest {private Timeline timeline;@Beforepublic void setUp() {timeline = new Timeline();}@Testpublic void setFetchCount() {int expected = 5;timeline.setFetchCount( expected );int actual = timeline.getFetchCount();assertEquals( expected, actual );}@Test( expected = IllegalArgumentException.class )public void setFetchCountWithNonPositiveValue() {timeline.setFetchCount( 0 );} }

確實，在使用EclEmma收集覆蓋率數據的同時運行測試會產生完整的覆蓋率報告，如下圖所示。

可能您已經檢測到了弱點。 但是，讓我們天真地玩，忽略地平線上的烏云，然后繼續進行突變測試。 我們將PIT用于此目的，因為它似乎是該領域中最受歡迎和最活躍的工具。 其他可能性是μJava和Jumble 。

PIT支持命令行執行， Ant和Maven構建集成以及第三方產品的IDE和報告集成。 有關各種使用方案的更多詳細信息，請參閱相應的在線文檔。

生成的針對特定項目的變異測試HTML報告包含程序包細分，并且可以深入到類級別。 下圖顯示了時間軸組件的類列表報告。 下面，同一報告在Eclipse IDE中顯示為結構樹。

太震驚了！ 我們對高覆蓋率的信心是一種錯覺。 如您所見，該報告列出了將哪些突變應用于哪一行。 同樣，請記住，對于每個突變，將執行一個單獨的測試運行，包括所有測試！ 帶綠色下劃線的列表條目表示被殺死的突變體，而紅色的表示幸存者。

仔細檢查后，很快就會知道我們錯過了什么。 我們通過在測試用例中添加初始狀態驗證來解決此問題，如以下代碼片段所示(請注意Timeline.DEFAULT_FETCH_COUNT的靜態導入)。

public class TimelineTest {[...]@Testpublic void initialState() {assertEquals( DEFAULT_FETCH_COUNT, timeline.getFetchCount() );}[...] }

就是這個！ 現在，突變測試運行會殺死所有突變體。 下圖顯示了一份報告，其中列出了所有報告。

很難相信為這么小的一類人創造的突變數量。 9個突變體僅需22條指令！ 這將我們引到本文的最后一部分。

缺點是什么？

上游覆蓋率分析，動態創建突變體以及所有必要的測試運行都需要花費大量時間。 我將突變測試納入了完整的時間線示例應用程序的構建過程中，該應用程序包含一個包含約350個測試的套件。 與常規運行相比，這將執行時間增加了四倍。

有了這些數字，很明顯，出于實際原因，變異測試運行無法像單元測試運行那樣頻繁地執行。 因此，重要的是找到一種合適的工作流程，該工作流程應在早期反饋和效率方面提供最佳折衷方案。 對于大型軟件系統，這可能意味著突變測試運行可能更好地限于夜間構建等。

現場測試中出現了另一個問題，表明PIT可能會遇到基礎技術堆棧[STAPIT]的麻煩。 就我而言，似乎不支持用于基于枚舉的參數化測試的Burst JUnit測試運行器。 因此，特定類別的所有突變都可以幸免。 但是手動復制證明了這些結果是錯誤的。 因此，您要么不用麻煩的技術，要么將PIT配置為排除麻煩的測試用例。

概要

這篇文章簡要介紹了突變測試。 我們已經了解了什么是測試突變體，突變體的殺滅率如何說明現有測試套件的質量，以及該測試技術與代碼覆蓋率之間的關系。 此外，我們已經了解了如何使用該領域最流行的工具PIT，并對一些執行報告進行了評估。 考慮到從現場測試中得出的一些缺點，得出了本主題的結論。

總之，變異測試似乎是對基于自動化測試的質量保證工具集的有趣補充。 正如開頭提到的那樣，我對這個話題還很陌生，因此，從更高級的用戶那里聽到他們可能錯過或遺忘的經驗和方面會很有趣。

參考文獻

• [MUTTES]：突變測試，Wikipedia， https ：//en.wikipedia.org/wiki/Mutation_testing
• [STAPIT]：JUnit測試通過了，但是…，Stackoverflow， http ：//stackoverflow.com/questions/30789480/
• [TESCOV]：TestCoverage，Fowler， http ：//martinfowler.com/bliki/TestCoverage.html

翻譯自: https://www.javacodegeeks.com/2015/10/what-the-heck-is-mutation-testing.html

突變測試

總結

以上是生活随笔為你收集整理的突变测试_什么是突变测试？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。