CTS basato sugli sviluppatori

Questa pagina descrive le linee guida per l'utilizzo di CTS-D (Developer-Powered CTS).

Copertura test

CTS-D, come CTS e CTS Verifier, può applicare solo quanto segue:

  • Tutte le API pubbliche descritte nell'SDK per sviluppatori (developer.android.com) per un determinato livello API.
  • Tutti i requisiti MUST inclusi nel CDD (Compatibility Definition Document) di Android per un determinato livello API.

I requisiti non MUST, come STRONGLY RECOMMENDED, SHOULD, MAY, sono facoltativi e non possono essere testati utilizzando CTS.

Poiché tutti i requisiti delle API e del CDD sono associati a un livello API specifico, tutti i test CTS (CTS, CTS-D e CTS Verifier) sono associati allo stesso livello API delle API o dei requisiti associati. Se un'API specifica è obsoleta o modificata, il test corrispondente deve essere obsoleto o aggiornato.

Regole di creazione dei test CTS

  • Un test deve produrre lo stesso risultato obiettivo in modo coerente.
  • Un test deve determinare se un dispositivo supera o meno il test eseguendolo una sola volta.
  • I creatori dei test devono rimuovere tutti i possibili fattori che potrebbero influire sui risultati dei test.
  • Se un dispositivo richiede una determinata condizione/ambiente/configurazione hardware, questa configurazione deve essere definita chiaramente nel messaggio di commit. Per istruzioni di configurazione di esempio, vedi Configurare CTS.
  • Il test non deve essere eseguito per più di 6 ore alla volta. Se deve essere eseguito per un periodo più lungo, includi la motivazione nella proposta di test in modo che possiamo esaminarla.

Di seguito è riportato un insieme di condizioni di test di esempio per testare una limitazione dell'app:

  • La rete Wi-Fi è stabile (per un test che si basa sulla rete Wi-Fi).
  • Il dispositivo rimane fermo durante il test (o meno, a seconda del test).
  • Il dispositivo è scollegato da qualsiasi fonte di alimentazione con un livello batteria pari a X.
  • Non sono in esecuzione app, servizi in primo piano o servizi in background, ad eccezione di CTS.
  • Lo schermo è spento durante l'esecuzione di CTS.
  • Il dispositivo NON è isLowRamDevice.
  • Il risparmio batteria / le limitazioni delle app non sono stati modificati rispetto allo stato "out-of-the-box".

Idoneità al test

Accettiamo nuovi test che applicano un comportamento non testato dai test CTS, CTS Verifier o CTS-D esistenti. Qualsiasi test che controlli un comportamento al di fuori dell'ambito di copertura dei test verrà rifiutato.

Procedura di invio di CTS

  1. Scrivi una proposta di test: uno sviluppatore di app invia una proposta di test utilizzando Google Issue Tracker, descrivendo il problema identificato e proponendo un test per verificarlo. La proposta deve includere l'ID del requisito CDD associato. Il team Android esamina la proposta.
  2. Sviluppa un test CTS: dopo l'approvazione di una proposta, il mittente crea un test CTS su AOSP nel ramo della release più recente di Android (android17-release). Il team Android esamina il codice e, se accettato, seleziona la modifica e la unisce al ramo di sviluppo interno. Per maggiori dettagli, vedi Dove devo proporre le modifiche ad AOSP?.

Linee guida per la scrittura dei test CTS-D

  • Segui la Guida allo stile del codice Java.
  • Segui tutti i passaggi descritti in Sviluppo CTS.
  • Aggiungi i test al piano di test appropriato:
    • Utilizza include-filters per aggiungere i nuovi test al piano di test CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Utilizza exclude-filters per escludere i nuovi test dal piano di test CTS principale: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Gestisci tutti gli avvisi e i suggerimenti errorprone in build_error.log.
  • Esegui il rebase delle modifiche su head. Sono inclusi i piani di test cts-developer.xml e cts-developer-exclude.xml.
  • Collabora con il tuo contatto di ingegneria Google per determinare se il tuo caso di test può essere incluso in un modulo CTS esistente. In caso contrario, ti aiuterà a creare un nuovo modulo.
  • Per ogni nuovo modulo di test creato, crea un file OWNERS nella directory del nuovo modulo di test.
    • Il file OWNERS deve contenere le seguenti informazioni, ottenute dal proprietario del test Google con cui stai collaborando:
    • # Bug component: xxx
    • LDAP del proprietario del test Google
  • In AndroidTest.xml, specifica i seguenti parametri. Per esempi, consulta i file di esempio (1, 2) per esempi:
    • Instant_app o not_instant_app
    • secondary_user o not_secondary_user
    • all_foldable_states o no_foldable_states
  • Per specificare il minSDK corretto, consulta la documentazione di <uses-sdk>.
  • Quando esegui il check-in di nuovi metodi, classi o moduli di test, aggiungili al piano di test CTS-D ed escludili dal piano di test CTS principale nello stesso modo dei nuovi test.

Esegui il test CTS-D

Esegui il piano di test CTS-D dalla riga di comando utilizzando run cts --plan cts-developer.

Per eseguire un caso di test specifico, utilizza run cts --include-filter "test_module_name test_name".

Per informazioni sull'esecuzione di CTS completo, vedi Eseguire i test CTS.

Accettazione e rilascio

Una volta inviata una richiesta di test, un team interno la esaminerà per assicurarsi che testi un requisito CDD o un comportamento API documentato. Se il test verifica un requisito o un comportamento valido, il team inoltrerà il caso di test a un ingegnere Google per un'ulteriore revisione. L'ingegnere Google ti contatterà per fornirti feedback su come migliorare il test prima che possa essere accettato in CTS.

Per informazioni dettagliate sulla pianificazione delle release di CTS, vedi Pianificazione delle release e informazioni sui rami.