Pakiet składa się zwykle z kilku modułów testowych i może docierać do dużej rozmiar korpusu testowego. Na przykład Compatibility Test Suite (CTS) obejmuje setki modułów i setki tysięcy przypadków testowych.
Duża liczba testów może zakończyć się niepowodzeniem z powodu słabej izolacji lub urządzeń będących w złym stanie.
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
Ponowienie próby polega na odczytaniu poprzednich wyników i ponownym uruchomieniu poprzedniego wywołania.
Główny interfejs powodujący ponowienie próby to ITestSuiteResultLoader
,
który pozwala wczytać poprzedni wynik oraz poprzedni wiersz poleceń.
RetryRescheduler
używa tych informacji do ponownego utworzenia poprzedniego polecenia i wypełnienia niektórych filtrów, aby ponownie uruchomić tylko poprzednie nieudane testy lub niewykonane testy.
Przykładowy pakiet do ponownego testowania: 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. Musisz dodać te elementy:
<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
.
Następnie CTS ponów próbę, a następnie wczytuje dane z kombinacji tych danych: test-record.pb
i
istniejące test_result.xml
, aby przygotować ponowne wywołanie.