Android Handleiding voor het testen van apps met behulp van een automatiseringsframework.

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 je investeert in ontwerp en implementatie, fouten zijn onvermijdelijk en er zullen bugs opduiken.

Android Strategie testen

een juiste Android De teststrategie moet het volgende omvatten:

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

Eenheidstests

Unit tests zijn sets programma's die zijn ontworpen om een ​​atomair onderdeel van de broncode te verifiëren, zoals een methode of een klasse.

De Android Het platform is vooraf geïntegreerd met de JUnit 3.0 framework. Het is een open source framework voor automatisering. Testen van een eenheidEn het stelt ontwikkelaars in staat om effectieve unit-testprogramma's te schrijven.

Naast unit-testen zijn er ook gebruikersinterface (UI)-testen. Deze testen de UI-componenten van je doelapplicatie en zorgen ervoor dat deze de juiste uitvoer geeft voor een reeks gebruikersacties op het apparaat.

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

⚠️ Versie-opmerking: JUnit 3 klassen zoals InstrumentatieTestCase werden afgekeurd bij API 24; huidige projecten gebruiken AndroidX-test, Espresso en UI Automator. Robotium is sinds 2016 niet meer uitgebracht.

Integratietests

In IntegratietestenAlle geteste modules worden gecombineerd en geverifieerd. Android Dit houdt vaak in dat de integratie met componenten zoals Service, Activity en Content Provider wordt gecontroleerd.

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

Operationele testen

OperaFunctionele tests, ook wel acceptatietests genoemd, zijn tests op hoog niveau die de volledigheid en correctheid van de applicatie controleren.

In Android, FitNesse is een open-source framework waarmee operationele tests eenvoudig kunnen worden uitgevoerd op de doelapplicatie.

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 Tracbekijken om prestatietests uit te voeren op AndroidDeze tool kan je helpen bij het debuggen van je applicatie en het profileren van de prestaties ervan. Traceview is nu verouderd en vervangen door de CPU-profiel.

Automatische Android Testen

As Android is gefragmenteerd, testen op veel apparaten is nodig en dat kost geld. Geautomatiseerd Android Testen helpt die kosten te verlagen.

Voordelen van automatisering Android het testen van

• 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 toepassingen is de Android testframework. Het is goed geïntegreerd met de Android SDK-tools en hun architectuur bestaan ​​uit drie onderdelen.

1. Het applicatiepakket is de doelapplicatie die getest moet worden.
2. InstrumentationTestRunner is de Testgeval Een runner die testcases uitvoert op de doelapplicatie. Deze omvat:
   • Testtools: SDK-tools voor het bouwen van tests. Deze zijn geïntegreerd in de IDE of kunnen vanaf de commandoregel worden uitgevoerd.
   • MonkeyRunner: Een tool die API's biedt voor het schrijven van programma's die een systeem besturen. Android apparaat of emulator buiten Android code.
3. Een testpakket is georganiseerd in testprojecten en volgt een naamgevingsconventie. Als de te testen applicatie een pakketnaam heeft van "com.mydomain.myapp", dan moet het testpakket "com.mydomain.myapp.test" heten. Het testpakket bevat 2 objecten:
   • Testcaseklassen: Voeg testmethoden toe die op de doelapplicatie moeten worden uitgevoerd.
   • Nepobjecten: Voeg fictieve gegevens toe die als voorbeeldinvoer voor testgevallen zullen worden gebruikt.

Android Testcase-klassen

1. Testcase bevat JUnit methoden om te draaien JUnit proef
2. TestSuite wordt gebruikt om een ​​reeks testgevallen uit te voeren.
3. InstrumentationTestSuite is een testsuite die instrumentatie injecteert in InstrumentationTestCase voordat deze worden uitgevoerd.
4. InstrumentationTestRunner voert testcases uit op de doelapplicatie.
5. AndroidTestCase breidt uit JUnit Testcase met methoden voor toegang tot resources zoals de activiteitscontext.
6. ApplicationTestCase verifieert de applicatieklassen in een gecontroleerde omgeving.
7. InstrumentationTestCase verifieert een specifieke functie of gedrag, bijvoorbeeld de UI-uitvoer van de applicatie.
8. ActivityTestCase is een basisklasse die het testen van de applicatieactiviteiten ondersteunt.
9. ProviderTestCase is een klasse voor het testen van een enkele ContentProvider.
10. ServiceTestCase test Service-klassen in een testomgeving en ondersteunt de levenscyclus van de Service.
11. SingleLaunchActivityTestCase wordt gebruikt om een ​​enkele activiteit te testen met een InstrumentationTestCase.
12. ActiviteitUnitTestCase wordt gebruikt om een ​​enkele, geïsoleerde activiteit te testen.
13. ActiviteitInstrumentatieTestcase2 verlengt de JUnit De TestCase-klasse verbindt je met de doelapplicatie via instrumentatie, zodat je toegang hebt tot GUI-componenten en UI-gebeurtenissen zoals toetsaanslagen of aanrakingen kunt verzenden.

Hieronder staat een voorbeeld van een ActivityInstrumentationTestCase. Deze test verifieert de werking van de gebruikersinterface van een rekenmachine-applicatie en controleert de correctheid van de uitvoer.

Robo-elektrisch testframework

Testen met behulp van de Android Het testen van een framework met een apparaat of emulator is lastig. Het bouwen en uitvoeren van tests is traag en vergt veel ontwikkeltijd. Om dit probleem op te lossen, is er een alternatief: het Robolectric-testframework.

Met Robolectric kunt u Android Tests worden direct op de JVM uitgevoerd, zonder dat een apparaat of emulator nodig is.

Robolektrische testcaseklassen

Robolectric kan de volgende acties uitvoeren:

• Registreer en maak een Shadow-klasse
• Onderschep het laden van Android klasse
• u gebruikt Javassist om de methodelichamen van te overschrijven Android klasse
• Bind Shadow-object aan Android klasse

Dit zorgt ervoor dat de te testen code kan worden uitgevoerd zonder een Android milieu.

Andere testframeworks

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

• Android Junit-rapport, een aangepaste instrumentatietestloper voor Android dat XML-rapporten genereert voor integratie met andere tools.
• Espresso
• 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 nr. 1: Alle Android De apparaten zijn hetzelfde, dus testen op emulators is voldoende.

Een applicatie kan perfect werken op emulators, maar tijdens de uitvoering vastlopen op sommige echte apparaten.

Emulators zijn niet voldoende voor het testen van je app op mobiele apparaten. Je moet je app op echte apparaten testen.

Mythe 2: Testen op een paar gangbare apparaten is voldoende.

Je applicatie ziet er op verschillende apparaten anders uit, omdat hardware, schermformaten en geheugen verschillen. Test de applicatie daarom op diverse apparaten, besturingssysteemversies, mobiele netwerken en locaties.

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

• Bij de meeste testmethoden ontwerpen we testgevallen en voeren we die vervolgens uit; bij exploratief testen vinden ontwerp en uitvoering gelijktijdig plaats.
• Er is geen plan of voorbereiding, dus de tester voert de tests uit die hij zelf kiest. Sommige functies worden herhaaldelijk getest, terwijl andere nooit worden getest.

Mythe 4: Als er bugs in de applicatie zitten, zullen gebruikers dat wel begrijpen.

• Als de applicatie niet werkt en bugs bevat, verwijderen gebruikers je app.
• Kwaliteitsproblemen zijn de belangrijkste reden voor slechte recensies. Google Speel hierop in, schaad je reputatie en verlies het vertrouwen van je klanten.

Daarom is het essentieel om over de juiste kennis te beschikken. Android Teststrategie is van kracht.

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 uitsluitend vertrouwen op emulators en gerootte apparaten; bevestig de resultaten op echte hardware met een inspectieprogramma zoals uiautomatorviewer

Veelgestelde vragen