Tutorials til test af mobilapps (En komplet guide med 30+ tutorials)

mobile app testing tutorials

Prøv Vores Instrument Til At Fjerne Problemer

Vælg Operativsystemet Vælg Et Projektionsprojekt (Valgfrit)

Beskriv Dit Problem

En komplet guide til test af mobile applikationer med dybdegående tutorials:

Mobil teknologi og smarte enheder er tendensen nu og vil ændre verdens fremtid, som vi kender den. Vi kan alle stå inde for det, kan vi ikke? Nu bliver det amatørmæssigt, hvis jeg angiver, hvad vi bruger disse mobile enheder til. I ved det alle sammen - måske bedre end vi gør.

Lad os komme direkte til, hvad denne tutorial vil handle om.

Den komplette liste over 30+ mobile testvejledninger:

test af mobilapplikationer 1

Introduktion til mobil test:

Tutorial # 1: Introduktion til mobil test
Tutorial # 2: iOS-apptest
Tutorial # 3: Test af Android-app
Tutorial # 4 : Mobil testudfordringer og løsninger
Tutorial # 5: Hvorfor mobil test er hård?

Test af mobilenheder:

Tutorial # 6: Test en Android-version, når den tages ud af markedet
Tutorial # 7 : Sådan testes mobilapps på low-end-enheder
Tutorial # 8 : Marktestning for mobilapplikationer
Tutorial # 9: Telefonmodel mod OS-version: Hvilken skal testes først?

Mobil UI-test:

Tutorial # 10: UI-test af mobilapps
Tutorial # 11: Mobil responsiv test

Mobile testtjenester:

Tutorial # 12: Cloudbaseret mobil applikationstest
Tutorial # 13: Mobile testtjenester
Vejledning nr. 14 : Mobile App Beta Testing Services
Tutorial # 15: Mobile App Development Company
Tutorial # 16: Cloudbaserede mobilapptestudbydere

Test af mobilappsydelse og sikkerhed:

Tutorial # 17: Test af ydeevne til mobile applikationer ved hjælp af BlazeMeter
Tutorial # 18 : Retningslinjer for test af mobilappsikkerhed

Mobile testværktøjer:

Tutorial # 19: Android App Testværktøjer
Tutorial # 20: Bedste værktøjer til test af mobilapps sikkerhed
Tutorial # 21: 58 Bedste mobile testværktøjer

Test af mobil automatisering:

Tutorial # 22: Appium Mobile Automation Tool tutorial
Tutorial # 23: Appium Studio-vejledning
Tutorial # 24: Automatiser Android-applikationer ved hjælp af TestComplete-værktøjet
Tutorial # 25 : Robotium tutorial - Android App UI Testing Tool
Tutorial # 26: Selendroid Tutorial: Mobile Automation Framework
Tutorial # 27: pCloudy Tutorial: Mobile App Testing on Real Devices
Tutorial # 28: Katalon Studio & Kobitons Cloud-Based Device Farm Tutorial

Mobil testkarriere:

Tutorial # 29: Sådan får du et hurtigt testjob hurtigt
Tutorial # 30: Mobile Testing Interview Spørgsmål og CV
Tutorial # 31: Spørgsmål om mobiltestinterview del 2

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

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

Hvad du vil lære:

Tutorial # 1: Introduktion til test af mobilapplikationer

Tutorial # 1: Introduktion til test af mobilapplikationer

Borte er de dage, hvor telefonen plejede at være et apparat, der sad i et hjørne og måtte ringe for at få vores opmærksomhed, eller hvis en computer var en maskine, som kun nogle få mennesker brugte - de er nu en udvidelse af vores væren - et vindue til verden og virtuelle tjenere, der gør som de bliver fortalt.

Computere var raseri og ændrede, hvordan vi mennesker tænkte, opførte os, lærte og eksisterede.

I dag har mobilitetsløsninger overtaget markedet. Folk ønsker ikke at tænde deres laptops / pc til alt, men de vil hellere have, at deres håndholdte enheder udfører alt hurtigt.

Derfor skal de mobile løsninger, som vi leverer til vores kunder, testes meget godt. Denne vejledning er beregnet til de mennesker, der allerede er i mobil test eller dem, der har skiftet til det i nyere tid. Da vi allerede har mange selvstudier om definitioner af terminologierelaterede terminologier, vil vi direkte beskæftige os med omfanget af denne vejledning.

Denne vejledning er både en introduktion og din guide til mobil test. Så læs igennem!

Typer af mobil test

Der er stort set to slags test, der finder sted på mobile enheder:

# 1. Hardware test:

Enheden inklusive interne processorer, intern hardware, skærmstørrelser, opløsning, plads eller hukommelse, kamera, radio, Bluetooth, WIFI osv. Dette kaldes undertiden simpel, “Mobil test”.

# 2. Software eller applikationstest:

De applikationer, der fungerer på mobile enheder, og deres funktionalitet testes. Det kaldes “Test af mobilapplikationer”For at skelne det fra den tidligere metode. Selv i mobilapplikationer er der få grundlæggende forskelle, der er vigtige for forståelsen:

a) Native apps: En oprindelig applikation oprettes til brug på en platform som mobil og tablets.
b) Mobile webapps er appsider på serversiden for at få adgang til websteder på mobiltelefoner ved hjælp af forskellige browsere som Chrome, Firefox ved at oprette forbindelse til et mobilnetværk eller 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 få grundlæggende forskelle, der adskiller disse fra hinanden:

Native apps har affinitet med en enkelt platform, mens mobile webapps har tilknytning på tværs af platforme.
Indfødte apps er skrevet på platforme som SDK'er, mens mobile webapps er skrevet med webteknologier som HTML, CSS, asp.net, Java, PHP.
For en indbygget app kræves installation, men for mobile webapps kræves ingen installation.
En indbygget app kan opdateres fra playbutikken eller appbutikken, 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.
Indfødte apps installeres fra appbutikker som f.eks Google Play Butik eller app butik hvor mobilweb er websteder og kun er tilgængelige via internettet.

Resten af artiklen handler om test af mobilapplikationer.

Betydningen af mobil applikationstest

Test af applikationer på mobile enheder er mere udfordrende end at teste webapps på skrivebordet pga

Forskelligt udvalg af mobile enheder med forskellige skærmstørrelser og hardwarekonfigurationer som et hårdt tastatur, virtuelt tastatur (berøringsskærm) og trackball osv.
Brede varianter af mobile enheder som HTC, Samsung, Apple og Nokia.
Forskellige mobile operativsystemer som Android, Symbian, Windows, Blackberry og IOS.
Forskellige versioner af operativsystemet som iOS 5.x, iOS 6.x, BB5.x, BB6.x osv.
Forskellige mobilnetværksoperatører som GSM og CDMA.
Hyppige opdateringer - (som Android- 4.2, 4.3, 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 test af mobilapplikationer også meget vigtig, da kundekreds 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 problemer og uoprettelig skade på brand image.

Grundlæggende forskel mellem test af mobilapplikationer og desktop applikationer:

Få åbenlyse aspekter, der adskiller test af mobilapp fra bortset fra desktop-test

På skrivebordet testes applikationen på en central behandlingsenhed. På en mobilenhed testes applikationen på håndsæt som Samsung, Nokia, Apple og HTC.
Skærmstørrelsen på mobilenheden er mindre end et skrivebord.
Mobilenheder har mindre hukommelse end et skrivebord.
Mobiler bruger netværksforbindelser som 2G, 3G, 4G eller WIFI, hvor desktop bruger bredbånds- eller opkaldsforbindelser.
Automatiseringsværktøjet, der bruges til desktop-applikationstest, fungerer muligvis ikke på mobilapplikationer.

Typer af mobilapptest:

For at imødegå alle ovennævnte tekniske aspekter udføres følgende typer test på mobilapplikationer.

Brugervenlighedstest - For at sikre, at mobilappen er nem at bruge og giver kunderne en tilfredsstillende brugeroplevelse
Kompatibilitetstest - Test af applikationen i forskellige mobilenheder, browsere, skærmstørrelser og OS-versioner i henhold til kravene.
Interface test - Test af menupunkter, knapper, bogmærker, historie, indstillinger og navigationsflow for applikationen.
Test af tjenester - Test af applikationens tjenester online og offline.
Test på lavt niveau af ressourcer : Test af hukommelsesforbrug, automatisk sletning af midlertidige filer, lokale databasevoksende problemer kendt som ressourcetest på lavt niveau.
Test af ydeevne - Test af applikationens ydeevne ved at ændre forbindelsen fra 2G, 3G til WIFI, dele dokumenter, batteriforbrug osv.
Operationel test - Test af sikkerhedskopier og gendannelsesplan, hvis et batteri går ned eller datatab 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.

Strategi til test af mobilapplikationer

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

1) Valg af enheder - Analyser markedet, og vælg de enheder, der er meget udbredt. (Denne beslutning er for det meste afhængig af klienterne. Klienten eller appbyggerne overvejer popularitetsfaktoren for visse enheder såvel som markedsføringsbehovet for applikationen for at beslutte, hvilke håndsæt der skal bruges til test.)

2) Emulatorer - Brugen af disse er yderst nyttig i indledende udviklingsfaser, da de muliggør 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. Det duplikerer funktionerne og fungerer på det rigtige system.

Typer af mobile emulatorer

Enhedsemulator - leveret af enhedsproducenter
Browser-emulator - simulerer mobilbrowsermiljø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 overkommelig og meget fleksibel skybaseret mobiloplevelsesplatform, der fremskynder testning og levering af native-, web- og hybrid-apps på både Android og iOS ved hjælp af rigtige enheder. Deres nye scriptless testautomatisering hjælper holdene uden kodningsekspertise med let at generere åbne standard Appium-scripts.

Kobiton Nyhed

=> Besøg Kobitons websted

software til at rippe dvd til pc

Liste over få gratis og nemme at bruge emulatorer til mobilenheder

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

emulator til mobilenhed 2

ii. MobiReady - Med dette kan vi ikke kun teste webappen, vi kan også kontrollere koden.

emulator til mobilenhed 3

iii. Responsivepx - Det kontrollerer svarene på websiderne, udseendet og funktionaliteten på hjemmesiderne.

emulator til mobilenhed 4

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

emulator til mobilenhed 5

3) Når et tilfredsstillende udviklingsniveau er afsluttet for mobilappen, kan du gå videre til at teste på fysiske enheder for mere virkelige scenarier baseret test.

4) Overvej cloud computing-baseret test: Skyen kører dybest set enheder på flere systemer eller netværk via Internettet, hvor applikationer kan testes, opdateres og administreres. Til testformål opretter det det webbaserede mobile miljø på en simulator for at få adgang til mobilappen.

skybaseret mobil test

Fordele:

Backup og gendannelse - Cloud computing tager automatisk sikkerhedskopi af dine data fra fjernplacering, hvilket gør gendannelse og gendannelse af data let. Og også er lagerkapaciteten ubegrænset.
Skyer kan tilgås fra forskellige enheder og hvor som helst.
Cloud computing er omkostningseffektiv, nem at bruge, vedligeholde og opdatere.
Hurtig og hurtig implementering.
Web-baseret grænseflade.
Kan køre det samme script på flere enheder parallelt.

Ulemper

Mindre kontrol - Da applikationen kører på fjern- eller tredjepartsmiljø, har brugeren begrænset kontrol og adgang til funktionerne.
Internetforbindelsesproblemer - opsætningen er på Internettet. Netværksproblemer påvirker tilgængeligheden og funktionen
Problemer med sikkerhed og privatliv - Cloud computing er en internetcomputering, og intet på Internettet fuldfører sikker, så chancerne for datahacking er mere.

5) Automation vs. manuel test

Hvis applikationen indeholder ny funktionalitet, skal du teste den manuelt.
Hvis applikationen kræver test en eller to gange, skal du gøre det manuelt.
Automatiser scripts til tilfælde af regressionstest. Hvis regressionstest gentages, er automatiseret test perfekt til det.
Automatiser scripts til komplekse scenarier, der er tidskrævende, hvis de udføres manuelt.

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

Objektbaserede mobile testværktøjer - automatisering ved at kortlægge elementer på enhedens skærm til objekter. Denne tilgang er uafhængig af skærmstørrelse og bruges hovedsageligt til Android-enheder.

F.eks .: - Ranorex, jamo-løsning

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

F.eks .: - Sikuli, ægplante, RoutineBot

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

Testtilfælde til test af en mobilapp

Ud over funktionalitetsbaserede testcases kræver test af mobilapplikationer specielle testcases, som skal dække følgende scenarier.

Batteriforbrug - Det er vigtigt at holde styr på batteriforbruget, mens applikationen kører på de mobile enheder.
Ansøgningens hastighed- svartiden på forskellige enheder, med forskellige hukommelsesparametre, med forskellige netværkstyper osv.
Datakrav - Til installation samt for at kontrollere, om brugeren med den begrænsede dataplan kan downloade den.
Hukommelseskrav - 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 noget andet.

HentNogle eksempler på testtilfælde til test af mobilapplikationer:

=> Download testeksempler på mobilapp

Typiske aktiviteter og procedurer i test af mobilapplikation

Testens omfang afhænger af et antal krav, der skal kontrolleres, eller omfanget af ændringer, der er foretaget i appen. Hvis ændringerne er få, en runde af fornuft testning vil gøre. I tilfælde af større og / eller komplekse ændringer, a fuld regression anbefales.

Et eksempel på applikationstestprojekt : ILL (International Learn Lab) er en applikation designet til at hjælpe admin, udgiver med at oprette websteder i samarbejde. Ved hjælp af en webbrowser vælger instruktører et sæt funktioner til at oprette en klasse, der opfylder deres krav.

Mobil testproces:

Trin 1. Identificer typer af test : Da en ILL-applikation gælder for browsere, er det obligatorisk at teste denne applikation på alle understøttede browsere ved hjælp af forskellige mobile enheder. Vi skal gøre brugervenlighed, funktionel og kompatibilitet test på forskellige browsere med kombinationer af Håndbog og automatisering test tilfælde.

Trin 2. Manuel og automatiseret test: Metoden, der følges for dette projekt, er Agile med iteration på to uger. Hver anden uge dev. team frigiver et nyt build til testteam, og testteam vil køre deres testcases i QA-miljø. Automatiseringsteam opretter scripts til sættet med grundlæggende funktionalitet og kører de scripts, der hjælper med at afgøre, om den nye build er stabil nok til at teste. Det manuelle testteam vil teste den nye funktionalitet.

JIRA bruges til skrivning af acceptkriterier; vedligeholdelse af testsager og logføring / re-verifikation af mangler. Når iteration er overstået, iteration planlægning møde afholdt hvor dev. Teamet, produktejeren, forretningsanalytikeren og QA-teamet diskuterer hvad gik godt og hvad der skal forbedres .

Trin # 3. Betatestning: Når regressionstesten er afsluttet af QA-teamet, flytter bygningen ind i UAT. Test af brugeraccept udføres af klienten. De bekræfter alle fejlene igen for at sikre, at alle fejl blev rettet, og at applikationen fungerer som forventet på hver godkendt browser.

Trin # 4. Præstationstest: Performance-testteamet tester webappens ydeevne ved hjælp af JMeter-scripts og med forskellige belastninger på applikationen.

klassisk World of Warcraft privat server

Trin # 5. Browser test : Webappen bliver testet på tværs af flere browsere - både ved hjælp af forskellige simuleringsværktøjer såvel som fysisk ved hjælp af ægte mobile enheder.

Trin # 6. Startplan: Efter hver 4. uge flytter testen sig til iscenesættelse, hvor en sidste runde afslutning til slut-testning på disse enheder udføres for at sikre, at produktet er klar til produktion. Og så går det live!

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

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

Test af mobilapplikationer

Det er meget vigtigt for testere, der tester deres apps på både iOS og Android Platform, at kende forskellen mellem de to. iOS og Android har mange forskelle i forhold til udseende og følelse, appvisninger, kodningsstandarder, ydeevne osv.

Grundlæggende forskel mellem test af Android og iOS

Du har muligvis gennemgået alle vejledningerne, jeg har lagt nogle store forskelle her, som igen vil hjælpe dig som en del af din test:

# 1) Da vi har mange Android-enheder tilgængelige på markedet, og alle kommer med forskellige skærmopløsninger og størrelser, derfor er dette en af de største forskelle.

For eksempel , Samsung S2-størrelsen er 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 er tællbare enheder tilgængelige på markedet, og ud af disse har mange telefoner lignende opløsninger.

For eksempel, før iPhone 6 og nyere blev til, havde alle de ældre versioner kun samme størrelse.

#to) Eksempel på at hævde 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 testers ansvar at sikre, at billederne og de andre UI-elementer vises korrekt på alle enheder.

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

Mobilopløsninger

# 3) Da vi har markedet oversvømmet med Android-enheder, skal koden skrives på en sådan måde, at ydeevnen forbliver stabil. Så det er meget sandsynligt, at din app kan opføre sig langsomt på lavere enheder.

# 4) Et andet problem med Android er, at softwareopgraderinger ikke er tilgængelige for alle enheder på en gang. Enhedsfabrikanter beslutter, hvornår de skal opgradere deres enheder. Det bliver en meget vanskelig opgave at teste alt sammen med det nye operativsystem og det gamle operativsystem.

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

For eksempel , da Android 6.0 kom, var der en større ændring, da dette operativsystem begyndte at understøtte appniveautilladelser. For at afklare yderligere kunne brugeren skift tilladelser (placering, kontakter) også på app-niveau.

Nu skylder testteamet ansvaret for at sikre, at visning af tilladelsesskærm ved appstart på Android 6.0 og derover og ikke viser tilladelsesskærm i de lavere versioner.

# 5) Fra testperspektivet er test af præproduktionsbygning (dvs. betaversion) forskellig på begge platforme. I Android, hvis en bruger føjes til listen over betabrugere, kan han kun se den opdaterede betaversion i Play Butik, hvis han er logget ind i playbutikken med det samme e-mail-id, der tilføjes som en beta-bruger.

Nøglefaktorer i mobil test

Jeg har arbejdet i Mobile Testing i de sidste 2 år på både iOS og Android Platform, og alle de nøglepunkter, der er nævnt nedenfor i denne vejledning, er fra min personlige erfaring, og nogle stammer fra de problemer, der er stødt på i projektet.

Definer dit eget omfang af testning

Alle har deres egen testtest. Nogle testere fokuserer bare på det, de ser fra deres øjne, og resten brænder for alt, hvad der fungerer bag kulisserne i enhver mobilapplikation.

Hvis du er en iOS / Android-tester, vil jeg foreslå, at du i det mindste bliver fortrolig med nogle almindelige begrænsninger / grundlæggende funktioner i Android eller iOS, da det altid tilføjer værdi til vores teststil. Jeg ved, at ting er vanskelige at forstå uden at nævne eksempler.

Nedenfor er der få eksempler:

Vi kan ikke ændre tilladelserne som kamera, lager osv. På app-niveau i Android-enheder, der er under 6.0.1-versionen.
For iOS under version 10.0 var opkaldssættet ikke der. Bare for at orientere dig med enkle ord, kaldesæt bruges af en opkaldsapp og viser fuldskærmsvisning, når en bruger modtager et opkald fra de opkaldende apps som WhatsApp, Skype osv. Mens vi for iOS-versioner under 10.0 ser disse opkald som et meddelelsesbanner.
Mange af jer er muligvis stødt på problemer i Paytm, hvor din app ikke omdirigerer dig til bankens betalingsside, hvis du vil tilføje penge til din tegnebog. Vi synes, at ovenstående er et problem med vores bank eller Paytm-server, men det er bare, at vores AndroidSystemWebView ikke opdateres. Lidt viden om programmering er altid nyttigt for dig og at dele med dit team.
Med enkle ord, når en app åbner en webside i den, skal AndroidSystemWebView opdateres.

Testens omfang

Begræns ikke din test

Testning bør ikke kun være begrænset til at udforske mobilappen og logfiler. Vi, som en kvalitetssikring, skal være opmærksom på al anmodning om, at vi rammer vores server, og svaret, som vi får ud af den.

Konfigurer Putty for at få vist logfiler eller verificere sumo-logik for logfiler afhængigt af hvad der bruges i dit projekt. Det hjælper dig ikke kun med at kende applikationens ende-til-slut-strømning, men gør dig også til en bedre tester, efterhånden som du får flere ideer og scenarier nu.

Mobile Server Floe Diagram

Grund: Intet kommer til denne verden uden nogen grund. Enhver erklæring skal have en gyldig grund bagved. Årsagen til analysen af logfilerne er, at der observeres mange undtagelser i logfilerne, men de viser ingen indflydelse på brugergrænsefladen, og vi bemærker det derfor ikke.

Så skal vi ignorere det?

Nej, det burde vi ikke. Det har ingen indflydelse på brugergrænsefladen, men det kan være en futuristisk bekymring. Vi kan potentielt se vores app gå ned, hvis denne slags undtagelse fortsætter med at krybe. Som vi har nævnt om App Crash i sidste sætning, fører dette til, at QA har adgang til crashlytics af projektet.

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

Nu er spørgsmålet herovre, at hvis testeren har set app gå ned, hvorfor skal han så gider med crashlytics?

Svaret på dette er ret interessant. Der er nogle nedbrud, som muligvis ikke kan ses på brugergrænsefladen, men de er logget på crashlytics. Det kan være ude af hukommelsesnedbrud eller nogle fatale undtagelser, som kan påvirke ydeevnen senere.

Test på tværs af platforme

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

Citerer en simpel Eksempel , siger du arbejder på en chatapplikation som WhatsApp, der understøtter afsendelse af billeder og videoer, og applikationen er bygget på både iOS- og Android-platforme (Udvikling kan muligvis synkroniseres)

Sørg for at teste kommunikationen mellem Android og iOS, fordi iOS bruger 'Objective C', mens Android-programmering er Java-baseret, og på grund af at begge er bygget på forskellige platforme, skal der nogle gange foretages ekstra rettelser i appen side for at genkende strenge, der kommer fra forskellige sprogplatforme.

Hold øje med størrelsen på din mobilapp

Et andet vigtigt råd til mobile testere - Bliv ved med at tjekke størrelsen på din app efter hver frigivelse.

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

Til mobile testere test af appopgradering er meget vigtigt. Sørg for, at din app ikke går ned ved opgradering, da dev-teamet muligvis har gjort mismatching af et versionsnummer.

Datalagring er også lige så vigtig, da uanset hvilke præferencer brugeren har gemt i den tidligere version, skal bibeholdes, når han opgraderer appen.

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

Enheds OS understøtter muligvis ikke appen

Lyder interessant?

Ja, mange enheder understøtter muligvis ikke din app. Mange af jer må vide, at leverandører skriver deres egne indpakninger på toppen af USA, 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 ikke engang at starte app på den telefon.

Punkt herovre er - Forsøg 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.

Test af apptilladelse

Næste på listen er Tilladelsestest af mobilapps . Næsten hver anden app beder sine brugere om adgang til deres telefons kontakt, kamera, galleri, placering osv. Jeg har set få testere, der laver en fejl ved ikke at teste de rigtige kombinationer af disse tilladelser.

Jeg kan huske en realtid Eksempel da vi testede en chat-app, der havde alle funktionerne i deling af billeder og lydfiler. Tilladelse til opbevaring blev sat til NEJ.

Når en bruger nu klikker på indstillingen Kamera, åbnede den aldrig, før tilladelsen til opbevaring er indstillet til JA. Scenariet blev ignoreret, da Android Marshmallow havde denne funktion, at hvis lagringstilladelse er indstillet til NEJ, kan kameraet ikke bruges til den app.

Omfanget strækker sig længere end det, vi har diskuteret i ovenstående afsnit. Vi skal sikre os, at appen ikke beder om tilladelser, der ikke bruges.

Enhver slutbruger, der er fortrolig med softwareindustrien, kan ikke downloade den app, hvor der stilles for mange tilladelser. Hvis du har fjernet en funktion fra din app, skal du sørge for at fjerne tilladelsesskærmen for det samme.

hvordan man finder netværkssikkerhedsnøgle til mobil hotspot

Sammenlign med lignende og populære apps på markedet

Moralen ved historien - Hvis du nogensinde er i tvivl, skal du bare ikke afslutte det selv. Sammenligning med de andre lignende apps på den samme platform kan styrke dit argument for, at den testede funktionalitet fungerer eller ej.

Få et overblik over Apples Build Rejection Criterion

Endelig har et flertal af jer måske stødt på situationer, hvor dine builds blev afvist af Apple. Jeg ved, at dette emne ikke vil interessere en stor del af læserne, men det er altid godt at kende Apples afvisningspolitikker.

Som tester bliver det vanskeligt for os at imødekomme de tekniske aspekter, men der er stadig et afvisningskriterium, som testerne kan tage sig af.

For mere information om dette, klik venligst her.

Vær altid på frontfoden

Når du er tester, må du ikke lade tingene videregive til din domstol fra Dev Team / Managers. Hvis du er lidenskabelig med at teste, så “Vær altid på frontfoden” . Prøv at engagere dig i aktiviteter, der finder sted i god tid, før koden kommer til din spand for at teste.

Vigtigst er det, fortsæt med at kigge på JIRA, QC, MTM eller det, der bruges i dit projekt, for at få de seneste opdateringer om billetter fra kunder og Business Analyst. 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.

Indtil og medmindre vi ikke føler produktet som vores eget, burde vi aldrig give forslag til nye forbedringer eller ændringer af den eksisterende funktionalitet.

Hold din app i baggrunden i lang tid (12-24 timer)

Jeg ved, det lyder underligt, men der er meget logik bag kulisserne, som vi alle ikke forstår.

Jeg deler dette, fordi jeg har set appen gå ned efter lanceringen, siger efter cirka 14 timer fra baggrundsstatus. Årsagen kan være alt afhængigt af hvordan udviklerne har kodet det.

Lad mig dele et eksempel i realtid:

I mit tilfælde var udløbet af token årsagen bag det. For en af chat-apps, hvis den blev lanceret efter 12-14 timer, ville sidde fast på forbindelsesbanneret og aldrig blive forbundet, før den blev dræbt og genstartet. Denne slags ting er meget vanskelige at fange, og på en måde gør det mobil test mere udfordrende og kreativt.

Ydelsestest af din app

I mobilverdenen påvirker ydeevnen af din app, i hvilket omfang din applikation bliver anerkendt over hele verden. Som testteam bliver det for vigtigt at kontrollere dit apprespons og vigtigere, hvordan det fungerer, når et stort antal brugere bruger det hele sammen.

Eksempel:

Lad os tale om PayTm.

I skal alle have klikket på TILFØJ PENGE i PayTm-appen, som derefter viser den saldo, du har i din tegnebog. Hvis vi overvejer, hvad der foregår bag kulisserne, er det en anmodning, der foregår til serveren med PayTm UserID, og serveren sender svaret tilbage med saldoen på din konto.

Eksempel

Ovenstående tilfælde er kun, når en bruger har ramt serveren. Vi er nødt til at sikre, at selv når 1000 brugere rammer serveren, skal de vende tilbage svaret til tiden, fordi slutbrugernes anvendelighed er vores primære mål.

Konklusion

Jeg vil afslutte denne vejledning ved at gentage, at mobil test synes at være meget let i starten, men når du bliver ved med at grave ind, vil du forstå, at det ikke er let at sikre, at det, der udvikles, 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 par versioner af OS. Det bliver dog testernes pligt at sikre, at de ikke går glip af scenarier. De er mange andre punkter, der skal tages i betragtning, men jeg har ikke nævnt dem, der allerede er gentaget i de andre tutorials.

Scenarier som batteriforbrug, afbrydelse af test, test på forskellige netværk (3G, Wi-Fi), test, mens der skiftes netværk, abetest af mobile apps osv. Er alle nyttige, når det kommer til mobil test.

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

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

At designe den rigtige teststrategi, vælge de rigtige mobile simulatorer, 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 testpakker.

Nå, dette har været vores bestræbelse på at opfylde flere anmodninger fra vores læsere på en testguide til mobilapplikationer.

Forfattere : Tak til Swapna, Hasnet og mange andre mobile testeksperter for at hjælpe os med at kompilere denne serie!

I vores næste artikel vil vi diskutere mere om iOS-apptest .