CTS basato sugli sviluppatori

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

Testare la copertura

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 documento CDD (Android Compatibility Definition Document) per un determinato livello API.

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

Poiché tutte le API e i requisiti 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 deprecata o modificata, il test corrispondente deve essere deprecato o aggiornato.

Regole per la creazione dei test CTS

  • Un test deve produrre costantemente lo stesso risultato oggettivo.
  • Un test deve determinare se un dispositivo supera o fallisce testandolo una volta fuori dalla scatola.
  • I creatori dei test devono rimuovere tutti i possibili fattori che potrebbero influenzare i risultati dei test.
  • Se un dispositivo necessita di una determinata condizione/ambiente/configurazione hardware, tale configurazione deve essere chiaramente definita nel messaggio di commit. Per istruzioni di configurazione di esempio, vedere Configurazione di CTS .
  • Il test non deve durare più di 6 ore consecutive. Se è necessario che venga eseguito per un periodo più lungo, includi la motivazione nella proposta di test in modo che possiamo esaminarla.

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

  • Il Wifi è stabile (per un test che si basa sul Wifi).
  • Il dispositivo rimane fermo durante il test (o meno, a seconda del test).
  • Il dispositivo è scollegato da qualsiasi fonte di alimentazione con l'X% del livello della batteria.
  • Nessuna app, servizio in primo piano o servizio in background è in esecuzione, ad eccezione di CTS.
  • Lo schermo è spento durante l'esecuzione di CTS.
  • Il dispositivo NON è isLowRamDevice .
  • Le restrizioni sul risparmio energetico/app non sono state modificate rispetto allo stato "pronto all'uso".

Prova l'idoneità

Accettiamo nuovi test che impongono 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 di 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 del requisito CDD associato. Il team Android esamina la proposta.
  2. Sviluppare un test CTS: dopo che una proposta è stata approvata, il mittente crea un test CTS su AOSP sul ramo principale (AOSP/main). Il team Android esamina il codice.
  3. Pubblica test: invia il tuo CL su AOSP/main e poi selezionalo nell'ultimo ramo androidx-tests-dev . Il test è ora disponibile al pubblico.

Linee guida per la scrittura del test CTS-D

  • Segui la Guida allo stile del codice Java .
  • Seguire tutti i passaggi descritti in Sviluppo CTS .
  • Aggiungi i tuoi test al piano di test appropriato:
    • Utilizza include-filters per aggiungere i tuoi nuovi test al piano di test CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml .
    • Utilizza exclude-filters per escludere i tuoi 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 .
  • Ribasare le modifiche a head . Ciò include i piani di test cts-developer.xml e cts-developer-exclude.xml .
  • Collabora con il tuo contatto tecnico di Google per determinare se il tuo caso di test può essere incluso in un modulo CTS esistente. Se non è possibile, ti aiuteranno a creare un nuovo modulo.
  • Per ogni nuovo modulo di test creato, crea un file OWNERS nella nuova directory del modulo di test.
    • Il tuo file OWNERS dovrebbe 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 specificare i seguenti parametri. Fare riferimento ai 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, fare riferimento alla documentazione <uses-sdk> .
  • Quando si archiviano nuovi metodi, classi o moduli di test, aggiungerli al piano di test CTS-D ed escluderli dal piano di test CTS principale allo 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, utilizzare run cts --include-filter "test_module_name test_name" .

Per informazioni sull'esecuzione del CTS completo, consulta 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 si determina che il test verifica un requisito o un comportamento valido, il team inoltrerà questo test case a un ingegnere di Google per un'ulteriore revisione. L'ingegnere di Google ti contatterà con il tuo feedback su come migliorare il test prima che possa essere accettato nel CTS.

Vedi Programma di rilascio e informazioni sulle filiali per i dettagli sul programma di rilascio CTS.