Una suite tende a includere diversi moduli di test e può raggiungere dimensioni piuttosto elevate del corpus di test. Ad esempio, la Compatibility Test Suite (CTS) di Android include centinaia di moduli e centinaia di migliaia di casi di test.
È possibile che un numero elevato di test non riesca a causa di un isolamento insufficiente o di dispositivi che passano a uno stato errato.
La funzionalità di ripetizione della suite è pensata per risolvere questi casi: ti consente di riprovare solo i fallimenti anziché le suite complete per escludere la variabilità e la scarsa efficacia dell'isolamento. Se un test non va a buon fine in modo coerente, anche il nuovo tentativo non va a buon fine e hai un segnale molto più forte che indica che esiste un problema reale.
Implementa il nuovo tentativo della suite
Il nuovo tentativo dei risultati comporta la lettura dei risultati precedenti e la nuova esecuzione dell'invocazione precedente.
L'interfaccia principale che gestisce il nuovo tentativo è ITestSuiteResultLoader, che consente di caricare un risultato precedente e la riga di comando precedente.
RetryRescheduler
poi utilizza queste informazioni per ricreare il comando precedente e compilare alcuni
filtri al fine di eseguire nuovamente solo i fallimenti precedenti o i test non eseguiti.
Esempio di ripetizione della suite: CTS
La configurazione dei nuovi tentativi in 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>
Questo vale per la maggior parte delle suite che la estendono, ad esempio VTS.
Verrà richiamato con:
cts-tradefed run retry --retry <session>
La sessione viene trovata elencando i risultati precedenti nella console 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
Il comando originale esatto verrà ricaricato ed eseguito di nuovo con filtri aggiuntivi. Ciò significa che se il comando originale includeva alcune opzioni, queste fanno parte anche del nuovo tentativo.
Ad esempio:
cts-tradefed run cts-dev -m CtsGestureTestCases
Il nuovo tentativo di cui sopra è sempre associato a CtsGestureTestCases perché stiamo tentando di nuovo un comando che lo riguardava solo.
Configurare il nuovo tentativo per la suite in stile CTS
Affinché il nuovo tentativo funzioni, i risultati precedenti devono essere esportati in formato proto. È necessario aggiungere quanto segue:
<result_reporter class="com.android.compatibility.common.tradefed.result.suite.CompatibilityProtoResultReporter" />
Questo parametro deve essere aggiunto alla configurazione XML del comando principale e genera un file test-record.pb nella cartella dei risultati.
Il nuovo tentativo CTS carica quindi i dati da una combinazione di test-record.pb e
test_result.xml esistenti per preparare l'invocazione del nuovo tentativo.