Zwykle zawiera ona kilka modułów testowych i może mieć dość duży korpus testowy. Na przykład 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 pakietu
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
używa tych informacji do ponownego utworzenia poprzedniego polecenia i wypełnienia niektórych filtrów, aby ponownie uruchomić tylko poprzednie niepowodzenia lub niewykonane testy.
Ponowna próba wyświetlenia przykładowego pakietu: 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.
Zostanie wywołana w ramach:
cts-tradefed run retry --retry <session>
Sesję można znaleźć, wyświetlając listę poprzednich wyników 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 pierwotne 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" />
Trzeba go dodać do konfiguracji XML polecenia głównego. Spowoduje to utworzenie pliku test-record.pb
w folderze wyników.
CTS retry wczytuje dane z kombinacji test-record.pb
i dotychczasowych test_result.xml
, aby przygotować wywołanie ponownego próby.