海賊王為什么畫風(fēng)突變

最近，我再三提到突變測(cè)試一詞。 因?yàn)榭梢哉f(shuō)這種方法能夠以超出代碼覆蓋范圍的方式檢測(cè)測(cè)試安全網(wǎng)的空白，所以我花了一些時(shí)間來(lái)追趕這個(gè)話題并嘗試一下。 這篇文章總結(jié)了我的發(fā)現(xiàn)，作為對(duì)該主題的快速介紹。

什么是變異測(cè)試？

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

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

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

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

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

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

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

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

學(xué)到更多…

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

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

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

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

如何使用？

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

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

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

確實(shí)，在使用EclEmma收集覆蓋率數(shù)據(jù)的同時(shí)運(yùn)行測(cè)試會(huì)產(chǎn)生完整的覆蓋率報(bào)告，如下圖所示。

可能您已經(jīng)檢測(cè)到了弱點(diǎn)。 但是，讓我們天真地玩，忽略地平線上的烏云，然后繼續(xù)進(jìn)行突變測(cè)試。 我們將PIT用于此目的，因?yàn)樗坪跏窃擃I(lǐng)域中最受歡迎和最活躍的工具。 其他可能性包括μJava和Jumble 。

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

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

太震驚了！ 我們對(duì)高覆蓋率的信心是一種錯(cuò)覺(jué)。 如您所見(jiàn)，該報(bào)告列出了將哪些突變應(yīng)用于哪一行。 同樣，請(qǐng)記住，對(duì)于每個(gè)突變，都將執(zhí)行單獨(dú)的測(cè)試運(yùn)行，包括所有測(cè)試！ 帶綠色下劃線的列表?xiàng)l目表示被殺死的突變體，而紅色的表示幸存者。

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

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

就是這個(gè)！ 現(xiàn)在，突變測(cè)試運(yùn)行會(huì)殺死所有突變體。 下一張圖片顯示了一個(gè)列出所有內(nèi)容的報(bào)告。

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

缺點(diǎn)是什么？

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

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

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

摘要

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

總之，變異測(cè)試似乎是對(duì)基于自動(dòng)化測(cè)試的質(zhì)量保證工具集的有趣補(bǔ)充。 如開始時(shí)提到的，我對(duì)這個(gè)話題還很陌生，因此，從更高級(jí)的用戶那里聽到他們可能錯(cuò)過(guò)或遺忘的經(jīng)驗(yàn)和方面會(huì)很有趣。

參考資料

• [MUTTES]：變異測(cè)試，Wikipedia， https ：//en.wikipedia.org/wiki/Mutation_testing
• [STAPIT]：JUnit測(cè)試通過(guò)了，但是…，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

海賊王為什么畫風(fēng)突變

總結(jié)

以上是生活随笔為你收集整理的海贼王为什么画风突变_什么是突变测试？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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