我在學(xué)習(xí)使用 Evosuite 的時候，寫了一些錯誤的方法。例如其中一個類的方法A直接調(diào)用 interface 的抽象方法B，EvoSuite 生成了一個mock forB來避免案例失?。篿mport org.junit.Test;import static org.junit.Assert.*;import static org.evosuite.shaded.org.mockito.Mockito.*;import MockTest.A;import MockTest.B;import org.evosuite.runtime.EvoRunner;import org.evosuite.runtime.EvoRunnerParameters;import org.evosuite.runtime.ViolatedAssumptionAnswer;import org.junit.runner.RunWith;@RunWith(EvoRunner.class) @EvoRunnerParameters(useVNET = true, separateClassLoader = true, useJEE = true) public class A_ESTest extends A_ESTest_scaffolding { @Test(timeout = 4000) public void test0() throws Throwable { A a0 = new A(); B b0 = mock(B.class, new ViolatedAssumptionAnswer()); doReturn((String) null).when(b0).get(anyInt()); String string0 = a0.test(b0); assertNull(string0); }}對于可能發(fā)生被零除的方法，EvoSuite 生成的測試用例甚至?xí)东@異常以確保測試用例通過：import org.junit.Test;import static org.junit.Assert.*;import static org.evosuite.runtime.EvoAssertions.*;import org.evosuite.runtime.EvoRunner;import org.evosuite.runtime.EvoRunnerParameters;import org.junit.runner.RunWith;import test.Case2;@RunWith(EvoRunner.class) @EvoRunnerParameters(useVNET = true, separateClassLoader = true, useJEE = true) public class Case2_ESTest extends Case2_ESTest_scaffolding { @Test(timeout = 4000) public void test8() throws Throwable { Case2 case2_0 = new Case2(); // Undeclared exception! try { case2_0.add(6, 0); fail("Expecting exception: ArithmeticException"); } catch(ArithmeticException e) { // // / by zero // verifyException("test.Case2", e); } }}EvoSuite 自動生成的測試用例是否總是通過，如這些示例中所示？如何讓 EvoSuite 生成可能失敗的測試用例，從而可以直接供開發(fā)人員使用？
1 回答
一只名叫tom的貓
TA貢獻1906條經(jīng)驗 獲得超3個贊
EvoSuite 自動生成的測試用例是否總是通過，如這些示例中所示？
EvoSuite 站點提供了大量出版物列表，描述了該軟件的理論和操作。然而，將其歸結(jié)為最簡單的術(shù)語，該軟件會生成測試用例，以檢測被測軟件中的突變，這些突變會改變其行為并且不會被現(xiàn)有測試捕獲。因此，被測軟件的實際行為是基線，因此在未修改的軟件上生成的任何測試都不應(yīng)該失敗。
如何讓 EvoSuite 生成可能失敗的測試用例，從而可以直接供開發(fā)人員使用？
我看不出任何軟件都可以做到這一點。EvoSuite 如何將軟件的任何特定行為識別為不正確，從而生成失敗案例？考慮您的除以零示例。當(dāng)被測方法ArithmeticException的第二個參數(shù)為 0 時，它顯然拋出an。EvoSuite 怎么知道這不是方法應(yīng)該做的？
如果軟件可以先驗地辨別出被測代碼應(yīng)該做什么，那么對這一非凡壯舉的更好應(yīng)用就是讓它（重新）編寫實際代碼。
但這并不意味著開發(fā)人員不能使用 EvoSuite 測試。開發(fā)人員至少可以通過以下方式使用它們：
開發(fā)人員可以分析生成的測試以檢測被測軟件表現(xiàn)出的意外行為。這是一件非?？崆矣袃r值的事情，但也許它不適合您“直接”使用測試。
許多測試將正確斷言預(yù)期行為，并且可以在軟件的測試套件中按原樣使用。生成的整體套件將提供比許多軟件更好的回歸保護。
即使斷言不正確行為的測試也可能有用，不是為了提前檢測缺陷，而是在通過其他方式檢測到缺陷后對其進行表征。例如，假設(shè)您從該領(lǐng)域得到一個報告，該方法
widget.frob()拋出了一個意外的UpYoursException，但導(dǎo)致它的情況不清楚。很有可能您的 EvoSuite 測試已經(jīng)顯示了至少一種從受影響的方法中引發(fā)此異常的方法。這可能不符合“直接”使用測試的條件，但這是不嘗試提前清除不正確的自動測試用例（同時不修復(fù)被測代碼）的理由。
底線：EvoSuite 是對手寫測試用例的補充，而不是替代它們。
添加回答
舉報
0/150
提交
取消