Android Tutorial sul test dell'APP con Framework di automazione

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 investi nella progettazione e nell'implementazione, gli errori sono inevitabili e appariranno dei bug.

Android Strategia di test

Una corretta strategia di test Android dovrebbe includere quanto segue

1. Test unitario
2. Prova di integrazione
3. Operaprova nazionale
4. test del sistema

Test unitari

I test unitari includono set di uno o più programmi progettati per verificare un'unità atomica del codice sorgente, come un metodo o una classe.

Android la piattaforma è preintegrata giunzione quadro 3.0. È un framework open source per l'automazione Test unitari. Android Testing Framework è un potente strumento per gli sviluppatori per scrivere l'efficace programma di unit test.

Un'aggiunta allo unit test sono i test dell'interfaccia utente (UI). Questi test riguardano i componenti dell'interfaccia utente dell'applicazione di destinazione. I test dell'interfaccia utente garantiscono che l'applicazione restituisca l'output dell'interfaccia utente corretto in risposta alla sequenza di azioni dell'utente sul dispositivo.

Il modo comune per eseguire i test dell'interfaccia utente sul dispositivo è Android Strumentazione. Ma questo ha problemi di prestazioni. Uno dei migliori strumenti per condurre test dell'interfaccia utente Android is Robotio.

Test di integrazione

In Test d'integrazione, tutti i moduli testati sull'unità, sono combinati e verificati. In Android, i test di integrazione spesso implicano la verifica dell'integrazione conAndroid componenti come test del servizio, test delle attività, test del fornitore di contenuti, ecc

Esistono molti framework di test utilizzati per condurre test di integrazione Android come Troyd, Robolectric, Robotium.

Operaprove nazionali

• Operasono anche chiamati Test Funzionali o Test di Accettazione. Sono test di alto livello volti a verificare la completezza e la correttezza dell'applicazione.
• In Android, fitness è un framework open source che semplifica la conduzione di test operativi per l'applicazione target.

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 Visualizzazione della traccia su cui condurre test delle prestazioni Android .Questo strumento può aiutarti a eseguire il debug della tua applicazione e a profilarne le prestazioni.

TEST ANDROID automatizzati

Poiché Android è frammentato, è necessario testare su una moltitudine di dispositivi. Ma questo ti costerà anche denaro. Automatizzato Android I test possono aiutare a ridurre i costi

Vantaggi dei test Android automatizzati

• 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 applicazione è Android struttura di test. È un framework di test potente e facile da usare, ben integrato con Android Strumenti dell'SDK.

1. Pacchetto dell'applicazione è l'applicazione di destinazione che deve essere testata
2. StrumentazioneTestRunner Europe è Test Case runner che esegue il test case sull'applicazione di destinazione. Include:

2) Strumenti di prova: Uno strumento SDK per la creazione di test. Sono integrati in Eclipse IDE o esegui come riga di comando.

2b) ScimmiaRunner: Uno strumento che fornisce API per scrivere programmi che controllano un file Android dispositivo o emulatore al di fuori di Android codice.

3. Pacchetto di prova sono organizzati in progetti di prova. Questo pacchetto segue la convenzione di denominazione. Se l'applicazione in prova ha il nome del pacchetto "com.mydomain.myapp", il pacchetto test dovrebbe essere "com.mydomain.myapp.test". Il pacchetto test include 2 oggetti come di seguito:

3a) Classi dei casi di test: includono metodi di test da eseguire sull'applicazione di destinazione.

3b) Oggetti simulati: include dati simulati che verranno utilizzati come input di esempio per i casi di test.

Android Classi dei casi di test

1. Caso di prova inclusi JUnit metodi per eseguire JUnit test
2. Suite di prova viene utilizzato per eseguire una serie di casi di test
3. StrumentazioneTestSuite è una TestSuite che inserisce la strumentazione in InstrumentationTestCase prima di eseguirla.
4. StrumentazioneTestRunner è il runner del test case che esegue il test case sull'applicazione di destinazione.
5. AndroidCaso di prova si estende JUnit Caso di prova. Contiene metodi per accedere a risorse come Activity Context.
6. ApplicationTestCase verifica le classi dell'Applicazione in un ambiente controllato.
7. StrumentazioneTestCase verifica una particolare funzionalità o comportamento dell'applicazione di destinazione, ad esempio, verifica l'output dell'interfaccia utente dell'applicazione.
8. ActivityTestCase è la classe base che supporta il test delle attività dell'applicazione.
9. ProviderTestCase è la classe per testare un singolo ContentProvider.
10. ServiceTestCase viene utilizzato per testare le classi di servizio nell'ambiente di test. Supporta inoltre il ciclo di vita del servizio.
11. SingeLauchActivityTestCase viene utilizzato per testare una singola attività con un InstrumentationTestCase.
12. ActivityUnitTestCase viene utilizzato per testare una singola attività isolata.
13. AttivitàStrumentazioneTestCase2 estende l' JUnit Classe TestCase. Ti collega all'applicazione target con la strumentazione. Con questa classe è possibile accedere al componente GUI dell'applicazione e inviare un evento dell'interfaccia utente (pressione di un tasto o evento tocco) all'interfaccia utente.

Di seguito è riportato un esempio di ActivityInstrumentationTestCase. Verifica il funzionamento dell'interfaccia utente dell'applicazione Calcolatrice, controlla la correttezza degli output dell'interfaccia utente.

Quadro di test Robolectric

Testare utilizzando Android Testare il framework con un dispositivo o un emulatore è difficile. La creazione e l'esecuzione dei test sono lente e richiedono molto impegno di sviluppo. Per risolvere questo problema, c'è un'altra scelta: Roboelettrico quadro di prova.

Il framework Robolectric ti consente di correre Android test direttamente su JVM senza la necessità di un dispositivo o di un emulatore.

Classi di casi di test Robolectric

• Come mostrato sopra, Robolectric può eseguire le seguenti azioni:
• Registrati e crea una classe Shadow
• Intercettare il caricamento di Android classe
• Utilizza Javaassist per sovrascrivere i corpi del metodo di Android classe
• Associa l'oggetto Ombra a Android classe
• Ciò consente al codice sotto test di essere eseguito senza Android ambiente.

Altri test quadro

Oltre ai framework di test menzionati sopra, esistono molti altri framework di test come:

• 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 aziende 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… basta il test sugli emulatori

Cominciamo con un semplice esempio. Un'applicazione funziona perfettamente sugli emulatori ma su alcuni dispositivi reali si blocca durante l'esecuzione

Gli emulatori lo sono non sufficiente per i tuoi test mobili. Devi testare la tua app su dispositivi reali.

Mito n.2: è sufficiente eseguire test su alcuni dispositivi comuni

• Su dispositivi diversi, la tua applicazione ha un aspetto diverso perché dispositivi diversi hanno hardware, dimensioni dello schermo, memoria ecc. diversi. Devi testare la tua applicazione su dispositivi, versioni del sistema operativo, reti di operatori e posizioni diversi.

Mito n. 3: i test esplorativi appena prima del lancio sono sufficienti

• Generalmente in tutti i test, progettiamo i casi di test e poi li eseguiamo. Ma nei test esplorativi, la progettazione e l'esecuzione dei test verranno eseguite tutte insieme.
• Nei test esplorativi non esiste un piano né una preparazione, quindi il tester eseguirà i test che desidera eseguire. Alcune funzioni verranno testate ripetutamente, mentre altre non verranno testate completamente.

Mito n. 4: Se ci sono dei bug nell'applicazione, gli utenti capiranno

• Se l'applicazione non funziona e presenta bug, gli utenti disinstallano la tua app
• I problemi di qualità sono il primo motivo di una recensione negativa su Google Play. Ne risente la tua reputazione e perdi la fiducia dei clienti.

Pertanto è essenziale disporre di un'adeguata strategia di test Android

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 dovrebbero essere archiviati nel controllo di versione insieme al codice sorgente
• Utilizza l'integrazione continua ed esegui test ogni volta che il codice viene modificato
• Evitare l'uso di emulatori e dispositivi rooted