CTS basato sugli sviluppatori

Questa pagina descrive le linee guida per l'utilizzo di CTS basato sugli sviluppatori (CTS-D).

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 Compatibility Definition Document (CDD) 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 di 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 una specifica API viene ritirata o modificata, il test corrispondente deve essere ritirato 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 eseguendo il test del dispositivo una volta appena estratto dalla confezione.
  • Gli autori dei test devono rimuovere tutti i possibili fattori che potrebbero influire sui risultati.
  • 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 Configurazione di 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 esempio di insieme di condizioni di test per testare una limitazione dell'app:

  • Il Wi-Fi è stabile (per un test che si basa sul Wi-Fi).
  • Il dispositivo rimane fermo durante il test (o meno, a seconda del test).
  • Il dispositivo è scollegato da qualsiasi fonte di alimentazione con una percentuale di 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 energetico / le limitazioni delle app non sono stati modificati rispetto allo stato di fabbrica.

Verifica dell'idoneità

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

Procedura di invio del 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 requisito CDD associato. Il team Android esamina la proposta.
  2. Sviluppa un test CTS:dopo l'approvazione di una proposta, il suo autore crea un test CTS su AOSP nel ramo dell'ultima release di Android (android16-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 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 di 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 tecnico Google per determinare se il tuo scenario 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 collabori:
    • # Bug component: xxx
    • LDAP del proprietario del test Google
  • In AndroidTest.xml, specifica i seguenti parametri. Fai riferimento ai file di esempio (1, 2) per visualizzare degli esempi:
    • Instant_app o not_instant_app
    • secondary_user o not_secondary_user
    • all_foldable_states o no_foldable_states
  • Per specificare l'SDK minimo 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 uno scenario di test specifico, utilizza run cts --include-filter "test_module_name test_name".

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

Accettazione ed esonero

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

Per informazioni dettagliate sulla pianificazione delle release del CTS, consulta la sezione Pianificazione delle release e informazioni sui rami.