Afbryd test i mobilapplikation
Thomas Hamilton
⚡ Smart opsummering
Afbrydelsestestning kontrollerer, hvordan en mobilapplikation opfører sig, når et opkald, en alarm, en notifikation eller et netværksafbrydelse tager over, og om applikationen vender tilbage til sin nøjagtige tidligere tilstand, når afbrydelsen slutter.
Hvad er Interrupt Testing?
Afbryd test er en gren af mobilapplikationstest, der omhandler, hvordan en applikation reagerer på en afbrydelse og vender tilbage til sin tidligere tilstand. Afbrydelsen kommer udefra applikationen - operativsystemet, hardwaren eller en anden app - og testen verificerer, at ingen data, skærmtilstand eller igangværende transaktion går tabt, når kontrollen vender tilbage.
Interrupt Testing gælder for alle applikationstyper - web, mobil, standalone osv. Mangfoldigheden af enheder, netværk og konfigurationer gør det langt mere fremtrædende for mobil ansøgninger end for de andre.
Hvorfor har du brug for Interrupt Testing?
Hvad er den ene ting, der næsten altid sker, når du er i et møde? Du bliver afbrudt, ikke? Når det sker, blinker nogle mennesker ikke engang, nogle har brug for et minut til at komme tilbage, og nogle mister deres tankegang fuldstændigt. Kort sagt forsøger Interrupt Testing at finde ud af, hvilken adfærd din applikation udviser.
Hold al formulering til side et øjeblik, og se på en anden situation fra den virkelige verden. Lad os sige, at du ejer en lommelygte og tænder den. Batteriet løber tør, hvilket afbryder dens nuværende aktive tilstand. Udskift batterierne, og genopret den. Lommelygten burde tænde igen som normalt. Dette er use casen. En testdisciplin, der fokuserer på, om dette sker eller ej, er afbrydelsestestning.
Business casen er ligetil. En afbrydelse opstår på det værst tænkelige tidspunkt – midt i en betaling, midt i en upload, midt i en formular – og en bruger, der mister det arbejde, prøver sjældent igen. Nedbrud på CV'et, tomme skærme, duplikerede transaktioner og mistet formularinput er alle defekter, som kun en afbrydelse afslører, og derfor overlever de en funktionel proces, der aldrig afbryder noget.
Type af afbrydelser i mobilapplikation
Afbrydelser falder i en håndfuld velkendte grupper, opsummeret i illustrationen nedenfor.
Vi kender alle de almindelige afbrydelser, der normalt opstår. Her er et par af dem:
- Lavt batteri
- Batteri fuldt — under opladning
- Indgående telefonopkald
- Indgående SMS
- Indgående alarm fra en anden mobilapplikation
- Tilsluttet til opladning
- Tilsluttet fra opladning
- Enheden er slukket
- Påmindelser om applikationsopdateringer
- Alarm
- Tab af netværksforbindelse
- Gendannelse af netværksforbindelse
Denne liste er ikke udtømmende, men indeholder de mest almindelige scenarier. En praktisk måde at organisere den på er efter oprindelse: enhedsafhængige hændelser såsom batteri og opladning, brugerinitierede hændelser såsom at besvare et opkald eller skifte app, og eksterne hændelser såsom tab af signal i en elevator eller en tunnel.
Løsning i tilfælde af afbrydelse
Den forventede adfærd i tilfælde af disse afbrydelser er en af følgende fire:
- Kør i baggrunden: Afbrydelsen tager over, mens applikationen træder i baggrunden. Den får kontrol, når afbrydelsen slutter. For eksempel et telefonopkald eller FaceTime-opkald, som du deltager i, mens du læser en digital bog i iBooks (eller et lignende program). Når brugeren besvarer telefonen, venter iBooks, indtil opkaldet er færdigt, og genoptager derefter, når det slutter.
- Vis alarm: Alarmen forsvinder, og du arbejder som normalt. Beskeden "SMS modtaget" vises i headeren. Brugeren bekymrer sig ikke om det og fortsætter med at arbejde med applikationen som normalt. Andre mobilapp-alarmer, såsom en ny venneanmodning på Facebook eller en WhatsApp-besked, falder også ind under denne kategori. Men hvis brugeren beslutter sig for at læse beskeden, følges den adfærd, der er beskrevet i punkt 1. Hvis alarmen ignoreres, forbliver applikationens tilstand uændret.
- Opfordring til handling: Alarmer skal slukkes eller snoozes, før du kan fortsætte med at arbejde. Det samme gælder for appopdateringer. Du skal enten annullere eller acceptere ændringerne, før du fortsætter. Et andet eksempel er alarmen om lavt batteri – du kan vælge at fortsætte som normalt eller gå i lavstrømstilstand, hvis enheden tillader det.
- Ingen indvirkning: Et eksempel er en netværksforbindelse, der bliver tilgængelig, og din enhed opretter forbindelse til den. Når du tilslutter din enhed til opladning, er der heller ikke behov for en advarsel eller handlingsopfordring. Den vil sandsynligvis gøre sit arbejde, mens du fortsætter med at bruge din applikation.
Afhængigt af den afbrydelse, du tester for, skal du derfor forstå adfærden og se, om din applikation opfylder den. Den ovenfor beskrevne adfærd behøver heller ikke at være den samme for alle applikationer og enheder. Sørg for at finde ud af de specifikke detaljer for din mobilapp.
Afbryd test af testtilfælde med forventede resultater
Når den forventede løsning er aftalt, bliver hver afbrydelse en almindelig testcase med en udløser, en handling og et verificerbart resultat. Tabellen nedenfor viser, hvordan de fire ovenstående løsninger omsættes til konkrete scenarier.
| Afbrydelse | Testscenarie | Forventet resultat |
| Indgående telefonopkald | Udløs et opkald, mens en formular er halvt udfyldt, besvar den, og afslut derefter opkaldet | Applikationen flyttes til baggrunden og genoptages på den samme skærm med de indtastede data intakte |
| Indgående SMS eller push-alarm | Send en besked, mens en video eller upload er i gang, og ignorer banneret | Banneren vises og forsvinder; applikationens tilstand er uændret |
| Alarm | Lad en planlagt alarm udløses under en aktiv session og afvis den | Alarmen kræver først en opfordring til handling, derefter genoptager applikationen, hvor den stoppede |
| Advarsel om lavt batteriniveau | Tøm enheden til advarselstærsklen under en transaktion | Der vises en advarsel, transaktionen annulleres ikke, og lavstrømstilstanden afbryder ikke skærmen |
| Tab af netværksforbindelse | Deaktiver forbindelse midt i anmodningen, og gendan den derefter | Der vises en tydelig besked, der opstår intet nedbrud, og anmodningen fuldføres eller mislykkes sikkert ved gendannelse. |
| Opladning tilsluttet eller udtaget | Tilslut og frakobl opladeren under en aktiv session | Ingen påvirkning — applikationen fortsætter uden en synlig ændring |
| Påmindelse om applikationsopdatering | Send en opdateringsmeddelelse, mens applikationen er i brug | Brugeren kan annullere eller acceptere, og den underliggende skærm bevares ved begge valg. |
Behold én række pr. afbrydelse pr. kritisk skærm i stedet for én række pr. afbrydelse for hele applikationen. Betalingsskærmen, loginskærmen og en lang formular fejler hver især forskelligt, og et enkelt generisk tilfælde skjuler det.
Nu hvor vi forstår, hvad Interrupt Testing er, og hvad man skal validere, når man udfører det, er det tid til at tale om, hvordan man gør det.
Sådan laver du afbrydelsestest
Se på denne erklæring: iBooks skal køre i baggrunden, når brugeren modtager et indgående telefonopkald.
Ville du ikke kalde dette et funktionelt krav til iBooks-appen? Jeg ved det godt.
Så Interrupt Testing er en undergruppe af Funktionstest for en mobilapplikation. For at udføre Interrupt Testing følger du de samme testframeworks og -værktøjer for mobilapplikationer. Det er testernes færdighed at udtænke disse scenarier. Når det er gjort, designer du testcases og udfører dem på præcis samme måde som enhver anden test.
I praksis er sekvensen kort og gentagelig:
- Angiv de kritiske brugerrejser — login, betaling, upload, lange formularer, medieafspilning.
- Kortlæg alle plausible afbrydelser fra listen ovenfor på hver rejse.
- Aftal den forventede løsning for hver parring med produktejeren, da der ikke er nogen universel standard.
- Udfør afbrydelsen på det mest risikable tidspunkt, ikke i et inaktivt øjeblik, og genoptag derefter.
- Bekræft tilstand, data, session og hukommelse efter genoptagelse, ikke blot at applikationen stadig er åben.
For mere information om den bredere disciplin, se Mobil test tutorial og eksempelcases i Test af mobilapp.
Værktøjer og teknikker til simulering af afbrydelser
Ovenstående scenarier skal produceres on-demand i stedet for at blive ventet på, og hver platform tilbyder en måde at gøre det på.
- Android Udvidede kontroller for emulatoren: Emulatorens sidepanel simulerer et indgående opkald, en SMS, batteriniveau og opladerstatus samt mobilsignalstyrke, så det meste af afbrydelseslisten kan køres uden et andet håndsæt.
- iOS-simulator og Xcode: Forbindelses- og hardwaretilstande kan varieres fra simulatoren og fra enhedsindstillingerne, mens en parret fysisk enhed dækker de opkaldsscenarier, som en simulator ikke kan generere.
- En anden fysisk enhed: At ringe eller sende en besked til den enhed, der testes, fra en anden håndsæt er fortsat den mest nøjagtige måde at reproducere en reel afbrydelse på, især i tilfælde, der er følsomme over for tidsintervaller.
- Enhedsindstillinger: Flytilstand, Wi-Fi-knapper, Forstyr ikke, batterisparefunktion og planlagte alarmer dækker forbindelse og strømafbrydelser på rigtig hardware.
- Automatiseringsrammer: Den samme automatiseringsstak, der bruges til resten af din funktionelle suite, kan styre applikationen før og efter afbrydelsen, så CV-tjekket hævdes snarere end observeres.
- Skyer på rigtige enheder: En hosted enhedsfarm udvider dækningen på tværs af producenter og OS-versioner, hvilket er vigtigt, fordi håndtering af afbrydelser er et af de områder, hvor leverandørtilpasninger afviger mest.
Uanset mekanismen skal det nøjagtige tidspunkt for afbrydelsen registreres i testcasen. "Afbrydelse under upload" og "afbrydelse efter upload" er forskellige tests med forskellige fejltilstande.
Bedste praksis for afbrydelsestest
Et par vaner adskiller en nyttig afbrydelsessuite fra en øvelse i at afkrydse bokse.
- Afbryd i det værste øjeblik: Target i det øjeblik en transaktion gennemføres eller en fil skrives, fordi det er der, hvor tilstanden er mest skrøbelig.
- Test CV'et, ikke afbrydelsen: Fejlen opstår næsten altid efter kontrolreturnering, så påstande hører hjemme på den gendannede skærm.
- Dæk begge retninger af en netværksændring: At miste en forbindelse og at genvinde den er to separate tilfælde, og den anden springes over oftere.
- Varier varigheden: En to sekunders alarm og et ti minutters kald skubber applikationen gennem forskellige livscyklusstier, herunder at blive fjernet fra hukommelsen.
- Fordelt på tværs af OS-versioner og hardware i lav prisklassen: Baggrundsfjerning er langt mere aggressiv på begrænsede enheder, hvilket afslører defekter, som en flagskibstelefon skjuler.
- Automatiser de gentagne: Forbindelses- og batteriafbrydelser automatiseres nemt, hvilket frigør manuel indsats til opkalds- og alarmscenarier.
- Se ressourceforbrug samt tilstand: En afbrydelse, der lækker hukommelse eller dræner batteriet ved genoptagelse, er en defekt, selv når skærmen ser korrekt ud, hvilket forbinder dette arbejde med test af mobilapps ydeevne.
Er Interrupt Testing ikke det samme som Recovery Testing?
Nej det er ikke. Gendannelsestest validerer genoprettelse fra en fejl. En afbrydelse er ikke nødvendigvis en fejl – det er blot en afbrydelsetraction.
Det er ligesom forskellen mellem et komma og et punktum på engelsk. Sondringen er kun teknisk, men billedet er tydeligt. Recovery Testing spørger, om applikationen kan komme tilbage, efter at noget er gået i stykker; Interrupt Testing spørger, om noget overhovedet går i stykker, når noget andet træder i forgrunden.
Det er, hvad der er brug for at vide for at komme i gang med Interrupt Testing – en vigtig og intuitiv gren af mobilapplikationstest.
