Avbryt testing i mobilapplikasjon

Hva er avbruddstesting?

Avbryt testing er en gren av mobilapplikasjonstesting som omhandler hvordan en applikasjon reagerer på et avbrudd og går tilbake til sin tidligere tilstand. Avbruddet kommer utenfra applikasjonen – operativsystemet, maskinvaren eller en annen app – og testen bekrefter at ingen data, skjermtilstand eller pågående transaksjoner går tapt når kontrollen kommer tilbake.

Avbruddstesting gjelder for alle typer applikasjoner – web, mobil, frittstående og så videre. Mangfoldet av enheter, nettverk og konfigurasjoner gjør det langt mer fremtredende for mobil applikasjoner enn for de andre.

Hvorfor trenger du avbruddstesting?

Hva er det som nesten alltid skjer når du er i et møte? Du blir avbrutt, ikke sant? Når det skjer, blunker ikke noen engang, noen trenger et minutt for å komme tilbake, og noen mister tankerekken fullstendig. Enkelt sagt prøver avbruddstesting å finne ut hvilken oppførsel applikasjonen din viser.

Legg all formulering til side et øyeblikk og se på en annen situasjon fra den virkelige verden. La oss si at du eier en lommelykt og slår den PÅ. Batteriet går tomt, noe som avbryter den nåværende aktive tilstanden. Skift batteriene og gjenopprett strømmen. Lommelykten skal slå seg PÅ igjen som normalt. Dette er brukstilfellet. En testdisiplin som fokuserer på om dette skjer eller ikke, er avbruddstesting.

Forretningsargumentet er enkelt. Et avbrudd kommer på verst tenkelig tidspunkt – midt i en betaling, midt i en opplasting, midt i et skjema – og en bruker som mister det arbeidet prøver sjelden igjen. Krasj på CV-en, tomme skjermer, dupliserte transaksjoner og tapt skjemainndata er alle feil som bare et avbrudd avdekker, og det er derfor de overlever en funksjonell passasje som aldri avbryter noe.

Type avbrudd i mobilapplikasjon

Avbrudd faller inn i en håndfull kjente grupper, oppsummert i illustrasjonen nedenfor.

Vi er alle kjent med de vanlige avbruddene som vanligvis oppstår. Her er noen av dem:

• Lavt batteri
• Batteri fullt – under lading
• Innkommende telefonsamtale
• Innkommende SMS
• Innkommende varsel fra en annen mobilapplikasjon
• Plugget inn for lading
• Koblet fra lading
• Enheten er slått av
• Påminnelser om applikasjonsoppdateringer
• Alarm
• Tap av nettverkstilkobling
• Gjenoppretting av nettverkstilkobling

Denne listen er ikke uttømmende, men inkluderer de vanligste scenariene. En praktisk måte å organisere den på er etter opprinnelse: enhetsavhengige hendelser som batteri og lading, brukerinitierte hendelser som å svare på et anrop eller bytte apper, og eksterne hendelser som tap av signal i en heis eller tunnel.

Løsning i tilfelle avbrudd

Forventet oppførsel ved disse avbruddene er én av følgende fire:

1. Kjør i bakgrunnen: Avbruddet tar over, mens applikasjonen trer i bakgrunnen. Den får kontroll etter at avbruddet er over. For eksempel en telefonsamtale eller FaceTime-samtale du deltar i mens du leser en digital bok på iBooks (eller et lignende program). Når brukeren svarer på telefonen, venter iBooks til samtalen er ferdig, og fortsetter deretter når den er over.
2. Vis varsel: Varselet forsvinner, og du jobber som vanlig. Meldingen «SMS mottatt» vises i overskriften. Brukeren bryr seg ikke om det og fortsetter å jobbe med applikasjonen som normalt. Andre varsler fra mobilapper, for eksempel en ny venneforespørsel på Facebook eller en WhatsApp-melding, faller også inn under denne kategorien. Men hvis brukeren bestemmer seg for å lese meldingen, følges oppførselen beskrevet i punkt 1. Hvis varselet ignoreres, forblir applikasjonens tilstand uendret.
3. Oppfordring til handling: Alarmer må slås av eller settes på slumremodus før du fortsetter å jobbe. Det samme gjelder meldinger om appoppdateringer. Du må enten avbryte eller godta endringene før du fortsetter. Et annet eksempel er varselet om lavt batteri – du kan velge å fortsette som vanlig eller gå inn i en lavstrømsmodus, hvis enheten tillater det.
4. Ingen innvirkning: Et eksempel er en nettverkstilkobling som blir tilgjengelig, og enheten din kobler seg til den. Når du kobler enheten til ladestasjonen, er det heller ikke nødvendig med noe varsel eller handlingsfremmende trinn. Den vil sannsynligvis gjøre jobben sin mens du fortsetter å bruke appen.

Avhengig av avbruddet du tester for, bør du derfor forstå virkemåten og se om applikasjonen din oppfyller den. Virkemåten beskrevet ovenfor trenger heller ikke å være den samme for alle applikasjoner og enheter. Sørg for å finne ut de spesifikke detaljene for mobilappen din.

Avbryt testing av testtilfeller med forventede resultater

Når den forventede løsningen er avtalt, blir hver avbrudd en vanlig testsak med en utløser, en handling og et verifiserbart resultat. Tabellen nedenfor viser hvordan de fire løsningene ovenfor oversettes til konkrete scenarier.

Behold én rad per avbrudd per kritisk skjerm i stedet for én rad per avbrudd for hele applikasjonen. Betalingsskjermen, innloggingsskjermen og et langt skjema feiler forskjellig, og et enkelt generisk tilfelle skjuler det.

Nå som vi forstår hva avbruddstesting er og hva vi skal validere når vi utfører det, er det på tide å snakke om hvordan du gjør det.

Hvordan utføre avbruddstesting

Se på denne uttalelsen: iBooks må kjøre i bakgrunnen når brukeren mottar en innkommende telefonsamtale.

Ville du ikke kalt dette et funksjonskrav for iBooks-appen? Jeg vet det.

Så avbruddstesting er en undergruppe av Funksjonell testing for en mobilapplikasjon. For å utføre avbruddstesting følger du de samme testrammeverkene og verktøyene for mobilapplikasjoner. Det er testernes ferdighet å tenke ut disse scenariene. Når det er gjort, designer du testtilfellene og utfører dem på nøyaktig samme måte som enhver annen test.

I praksis er sekvensen kort og repeterbar:

1. List opp de kritiske brukerreisene – innlogging, betaling, opplasting, lange skjemaer, avspilling av media.
2. Kartlegg alle plausible avbrudd fra listen ovenfor på hver reise.
3. Avtal den forventede løsningen for hver paring med produkteieren, fordi det ikke finnes noen universell standard.
4. Utfør avbruddet på det mest risikable tidspunktet, ikke i et inaktivt øyeblikk, og fortsett deretter.
5. Bekreft status, data, økt og minne etter gjenopptakelse, ikke bare at applikasjonen fortsatt er åpen.

For mer informasjon om den bredere fagdisiplinen, se Mobil testing veiledningen og eksempeltilfellene i Test av mobilapp.

Verktøy og teknikker for å simulere avbrudd

Scenariene ovenfor må produseres på forespørsel i stedet for å vente på dem, og hver plattform tilbyr en måte å gjøre det på.

• Android Utvidede kontroller for emulator: Emulatorens sidepanel simulerer et innkommende anrop, en SMS, batterinivå og laderstatus, samt mobilsignalstyrke, slik at mesteparten av avbruddslisten kan kjøres uten et ekstra håndsett.
• iOS-simulator og Xcode: Tilkoblings- og maskinvaretilstander kan varieres fra simulatoren og fra enhetsinnstillinger, mens en paret fysisk enhet dekker anropsscenarier som en simulator ikke kan generere.
• En annen fysisk enhet: Å ringe eller sende melding til enheten som testes fra et annet håndsett er fortsatt den mest trofaste måten å gjenskape et reelt avbrudd på, spesielt i tilfeller der det er sensitivt for tid.
• Enhetsinnstillinger: Flymodus, Wi-Fi-brytere, Ikke forstyrr, batterisparing og planlagte alarmer dekker tilkobling og strømavbrudd på ekte maskinvare.
• Automatiseringsrammeverk: Den samme automatiseringsstakken som brukes for resten av funksjonspakken din, kan kjøre applikasjonen før og etter avbruddet, slik at CV-sjekken hevdes i stedet for å bli observert.
• Skyer på ekte enheter: En hosted enhetsfarm utvider dekningen på tvers av produsenter og operativsystemversjoner, noe som er viktig fordi avbruddshåndtering er et av områdene der leverandørtilpasninger avviker mest.

Uansett mekanisme, registrer det nøyaktige øyeblikket for avbruddet i testtilfellet. «Avbrudd under opplasting» og «avbrudd etter opplasting» er forskjellige tester med forskjellige feilmoduser.

Beste praksis for avbruddstesting

Noen få vaner skiller en nyttig avbruddssuite fra en boks-kryssøvelse.

• Avbryt i verste fall: Target i det øyeblikket en transaksjon gjennomføres eller en fil skrives, fordi det er der tilstanden er mest sårbar.
• Test CV-en, ikke avbruddet: Feilen dukker nesten alltid opp etter at kontrollen returneres, så påstander hører hjemme på den gjenopprettede skjermen.
• Dekk begge retninger av en nettverksendring: Å miste en forbindelse og gjenopprette den er separate tilfeller, og det andre hoppes over oftere.
• Varier varigheten: Et to sekunders varsel og et ti minutters kall skyver applikasjonen gjennom forskjellige livssyklusbaner, inkludert å bli fjernet fra minnet.
• Fordelt på OS-versjoner og avansert maskinvare: Bakgrunnsfjerning er langt mer aggressiv på begrensede enheter, som viser feil som en flaggskiptelefon skjuler.
• Automatiser de repeterbare: Tilkobling og batteriavbrudd automatiseres på en enkel måte, noe som frigjør manuell innsats for anrop og alarmscenarioer.
• Følg med på ressursbruk samt tilstand: En avbrudd som lekker minne eller tapper batteriet ved gjenopptagelse er en feil selv når skjermen ser riktig ut, noe som knytter dette arbeidet til ytelsestesting av mobilapper.

Er ikke avbruddstesting det samme som gjenopprettingstesting?

Nei det er ikke. Gjenopprettingstesting validerer gjenoppretting fra en feil. Et avbrudd er ikke nødvendigvis en feil – det er bare en forstyrrelsetracsjon.

Det er som forskjellen mellom komma og punktum på engelsk. Forskjellen er bare teknisk, men bildet er tydelig. Gjenopprettingstesting spør om applikasjonen kan komme tilbake etter at noe har gått i stykker, mens avbruddstesting spør om noe i det hele tatt går i stykker når noe annet kommer i forgrunnen.

Det er det man trenger å vite for å komme i gang med avbruddstesting – en viktig og intuitiv gren av testing av mobilapplikasjoner.

Spørsmål og svar