Android Tutorial sul test delle app con framework di automazione
Team editoriale
⚡ Riepilogo intelligente
Android Il test delle app verifica una build su un panorama di dispositivi frammentato, combinando controlli unitari, di integrazione, operativi e di sistema con framework di automazione che vengono eseguiti su un dispositivo o direttamente sulla JVM.
Perché Android Prove?
Android è il più grande sistema operativo al mondo. Allo stesso tempo, Android è frammentato: ci sono tonnellate di dispositivi e Android versioni con cui la tua app deve essere compatibile.
Non importa quanto tempo si investa nella progettazione e nell'implementazione, gli errori sono inevitabili e i bug compariranno.
Android Strategia di test
un corretto Android La strategia di test dovrebbe includere quanto segue:
- Test unitario
- Prova di integrazione
- Operaprova nazionale
- test del sistema
Test unitari
I test unitari sono insiemi di programmi progettati per verificare un'unità atomica di codice sorgente, come un metodo o una classe.
Migliori Android la piattaforma viene fornita pre-integrata con JUnit Framework 3.0. È un framework open source per l'automazione Test unitarie consente agli sviluppatori di scrivere programmi di test unitari efficaci.
Oltre ai test unitari, i test dell'interfaccia utente (UI) rappresentano un'aggiunta fondamentale. Essi coprono i componenti dell'interfaccia utente dell'applicazione di destinazione e garantiscono che essa restituisca l'output corretto per una sequenza di azioni dell'utente sul dispositivo.
Il modo comune per eseguire test dell'interfaccia utente su un dispositivo è Android Strumentazione. Ma questo ha problemi di prestazioni. Uno dei migliori strumenti per condurre test dell'interfaccia utente Android is Robotium.
⚠️ Nota sulla versione: JUnit 3 classi come StrumentazioneTestCase sono stati deprecati all'API 24; i progetti attuali utilizzano AndroidTest X, Espresso e UI Automator. Robotium non è stato pubblicato nulla dal 2016.
Test di integrazione
In Test d'integrazione, tutti i moduli testati a livello di unità vengono combinati e verificati. In Android Ciò spesso implica la verifica dell'integrazione con componenti quali il test di Service, Activity e Content Provider.
Molti framework di test vengono utilizzati per condurre test di integrazione per Android, come Troyd, Robolectric e Robotium.
Operaprove nazionali
OperaI test di accettazione, detti anche test funzionali o di accettazione, sono test di alto livello che verificano la completezza e la correttezza dell'applicazione.
In Android, fitness è un framework open-source che semplifica l'esecuzione di test operativi sull'applicazione di destinazione.
Prove di sistema
In Test di sistema il sistema viene testato nel suo complesso e viene verificata l'interazione tra i componenti, software e hardware.
In Android, Il test del sistema normalmente include
- Test della GUI
- Test di usabilità
- Test delle prestazioni
- Prove di stress
Nell'elenco sopra, Test di Performance viene data maggiore attenzione. Puoi usare strumenti come Tracvista condurre test di prestazione su AndroidQuesto strumento può aiutarti a eseguire il debug della tua applicazione e a profilarne le prestazioni. Traceview è ora deprecato a favore di Profiler CPU.
Automatizzata Android Collaudo
As Android è frammentato, è necessario testare su molti dispositivi e questo costa denaro. Automatizzato Android I test contribuiscono a ridurre tali costi.
Vantaggi dell'automazione Android analisi
- Ridurre il tempo per l'esecuzione dei casi di test
- Aumenta la produttività del tuo processo di sviluppo
- Rilevamento tempestivo dei bug, risparmio sui costi di manutenzione del software
- Individuato e corretto rapidamente i bug sull'implementazione
- Garantire la qualità del software
Studieremo i seguenti 2 framework
- Android Quadro di prova
- Struttura di test Robolectric
Android struttura di test
Uno dei framework di test standard per Android le applicazioni sono le Android framework di test. È ben integrato con il Android Gli strumenti SDK e la loro architettura sono composti da tre parti.
- Il pacchetto applicativo è l'applicazione di destinazione che deve essere testata.
- InstrumentationTestRunner è il Test Case Runner che esegue i casi di test sull'applicazione di destinazione. Include:
- Strumenti di prova: Strumenti SDK per la creazione di test. Sono integrati nell'IDE o eseguibili dalla riga di comando.
- ScimmiaRunner: Uno strumento che fornisce API per la scrittura di programmi che controllano un Android dispositivo o emulatore al di fuori di Android codice.
- Il pacchetto di test è organizzato in progetti di test e segue una convenzione di denominazione. Se l'applicazione da testare ha un nome di pacchetto "com.mydomain.myapp", il pacchetto di test dovrebbe essere "com.mydomain.myapp.test". Il pacchetto di test include 2 oggetti:
- Classi di casi di test: includere metodi di test da eseguire sull'applicazione di destinazione.
- Oggetti fittizi: includere dati fittizi che verranno utilizzati come input di esempio per i casi di test.
Android Classi dei casi di test
- Il caso di test include JUnit metodi per eseguire JUnit test
- TestSuite viene utilizzato per eseguire una serie di casi di test
- InstrumentationTestSuite è una TestSuite che inietta la strumentazione in InstrumentationTestCase prima di eseguirli.
- InstrumentationTestRunner esegue i casi di test sull'applicazione di destinazione.
- AndroidTestCase estende JUnit TestCase con metodi per accedere a risorse come Activity Context.
- ApplicationTestCase verifica le classi dell'applicazione in un ambiente controllato.
- InstrumentationTestCase verifica una particolare funzionalità o comportamento, ad esempio l'output dell'interfaccia utente dell'applicazione.
- ActivityTestCase è la classe base che supporta il test delle attività dell'applicazione.
- ProviderTestCase è una classe per testare un singolo ContentProvider.
- ServiceTestCase esegue test sulle classi Service in un ambiente di test e supporta il ciclo di vita del servizio.
- SingleLaunchActivityTestCase viene utilizzato per testare una singola Activity con un InstrumentationTestCase.
- Caso di test dell'unità di attività viene utilizzato per testare singole attività isolate.
- AttivitàStrumentazioneCaso di prova2 estende il JUnit La classe TestCase ti connette all'applicazione di destinazione tramite strumentazione, permettendoti di accedere ai componenti dell'interfaccia utente e inviare eventi come la pressione dei tasti o i tocchi.
Di seguito è riportato un esempio di ActivityInstrumentationTestCase. Verifica il funzionamento dell'interfaccia utente di un'applicazione Calcolatrice e controlla la correttezza degli output dell'interfaccia utente.
Quadro di test Robolectric
Test utilizzando il Android Testare un framework con un dispositivo o un emulatore è difficile. La creazione e l'esecuzione dei test sono lente e richiedono un notevole impegno di sviluppo. Per risolvere questo problema, esiste un'alternativa: il framework di test Robolectric.
Robolectric ti permette di correre Android Esegue i test direttamente sulla JVM senza bisogno di un dispositivo o di un emulatore.
Classi di casi di test Robolectric
Robolectric è in grado di eseguire le seguenti azioni:
- Registrati e crea una classe Shadow
- Intercettare il caricamento di Android classe
- si utilizza Javaassistere per sovrascrivere i corpi del metodo di Android classe
- Associa l'oggetto Ombra a Android classe
Ciò consente l'esecuzione del codice in fase di test senza un Android ambiente.
Altri framework di test
Oltre ai framework di test menzionati sopra, ne esistono molti altri, come ad esempio:
- Android Rapporto Junit, un test runner di strumentazione personalizzata per Android che genera report XML per l'integrazione con altri strumenti.
- Espresso
- Appium
Miti di Android Collaudo
Molte imprese sviluppano Android Collaudo strategie basate su idee sbagliate comuni. Questa sezione esamina alcuni miti e realtà popolari di Android test.
Mito n. 1: Tutti Android I dispositivi sono gli stessi, quindi è sufficiente testare sugli emulatori.
Un'applicazione può funzionare perfettamente sugli emulatori, ma bloccarsi durante l'esecuzione su alcuni dispositivi reali.
Gli emulatori non sono sufficienti per testare la tua app su dispositivi mobili. Devi testarla su dispositivi reali.
Mito n. 2: Testare su alcuni dispositivi comuni è sufficiente
L'aspetto della tua applicazione varia a seconda del dispositivo, poiché hardware, dimensioni dello schermo e memoria differiscono. Esegui dei test su una varietà di dispositivi, versioni del sistema operativo, reti e posizioni geografiche.
Mito n. 3: I test esplorativi appena prima del lancio sono sufficienti
- Nella maggior parte dei test, prima si progettano i casi di test e poi li si esegue; nei test esplorativi, invece, la progettazione e l'esecuzione avvengono simultaneamente.
- Non c'è un piano né una preparazione, quindi il tester esegue i test che preferisce. Alcune funzioni vengono testate ripetutamente, mentre altre non vengono mai testate.
Mito n. 4: Se ci sono dei bug nell'applicazione, gli utenti capiranno
- Se l'applicazione non funziona e presenta dei bug, gli utenti la disinstallano.
- I problemi di qualità sono la prima ragione per cui vengono pubblicate recensioni negative Google Giocare in modo scorretto danneggia la tua reputazione e fa perdere la fiducia dei clienti.
Pertanto è essenziale avere un adeguato Android Strategia di test in atto.
migliori pratiche in Android Collaudo
- Gli sviluppatori di applicazioni dovrebbero creare i casi di test nello stesso momento in cui scrivono il codice
- Tutti i casi di test devono essere archiviati nel sistema di controllo versione, insieme al codice sorgente.
- Utilizza l'integrazione continua ed esegui test ogni volta che il codice viene modificato
- Evita di affidarti solo agli emulatori e ai dispositivi con root; conferma i risultati su hardware reale con un ispettore come uiautomatorviewer
