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

什么是變異測試？

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

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

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

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

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

使用JUnit進(jìn)行測試

使用JUnit進(jìn)行測試是Java開發(fā)人員可以學(xué)習(xí)的最有價值的技能之一。 無論您的背景是什么，無論您是只是想建立一個安全網(wǎng)以減少桌面應(yīng)用程序的性能下降，還是要基于健壯且可重用的組件來提高服務(wù)器端的可靠性，都需要進(jìn)行單元測試。

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

學(xué)到更多…

它與代碼覆蓋率有何關(guān)系？

正如Martin Fowler所說的那樣， “測試覆蓋率是查找代碼庫中未經(jīng)測試的部分的有用工具 ”。 這意味著覆蓋率不佳表明測試套件的安全網(wǎng)中存在令人擔(dān)憂的漏洞。 但是，僅覆蓋范圍就不能證明基礎(chǔ)測試的質(zhì)量！ 得出的唯一合理結(jié)論是，顯然沒有發(fā)現(xiàn)斑點。

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

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

如何使用？

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

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;} }

雖然這里沒有什么復(fù)雜的，但是我們對下面的測試用例感到放心（讓我們使用JUnit內(nèi)置的org.junit.Assert類的各種assert方法來進(jìn)行驗證，在這篇文章中使用了靜態(tài)導(dǎo)入來簡化內(nèi)容） ）。

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收集覆蓋率數(shù)據(jù)的同時運行測試會產(chǎn)生完整的覆蓋率報告，如下圖所示。

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

PIT支持命令行執(zhí)行 ， Ant和Maven構(gòu)建集成以及第三方產(chǎn)品的 IDE和報告集成。 有關(guān)各種使用方案的更多詳細(xì)信息，請參閱相應(yīng)的在線文檔。

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

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

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

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

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

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

缺點是什么？

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

有了這些數(shù)字，很明顯，出于實際原因，變異測試運行不能像單元測試運行那樣頻繁地執(zhí)行。 因此，找到合適的工作流程以在早期反饋和效率方面提供最佳折衷是很重要的。 對于大型軟件系統(tǒng)，這可能意味著突變測試運行可能更好地限于夜間構(gòu)建等。

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

摘要

這篇文章簡要介紹了突變測試。 我們已經(jīng)了解了什么是測試突變體，突變體的殺死率如何說明現(xiàn)有測試套件的質(zhì)量，以及該測試技術(shù)與代碼覆蓋率之間的關(guān)系。 此外，我們已經(jīng)了解了如何使用該領(lǐng)域最受歡迎的工具PIT，并對一些執(zhí)行報告進(jìn)行了評估。 考慮到從現(xiàn)場測試中得出的一些缺點，得出了本主題的結(jié)論。

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

參考文獻(xiàn)

• [MUTTES]：突變測試，維基百科， 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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。