Android Tutorial voor APP-testen met Automation Framework

Waarom Android Testen?

Android is het grootste besturingssysteem ter wereld. Tegelijkertijd, Android is 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 bugs zullen verschijnen.

Android Strategie testen

Een correcte Android-teststrategie zou het volgende moeten omvatten

1. Hoofdstuk toets
2. Integratietest
3. Operaationele test
4. Systeemtest

Eenheidstests

Unittests bestaan ​​uit sets van één of meer programma's die zijn ontworpen om een ​​atomaire eenheid van de broncode, zoals een methode of een klasse, te verifiëren.

Android platform is vooraf geïntegreerd Juniet 3.0 raamwerk. Het is een open source raamwerk voor automatisering Testen van een eenheid. Android Testing Framework is een krachtig hulpmiddel voor ontwikkelaars om het effectieve unit-testprogramma te schrijven.

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 de reeks gebruikersacties op het apparaat.

De gebruikelijke manier om UI-tests op een apparaat uit te voeren is Android Instrumentatie. Maar dit heeft prestatieproblemen. Een van de beste tools om UI-tests uit te voeren Android is Robotium.

Integratietests

In IntegratietestenAlle unit-geteste modules worden gecombineerd en geverifieerd. In AndroidBij integratietests gaat het vaak om het controleren van de integratie metAndroid componenten zoals servicetests, activiteitentests, tests van inhoudsproviders, enz

Er zijn veel testframeworks die worden gebruikt om integratietests uit te voeren Android zoals Troyd, Robolectric, Robotium.

Operationele testen

• Operationeel worden ook wel Functionele Tests of Acceptatietests genoemd. Het zijn tests op hoog niveau, ontworpen om de volledigheid en juistheid van de toepassing te controleren.
• In Android, FitNesse is een open-source framework waarmee u eenvoudig operationele tests voor de doelapplicatie kunt uitvoeren.

Systeem testen

In Systeem testen het systeem wordt als geheel getest en de interactie tussen de componenten, software en hardware wordt gecontroleerd.

In AndroidSysteemtesten omvatten normaal gesproken

• GUI-tests
• Bruikbaarheidstesten
• Prestatietests
• Stresstesten

In de bovenstaande lijst staat Performance Testing krijgt meer focus. Je kunt tools gebruiken zoals Traceview prestatietest uit te voeren Android Met deze tool kunt u fouten in uw toepassing opsporen en de prestaties ervan profileren.

Geautomatiseerde ANDROID-TESTEN

Omdat Android gefragmenteerd is, is het noodzakelijk om op meerdere apparaten te testen. Maar dit kost je ook geld. Geautomatiseerd Android Testen kan helpen de kosten te verlagen

Voordelen van geautomatiseerde Android-tests

• Verminder de tijd voor het uitvoeren van testgevallen
• Verhoog de productiviteit van uw ontwikkelingsproces
• Vroegtijdige detectie van bugs, bespaar kosten op softwareonderhoud
• Snel de bugs bij de implementatie gevonden en opgelost
• Zorgen voor de kwaliteit van software

We zullen de volgende 2 raamwerken bestuderen

• Android Testkader
• Robolektrisch testframework

Android testkader

Een van de standaard testframeworks voor Android toepassing is Android testkader. Het is een krachtig en gebruiksvriendelijk testframework dat goed is geïntegreerd met de Android SDK-hulpmiddelen.

1. Toepassingspakket: is uw doeltoepassing die moet worden getest
2. InstrumentatieTestRunner is de Testgeval runner die een testcase uitvoert op de doeltoepassing. Het bevat:

2a) Testtools: Een SDK-tool voor het bouwen van tests. Ze zijn erin geïntegreerd Eclipse IDE of uitvoeren als opdrachtregel.

2b) MonkeyRunner: Een tool die API's biedt voor het schrijven van programma's die een Android apparaat of emulator buiten Android code.

3. Testpakket zijn georganiseerd in testprojecten. Dit pakket volgt de naamgevingsconventie. Als de te testen applicatie de pakketnaam “com.mydomain.myapp” heeft, dan moet het testpakket “com.mydomain.myapp.test” zijn. Het testpakket bevat 2 objecten, zoals hieronder:

3a) Testcaseklassen: omvatten testmethoden die op de doeltoepassing moeten worden uitgevoerd.

3b) Mock-objecten: bevat mock-gegevens die zullen worden gebruikt als voorbeeldinvoer voor testgevallen.

Android Testcase-klassen

1. Testcase omvat JUnit methoden om te draaien JUnit proef
2. Test pak wordt gebruikt om een ​​reeks testgevallen uit te voeren
3. InstrumentatieTestSuite is een TestSuite die Instrumentatie in InstrumentationTestCase injecteert voordat deze wordt uitgevoerd.
4. InstrumentatieTestRunner is de testcaserunner die de testcase op de doeltoepassing uitvoert.
5. AndroidTestcase strekt JUnit Testcase. Het bevat methoden voor toegang tot bronnen zoals Activity Context.
6. ToepassingTestCase verifieert de applicatieklassen in een gecontroleerde omgeving.
7. InstrumentatieTestCase verifieert een bepaalde functie of gedrag van de doeltoepassing, bijvoorbeeld de UI-uitvoer van de toepassing verifiëren.
8. ActiviteitTestCase is een basisklasse die het testen van de applicatieactiviteiten ondersteunt.
9. ProviderTestCase is een klasse voor het testen van één ContentProvider.
10. ServiceTestCase wordt gebruikt om serviceklassen in de testomgeving te testen. Het ondersteunt ook de levenscyclus van Service.
11. SingeLauchActiviteitTestCase wordt gebruikt om een ​​enkele activiteit te testen met een InstrumentationTestCase.
12. ActivityUnitTestCase wordt gebruikt om enkele geïsoleerde activiteit te testen.
13. ActiviteitInstrumentatieTestCase2 verlengt de JUnit TestCase-klasse. Het verbindt u met de doeltoepassing met instrumentatie. Met deze klasse heeft u toegang tot de GUI-component van de toepassing en kunt u een UI-gebeurtenis (toetsaanslag of aanraakgebeurtenis) naar de gebruikersinterface verzenden.

Hieronder ziet u een voorbeeld van ActivityInstrumentationTestCase. Het verifieert de UI-werking van de Calculator-applicatie en controleert de juistheid van de UI-uitvoer.

Robo-elektrisch testframework

Testen met behulp van Android Het testen van het raamwerk met een apparaat of emulator is moeilijk. Het bouwen en uitvoeren van tests gaat langzaam en vergt veel ontwikkelingsinspanning. Om dit probleem op te lossen, is er nog een andere keuze: Robo-elektrisch toetsingskader.

Met het Robolectric-framework kunt u rennen Android testen direct op JVM zonder de behoefte aan een apparaat of een emulator.

Robolektrische testcaseklassen

• 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 methodelichamen van te overschrijven Android klasse
• Bind Shadow-object aan Android klasse
• Hierdoor kan de te testen code worden uitgevoerd zonder Android milieu.

Anderen testen raamwerk

Naast de hierboven genoemde testframeworks zijn er nog vele andere testframeworks zoals:

• Android Junit-rapport, een aangepaste instrumentatietestloper voor Android dat XML-rapporten genereert voor integratie met andere tools.
• Expresso
• Appium

Mythen van Android Testen

Veel bedrijven ontwikkelen Android Testen strategieën die gebaseerd zijn op veelvoorkomende misvattingen. In dit gedeelte worden enkele populaire mythen en realiteiten onderzocht Android testen.

Mythe #1: Alles 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 deze tijdens de uitvoering

Emulators zijn niet voldoende voor uw mobiele testen. U moet uw app op echte apparaten testen.

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, besturingssysteemversies, netwerkaanbieders en locaties.

Mythe #3: Verkennende tests vlak voor de lancering zijn voldoende

• Over het algemeen ontwerpen we bij alle tests de testgevallen en voeren deze vervolgens uit. Maar bij verkennend testen zullen testontwerp en uitvoering allemaal samen gebeuren.
• Bij verkennende tests is er geen plan en geen voorbereiding, en de tester zou tests doen die hij wil doen. Sommige functies zullen herhaaldelijk worden getest, terwijl sommige functies helemaal niet zullen worden getest.

Mythe #4:Als er bugs in de applicatie zitten, zullen gebruikers dit begrijpen

• Als de applicatie niet werkt en bugs bevat, verwijderen gebruikers uw app
• Kwaliteitsproblemen zijn de eerste reden voor slechte recensies op Google Play. Het tast uw reputatie aan en u verliest het vertrouwen van uw klant.

Daarom is het essentieel om een ​​goede Android-teststrategie te hebben

Best practices binnen Android Testen

• Applicatieontwikkelaars moeten de testcases maken op hetzelfde moment dat ze de code schrijven
• Alle testgevallen moeten samen met de broncode in versiebeheer worden opgeslagen
• Maak gebruik van continue integratie en voer tests uit telkens wanneer de code wordt gewijzigd
• Vermijd het gebruik van emulators en geroote apparaten