Avbryt testning i mobilapplikation
Redaktionellt team
⚡ Smart sammanfattning
Avbrottstestning kontrollerar hur en mobilapplikation beter sig när ett samtal, larm, meddelande eller nätverksavbrott tar över, och om applikationen återgår till sitt exakta tidigare tillstånd när avbrottet upphör.
Vad är avbrottstestning?
Avbryt testning är en gren av mobilapplikationstestning som handlar om hur en applikation reagerar på ett avbrott och återgår till sitt tidigare tillstånd. Avbrottet kommer utanför applikationen – operativsystemet, hårdvaran eller en annan app – och testet verifierar att ingen data, skärmtillstånd eller pågående transaktion går förlorad när kontrollen återgår.
Avbrottstestning gäller för alla typer av applikationer – webb, mobil, fristående och så vidare. Mångfalden av enheter, nätverk och konfigurationer gör det mycket mer framträdande för mobil applikationer än för de andra.
Varför behöver du avbrottstestning?
Vad är det som nästan alltid händer när man sitter i ett möte? Man blir avbruten, eller hur? När det händer blinkar vissa inte ens, vissa behöver en minut för att komma tillbaka, och vissa tappar tankegången helt. Enkelt uttryckt försöker avbrottstestning ta reda på vilket beteende din applikation uppvisar.
Lägg all formulering åt sidan en sekund och titta på en annan verklig situation. Säg att du äger en ficklampa och slår PÅ den. Batteriet tar slut, vilket avbryter dess nuvarande aktiva tillstånd. Byt ut batterierna och återställ den. Ficklampan bör tändas igen som vanligt. Detta är användningsfallet. En testdisciplin som fokuserar på huruvida detta händer eller inte är avbrottstestning.
Affärsargumentet är enkelt. Ett avbrott inträffar vid värsta möjliga tidpunkt – mitt i en betalning, mitt i en uppladdning, mitt i ett formulär – och en användare som förlorar det arbetet försöker sällan igen. Krascher på CV, tomma skärmar, duplicerade transaktioner och förlorad formulärinmatning är alla defekter som bara ett avbrott avslöjar, vilket är anledningen till att de överlever ett funktionellt pass som aldrig avbryter någonting.
Typ av avbrott i mobilapplikation
Avbrott faller inom en handfull välkända grupper, sammanfattade i illustrationen nedan.
Vi känner alla till de vanliga avbrott som normalt uppstår. Här är några av dem:
- Svagt batteri
- Batteri fullt — vid laddning
- Inkommande telefonsamtal
- Inkommande SMS
- Inkommande avisering från en annan mobilapplikation
- Inkopplad för laddning
- Utkopplad från laddning
- Enheten stängs av
- Påminnelser om applikationsuppdateringar
- Larmet
- Förlust av nätverksanslutningen
- Återställning av nätverksanslutningen
Denna lista är inte uttömmande men inkluderar de vanligaste scenarierna. Ett praktiskt sätt att organisera den är efter ursprung: enhetsberoende händelser som batteri och laddning, användarinitierade händelser som att svara på ett samtal eller byta app, och externa händelser som att förlora signalen i en hiss eller tunnel.
Upplösning vid avbrott
Det förväntade beteendet vid dessa avbrott är ett av följande fyra:
- Kör i bakgrunden: Avbrottet tar över medan appen hamnar i bakgrunden. Den får kontroll efter att avbrottet slutar. Till exempel ett telefonsamtal eller FaceTime-samtal som du deltar i medan du läser en digital bok i iBooks (eller en liknande applikation). När användaren svarar i telefonen väntar iBooks tills samtalet är avslutat och återupptas sedan när det slutar.
- Visa varning: Aviseringen försvinner och du arbetar som vanligt. Meddelandet "SMS mottaget" visas i rubriken. Användaren bryr sig inte om det och fortsätter att arbeta med applikationen som vanligt. Andra aviseringar i mobilappar, som en ny vänförfrågan på Facebook eller ett WhatsApp-meddelande, faller också inom denna kategori. Men om användaren väljer att läsa meddelandet följs beteendet som beskrivs i punkt 1. Om aviseringen ignoreras förblir applikationens tillstånd oförändrat.
- Uppmaning till handling: Larm måste stängas av eller snoozas innan du fortsätter att arbeta. Detsamma gäller för meddelanden om appuppdateringar. Du måste antingen avbryta eller acceptera ändringarna innan du fortsätter. Ett annat exempel är varningen för låg batterinivå – du kan välja att fortsätta som vanligt eller gå in i ett lågströmsläge, om enheten tillåter det.
- Ingen inverkan: Ett exempel är en nätverksanslutning som blir tillgänglig och din enhet ansluter till den. När du ansluter enheten för laddning behövs ingen varning eller uppmaning till åtgärd. Den kommer förmodligen att göra sitt jobb medan du fortsätter att använda din applikation.
Beroende på vilket avbrott du testar bör du därför förstå beteendet och se om din applikation uppfyller det. Beteendet som beskrivs ovan behöver inte heller vara detsamma för alla applikationer och enheter. Se till att ta reda på de specifika detaljerna för din mobilapp.
Avbrottstestning av testfall med förväntade resultat
När den förväntade lösningen är överenskommen blir varje avbrott ett vanligt testfall med en utlösande faktor, en åtgärd och ett verifierbart resultat. Tabellen nedan visar hur de fyra lösningarna ovan omsätts i konkreta scenarier.
| Avbrott | Testscenario | Förväntat resultat |
| Inkommande telefonsamtal | Utlösa ett samtal medan ett formulär är halvfullt ifyllt, svara på det och avsluta sedan samtalet | Applikationen flyttas till bakgrunden och återupptas på samma skärm med intakta inmatade data |
| Inkommande SMS eller push-avisering | Skicka ett meddelande medan en video eller uppladdning pågår och ignorera bannern | Bannern visas och försvinner; applikationens tillstånd är oförändrat |
| Larmet | Låt ett schemalagt larm utlösas under en aktiv session och avvisa det | Larm kräver först en uppmaning till handling, sedan återupptas applikationen där den stoppades |
| Låg batterilarm | Töm enheten till varningsgränsen under en transaktion | En varning visas, transaktionen avbryts inte och strömsparläget bryter inte skärmen. |
| Förlust av nätverksanslutningen | Inaktivera anslutningen mitt i en begäran och återställ den sedan | Ett tydligt meddelande visas, ingen krasch inträffar och begäran slutförs eller misslyckas säkert vid återställning. |
| Laddning inkopplad eller urkopplad | Ansluta och koppla från laddaren under en aktiv session | Ingen påverkan — applikationen fortsätter utan en synlig förändring |
| Påminnelse om applikationsuppdatering | Skapa en uppdateringsfråga medan applikationen används | Användaren kan avbryta eller acceptera, och den underliggande skärmen fortsätter att användas. |
Behåll en rad per avbrott per kritisk skärm istället för en rad per avbrott för hela applikationen. Betalningsskärmen, inloggningsskärmen och ett långt formulär misslyckas på olika sätt, och ett enda generiskt fall döljer det.
Nu när vi förstår vad Interrupt Testing är och vad vi ska validera när vi utför det, är det dags att prata om hur man gör det.
Hur man gör avbrottstestning
Titta på detta uttalande: iBooks måste köras i bakgrunden när användaren får ett inkommande telefonsamtal.
Skulle du inte kalla detta ett funktionellt krav för iBooks-appen? Jag vet att jag skulle göra det.
Så, Interrupt Testing är en undergrupp av funktions~~POS=TRUNC för en mobilapplikation. För att utföra avbrottstestning följer du samma testramverk och verktyg för mobilapplikationer. Det är testarnas skicklighet att utforma dessa scenarier. När det är klart designar du testfallen och kör dem på exakt samma sätt som vilket annat test som helst.
I praktiken är sekvensen kort och repeterbar:
- Lista de kritiska användarresorna – inloggning, betalning, uppladdning, långa formulär, uppspelning av media.
- Kartlägg alla rimliga avbrott från listan ovan på varje resa.
- Kom överens med produktägaren om den förväntade lösningen för varje parkoppling, eftersom det inte finns någon universell standard.
- Utför avbrottet vid det mest riskfyllda ögonblicket, inte i ett viloögonblick, och återuppta sedan.
- Verifiera tillstånd, data, session och minne efter återupptagande, inte bara att applikationen fortfarande är öppen.
För mer information om den bredare disciplinen, se Mobiltestning handledning och exempelfallen i Test av mobilappar.
Verktyg och tekniker för att simulera avbrott
Scenarierna ovan måste produceras på begäran snarare än att väntas på, och varje plattform erbjuder ett sätt att göra det.
- Android Utökade kontroller för emulatorn: Emulatorns sidopanel simulerar ett inkommande samtal, ett SMS, batterinivå och laddarstatus samt mobilsignalstyrka, så att det mesta av avbrottslistan kan tas upp utan en andra handenhet.
- iOS-simulator och Xcode: Anslutnings- och hårdvarustatus kan varieras från simulatorn och från enhetsinställningar, medan en parad fysisk enhet täcker de anropsscenarier som en simulator inte kan generera.
- En andra fysisk enhet: Att ringa eller skicka meddelanden till den testade enheten från en annan handenhet är fortfarande det mest trogna sättet att återskapa ett verkligt avbrott, särskilt i fall som är känsliga för tidpunkten.
- Enhetsinställningar: Flygplansläge, Wi-Fi-växlare, Stör ej, batterisparläge och schemalagda alarm täcker anslutning och strömavbrott på riktig hårdvara.
- Automatiseringsramverk: Samma automatiseringsstack som används för resten av din funktionella sviten kan driva applikationen före och efter avbrottet, så att CV-kontrollen görs gällande snarare än observeras.
- Moln för riktiga enheter: En värdbaserad enhetsfarm breddar täckningen mellan tillverkare och operativsystemversioner, vilket är viktigt eftersom avbrottshantering är ett av de områden där leverantörernas anpassningar skiljer sig mest åt.
Oavsett mekanism, registrera det exakta ögonblicket för avbrottet i testfallet. ”Avbrott under uppladdning” och ”avbrott efter uppladdning” är olika tester med olika fellägen.
Bästa praxis för avbrottstestning
Några vanor skiljer en användbar avbrottssvit från en övning där man kryssar i rutor.
- Avbryt i värsta fall: Target i det ögonblick en transaktion genomförs eller en fil skrivs, eftersom det är där tillståndet är som mest skört.
- Testa CV:t, inte avbrottet: Defekten uppstår nästan alltid efter att kontrollen returnerats, så påståenden hör hemma på den återställda skärmen.
- Täck båda riktningarna för en nätverksförändring: Att förlora en anslutning och återfå den är separata fall, och det andra hoppas över oftare.
- Variera varaktigheten: En två sekunders avisering och ett tio minuter långt anrop leder applikationen genom olika livscykelvägar, inklusive att tas bort från minnet.
- Spridda över OS-versioner och avancerad hårdvara: Bakgrundsborttagning är mycket mer aggressiv på begränsade enheter, vilket visar defekter som en flaggskeppstelefon döljer.
- Automatisera de repeterbara: Avbrott i anslutning och batteri automatiseras på ett smidigt sätt, vilket frigör manuell ansträngning för samtal och larm.
- Titta på resursanvändning samt tillstånd: Ett avbrott som läcker minne eller tömmer batteriet vid återupptagning är en defekt även när skärmen ser korrekt ut, vilket kopplar detta arbete till prestandatestning av mobilappar.
Är inte avbrottstestning detsamma som återställningstest?
Nej det är det inte. Återhämtningstestning validerar återställning från ett fel. Ett avbrott är inte nödvändigtvis ett fel – det är bara entraction.
Det är som skillnaden mellan ett komma och en punkt på engelska. Skillnaden är bara teknisk, men bilden är tydlig. Återställningstestning frågar om applikationen kan återställas efter att något har gått sönder; Avbrottstestning frågar om något alls går sönder när något annat kommer i förgrunden.
Det är vad man behöver veta för att komma igång med avbrottstestning – en viktig och intuitiv gren av mobilapplikationstestning.
