自動化測試用例失敗重跑有助於提高自動化用例的穩定性，那我們來看一下，python和java生態裡都有哪些具體做法？ # 怎麼做 如果是在python生態裡，用pytest做測試驅動，那麼可以通過pytest的外掛pytest-rerunfailures來實現失敗用例重跑，具體的使用方式有兩種，一種是通過命令列指定pytest --reruns 2 --reruns-delay 1，reruns表示重複執行次數，reruns-delay 表示重複執行是的延遲時間。另一種方式是通過@pytest.mark.flaky(reruns=2, reruns_delay=1)，這種方式一般運用，不想全域性所有的測試用例都重跑，只是特定的測試用例需要跑，那就在特定的測試方法上使用這個標記。   如果是在java生態裡，用junit做測試驅動，junit5提供了註解@RepeatTest(2)，可以試下測試類或者測試方法的重複執行，也可以自定義，通過實現個TestRule介面，來控制測試用例的執行。 ``` public class MyTestClass { @Rule public RepeatRule repeatRule = new RepeatRule(); @Test @Repeat(10) public void testMyCode() { //your test code goes here } } import static java.lang.annotation.ElementType.ANNOTATION_TYPE; import static java.lang.annotation.ElementType.METHOD; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention( RetentionPolicy.RUNTIME ) @Target({ METHOD, ANNOTATION_TYPE }) public @interface Repeat { int value() default 1; } import org.junit.rules.TestRule; import org.junit.runner.Description; import org.junit.runners.model.Statement; public class RepeatRule implements TestRule { private static class RepeatStatement extends Statement { private final Statement statement; private final int repeat; public RepeatStatement(Statement statement, int repeat) { this.statement = statement; this.repeat = repeat; } @Override public void evaluate() throws Throwable { for (int i = 0; i < repeat; i++) { statement.evaluate(); } } } @Override public Statement apply(Statement statement, Description description) { Statement result = statement; Repeat repeat = description.getAnnotation(Repeat.class); if (repeat != null) { int times = repeat.value(); result = new RepeatStatement(statement, times); } return result; } } ``` 還有就是如果使用到了maven可以新增一個rerunFailingTestsCount引數，不過這個是控制所有的用例了。 為什麼要讓失敗用例重跑呢 因為自動化一般都會在測試環境或者其他非線上的環境，由於環境的不穩定可能會導致測試用例莫名其妙的失敗，是用例的穩定性大打折扣。這個時候加入失敗重跑機制，能夠在一定範圍內提高測試用例的穩定性，做出更多的產出。 # 什麼樣的自動化用例要進行失敗重跑 介面自動化測試用以建議可以加入這種失敗重跑，而對於UI介面介面自動化，失敗重跑的話，覺得意義不大，因為往往當用例的失敗的時候，要麼是由於介面元素沒加載出來，要麼是用例的邏輯有問題，要麼是意外的彈窗影響，這個時候應該讓錯誤儘早的丟擲來，好儘快的修復，而不是在哪兒一個勁的重試，沒啥用。UI自動化應該做好顯式和隱式等待。 # 什麼樣的失敗用例應該重跑 在測試框架中，最好能區分出什麼樣的異常時服務異常，什麼是測試框架本身的異常，對於服務異常可以適當重試，對於框架異常不進行重跑，直接丟擲。斷言失敗當然更不需要重跑。所以在控制測試用例執行的時候，不要一股腦兒的全都重跑，有選擇性的，既要保證穩定性，還要保證效率，讓自動化發揮價值。 # 總結 測試要做到有的放矢，在合適的時候做合適的事情，自動化測試的價值就是因為它能快速的檢查系統，如果因為重試導致執行的時間成倍增加，是沒有任何意義的，還不如丟擲錯了，儘快去解決。而且自動化測試用例的執行順序也要控制，處於業務前方的介面儘量先跑，處於業務後方的介面儘量後跑。比如登陸介面和下單介面，登陸介面屬於業務靠前的，下單是靠後的，一般在測試下單介面的時候都要初始化登陸狀態，這個時候會呼叫登陸介面，在測試用例批量執行的時候，可以先讓登陸介面測試用例先跑，如果這個介面有問題，那麼其他需要登陸介面配合的用例全都會失敗，那這樣後面的用例就不用跑了，這樣會節省很多的時間。 > 歡迎大家去 [我的部落格](https://www.immortalp.com) 瞅瞅，裡面有更多關於測試實戰的內容哦！！