Android APP Test Tutorial med Automation Framework

Hvorfor Android Test?

Android er det største operativsystem i verden. På samme tid, Android er fragmenteret. der er tonsvis af enheder og Android versioner, som din app skal være kompatibel med.

Det er lige meget, hvor meget tid du investerer i design og implementering, fejl er uundgåelige, og fejl vil dukke op.

Android Teststrategi

En korrekt android-teststrategi bør omfatte følgende

1. Enhedstest
2. Integrationstest
3. Operational test
4. Systemtest

Enhedstest

Enhedstest omfatter sæt af et eller flere programmer, som er designet til at verificere en atomare enhed af kildekode, såsom en metode eller en klasse.

Android platform leveres præ-integreret Junit 3.0 ramme. Det er open source-ramme til automatisering Enhedstest. Android Testing Framework er et kraftfuldt værktøj for udviklere til at skrive det effektive enhedstestprogram.

En tilføjelse til Unit Testing er User Interface (UI) test. Disse tests relaterer sig til UI-komponenter i din målapplikation. UI-tests sikrer, at din applikation returnerer det korrekte UI-output som svar på rækkefølgen af ​​brugerhandlinger på enheden.

Den almindelige måde at udføre UI-test på enheden er Android Instrumentering. Men dette har præstationsproblemer. Et af de bedste værktøjer til at udføre UI-test på Android is Robotium.

Integrationstest

In Integrationstest, alle enhedstestede moduler, kombineres og verificeres. I Android, involverer integrationstest ofte kontrol af integration medAndroid komponenter som Servicetest, Aktivitetstest, Content Provider test mv

Der er mange testrammer, der bruges til at udføre integrationstest for Android såsom Troyd, Robolectric, Robotium.

Operanationale prøver

• Operationelle kaldes også funktionelle tests eller accepttests. De er test på højt niveau designet til at kontrollere fuldstændigheden og rigtigheden af ​​ansøgningen.
• In Android, FitNesse er open source-ramme, der gør det nemt at udføre operationelle test til målapplikation.

System tests

In Systemtest systemet testes som en helhed, og samspillet mellem komponenter, software og hardware kontrolleres.

In Android, Systemtest inkluderer normalt

• GUI test
• Brugbarhedstest
• Ydelsestest
• Stresstest

I ovenstående liste, Test af ydeevne får mere fokus. Du kan bruge værktøjer som f.eks Traceview at udføre præstationstest på Android Dette værktøj kan hjælpe dig med at fejlsøge din applikation og profilere dens ydeevne.

Automatiseret ANDROID-TEST

Da Android er fragmenteret, er det nødvendigt at teste på mange enheder. Men det vil også koste dig penge. Automatiseret Android Test kan hjælpe med at reducere omkostningerne

Fordele ved automatiseret Android-test

• Reducer tid til at udføre testcases
• Øg produktiviteten i din udviklingsproces
• Tidlig fejldetektion, spar omkostninger på softwarevedligeholdelse
• Find hurtigt og ret fejlene ved implementering
• Sikre kvaliteten af ​​softwaren

Vi vil studere følgende 2 rammer

• Android Testramme
• Roboelektrisk testramme

Android testramme

En af standard testrammer for Android ansøgning er Android testramme. Det er en kraftfuld og nem at bruge testramme, der er godt integreret med Android SDK værktøjer.

1. Ansøgningspakke er din målapplikation, som skal testes
2. InstrumentationTestRunner er Test sag runner, der udfører testcase på målapplikationen. Det omfatter:

2) Testværktøjer: Et SDK-værktøj til byggetest. De er integreret i Eclipse IDE eller kør som kommandolinje.

2b) MonkeyRunner: Et værktøj, der leverer API'er til at skrive program, der styrer en Android enhed eller emulator udenfor Android kode.

3. Testpakke er organiseret i testprojekter. Denne pakke følger navnekonventionen. Hvis applikationen under test har pakkenavnet "com.mydomain.myapp", skal testpakken være "com.mydomain.myapp.test". Testpakken indeholder 2 objekter som nedenfor:

3a) Testcaseklasser: omfatter testmetoder, der skal udføres på målapplikationen.

3b) Mock-objekter: inkluderer mock-data, der vil blive brugt som eksempelinput til testcases.

Android Test Case klasser

1. Test sag omfatter JUnit metoder til at køre JUnit prøve
2. TestSuite bruges til at køre sæt af testcases
3. InstrumentationTestSuite er en TestSuite, der injicerer Instrumentation i InstrumentationTestCase, før de køres.
4. InstrumentationTestRunner er testcase-løberen, der udfører testcase på målapplikationen.
5. AndroidTest sag udvider JUnit Test sag. Den indeholder metoder til at få adgang til ressourcer som Aktivitetskontekst.
6. ApplicationTestCase verificerer applikationsklasserne i et kontrolleret miljø.
7. InstrumentationTestCase verificerer en bestemt funktion eller adfærd i målapplikationen, f.eks. verificere UI-output af applikationen.
8. ActivityTestCase er basisklasse, der understøtter test af applikationsaktiviteterne.
9. ProviderTestCase er klasse til test af enkelt ContentProvider.
10. ServiceTestCase bruges til at teste serviceklasser i testmiljø. Det understøtter også tjenestens livscyklus.
11. SingeLauchActivityTestCase bruges til at teste enkelt aktivitet med en InstrumentationTestCase.
12. ActivityUnitTestCase bruges til at teste enkelt isoleret aktivitet.
13. AktivitetInstrumentationTestCase2 udvider JUnit TestCase klasse. Det forbinder dig til målapplikationen med instrumentering. Med denne klasse kan du få adgang til applikationens GUI-komponent og sende UI-hændelse (tastetryk eller berøringshændelse) til UI.

Nedenfor er et eksempel på ActivityInstrumentationTestCase. Det verificerer UI-driften af ​​Calculator-applikationen, kontroller rigtigheden af ​​UI-output.

Roboelektrisk testramme

Test vha Android Det er svært at teste rammer med enhed eller emulator. Bygge- og køretest er langsom og kræver meget udviklingsindsats. For at løse dette problem er der et andet valg – Roboelektrisk testramme.

Robolectric framework giver dig mulighed for at løbe Android tests direkte på JVM uden behovet for en enhed eller en emulator.

Klasser af roboelektriske testtilfælde

• Som vist ovenfor kan Robolectric udføre følgende handlinger:
• Tilmeld dig og opret en Shadow-klasse
• Opsnappe indlæsningen af Android klasse
• Bruger javaassist til at tilsidesætte metodelegemerne af Android klasse
• Bind Shadow objekt til Android klasse
• Dette gør det muligt for koden under test at køre uden Android miljø.

Andre testramme

Udover testrammer, som blev nævnt ovenfor, er der mange andre testrammer såsom:

• Android Junit rapport, en brugerdefineret instrumenteringstestløber til Android der genererer XML-rapporter til integration med andre værktøjer.
• udtrykke
• Appium

Myter om Android Test

Mange virksomheder udvikler Android Test strategier, der er baseret på almindelige misforståelser. Dette afsnit undersøger et par populære myter og realiteter om Android testning.

Myte #1: Alle Android enheder er de samme ... test på emulatorer er nok

Lad os starte med et simpelt eksempel. En applikation fungerer perfekt på emulatorer, men på nogle rigtige enheder går den ned under udførelse

Emulatorer er ikke tilstrækkelig til din mobiltest. Du skal teste din app på rigtige enheder.

Myte #2: Det er nok at teste på nogle almindelige enheder

• På forskellige enheder ser din applikation anderledes ud, fordi forskellige enheder har forskellig hardware, skærmstørrelser, hukommelse osv. Du skal teste din applikation på forskellige enheder, OS-versioner, operatørnetværk og placeringer.

Myte#3: Udforskende test lige før lancering er nok

• Generelt i al testning designer vi testcaserne og udfører dem derefter. Men i Exploratory testing, testdesign og udførelse vil alt blive udført sammen.
• I udforskende test er der ingen plan og ingen forberedelse, så ville testeren lave test, som han vil lave. Nogle funktioner vil blive testet gentagne gange, mens nogle funktioner ikke vil blive testet helt.

Myte #4: Hvis der er nogle fejl i applikationen, vil brugerne forstå

• Hvis programmet ikke virker og har fejl, afinstallerer brugerne din app
• Kvalitetsproblemer er den første årsag til dårlig anmeldelse i Google Play. Det påvirker dit omdømme, og du mister kundernes tillid.

Derfor er det vigtigt at have en ordentlig android-teststrategi på plads

Bedste øver sig i Android Test

• Applikationsudviklere bør oprette testcases på samme tid, når de skriver koden
• Alle testcases skal gemmes i versionskontrol sammen med kildekode
• Brug kontinuerlig integration og kør test hver gang koden ændres
• Undgå at bruge emulatorer og rootede enheder