Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Configura frammentazione

Questa pagina descrive cosa è possibile ottimizzare per un modulo suite ( AndroidTest.xml ) tramite sharding e ottenere le migliori prestazioni di velocità durante l'esecuzione continua in laboratorio. Tenteremo di descrivere le opzioni in modo generico con la logica di usarle.

Quando si esegue continuamente una suite in laboratorio, la suite viene solitamente suddivisa su più dispositivi per ridurre i tempi complessivi di completamento. L'imbracatura in genere tenta di bilanciare il tempo di esecuzione di ciascun frammento per ridurre al minimo il tempo complessivo di completamento (al termine dell'ultimo frammento); ma a causa della natura di alcuni test, non sempre abbiamo abbastanza introspezione e abbiamo bisogno del proprietario del modulo per ottimizzare alcuni comportamenti.

Shardable o non shardable?

È possibile taggare un modulo ( AndroidTest.xml ) con <option name="not-shardable" value="true" /> per notificare al cablaggio che non deve essere suddiviso.

In un modulo tipico, lasciare che il cablaggio sia frammentato (il comportamento predefinito) è la cosa giusta da fare. Ma in alcuni casi, potresti voler ignorare quel comportamento:

  • Quando l'installazione del modulo è costosa:

La frammentazione di un modulo comporta la preparazione (installazione dell'APK, file push, ecc.) Eventualmente eseguita una volta per dispositivo interessato. Se la configurazione del modulo è lunga e costosa e non vale la pena replicarla rispetto al tempo di esecuzione del test, è necessario contrassegnare il modulo come non frammentabile.

  • Quando il numero di test nel modulo è basso:

La frammentazione di un modulo comporta l'esecuzione di tutti i casi di test in modo indipendente su dispositivi diversi. Questo si riferisce al primo punto; se il tuo numero di test è basso, potresti finire con un singolo test o nessun test in alcuni frammenti, il che renderebbe ogni fase di preparazione piuttosto costosa. L'installazione di un APK per un singolo test case di solito non ne vale la pena, ad esempio.

Test di strumentazione: numero massimo di frammenti?

Un test di strumentazione che esegue AndroidJUnitTest non espone all'imbracatura quanti test fanno parte della strumentazione fino a quando non installiamo ed eseguiamo effettivamente l'APK. Queste operazioni sono costose e non possono essere eseguite al momento dello sharding per tutti i moduli della suite.

L'imbracatura potrebbe frammentare eccessivamente il test di strumentazione e finire con alcuni frammenti vuoti; la divisione di un test di strumentazione con cinque prove in sei frammenti produce cinque frammenti con un test e un frammento senza test. Ognuno di questi frammenti richiederebbe un'installazione APK costosa.

Pertanto, quando il numero di test <option name="not-shardable" value="true" /> del test di strumentazione è basso, contrassegnare il modulo con <option name="not-shardable" value="true" /> consentirebbe all'imbracatura di sapere che il modulo non è utile.

Il corridore AndroidJUnitTest ha un'opzione speciale che consente di specificare il numero massimo di frammenti in cui è consentito frammentare: <option name="ajur-max-shard" value="5" /> .

Ciò consente di specificare un numero massimo di volte in cui la strumentazione può essere suddivisa in frammenti indipendentemente dal numero di frammenti richiesti a livello di invocazione. Per impostazione predefinita, la strumentazione verrà suddivisa nel numero di frammenti richiesti per l'invocazione.

Ad esempio, se l'APK di test della strumentazione contiene solo due casi di test ma si desidera ancora frammentarlo, avere un valore ajur-max-shard pari a 2 garantirebbe di non creare frammenti vuoti.