Free Press

Een complete gids voor het testen van mobiele applicaties met diepgaande handleidingen:

Mobiele technologie en slimme apparaten zijn de trend van dit moment en zullen de toekomst van de wereld zoals wij die kennen veranderen. We kunnen allemaal instaan voor het, kunnen we niet? Nu, het zal amateuristisch zijn als ik opsom waar we deze mobiele apparaten voor gebruiken. Jullie weten het allemaal – Misschien wel beter dan wij.

Laten we maar meteen beginnen waar deze tutorial over gaat.

De complete lijst met meer dan 30 tutorials over mobiel testen:

Mobiele testinleiding:

Tutorial #1: Inleiding tot mobiel testen
Tutorial #2: iOS app testen
Tutorial #3: Android app testen
Tutorial #4: Uitdagingen en oplossingen voor mobiel testen
Tutorial #5: Waarom mobiel testen moeilijk is?

Testen van mobiele apparaten:

Tutorial #6: Test een Android-versie wanneer deze uit de markt wordt genomen
Tutorial #7: Hoe test u mobiele apps op low-end apparaten
Tutorial #8: Veldtests voor mobiele applicaties
Tutorial #9: Telefoonmodel vs. OS-versie: Welke moet eerst worden getest?

Mobiele UI Testen:

Tutorial #10: UI Testen van Mobiele Apps
Tutorial #11: Mobile Responsive Test

Mobile Testing Services:

Tutorial #12: Cloud-Based Mobile Application Testing
Tutorial #13: Mobile Testing Services
Tutorial #14: Mobile App Beta Testing Services
Tutorial #15: Mobile App Development Company
Tutorial #16: Cloud-Based Mobile App Testing Service Providers

Mobile App Performance and Security Testing:

Tutorial #17: Mobile Applications Performance Testing Using BlazeMeter
Tutorial #18: Mobile App Security Testing Guidelines

Mobile Testing Tools:

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 Studio tutorial
Tutorial #24: Android Applications Automate Using TestComplete Tool
Tutorial #25: Robotium tutorial – Android App UI Testing Tool
Tutorial #26: Selendroid handleiding: Mobile Automation Framework
Tutorial #27: pCloudy Tutorial: Mobiele App Testen op Echte Apparaten
Tutorial #28: Katalon Studio & Kobiton’s Cloud-Based Device Farm Tutorial

Mobile Testing Career:

Tutorial #29: Hoe je snel een Mobile Testing Baan krijgt
Tutorial #30: Mobile Testing Interview Vragen en C.V.
Tutorial #31: Mobile Testing Interview Vragen Deel 2

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

Laten we beginnen met de 1e tutorial in de serie.

Tutorial #1: Inleiding tot het testen van mobiele applicaties

De tijd dat de telefoon een apparaat was dat in een hoekje stond en moest rinkelen om onze aandacht te trekken is voorbij, of dat een computer een apparaat was dat slechts door een paar mensen werd gebruikt – ze zijn nu een verlengstuk van ons wezen – een venster op de wereld en virtuele dienaren die doen wat hen wordt opgedragen.

Computers waren een rage en veranderden hoe wij mensen dachten, ons gedroegen, leerden en bestonden.

Heden ten dage hebben Mobiliteitsoplossingen de markt overgenomen. Mensen willen niet meer voor alles hun laptop/PC aanzetten, maar willen dat hun handheld apparaten alles snel uitvoeren.

Daarom moeten de mobiele oplossingen die we aan onze klanten leveren zeer goed getest worden. Deze tutorial is bedoeld voor die mensen die al bezig zijn met mobiel testen of die er de afgelopen tijd op zijn overgestapt. Omdat we al veel tutorials hebben over definities van mobiele testgerelateerde terminologie, zullen we direct ingaan op de scope van deze tutorial.

Deze tutorial zal zowel een introductie als uw gids zijn voor Mobile Testing. Dus, lees door!

Types van mobiel testen

Er zijn in grote lijnen 2 soorten testen die plaatsvinden op mobiele apparaten:

#1. Hardware testen:

Het apparaat inclusief de interne processoren, interne hardware, schermformaten, resolutie, ruimte of geheugen, camera, radio, Bluetooth, WIFI enz. Dit wordt soms aangeduid als, eenvoudig “Mobiel testen”.

#2. Software of Applicatie testen:

De applicaties die werken op mobiele apparaten en hun functionaliteit worden getest. Het wordt “Mobile Application Testing” genoemd om het te onderscheiden van de eerdere methode. Ook bij mobiele toepassingen zijn er enkele basisverschillen die belangrijk zijn om te begrijpen:

a) Native apps: Een native applicatie wordt gemaakt voor gebruik op een platform zoals mobiel en tablets.
b) Mobiele web apps zijn server-side apps om toegang te krijgen tot website / s op mobiel met behulp van verschillende browsers zoals Chrome, Firefox door verbinding te maken met een mobiel netwerk of een draadloos netwerk zoals WIFI.
c) Hybride apps zijn combinaties van native app en web app. Ze draaien op apparaten of offline en zijn geschreven met behulp van webtechnologieën zoals HTML5 en CSS.

Er zijn een paar fundamentele verschillen die deze onderscheiden:

• Native apps hebben affiniteit met één platform, terwijl mobiele webapps de cross-platform affiniteit hebben.
• Native apps zijn geschreven in platforms zoals SDK’s, terwijl mobiele webapps zijn geschreven met webtechnologieën zoals HTML, CSS, asp.net, Java, PHP.
• Voor een native app is installatie vereist, maar voor mobiele webapps is geen installatie vereist.
• Een native app kan worden bijgewerkt vanuit de play store of app store, terwijl mobiele webapps gecentraliseerde updates zijn.
• Veel native apps vereisen geen internetverbinding, maar voor mobiele webapps is het een must.
• Native app werkt sneller in vergelijking met mobiele webapps.
• Native apps worden geïnstalleerd vanuit app stores zoals Google play store of app store waar mobile web websites zijn en alleen toegankelijk zijn via het internet.

De rest van het artikel gaat over Mobile Application Testing.

Het belang van het testen van mobiele applicaties

Het testen van applicaties op mobiele apparaten is een grotere uitdaging dan het testen van web-apps op de desktop als gevolg van

• Verschillende reeks mobiele apparaten met verschillende schermgroottes en hardwareconfiguraties zoals een hard toetsenbord, virtueel toetsenbord (touchscreen) en trackball, enz.
• Grote verscheidenheid aan mobiele apparaten zoals HTC, Samsung, Apple en Nokia.
• Verschillende mobiele besturingssystemen zoals Android, Symbian, Windows, Blackberry en IOS.
• Verschillende versies van besturingssystemen zoals iOS 5.x, iOS 6.x, BB5.x, BB6.x etc.
• Verschillende mobiele netwerk operators zoals GSM en CDMA.
• Frequente updates – (zoals Android- 4.2, 4.3, 4.4, iOS-5.x, 6..x) – met elke update een nieuwe testcyclus wordt aanbevolen om ervoor te zorgen geen toepassing functionaliteit wordt beïnvloed.

Zoals bij elke toepassing, Mobiele applicatie testen is ook erg belangrijk, zoals de klantenkring is meestal in miljoenen voor een bepaald product – en een product met bugs wordt nooit gewaardeerd. Het resulteert vaak in monetaire verliezen, juridische kwestie, en onherstelbare schade aan het merkimago.

Basic verschil tussen mobiele en desktop applicatie testen:

Weinig voor de hand liggende aspecten die mobiele app testen onderscheiden van de desktop testen

• Op de desktop, wordt de applicatie getest op een centrale verwerkingseenheid. Op een mobiel apparaat wordt de applicatie getest op handsets zoals Samsung, Nokia, Apple en HTC.
• De schermgrootte van een mobiel apparaat is kleiner dan een desktop.
• Mobiele apparaten hebben minder geheugen dan een desktop.
• Mobiele apparaten gebruiken netwerkverbindingen zoals 2G, 3G, 4G of WIFI waar desktop breedband- of inbelverbindingen gebruiken.
• De automatisering tool die wordt gebruikt voor desktop applicatie testen misschien niet werken op mobiele applicaties.

Types van Mobile App Testing:

Om alle bovenstaande technische aspecten aan te pakken, worden de volgende soorten testen uitgevoerd op Mobiele applicaties.

• Gebruiksvriendelijkheid testen- Om ervoor te zorgen dat de mobiele app is gemakkelijk te gebruiken en biedt een bevredigende gebruikerservaring aan de klanten
• Compatibiliteit testen- Testen van de applicatie in verschillende mobiele apparaten, browsers, schermformaten en OS-versies volgens de eisen.
• Interface testing- Testen van menu opties, knoppen, bladwijzers, geschiedenis, instellingen, en navigatie flow van de applicatie.
• Services testing- Testen van de diensten van de applicatie online en offline.
• Low-level resource testing: Testen van geheugengebruik, automatisch verwijderen van tijdelijke bestanden, lokale database groeiende problemen bekend als low-level resource testing.
• Performance testing- Testen van de prestaties van de applicatie door het veranderen van de verbinding van 2G, 3G naar WIFI, het delen van de documenten, batterijverbruik, etc.
• Operationele testen- Testen van back-ups en herstelplan als een batterij uitvalt, of verlies van gegevens tijdens het upgraden van de applicatie uit een winkel.
• Installatie testen- Validatie van de applicatie door het te installeren / de-installeren op de apparaten.
• Security testen- Testen van een applicatie om te valideren of het informatiesysteem gegevens beschermt of niet.

Mobiele Applicatie Test Strategie

De Test strategie moet ervoor zorgen dat aan alle kwaliteit en prestatie richtlijnen wordt voldaan. Een paar aanwijzingen op dit gebied:

1) Selectie van de apparaten – Analyseer de markt en kies de apparaten die veel gebruikt worden. (Deze beslissing hangt meestal af van de klanten. De klant of de app-bouwers houden rekening met de populariteitsfactor van bepaalde apparaten, evenals de marketingbehoeften voor de toepassing om te beslissen welke handsets moeten worden gebruikt voor het testen.)

2) Emulators – Het gebruik van deze is uiterst nuttig in de eerste stadia van ontwikkeling, omdat ze een snelle en efficiënte controle van de app mogelijk maken. De emulator is een systeem dat software van de ene omgeving in een andere omgeving uitvoert zonder de software zelf te veranderen. Het dupliceert de functies en werkt op het echte systeem.

Types van mobiele emulatoren

• Device Emulator- geleverd door fabrikanten van apparaten
• Browser Emulator- simuleert mobiele browser omgevingen.
• Besturingssystemen Emulator- Apple biedt emulators voor iPhones, Microsoft voor Windows-telefoons en Google Android-telefoons

Aanbevolen tool

#1) Kobiton

Kobiton is een betaalbaar en zeer flexibel cloud-based mobile experience platform dat het testen en opleveren van native, web en hybride apps op zowel Android als iOS versnelt met behulp van echte apparaten. Hun nieuwe scriptloze testautomatisering helpt teams zonder codeerexpertise om met gemak open standaard Appium-scripts te genereren.

=> Bezoek de website van Kobiton

Lijst met enkele gratis en eenvoudig te gebruiken emulators voor mobiele apparaten

i. Mobile Phone Emulator – Wordt gebruikt voor het testen van handsets zoals iPhone, Blackberry, HTC, Samsung enz.

ii. MobiReady – Hiermee kunnen we niet alleen de webapp testen, maar ook de code controleren.

iii. Responsivepx – Hiermee worden de reacties van de webpagina’s, de verschijningsvorm en de functionaliteit van de websites gecontroleerd.

iv. Screenfly – Dit is een aanpasbare tool die wordt gebruikt om websites in verschillende categorieën te testen.

3) Nadat de mobiele app naar tevredenheid is ontwikkeld, kunt u overgaan op het testen van fysieke apparaten voor het testen van levensechte scenario’s.

4) Overweeg het testen met behulp van cloud computing: Cloud computing is in feite het draaien van apparaten op meerdere systemen of netwerken via het internet waar applicaties kunnen worden getest, bijgewerkt en beheerd. Voor testdoeleinden wordt een webgebaseerde mobiele omgeving gecreëerd op een simulator om toegang te krijgen tot de mobiele app.

Pros:

• Back-up en herstel- Cloud computing maakt automatisch een back-up van uw gegevens vanaf een externe locatie, waardoor gegevens gemakkelijk kunnen worden hersteld en teruggezet. En ook de opslagcapaciteit is onbeperkt.
• Clouds zijn toegankelijk vanaf verschillende apparaten en overal.
• Cloud computing is kostenefficiënt, gemakkelijk te gebruiken, te onderhouden en te updaten.
• Snelle en snelle implementatie.
• Web-based interface.
• Kan hetzelfde script op meerdere apparaten parallel uitvoeren.

Cons

• Minder controle- Omdat de applicatie op de externe of third-party omgeving draait, heeft de gebruiker beperkte controle en toegang tot de functies.
• Problemen met de internetverbinding- De setup bevindt zich op het internet. Netwerk problemen hebben invloed op de beschikbaarheid en de werking
• Veiligheid en privacy Issues- Cloud computing is een Internet computing en niets op het Internet is volledig veilig, dus de kans op het hacken van gegevens zijn meer.

5) Automatisering vs. Handmatig testen

• Als de applicatie bevat nieuwe functionaliteit, test het handmatig.
• Als de applicatie vereist een of twee keer testen, doe het handmatig.
• Automatiseer de scripts voor regressie testgevallen. Als regressietests worden herhaald, is geautomatiseerd testen daar perfect voor.
• Automatiseer de scripts voor complexe scenario’s die tijdrovend zijn als ze handmatig worden uitgevoerd.

Twee soorten automatiseringstools zijn beschikbaar voor het testen van mobiele apps:

Object-based mobile testing tools-automatisering door elementen op het scherm van het apparaat in kaart te brengen in objecten. Deze aanpak is onafhankelijk van de schermgrootte en wordt voornamelijk gebruikt voor Android-apparaten.

• Eg:- Ranorex, jamo oplossing

Image-based mobile testing tools- maak automatiseringsscripts op basis van schermcoördinaten van elementen.

• Eg:- Sikuli, Egg Plant, RoutineBot

6) Netwerkconfiguratie is ook het noodzakelijke onderdeel van mobiel testen. Het is belangrijk om de applicatie te valideren op verschillende netwerken, zoals 2G, 3G, 4G of WIFI.

Testgevallen voor het testen van een mobiele applicatie

Naast de functionaliteit gebaseerde testgevallen, Mobiele applicatie testen vereist speciale testgevallen die de volgende scenario’s moeten dekken.

• Batterijverbruik- Het is belangrijk om het batterijverbruik bij te houden tijdens het draaien van de applicatie op de mobiele apparaten.
• De snelheid van de applicatie- de responstijd op verschillende apparaten, met verschillende geheugen parameters, met verschillende netwerk types etc.
• Gegevensvereisten – voor de installatie, alsmede om te controleren of de gebruiker met de beperkte data-plan in staat zal zijn om het te downloaden.
• Geheugenvereiste- opnieuw, om te downloaden, te installeren en uit te voeren
• De functionaliteit van de toepassing- zorg ervoor dat de toepassing niet crasht als gevolg van een netwerkstoring of iets anders.

Download enkele voorbeeldtestgevallen voor het testen van mobiele toepassingen:

=> Download Mobiele app voorbeeld testcases

Typische activiteiten en procedures bij het testen van Mobiele Applicatie

De omvang van het testen hangt af van een aantal eisen die moeten worden gecontroleerd of de omvang van de wijzigingen die in de app zijn aangebracht. Als de wijzigingen gering zijn, is een ronde van sanity testing voldoende. Bij grote en/of complexe wijzigingen is een volledige regressie aan te bevelen.

Een voorbeeld applicatie test project: ILL (International Learn Lab) is een applicatie ontworpen om admin, uitgever te helpen om in samenwerking websites te maken. Met behulp van een webbrowser, instructeurs kiezen uit een set van functies om een klasse die voldoet aan hun eisen te creëren.

Mobile Testing proces:

Step # 1. Identificeer de soorten van testen: Als een ILL applicatie is van toepassing voor browsers, dus het is verplicht om deze applicatie te testen op alle ondersteunde browsers met behulp van verschillende mobiele apparaten. We moeten bruikbaarheid, functioneel en compatibiliteit testen op verschillende browsers met de combinaties van handmatige en geautomatiseerde testcases.

Stap #2. Handmatig en geautomatiseerd testen: De methodologie die voor dit project wordt gevolgd is Agile met de iteratie van twee weken. Elke twee weken geeft het dev. team een nieuwe build vrij voor het testteam en het testteam zal hun testgevallen uitvoeren in de QA-omgeving. Het automatiseringsteam maakt scripts voor de set basisfunctionaliteiten en voert de scripts uit die helpen bepalen of de nieuwe build stabiel genoeg is om te testen. Het handmatige testteam zal de nieuwe functionaliteit testen.

JIRA wordt gebruikt voor het schrijven van acceptatiecriteria; het onderhouden van testgevallen en het loggen / her-verifiëren van defecten. Zodra de iteratie voorbij is, wordt de iteratie planning vergadering gehouden waar dev. Het team, product owner, business analist, en QA team bespreken wat er goed ging en wat er moet worden verbeterd.

Stap #3. Beta-testen: Zodra de regressietesten zijn voltooid door het QA-team, gaat de build naar UAT. Gebruikers Acceptatie Test wordt gedaan door de klant. Zij controleren alle bugs opnieuw om er zeker van te zijn dat elke bug is verholpen en de applicatie werkt zoals verwacht op elke goedgekeurde browser.

Stap #4. Prestatie test: Performance testing team test de prestaties van de web app met behulp van JMeter scripts en met verschillende de belastingen op de applicatie.

Step #5. Browser testen: De web app wordt getest in meerdere browsers- zowel met behulp van verschillende simulatie tools als fysiek met behulp van echte mobiele apparaten.

Step #6. Lanceringsplan: Na elke 4e week, verhuist het testen naar staging, waar een laatste ronde van end-to-end testen op deze apparaten wordt uitgevoerd om ervoor te zorgen dat het product klaar is voor productie. En dan gaat het product live!

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

Hoe test u mobiele applicaties op zowel het Android- als het iOS-platform?

Het is heel belangrijk voor testers die hun apps testen op zowel het iOS- als het Android-platform om het verschil tussen beide platforms te kennen. iOS en Android hebben veel verschillen met betrekking tot de look & feel, app-weergaven, coderingsstandaarden, prestaties, enzovoort.

Basisverschil tussen Android en iOS Testing

Je hebt misschien alle tutorials doorgenomen, ik heb hier een aantal belangrijke verschillen opgesomd, die je op hun beurt zullen helpen als onderdeel van je testen:

#1) Aangezien we veel Android-apparaten op de markt hebben en ze allemaal verschillende schermresoluties en -groottes hebben, is dit een van de belangrijkste verschillen.

Voorbeeld, Samsung S2 formaat is te klein in vergelijking met Nexus 6. Er zijn grote mogelijkheden dat uw app lay-out en ontwerp vervormd raken op een van de apparaten. Bij iOS is die kans klein, omdat er maar een beperkt aantal apparaten op de markt is en veel van die apparaten een vergelijkbare resolutie hebben.

Bijvoorbeeld, voordat de iPhone 6 en hoger bestond, hadden alle oudere versies een vergelijkbare grootte.

#2) Een voorbeeld om het bovenstaande punt te staven is dat in Android de ontwikkelaars 1x,2x,3x,4x en 5x afbeeldingen moeten gebruiken om de beeldresoluties voor alle apparaten te ondersteunen, terwijl iOS slechts 1x,2x en 3x gebruikt. Het wordt echter de verantwoordelijkheid van de tester om ervoor te zorgen dat de afbeeldingen en de andere UI-elementen op alle apparaten correct worden weergegeven.

U kunt het onderstaande diagram raadplegen om het concept van beeldresoluties te begrijpen:

#3) Aangezien de markt wordt overspoeld door Android-apparaten, moet de code zodanig worden geschreven dat de prestaties stabiel blijven. Het is dus heel waarschijnlijk dat uw app zich traag gedraagt op apparaten in het lagere segment.

#4) Een ander probleem met Android is dat software-upgrades niet voor alle apparaten tegelijk beschikbaar zijn. Apparaatfabrikanten beslissen wanneer ze hun apparaten upgraden. Het wordt een zeer moeilijke taak om alles te testen zowel met het nieuwe OS en het oude OS.

Ook wordt het een lastige taak voor de ontwikkelaars om hun code te wijzigen om beide versies te ondersteunen.

Bijvoorbeeld, toen Android 6.0 kwam, was er een grote verandering als dit OS begon app-niveau machtigingen te ondersteunen. Om verder te verduidelijken, kon de gebruiker machtigingen (locatie, contacten) wijzigen op app-niveau ook.

Nu het testen team dankt de verantwoordelijkheid om ervoor te zorgen dat het tonen van machtigingen scherm op de app te starten op Android 6.0 en hoger en niet tonen toestemming scherm op de lagere versies.

#5) Vanuit het perspectief van het testen, Pre-productie build (dat wil zeggen beta versie) testen is anders op beide platformen. In Android, als een gebruiker wordt toegevoegd aan beta gebruikers lijst dan kan hij de bijgewerkte beta build te zien op de Play Store alleen als hij is aangemeld bij de play store met dezelfde e-mail ID die is toegevoegd als een beta gebruiker.

Key Factors in Mobile Testing

Ik heb gewerkt in Mobile Testing voor de laatste 2 jaar op zowel iOS-en Android-platform en alle belangrijke punten hieronder vermeld in deze tutorial zijn uit mijn persoonlijke ervaring en sommige werden afgeleid van de problemen die zich in het project.

Definieer je eigen reikwijdte van het testen

Iedereen heeft zijn eigen stijl van testen. Sommige testers richten zich alleen op wat ze zien vanuit hun ogen en de rest is gepassioneerd over alles wat werkt achter de schermen van een mobiele applicatie.

Als je een iOS / Android Tester bent, zou ik je aanraden om jezelf op zijn minst vertrouwd te maken met een aantal gemeenschappelijke beperkingen / basisfunctionaliteiten van Android of iOS, omdat het altijd waarde toevoegt aan onze stijl van testen. Ik weet dat dingen moeilijk te begrijpen zijn zonder voorbeelden te noemen.

Hieronder staan enkele voorbeelden:

• We kunnen de machtigingen zoals camera, opslag, enz. niet wijzigen op app-niveau in Android-apparaten die lager zijn dan 6.0.1 versie.
• Voor iOS lager dan 10.0 versie, was call kit er niet. Gewoon om u in eenvoudige woorden te informeren, call kit wordt gebruikt door een bel-app en toont schermvullende weergave wanneer een gebruiker wordt gebeld door de bel-apps zoals WhatsApp, Skype, enz. Overwegende dat voor iOS versies lager dan 10.0 we die oproepen zien als een kennisgeving banner.
• Velen van jullie kunnen problemen zijn tegengekomen in Paytm waar uw app u niet doorverwijst naar de betaalpagina van de bank in het geval dat u geld wilt toevoegen aan uw portemonnee. We denken dat het bovenstaande een probleem is met onze bank of Paytm server, maar het is gewoon dat onze AndroidSystemWebView niet is bijgewerkt. Een beetje kennis van programmeren is altijd nuttig voor u en om te delen met uw team.
• In eenvoudige woorden, wanneer een app een webpagina opent, dan moet AndroidSystemWebView worden bijgewerkt.

Beperk uw testen niet

Testen mag niet alleen beperkt blijven tot het onderzoeken van de mobiele app en het loggen van bugs. Wij, als QA moeten ons bewust zijn van alle verzoeken die we onze server raken en de respons die we eruit krijgen.

Configureer Putty om logs te bekijken of controleer sumo-logica voor logs, afhankelijk van wat er in uw project wordt gebruikt. Het helpt je niet alleen om de End-to-End flow van de applicatie te kennen, maar maakt je ook een betere tester omdat je nu meer ideeën en scenario’s krijgt.

Reason: Niets komt in deze wereld zonder enige reden. Elke uitspraak moet een geldige reden hebben. De reden voor het analyseren van de logboeken is dat er veel uitzonderingen in de logboeken staan, maar die hebben geen enkele invloed op de gebruikersinterface, zodat we ze niet opmerken.

Moeten we die dan maar negeren?

Nee, dat moeten we niet doen. Het heeft geen invloed op de UI, maar het kan een futuristisch punt van zorg zijn. We zouden onze app kunnen zien crashen als dit soort uitzonderingen blijven sluipen. Zoals we hebben gezegd over App Crash in de laatste zin, dit leidt de QA om toegang te hebben tot crashlytics van het project.

Crashlytics is een tool waar crashes worden gelogd, samen met de tijd en het apparaat model.

Nu de vraag hier is dat als de tester heeft gezien app crashen dan waarom moet hij lastig vallen over crashlytics?

Het antwoord op deze is heel interessant. Er zijn crashes die misschien niet zichtbaar zijn op de UI, maar die wel worden gelogd op crashlytics. Het kan een out of memory crash zijn of een aantal fatale uitzonderingen die later van invloed kunnen zijn op de performance.

Cross-Platform Testing

Cross-Platform Interaction Testing is erg belangrijk.

Een eenvoudig voorbeeld: stel dat je werkt aan een chat-applicatie zoals WhatsApp, die het verzenden van afbeeldingen en video’s ondersteunt, en de applicatie is gebouwd op zowel iOS- als Android-platforms (de ontwikkeling kan al dan niet synchroon lopen)

Zorg ervoor dat je de communicatie tussen Android en iOS test. De reden hiervoor is dat iOS “Objective C” gebruikt, terwijl Android programmeert op basis van Java en omdat ze allebei op verschillende platforms zijn gebouwd, moeten er soms extra fixes worden gemaakt aan de kant van de app om strings te herkennen die afkomstig zijn van verschillende taalplatforms.

Houd de grootte van uw mobiele app in de gaten

Een ander belangrijk advies voor mobiele testers – Blijf de grootte van uw app controleren na elke release.

We moeten ervoor zorgen dat de grootte van de app niet een punt bereikt waarop zelfs wij als eindgebruiker deze app niet meer willen downloaden vanwege de grote omvang.

Testen van app-upgradescenario’s

Voor mobiele testers is het testen van app-upgrades erg belangrijk. Zorg ervoor dat uw app niet crasht bij de upgrade als het dev team kan hebben gedaan mismatching van een versienummer.

Data retentie is ook net zo belangrijk als in wat voorkeuren die de gebruiker heeft opgeslagen in de vorige versie moet worden behouden wanneer hij een upgrade van de app.

Voorbeeld, een gebruiker kan hebben opgeslagen zijn bankpas gegevens in apps als PayTm, etc.

Device OS kan niet ondersteunen App

Klinkt interessant?

Ja, veel apparaten kunnen uw app niet ondersteunen. Velen van u moet weten dat leveranciers hun eigen wrappers schrijven op de top van de VS en het zou mogelijk kunnen zijn dat een SQL query van uw app niet compatibel is met het apparaat en dus het gooit een uitzondering en het kan resulteren in het niet eens starten van de app op die phone.

Point over hier is – Probeer uw app te gebruiken op uw eigen apparaten, met uitzondering van degenen die u gebruikt op kantoor. Het is heel goed mogelijk dat u een aantal problemen met uw app ziet.

App Permission Testing

Next op de lijst is Permission Testing van mobiele apps. Bijna elke tweede app vraagt zijn gebruikers om toegang tot contact, camera, galerij, locatie enz. van hun telefoon. Ik heb een paar testers gezien die een fout maken door niet de juiste combinaties van deze permissies te testen.

Ik kan me een real-time voorbeeld herinneren toen we een chat-app aan het testen waren die alle functies van het delen van afbeeldingen en audiobestanden had. Toestemming voor opslag was ingesteld op NO.

Nu, wanneer een gebruiker zou klikken op de optie Camera het nooit geopend totdat de toestemming voor opslag is ingesteld op JA. Het scenario werd genegeerd omdat Android Marshmallow deze functionaliteit had dat als opslagtoestemming is ingesteld op NEE, de camera niet kan worden gebruikt voor die app.

Het toepassingsgebied strekt zich verder uit dan wat we in de bovenstaande paragraaf hebben besproken. We moeten ervoor zorgen dat de app geen machtigingen vraagt die niet worden gebruikt.

Een eindgebruiker die bekend is met de software-industrie, downloadt mogelijk niet de app waarin te veel machtigingen worden gevraagd. Als u hebt verwijderd elke functie van uw app, zorg er dan voor om de toestemming scherm voor the same.

Vergelijken met soortgelijke en populaire Apps in de markt

Moraal van het verhaal – Als je ooit in een twijfel, dan gewoon niet concluderen zelf. Vergelijken met andere soortgelijke apps op hetzelfde platform kan uw argument versterken dat de functionaliteit die wordt getest al dan niet zal werken.

Krijg een overzicht van Apple’s Build Rejection Criterion

Ten slotte is een meerderheid van u misschien situaties tegengekomen waarin uw builds werden afgewezen door Apple. Ik weet dat dit onderwerp een groot deel van de lezers niet zal interesseren, maar het is altijd goed om het afkeuringsbeleid van Apple te kennen.

Als tester wordt het moeilijk voor ons om de technische aspecten te regelen, maar toch is er een afkeuringscriterium waar de testers voor kunnen zorgen.

Voor meer informatie hierover, klik hier.

Altijd op de voorste voet

Als tester, laat niet dingen overgaan naar uw rechtbank van het Dev Team / Managers. Als je gepassioneerd bent over testen dan “Always be on Front Foot”. Probeer jezelf te betrekken bij activiteiten die plaatsvinden ruim voordat de code in je emmer komt om te testen.

Het belangrijkste is, blijf kijken naar JIRA, QC, MTM of welke dan ook wordt gebruikt in je project voor alle laatste updates over tickets van klanten en de Business Analyst. Wees ook bereid om uw mening te delen als u wijzigingen nodig heeft. Dit geldt voor alle testers die op verschillende domeinen en platformen werken.

Tot en tenzij we het product niet als het onze voelen, zouden we nooit suggesties moeten geven voor nieuwe verbeteringen of wijzigingen in de bestaande functionaliteit.

Houd uw app lange tijd op de achtergrond (12-24 uur)

Ik weet dat het raar klinkt, maar er is veel logica achter de schermen die we allemaal niet begrijpen.

Ik deel dit omdat ik heb gezien dat de app crasht nadat deze is gestart, zeg na ongeveer 14 uur vanuit de achtergrondstatus. De reden kan van alles zijn, afhankelijk van hoe de ontwikkelaars het hebben gecodeerd.

Laat me een real-time voorbeeld delen:

In mijn geval was het verlopen van het token de achterliggende oorzaak. Voor een van de chat-apps indien gelanceerd na 12-14 uur zou vast komen te zitten op de verbinding banner en zou nooit meer verbinding totdat gedood en opnieuw opgestart. Dit soort dingen zijn zeer moeilijk te vangen en op een bepaalde manier, het maakt mobiel testen meer uitdagend en creatief.

Prestatie testen van uw App

In de mobiele wereld, de prestaties van uw app van invloed op de mate waarin uw applicatie wordt wereldwijd erkend. Als testteam wordt het te belangrijk om de respons van uw app te controleren en nog belangrijker hoe deze werkt wanneer een groot aantal gebruikers er gebruik van maakt.

Voorbeeld:

Laten we het hebben over PayTm.

U hebt vast allemaal wel eens op de ADD MONEY-optie in de PayTm-app geklikt, die vervolgens het saldo weergeeft dat u in uw portemonnee hebt. Als we kijken naar wat er achter de schermen gebeurt, dan is het een verzoek dat naar de server gaat met de PayTm UserID en de server stuurt het antwoord terug met het saldo op uw rekening.

Het bovenstaande geval doet zich alleen voor wanneer één gebruiker de server heeft aangesproken. We moeten ervoor zorgen dat zelfs als 1000 gebruikers de server benaderen, zij op tijd antwoord krijgen, omdat de bruikbaarheid voor eindgebruikers ons belangrijkste doel is.

Conclusie

Ik zou deze tutorial afsluiten door te herhalen dat mobiel testen in het begin heel eenvoudig lijkt, maar als je je erin blijft verdiepen, zul je begrijpen dat het niet eenvoudig is om ervoor te zorgen dat wat er ook is ontwikkeld, soepel zal draaien op duizenden apparaten over de hele wereld.

Je zou meestal de apps zien die alleen op de nieuwste en laatste paar versies van OS worden ondersteund. Echter, het wordt de plicht van de testers om ervoor te zorgen dat ze niet missen geen scenario’s. Er zijn vele andere punten die moeten worden genomen in overweging, maar ik heb niet genoemd die reeds iterated in de andere tutorials.

Scenario’s zoals batterijverbruik, interrupt testen, testen op verschillende netwerken (3G, Wi-Fi), testen tijdens het schakelen van netwerken, aap testen van mobiele apps, enz. zijn allemaal nuttig als het gaat om mobiel testen.

De houding van de testers is van groot belang als het gaat om de echte testomgeving. Tot en tenzij je van je werk houdt, zul je niet de moeite nemen om dingen te doen die in de tutorial worden genoemd.

Ik ben nu ongeveer 6 jaar in dit veld en ik ben me er heel goed van bewust dat de taken soms eentonig worden, maar er zijn veel andere dingen die we op onszelf kunnen doen om die eentonige taken enigszins interessant te maken.

Het ontwerpen van de juiste teststrategie, het kiezen van de juiste mobiele simulatoren, apparaten en mobiele testtools kan ervoor zorgen dat we 100% testdekking hebben en ons helpen om beveiliging, bruikbaarheid, prestaties, functionaliteit en compatibiliteit gebaseerde tests op te nemen in onze testsuites.

Wel, dit is onze poging geweest om meerdere verzoeken van onze lezers over een mobiele applicatie testgids te vervullen.

Auteurs: Met dank aan Swapna, Hasnet, en vele andere mobiele testen deskundigen voor het helpen ons samenstellen van deze serie!

In ons volgende artikel, zullen we meer bespreken over iOS App Testing.