Pakiet zwykle zawiera kilka modułów testowych i może osiągnąć dość duży rozmiar korpusu testowego. Na przykład Android Compatibility Test Suite (CTS) zawiera setki modułów i setki tysięcy przypadków testowych.
Istnieje możliwość, że duża liczba testów zakończy się niepowodzeniem z powodu słabej izolacji lub urządzeń przechodzących w zły stan.
Funkcja ponawiania pakietów ma na celu rozwiązanie tych przypadków: umożliwia ponawianie tylko błędów zamiast pełnych pakietów, aby wykluczyć niestabilność i słabą izolację. Jeśli test stale kończy się niepowodzeniem, ponowna próba również się nie powiedzie; i otrzymujesz znacznie silniejszy sygnał, że istnieje prawdziwy problem.
Ponowna próba pakietu implementacji
Ponowna próba wyników obejmuje odczytanie poprzednich wyników i ponowne uruchomienie poprzedniego wywołania.
Głównym interfejsem sterującym ponowną próbą jest ITestSuiteResultLoader , który umożliwia załadowanie poprzedniego wyniku i poprzedniego wiersza polecenia.
RetryRescheduler następnie używa tych informacji do odtworzenia poprzedniego polecenia i wypełnienia niektórych filtrów w celu ponownego uruchomienia tylko poprzednich niepowodzeń lub niewykonanych testów.
Przykładowe ponowienie zestawu: CTS
Konfiguracja ponawiania w CTS to:
<configuration description="Runs a retry of a previous CTS session.">
<object type="previous_loader" class="com.android.compatibility.common.tradefed.result.suite.PreviousResultLoader" />
<test class="com.android.tradefed.testtype.suite.retry.RetryRescheduler" />
<logger class="com.android.tradefed.log.FileLogger">
<option name="log-level-display" value="WARN" />
</logger>
</configuration>
Dotyczy to większości pakietów, które go rozszerzają, na przykład VTS ).
Zostałby wywołany przez:
cts-tradefed run retry --retry <session>
Sesję można by znaleźć, wyliczając poprzednie wyniki w konsoli CTS:
cts-tf > l r
Session Pass Fail Modules Complete Result Directory Test Plan Device serial(s) Build ID Product
0 2092 30 148 of 999 2018.10.29_14.12.57 cts [serial] P Pixel
Dokładne oryginalne polecenie zostanie ponownie załadowane i ponownie uruchomione z dodatkowymi filtrami. Oznacza to, że jeśli oryginalne polecenie zawierało jakieś opcje, byłyby one również częścią ponownej próby.
Na przykład:
cts-tradefed run cts-dev -m CtsGestureTestCases
Ponowna próba powyższego zawsze byłaby powiązana z CtsGestureTestCases , ponieważ ponawiamy polecenie, które dotyczy tylko tego polecenia.
Skonfiguruj ponowną próbę dla pakietu w stylu CTS
Aby ponowna próba zadziałała, poprzednie wyniki należy wyeksportować w formacie proto. Należy dodać, co następuje:
<result_reporter class="com.android.compatibility.common.tradefed.result.suite.CompatibilityProtoResultReporter" />
Należy to dodać do konfiguracji XML głównego polecenia, co spowoduje utworzenie pliku test-record.pb w folderze wyników.
Ponowna próba CTS następnie ładuje dane z kombinacji test-record.pb i istniejącego test_result.xml , aby przygotować wywołanie ponownej próby.