Hvilke mobile platforme skal du test på?

Tester du din mobile løsning på de samme platforme, som dine brugere har? Når du tester jeres apps eller andre mobile løsninger, er det altid et spørgsmål, hvilke platforme der skal teste på. Dvs. hvilke kombinationer af enheder og versioner af operativsystemet skal ens testcases køres på?

Hvis du ser på enhederne først, så kan de have mange forskellige egenskaber, der kan påvirke, om der skal testes på dem. Det kan være fingeraftrykslæser, ForceTouch, eller noget helt andet, men den egenskab, der påvirker vores test mest, er skærmstørrelsen. Dvs. du skal have et udvalg af skærmstørrelser, der svarer til de skærmstørrelser, der bliver brugt i produktion. Hvis løsningen allerede er i produktion, kan du få den information fra app-storen, hvis det er en app, eller fra webserveren, hvis det er en webløsning.

Hvis løsningen ikke er i produktion, eller du af andre grunde ikke har adgang til informationen, kan du bruge statistikker, som frigives af forskellige virksomheder. Nogle koster penge, men der findes også gratis løsninger. Et eksempel er StatCounter, hvor du for Danmark kan se, hvilke skærmstørrelser de mest brugte telefoner eller tablets har, og du kan herefter udvælge enheder med de relevante skærmstørrelser.

Når du har information om skærmstørrelserne, så skal du finde ud af, hvilke operativsystemer man skal teste på. Først skal du beslutte, om du overhovedet vil teste på en bestemt platform. Hvis I laver native apps (dvs. en app, der er skrevet specifikt til et operativsystem), så giver det lidt sig selv, men hvis I bruger frameworks, der kan køre på flere platforme, eller har en webløsning, så skal du tage et bevidst valg. Hos StatCounter kan man også se, hvad fordelingen af Android, IOS og Windows Phone-enheder er i fx Danmark, og ud fra det tal kan du så beslutte, hvilke platforme, der skal testes. Fx har Windows Phone kun ca. 2-3% af markedet i Danmark, så mange vælger ikke at teste på den.

For hvert operativsystem du vælger, skal du beslutte, hvilke versioner, der skal testes på. Det er igen noget du kan få fra jeres produktionssystemer, men alternativt er distributionstal for de forskellige platforme frit tilgængelige fra producenterne.

For IOS kan du se dem her
For Android kan du se dem her

Generelt er Apple ret aggressive i forhold til at opdatere folks enheder, så det er normalt nok at teste på de to senest versioner. Mange Android-enheder kan derimod ikke opdateres eller bliver det bare ikke, og derfor er det nødvendigt med 4-5 versioner for at få en passende dækning.

Nu skal du så definere dine platforme ved at kombinere skærmstørrelser og operativsystemversioner. Her kan du vælge at være grundig og teste alle skærmstørrelser på hver operativsystem, eller du kan nøjes med at teste nogle kombinationer. Det bestemmes ud fra den risiko testen forsøger at afdække, eller den tid, der er til rådighed.

Der kan som nævnt være andre egenskaber ved enheder, som du ønsker at teste, hvilket kan påvirke dine valg af enheder. Samtidig er det vigtigt at huske på, hvem ens brugere er, når du bruger statistikker. Fx er der langt flere IOS enheder i de større byer, så hvis dine brugere primært bor i byen, kan du måske ikke helt regne med statistikken, der kigger på hele landet.

Alt i alt får du dog et godt udgangspunkt ved ovenstående metode, og platformene kan herefter raffineres på baggrund af testerfaringer og udviklingen af nye enheder og operativsystemer.

Mobile performance testing

Performancetest er vigtigt for alle typer af software, men for mobile applikationer er det særligt vigtigt! 

De enkelte mobile enheder har ofte meget begrænsede ressourcer og vi bruger dem anderledes end vi bruger mere traditionel software som f.eks. det vi kører på en laptop. Faktisk siger 3 ud af 5 it-ledere i 2014 at deres primære fokus for mobiltest er performance (kilde: World Quality Report 2013-14).

Så hvad skal man tænke over, når man laver perfomancetest af mobile applikationer? Det varierer selvfølgelig fra applikation til applikation, men hvis man adresserer følgende tre punkter i sin test er man i hvert fald godt på vej og langt foran gennemsnittet.

  • Hvem bruger min app?
  • Hvilke typer forbindelser skal testes?
  • Performance på de enkelte enheder?

Hvem bruger min app?

Først er det vigtigt at identificere brugerprofilen for dine brugere og den belastning der skal simuleres under testen. 

  • Er det en native app eller en browserløsning?
  • Hvilke enheder har brugerne og hvilke versioner af operativsystemer er der på dem?
  • Hvis det er en browserløsning, hvilken browser bruges der så mest? – Safari, Chrome, Explorer etc.
  • Hvor er brugerne henne i verden og hvor mange er der hvert sted?
  • Hvor tit kommunikeres der mellem enhederne og serveren – og hvor store mængder data?
  • Er der nogle dele/forretningsprocesser der bruges mere end andre?

Hvilke typer af forbindelser skal testes?

At en bruger er mobil er langt fra det samme som at vedkommende er online hele tiden. Forbindelsen vil f.eks. variere når brugeren flytter sig eller vejret skifter og alt efter om brugeren benytter, 3g, 4g eller wifi vil der være betydelige forskelle i svartider og overførselshastigheder. En god tilgang til testen er først at etablere en baseline, hvor der kun testes med en enkelt bruger/enhed. Her måles både svartider fra serveren men også hvordan brugerinterfacet på enheden opfører sig. Herefter gennemføres en test hvor en realistisk belastning på systemet simuleres og der samtidig testes med fysiske enheder for at se konsekvenserne af den eventuelt reducerede performance. 

Der er således to aspekter der skal simuleres i testen.

  1. En realistisk belastning på serveren. Det er ofte lettest at gøre via cloud-løsninger, da det normalt vil kræve at man har servere placeret på de fysiske lokationer hvor belastningen kommer fra, men for interne applikationer kan virksomhedens eget datacenter nogle gange benyttes.
  2. Forskellige typer af forbindelser på de fysiske enheder. Dette gøres oftest lettere via en proxy der understøtter “throttling”. Dvs. begrænse forbindelsens hastighed. Evt. kan man også tage de fysiske enheder ud i de omgivelser hvor de skal bruges, men det kan her være svært at få konsistente tests.

Performance på de enkelte enheder 

At måle performance af en server når mange enheder forbinder til den er vigtigt, men det er lige så vigtigt at teste om appen (klienten) fungerer tilfredsstillende på de enkelte enheder. Hvis f.eks. batterilevetiden halveres når appen benyttes, vil brugerne hurtigt finde en anden løsning hvis de får muligheden. Det samme gælder for processorbrug, hukommelse, grafikhastighed o. lign.

Den nemmeste og bedste måde at måle dette på er normalt, at indbygge et framework i ens app der kan rapportere enhedens tilstand tilbage til en server med faste intervaller. Husk at benytte informationen fra tidligere om, hvilke enheder og operativsystemversioner brugerne har til at teste de meste relevante kombinationer.

Opsummering

Performancetest af mobile løsninger er ikke bare at teste at serveren kan holde til en masse belastning. Vi skal også huske at teste ude på de enkelte enheder og vi skal huske at simulere vores brugere præcist, både hvad angår lokation såvel som forbindelseskvalitet. Som det altid gælder for performanceproblemer, så kan de være rigtig dyre at rette, hvis man først finder dem lige omkring release. Begynd derfor så tidligt som overhovedet muligt. Hvis der er skrevet noget kode, kan vi også måle på, hvor hurtigt det kører og om det pludseligt bliver langsommere!

Tolv hurtige, som ofte bliver glemt

Der er rigtig mange ting, som skal overvejes, når man tester mobile løsninger. Sikkerhed, funktionalitet og performance skal alt sammen virke efter hensigten på mange forskellige enheder og operativsystemer. Her er 12 test cases, som ofte bliver glemt under testen – også selvom man har en struktureret tilgang.

  • Indgående telefonopkald
  • Indgående SMS
  • GPS (bevægelse, tab af signal)
  • Bevægelse af telefonen (ryst, gang, løb)
  • Installering og afinstallation
  • Tab af internetforbindelse
  • Drejning af enheden
  • Tryk på fysiske knapper (volumen, tilbage, home)
  • Tilslutning og frakobling af oplader
  • Timeout for skærm / lås af skærmen
  • Voice Over
  • Navigation til anden app og tilbage igen

Har du prøvet dem alle på din app?