Tutorial voor het testen van Android-apps met Automation Framework

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.

Android-testen

Het maakt niet uit hoeveel tijd u investeert in ontwerp en implementatie, fouten zijn onvermijdelijk en bugs zullen verschijnen.

Android-testen

Android-teststrategie

Een correcte Android-teststrategie moet het volgende omvattenwing

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

Android-teststrategie

Eenheidstests

Eenheidstests omvatten sets van een of meer programma's die zijn ontworpen om een ​​programma te verifiëren atomic-eenheid van de broncode, zoals een methode of een klasse.

Het 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.

Integratie van Android en JUnit Framework
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 de reeks gebruikersacties op het apparaat.

Algemene gebruikersinterfaceacties op toepassing
Algemene gebruikersinterface-acties op de applicatie

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 op Android uit te voeren is Robotium.

Integratietests

In IntegratietestenAlle unit-geteste modules worden gecombineerd en geverifieerd. In Android omvatten integratietests vaak het controleren van de integratie met Android-componenten zoals servicetests, activiteitentests, tests van inhoudsproviders, enz

Integratietesten
Soorten integratietest op Android

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

Operationele tests

  • 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.
  • Android, FitNesse is een open-sourceframework waarmee u eenvoudig operationele tests voor doeltoepassingen 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 Android omvat systeemtesten normaal gesproken:

  • GUI-tests
  • Bruikbaarheidstesten
  • Prestatietests
  • Stresstesten

In de bovenstaande lijst staat Performance Testing krijgt meer focus. Je kunt tools gebruiken zoals Traceview om prestatietests uit te voeren op Android. Deze tool kan u helpen fouten in uw applicatie op te sporen en de prestaties ervan te profileren.

Geautomatiseerde ANDROID-TESTEN

Omdat Android gefragmenteerd is, is testen op een groot aantal apparaten noodzakelijk. Maar dit kost je ook geld. Geautomatiseerde Android-tests kunnen de kosten helpen verlagen

Voordelen van geautomatiseerd Android-testen

  • 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 het volgende bestuderenwing 2 kaders

  • Android-testframework
  • Robolektrisch testframework

Android-testframework

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

Android-testframework
Android-testframework Architectuur
  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 besturen buiten de Android-code.

  1. 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-testcaseklassen

Android-testcaseklassen
AndroidTestCase-klassediagram
  1. Testcase bevat JUnit-methoden om de JUnit-test uit te voeren
  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 breidt JUnit TestCase uit. 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 breidt de JUnit TestCase-klasse uit. 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 werking van de gebruikersinterface van Calculator applicentie, controleer de juistheid van de UI-uitvoer.

ActiviteitInstrumentatieTestCase2 Testen
ActiviteitInstrumentatieTestCase2 testvoorbeeld

Robo-elektrisch testframework

Testen met Android Testframework met 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 Android-tests uitvoeren direct op JVM zonder de behoefte aan een apparaat of een emulator.

Geavanceerde functies van Robolectric
Geavanceerde functies van Robolectric

Robolektrische testcaseklassen

Werking van Robolektrisch
Werking van Robolektrisch
  • Zoals hierboven weergegeven, kan Robolectric follo uitvoerenwing acties:
  • Registreer en maak een Shadow-klasse
  • Onderschep het laden van de Android-klasse
  • Gebruikt Javaassist om de methodelichamen van de Android-klasse te overschrijven
  • Bind Shadow-object aan Android-klasse
  • Hierdoor kan de geteste code worden uitgevoerd zonder Android-omgeving.

Anderen testen raamwerk

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

Mythen over Android-testen

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

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 deze tijdens de uitvoering

Applicatie loopt vast tijdens uitvoering op echt apparaat
Applicatie crasht tijdens uitvoering op een echt apparaat

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

Praktische tips voor 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