自動化測試用例失敗重跑有助於提高自動化用例的穩定性，那我們來看一下，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自動化應該做好顯式和隱式等待。

什麼樣的失敗用例應該重跑

在測試框架中，最好能區分出什麼樣的異常時服務異常，什麼是測試框架本身的異常，對於服務異常可以適當重試，對於框架異常不進行重跑，直接拋出。斷言失敗當然更不需要重跑。所以在控制測試用例執行的時候，不要一股腦兒的全都重跑，有選擇性的，既要保證穩定性，還要保證效率，讓自動化發揮價值。

總結

測試要做到有的放矢，在合適的時候做合適的事情，自動化測試的價值就是因爲它能快速的檢查系統，如果因爲重試導致運行的時間成倍增加，是沒有任何意義的，還不如拋出錯了，儘快去解決。而且自動化測試用例的運行順序也要控制，處於業務前方的接口儘量先跑，處於業務後方的接口儘量後跑。比如登陸接口和下單接口，登陸接口屬於業務靠前的，下單是靠後的，一般在測試下單接口的時候都要初始化登陸狀態，這個時候會調用登陸接口，在測試用例批量執行的時候，可以先讓登陸接口測試用例先跑，如果這個接口有問題，那麼其他需要登陸接口配合的用例全都會失敗，那這樣後面的用例就不用跑了，這樣會節省很多的時間。

歡迎大家去 我的博客 瞅瞅，裏面有更多關於測試實戰的內容哦！！

相關文章