自動化測試寫的用例怎樣讓其在執行失敗的時候自動重跑1次或多次呢？

自動化測試用例失敗重跑有助于提高自動化用例的穩定性，那我們來看一下，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接口，來控制測試用例的運行。還有就是如果使用到了maven可以添加一個rerunFailingTestsCount參數，不過這個是控制所有的用例了。為什么要讓失敗用例重跑呢

因為自動化一般都會在測試環境或者其他非線上的環境，由于環境的不穩定可能會導致測試用例莫名其妙的失敗，是用例的穩定性大打折扣。這個時候加入失敗重跑機制，能夠在一定范圍內提高測試用例的穩定性，做出更多的產出。

什么樣的自動化用例要進行失敗重跑

接口自動化測試用例我建議加入這種失敗重跑，而對于UI接口接口自動化，失敗重跑的話，我覺得意義不大，因為往往當用例的失敗的時候，要么是由于界面元素沒加載出來，要么是用例的邏輯有問題，要么是意外的彈窗影響，這個時候應該讓錯誤盡早的拋出來，好盡快的修復，而不是在哪兒一個勁的重試，沒啥用。UI自動化應該做好顯式和隱式等待，這個是提升穩定的關鍵。

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

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

總結

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