CTS basato sugli sviluppatori

In questa pagina vengono descritte le linee guida per l'utilizzo dei servizi CTS forniti dallo sviluppatore (CTS-D).

Copertura del test

CTS-D, come CTS e Lo strumento di verifica CTS può applicare solo i seguenti criteri:

  • Tutte le API pubbliche che sono descritte nell'SDK per sviluppatori (developer.android.com) per un determinato livello API.
  • Tutti i requisiti DEVI che sono inclusi nella sezione Compatibilità Android Definition Document (CDD) per un determinato livello API.

I requisiti non DEVI, quali VIVAMENTE CONSIGLIATO, DOVREBBE, MAGGIO, sono facoltativi e non possono essere testati tramite CTS.

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

Regole di creazione del 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 del dispositivo una volta pronta all'uso.
  • Gli autori del test devono rimuovere tutti i possibili fattori che potrebbero influire sui risultati del test.
  • Se un dispositivo ha bisogno di una determinata condizione/ambiente/configurazione hardware, la configurazione deve essere chiaramente definito nel messaggio di commit. Ad esempio, tramite le istruzioni di configurazione, consulta la sezione Configurazione di CTS.
  • Il test non deve essere eseguito per più di 6 ore alla volta. Se deve essere eseguito per includi il ragionamento nella tua proposta di prova per consentirci di esaminarla.

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

  • 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 ci sono app, servizi in primo piano o servizi in background in esecuzione, ad eccezione di CTS
  • Lo schermo è spento durante l'esecuzione di CTS.
  • Il dispositivo NON è isLowRamDevice.
  • Il risparmio energetico e le limitazioni delle app non sono stati modificati dalla stato "pronta all'uso".

Idoneità ai test

Accettiamo nuovi test che applicano un comportamento non testato da CTS esistenti, Verificatore CTS o test CTS-D. Qualsiasi test che verifichi un comportamento che non rientra nell'ambito della nostra copertura del test verrà rifiutata.

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 che è stato identificato e proponendo un test per verificare . La proposta deve includere l'ID requisito CDD associato. Il team di Android esamina la proposta.
  2. Sviluppare un test CTS: dopo l'approvazione di una proposta, l'autore della richiesta crea un CTS su AOSP sul ramo principale (AOSP/main). Il team Android esamina il codice.
  3. Pubblica test: invia il CL su AOSP/main e poi selezionalo nel l'ultimo ramo androidx-tests-dev. Il test è ora disponibile pubblicamente.

Linee guida per la scrittura del test CTS-D

  • Segui la Guida di stile per Java Code.
  • 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 relativi a errorprone in build_error.log.
  • Ripeti le modifiche in head. Sono inclusi i cts-developer.xml e Piani di test cts-developer-exclude.xml.
  • Collabora con il tuo contatto tecnico Google per determinare se lo scenario di test può essere incluso in un modulo CTS esistente. In caso contrario, ti aiuteranno per creare un nuovo modulo.
  • Per ogni nuovo modulo di test creato, crea un file OWNERS nel nuovo modulo di test .
    • Il file OWNERS deve contenere le seguenti informazioni, ottenute da il proprietario del test Google con cui stai lavorando:
    • # Bug component: xxx
    • Proprietario test Google LDAP
  • In AndroidTest.xml, specifica i seguenti parametri. Consulta I file di esempio (1, 2) per alcuni 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, fai riferimento alla documentazione <uses-sdk> documentazione.
  • Quando controlli nuovi metodi, classi o moduli di test, aggiungili al CTS-D ed escludili dal piano di test CTS principale nello stesso modo in cui nuovi test.

Eseguire il test CTS-D

Eseguire 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 test CTS completo, consulta Esecuzione dei test CTS.

Accettazione e rilascio

Una volta inviata la richiesta di test, un team interno la esaminerà per assicurarsi verifica un requisito CDD o un comportamento documentato dell'API. Se il test è determinato di verificare la presenza di requisiti o comportamenti validi, il team inoltrerà questo caso di test a un tecnico Google per un'ulteriore revisione. Il team di il tecnico ti contatterà per fornirti un feedback su come migliorare il test prima di poter essere accettata in CTS.

Consulta: Programma delle release e informazioni sulle filiali per informazioni dettagliate sul programma delle pubblicazioni di CTS.