Free Press

En komplet guide til test af mobilapplikationer med dybdegående vejledninger:

Mobilteknologi og smarte enheder er en trend nu og vil ændre fremtiden for den verden, som vi kender den. Det kan vi alle sammen stå inde for, ikke sandt? Nu vil det være amatøragtigt, hvis jeg opregner, hvad vi bruger disse mobile enheder til. I ved det alle sammen – måske bedre end vi gør.

Lad os komme direkte til det, som denne vejledning kommer til at handle om.

Den komplette liste over 30+ vejledninger om mobiltestning:

Indledning til mobiltestning:

Tutorial #1: Introduktion til mobiltestning
Tutorial #2: iOS App-testning
Tutorial #3: Android App-testning
Tutorial #4: Udfordringer og løsninger på mobiltestning
Tutorial #5: Hvorfor mobiltestning er svært?

Test af mobile enheder:

Tutorial #6: Test en Android-version, når den er taget ud af markedet
Tutorial #7: Sådan tester du mobile apps på low-end-enheder
Tutorial #8: Felttest af mobile applikationer
Tutorial #9: Telefonmodel Vs OS-version:

Mobile UI Testing:

Tutorial #10: UI Testing of Mobile Apps
Tutorial #11: UI Testing of Mobile Apps
Tutorial #11: Mobile Responsive Test

Mobile testtjenester:

Tutorial #12: Cloud-baseret test af mobilapplikationer
Tutorial #13: Mobiltesttjenester
Tutorial #14: Betatesttjenester for mobilapplikationer
Tutorial #15: Mobilapplikationsudviklingsfirma
Tutorial #16: Cloud-baserede udbydere af testtjenester for mobilapplikationer

Mobilapplikationspræstations- og sikkerhedstest:

Tutorial #17: Test af mobilapplikationers ydeevne ved hjælp af BlazeMeter
Tutorial #18: Retningslinjer for test af mobilapps sikkerhed

Mobile testværktøjer:

Tutorial #19: 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 Mobile Automation Tool tutorial
Tutorial #23: Appium Studio tutorial
Tutorial #24: Automatiser Android-applikationer ved hjælp af TestComplete-værktøjet
Tutorial #25: Robotium tutorial – Android App UI Testing Tool
Tutorial #26: Robotium tutorial – Android App UI Testing Tool
Tutorial #26: Selendroid Tutorial: Mobile Automation Framework
Tutorial #27: pCloudy Tutorial: Tutorial #28: Katalon Studio & Kobiton’s Cloud-Based Device Farm Tutorial

Mobile Testing Career:

Tutorial #29: How to Get a Mobile Testing Job Fast
Tutorial #30: Mobile Testing Interview Questions and Resume
Tutorial #31: Mobile Testing Interview Questions Part 2

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

Lad os begynde med den første tutorial i serien.

Tutorial #1: Introduktion til test af mobilapplikationer

De dage er forbi, hvor telefonen var et apparat, der sad i et hjørne og skulle ringe for at få vores opmærksomhed, eller hvor en computer var en maskine, som kun få mennesker brugte – de er nu en forlængelse af vores væsen – et vindue til verden og virtuelle tjenere, der gør, som de bliver bedt om.

Computere var en raseri og ændrede den måde, vi mennesker tænkte, opførte os, lærte og eksisterede på.

I dag har mobilitetsløsninger overtaget markedet. Folk ønsker ikke at tænde for deres bærbare computere/PC til alting, de ønsker snarere at deres håndholdte enheder skal udføre alting hurtigt.

Derfor bør de mobile løsninger, som vi leverer til vores kunder, være testet meget godt. Denne tutorial er beregnet til de personer, der allerede er i mobiltestning eller dem, der har skiftet til det i den seneste tid. Da vi allerede har mange tutorials om definitioner af mobiltestrelaterede terminologier, vil vi direkte beskæftige os med omfanget af denne tutorial.

Denne tutorial vil både være en introduktion og din guide til mobiltestning. Så læs den igennem!

Typer af mobiltestning

Der er groft sagt 2 typer af testning, der finder sted på mobile enheder:

#1. Hardwareafprøvning:

Enheden, herunder de interne processorer, intern hardware, skærmstørrelser, opløsning, plads eller hukommelse, kamera, radio, Bluetooth, WIFI osv. Dette kaldes nogle gange for simpel “mobiltestning”.

#2. Test af software eller applikationer:

De applikationer, der fungerer på mobile enheder, og deres funktionalitet testes. Den kaldes “Mobile Application Testing” for at adskille den fra den tidligere metode. Selv i mobile applikationer er der nogle få grundlæggende forskelle, som det er vigtigt at forstå:

a) Native apps: En native applikation er skabt til brug på en platform som f.eks. mobiler og tablets.
b) Mobile webapps er server-side apps til at få adgang til websted(er) på mobilen ved hjælp af forskellige browsere som Chrome, Firefox ved at oprette forbindelse til et mobilnetværk eller et trådløst netværk som WIFI.
c) Hybrid apps er kombinationer af native app og webapp. De kører på enheder eller offline og er skrevet ved hjælp af webteknologier som HTML5 og CSS.

Der er nogle få grundlæggende forskelle, der adskiller dem fra hinanden:

• Native apps har affinitet med en enkelt platform, mens mobile webapps har affinitet med flere platforme.
• Native apps er skrevet i platforme som SDK’er, mens mobile webapps er skrevet med webteknologier som HTML, CSS, asp.net, Java, PHP.
• For en native app kræves der installation, men for mobile webapps kræves der ingen installation.
• En native app kan opdateres fra Play Store eller App Store, mens mobile webapps er centraliserede opdateringer.
• Mange native apps kræver ikke en internetforbindelse, men for mobile webapps er det et must.
• Native app fungerer hurtigere sammenlignet med mobile webapps.
• Native apps installeres fra app stores som Google play store eller app store, hvor mobile web er websites og kun er tilgængelige via internettet.

Resten af artiklen kommer til at handle om test af mobile applikationer.

Betydningen af test af mobilapplikationer

Test af applikationer på mobile enheder er mere udfordrende end test af webapps på skrivebordet på grund af

• Forskellige udvalg af mobile enheder med forskellige skærmstørrelser og hardware-konfigurationer som et hårdt tastatur, virtuelt tastatur (touch screen) og trackball osv.
• Store udvalg af mobile enheder som f.eks. HTC, Samsung, Apple og Nokia.
• Forskellige mobile styresystemer som Android, Symbian, Windows, Blackberry og IOS.
• Forskellige versioner af operativsystemer som iOS 5.x, iOS 6.x, BB5.x, BB6.x osv.
• Forskellige mobilnetoperatører som GSM og CDMA.
• Hyppige opdateringer – (som Android- 4.2, 4.3, 4.4, 4.4, iOS-5.x, 6.x) – med hver opdatering anbefales en ny testcyklus for at sikre, at ingen applikationsfunktionalitet påvirkes.

Som med enhver applikation er testning af mobilapplikationer også meget vigtig, da kundekredsen normalt er i millioner for et bestemt produkt – og et produkt med fejl bliver aldrig værdsat. Det resulterer ofte i monetære tab, juridiske spørgsmål og uoprettelig skade på brand image.

Grundlæggende forskel mellem test af mobilapplikationer og desktopapplikationer:

Få indlysende aspekter, der adskiller test af mobilapplikationer fra desktoptestning

• På desktoppen testes applikationen på en central processorenhed. På en mobilenhed testes applikationen på håndsæt som Samsung, Nokia, Apple og HTC.
• Skærmstørrelsen på en mobilenhed er mindre end på en stationær computer.
• Mobile enheder har mindre hukommelse end en stationær computer.
• Mobiler bruger netværksforbindelser som 2G, 3G, 4G eller WIFI, hvor stationære enheder bruger bredbånds- eller dial-up-forbindelser.
• Det automatiseringsværktøj, der anvendes til test af desktopapplikationer, fungerer muligvis ikke på mobilapplikationer.

Typer af test af mobilapplikationer:

For at tage højde for alle de ovennævnte tekniske aspekter udføres følgende typer test af mobilapplikationer.

• Brugervenlighedstest- For at sikre, at mobilappen er nem at bruge og giver kunderne en tilfredsstillende brugeroplevelse
• Kompatibilitetstest- Test af applikationen på forskellige mobilenheder, browsere, skærmstørrelser og OS-versioner i henhold til kravene.
• Grænsefladetestning- Test af menupunkter, knapper, bogmærker, historik, indstillinger og navigationsflow i applikationen.
• Test af tjenester- Test af applikationens tjenester online og offline.
• Test af ressourcer på lavt niveau: Test af hukommelsesforbrug, automatisk sletning af midlertidige filer, problemer med voksende lokale databaser, kendt som test af ressourcer på lavt niveau.
• Test af ydeevne – Test af applikationens ydeevne ved at ændre forbindelsen fra 2G, 3G til WIFI, deling af dokumenter, batteriforbrug osv.
• Operationel test – Test af sikkerhedskopier og genoprettelsesplan, hvis et batteri går ned, eller tab af data under opgradering af applikationen fra en butik.
• Installationstest- Validering af applikationen ved at installere/afinstallere den på enhederne.
• Sikkerhedstest- Test af en applikation for at validere, om informationssystemet beskytter data eller ej.

Mobile Application Testing Strategy

Teststrategien skal sikre, at alle retningslinjer for kvalitet og ydeevne er opfyldt. Et par pejlemærker på dette område:

1) Valg af enheder – Analyser markedet og vælg de enheder, der er meget udbredte. (Denne beslutning afhænger for det meste af kunderne. Klienten eller app-byggerne tager hensyn til popularitetsfaktoren for visse enheder samt markedsføringsbehovene for applikationen for at beslutte, hvilke håndsæt der skal bruges til testning.)

2) Emulatorer – Brugen af disse er yderst nyttig i de indledende faser af udviklingen, da de giver mulighed for hurtig og effektiv kontrol af appen. Emulatoren er et system, der kører software fra et miljø til et andet miljø uden at ændre selve softwaren. Den kopierer funktionerne og fungerer på det rigtige system.

Typer af mobilemulatorer

• Enhedsemulator – leveres af enhedsproducenterne
• Browseremulator – simulerer mobile browsermiljøer.
• Operativsystemer Emulator- Apple leverer emulatorer til iPhones, Microsoft til Windows-telefoner og Google Android-telefoner

Anbefalet værktøj

#1) Kobiton

Kobiton er en prisbillig og meget fleksibel cloud-baseret mobiloplevelsesplatform, der fremskynder testning og levering af native, web- og hybridapps på både Android og iOS ved hjælp af rigtige enheder. Deres nye scriptløse testautomatisering hjælper teams uden kodningsekspertise med at generere åbne standard Appium-scripts med lethed.

=> Besøg Kobitons websted

Liste over få gratis og letanvendelige emulatorer til mobile enheder

i. Mobiltelefonemulator – Bruges til at teste håndsæt som iPhone, Blackberry, HTC, Samsung osv.

ii. MobiReady – Med denne kan vi ikke kun teste webappen, vi kan også kontrollere koden.

iii. Responsivepx – Det tjekker websidernes respons, udseende og funktionalitet.

iv. Screenfly – Det er et værktøj, der kan tilpasses og bruges til at teste websteder under forskellige kategorier.

3) Når et tilfredsstillende udviklingsniveau er nået for mobilappen, kan du gå over til at teste på de fysiske enheder for mere virkelighedsnære scenarier baseret test.

4) Overvej cloud computing-baseret testning: Cloud computing er grundlæggende at køre enheder på flere systemer eller netværk via internettet, hvor applikationer kan testes, opdateres og administreres. Til testformål oprettes det webbaserede mobilmiljø på en simulator for at få adgang til mobilappen.

Pros:

• Backup og gendannelse- Cloud computing tager automatisk backup af dine data fra en fjernplacering, hvilket gør gendannelse og gendannelse af data nemt. Og desuden er lagerkapaciteten ubegrænset.
• Clouds kan tilgås fra forskellige enheder og hvor som helst.
• Cloud computing er omkostningseffektivt, nemt at bruge, vedligeholde og opdatere.
• Snav og hurtig implementering.
• Webbaseret grænseflade.
• Kan køre det samme script på flere enheder parallelt.

Konsekvenser

• Mindre kontrol- Da applikationen kører på fjernmiljøet eller tredjepartsmiljøet, har brugeren begrænset kontrol og adgang til funktionerne.
• Problemer med internetforbindelse- Opsætningen er på internettet. Netværksproblemer påvirker tilgængeligheden og funktionen
• Sikkerhed og privatlivsproblemer- Cloud computing er en internetcomputing, og intet på internettet er færdiggørende sikkert, så chancerne for datahacking er større.

5) Automatisering vs. Manuel testning

• Hvis applikationen indeholder ny funktionalitet, skal du teste den manuelt.
• Hvis applikationen kræver testning en eller to gange, skal du gøre det manuelt.
• Automatiser scripts til regressionstestcases. Hvis regressionstests gentages, er automatiseret test perfekt til det.
• Automatiser scripts til komplekse scenarier, som er tidskrævende, hvis de udføres manuelt.

To slags automatiseringsværktøjer er tilgængelige til test af mobilapps:

Objektbaserede mobiltestværktøjer – automatisering ved at mappe elementer på enhedens skærm til objekter. Denne tilgang er uafhængig af skærmstørrelse og bruges primært til Android-enheder.

• Eg:- Ranorex, jamo solution

Billedbaserede mobile testværktøjer- opretter automatiseringsskripter baseret på skærmkoordinater for elementer.

• Eg:- Sikuli, Egg Plant, RoutineBot

6) Netværkskonfiguration er også den nødvendige del af mobiltestning. Det er vigtigt at validere applikationen på forskellige netværk som 2G, 3G, 4G eller WIFI.

Testcases til test af en mobilapplikation

Ud over funktionalitetsbaserede testcases kræver test af mobilapplikationer særlige testcases, som bør dække følgende scenarier.

• Batteriforbrug- Det er vigtigt at holde styr på batteriforbruget, mens applikationen kører på de mobile enheder.
• Applikationens hastighed- svartiden på forskellige enheder, med forskellige hukommelsesparametre, med forskellige netværkstyper osv.
• Datakrav – Til installation samt til at verificere, om brugeren med det begrænsede dataabonnement vil kunne downloade det.
• Hukommelsesbehov – igen, for at downloade, installere og køre
• Applikationens funktionalitet – sørg for, at applikationen ikke går ned på grund af netværksfejl eller andet.

Download nogle eksempler på testcases til test af mobilapplikationer:

=> Download eksempler på testcases for mobilapplikationer

Typiske aktiviteter og procedurer i forbindelse med test af mobilapplikationer

Det omfang af testen afhænger af et antal krav, der skal kontrolleres, eller omfanget af de ændringer, der er foretaget i appen. Hvis ændringerne er få, er en runde af sanity testing nok. I tilfælde af større og/eller komplekse ændringer anbefales en fuld regression.

Et eksempel på et projekt til test af en applikation: ILL (International Learn Lab) er en applikation, der er designet til at hjælpe administrator, udgiver til at oprette websteder i samarbejde. Ved hjælp af en webbrowser kan undervisere vælge mellem et sæt funktioner for at oprette en klasse, der opfylder deres krav.

Mobile testproces:

Stræk 1. Identificer testtyperne: Da en ILL-applikation er anvendelig for browsere, er det obligatorisk at teste denne applikation på alle understøttede browsere ved hjælp af forskellige mobile enheder. Vi skal udføre brugervenlighed, funktionel og kompatibilitetstest på forskellige browsere med kombinationer af manuelle og automatiserede testcases.

Stræk #2. Manuel og automatiseret test: Den metodologi, der følges til dette projekt, er Agile med en iteration på to uger. Hver anden uge frigiver udviklingsholdet et nyt build til testholdet, og testholdet kører deres testcases i QA-miljøet. Automatiseringsteamet opretter scripts for sætet af grundlæggende funktionalitet og kører scripts, der hjælper med at afgøre, om det nye build er stabilt nok til at blive testet. Det manuelle testteam tester den nye funktionalitet.

JIRA bruges til at skrive acceptkriterier, vedligeholde testcases og logge/reverificere defekter. Når iterationen er overstået, afholdes et iterationsplanlægningsmøde, hvor dev. Teamet, produktejeren, forretningsanalytikeren og QA-teamet diskuterer, hvad der gik godt, og hvad der skal forbedres.

Skridt #3. Betatestning: Når regressionstesten er afsluttet af QA-teamet, flyttes buildet til UAT. User Acceptance Testing udføres af kunden. De genverificerer alle fejl for at sikre, at alle fejl er blevet rettet, og at applikationen fungerer som forventet på alle godkendte browsere.

Stræk 4. Test af ydeevne: Præstationsafprøvningsteamet tester webappens ydeevne ved hjælp af JMeter-scripts og med forskellige belastninger på applikationen.

Stræk #5. Test af browser: Webappen bliver testet på tværs af flere browsere – både ved hjælp af forskellige simuleringsværktøjer og fysisk ved hjælp af rigtige mobile enheder.

Stræk 6: Webappen bliver testet på tværs af flere browsere – både ved hjælp af forskellige simuleringsværktøjer og fysisk ved hjælp af rigtige mobile enheder. Lanceringsplan: Efter hver 4. uge flyttes testen over i staging, hvor der udføres en sidste runde af end-to-end-test på disse enheder for at sikre, at produktet er klar til produktion. Og så går det live!

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

Sådan tester du mobilapplikationer på både Android- og iOS-platforme

Det er meget vigtigt for de testere, der tester deres apps på både iOS- og Android-platformen, at kende forskellen mellem de to. iOS og Android har en masse forskelle m.h.t. udseende, app-visninger, kodningsstandarder, ydeevne osv.

Basisk forskel mellem Android- og iOS-testning

Du har måske gennemgået alle tutorials, jeg har sat nogle vigtige forskelle ind her, som igen vil hjælpe dig som en del af din testning:

#1) Da vi har en masse Android-enheder til rådighed på markedet, og de kommer alle med forskellige skærmopløsninger og størrelser, derfor er dette en af de store forskelle.

For eksempel er Samsung S2 størrelsen for lille sammenlignet med Nexus 6. Der er store muligheder for, at dit app-layout og design bliver forvrænget på en af enhederne. Sandsynligheden er lav i iOS, da der kun findes et utal af enheder på markedet, og ud af disse har mange telefoner lignende opløsninger.

F.eks. før iPhone 6 og derover kom til verden, havde alle de ældre versioner kun den samme størrelse.

#2) Eksempel til bekræftelse af ovenstående punkt er, at i Android skal udviklerne bruge 1x,2x,3x,4x og 5x billeder for at understøtte billedopløsninger for alle enheder, mens iOS kun bruger 1x,2x og 3x. Det bliver dog testerens ansvar at sikre, at billederne og de andre UI-elementer vises korrekt på alle enheder.

Du kan se nedenstående diagram for at forstå begrebet billedopløsninger:

#3) Da vi har et marked, der er oversvømmet af Android-enheder, skal koden skrives på en sådan måde, at ydelsen forbliver stabil. Så det er ret sandsynligt, at din app kan opføre sig langsomt på enheder i den lavere ende.

#4) Et andet problem med Android er, at softwareopgraderinger ikke er tilgængelige for alle enheder på en gang. Enhedsproducenterne bestemmer selv, hvornår de vil opgradere deres enheder. Det bliver en meget vanskelig opgave at teste alting både med det nye og det gamle styresystem.

Det bliver også en besværlig opgave for udviklerne at ændre deres kode for at understøtte begge versioner.

For eksempel var der en stor ændring, da Android 6.0 kom, da dette styresystem begyndte at understøtte tilladelser på app-niveau. For at præcisere yderligere, kunne brugeren også ændre tilladelser (placering, kontakter) på app-niveau.

Nu skylder testteamet ansvaret for at sikre, at der vises en skærm med tilladelser ved app-start på Android 6.0 og derover og ikke vises en skærm med tilladelser på de lavere versioner.

#5) Fra testperspektivet er testning af præproduktionsbyggeri (dvs. betaversion) forskellig på begge platforme. I Android, hvis en bruger er tilføjet til listen over beta-brugere, kan han kun se det opdaterede beta build i Play Store, hvis han er logget ind i Play Store med det samme e-mail-id, som er tilføjet som beta-bruger.

Nøglefaktorer i mobiltestning

Jeg har arbejdet med mobiltestning i de sidste 2 år på både iOS- og Android-platformen, og alle de nøglepunkter, der er nævnt nedenfor i denne tutorial, er fra min personlige erfaring, og nogle blev afledt af de problemer, der opstod i projektet.

Definér dit eget omfang af testning

Alle har deres egen stil med testning. Nogle testere fokuserer bare på det, de ser med deres øjne, og resten brænder for alt det, der fungerer bag kulisserne på en mobilapplikation.

Hvis du er iOS/Android-tester, vil jeg foreslå dig, at du i det mindste gør dig bekendt med nogle almindelige begrænsninger/grundlæggende funktionaliteter i Android eller iOS, da det altid tilføjer værdi til vores teststil. Jeg ved, at tingene er svære at forstå uden at citere eksempler.

Nedenfor er der nogle få eksempler:

• Vi kan ikke ændre tilladelser som kamera, lager osv. på app-niveau i Android-enheder, der er under 6.0.1 version.
• For iOS under 10.0 version, call kit var der ikke. Bare for at orientere dig med enkle ord, bruges call kit af en opkaldsapp og viser fuldskærmsvisning, når en bruger får et opkald fra opkaldsapps såsom WhatsApp, Skype osv. Mens vi i iOS-versioner under 10.0 ser disse opkald som et notifikationsbanner.
• Mange af jer er måske stødt på problemer i Paytm, hvor jeres app ikke videresender jer til bankens betalingsside, hvis I ønsker at tilføje penge til jeres tegnebog. Vi tror, at ovenstående er et problem med vores bank eller Paytm-server, men det er bare, at vores AndroidSystemWebView ikke er opdateret. Lidt viden om programmering er altid nyttigt for dig og til at dele med dit team.
• Med enkle ord, når en app åbner en webside i den, så skal AndroidSystemWebView opdateres.

Begræns ikke din testning

Testning bør ikke kun være begrænset til at udforske mobilappen og logge fejl. Vi som QA bør være opmærksomme på alle de anmodninger, som vi rammer vores server, og det svar, som vi får ud af det.

Konfigurer Putty til at se logs eller verificere sumo-logik for logs afhængigt af, hvad der bruges i dit projekt. Det hjælper dig ikke kun med at kende applikationens End-to-End flow, men gør dig også til en bedre tester, da du får flere ideer og scenarier nu.

Ræsonnement: Intet kommer ind i denne verden uden nogen grund. Enhver udtalelse bør have en gyldig grund bag sig. Grunden bag analysen af logfilerne er, at mange undtagelser observeres i logfilerne, men de viser ikke nogen indvirkning på brugergrænsefladen, hvorfor vi ikke bemærker det.

Så, skal vi ignorere det?

Nej, det skal vi ikke. Det har ingen indvirkning på brugergrænsefladen, men det kan være en fremtidsorienteret bekymring. Vi kan potentielt se vores app gå ned, hvis denne slags undtagelser bliver ved med at snige sig ind. Som vi har nævnt om App Crash i sidste sætning, fører det til, at QA skal have adgang til crashlytics for projektet.

Crashlytics er et værktøj, hvor nedbrud logges sammen med tidspunkt og enhedsmodel.

Nu er spørgsmålet herovre, at hvis testeren har set appen gå ned, hvorfor skal han så bekymre sig om crashlytics?

Svaret på dette er ganske interessant. Der er nogle nedbrud, som måske ikke er synlige på brugergrænsefladen, men de er logget på crashlytics. Det kan være nedbrud på grund af manglende hukommelse eller nogle fatale undtagelser, som kan påvirke ydeevnen senere.

Testning på tværs af platforme

Testning af interaktion på tværs af platforme er meget vigtig.

Tegne et simpelt eksempel: Lad os sige, at du arbejder på en chat-applikation som WhatsApp, der understøtter afsendelse af billeder og videoer, og applikationen er bygget på både iOS- og Android-platforme (udviklingen går måske eller måske ikke synkroniseret)

Sørg for at teste kommunikationen mellem Android og iOS, fordi iOS bruger “Objective C”, mens Android-programmering er Java-baseret, og fordi de begge er bygget på forskellige platforme, skal der nogle gange foretages ekstra rettelser på app-siden for at genkende strenge, der kommer fra forskellige sprogplatforme.

Hold øje med størrelsen af din mobilapp

Et andet vigtigt råd til mobiltestere – kontroller venligst størrelsen af din app efter hver udgivelse.

Vi bør sikre, at appens størrelse ikke når et punkt, hvor selv vi som slutbruger ikke ønsker at downloade denne app på grund af dens store størrelse.

Test af app-opgraderingsscenarier

For mobiltestere er det meget vigtigt at teste app-opgraderingstest. Sørg for, at din app ikke går ned ved opgradering, da udviklingsteamet måske har foretaget en fejlmatchning af et versionsnummer.

Databevaring er også lige så vigtigt, da de præferencer, som brugeren har gemt i den tidligere version, skal bevares, når han opgraderer appen.

For eksempel kan en bruger have gemt sine bankkortoplysninger i apps som PayTm osv.

Enhedens operativsystem understøtter måske ikke appen

Lyder det interessant?

Ja, mange enheder understøtter muligvis ikke din app. Mange af jer må vide, at leverandører skriver deres egne wrappers oven på US, og det kan være muligt, at enhver SQL-forespørgsel i din app ikke er kompatibel med enheden, og derfor kaster den en undtagelse, og det kan resultere i, at appen ikke engang starter appen på den pågældende telefon.

Punktet herover er – Prøv at bruge din app på dine egne enheder, undtagen dem, du bruger på kontoret. Det er meget muligt, at du ser nogle problemer med din app.

App Permission Testing

Næste punkt på listen er Permission Testing af mobile apps. Næsten hver anden app beder sine brugere om adgang til telefonens kontakt, kamera, galleri, placering osv. Jeg har set få testere, der begår en fejl ved ikke at teste de rigtige kombinationer af disse tilladelser.

Jeg kan huske et realtidseksempel, da vi testede en chat-app, som havde alle funktioner til at dele billeder og lydfiler. Tilladelse til lagring var indstillet til NEJ.

Nu, når en bruger klikker på kameraindstillingen, åbnes den aldrig, indtil tilladelsen til lagring er indstillet til JA. Scenariet blev ignoreret, da Android Marshmallow havde denne funktionalitet, at hvis tilladelsen til opbevaring er indstillet til NEJ, kan kameraet ikke bruges til den pågældende app.

Den rækkevidde strækker sig længere end det, vi har diskuteret i ovenstående afsnit. Vi bør sikre os, at appen ikke beder om tilladelser, som ikke bruges.

En slutbruger, der er bekendt med softwareindustrien, vil måske ikke downloade den app, hvor der bliver bedt om for mange tilladelser. Hvis du har fjernet en funktion fra din app, skal du sørge for at fjerne tilladelsesskærmen for den samme.

Sammenlign med lignende og populære apps på markedet

Moral i historien – Hvis du nogensinde er i tvivl, skal du bare ikke selv konkludere det. Sammenligning med andre lignende apps på den samme platform kan styrke dit argument for, om den funktionalitet, der testes, vil fungere eller ej.

Få et overblik over Apples kriterium for afvisning af builds

Sidst, et flertal af jer har måske oplevet situationer, hvor jeres builds blev afvist af Apple. Jeg ved, at dette emne ikke vil interessere størstedelen af læserne, men det er altid godt at kende Apples afvisningspolitikker.

Som tester bliver det svært for os at tage højde for de tekniske aspekter, men der er stadig nogle afvisningskriterier, som testerne kan tage sig af.

For mere information om dette kan du klikke her.

Altid være på forkant

Som tester skal du ikke lade tingene gå over på din banehalvdel fra Dev Team/managers. Hvis du brænder for at teste, så “Always be on Front Foot”. Prøv at engagere dig i aktiviteter, der finder sted længe før koden kommer til din spand til test.

Det vigtigste er, at du bliver ved med at kigge på JIRA, QC, MTM eller hvad der bruges i dit projekt for at få alle de seneste opdateringer om billetter fra kunder og forretningsanalytikeren. Vær også klar til at dele dine synspunkter, hvis du har brug for ændringer. Dette gælder for alle testere, der arbejder på forskellige domæner og platforme.

Selv om vi ikke føler produktet som vores eget, burde vi aldrig komme med forslag til nye forbedringer eller ændringer af den eksisterende funktionalitet.

Lad din app være i baggrunden i lang tid (12-24 timer)

Jeg ved godt, at det lyder mærkeligt, men der er meget logik bag kulisserne, som vi alle ikke forstår.

Jeg deler dette, fordi jeg har set appen gå ned efter at have lanceret den, f.eks. efter ca. 14 timer fra baggrundstilstand. Årsagen kan være alt afhængigt af, hvordan udviklerne har kodet det.

Lad mig dele et realtidseksempel:

I mit tilfælde var tokenudløb årsagen bag det. Hvis en af chat-appene blev startet efter 12-14 timer, sad den fast på banneret for tilslutning og fik aldrig forbindelse, før den blev dræbt og genstartet. Den slags ting er meget svære at fange, og på en måde gør det mobiltestning mere udfordrende og kreativ.

Performance Testing of your App

I den mobile verden har din apps ydeevne indflydelse på, i hvilket omfang din applikation bliver anerkendt verden over. Som testteam bliver det for vigtigt at kontrollere din apprespons og endnu vigtigere, hvordan den fungerer, når et stort antal brugere bruger den alle sammen.

Eksempel:

Lad os tale om PayTm.

I skal alle have klikket på ADD MONEY-muligheden i PayTm-appen, som derefter viser den saldo, du har i din tegnebog. Hvis vi ser på, hvad der foregår bag kulisserne, så er det en forespørgsel, der går videre til serveren med PayTm UserID, og serveren sender svaret tilbage med saldoen på din konto.

Overstående tilfælde er kun, når én bruger har ramt serveren. Vi skal sikre os, at selv når 1000 brugere rammer serveren, skal de få svaret tilbage i god tid, fordi slutbrugerens brugervenlighed er vores primære mål.

Konklusion

Jeg vil slutte denne tutorial ved at gentage, at mobiltestning synes at være meget let i begyndelsen, men når du fortsætter med at grave dig ned, vil du forstå, at det ikke er let at sikre, at det, der er udviklet, vil køre problemfrit på tusindvis af enheder over hele verden.

Du vil for det meste se de apps, der kun understøttes på de nyeste og sidste få versioner af OS. Det bliver imidlertid testernes pligt at sikre, at de ikke går glip af nogen scenarier. Der er mange andre punkter, der skal tages i betragtning, men jeg har ikke nævnt dem, der allerede er nævnt i de andre tutorials.

Scenarier som batteriforbrug, afbrydelsestest, test på forskellige netværk (3G, Wi-Fi), test ved skift af netværk, abe-test af mobilapps osv. er alle nyttige, når det kommer til mobiltestning.

Testernes holdning betyder meget, når det kommer til det virkelige testmiljø. Indtil og medmindre du elsker dit job, vil du ikke gider gøre de ting, som er nævnt i vejledningen.

Jeg har været i dette felt i omkring 6 år nu, og jeg er meget vel klar over, at opgaverne bliver monotone til tider, men der er mange andre ting, som vi kan gøre på egen hånd for at gøre disse monotone opgaver lidt interessante.

Design af den rigtige teststrategi, valg af de rigtige mobilsimulatorer, enheder og mobile testværktøjer kan sikre, at vi har 100% testdækning og hjælpe os med at inkludere sikkerhed, brugervenlighed, ydeevne, funktionalitet og kompatibilitetsbaserede tests i vores testsuiter.

Jamen, dette har været vores forsøg på at opfylde flere anmodninger fra vores læsere om en guide til test af mobile applikationer.

Autorer:

Author: I vores næste artikel vil vi diskutere mere om iOS App Testing.