Zwykle zawiera on kilka modułów testowych i może mieć dość dużą wielkość. Na przykład pakiet testów zgodności z Androidem (Compatibility Test Suite, CTS) obejmuje setki modułów i setki tysięcy przypadków testowych.
W przypadku słabego odseparowania lub nieprawidłowego stanu urządzeń może się zdarzyć, że duża liczba testów zakończy się niepowodzeniem.
Funkcja ponownego próbowania testów ma na celu rozwiązanie takich problemów: umożliwia ponowne próbowanie tylko nieudanych testów zamiast pełnych testów, aby wyeliminować niestabilność i słabą izolację. Jeśli test się nie powiedzie, ponowna próba również się nie powiedzie. Otrzymasz znacznie wyraźniejszy sygnał, że jest to prawdziwy problem.
Implementacja ponownego próbowania zestawu
Ponowne próby uzyskania wyników polegają na odczytaniu poprzednich wyników i ponowym wywołaniu poprzedniego wywołania.
Głównym interfejsem obsługującym ponowne próby jest ITestSuiteResultLoader, który umożliwia załadowanie poprzedniego wyniku i poprzedniego wiersza poleceń.
RetryRescheduler
następnie używa tych informacji do odtworzenia poprzedniego polecenia i wypełnienia niektórych filtrów, aby ponownie uruchomić tylko poprzednie nieudane testy lub niewykonane testy.
Przykładowy powtórzenie zestawu: CTS
Konfiguracja ponawiania w CTS:
<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ą, np. VTS.
Wywołanie nastąpi w ramach:
cts-tradefed run retry --retry <session>
Sesję można znaleźć, wyświetlają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
Zostanie ponownie załadowana i wykonana dokładna pierwotna komenda z dodatkowymi filtrami. Oznacza to, że jeśli pierwotny polecenie zawierało opcje, są one również uwzględniane podczas ponownego próby.
Na przykład:
cts-tradefed run cts-dev -m CtsGestureTestCases
Ponowne wykonanie tego polecenia jest zawsze powiązane z wartością CtsGestureTestCases, ponieważ dotyczy ono tylko tego urządzenia.
Konfigurowanie ponownych prób w przypadku zestawu w stylu CTS
Aby ponowne próby się powiodły, poprzednie wyniki muszą zostać wyeksportowane w formacie proto. Należy dodać te informacje:
<result_reporter class="com.android.compatibility.common.tradefed.result.suite.CompatibilityProtoResultReporter" />
Należy go dodać do konfiguracji XML polecenia głównego, co spowoduje utworzenie w folderze wyników pliku test-record.pb.
CTS retry wczytuje dane z kombinacji test-record.pb i dotychczasowych test_result.xml, aby przygotować wywołanie ponownego próby.