Waarom Android-testen?
Android is het grootste besturingssysteem ter wereld. Tegelijkertijd is Android gefragmenteerd. er zijn talloze apparaten en Android-versies waarmee uw app compatibel moet zijn.
Het maakt niet uit hoeveel tijd u investeert in ontwerp en implementatie, fouten zijn onvermijdelijk en er zullen bugs verschijnen.
In deze tutorial leer je-
- Waarom Android-testen?
- Android-teststrategie
- Eenheidstests
- Integratietesten
- Operationele tests
- Systeemtests
- Geautomatiseerde ANDROID-TESTEN
- Android-testraamwerk
- Robolectric testraamwerk
- Mythen van Android-testen
- Praktische tips voor Android-tests
Android-teststrategie
Een correcte Android-teststrategie zou het volgende moeten omvatten
- Hoofdstuk toets
- Integratietest
- Operationele test
- Systeemtest
Eenheidstests
Unit-tests omvatten sets van een of meer programma's die zijn ontworpen om een atomaire broncode-eenheid te verifiëren, zoals een methode of een klasse.
Android-platform wordt geleverd met een vooraf geïntegreerd Junit 3.0-framework. Het is een open source framework voor het automatiseren van Unit Testing. Android Testing Framework is een krachtig hulpmiddel voor ontwikkelaars om het effectieve unit-testprogramma te schrijven.
De integratie van Android en JUnit-framework
Een aanvulling op Unit Testing zijn User Interface (UI) -tests. Deze tests hebben betrekking op UI-componenten van uw doeltoepassing. UI-tests zorgen ervoor dat uw toepassing de juiste UI-uitvoer retourneert als reactie op een reeks gebruikersacties op het apparaat.
Algemene gebruikersinterface-acties op de applicatie
De gebruikelijke manier om UI-tests op het apparaat uit te voeren, is Android Instrumentation. Maar dit heeft prestatieproblemen. Een van de beste tools om UI-tests op Android uit te voeren, is Robotium.
Integratietesten
Bij Integration Testing worden alle unit-geteste modules gecombineerd en geverifieerd. In Android omvatten integratietests vaak het controleren van de integratie met Android-componenten, zoals servicetests, activiteitstests, testen van contentproviders, enz.
Typen integratietests op Android
Er worden veel testkaders gebruikt om integratietests voor Android uit te voeren, zoals Troyd, Robolectric, Robotium.
Operationele tests
- Operationeel worden ook wel functionele tests of acceptatietests genoemd. Het zijn tests van hoog niveau die zijn ontworpen om de volledigheid en juistheid van de toepassing te controleren.
- In Android is FitNesse een open-source framework dat het gemakkelijk maakt om operationele tests uit te voeren voor de doeltoepassing.
Systeemtests
Bij System Testing wordt het systeem als geheel getest en wordt de interactie tussen de componenten, software en hardware gecontroleerd.
In Android omvat Systeemtesten normaal gesproken
- GUI-tests
- Bruikbaarheidstests
- Prestatie testen
- Stresstests
In de bovenstaande lijst krijgt Performance Testing meer aandacht. U kunt tools zoals Traceview gebruiken om prestatietests op Android uit te voeren. Deze tool kan u helpen bij het opsporen van fouten in uw toepassing en de prestaties ervan te profileren.
Geautomatiseerde ANDROID-TESTEN
Omdat Android gefragmenteerd is, is testen op een groot aantal apparaten noodzakelijk. Maar dit kost u ook geld. Geautomatiseerde Android-tests kunnen de kosten verlagen
Voordelen van geautomatiseerde Android-tests
- Verkort de tijd voor het uitvoeren van testcases
- Verhoog de productiviteit van uw ontwikkelingsproces
- Vroege bugdetectie, bespaar kosten op softwareonderhoud
- Vind en los de bugs bij de implementatie snel op
- Zorg voor de kwaliteit van software
We zullen de volgende 2 kaders bestuderen
- Android-testraamwerk
- Robolectric testraamwerk
Android-testraamwerk
Een van de standaard testframeworks voor Android-applicaties is het Android-testraamwerk . Het is een krachtig en gebruiksvriendelijk testraamwerk dat goed is geïntegreerd met de Android SDK-tools.
Architectuur van het Android-testkader
- Applicatiepakket is uw doeltoepassing die moet worden getest
- InstrumentationTestRunner is de Test Case-runner die een testcase op een doeltoepassing uitvoert. Het bevat:
2a) Testtools: een SDK-tools voor het bouwen van test. Ze zijn geïntegreerd in Eclipse IDE of worden uitgevoerd als opdrachtregel.
2b) MonkeyRunner: een tool die API's biedt voor het schrijven van programma's die een Android-apparaat of emulator besturen buiten de Android-code om.
- Testpakketten zijn georganiseerd in testprojecten. Dit pakket volgt de naamgevingsconventie. Als de te testen toepassing de pakketnaam "com.mijndomein.mijnapp" heeft, dan moet het testpakket "com.mijndomein.mijnapp.test" zijn. Het testpakket bevat 2 objecten, zoals hieronder:
3a) Testcaseklassen: omvatten testmethoden die op de doeltoepassing moeten worden uitgevoerd.
3b) Mock-objecten: bevat nepgegevens die zullen worden gebruikt als voorbeeldinvoer voor testgevallen.
Android-testcaseklassen
AndroidTestCase-klassendiagram
- TestCase bevat JUnit-methoden om de JUnit-test uit te voeren
- TestSuite wordt gebruikt om een reeks testcases uit te voeren
- InstrumentationTestSuite is een TestSuite die Instrumentation in InstrumentationTestCase injecteert voordat ze worden uitgevoerd.
- InstrumentationTestRunner is de testcase-runner die een testcase uitvoert op de doeltoepassing.
- AndroidTestCase breidt JUnit TestCase uit. Het bevat methoden voor toegang tot bronnen zoals Activity Context.
- ApplicationTestCase verifieert de toepassingsklassen in een gecontroleerde omgeving.
- InstrumentationTestCase verifieert een bepaald kenmerk of gedrag van de doeltoepassing, bijvoorbeeld om de UI-uitvoer van de toepassing te verifiëren.
- ActivityTestCase is een basisklasse die het testen van de toepassingsactiviteiten ondersteunt.
- ProviderTestCase is een klasse voor het testen van één ContentProvider.
- ServiceTestCase wordt gebruikt om serviceklassen in een testomgeving te testen. Het ondersteunt ook de levenscyclus van de service.
- SingeLauchActivityTestCase wordt gebruikt om een enkele activiteit te testen met een InstrumentationTestCase.
- ActivityUnitTestCase
wordt gebruikt om enkele geïsoleerde activiteit te testen. - ActivityInstrumentationTestCase2
breidt de JUnit TestCase-klasse uit. Het verbindt u met de doeltoepassing met instrumentatie. Met deze klasse hebt u toegang tot de GUI-component van de toepassing en kunt u een UI-gebeurtenis (toetsaanslag of aanraakgebeurtenis) naar de gebruikersinterface sturen.
Hieronder ziet u een voorbeeld van ActivityInstrumentationTestCase. Het verifieert de UI-werking van de Rekenmachine-applicatie, controleer de juistheid van de UI-uitgangen.
ActivityInstrumentationTestCase2-testvoorbeeld
Robolectric testraamwerk
Testen met het Android-testframework met apparaat of emulator is moeilijk. Het bouwen en uitvoeren van tests is traag en vereist veel ontwikkelingsinspanning. Om dit probleem op te lossen, is er nog een andere keuze: het Robolectric-testraamwerk .
Met het Robolectric-framework kunt u Android-tests rechtstreeks op JVM uitvoeren zonder dat u een apparaat of emulator nodig hebt.
Geavanceerde kenmerken van Robolectric
Robolectric Test Case Klassen
Werking van Robolectric
- Zoals hierboven weergegeven, kan Robolectric de volgende acties uitvoeren:
- Registreer en maak een Shadow-klasse
- Onderschep het laden van Android-klasse
- Gebruikt javaassist om de body van de Android-klasse te overschrijven
- Bind Shadow-object aan Android-klasse
- Hierdoor kan de te testen code worden uitgevoerd zonder Android-omgeving.
Anderen testkader
Naast de hierboven genoemde testkaders zijn er nog vele andere testkaders zoals:
- Android Junit Report, een aangepaste instrumentatietest voor Android die XML-rapporten genereert voor integratie met andere tools.
- Expresso
- Appium
Mythen van Android-testen
Veel bedrijven ontwikkelen Android-teststrategieën die zijn gebaseerd op algemene misvattingen. In dit gedeelte worden enkele populaire mythes en realiteiten van Android-testen besproken.
Mythe # 1: alle Android-apparaten zijn hetzelfde ... testen op emulators is voldoende
Laten we beginnen met een eenvoudig voorbeeld. Een applicatie werkt perfect op emulators, maar op sommige echte apparaten crasht het tijdens de uitvoering
Applicatie crasht tijdens uitvoering op echt apparaat
Emulators zijn niet voldoende voor uw mobiele tests. U moet uw app testen op echte apparaten.
Mythe 2: testen op een aantal veelgebruikte apparaten is voldoende
- Op verschillende apparaten ziet uw applicatie er anders uit omdat verschillende apparaten verschillende hardware, schermformaten, geheugen enz. Hebben. U moet uw applicatie testen op verschillende apparaten, OS-versies, providernetwerken en locaties.
Mythe 3: verkennend testen net voor de lancering is voldoende
- Over het algemeen ontwerpen we bij alle tests de testcases en voeren ze vervolgens uit. Maar bij Exploratory testing, test design en executie gebeurt alles samen.
- Bij verkennend testen is er geen plan en geen voorbereiding, dan zou de tester testen doen die hij wil doen. Sommige functies worden herhaaldelijk getest, terwijl sommige functies niet helemaal worden getest.
Mythe # 4: Als er een aantal bugs in de applicatie zitten, zullen gebruikers het begrijpen
- Als de applicatie niet werkt en bugs bevat, verwijderen gebruikers uw app
- Kwaliteitsproblemen zijn de eerste reden voor slechte recensies in Google Play. Het heeft invloed op uw reputatie en u verliest het vertrouwen van de klant.
Daarom is het essentieel om een goede Android-teststrategie te hebben
Praktische tips voor Android-tests
- Applicatieontwikkelaars moeten de testcases maken op hetzelfde moment dat ze de code schrijven
- Alle testgevallen moeten worden opgeslagen in versiebeheer, samen met de broncode
- Gebruik continue integratie en voer tests uit telkens wanneer de code wordt gewijzigd
- Gebruik geen emulators en geroote apparaten