La struttura complessiva della configurazione dei moduli segue uno schema simile alla normale configurazione XML di Tradefed, ma con alcune restrizioni dovute al fatto che vengono eseguiti come parte di una suite.
Elenco di tag consentiti
La configurazione del modulo AndroidTest.xml o più in generale può contenere solo i seguenti tag XML: target_preparer , multi_target_preparer , test e metrics_collector .
Sebbene tale elenco appaia restrittivo, consente di definire con precisione le esigenze di configurazione del modulo di test e il test da eseguire.
NOTA: Consulta la configurazione XML di Tradefed se hai bisogno di un aggiornamento sui diversi tag.
Oggetti come build_provider o result_reporter genereranno un'eccezione ConfigurationException se tentati di essere eseguiti dall'interno di una configurazione del modulo. Questo ha lo scopo di evitare l'aspettativa che questi oggetti eseguano effettivamente alcune attività all'interno di un modulo.
Esempio di configurazione del modulo
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Questa configurazione descrive un test che richiede l'installazione di CtsGestureTestCases.apk ed eseguirà una strumentazione sul pacchetto android.gesture.cts .
Caso speciale per il tag "metrics_collector".
metrics_collector è consentito ma limitato alla classe FilePullerLogCollector per specificare un determinato file o directory da estrarre e registrare per il modulo. Ciò è utile se stai lasciando i registri in una posizione particolare e desideri recuperarli automaticamente.
Esempio di configurazione:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
Che dire delle informazioni sulla build o dei download?
La definizione dei tag consentiti potrebbe dare l'impressione errata che un modulo non riceverà alcuna informazione di build. Questo non è vero .
Le informazioni sulla build vengono fornite dalla configurazione a livello di suite e saranno condivise da tutti i moduli della suite. Ciò consente un'unica configurazione di primo livello per la suite in modo da eseguire tutti i moduli che fanno parte della suite.
Ad esempio, invece di ogni modulo Compatibility Test Suite (CTS) che interroga individualmente le informazioni sul dispositivo, i tipi e così via, l'impostazione a livello di suite CTS ( cts.xml ) lo fa una volta e ogni modulo riceverà tali informazioni se le richiede.
Affinché gli oggetti in un modulo ricevano le informazioni sulla build, devono fare lo stesso della normale configurazione Tradefed: implementare l'interfaccia IBuildReceiver per ricevere IBuildInfo . Vedere test con il dispositivo per maggiori dettagli.
Campi di metadati
Un gran numero di moduli di test include alcune specifiche di metadata , ognuno dei quali ha un obiettivo unico.
Esempio:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
Componente
I metadati del component descrivono il componente Android generale che il modulo intende testare. Non ha alcun impatto diretto sull'esecuzione del test; viene utilizzato principalmente per scopi organizzativi.
L'elenco aggiornato dei componenti consentiti per CTS è disponibile in CtsConfigLoadingTest . Questo test ha esito negativo nel preinvio se un componente non esistente viene aggiunto a un modulo CTS.
È possibile filtrare un'esecuzione della suite in base ai componenti utilizzando module-metadata-include-filter e module-metadata-exclude-filter .
Esempio:
--module-metadata-include-filter component framework
Questo esempio esegue solo il modulo di test annotato con il componente framework .
Parametro
I metadati dei parameter sono informativi e influiscono sull'esecuzione del test. Specifica a quale modalità Android si applica il modulo di test. In questo caso, le modalità sono limitate alle modalità Android di alto livello, come instant apps , secondary users o different abis .
Durante l'esecuzione della suite, se la modalità si applica al test, vengono create diverse varianti del modulo di test in base alla modalità. Ogni variazione esegue test simili ma in modalità diverse.
-
instant_app: crea una variante dei test che installano gli APK come app istantanee. -
multi_abi: Crea una variazione dei test per ogni ABI supportato dal dispositivo. -
secondary_user: crea una variante dei test che installano gli APK ed eseguono i test come utente secondario.