Android Veiledning for apptesting med automatiseringsrammeverk

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

⚡ Smart oppsummering

Android Apptesting verifiserer en plattformuavhengig versjon på tvers av et fragmentert enhetslandskap, og kombinerer enhets-, integrasjons-, drifts- og systemkontroller med automatiseringsrammeverk som kjører enten på en enhet eller direkte på JVM-en.

  • 🔘 Hvorfor det betyr noe: Android kjører på utallige enhets- og versjonskombinasjoner, så kompatibilitetsfeil er nesten sikre.
  • ☑️ Fire testnivåer: Enhets-, integrasjons-, drifts- og systemtesting fanger hver opp en annen klasse av feil.
  • ✅ Rammeverk på enheten: Ocuco Android testrammeverket bygger på JUnit og instrumentering.
  • 🧪 JVM-alternativ: Roboelektriske skygger Android klasser slik at suiter kjører på JVM uten en enhet eller emulator.
  • 🛠️ Bredere verktøysett: Espresso, UI Automator og Appium utvide dekningen utover de innebygde klassene.
  • 📊 Myter å unngå: Bare emulatorer, noen få håndsett eller utforskende testing i siste liten etterlater feil i produksjonen.
Les mer

Android Veiledning for apptesting som dekker testnivåer, automatiseringsrammeverk og enhetsdekning

Hvorfor Android Testing?

Android er det største operativsystemet i verden. Samtidig, Android er fragmentert: det finnes tonnevis av enheter og Android versjoner som appen din må være kompatibel med.

Det spiller ingen rolle hvor mye tid du investerer i design og implementering, feil er uunngåelige, og bugs vil dukke opp.

Android Teststrategi

En korrekt Android Teststrategien bør inkludere følgende

  1. Enhetstest
  2. Integrasjonstest
  3. Operanasjonal test
  4. Systemtest

Enhetstester

Enhetstester er sett med programmer som er designet for å verifisere en atomær enhet av kildekode, for eksempel en metode eller en klasse.

Ocuco Android plattformen leveres forhåndsintegrert med JUnit 3.0-rammeverket. Det er et åpen kildekode-rammeverk for automatisering Enhetstesting, og det lar utviklere skrive effektive enhetstestprogrammer.

Et tillegg til enhetstesting er brukergrensesnitttester (UI-tester). De dekker UI-komponentene i målapplikasjonen din og sikrer at den returnerer riktig utdata for en sekvens av brukerhandlinger på enheten.

Vanlige brukergrensesnitthandlinger på en Android applikasjon som trykk, skriving og sveiping

Den vanlige måten å utføre UI-tester på en enhet er Android Instrumentleverandører . Men dette har ytelsesproblemer. Et av de beste verktøyene å utføre UI-testing på Android is Robotium.

⚠️ Versjonsmerknad: JUnit 3 klasser som f.eks. InstrumentationTestCase ble avskrevet ved API 24; nåværende prosjekter bruker AndroidX-test, Espresso og UI Automator. Robotium har ikke hatt noen utgivelse siden 2016.

Integrasjonstester

In Integrasjonstesting, alle enhetstestede moduler kombineres og verifiseres. I Android Dette betyr ofte å sjekke integrasjon med komponenter som testing av tjenester, aktiviteter og innholdsleverandører.

Typer integrasjonstest på Android som dekker testing av tjenester, aktiviteter og innholdsleverandører

Mange testrammeverk brukes til å utføre integrasjonstester for Android, som Troyd, Robolectric og Robotium.

Operanasjonale prøver

OperaFunksjonstester, også kalt funksjonstester eller akseptansetester, er tester på høyt nivå som kontrollerer applikasjonens fullstendighet og korrekthet.

In Android, FitNesse er et åpen kildekode-rammeverk som gjør det enkelt å kjøre operasjonelle tester mot målapplikasjonen.

Systemtester

In Systemtesting systemet testes som en helhet og samspillet mellom komponentene, programvare og maskinvare kontrolleres.

In Android, Systemtesting inkluderer normalt

  • GUI-tester
  • Brukervennlighetstester
  • Ytelsestester
  • Stresstester

I listen ovenfor, Ytelsestesting får mer fokus. Du kan bruke verktøy som Tracanmeldelse å utføre ytelsestester på AndroidDette verktøyet kan hjelpe deg med å feilsøke applikasjonen din og profilere ytelsen. Trace-gjennomgangen er nå avskrevet til fordel for CPU-profiler.

Automatisert Android Testing

As Android er fragmentert, er testing på mange enheter nødvendig, og det koster penger. Automatisert Android Testing bidrar til å redusere disse kostnadene.

Fordeler med automatisering Android testing

  • Reduser tid for gjennomføring av testsaker
  • Øk produktiviteten i utviklingsprosessen din
  • Tidlig feildeteksjon, spar kostnad på vedlikehold av programvare
  • Finn og fiks feilene raskt ved implementering
  • Sikre kvaliteten på programvaren

Vi vil studere følgende 2 rammeverk

  • Android Testramme
  • Rammeverk for roboelektrisk testing
Ikke gå glipp av:

Android testramme

Et av standard testrammeverk for Android applikasjonene er Android testrammeverket. Det er godt integrert med Android SDK-verktøy, og arkitekturen har tre deler.

  1. Applikasjonspakken er målapplikasjonen din som må testes.
  2. InstrumentationTestRunner er Testsak runner som kjører testtilfeller på målapplikasjonen. Den inkluderer:
    • Testverktøy: SDK-verktøy for å bygge tester. De er integrert i IDE-et eller kjøres fra kommandolinjen.
    • MonkeyRunner: Et verktøy som tilbyr API-er for å skrive programmer som kontrollerer en Android enhet eller emulator utenfor Android kode.
  3. Testpakken er organisert i testprosjekter og følger en navnekonvensjon. Hvis applikasjonen som testes har pakkenavnet «com.mydomain.myapp», skal testpakken være «com.mydomain.myapp.test». Testpakken inneholder to objekter:
    • Testtilfelleklasser: inkludere testmetoder som skal kjøres på målapplikasjonen.
    • Imitasjonsobjekter: inkludere mock-data som vil bli brukt som eksempelinndata for testtilfeller.

Android Test Case-klasser

AndroidTestCase-klassediagram som viser JUnit og instrumenteringstesttilfellehierarki

  1. TestCase inkluderer JUnit metoder for å kjøre JUnit test
  2. TestSuite brukes til å kjøre et sett med testtilfeller
  3. InstrumentationTestSuite er en TestSuite som injiserer Instrumentation i InstrumentationTestCase før den kjøres.
  4. InstrumentationTestRunner kjører testtilfeller på målapplikasjonen.
  5. AndroidTestCase utvider JUnit TestCase med metoder for å få tilgang til ressurser som aktivitetskontekst.
  6. ApplicationTestCase verifiserer applikasjonsklassene i et kontrollert miljø.
  7. InstrumentationTestCase verifiserer en bestemt funksjon eller oppførsel, for eksempel brukergrensesnittets utdata.
  8. ActivityTestCase er en basisklasse som støtter testing av applikasjonsaktiviteter.
  9. ProviderTestCase er en klasse for testing av én enkelt ContentProvider.
  10. ServiceTestCase tester tjenesteklasser i et testmiljø og støtter tjenestens livssyklus.
  11. SingleLaunchActivityTestCase brukes til å teste enkeltaktiviteter med en InstrumentationTestCase.
  12. AktivitetsenhetTesttilfelle brukes til å teste enkeltstående isolert aktivitet.
  13. AktivitetInstrumentTestCase2 utvider JUnit TestCase-klassen og kobler deg til målapplikasjonen med instrumentasjon, slik at du kan få tilgang til GUI-komponenter og sende UI-hendelser som tastetrykk eller berøringer.

Nedenfor er et eksempel på ActivityInstrumentationTestCase. Den verifiserer brukergrensesnittets drift av et Kalkulator-program og kontrollerer riktigheten av brukergrensesnittets utdata.

Eksempel på ActivityInstrumentationTestCase2 som verifiserer utdata fra Kalkulator-grensesnittet Android

Rammeverk for roboelektrisk testing

Testing ved hjelp av Android Det er vanskelig å teste et rammeverk med en enhet eller emulator. Det er tregt å bygge og kjøre tester og krever mye utviklingsinnsats. For å løse dette problemet finnes det et annet alternativ: testrammeverket Robolectric.

Robolectric lar deg kjøre Android tester direkte på JVM-en uten behov for en enhet eller en emulator.

Klasser for roboelektriske testtilfeller

Robolectric kan utføre følgende handlinger:

  • Registrer deg og lag en Shadow-klasse
  • Avskjære lasting av Android klasse
  • Bruker Javahjelpe til med å overstyre metodedelene til Android klasse
  • Bind Shadow-objektet til Android klasse

Dette gjør at koden som testes kan kjøres uten en Android miljø.

Andre testrammeverk

Foruten testrammeverkene nevnt ovenfor, finnes det mange andre, som for eksempel:

Myter om Android Testing

Mange bedrifter utvikler Android Testing strategier som er basert på vanlige misoppfatninger. Denne delen undersøker noen få populære myter og realiteter Android testing.

Myte nr. 1: Alle Android enhetene er de samme, så testing på emulatorer er nok

En applikasjon kan fungere perfekt på emulatorer, men krasje under kjøring på noen ekte enheter.

Android Programkrasjdialogboks som vises under kjøring på en ekte enhet

Emulatorer er ikke tilstrekkelig for mobiltesting. Du må teste appen din på ekte enheter.

Myte nr. 2: Det er nok å teste på noen vanlige enheter

Applikasjonen din ser forskjellig ut på tvers av enheter fordi maskinvare, skjermstørrelser og minne varierer. Test på en rekke enheter, OS-versjoner, operatørnettverk og steder.

Myte nr. 3: Utforskende testing rett før lansering er nok

  • I de fleste testingstilfeller designer vi testtilfeller og utfører dem; i utforskende testing skjer design og utførelse sammen.
  • Det er ingen plan eller forberedelse, så testeren kjører hvilke som helst tester han velger. Noen funksjoner testes gjentatte ganger, mens andre aldri testes.

Myte nr. 4: Hvis det er noen feil i applikasjonen, vil brukerne forstå

  • Hvis applikasjonen ikke fungerer og har feil, avinstallerer brukerne appen din.
  • Kvalitetsproblemer er den første årsaken til dårlige anmeldelser Google Spill, skade omdømmet ditt og miste kundenes tillit.

Derfor er det viktig å ha en skikkelig Android teststrategi på plass.

Beste praksis i Android Testing

  • Applikasjonsutviklere bør lage testsakene samtidig når de skriver koden
  • Alle testtilfeller skal lagres i versjonskontroll, sammen med kildekode
  • Bruk kontinuerlig integrasjon og kjør tester hver gang koden endres
  • Unngå å stole kun på emulatorer og rootede enheter; bekreft resultatene på ekte maskinvare med en inspektør som f.eks. uiautomatorviewer

Spørsmål og svar

Nei. Moderne prosjekter bruker AndroidX-test med JUnit 4 og AndroidJUnitLøperen. Den JUnit 3 testtilfelleklasser beskrevet her ble avskrevet ved API 24 og forblir kun tilgjengelige for eldre programserier.

Maskinlæring reparerer lokatorer etter en layoutendring, grupperer duplikater av krasj- og ANR-rapporter, og forutsier hvilke tester en endring vil bryte, slik at en kortere pakke kjører per commit.

Copilot skriver vanlige onView- og kontrollmønstre fra et beskrevet scenario. Den kan ikke kjenne visningsidentifikatorene eller timingen din, så kjør hvert forslag én gang og juster matcherne først.

Espresso tester i din egen applikasjon og er rask og stabil. UI Automator krysser applikasjonsgrenser, så den passer til varsler, innstillinger og systemdialoger. Mange pakker bruker begge deler.

ActivityScenario API-et i AndroidX-test, vanligvis med en ActivityScenarioRule. Den flytter en aktivitet gjennom definerte livssyklustilstander uten å utvide en utdatert testtilfelleklasse.

Start med en billigtelefon, en mellomklassetelefon og en nyere flaggskiptelefon som strekker seg over to eller tre Android versjoner, pluss et nettbrett. Legg til enhetsskykjøringer før utgivelse i stedet for å kjøpe mer maskinvare.

De kjører på byggemaskinens JVM med skyggeklasser i stedet for en ekte enhet, så det er ingen pakking, installasjon eller emulatoroppstart. Det gjør dem praktiske for hver commit.

Googlesitt nåværende testbiblioteksett. Det pakker JUnit og Truth-utvidelser, ActivityScenario, Espresso og UI Automator bak én avhengighetsgruppe som fungerer på enheter, emulatorer og Robolectric.

Oppsummer dette innlegget med: