CTS basato sugli sviluppatori

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

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 DEVI che sono inclusi nel Compatibility Definition Document (CDD) di Android per un determinato livello API.

I requisiti NON OBBLIGATORI, come FORTEMENTE CONSIGLIATO, DEVE, PUO, sono facoltativi e non possono essere testati utilizzando CTS.

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

Regole per la creazione di test CTS

  • Un test deve produrre lo stesso risultato oggettivo in modo coerente.
  • Un test deve determinare se un dispositivo supera o meno il test testandolo una volta fuori dalla confezione.
  • I creator dei test devono rimuovere tutti i fattori che potrebbero influire sui risultati dei test.
  • Se un dispositivo richiede una determinata condizione/ambiente/configurazione hardware, questa deve essere chiaramente definita nel messaggio di commit. Per istruzioni di configurazione di esempio, consulta Configurare CTS.
  • Il test non deve essere eseguito per più di 6 ore alla volta. Se dovrà essere pubblicato per un periodo più lungo, includi il ragionamento nella tua proposta di prova per consentirci di esaminarla.

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

  • Il Wi-Fi è stabile (per un test basato su 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 della batteria pari al X percento.
  • Non sono in esecuzione app, servizi in primo piano o servizi in background, ad eccezione di CTS.
  • Lo schermo è spento durante l'esecuzione del CTS.
  • Il dispositivo NON è isLowRamDevice.
  • Le restrizioni per il risparmio energetico / le app non sono state modificate rispetto allo stato "out-of-the-box".

Verificare l'idoneità

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 della nostra copertura dei test verrà rifiutato.

Procedura di invio del CTS

  1. Scrivere una proposta di test: uno sviluppatore di app invia una proposta di test utilizzando Google Issue Tracker, descrivendo il problema che è stato identificato e proponendo un test per verificarlo. La proposta deve includere l'ID requisito CDD associato. Il team di Android esamina la proposta.
  2. Sviluppare un test CTS: dopo l'approvazione della proposta, l'autore crea un test CTS su AOSP nel ramo principale (AOSP/principale). Il team di Android esamina il codice.
  3. Test di pubblicazione: invia il tuo CL su AOSP/main e poi selezionalo per il ramo androidx-tests-dev più recente. Il test è ora disponibile pubblicamente.

Linee guida per la scrittura del test CTS-D

  • Segui la Java Code Style Guide.
  • 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 la 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 stabilire se il tuo caso di test può essere incluso in un modulo CTS esistente. In caso contrario, ti aiuteranno 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 lavorando:
    • # Bug component: xxx
    • Proprietario del test Google ldap
  • In AndroidTest.xml, specifica i seguenti parametri. 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 <uses-sdk>.
  • Quando effettui il check-in di nuovi metodi, classi o moduli di test, aggiungili al piano di test CTS-D e li escludi dal piano di test CTS principale nello stesso modo in cui accade per i nuovi test.

Eseguire 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 del CTS completo, vedi Eseguire i test CTS.

Accettazione e rilascio

Una volta inviata una richiesta di test, un team interno la esaminerà per verificare che test un requisito del CDD o un comportamento dell'API documentato. Se viene stabilito che il test verifica la presenza di un requisito o un comportamento valido, il team inoltra questo caso di test a un ingegnere di Google per un'ulteriore revisione. Il tecnico 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 di CTS, consulta la sezione Pianificazione delle release e informazioni sui branch.