Perché Android Testing?
Android è il più grande sistema operativo al mondo. Allo stesso tempo, Android è frammentato. ci sono tantissimi dispositivi e versioni Android 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.
In questo tutorial imparerai-
- Perché Android Testing?
- Strategia di test Android
- Test unitari
- Test di integrazione
- Test operativi
- Test di sistema
- TEST ANDROID automatizzati
- Framework di test Android
- Framework di test Robolectric
- Miti di Android Testing
- Best practice per Android Testing
Strategia di test Android
Una corretta strategia di test Android dovrebbe includere quanto segue
- Test unitario
- Test di integrazione
- Test operativo
- Test di sistema
Test unitari
Gli unit test includono set di uno o più programmi progettati per verificare un'unità atomica di codice sorgente, come un metodo o una classe.
La piattaforma Android include il framework Junit 3.0 preintegrato. È un framework open source per l'automazione di Unit Testing. Android Testing Framework è un potente strumento per gli sviluppatori per scrivere il programma di unit test efficace.
L'integrazione di Android e framework JUnit
Un'aggiunta a Unit Testing sono i test dell'interfaccia utente (UI). Questi test si riferiscono ai componenti dell'interfaccia utente dell'applicazione di destinazione. I test dell'interfaccia utente assicurano che l'applicazione restituisca l'output dell'interfaccia utente corretto in risposta alla sequenza di azioni dell'utente sul dispositivo.
Azioni comuni dell'interfaccia utente utente sull'applicazione
Il modo più comune per eseguire i test dell'interfaccia utente sul dispositivo è Android Instrumentation. Ma questo ha problemi di prestazioni. Uno dei migliori strumenti per condurre test dell'interfaccia utente su Android è Robotium.
Test di integrazione
In Integration Testing, tutti i moduli testati dall'unità vengono combinati e verificati. In Android, i test di integrazione spesso comportano il controllo dell'integrazione con componenti Android come il test del servizio, il test dell'attività, il test del fornitore di contenuti, ecc
Tipi di test di integrazione su Android
Esistono molti framework di test utilizzati per condurre test di integrazione per Android come Troyd, Robolectric, Robotium.
Test operativi
- Operativi sono 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, FitNesse è un framework open source che semplifica l'esecuzione di test operativi per l'applicazione di destinazione.
Test di sistema
In System Testing il sistema viene testato nel suo complesso e viene verificata l'interazione tra i componenti, il software e l'hardware.
In Android, il test di sistema normalmente include
- Test della GUI
- Test di usabilità
- Test delle prestazioni
- Test di stress
Nell'elenco precedente, viene data maggiore attenzione al test delle prestazioni . Puoi utilizzare strumenti come Traceview per condurre test delle prestazioni su Android. Questo strumento può aiutarti a eseguire il debug della tua applicazione e profilarne le prestazioni.
TEST ANDROID automatizzati
Poiché Android è frammentato, è necessario eseguire test su una moltitudine di dispositivi. Ma questo ti costerà anche dei soldi. Il test Android automatizzato può aiutare a ridurre i costi
Vantaggi del test Android automatizzato
- Riduci i tempi di esecuzione dei casi di test
- Aumenta la produttività del tuo processo di sviluppo
- Rilevamento precoce dei bug, risparmio sui costi di manutenzione del software
- Trova e correggi rapidamente i bug durante l'implementazione
- Garantire la qualità del software
Studieremo i seguenti 2 framework
- Framework di test Android
- Framework di test Robolectric
Framework di test Android
Uno dei framework di test standard per l'applicazione Android è il framework di test Android . È un framework di test potente e facile da usare che è ben integrato con gli strumenti di Android SDK.
Architettura del framework di test Android
- Il pacchetto dell'applicazione è l'applicazione di destinazione che deve essere testata
- InstrumentationTestRunner è il runner del test case che esegue il test case sull'applicazione di destinazione. Include:
2a) Strumenti di test: strumenti SDK per la creazione di test. Sono integrati in Eclipse IDE o eseguiti come riga di comando.
2b) MonkeyRunner: uno strumento che fornisce API per la scrittura di programmi che controllano un dispositivo o un emulatore Android al di fuori del codice Android.
- I pacchetti di test sono organizzati in progetti di test. Questo pacchetto segue la convenzione di denominazione. Se l'applicazione sottoposta a test 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 come di seguito:
3a) Classi di casi di test: includono metodi di test da eseguire sull'applicazione di destinazione.
3b) Oggetti fittizi: include dati fittizi che verranno utilizzati come input di esempio per i casi di test.
Classi di casi di test Android
Diagramma di classe AndroidTestCase
- TestCase include metodi JUnit per eseguire il test JUnit
- TestSuite viene utilizzato per eseguire una serie di casi di test
- InstrumentationTestSuite è una TestSuite che inietta la strumentazione in InstrumentationTestCase prima di eseguirli.
- InstrumentationTestRunner è il runner dello scenario di test che esegue lo scenario di test sull'applicazione di destinazione.
- AndroidTestCase estende JUnit TestCase. Contiene 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 dell'applicazione di destinazione, ad esempio, verifica l'output dell'interfaccia utente dell'applicazione.
- ActivityTestCase è una classe base che supporta il test delle attività dell'applicazione.
- ProviderTestCase è una classe per testare un singolo ContentProvider.
- ServiceTestCase viene utilizzato per testare le classi di servizio nell'ambiente di test. Supporta anche il ciclo di vita del servizio.
- SingeLauchActivityTestCase viene utilizzato per testare una singola attività con un InstrumentationTestCase.
- ActivityUnitTestCase
viene utilizzato per testare una singola attività isolata. - ActivityInstrumentationTestCase2
estende la classe JUnit TestCase. Ti connette all'applicazione di destinazione con la strumentazione. Con questa classe è possibile accedere al componente GUI dell'applicazione e inviare un evento dell'interfaccia utente (sequenza di tasti 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.
Esempio di test ActivityInstrumentationTestCase2
Framework di test Robolectric
Il test utilizzando il framework di test Android con un dispositivo o un emulatore è difficile. La creazione e l'esecuzione del test è lento e richiede molto impegno di sviluppo. Per risolvere questo problema, c'è un'altra scelta: il framework di test Robolectric .
Il framework Robolectric ti consente di eseguire test Android direttamente su JVM senza la necessità di un dispositivo o di un emulatore.
Funzionalità avanzate di Robolectric
Classi di casi di test Robolectric
Funzionamento di Robolectric
- Come mostrato sopra, Robolectric può eseguire le seguenti azioni:
- Registrati e crea una classe Shadow
- Intercetta il caricamento della classe Android
- Utilizza javaassist per sovrascrivere i corpi del metodo della classe Android
- Associa l'oggetto Shadow alla classe Android
- Ciò consente al codice sotto test di essere eseguito senza ambiente Android.
Altri testano il framework
Oltre ai framework di test che sono stati menzionati sopra, ci sono molti altri framework di test come:
- Android Junit Report, un test runner di strumentazione personalizzato per Android che genera report XML per l'integrazione con altri strumenti.
- Espresso
- Appium
Miti di Android Testing
Molte aziende sviluppano strategie di test Android basate su idee sbagliate comuni. Questa sezione esamina alcuni popolari miti e realtà dei test Android.
Mito n. 1: tutti i dispositivi Android sono uguali ... è sufficiente test sugli emulatori
Cominciamo con un semplice esempio. Un'applicazione funziona perfettamente sugli emulatori ma su alcuni dispositivi reali si blocca durante l'esecuzione
L'applicazione si arresta in modo anomalo durante l'esecuzione sul dispositivo reale
Gli emulatori non sono sufficienti per i tuoi test mobili. Devi testare la tua app su dispositivi reali.
Mito n. 2: il test su alcuni dispositivi comuni è sufficiente
- Su dispositivi diversi, l'applicazione ha un aspetto diverso perché dispositivi diversi hanno hardware, dimensioni dello schermo, memoria, ecc.
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 c'è un piano e nessuna preparazione, quindi il tester farebbe i test che vuole fare. Alcune funzioni verranno testate ripetutamente, mentre alcune funzioni non verranno testate del tutto.
Mito # 4: se ci sono alcuni bug nell'applicazione, gli utenti capiranno
- Se l'applicazione non funziona e presenta bug, gli utenti la disinstallano
- I problemi di qualità sono il primo motivo per una recensione negativa in Google Play. Influisce sulla tua reputazione e perdi la fiducia del cliente.
Pertanto è essenziale disporre di una corretta strategia di test Android
Best practice per Android Testing
- 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 controllo della versione insieme al codice sorgente
- Utilizza l'integrazione continua ed esegui test ogni volta che il codice viene modificato
- Evita di usare emulatori e dispositivi rooted