Tutorial voor het testen van mobiele gebruikersinterface (GUI-testen van iOS- en Android-apps)

mobile ui testing tutorial gui testing ios

Handleiding voor het testen van de gebruikersinterface van mobiele apps: leer hoe u iOS- en Android-UI-tests uitvoert

Met de bloeiende markt voor mobiele telefoons wordt het testen van mobiele applicaties elke dag spannend.

welke van de volgende zaken geldt voor een integratietest?

Alleen door functionele tests uit te voeren op een mobiele applicatie, kunt u de app niet afmelden. Er zijn enkele andere soorten tests, zoals veldtests, netwerktests, UI-tests, testen van de levensduur van de batterij, enz., Die moeten worden uitgevoerd.

UI-testen is een van de belangrijke tests bij het testen van mobiele applicaties en het moet niet lichtvaardig worden opgevat.

Grafische gebruikersinterface zorgt voor veel verschil in hoe interessant en interactief een gebruiker uw toepassing vindt. Het belang van een fatsoenlijke en aantrekkelijke GUI is duidelijker voelbaar in een smart device-omgeving waar de schermgrootte veel kleiner is dan die van een laptop of desktop.

Wat je leert:

• Het belang van de gebruikersinterface van de mobiele app testen
• Hoe te beslissen hoeveel UI-tests nodig zijn?
• Richtlijnen: wat te testen bij het testen van de gebruikersinterface van mobiele apps
  • # 1) Schermresolutie
  • # 2) Schermgrootte
  • # 3) Verschillende UI-elementen
  • # 4) Stijl: kleur- en themaschema van het apparaat
  • # 5) Multi-touch of Single touch
  • # 6) Lang of kort indrukken
  • # 7) Locatie
• Hoe UI-variaties in verschillende OS-versies te testen?
• Echte apparaten of emulators: wat te kiezen voor UI-testen?
  • Voordelen
  • Nadelen
• Handmatig of geautomatiseerd UI-testen?
• UI-testtools voor mobiele apps
• Checklist voor het testen van de gebruikersinterface van mobiele apps
• 5 mythes over geautomatiseerde mobiele UI-tests
  • Mythe 1: snelheid
  • Mythe 2: dekking
  • Mythe 3: kosten
  • Mythe 4: consistentie
  • Mythe 5: onwil
• De mythe en realiteit
• Gevolgtrekking
• Aanbevolen literatuur

Het belang van de gebruikersinterface van de mobiele app testen

Heeft u als gebruiker zin om een ​​app te gebruiken die geen gebruikersinteractie heeft en het moeilijk maakt om te begrijpen hoe u deze moet gebruiken?

Wanneer gebruikers een mobiele applicatie voor het eerst gebruiken, zijn het niet alleen de prestaties die de aandacht trekken, maar ook de aantrekkelijke gebruikersinterface. Een UI-vriendelijke applicatie verkoopt meer in vergelijking met een app die het best is ontwikkeld, maar met een vervelende gebruikersinterface.

Als een applicatie een perfecte en prachtige gebruikersinterface heeft op het ene apparaat, maar op het andere apparaat volledig verdraaid is, alleen omdat het een andere grootte of een ander besturingssysteem heeft, dan zal het een zeer slechte indruk achterlaten. Het commerciële succes van de applicatie zal ernstig worden aangetast.

Gaat u een app promoten waarbij de knop te klein is om op te klikken en de hele set functionaliteit te blokkeren?

Zijn dit niet onaangename ervaringen voor de gebruikers? Vanwege de bovengenoemde gevallen wordt het erg belangrijk om de gebruikersinterface van een applicatie te testen. De twee belangrijkste verificatie die moet worden gedaan voor mobiele applicaties is gebruiksvriendelijkheid en uiterlijk voor verschillende modellen en OS-versies.

Hieronder volgt een voorbeeld van hoe de gebruikersinterface perfect moet zijn voor verschillende schermformaten:

Hoe te beslissen hoeveel UI-tests nodig zijn?

De volgende grafiek geeft de verschillende branches weer waarin mobiele apps kunnen worden ingedeeld:

(beeld bron ​

Uit de bovenstaande grafiek kun je opmaken dat gaming-apps het grootste deel van het marktaandeel van ongeveer 24,43% innemen, gevolgd door zakelijke en educatieve apps.

• Apps die zijn ontwikkeld als gaming-apps, moeten op elk aspect grondig worden getest, aangezien de gebruikersinterface de grootste bijdrage levert aan succes, ongeacht of het een native of hybride app is
• Een zakelijke app kan voor het succes niet volledig vertrouwen op de gebruikersinterface, omdat in de meeste gevallen de doelgroepen worden getraind om de app te gebruiken. Daarom kunnen dergelijke apps een eenvoudige gebruikersinterface hebben.
• Apps die voor educatieve doeleinden zijn ontwikkeld, moeten grondig worden getest.
• Commerciële apps zoals winkelen, reizen, enz. Hebben ook volledige UI-tests nodig op verschillende apparaten en verschillende OS-versies.

Kortom, afhankelijk van het doel van de app kan de diepte van de UI-tests worden bepaald, maar UI-tests moeten altijd worden uitgevoerd op ten minste 3 verschillende OS-versies.

Richtlijnen: wat te testen bij het testen van de gebruikersinterface van mobiele apps

Tijdens het testen van de gebruikersinterface op een mobiele applicatie, moeten verschillende kenmerken worden geverifieerd.

Hieronder volgen enkele van de kenmerken die voor elke app moeten worden getest:

# 1) Schermresolutie

Hieronder volgen enkele van de algemene schermresoluties die in overweging worden genomen bij het maken van testbeds:

• 640 × 480
• 800 × 600
• 1024 × 768
• 1280 × 800
• 1366 × 768
• 1400 × 900
• 1680 × 1050

Al deze resoluties zijn een must om te testen wanneer u een lay-out met meerdere kolommen in uw app heeft.

Daarom moet verificatie worden uitgevoerd vanaf de kleinste tot de grootste resolutie. Afgezien hiervan, als uw app een lange lijst met kaarten met informatie heeft, moeten deze ook worden getest op een andere resolutie voor hun informatieverpakking.

​ afbeeldingsbron ​

# 2) Schermgrootte

Er zijn te veel variaties in schermformaten en beschikbare resoluties. Vooral bij slimme apparaten zijn de afmetingen van de bedieningselementen niet statisch, ze hebben betrekking op de beschikbare schermgrootte.

Zorg er tijdens het testen voor dat de grootte van de bedieningselementen er esthetisch goed uitziet en dat de bediening volledig zichtbaar is op het scherm zonder te scrollen. Test de GUI op verschillende apparaten met verschillende schermformaten en resoluties.

Emulators zijn goed voor dit doel, maar niets komt overeen met het echte apparaat. Zorg er dus voor dat u op minimaal twee of drie echte apparaten test. Vergeet ook niet te testen op landschaps- en portretoriëntaties als het apparaat dit ondersteunt.

U moet de toepassing testen onder veelgebruikte resoluties om de bruikbaarheid ervan te garanderen.

Enkele dingen die u hier moet begrijpen, zijn:

Het verschil tussen schermgrootte en resolutie: De schermgrootte is de lengte van het scherm in inches gemeten diagonaal of van de ene hoek naar de andere hoek van het scherm. De schermresolutie is de breedte en hoogte, Voorbeeld 640w × 480h, dat staat voor het aantal pixels dat over het scherm gaat, vermenigvuldigd met een aantal pixels naar beneden.

# 3) Verschillende UI-elementen

De UI-elementen zoals knoppen, koppen, pictogrammen, afbeeldingen, selectievelden, tekstvelden, selectievakjes, enz., Zijn enkele van de verschillende elementen die moeten worden gecontroleerd op hun uiterlijk en grootte op het scherm.

Specifiek voor tekstvelden, als het zachte toetsenbord wordt weergegeven op de tik in het tekstveld, moet het worden getest en geverifieerd.

Het belangrijkste is dat het grondig testen van knopgroottes vereist is, omdat ik me herinner dat we in onze app tijdens het testen op de Galaxy S-telefoon een blokkering vonden waarbij een knop de hele app had geblokkeerd alleen omdat de knop te klein leek om op te klikken.

De positie van de UI-elementen moet ook worden geverifieerd aan de hand van de vereiste, d.w.z. of ze allemaal gecentreerd of links uitgelijnd moeten zijn enz.

# 4) Stijl: kleur- en themaschema van het apparaat

De gebruikersinterface en het kleurenschema van de app moeten consistent zijn met verschillende kleuren en themaschema's van de telefoon. De kleur en het thema van een Samsung-telefoon zijn heel anders dan die van Nokia of de MI-telefoon ​

Daarom moet u controleren of de app er consistent uitziet op dergelijke telefoons.

Uw applicatie heeft een specifiek ontwerp. En de stijl van de bedieningselementen moet bij dat ontwerp passen. U heeft wellicht veel toepassingen gezien waarvan sommige bedieningselementen, bijv. panelen hebben ronde randen en andere bedieningselementen, b.v. tekstvakken hebben scherpe randen.

Hoewel dit soort problemen geen invloed heeft op de bruikbaarheid of functionaliteit van de app, helpt een consistent uiterlijk van de app om een ​​vriendelijke relatie op te bouwen tussen de applicatie en de gebruiker.

Een van de belangrijkste dingen in stijl is het lettertype van de verschillende pagina's. Het lettertype moet goed worden getest om inconsistenties in het uiterlijk van de toepassing te voorkomen.

Meestal concentreren we ons op de tekst die in normale situaties zichtbaar is en negeren we de tekst die in specifieke situaties verschijnt. Succes- en foutberichten zijn een voorbeeld van een dergelijk type tekst.

Een andere factor die belangrijk is in stijl, is een relatie tussen de kleur van het lettertype en de situatie waarin tekst wordt weergegeven.

Bijvoorbeeld, Rode kleur wordt gebruikt voor foutmeldingen, groen voor succes, geel voor waarschuwingen en blauw voor hyperlinks.

# 5) Multi-touch of Single touch

Als uw app de multi-touch-functie ondersteunt, zoals knijpen om te zoomen of knijpen om te verkleinen enz., Dan moet u deze functie grondig testen en hiervoor veel testcases maken voor alle toepasselijke schermen.

# 6) Lang of kort indrukken

Een lange druk op een pictogram geeft het contextmenu weer, terwijl een korte aanraking de allereerste actie van het menu uitvoert. Als deze functie in uw app beschikbaar is, moet u deze functionaliteit en alle functionaliteiten eromheen verifiëren.

# 7) Locatie

Locatie en positie zijn de twee woorden die afwisselend worden gebruikt en, interessant genoeg, ze worden verder gebruikt om twee verschillende concepten over te brengen die hieronder worden uitgelegd:

1) Soms is het het gebied op het scherm waar een besturingselement verschijnt.

Bijvoorbeeld, Header bevindt zich op top van de pagina, Labels zijn Links uitgelijnd , en tekstvakken zijn Rechts uitgelijnd, etc. Hier zijn ‘top’, ‘left Aligned’ en ‘Right Aligned’ relatieve posities van de bedieningselementen.

twee) Soms is het de volgorde van controle tussen de andere controles.

Bijvoorbeeld, terwijl u persoonlijke informatie ontvangt, is voornaam gevolgd op achternaam. Of de indeling van besturingselementen die om een ​​Amerikaans adres vragen, moet de indeling hebben bestellen - postcode, stad, staat.

Voor beide situaties hebben we het over de locatie van de bedieningselementen.

Zorg er bij het testen van de locatie en positie van de bedieningselementen voor dat alles logisch op het scherm is geplaatst en er een goed gevoel voor heeft.

Er zijn situaties waarin een of meer bedieningselementen op meer dan één scherm verschijnen. In deze situatie moet u ervoor zorgen dat ze op alle pagina's op dezelfde locatie en in dezelfde relatieve volgorde verschijnen.

Hoe UI-variaties in verschillende OS-versies te testen?

De gebruikersinterface varieert met de OS-versie en met de lancering van een nieuwe versie worden verbeteringen aangebracht in de gebruikersinterface.

Laten we eens kijken naar de gebruikersinterface van het 3 nieuwste besturingssysteem dat momenteel beschikbaar is en begrijpen hoe deze variaties van invloed zijn op een mobiele applicatie.

Zij zijn:

1. Lolly
2. Heemst
3. Noga

Als je naar de bovenstaande lijst met nieuwe gebruikersinterface- of functionaliteitsfuncties kijkt, moet je als QA hier testcases omheen ontwerpen.

1) Lolly:

• Maak testcases voor het effect van het nieuwe ontwerp op uw app.
• Niet per se voor alle schermen, maar maak testcases om toegang te krijgen tot de nieuwe snelkoppelingen in uw app.

2) Heemst:

• Als uw app met emoji's te maken heeft, maakt u testcases om de nieuwe emoji's te verifiëren. Apps waarmee gebruikers recensies kunnen schrijven of kunnen chatten, zijn degenen die vaak emoji's gebruiken.
• Wanneer uw app voor de eerste keer wordt gepubliceerd en geïnstalleerd, moet deze mogelijk om toestemming worden gevraagd, vandaar dat de UI-tests van het nieuwe toestemmingsscherm moeten worden uitgevoerd. En maak hiervoor testcases.
• Als uw app Google Now gebruikt, moet u testcases maken om de bijgewerkte gebruikersinterface van Google Now te testen.

3) Nougat:

• Je app moet grondig worden getest voor de daydream reality-modus en dienovereenkomstig testcases maken.
• Maak testcases om de menu-opties voor uw app te verifiëren.
• Als uw app te maken heeft met emoji's en GIF's, maak dan testcases om de nieuwe emoji's te verifiëren en de optie om GIF's te verzenden.

Echte apparaten of emulators: wat te kiezen voor UI-testen?

Wanneer u een mobiele applicatie moet testen, denkt u misschien na over wat het testbed zou moeten zijn?

Of u wilt testen op een echt apparaat of emulator of beide? Hier is geen definitief antwoord op, omdat de keuze afhangt van wat u wilt testen.

Voor het testen van de functionaliteit, prestaties, netwerkrespons, veldtest, enz., Zou u altijd de voorkeur moeten geven aan een echt apparaat. Maar voor zaken als UI moet u emulators kiezen samen met enkele echte apparaten.

Voordelen

De voordelen van het gebruik van emulators voor UI-testen zijn:

1) Het is praktisch niet mogelijk om de apparaten van alle resoluties te verzamelen en dat zou ook enorm veel geld kosten. Maar emulators kosten niets.
twee) Met een emulator kun je alle schermresolutie en OS-combinaties maken.
3) Als u slechts één set echte apparaten heeft, maar het QA-team bestaat uit meer dan 1 persoon, dan kunnen alle QA's niet parallel testen voor hetzelfde testbed. Met een emulator kan elke QA dezelfde combinatie op hun computer maken en parallel testen.
4) Testen op een emulator kost minder tijd en is sneller in vergelijking met een echt apparaat.
5) Veelvoorkomende bugs met betrekking tot de gebruikersinterface, zoals uitlijning enz., Kunnen gemakkelijk worden opgemerkt op emulators.

Nadelen

Nadelen zijn onder meer:

1) Gebaren kunnen niet worden getest op emulators. Er kan slechts één gebaar tegelijk worden geëmuleerd.
twee) Fysieke invoer van GPS, uitval of zwak netwerk, enz. Kunnen ook niet worden getest.
3) U kunt op geen enkele manier een emulator maken voor telefoons van Sony, LG, Nexus, enz.
4) Het is niet mogelijk om op de emulator een echte omgeving te creëren met een bijna lege batterij of een laag geheugen enz.

Daarom moet de beslissing worden genomen afhankelijk van uw app en de testvereiste.

Handmatig of geautomatiseerd UI-testen?

Geen enkel product, of het nu een desktop-app, een webapp of een mobiele app is, kan worden uitgebracht zonder te testen. Als QA hebben we moeite om elk defect te vinden en te rapporteren, maar toch worden ze door klanten gemeld.

Weet u waarom?

Omdat langdurige tests vaak worden vermeden of gemist, waardoor onontdekte bugs achterblijven. Ook 100% dekking, diepgaande uitvoering is niet mogelijk met handmatig testen.

interviewvragen over rustgevende webservices

UI-testen is vrij eenvoudig en duidelijk en u hoeft alleen maar te kijken naar hoe het eruit ziet voor uw oog. Als dit nu handmatig wordt gedaan, is het erg tijdrovend. Bovendien moeten we meestal enorme gegevens maken voor het testen van de gebruikersinterface, zoals een scroll alleen verschijnt als de rijen kaarten een bepaald aantal overschrijden.

Het creëren van big data is erg tijdrovend. Het hebben van een geautomatiseerde suite kan beide problemen oplossen.

Als de functionaliteiten of UI van de app zich daarentegen nog in een veranderende fase bevinden, heeft het geen zin om in automatisering te investeren. Evenzo, als de functionaliteiten van de app essentieel zijn, is het beter om handmatig te testen.

Daarom moet u, afhankelijk van de volgende aanwijzingen, beslissen of u handmatig wilt testen of wilt automatiseren:

• De aard van uw app.
• De stabiliteit van uw app.
• De beschikbare middelen zoals mankracht om de tools te bestuderen en te vergelijken.
• Hoeveel tijd is er nodig om een ​​automatiseringstool te bestuderen en op te starten?
• Is de klant bereid om tijd te investeren in de opstart en studie?

UI-testtools voor mobiele apps

Hieronder volgt een lijst met 5 tools die kunnen worden gebruikt voor UI-testen van een mobiele applicatie voor Android en / of iOS.

(Voor tools voor het testen van functionaliteit y U kunt verwijzen naar de lijst met automatiseringstools op onze automatisering tools voor het testen van Android-applicaties bladzijde).

# 1) Selendroid

Selendroid is een van de beste en meest aanbevolen tools voor het automatiseren van mobiele applicaties voor UI-testen.

Het kan worden gebruikt voor zowel native als hybride apps. Het kan alleen worden gebruikt voor Android-apps en de client-API-tests zijn geschreven met Selendroid 2. Het kan ook met meer dan één apparaat worden gebruikt en is volledig compatibel met JSON.

# 2) Testdroid

Dit is een cloudgebaseerde tool en kan worden gebruikt voor een verscheidenheid aan apparaten, verschillende schermresoluties en OS-versies van zowel Android als iOS. Het parallel testen van apparaten is een groot voordeel van deze tool en is een goede tool voor UI-testen. Het helpt de ontwikkelaars om de time-to-market te verbeteren.

# 3) ZieTest

Het is een betaalde tool en kan worden gebruikt voor Android, iOS, Windows, Symbian, etc.

Het is een platformonafhankelijke tool en daarom is het voordeel dat dezelfde test op alle platforms kan worden uitgevoerd. Het kan voor alle mobiele toepassingen worden gebruikt en de tests kunnen parallel op meer dan één apparaat worden uitgevoerd.

# 4) UI-automatisering

Dit is de officiële UI-testtool voor Apple en is de beste tool voor het automatiseren van iOS-applicaties. Hoewel het moeilijk te leren is, biedt het een groot voordeel met bibliotheken, prestaties, UI-testen, enz.

# 5) Kalebas

Het kan worden gebruikt voor zowel Android- als iOS-tests voor native of hybride apps. Het is een platformonafhankelijke tool en kan het beste worden gebruikt voor het automatiseren van gebaren, schermafbeeldingen, beweringen, enz. Het kan worden gebruikt op echte touchscreen-apparaten. Het heeft ook ondersteuning voor komkommer.

Wanneer ontwikkelaars de app unit testen, kunnen ze ook UI-testen doen met Android Studio, maar deze kan alleen worden gebruikt voor Android-applicaties.

Aanbevolen literatuur => Automatiseer gebruikersinterfacetests

Checklist voor het testen van de gebruikersinterface van mobiele apps

Hieronder vindt u de checklist voor testers om ervoor te zorgen dat de GUI volledig goed wordt getest op slimme apparaten:

5 mythes over geautomatiseerde mobiele UI-tests

Geautomatiseerde mobiele UI-tests worden als cruciaal beschouwd wanneer de kwestie van het succes van een applicatie zich voordoet. Maar er zijn enkele mythes die verband houden met geautomatiseerd testen.

Dergelijke mythen zijn misschien niet waar omdat ze oppervlakkig kunnen zijn. Door diep in het proces van geautomatiseerd testen te duiken, verdwijnt het. Laten we er dieper op ingaan.

Mythe 1: snelheid

Deze mythe komt veel voor. De meeste mensen in de IT-industrie hebben de mythe dat het uitvoeren van 'automatiseringstests' meer tijd kost in vergelijking met 'handmatige tests'. Dit feit is tot op zekere hoogte waar in een paar scenario's.

De reden is dat handmatig testen snelle resultaten oplevert in vergelijking met geautomatiseerde mobiele UI-tests. Maar dit is alleen het geval in de voorbereidende en beginfase.

Bij herhaaldelijk testen, moet u veel meer testfuncties toevoegen of afnemende testkwaliteiten. Terwijl u met geautomatiseerd testen altijd dezelfde testniveaus uitvoert, waardoor u op de lange termijn tijd bespaart.

Mythe 2: dekking

In het huidige scenario worden regelmatig nieuwe Android-apparaten op de markt uitgebracht. En het aantal apps van dergelijke besturingssystemen (OS) neemt toe. Dan zijn er besturingssystemen zoals iOS die nog meer apps hebben gemaakt voor dagelijks gebruik.

Handmatig testen voor zoveel apps wordt erg moeilijk. Maar in het geval van geautomatiseerd testen is onderhoud van cloudservers voldoende. Met behulp van geautomatiseerd testen is een totale en volledige testdekking van de apps mogelijk.

Mythe 3: kosten

Het is een feit dat geautomatiseerd testen van de apps meer kost in vergelijking met de kosten van handmatig testen. Dit is echter alleen waar als er tests worden uitgevoerd voor de essentiële zaken van de app. Naarmate de omgeving van de app en de software gecompliceerd worden, wordt handmatig testen duurder.

Dit komt doordat er meer geavanceerde tools nodig zijn voor optimale testresultaten. Naast deze geavanceerde testtools is er behoefte aan hoog opgeleid personeel dat dergelijke tools kan beheren. Dit vereist training.

Handmatig testen wordt dus duurder in vergelijking met geautomatiseerd testen.

Mythe 4: consistentie

Bij handmatig testen is er altijd ruimte voor verschillende percepties die van tester tot tester verschillen. Dit hangt ook af van de overwogen tests, omgevingen en apps, samen met het besturingssysteem (OS).

Wanneer u handmatige tests toepast op de software, zijn er gaten waar weinig bugs doorheen kunnen komen. Daarom is handmatig testen alleen goed voor het opsporen van elementaire bugs. Geautomatiseerde tests worden uitgevoerd op de scripts zonder ruimte voor verschillende perceptie, waardoor het onfeilbaar is.

Mythe 5: onwil

Het is niet waar dat geautomatiseerd testen de mens heeft vervangen, het is eerder bedoeld om de handmatige tester te verbeteren. Geautomatiseerde tests leveren herhaaldelijk, meerdere keren met maximale nauwkeurigheid geautomatiseerde resultaten op. Dus de vraag rijst, waarom is er behoefte aan mensen?

Geautomatiseerd testen vereist scriptschrijven en de planning van de hele testprocedure. Deze taak vereist menselijke inspanning. De procedure van geautomatiseerd testen helpt om tijd en geld te besparen, zodat u dergelijke bronnen gebruikt voor de verbetering van procedures voor handmatig testen. De ontwikkeling van betere tools zal op zijn beurt helpen bij de bevordering van reeds bestaande procedures voor geautomatiseerd testen.

Bovengenoemde zijn enkele van de meest in de volksmond bestaande mythen die heersen in de industrie van geautomatiseerd testen. Dit moet worden uitgeroeid om de geautomatiseerde mobiele UI-tests te verbeteren.

De mythe en realiteit

Het is een feit dat zelfs de meest geavanceerde ontwikkelingsbedrijven handmatige tests voor mobiele telefoons gebruiken of helemaal geen volledige tests uitvoeren. Volgens de onderzoeken van Xamarin 2014 voert 13,2% van de ontwikkelaars van mobiele telefoons tests uit met geautomatiseerde gebruikersinterfaces. Volgens onderzoek van Forrester Research voert slechts 53% van de ontwikkelaars vluchtige tests uit op afzonderlijke apparaten.

De vijf meest voorkomende factoren waarom teams van mobiele telefoons de kwaliteiten van mobiele apps niet hebben geautomatiseerd en vijf redenen waarom deze niet alleen echt logisch zijn, zijn de volgende:

a) Snelheid is de eerste mythe.

Een persoon kan geen tijd nemen voor automatisering. In het jaar 2014 hadden de leveranciers 7000 nieuwe Android-apparaattypen geïntroduceerd. Dan waren er 10.000 API's die specifiek waren voor mobiele telefoons. De toepassing van mobiele telefoons wordt sneller verzonden en kan snel worden aangepast. Met Quality Assurance (QA) in constante crunch-modi, is er geen tijd om testscripts te maken, die op hun beurt synchroon blijven met regelmatig veranderende functies.

Het praktische scenario van de eerste mythe:

Een daarvan is momenteel kostbare tijd aan het verspillen. Het is heel waar. Handmatig testen is sneller dan automatisering. Maar dit is voor de allereerste testrun. Bij volgende runs, wat voor marginale voordelen het handmatig testen ook oplevert, in de richting van erosie. Dit is vrijwel direct. Samen met alle herhaalde testruns of functietoevoegingen moeten app-ontwikkelaars het testbereik of aanvullende testbronnen terugschroeven.

Samen met eindige budgettering leidt dit uiteindelijk tot de vicieuze cirkel van die kwaliteiten die aan het afnemen zijn. Als reactie op de gegevensbetrokkenheid en negatieve recensies van gebruikers van apparaten die niet zijn getest, willen teams een uitbreiding van de dekking van het apparaat. Deze verhogen nog meer de stress op QA-afdelingen als capaciteiten.

Het is dat het bedrijf worstelt met het onderhouden, onderzoeken en aanschaffen van apparaten tijdens het uitvoeren van testuitvoeringen. Zelfs de best gefinancierde handmatige testprogramma's van de gebruikersinterface worden verkort tot voltooide dekking.

In de VS moeten mobiele teams testen op 188 apparaten om 100 procent van de marketingaandelen te dekken. Volgens het Xamarin-onderzoek van 2014 testen de meeste ontwikkelingsteams regelmatig op 25 of minder apparaten.

Meer dan een kwart van deze ontwikkelaarsgemeenschappen richt zich op vijf of minder apparaten. In realistische testsituaties loont automatisering vrijwel onmiddellijk en onmiddellijk. Bij de allereerste testrun is het getuige dat consumenten de testtijdlijnen 4 keer versnellen. Het is meer dan volledig handmatig testen als je tegen vijftig of meer apparaten loopt.

Runs die in subreeks zijn, zijn veel sneller verlopen. Toch is er een verkorting voor een bijna volledige testweek tot slechts een gebruik van enkele uren.

b) Dekking is de tweede mythe.

Fragmentatie is de oorzaak dat er geen mogelijkheid is om de dekking van het apparaat te verbreden. Samen met meer dan 19.000 apparaten met unieke Androïden en een permutatie van tientallen voor het vormen van besturingssystemen en factoren voor iOS, zijn veel teams van mening dat het niet mogelijk is om de meerderheid van de apparaten in de voorziene markten te dekken.

Er is dus een standaardtest op het handjevol van deze apparaten, zoals goed genoeg.

De realiteit van de tweede mythe:

Men had de dekking van het apparaat kunnen voltooien. Als mensen apparaten in huis met een handvol onderhouden, doen ze veel. De aanschaf van apparaten is moeilijk.

Het behouden van hun geld, kosten en tijd, op hun beurt, het beschikbaar stellen van hun testers waar en wanneer dat nodig is, zorgt voor logistieke problemen. Gartner had verklaard dat mobiele ontwikkelaars manieren moesten vinden om hoge automatiseringspercentages te bereiken om het tempo van het platform en de verspreiding van veranderingen bij te houden. Dit was in de hosting geweest. Verschillende functies maakten gebruik van intern beheer.

De weg naar dergelijke automatisering loopt via clouddiensten van derden. De cloudservices van derden helpen bij het automatiseren van app-laadprocessen, de uitvoering van testscripts, rapportage van resultaten en het veilig opnieuw instellen van apparaatbacks voor standaarden van fabrieken. Ook worden subsets van tests van apps parallel uitgevoerd, waardoor de resultaten worden versneld.

Terwijl ze testen op een breed scala aan echte apparaten, stellen testwolken iedereen in staat om precies te weten hoe de app werkt, waardoor het typische giswerk van mobiele ontwikkelingen wordt geëlimineerd.

Voorbeeld: Productmanagers stellen minder systeemvereisten samen met vertrouwensrelaties die gerechtvaardigd zijn in de prestaties van apparaten. Ontwikkelaars ontvangen visuele objectieve bevestigingen van het oplossen van bugs voordat nieuwe builds worden toegevoegd. Dit is ongeacht waar en wanneer ze werken.

c) Kosten zijn de derde mythe.

Individuen kunnen zich alleen handmatige tests veroorloven. Voor het testen van automatisering zijn testscripts, leercurves voor QA-personeel en infrastructuur nodig. Veel teams hebben al moeite om deadlines te halen. Ze zijn al over het budget heen. Automatiseringstesten lijken dus ver weg te zijn.

Het praktische scenario voor de derde mythe:

Handmatig testen bespaart alleen geld als mensen dekking opofferen. Handmatig testen lijkt alleen minder duur in de meeste kale omgevingen.

In het geval van testen omvat een snelle 'darmcontrole' van basisfunctionaliteiten van minder apparaten, dan lijkt handmatig testen een koopje. Maar elke gelijkenis met testdekking en apparaat dat alomvattend is, zal handmatig testen veel duurder maken dan automatiseringstesten. Dit kan zelfs snel zijn.

Handmatig testen schalen alleen door de toevoeging van meer mensen en massa's. De kosten hebben geen echte lineariteit. Het opschalen van personeel om aan de eisen te voldoen, brengt enorme overheadkosten met zich mee in vormen van coördinatie en training. Verdeling van testcases vermindert daardoor de efficiëntie van alle testers door het verwijderen van perspectieven.

Bovendien zijn testers die over voldoende raffinement beschikken om verder te gaan dan het gebruikersgedrag en daarbij de redenen waarom applicaties mislukken te onderzoeken en te anticiperen, wellicht niet talrijk of goedkoop. Automatiseringstesten vereisen altijd iets meer overhead op het moment van de eerste installatie.

Maar zoals hierboven vermeld, kan het bij testsnelheden dramatisch winsten en winsten opleveren. Het zorgt ook voor een overeenkomstige personeelsreductie binnen een paar dagen. Cloudgebaseerde testomgevingen hebben de kosten verder verlaagd. Dit komt door het elimineren van onderbenutte en dure testinfrastructuur op locatie.

d) Consistentie moet de vierde mythe zijn.

Goed genoeg moet worden uitgevoerd, uitgevoerd en bediend. Voor verschillende testteams zijn kant-en-klare implementaties subjectieve beslissingen die zijn gebaseerd op de percepties van veel verschillende handmatige testers. Ze weten dat de bedoeling is dat insecten door scheuren vallen.

Overlappende testdekkingen moeten de meest voorkomende en kritieke problemen oplossen voordat ze worden uitgebracht. De rest van de bugs wachten op onderhoudsreleases.

Het echte scenario van de vierde mythe:

Kwaliteiten zijn niet kwalitatief. De gereedheid van producties mag geen factoren en meningen zijn. In een puur handmatige testomgeving variëren de percepties van de ene test tot de andere test en van de ene tester tot de andere tester. Dit leidt tot grillige testresultaten en in-consistente documentatie.

Beslissingen worden gecompliceerd wanneer overwegingen van gereedheid van producten aanwezig zijn. Het leidt tot mislukte compliances, massale ontgoocheling en gederfde inkomsten. Bovendien is er het ontstaan ​​van zakken met onontgonnen tribale inzichten die verloren gaan wanneer mensen en werknemers de deur uitgaan.

Automatisering zorgt op zijn beurt voor meetbare statistieken. Dit dient als objectieve bronnen voor de waarheid voor het informeren van beslissingen met betrekking tot de rechtvaardiging van de zakelijke beslissing, de gereedheid van het product en de voortgang van grafiekteams.

e) Tegenzin is de vijfde mythe.

Handmatig testen is vervangen door automatiseringstesten. Veel verschillende ontwikkelaars hebben toegang tot testautomatisering omdat ze verwachten testers te vervangen die handmatig werken met machines.

In het geval dat de automatisering van tests soortgelijke tests 1000 keer herhaalt met een nauwkeurigheid van 100 procent, dan ontstaan ​​er vragen over de vraag waarom mensen behoefte hebben aan testdoeleinden. Automatisering van testscripts kan ook door machines worden gedaan.

Het realtime beeld van de vijfde mythe:

etl testinterviewvragen en antwoorden voor ervaren pdf

Handmatige testers worden beter met automatiseringstesten. Machines en mensen beschikken over goede scenario's voor veel verschillende dingen en factoren. Testers die handmatig testen, kunnen altijd creatiever testen.

Door automatiseringstests hoeven ze dit niet meer te doen. Terwijl mensen uitkijken naar nieuwere manieren om apps te breken, zorgt automatisering voor compatibiliteit voor het brede scala aan apparaten. Dit is van eenheidstests tot volledige regressietests. Twee benaderingen hoeven niet geïsoleerd te werken.

Om tests uit te voeren als verkennend handmatig terwijl back-end-systemen niet zijn belast door geautomatiseerde tests. Dit zijn uitstekende manieren om fouten te ontdekken die opduiken in productiesituaties. Automatiseringstests zijn geen vervanging voor testers die mensen zijn. Hierdoor kunnen ze lonend en interessant werk verrichten.

Betere consistentie, dekking, kosten en snelheid dragen bij aan die kwaliteiten die worden verbeterd. Door geld en tijd te besparen, kan men meer testen en niet minder. Dit is het geval wanneer men mijlpalen bereikt die kritiek zijn. Hierdoor kunnen testen samen met teams van agile ontwikkelingen gelijke tred houden in plaats van in de weg te staan.

Organisaties geven dus veel vaker code vrij. Dit vermindert de impact en het aantal defecten krijgt builds. Dit betekent dat ontwikkelaars werken met schone codes. Het oplossen van bugs is dramatisch minder gecompliceerd. Dit bevrijdt testers door alleen als poortwachters op te treden, gericht op creativiteit. Verkennend testen verbetert daarmee de kwaliteit van producten.

Automatiseringstesten van mobiele gebruikersinterfaces biedt voordelen op het gebied van tijden en kwaliteiten. Tools die zijn geautomatiseerd, waardoor het voor testers gemakkelijk is om gebruikersinterfaces van apps te beoordelen via een groter bereik van de mobiele apparaten, samen met het aanbrengen van wijzigingen om de gebruikerservaring eenvoudig te verbeteren.

Gevolgtrekking

Een slechte GUI is een onaangename ervaring voor de gebruiker. De GUI-testen worden sterk aanbevolen en belangrijk, vooral als het gaat om slimme apparaten, omdat hier de schermgrootte relatief klein is en er veel variaties van de apparaten op de markt beschikbaar zijn.

Uw toepassing kan er op verschillende apparaten anders uitzien en zich anders gedragen. Het is dus belangrijk om de app te testen op ten minste enkele standaardformaten en variaties van apparaten.

Alle mobiele applicaties hebben UI-tests nodig, maar de diepgang van de vereiste tests wordt bepaald door de categorie of het doel van de applicatie. U moet een volledige analyse maken van de gebruikersinterface-functies van de applicatie aan de hand van het telefoonmodel of de OS-versies voordat u uw testbed afmaakt.

Op basis van deze analyse moet u uw testcases maken om te testen. Gebruik waar mogelijk automatisering om tijd te besparen.

Houd een oogje in het zeil tijdens het testen van de gebruikersinterface, want het is eenvoudig maar het heeft een groot effect op de verkoop van uw app.

Bekijk onze aanstaande tutorial voor gedetailleerde informatie over Mobiele responsieve test ​

Aanbevolen literatuur

• Appium-zelfstudie voor het testen van mobiele Android- en iOS-apps
• TOP 15 beste mobiele testtools in 2021 voor Android en iOS
• Beste softwaretesttools 2021 (QA Test Automation Tools)
• Beta-testservices voor mobiele apps (bètatesttools voor iOS en Android)
• Waarom is mobiel testen moeilijk?
• Aan de slag met Robotium - De meest populaire UI-testtool voor Android-applicaties
• Primer eBook downloaden testen
• 11 beste automatiseringstools voor het testen van Android-applicaties (Android App Testing Tools)