Vroegtijdige softwaretests bevestigen het ontwerp
"Test vroeg en vaak" is een strategie uit de agile softwareontwikkeling die is uitgegroeid tot een vereiste voor softwareontwikkelaars in alle vakgebieden. Vroegtijdige softwaretests zijn vooral belangrijk voor ontwikkelaars die werken aan applicaties voor verschillende platforms, omdat zij mobiele apparaten met uiteenlopende fysieke eigenschappen en besturingssysteemfunctionaliteiten moeten ondersteunen.
MobileTogether omvat functies waarmee vroegtijdige softwaretests in het ontwikkelingsproces kunnen worden geïntegreerd, zonder tijdrovende compilatie-, implementatie- en debugfasen voor elk mobiel platform. De Altova-website beschrijft de functie [automated-testing-for-mobile-apps|MobileTogether Simulator voor vroegtijdige softwaretests, en we hebben op onze blog geschreven over de mogelijkheid om specifieke sets van acties op te nemen en opnieuw uit te voeren in [testgevallen]].
Deze post beschrijft de functie "Trial Run" (proefdraai) die is geïntegreerd in de MobileTogether Designer. Deze functie stelt ontwikkelaars in staat om direct app-ontwerpen te bekijken en de logica en functionaliteit te valideren op elk ondersteund mobiel apparaat of platform, zoals Android, iOS, Windows Desktop of Windows Phone.
Een proefversie voor de klant is vooral nuttig voor de vroege testfase van apps die:
- Maak gebruik van mobiele functies die niet beschikbaar zijn in de Designer op het Windows-platform, zoals sms-berichten
- Gebruik acties die zich iets anders gedragen, afhankelijk van het besturingssysteem, zoals "Toon geolocatie", waarbij de standaardkaartapplicatie van de gebruiker wordt geopend
- Het is nodig om de software te testen op een gloednieuw mobiel model, waarbij de schermafmetingen mogelijk niet overeenkomen met die van een testapparaat dat door de ontwerper is gebruikt
Voor een testopstelling heeft de MobileTogether Client zeer beperkte eisen: het mobiele apparaat waarop de test wordt uitgevoerd, moet de MobileTogether Client-app geïnstalleerd hebben, het mobiele apparaat en de MobileTogether Designer-werkstation moeten op hetzelfde netwerk zijn, en het netwerkadres van de Designer-werkstation moet geconfigureerd zijn als een MobileTogether-server op het mobiele apparaat.
Zodra het clientapparaat klaar is, kan de ontwikkelaar een testrun op de client starten via het menu "Designer Project" of via de handige werkbalk:
Laten we eens kijken naar een app die nog in ontwikkeling is en gebruikmaakt van GPS-functionaliteit, waarbij de ontwikkelaar de iPhone 6 Plus heeft gekozen als het apparaat voor de preview.
De eerste mogelijkheid om de app te testen, is om deze uit te voeren in de MobileTogether Simulator, een functie van de MobileTogether Designer die altijd beschikbaar is tijdens de ontwikkeling.
Het hoofdvenster van de simulator toont de app zoals deze eruit zal zien op het geselecteerde preview-apparaat. Ontwikkelaars kunnen het apparaat selecteren om de gebruikersinterface te bekijken zoals deze eruit zal zien op verschillende iOS-, Android-, Windows- en andere apparaten, of zelfs direct schakelen tussen portret- en landscape-weergave.
De simulator houdt ook de wijzigingen bij die plaatsvinden in de datastructuur van de pagina's terwijl de app wordt uitgevoerd. Het venster "Berichten" in de ontwerper toont een gedetailleerd, stapsgewijs overzicht van de activiteiten tijdens de uitvoering, inclusief berichten tussen de client-app en de server. Alle besturingselementen die interactie met de gebruiker vereisen, zijn tijdens de simulatie actief.
Hieronder ziet u een weergave van de app die draait in de simulator:
Er treden direct twee problemen op: de simulator geeft geen accurate GPS-coördinaten weer. In plaats daarvan gebruikt hij een databestand om de beweging van het mobiele apparaat en de bijbehorende GPS-coördinaten te simuleren. Bovendien opent de knop "Kaartweergave" in de app Bing Maps op de Windows-werkstation waarop de Designer draait, terwijl deze in werkelijkheid Apple Maps zou moeten openen, aangezien dit de standaardkaartapplicatie is op een echte iPhone.
We kunnen de functie "Test uitvoeren op apparaat" gebruiken om de app op een echt mobiel apparaat te draaien, zodat we de GPS-functionaliteit daadwerkelijk kunnen testen en de knop "Kaartweergave" kunnen valideren. Voor de eerste test gebruiken we een Android-telefoon. Door op de knop "Test uitvoeren op apparaat" te klikken, wordt een nieuw venster geopend binnen de ontwerper:
Op dit moment fungeert de Designer-applicatie ook als een MobileTogether-server. Het interne berichtvenster wordt geopend wanneer het clientapparaat de app start.
De ontwikkelaar klikt op "Ja" in het ontwerpdialogvenster om verder te gaan, en de app wordt op het apparaat van de gebruiker gestart. Direct zien we een onverwacht probleem. De standaardtekstgrootte is extreem klein:
We zouden simpelweg op de knop "Abc+" kunnen klikken om de tekstgrootte te vergroten en gebruikers verplichten hetzelfde te doen, maar dat zou een onhandige en niet erg gebruiksvriendelijke oplossing zijn. Door verder onderzoek te doen, kunnen we het venster "Voorbeeld uitvoeren op client" in de ontwerper gebruiken om de datastructuur van de applicatie te bekijken terwijl deze draait:
Het element "textSize" in de permanente datastructuur bevat een waarde die de lettergrootte instelt voor tekstlabels en knoppen, uitgedrukt in absolute pixels. De vaste waarde van 20 is gekozen als standaardinstelling en zag er tijdens het ontwerp acceptabel uit voor de iPhone 6 Plus, maar het werkt niet voor het huidige apparaat.
We kunnen eenvoudig de standaardtekstgrootte wijzigen, van een vaste waarde naar een functie die gebaseerd is op de pixelafmetingen voor elk uniek apparaat van een klant. Vervolgens kunnen we direct een nieuwe test uitvoeren.
MobileTogether biedt globale variabelen die ontwikkelaars toegang geven tot verschillende kenmerken van elk gebruiksapparaat terwijl de app draait. Het venster "Globale variabelen" in de ontwerper toont de waarden voor het geselecteerde preview-apparaat. Hieronder een screenshot van de waarden voor de iPhone 6 Plus:
In plaats van een standaardwaarde van 20 pixels toe te passen voor het element "textSize", kunnen we een functie maken op basis van de globale variabele "MT_DeviceHeight". Twintig gedeeld door 736 is ongeveer 2,7 procent, dus we gebruiken die waarde om een XPath-functie te maken waarmee de initiële "textSize" kan worden ingesteld, afhankelijk van het gebruikte apparaat:
Nu kunnen we een nieuwe test uitvoeren op de applicatie met een Android-telefoon om het resultaat te controleren.
Het bovenstaande voorbeeld van de "proefopname" toont de nieuwe, berekende standaardwaarde voor de tekstgrootte, en hier is een nieuwe screenshot van de telefoon:
De standaard tekstgrootte, berekend op basis van de hoogte van het scherm, is veel logischer en gebruiksvriendelijker! Bovendien kan de tekstgrootte nog steeds worden aangepast met de knoppen "Abc-" en "Abc+", omdat deze knoppen simpelweg de waarde van de tekstgrootte verlagen of verhogen.
Nu kunnen we terugkeren naar onze oorspronkelijke uitdaging, namelijk het testen van de functionaliteit van de "Kaartweergave"-knop in de app. Hieronder staan screenshots van een pagina in de app en de bijbehorende kaartweergave voor een Android-telefoon:
En hier zijn dezelfde beelden, maar dan op een iPhone:
Alle vier de screenshots hierboven zijn gemaakt tijdens een testfase op de omgeving van de klant. De exacte weergave van de kaarten op elk platform wordt bepaald door de functies en gebruikersinstellingen in de betreffende kaartapplicatie. Zo heeft Google Maps op een Android-telefoon bijvoorbeeld de functie "Street View", terwijl de Maps-applicatie van Apple dit niet heeft.
U kunt alvast vroegtijdig software testen met behulp van "Trial Run on Client", en ook gebruikmaken van alle andere functies van MobileTogether voor het ontwikkelen van elegante apps, door de gratis MobileTogether Designer te downloaden. Deze wordt geleverd met geïntegreerde hulp, tutorials en veel voorbeelden.