Free Press

En komplett guide för testning av mobilapplikationer med djupgående handledningar:

Mobilteknik och smarta enheter är trenden nu och kommer att förändra framtiden för världen som vi känner den. Det kan vi alla intyga, eller hur? Nu blir det amatörmässigt om jag listar upp vad vi använder dessa mobila enheter till. Ni vet alla det – kanske bättre än vad vi gör.

Låt oss gå direkt till vad den här handledningen kommer att handla om.

Den kompletta listan över 30+ handledningar om mobiltestning:

Introduktion till mobiltestning:

Handledning nr 1: Introduktion till mobiltestning
Handledning nr 2: Testning av iOS-applikationer
Handledning nr 3: Testning av Android-applikationer
Handledning nr 4: Utmaningar och lösningar för mobiltestning
Handledning nr 5: Varför är det svårt med mobiltestning?

Testning av mobila enheter:

Tutorial #6: Testa en Android-version när den tas bort från marknaden
Tutorial #7: Hur man testar mobilappar på lågprismodeller
Tutorial #8: Fälttestning av mobilapplikationer
Tutorial #9: Telefonmodell Vs OS-version:

Mobile UI Testing:

Tutorial #10: UI Testing of Mobile Apps
Tutorial #11: Test av mobila responsiva applikationer

Mobila testtjänster:

Tutorial #12: Test av mobila applikationer i molnet
Tutorial #13: Test av mobila applikationer i molnet
Tutorial #13: Test av mobila applikationer i molnet: Mobila testtjänster
Tutorial #14: Betatestning av mobilapplikationer
Tutorial #15: Utvecklingsföretag för mobilapplikationer
Tutorial #16: Leverantörer av molnbaserade testtjänster för mobilapplikationer

Prestanda- och säkerhetstester för mobilapplikationer:

Tutorial #17: Testning av mobila applikationers prestanda med BlazeMeter
Tutorial #18: Riktlinjer för testning av mobilapplikationers säkerhet

Verktyg för mobiltestning:

Tutorial #19: Testning av mobilapplikationers säkerhet

Tutorial #19: Testning av mobilapplikationers säkerhet: Android App Testing Tools
Tutorial #20: Best Mobile App Security Testing Tools
Tutorial #21: 58 Best Mobile Testing Tools

Mobile Automation Testing:

Tutorial #22: Appium Mobile Automation Tool tutorial
Tutorial #23: Appium Studio tutorial
Tutorial #24: Automatisera Android-applikationer med hjälp av TestComplete Tool
Tutorial #25: Robotium tutorial – Android App UI Testing Tool
Tutorial #26: Robotium tutorial – Android App UI Testing Tool
Tutorial #26: Robotium tutorial: Selendroid Tutorial: Mobile Automation Framework
Tutorial #27: pCloudy Tutorial: Mobilapptestning på riktiga enheter
Tutorial #28: Katalon Studio & Kobitons molnbaserade enhetsfarm Tutorial

Mobiltestkarriär:

Tutorial #29: Hur man snabbt får ett jobb inom mobiltestning
Tutorial #30: Hur man snabbt får ett jobb inom mobiltestning
Tutorial #30: Mobilapptestarjobs: Handledning #31: Intervjufrågor om mobiltestning, del 2

*************************************************************

Låt oss börja med den första handledningen i serien.

Tutorial #1: Introduktion till testning av mobila applikationer

Den tid är förbi då telefonen var en apparat som satt i ett hörn och måste ringa för att få vår uppmärksamhet, eller då en dator var en maskin som endast ett fåtal personer använde – de är nu en förlängning av vår varelse – ett fönster mot världen och virtuella tjänare som gör som de blir tillsagda.

Datorer var ett raseri och förändrade hur vi människor tänkte, betedde oss, lärde oss och existerade.

Nuförtiden har mobilitetslösningar tagit över marknaden. Människor vill inte slå på sina bärbara datorer/PC:n för allting, utan vill snarare att deras handhållna enheter ska utföra allting snabbt.

Därmed bör de mobila lösningar som vi levererar till våra kunder testas mycket väl. Den här handledningen är avsedd för de personer som redan håller på med mobiltestning eller de som har övergått till det på senare tid. Eftersom vi redan har många handledningar om definitioner av terminologier relaterade till mobiltestning, kommer vi att direkt behandla omfattningen av denna handledning.

Denna handledning kommer att vara både en introduktion och din guide till mobiltestning. Så läs igenom!

Typer av mobiltestning

Det finns i stort sett två typer av testning som äger rum på mobila enheter:

#1. Hårdvarutestning:

Enheten omfattar interna processorer, intern hårdvara, skärmstorlekar, upplösning, utrymme eller minne, kamera, radio, Bluetooth, WIFI osv. Detta kallas ibland för enkel ”mobiltestning”.

#2. Testning av programvara eller program:

De program som fungerar på mobila enheter och deras funktionalitet testas. Den kallas ”Mobile Application Testing” för att skilja den från den tidigare metoden. Även när det gäller mobila applikationer finns det några grundläggande skillnader som är viktiga att förstå:

a) Nativa applikationer:
b) Mobila webbappar är appar på serversidan för att få tillgång till webbplatser på mobilen med hjälp av olika webbläsare som Chrome och Firefox genom att ansluta till ett mobilt nätverk eller trådlöst nätverk som WIFI.
c) Hybridappar är kombinationer av en inbyggd app och en webbapp. De körs på enheter eller offline och skrivs med hjälp av webbteknik som HTML5 och CSS.

Det finns några grundläggande skillnader som skiljer dem åt:

• Nativa appar är anpassade till en enda plattform medan mobila webbappar är anpassade till flera plattformar.
• Nativa appar skrivs i plattformar som SDK:er medan mobila webbappar skrivs med webbteknik som HTML, CSS, asp.net, Java, PHP.
• För en inhemsk app krävs installation, men för mobila webbappar krävs ingen installation.
• En infödd app kan uppdateras från Play Store eller App Store medan mobila webbappar är centraliserade uppdateringar.
• Många infödda appar kräver ingen internetuppkoppling men för mobila webbappar är det ett måste.
• En infödd app fungerar snabbare jämfört med mobila webbappar.
• Nativa appar installeras från appbutiker som Google play store eller app store där mobila webbappar är webbplatser och är endast tillgängliga via Internet.

Resten av artikeln kommer att handla om testning av mobila applikationer.

Betydelsen av testning av mobila applikationer

Testning av applikationer på mobila enheter är mer utmanande än testning av webbapplikationer på skrivbordet på grund av

• Olika utbud av mobila enheter med olika skärmstorlekar och hårdvarukonfigurationer som ett hårt tangentbord, virtuellt tangentbord (pekskärm) och trackball etc.
• Ett brett utbud av mobila enheter som HTC, Samsung, Apple och Nokia.
• Olika mobila operativsystem som Android, Symbian, Windows, Blackberry och IOS.
• Olika versioner av operativsystem som iOS 5.x, iOS 6.x, BB5.x, BB6.x etc.
• Olika mobilnätsoperatörer som GSM och CDMA.
• Frekventa uppdateringar – (som Android- 4.2, 4.3, 4.4, iOS-5.x, 6.x) – med varje uppdatering rekommenderas en ny testcykel för att se till att ingen applikationsfunktionalitet påverkas.

Som med alla applikationer är testning av mobilapplikationer också mycket viktigt, eftersom kundkretsen vanligtvis är i miljontals för en viss produkt – och en produkt med buggar är aldrig uppskattad. Det resulterar ofta i monetära förluster, juridiska problem och irreparabla skador på varumärkets image.

Grundläggande skillnad mellan testning av mobila och stationära applikationer:

Få uppenbara aspekter som skiljer testning av mobilapplikationer från testning av skrivbordsapplikationer

• På skrivbordet testas applikationen på en central processorenhet. På en mobil enhet testas applikationen på handenheter som Samsung, Nokia, Apple och HTC.
• Mobilenhetens skärmstorlek är mindre än en stationär dator.
• Mobilenheter har mindre minne än en stationär dator.
• Mobiler använder nätverksanslutningar som 2G, 3G, 4G eller WIFI där stationära datorer använder bredbands- eller uppringningsanslutningar.
• Automationsverktyget som används för testning av skrivbordstillämpningar kanske inte fungerar på mobila tillämpningar.

Typer av testning av mobila tillämpningar:

För att ta itu med alla ovanstående tekniska aspekter utförs följande typer av testning av mobila tillämpningar.

• Användbarhetstestning- För att se till att mobilappen är lätt att använda och ger kunderna en tillfredsställande användarupplevelse
• Kompatibilitetstestning- Testning av applikationen i olika mobila enheter, webbläsare, skärmstorlekar och OS-versioner i enlighet med kraven.
• Gränssnittstestning- Testning av menyalternativ, knappar, bokmärken, historik, inställningar och navigeringsflöde i applikationen.
• Testning av tjänster- Testning av applikationens tjänster online och offline.
• Resurstestning på låg nivå: Testning av minnesanvändning, automatisk radering av temporära filer, växande problem i den lokala databasen kallas testning av resurser på låg nivå.
• Prestandatestning – Testning av applikationens prestanda genom att ändra anslutningen från 2G, 3G till WIFI, dela dokumenten, batteriförbrukning etc.
• Driftstestning – Testning av säkerhetskopior och återhämtningsplan om ett batteri går ner eller dataförlust vid uppgradering av applikationen från en butik.
• Installationstest- Validering av applikationen genom att installera/avinstallera den på enheterna.
• Säkerhetstestning- Testning av en applikation för att validera om informationssystemet skyddar data eller inte.

Teststrategi för mobilapplikationer

Teststrategin ska säkerställa att alla riktlinjer för kvalitet och prestanda uppfylls. Några tips på detta område:

1) Val av enheter – Analysera marknaden och välj de enheter som används allmänt. (Detta beslut beror till största delen på kunderna. Kunden eller appbyggarna tar hänsyn till popularitetsfaktorn för vissa enheter samt marknadsföringsbehovet för applikationen för att bestämma vilka telefoner som ska användas för testning.)

2) Emulatorer – Användningen av dessa är ytterst användbar i utvecklingens inledande skeden, eftersom de möjliggör en snabb och effektiv kontroll av appen. Emulatorn är ett system som kör programvara från en miljö till en annan miljö utan att ändra själva programvaran. Den duplicerar funktionerna och fungerar på det riktiga systemet.

Typer av mobila emulatorer

• Enhetsemulator – tillhandahålls av enhetstillverkare
• Browseremulator – simulerar mobila webbläsarmiljöer.
• Operativsystememulator- Apple tillhandahåller emulatorer för iPhones, Microsoft för Windows-telefoner och Google Android-telefoner

Rekommenderat verktyg

#1) Kobiton

Kobiton är en prisvärd och mycket flexibel molnbaserad plattform för mobilupplevelser som påskyndar testning och leverans av native-, webb- och hybridappar på både Android och iOS med hjälp av verkliga enheter. Deras nya skriptlösa testautomatisering hjälper team utan kodningsexpertis att enkelt generera Appium-skript med öppen standard.

=> Besök Kobitons webbplats

Lista över ett fåtal gratis och lättanvända emulatorer för mobila enheter

i. Mobiltelefonemulator – Används för att testa telefoner som iPhone, Blackberry, HTC, Samsung etc.

ii. MobiReady – Med denna kan vi inte bara testa webbapplikationen utan även kontrollera koden.

iii. Responsivepx – Den kontrollerar webbsidornas svar, utseende och funktionalitet.

iv. Screenfly – Det är ett anpassningsbart verktyg och används för att testa webbplatser under olika kategorier.

3) När en tillfredsställande utvecklingsnivå har uppnåtts för mobilappen kan du gå över till att testa på fysiska enheter för att få mer verklighetstrogna scenarion baserade tester.

4) Överväg molnbaserade tester: Cloud computing är i princip att köra enheter på flera system eller nätverk via Internet där applikationer kan testas, uppdateras och hanteras. För teständamål skapas den webbaserade mobilmiljön på en simulator för att få tillgång till mobilappen.

Pros:

• Säkerhetskopiering och återställning- Molntjänster tar automatiskt säkerhetskopiering av dina data från en avlägsen plats vilket gör att det är enkelt att återställa och återskapa data. Och dessutom är lagringskapaciteten obegränsad.
• Moln kan nås från olika enheter och var som helst.
• Molnberäkningar är kostnadseffektiva, enkla att använda, underhålla och uppdatera.
• Snabb och snabb driftsättning.
• Webbaserat gränssnitt.
• Kan köra samma skript på flera enheter parallellt.

Konsekvenser

• Mindre kontroll- Eftersom applikationen körs i fjärr- eller tredjepartsmiljön har användaren begränsad kontroll och tillgång till funktionerna.
• Problem med internetanslutning- inställningen sker på internet. Nätverksproblem påverkar tillgängligheten och funktionen
• Säkerhets- och integritetsfrågor- Cloud computing är en internetdrift och ingenting på internet är helt säkert, så risken för datahaveri är större.

5) Automation vs. Manuell testning

• Om applikationen innehåller ny funktionalitet, testa den manuellt.
• Om applikationen kräver testning en eller två gånger, gör det manuellt.
• Automatisera skript för regressionstestfall. Om regressionstesterna upprepas är automatiserad testning perfekt för det.
• Automatisera skript för komplexa scenarier som är tidskrävande om de utförs manuellt.

Två typer av automatiseringsverktyg finns tillgängliga för att testa mobilapplikationer:

Objektsbaserade verktyg för mobiltestning – automatisering genom att mappa element på enhetens skärm till objekt. Detta tillvägagångssätt är oberoende av skärmstorlek och används främst för Android-enheter.

• Eg:- Ranorex, jamo solution

Bildbaserade verktyg för mobiltestning- skapar automationsskript baserade på elementens skärmkoordinater.

• Eg:- Sikuli, Egg Plant, RoutineBot

6) Nätverkskonfigurering är också en nödvändig del av mobiltestning. Det är viktigt att validera applikationen på olika nätverk som 2G, 3G, 4G eller WIFI.

Testfall för testning av en mobilapplikation

För att testa en mobilapplikation krävs, förutom funktionalitetsbaserade testfall, särskilda testfall som bör täcka följande scenarier.

• Batteriförbrukning- Det är viktigt att hålla koll på batteriförbrukningen när applikationen körs på de mobila enheterna.
• Applikationens hastighet- svarstiden på olika enheter, med olika minnesparametrar, med olika nätverkstyper osv.
• Datakrav – För installation samt för att kontrollera om användaren med begränsad dataplan kommer att kunna ladda ner den.
• Minnesbehov – återigen, för att ladda ner, installera och köra
• Applikationens funktionalitet – se till att applikationen inte kraschar på grund av nätverksfel eller något annat.

Ladda ner några exempel på testfall för testning av mobila applikationer:

=> Ladda ner provtestfall för mobilapplikationer

Typiska aktiviteter och förfaranden vid testning av mobilapplikationer

Testningens omfattning beror på ett antal krav som ska kontrolleras eller omfattningen av de ändringar som gjorts i appen. Om ändringarna är få räcker det med en runda sanity testing. Vid större och/eller komplexa ändringar rekommenderas en fullständig regression.

Ett exempel på ett projekt för testning av en applikation: ILL (International Learn Lab) är ett program som är utformat för att hjälpa administratörer och utgivare att skapa webbplatser i samarbete. Med hjälp av en webbläsare väljer lärare från en uppsättning funktioner för att skapa en klass som uppfyller deras krav.

Mobiltestningsprocess:

Steg 1. Identifiera de olika typerna av testning: Eftersom en ILL-applikation är tillämplig för webbläsare är det obligatoriskt att testa applikationen på alla webbläsare som stöds med olika mobila enheter. Vi måste göra användbarhets-, funktions- och kompatibilitetstester på olika webbläsare med kombinationer av manuella och automatiska testfall.

Steg #2. Manuell och automatiserad testning: Metodiken som följs för det här projektet är agil med en iteration på två veckor. Varannan vecka släpper utvecklingsteamet ett nytt bygge för testteamet och testteamet kör sina testfall i QA-miljön. Automatiseringsteamet skapar skript för den grundläggande funktionaliteten och kör skript som hjälper till att avgöra om den nya byggnaden är tillräckligt stabil för att kunna testas. Det manuella testteamet kommer att testa den nya funktionaliteten.

JIRA används för att skriva acceptanskriterier, underhålla testfall och logga/reverifiera defekter. När iterationen är över hålls ett iterationsplaneringsmöte där dev. Teamet, produktägaren, affärsanalytikern och QA-teamet diskuterar vad som gick bra och vad som behöver förbättras.

Steg 3. Betatestning: När regressionstesterna har slutförts av QA-teamet flyttas byggnaden till UAT. Användaracceptanstestning utförs av kunden. De verifierar alla buggar på nytt för att se till att alla buggar har rättats och att applikationen fungerar som förväntat i alla godkända webbläsare.

Steg 4. Prestandatester: Prestandatestningsteamet testar webbapplikationens prestanda med hjälp av JMeter-skript och med olika belastningar på applikationen.

Steg #5. Testning av webbläsare: Webbapplikationen testas i flera webbläsare – både med hjälp av olika simuleringsverktyg och fysiskt med riktiga mobila enheter.

Steg #6. Lanseringsplan: Efter var fjärde vecka flyttas testningen till staging, där en sista runda av end to end-testning på dessa enheter utförs för att se till att produkten är redo för produktion. Och sedan går den live!

*****************************************

Hur man testar mobilapplikationer på både Android- och iOS-plattformar

Det är mycket viktigt för de testare som testar sina appar på både iOS- och Android-plattformen att känna till skillnaden mellan de båda. iOS och Android har en hel del skillnader när det gäller utseende och känsla, appvisningar, kodningsstandarder, prestanda osv.

Grundläggande skillnader mellan Android- och iOS-testning

Du kanske har gått igenom alla handledningar, jag har lagt in några viktiga skillnader här, som i sin tur kommer att hjälpa dig som en del av din testning:

#1) Eftersom vi har många Android-enheter tillgängliga på marknaden och alla har olika skärmupplösningar och storlekar, är detta en av de viktigaste skillnaderna.

Till exempel är Samsung S2 storleken för liten jämfört med Nexus 6. Det finns stora möjligheter att din applayout och design förvrängs på en av enheterna. Sannolikheten är låg i iOS eftersom det bara finns ett antal enheter på marknaden och av dessa har många telefoner liknande upplösningar.

Exempelvis hade alla äldre versioner liknande storlek innan iPhone 6 och senare kom till.

#2) Ett exempel för att bekräfta ovanstående är att i Android måste utvecklarna använda 1x,2x,3x,4x och 5x bilder för att stödja bildupplösningar för alla enheter, medan iOS bara använder 1x,2x och 3x. Det blir dock testarens ansvar att se till att bilderna och andra UI-element visas korrekt på alla enheter.

Du kan hänvisa till nedanstående diagram för att förstå begreppet bildupplösningar:

#3) Eftersom vi har en marknad översvämmad av Android-enheter måste koden skrivas på ett sådant sätt att prestandan förblir jämn. Det är alltså ganska troligt att din app kan bete sig långsamt på enheter med lägre prestanda.

#4) Ett annat problem med Android är att mjukvaruuppgraderingar inte är tillgängliga för alla enheter på en gång. Enhetstillverkarna bestämmer när de vill uppgradera sina enheter. Det blir en mycket svår uppgift att testa allting både med det nya och det gamla operativsystemet.

Det blir också en besvärlig uppgift för utvecklarna att ändra sin kod för att stödja båda versionerna.

När Android 6.0 kom skedde till exempel en stor förändring eftersom operativsystemet började stödja behörigheter på appnivå. För att förtydliga ytterligare kunde användaren ändra behörigheter (plats, kontakter) även på appnivå.

Nu har testteamet ansvaret för att se till att det visas en behörighetsskärm vid lanseringen av appen på Android 6.0 och högre och att det inte visas en behörighetsskärm på de lägre versionerna.

#5) Ur testperspektivet är testning av preproduktionsbyggen (dvs. beta-versioner) olika på båda plattformarna. Om en användare i Android läggs till i listan över beta-användare kan han eller hon se den uppdaterade betaversionen i Play Store endast om han eller hon är inloggad i Play Store med samma e-post-ID som läggs till som beta-användare.

Nyckelfaktorer i mobiltestning

Jag har arbetat med mobiltestning under de senaste två åren på både iOS- och Android-plattformen och alla nyckelpunkter som nämns nedan i den här handledningen kommer från min personliga erfarenhet och vissa har härletts från de problem som uppstått i projektet.

Definiera ditt eget testningsomfång

Alla har sin egen stil för testning. Vissa testare fokuserar bara på vad de ser med ögonen och resten brinner för allt som fungerar bakom kulisserna på en mobilapplikation.

Om du är en iOS/Android-testare föreslår jag att du åtminstone bekantar dig med några vanliga begränsningar/grundläggande funktioner för Android eller iOS eftersom det alltid ger ett mervärde till vår teststil. Jag vet att saker och ting är svåra att förstå utan att citera exempel.

Nedan följer några exempel:

• Vi kan inte ändra behörigheter som kamera, lagringsutrymme etc. på appnivå i Android-enheter som är under version 6.0.1.
• För iOS under version 10.0 fanns inte call kit. För att ge dig en kortfattad beskrivning används call kit av en samtalsapp och visar helskärmsvisning när en användare får ett samtal från samtalsappar som WhatsApp, Skype osv. För iOS-versioner under 10.0 ser vi dessa samtal som en notifieringsbanner.
• Många av er kanske har stött på problem i Paytm där appen inte omdirigerar dig till bankens betalningssida om du vill lägga till pengar i din plånbok. Vi tror att ovanstående är ett problem med vår bank eller Paytm-server men det är bara att vår AndroidSystemWebView inte är uppdaterad. Lite kunskap om programmering är alltid till hjälp för dig och att dela med ditt team.
• Med enkla ord, närhelst en app öppnar en webbsida i den, bör AndroidSystemWebView uppdateras.

Begräns inte din testning

Testning bör inte bara begränsas till att utforska mobilappen och logga buggar. Vi som QA bör vara medvetna om alla förfrågningar som vi träffar vår server och det svar som vi får ut av den.

Konfigurera Putty för att visa loggar eller verifiera sumo-logik för loggar beroende på vad som används i ditt projekt. Det hjälper dig inte bara att känna till applikationens end-to-end-flöde utan gör dig också till en bättre testare eftersom du får fler idéer och scenarier nu.

Reason: Inget kommer in i den här världen utan anledning. Varje uttalande bör ha en giltig anledning bakom sig. Anledningen till att analysera loggarna är att många undantag observeras i loggarna men de visar ingen påverkan på användargränssnittet och därför lägger vi inte märke till det.

Så, ska vi ignorera det?

Nej, det ska vi inte. Det har ingen inverkan på användargränssnittet, men det kan vara ett futuristiskt problem. Vi kan potentiellt se vår app krascha om den här typen av undantag fortsätter att smyga sig in. Eftersom vi har nämnt App Crash i den sista meningen, leder detta till att QA måste ha tillgång till crashlytics för projektet.

Crashlytics är ett verktyg där krascher loggas tillsammans med tid och enhetsmodell.

Nu är frågan här borta att om testaren har sett appen krascha, varför behöver han då bry sig om crashlytics?

Svaret på detta är ganska intressant. Det finns vissa krascher som kanske inte syns på användargränssnittet men som loggas i crashlytics. Det kan vara en minneskrasch eller några fatala undantag som kan påverka prestandan senare.

Testning av interaktion mellan olika plattformar

Testning av interaktion mellan olika plattformar är mycket viktigt.

Till exempel: Säg att du arbetar med ett chattprogram som WhatsApp som har stöd för att skicka bilder och videoklipp och att programmet byggs på både iOS- och Android-plattformar (utvecklingen kan vara synkroniserad eller inte)

Säkerställ att du testar kommunikationen mellan Android och iOS, eftersom iOS använder ”Objective C” medan Android-programmering är Javabaserad och på grund av att båda är byggda på olika plattformar måste ibland extra korrigeringar göras på app-sidan för att känna igen strängar som kommer från olika språkplattformar.

Håll ett öga på storleken på din mobilapp

Ett annat viktigt råd för mobiltestare – Kontrollera storleken på din app efter varje version.

Vi bör se till att appens storlek inte når en punkt där inte ens vi som slutanvändare vill ladda ner appen på grund av dess stora storlek.

Testning av appuppgraderingsscenarier

För mobiltestare är testning av appuppgraderingar mycket viktigt. Se till att appen inte kraschar vid uppgradering eftersom utvecklingsteamet kan ha gjort en felmatchning av ett versionsnummer.

Datalagring är också lika viktigt eftersom de inställningar som användaren har sparat i den tidigare versionen bör behållas när han uppgraderar appen.

En användare kan t.ex. ha sparat sina bankkortsuppgifter i appar som PayTm etc.

Enhetens operativsystem kanske inte stöder appen

Låter det intressant?

Ja, många enheter kanske inte stöder din app. Många av er vet säkert att leverantörerna skriver sina egna wrappers ovanpå US och det kan vara möjligt att en SQL-fråga i din app inte är kompatibel med enheten, vilket leder till ett undantag och kan resultera i att appen inte ens kan startas på den telefonen.

Punkten här är – Försök att använda din app på dina egna enheter, förutom de som du använder på kontoret. Det är fullt möjligt att du ser några problem med din app.

App Permission Testing

Nästa punkt på listan är Permission Testing av mobilappar. Nästan varannan app ber sina användare om tillgång till telefonens kontakter, kamera, galleri, plats osv. Jag har sett några testare som gör ett misstag genom att inte testa rätt kombinationer av dessa behörigheter.

Jag kan minnas ett exempel i realtid när vi testade en chattapp som hade alla funktioner för att dela bilder och ljudfiler. Tillståndet för lagring var inställt på NEJ.

När en användare klickar på kameraalternativet öppnas det aldrig förrän tillståndet för lagring är inställt på JA. Scenariot ignorerades eftersom Android Marshmallow hade en funktionalitet som innebär att om lagringsbehörigheten är inställd på NEJ kan kameran inte användas för den appen.

Området sträcker sig längre än vad vi har diskuterat i ovanstående stycke. Vi bör se till att appen inte ber om några behörigheter som inte används.

En slutanvändare som är bekant med programvarubranschen kanske inte laddar ner en app där för många behörigheter begärs. Om du har tagit bort någon funktion från din app, se då till att ta bort behörighetsskärmen för samma sak.

Genomföra med liknande och populära appar på marknaden

Moralen i historien – Om du någonsin är osäker, så sluta inte själv. Att jämföra med andra liknande appar på samma plattform kan stärka ditt argument för att den funktionalitet som testas kommer att fungera eller inte.

Få en överblick över Apples kriterium för avvisning av byggnader

Sluttligen har majoriteten av er kanske stött på situationer där era byggnader avvisats av Apple. Jag vet att det här ämnet inte kommer att intressera större delen av läsarna, men det är alltid bra att känna till Apples avvisningsregler.

Som testare blir det svårt för oss att ta hand om de tekniska aspekterna, men det finns ändå vissa avvisningskriterier som testarna kan ta hand om.

För mer information om detta kan du klicka här.

Var alltid på framkant

Som testare får du inte låta saker och ting passera över till dig från utvecklingsteamet/cheferna. Om du brinner för testning ska du alltid vara på första parkett. Försök att engagera dig i aktiviteter som äger rum långt innan koden kommer till din hink för att testas.

Mast av allt, fortsätt att titta på JIRA, QC, MTM eller vad som än används i ditt projekt för alla de senaste uppdateringarna om biljetter från kunder och affärsanalytiker. Var också redo att dela med dig av dina synpunkter om du behöver ändringar. Detta gäller för alla testare som arbetar på olika domäner och plattformar.

Intill och om vi inte känner produkten som vår egen borde vi aldrig ge förslag på nya förbättringar eller ändringar av den befintliga funktionaliteten.

Lämna appen i bakgrunden under lång tid (12-24 timmar)

Jag vet att det låter konstigt, men det finns mycket logik bakom kulisserna som vi alla inte förstår.

Jag delar med mig av detta eftersom jag har sett appen krascha efter att ha startat den, säg efter cirka 14 timmar från bakgrundstillstånd. Orsaken kan vara vad som helst beroende på hur utvecklarna har kodat den.

Låt mig dela med mig av ett exempel i realtid:

I mitt fall var det tokenförfall som låg bakom. Om en av chattapparna startades efter 12-14 timmar fastnade den på anslutningsbannern och blev aldrig ansluten förrän den dödades och startades på nytt. Den här typen av saker är mycket svåra att fånga och på ett sätt gör det mobiltestning mer utmanande och kreativt.

Prestationstestning av din app

I mobilvärlden påverkar prestandan hos din app i vilken utsträckning din applikation blir erkänd över hela världen. Som testteam blir det alltför viktigt att kontrollera din app respons och framför allt hur den fungerar när ett stort antal användare använder den tillsammans.

Exempel:

Låt oss prata om PayTm.

Ni måste alla ha klickat på alternativet ADD MONEY (Lägg till pengar) i PayTm-appen, som sedan visar det saldo du har i din plånbok. Om vi tänker på vad som händer bakom kulisserna så är det en begäran som går till servern med PayTm UserID och servern skickar tillbaka svaret med saldot på ditt konto.

Ovanstående fall är bara när en användare har träffat servern. Vi måste se till att även när 1 000 användare använder servern ska de få tillbaka svaret i god tid eftersom slutanvändarens användbarhet är vårt främsta mål.

Slutsats

Jag avslutar den här handledningen med att upprepa att mobiltestning verkar vara väldigt enkelt i början, men när du fortsätter att gräva i det kommer du att förstå att det inte är lätt att se till att vad som än utvecklas kommer att köras smidigt på tusentals enheter över hela världen.

Det är oftast så att man ser appar som stöds endast på de senaste och sista versionerna av operativsystemen. Det blir dock testarnas plikt att se till att de inte missar några scenarier. Det finns många andra punkter som måste beaktas, men jag har inte nämnt dem som redan har nämnts i andra handledningar.

Scenarier som batteriförbrukning, testning av avbrott, testning i olika nätverk (3G, Wi-Fi), testning vid byte av nätverk, aptestning av mobilappar osv. är alla användbara när det gäller mobiltestning.

Testarnas attityd spelar stor roll när det gäller den verkliga testmiljön. Tills och om du älskar ditt jobb kommer du inte att bry dig om att göra saker som nämns i handledningen.

Jag har varit inom det här området i cirka 6 år nu och jag är mycket väl medveten om att arbetsuppgifterna blir monotona ibland, men det finns många andra saker som vi kan göra på egen hand för att göra de monotona arbetsuppgifterna någorlunda intressanta.

Utforma rätt teststrategi, välja rätt mobilsimulatorer, enheter och mobila testverktyg kan se till att vi har 100% testtäckning och hjälpa oss att inkludera säkerhet, användbarhet, prestanda, funktionalitet och kompatibilitetsbaserade tester i våra testsviter.

Ja, det här har varit vår ansträngning för att uppfylla flera förfrågningar från våra läsare om en guide för testning av mobilapplikationer.

Författare: Vi vill tacka Swapna, Hasnet och många andra experter på mobiltestning för att de har hjälpt oss att sammanställa denna serie!

I vår nästa artikel kommer vi att diskutera mer om iOS App Testing.