Share
Het testen van een app op Android of iOS is niet zo heel anders. Het doel is hetzelfde, het gewenste resultaat is hetzelfde en het proces is vergelijkbaar. Het grote verschil is dat we naar de details gaan kijken. Dat is wat ik van plan ben in dit artikel te doen.
Voordat we erin duiken, laten we het hebben over enkele fundamentele tests. Het is onmogelijk om onze opties te bekijken tenzij we de volledige afbeelding kennen en begrijpen.
Wat onderscheidt van Android is de ontelbare mogelijkheden. Op iOS is er een iPhone, iPad en iPod Touch. Ze zijn verschillend, maar de gemeenschappelijke factor tussen iOS-apparaten is pixeldichtheid, schermresolutie, processorsnelheden, geheugengrootte, enz.
In het geval van Android zijn er duizenden combinaties wanneer we kijken naar dezelfde factoren, schermresolutie en -grootte, processorsnelheden, geheugengrootte en, de kers op de taart, de fragmentatie van het besturingssysteem.
Over versies van het besturingssysteem gesproken, het is niet ongebruikelijk dat vervoerders en telefoonfabrikanten niet lang na het uitbrengen van het product updates stopzetten. Is dit een probleem? Ja. Bekijk de officiële Android marktaandeelstatistieken van Google om een idee te krijgen van de schaal van het probleem.
In dalende volgorde van marktaandeel hebben we Jelly Bean (4.1-4.3), Gingerbread (2.3) en Ice Cream Sandwich (4.0).
Vergelijk dat eens met de acceptatiegraad van iOS 7 van Apple. Eind januari van dit jaar had 80% van de iOS-apparaten iOS 7. Let wel dat iOS 7 in september 2013 werd uitgebracht. Dat is een groot verschil.
Heb je ooit een echt slechte Android-applicatie gebruikt? Erger nog dan een regelrechte slechte applicatie is echt een geweldige applicatie die een paar hardnekkige fouten bevat.
Ik voel een grote factor in goed testen is aandacht schenken aan wat je gebruikt, leuk vindt en haat. Haat is een sterk woord, maar ik weet zeker dat er altijd iets opvalt.
Stel jezelf de volgende vragen:
Laten we verwijzen naar die marktaandeelgrafiek van Android OS die we eerder zagen. Het is niet realistisch om het testen te benaderen met de gedachte dat je elk apparaat en elke smaak van Android zult ondersteunen.
Mijn punt is dat we moeten nadenken over de verdeling. Wat doet onze app en hoe ziet de doelmarkt eruit? Is het een game of een utility-applicatie?
Als het een spel is, is de focus waarschijnlijk alleen nieuwere en hogere apparaten. Een hulpprogramma kan echter door een breder publiek worden gebruikt en moet op een groter aantal apparaten werken.
Een probleem waarvan ik het gevoel heb dat de meesten van ons er tegenaan lopen, is dat we te dicht bij onze projecten staan. We weten hoe we onze app kunnen laten mislukken en hoe we deze kunnen laten werken. Om deze reden probeer ik met opzet mijn gedachten te richten op die van een gebruiker. Ik heb gebruikers in twee brede categorieën geplaatst, de Knop Stamper en de Gebruiker.
De Button Masher is het type gebruiker dat net begint te tikken op het scherm, een knop hier, een knop daar. "Die laatste knop heeft niets gedaan, ik zal er nog een raken."
Wat we van dit gebruikerstype kunnen leren, is waar we binnen onze app intensieve processen hebben. Als er iets gebeurt en er een ander verzoek of andere actie plaatsvindt, spijkeren we dan de processor of vullen we het geheugen van het apparaat op? Zorgt ervoor dat de toepassing crasht?
De andere vraag die aan de oppervlakte komt, is: 'Hoe goed informeren we de gebruiker over wat er aan de hand is'. Waarom klikten ze op een andere knop in plaats van te wachten? Kunnen we dit verhelpen door een laadscherm te tonen??
De gebruiker heeft de intentie. Een betere manier om dit type gebruiker uit te leggen zou zijn om naar use cases te kijken. Er is een specifieke taak die ze willen volbrengen en een specifieke stroom die ze proberen te volgen.
We kunnen leren hoe duidelijk de app is om een persoon door een proces of actie te leiden. Het zal ons laten zien waar een gebruiker verdwaalt en welke gebieden meer aandacht of verfijning vereisen.
We hebben ons doel en verschillende soorten gebruikers besproken, maar wat zijn onze opties en hoe moeten we ze testen? Gelukkig zijn er veel. En ik raad u aan zoveel mogelijk te doen.
Als je niet de luxe hebt om naar de QA-afdeling of een testlaboratorium te kunnen lopen, kun je een vriend bellen. Je hebt ogen nodig en je hebt apparaten nodig.
Als het gaat om het testen van mobiele apps, kan volume een verschil maken, vooral als u verschillende apparaten kunt krijgen.
Geautomatiseerd testen is je vriend. Hoewel er niets leuker zal zijn met een complete applicatie, is het ook belangrijk om te zien wat er onder de motorkap gebeurt en hoe je app programmatisch zal reageren op bepaalde situaties of onder stress staat..
Nog belangrijker is dat unit testing u toelaat om te testen terwijl u werkt, wat veel tijd kan besparen tijdens het testen en QA, voorafgaand aan de release.
De Android SDK wordt geleverd met het Android-testraamwerk, dat bestaat uit een test-API op basis van JUnit en monkeyrunner.
Met de Android JUnit-extensie kunnen ontwikkelaars unittests schrijven tegen Android-componenten en de Android API met vooraf gebouwde componentspecifieke testcases.
Monkeyrunner is een op Python gebaseerde API waarmee u programma's kunt schrijven die vanuit de gebruiker een apparaat besturen. Dit betekent dat u tests kunt maken die op meerdere apparaten of emulators kunnen worden uitgevoerd en die met uw app kunnen communiceren, toetsaanslagen kunnen verzenden en schermafbeeldingen kunnen maken..
Er zijn veel testkaders beschikbaar. Een paar van de meer populaire zijn Robolectric en Robotium.
Robolectric is een eenheidstestkader dat wordt uitgevoerd in uw IDE. Dit is geweldig voor het controleren van uw code vóór de bouw. Robotium voert testen uit op de Android API in emulators. Hoewel het meer tijd kost om de tests af te ronden, zal uw applicatiecode veel meer van een real-world test tegen apparaten en de API ondergaan.
Een andere interessante optie is Espresso. Het dient een zeer specifiek doel in vergelijking met de vorige twee opties. Het is een API om tests uit te voeren tegen de gebruikersinterface van Android.
Alle bovenstaande opties zijn geweldig, maar als u een hybride app bouwt, kunt u deze mogelijk niet gebruiken. Appium is een platformonafhankelijk automatiseringsraamwerk waarmee u tests kunt bouwen met elke gewenste taal voor beide grote mobiele platforms.
Het is ook erg handig om wat statistieken te zien en, nog belangrijker, verzamel fouten en crash logs. Dit is vooral handig als u veel mensen uw toepassing laat testen, omdat het log kan worden om logboeken van elke afzonderlijke gebruiker te verzamelen.
Naast het bijhouden van het gebruik van apps, kan Google Analytics u ook uitzonderingen sturen. Flurry is een andere geteste optie. Ze bestaan al heel lang en hun rapportages en crashrapporten zijn wat gedetailleerder.
Hoewel dit niet helpt tijdens de ontwikkelingsfase van uw toepassing, verzamelt Google ook crashmeldingen voor apps in de Play Store.
We willen allemaal graag 400 apparaten testen, zoals die enorme testlaboratoria die we online hebben gezien. Dat is echter niet realistisch. Om dit probleem te verhelpen, zijn er veel services beschikbaar als u bereid bent te investeren in testen.
Deze services variëren van één-op-één echte menstests tot volledig geautomatiseerde tests op honderden apparaten. Als u bereid bent om ervoor te betalen, is deze beschikbaar.
Ik heb geen ervaring met de meeste hiervan, maar degene die ik heb gebruikt is User Testing. Het is zeer nuttig om te zien dat een persoon uw testscript volgt terwijl ze door uw toepassing tikken en u hun gedachten geven.
Dit zijn een paar diensten om te overwegen:
Te vaak ben ik de situatie tegengekomen waarin QA en testen een soort nabeschouwing leek. In werkelijkheid is dit waarschijnlijk het belangrijkste onderdeel van het ontwikkelingsproces.
Android, met zijn vele smaken, lijkt misschien intimiderend, maar wanneer het bijna programmatisch benaderd wordt, wordt het echt een deel van het proces. Het is de extra tijd en moeite waard. Kwaliteitsapps vinden niet alleen plaats.
Accentsconagua