Veiledning for testing av mobilgrensesnitt (GUI-testing av iOS- og Android-apper)

mobile ui testing tutorial gui testing ios

Guide for mobilapp-UI-testing: Lær hvordan du utfører iOS- og Android-UI-testing

Med det blomstrende markedet for mobiltelefoner har testing av mobilapplikasjoner blitt spennende hver dag.

c og c ++ forskjell

Bare ved å kjøre funksjonstester på en mobilapplikasjon, kan du ikke logge av appen. Det er få andre testtyper som feltprøving, nettverkstesting, UI-testing, batterilevetidstest osv. Som må gjøres.

UI-testing er en av de viktigste testene i testing av mobilapplikasjoner, og det bør ikke tas lett på.

Grafisk brukergrensesnitt skaper stor forskjell i hvor interessant og interaktiv en bruker finner applikasjonen din. Betydningen av en anstendig og attraktiv grafisk brukergrensesnitt kan merkes mer betydelig i et smartenhetsmiljø der skjermstørrelsen er langt mindre sammenlignet med en bærbar eller stasjonær skjerm.

Hva du vil lære:

• Betydning for testing av brukergrensesnitt for mobilapp
• Hvordan bestemme hvor mye UI-testing som kreves?
• Retningslinjer: Hva du skal teste i UI-testing av mobilapp
  • # 1) Skjermoppløsning
  • # 2) Skjermstørrelse
  • # 3) Ulike UI-elementer
  • # 4) Stil: Farge- og temaskjema på enheten
  • # 5) Multi-touch eller Single touch
  • # 6) Langt eller kort trykk
  • # 7) Plassering
• Hvordan teste UI-variasjoner på tvers av forskjellige OS-versjoner?
• Ekte enheter eller emulatorer: Hva skal jeg velge for UI-testing?
  • Fordeler
  • Ulemper
• Manuell eller automatisering UI-testing?
• Testverktøy for brukergrensesnitt for mobilapp
• Sjekkliste for testing av mobilappgrensesnitt
• 5 myter om automatisert mobil UI-testing
  • Myte 1: Hastighet
  • Myte 2: Dekning
  • Myte 3: Kostnad
  • Myte 4: Konsistens
  • Myte 5: Motvilje
• Myten og virkeligheten
• Konklusjon
• Anbefalt lesing

Betydning for testing av brukergrensesnitt for mobilapp

Har du som bruker lyst til å bruke en app som mangler brukerinteraksjon og som gjør det vanskelig å forstå hvordan du bruker den?

Når brukerne bruker en mobilapplikasjon for første gang, er det ikke bare ytelsen som stjeler oppmerksomheten, men også det tiltalende brukergrensesnittet. En brukergrensesnittvennlig applikasjon selger mer sammenlignet med en app som er best utviklet, men med en stygg brukergrensesnitt.

Hvis et program har en perfekt og en fantastisk brukergrensesnitt på den ene enheten, men på den andre enheten, er den helt vridd bare fordi den har en annen størrelse eller et annet operativsystem, så vil det gi et veldig dårlig inntrykk. Den kommersielle suksessen til applikasjonen vil bli sterkt påvirket.

Vil du markedsføre en app der knappen er for liten til å klikke og blokkerer hele settet med funksjonalitet?

Er ikke dette ubehagelige opplevelser for brukerne? På grunn av de ovennevnte tilfellene blir det veldig viktig å teste brukergrensesnittet i en applikasjon. De to viktigste verifiseringene som må gjøres for mobilapplikasjoner er brukervennlighet og utseende på tvers av forskjellige modeller og operativsystemversjoner.

Følgende er et eksempel på hvordan brukergrensesnittet skal være perfekt på tvers av forskjellige skjermstørrelser:

Hvordan bestemme hvor mye UI-testing som kreves?

Følgende diagram viser de forskjellige vertikalene der mobilapper kan kategoriseres:

(bilde kilde )

Fra diagrammet ovenfor kan du se at spillappene tar størstedelen av markedsandelen på rundt 24,43%, og deretter etterfulgt av forretnings- og utdanningsapper.

• Apper utviklet som spillapper trenger grundige tester på alle måter, ettersom brukergrensesnittet er den største bidragsyteren for å oppnå suksess, uansett om det er en Native eller Hybrid-app
• En forretningsapp er kanskje ikke helt avhengig av brukergrensesnittet for suksess, fordi målgruppene i de fleste tilfeller er opplært til å bruke appen. Derfor kan slike apper ha et enkelt brukergrensesnitt.
• Apper utviklet for pedagogiske formål trenger grundig UI-testing.
• Kommersielle apper som shopping, reiser osv. Trenger også fullstendig UI-testing på tvers av enheter og forskjellige OS-versjoner.

Kort sagt, avhengig av formålet med appen, kan dybden på UI-testing avgjøres, men UI-testing bør alltid gjøres på minst 3 forskjellige OS-versjoner.

Retningslinjer: Hva du skal teste i UI-testing av mobilapp

Mens du bruker UI i en mobilapplikasjon, må forskjellige egenskaper bekreftes.

Følgende er noen av egenskapene som bør testes for hver app:

#1) Skjermoppløsning

Følgende er noen av de vanlige skjermoppløsninger som vurderes når du lager testsenger:

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

Alle disse resolusjonene er et must for testing når du har en layout med flere kolonner i appen din.

Derfor må verifisering gjøres fra den minste til den største oppløsningen. Bortsett fra dette, hvis appen din har en lang liste med kort med informasjon, må de også testes på en annen oppløsning for informasjonsinnpakning.

( bildekilde )

# 2) Skjermstørrelse

Det er for mange variasjoner i skjermstørrelser og tilgjengelige oppløsninger. Spesielt i smarte enheter er kontrollstørrelser ikke statiske, de har forhold til tilgjengelig skjermstørrelse.

Mens du tester, må du sørge for at kontrollstørrelsen ser estetisk bra ut og at kontrollen er helt synlig på skjermen uten å bla. Test GUI på forskjellige enheter med forskjellige skjermstørrelser og oppløsninger.

Emulatorer er gode for dette formålet, men ingenting samsvarer med den virkelige enheten. Så sørg for at du tester på minst to eller tre virkelige enheter. Ikke glem å teste på liggende og portrettretning hvis enheten støtter det.

Du må teste applikasjonen under ofte brukte oppløsninger for å sikre at den er brukbar.

Få ting du må forstå her er:

Forskjellen mellom skjermstørrelse og oppløsning: Skjermstørrelsen er lengden på skjermen i inches målt diagonalt eller fra ett hjørne til et annet hjørne av skjermen. Skjermoppløsningen er bredden og høyden, Eksempel 640w × 480h som representerer antall piksler som går over skjermen multiplisert med flere piksler som går ned.

# 3) Ulike UI-elementer

UI-elementene som knapper, overskrifter, ikoner, bilder, markeringsfelt, tekstfelt, avkrysningsruter osv. Er noen av de forskjellige elementene som må verifiseres for utseende og størrelse på skjermen.

Spesielt for tekstfelt, hvis det myke tastaturet dukker opp på trykk i tekstfeltet, bør det testes og verifiseres.

Viktigst er det grundig testing av knappestørrelser er nødvendig fordi jeg husker at i appen vår mens vi testet på Galaxy S-telefonen, fant vi en blokkerer der en knapp hadde blokkert hele appen bare fordi knappen virket for liten til å klikke på.

UI-elementenes posisjon bør også verifiseres mot kravet, dvs. hvis alle skal være midtjustert eller venstrejustert osv.

# 4) Stil: Farge- og temaskjema på enheten

Appens brukergrensesnitt og fargevalg skal være i samsvar med forskjellige farger og temaskjemaer på telefonen. Fargen og temaet på en Samsung-telefon er veldig forskjellig fra Nokia eller MI-telefonen .

Derfor må du bekrefte om appen ser ut konsistent på tvers av slike telefoner.

Søknaden din har et bestemt design. Og stilen på kontrollene skal samsvare med det designet. Du har kanskje sett mange applikasjoner der noen kontroller f.eks. panelene har runde kanter og andre kontroller f.eks. tekstbokser har skarpe kanter.

Selv om denne typen problemer ikke påvirker brukervennligheten eller funksjonaliteten til appen, hjelper fortsatt et konsistent utseende av applikasjonen til å bygge et vennlig forhold mellom applikasjonen og brukeren.

En av de viktigste tingene i stil er skriften på de forskjellige sidene. Skriften bør testes godt for å unngå inkonsekvenser i applikasjonens utseende og følelse.

Mesteparten av tiden fokuserer vi på teksten som er synlig i normale situasjoner og ignorerer teksten som vises i spesifikke situasjoner. Suksess- og sviktmeldinger er et eksempel på en slik type tekst.

En annen faktor som er viktig i stilen er en sammenheng mellom skriftfargen og situasjonen der teksten vises.

For eksempel, Rød farge brukes til feilmeldinger, grønn for suksess, gul for advarsler og blå for hyperkoblinger.

# 5) Multi-touch eller Single touch

Hvis appen din støtter multi-touch-funksjonen som klype for å zoome eller klype for å krympe osv., Må du teste denne funksjonen grundig og lage mange testtilfeller for dette for alle gjeldende skjermer.

# 6) Langt eller kort trykk

Et langt trykk på et ikon viser hurtigmenyen mens et kort trykk utfører den aller første handlingen på menyen. Hvis denne funksjonen er gitt i appen din, må du bekrefte denne funksjonaliteten og alle funksjonene rundt den.

# 7) Plassering

Plassering og posisjon er de to ordene som brukes alternativt, og interessant, de brukes videre til å formidle to forskjellige konsepter som er forklart nedenfor:

1) Noen ganger er det området på skjermen der en kontroll vises.

For eksempel, Header er plassert på topp på siden, Etiketter er Venstrejustert , og tekstbokser er Høyrejustert, osv. Her er 'topp', 'venstre justert' og 'høyre justert' relative posisjoner for kontrollene.

2) Noen ganger er det rekkefølgen på kontrollen blant de andre kontrollene.

For eksempel, mens du får personlig informasjon, er fornavnet fulgte etternavnet. Eller kontrollformatet for å be om en amerikansk adresse skal være i rekkefølge - Postnummer, by, delstat.

For begge disse situasjonene snakker vi om plasseringen av kontrollene.

Mens du tester for plassering og plassering av kontroller, må du sørge for at alt er logisk plassert på skjermen og viser en god estetisk sans.

Det er situasjoner der en eller flere kontroller vises på mer enn en skjerm. I denne situasjonen må du sørge for at de vises på samme sted og i samme relative rekkefølge på alle sidene.

Hvordan teste UI-variasjoner på tvers av forskjellige OS-versjoner?

UI varierer med OS-versjonen, og med lanseringen av en ny versjon forbedres det i UI.

La oss observere brukergrensesnittet til det 3 nyeste operativsystemet som for øyeblikket er tilgjengelig, og forstå hvordan disse variasjonene påvirker en mobilapplikasjon.

De er:

1. Kjærlighet på pinne
2. Marshmallow
3. Nougat

Når du ser på listen over nye brukergrensesnitt eller funksjonalitetsfunksjoner, må du som en kvalitetssikring designe testtilfeller rundt dette.

1) Lollipop:

• Lag testtilfeller for effekten av det nye designet på appen din.
• Ikke nødvendigvis for alle skjermene, men lag testtilfeller for tilgang til de nye snarveiene på appen din.

2) marshmallow:

• Hvis appen din håndterer emoji, kan du opprette testtilfeller for å bekrefte de nye emojiene. Apper som lar brukerne skrive anmeldelser eller chatte, er de som bruker emoji ofte.
• Når appen din blir publisert og installert for første gang, må den kanskje be om tillatelse, og behovet for UI-testing av den nye tillatelsesskjermen må gjøres. Og lag testsaker for det samme.
• Hvis appen din bruker Google Nå, må du opprette testtilfeller for å teste den oppdaterte brukergrensesnittet for Google Nå-funksjonen.

3) Nougat:

• Grundig testing av appen din må gjøres for dagdrømmen-virkelighetsmodusen, og opprett derfor testtilfeller deretter.
• Lag testtilfeller for å verifisere menyalternativene for appen din.
• Hvis appen din håndterer emoji og GIF, kan du opprette testtilfeller for å bekrefte de nye emojiene og muligheten for å sende GIF.

Ekte enheter eller emulatorer: Hva skal jeg velge for UI-testing?

Når du må teste en mobilapplikasjon, kan du tenke på hva testbedet skal være?

Om du skal teste på en ekte enhet eller emulator eller begge deler? Det er ikke noe fast svar på dette fordi valget avhenger av hva du vil teste.

For å teste funksjonalitet, ytelse, nettverksrespons, felttest osv., Bør du alltid foretrekke en ekte enhet. Men for ting som UI, bør du velge emulatorer sammen med noen virkelige enheter.

Fordeler

Fordelene med å bruke emulatorer for UI-testing er:

1) Det er ikke praktisk mulig å samle inn enhetene med alle oppløsninger, og det vil også koste enormt mye penger. Men emulatorer koster ingenting.
2) Med en emulator kan du opprette alle skjermoppløsninger og OS-kombinasjoner.
3) Hvis du bare har ett sett med virkelige enheter, men QA-teamet er på mer enn 1 person, kan ikke alle kvalitetssikringene teste for samme testbed parallelt. Med en emulator kan hver QA lage den samme kombinasjonen på maskinen sin og teste parallelt.
4) Testing på en emulator er mindre tidkrevende og er raskere sammenlignet med en ekte enhet.
5) Vanlige feil relatert til brukergrensesnittet som justering osv. Kan lett fanges opp på emulatorer.

Ulemper

Ulemper inkluderer:

1) Bevegelser kan ikke testes på emulatorer. Bare en gest kan emuleres om gangen.
2) Fysiske innganger av GPS, slippende eller svakt nettverk osv. Kan heller ikke testes.
3) Det er ingen måte at du kan lage en emulator for Sony, LG, Nexus, osv. Telefoner.
4) Det er ikke mulig å skape et reelt miljø med lavt batterinivå eller lite minne osv., På emulatoren.

Derfor bør avgjørelsen tas avhengig av appen din og testkravet.

Manuell eller automatisering UI-testing?

Ingen produkter, enten det er en stasjonær app, en webapp eller en mobilapp, kan slippes uten testing. Som en kvalitetssikring sliter vi med å finne og rapportere alle mangler, men likevel rapporteres de av kunder.

Vet du hvorfor?

Fordi lange tester som ofte unngås eller savnes, og dermed etterlater uoppdagede feil. 100% dekning, utførelse er ikke mulig med manuell testing.

UI-testing er ganske enkel og grei, og du må bare se på hvordan det ser ut for øyet ditt. Nå hvis dette gjøres manuelt, er det veldig tidkrevende. Også de fleste ganger trenger vi å lage enorme data for UI-testing som en rulle bare vises hvis kortradene krysser et bestemt antall.

Å lage store data er veldig tidkrevende. Å ha en automatisert suite kan løse begge problemene.

Tvert imot, hvis funksjonene eller brukergrensesnittet til appen fremdeles er i en skiftende fase, er det ikke fornuftig å investere i automatisering. Tilsvarende, hvis funksjonene til appen er viktige, er det bedre å teste manuelt.

Avhengig av følgende pekere, bør du derfor bestemme om du vil teste manuelt eller automatisere:

• Appens art.
• Stabiliteten til appen din.
• Tilgjengelige ressurser som arbeidskraft for å studere verktøyene og sammenligne dem.
• Hvor mye tid er investert i å studere og starte opp et automatiseringsverktøy som kreves?
• Er klienten klar til å investere tid i oppstart og studier?

Testverktøy for brukergrensesnitt for mobilapp

Følgende er en liste over 5 verktøy som kan brukes til UI-testing av en mobilapplikasjon for Android og / eller iOS.

(For verktøy for testing av funksjonalitet y Du kan referere til listen over automatiseringsverktøy i vår automatisering verktøy for testing av Android-applikasjoner side).

# 1) Selendroid

Selendroid er et av de beste og mest anbefalte verktøyene for automatisering av mobilapplikasjoner for UI-testing.

Den kan brukes til både Native og Hybrid-apper. Den kan bare brukes til Android-apper, og klient-API-testene skrives med Selendroid 2. Den kan også brukes med mer enn én enhet og er fullt kompatibel med JSON.

# 2) Testdroid

Dette er et skybasert verktøy og kan brukes til en rekke enheter, forskjellige skjermoppløsninger og OS-versjoner av både Android og iOS. Parallell testing av enheter er en stor fordel med dette verktøyet og er et godt verktøy for UI-testing. Det hjelper utviklerne med å forbedre time-to-market.

# 3) SeTest

Det er et betalt verktøy og kan brukes til Android, iOS, Windows, Symbian, etc.

Det er et plattformverktøy, og derfor er fordelen at den samme testen kan kjøres på alle plattformer. Den kan brukes til alle mobile applikasjoner, og testene kan kjøres parallelt på mer enn én enhet.

# 4) UI-automatisering

Dette er det offisielle UI-testverktøyet for Apple og er det beste verktøyet for automatisering av iOS-applikasjoner. Selv om det er vanskelig å lære, gir det en stor fordel med biblioteker, ytelse, UI-testing osv.

# 5) Calabash

Den kan brukes til både Android- og iOS-testing for native- eller hybridapper. Det er et plattformverktøy, og det brukes best til å automatisere bevegelser, skjermbilder, påstander osv. Det kan brukes på ekte berøringsskjermenheter. Det har også støtte for agurk.

unix-kommando for å sammenligne to filer og vise forskjellene

Når utviklere enhetstester appen, kan de også gjøre UI-testing ved hjelp av Android Studio, men den kan bare brukes til Android-applikasjoner.

Anbefalt lesing => Automatiser tester av brukergrensesnitt

Sjekkliste for testing av mobilappgrensesnitt

Nedenfor er sjekklisten for testere for å sikre at GUI testes helt bra på smarte enheter:

5 myter om automatisert mobil UI-testing

Automated Mobile UI Testing anses som mye avgjørende når spørsmålet om applikasjonssuksess oppstår. Men det er noen myter knyttet til automatisert testing.

Slike myter er kanskje ikke sanne fordi de kan være overfladiske. Å dykke dypt inn i prosessen med automatisert testing får den til å forsvinne. La oss grave dypere inn i dem.

Myte 1: Hastighet

Denne myten er veldig vanlig. De fleste mennesker relatert til IT-bransjer har en myte om at det å utføre 'automatiseringstesting' tar mer tid sammenlignet med 'manuell testing'. Dette faktum stemmer til en viss grad i noen få scenarier.

Årsaken er at manuell testing gir raske resultater sammenlignet med Automated Mobile UI Testing. Men dette er tilfelle bare i innledende og innledende faser.

Med gjentatt type testing, trenger du enten tillegg av mange flere funksjoner ved testing eller avtagende testkvaliteter. Mens du med automatisert testing alltid kjører lignende testnivåer hver gang, og dermed sparer du tid i det lange løp.

Myte 2: Dekning

I dagens scenario lanseres nye Android-enheter regelmessig i markeder. Og antall apper til slike operativsystemer (OS) øker. Så er det operativsystemer som iOS som har enda flere apper laget for daglig bruk.

Manuell testing for så mange apper blir veldig vanskelig. Men i tilfeller av automatisert testing skal det være tilstrekkelig med vedlikehold av skyservere. Ved hjelp av automatisert testing er total og fullstendig testdekning av appene mulig.

Myte 3: Kostnad

Det er et faktum at automatisk testing av appene koster mer enn kostnadene ved manuell testing. Dette gjelder imidlertid bare hvis det blir gjort tester for appens viktigste. Etter hvert som appens miljø og programvaren blir komplisert, blir manuell testing dyrere.

Dette er fordi det trengs mer sofistikerte verktøy for å oppnå optimale testresultater. Sammen med de sofistikerte testverktøyene, er det behov for høyt utdannet personale som kan håndtere slike verktøy. Dette skal kreve opplæring av dem.

Så manuell testing blir dyrere sammenlignet med en automatisert.

Myte 4: Konsistens

Når det gjelder manuell testing, er det alltid rom for forskjellige oppfatninger som varierer fra en tester til en annen. Dette avhenger også av tester som vurderes, miljøer og apper sammen med operativsystem (OS).

Når du bruker manuell testing på programvaren, er det hull som få feil kan passere gjennom. Manuell testing er derfor bare bra for å oppdage grunnleggende feil. Automatisert testing kjører på skriptene uten rom for varierende oppfatning, noe som gjør det idiotsikkert.

Myte 5: Motvilje

Det er ikke sant at automatisert testing har erstattet mennesker, men det er for manuell testers forbedring. Automatiserte tester gir automatiserte resultater gjentatte ganger, flere ganger med maksimal nøyaktighet. Så det oppstår spørsmål, hvorfor er det behov for mennesker?

Automatisert testing trenger manusforfatter og planlegging av hele testprosedyren. Denne oppgaven krever menneskelig innsats. Fremgangsmåten for automatisert testing hjelper deg med å spare tid og penger slik at du bruker slike ressurser til forbedring av prosedyrer for manuell testing. Utviklingen av bedre verktøy vil i sin tur hjelpe til med å fremme allerede eksisterende prosedyrer for automatisert testing.

Ovennevnte er få av de mest populære mytene som råder i bransjen for automatisert testing. Dette må utryddes for å forbedre Automated Mobile UI Testing.

Myten og virkeligheten

Faktum er at selv de mest sofistikerte utviklingsselskapene bruker manuell testing for mobiltelefoner, eller ikke utfører komplette tester i det hele tatt. I henhold til Xamarin 2014-undersøkelser utfører 13,2% av mobilutviklere tester som automatiserte brukergrensesnitt. I henhold til studier av Forrester Research utfører bare 53% av utviklerne kortvarige tester på enkeltenheter.

Fem mest vanlige faktorer for hvorfor team av mobiler ikke har automatiserte kvaliteter av mobilapper, og fem grunner til hvorfor disse ikke bare gir mening, er som følger:

den beste programvaren for å rengjøre datamaskinen

a) Hastighet er den første myten.

En person kan ikke ta seg tid til automatisering. I 2014 hadde leverandørene introdusert 7000 nye Android-enhetstyper. Så var det 10000 API-er som har vært spesifikke for mobiltelefoner. Bruken av mobiltelefoner sendes raskere og endres raskt. Med kvalitetssikring (QA) i konstant knusende modus, er det ikke tid for å lage testskripter, som igjen holder dem synkroniserte med funksjoner som endres regelmessig.

Det praktiske scenariet til den første myten:

For tiden kaster man bort dyrebar tid. Det er veldig sant. Å teste manuelt er raskere enn å teste automatiseringsmessig. Men dette er for den aller første testkjøringen. Ved påfølgende løp, uansett marginale fordeler, fører manuell testing frem til erosjoner. Dette er nesten umiddelbart. Sammen med alle gjentatte testkjøringer eller funksjonstillegg, bør apputviklere enten redusere testomfanget eller ekstra testressurser.

Sammen med begrenset budsjettering, fører dette til slutt til de onde syklusene til de egenskapene som avtar. Som svar på dataoppdrag og negative anmeldelser fra brukere fra enheter som ikke er testet, ønsker team en utvidelse av enhetens dekning. Dette øker stresset på QA-avdelinger som kapasitet ytterligere.

Det er at virksomheten sliter med å vedlikeholde, undersøke og anskaffe enheter mens de gjør testutførelser. Selv best finansierte UI-manuelle testprogrammer blir forkortet mot fullført dekning.

I USA krever mobilteam testing på 188 enheter for å dekke 100 prosent av markedsføringsandeler. I henhold til Xamarin-undersøkelsen i 2014 tester flertallet av utviklingsteamene ofte på 25 eller færre enheter.

Mer enn en fjerdedel av disse utviklermiljøene retter seg mot fem eller færre enheter. I virkelige situasjoner med testing, lønner seg automatisering seg øyeblikkelig og umiddelbart. På den aller første testkjøringen er det vitne til at forbrukerne akselererer testtidslinjene fire ganger. Det er over hele manuell testing når du kjører mot femti eller enheter mer enn det.

Løp som er i påfølgende har gått mye raskere. Likevel er forkortelse der for en nesten full testuke til bare bruk på få timer.

b) Dekning er den andre myten.

Fragmentering er årsaken til ingen mulighet for å få utvidet enhetsdekning. Sammen med mer enn 19000 enheter med unike Android og permutasjon av dusinvis for å danne operativsystemer og faktorer for iOS, tror mange lag at det ikke er mulig å dekke flertallet av enheter i de angitte markedene.

Så det er en standard testing på en håndfull av disse enhetene som bra nok.

Virkeligheten til den andre myten:

Man kunne ha fullført enhetens dekning. I tilfelle folk vedlikeholder enheter internt i håndfuller, gjør de mye. Anskaffelse av enheter er vanskelig.

Ved å opprettholde pengene, kostnadene og tiden deres, blir det testere tilgjengelige der og når behovet føltes, skaper logistikk. Det hadde blitt uttalt av Gartner at mobilutviklere burde finne måter for å oppnå høye automatiseringshastigheter for å holde tritt med plattformens tempo og spredning av endring. Dette hadde vært i hosting. Ulike funksjoner brukte intern styring.

Veien til slik automatisering går gjennom skytjenester fra tredjeparter. Tredjeparts skytjenester hjelper til med automatisering av app-lasteprosesser, utførelse av testskript, rapportering av resultater og omstilling av enhetssikkerhet for standarder for fabrikker på en sikker måte. Delsett av tester av apper kjøres parallelt, og dermed påskynder resultatene.

Mens du tester på et bredt utvalg av ekte enheter, tillater testskyene at alle på team vet nøyaktig hvordan app fungerer, og eliminerer typisk gjetning av mobilutviklingen.

Eksempel: Produktadministratorer setter færre systemkrav sammen med fortrolighet som er berettiget i ytelsen til enheter. Utviklere mottar visuelle objektive bekreftelser av å fikse feil før forpliktelsen til nyere bygg. Dette er uavhengig av hvor og når de opererer.

c) Kostnad er den tredje myten.

Enkeltpersoner har bare råd til manuell testing. Automatiseringstesting trenger oppretting av testskripter, læringskurver for QA-ansatte og infrastruktur. Mange lag har allerede slitt med å nå frister. De er over budsjettet allerede. Så automatiseringstesting ser ut til å være langt unna.

Det praktiske scenariet for den tredje myten:

Manuell testing sparer bare penger i tilfelle folk ofrer dekning. Å teste manuelt virker billigere bare i de fleste miljøer med bare bein.

I tilfelle testing inkluderer rask 'tarmkontroll' av grunnleggende funksjoner på færre enheter, virker manuell testing som gode kjøp. Men alle likheter med testdekning og enhet som er omfattende, skal gjøre testing manuelt mye dyrere enn automatiseringstesting. Dette kan være raskt til og med.

Manuell testing skalerer bare ved tilsetning av flere mennesker og masser. Kostnadene har ingen sann linearitet. Å skalere opp personalet for å møte kravene gir enorme omkostninger i form av koordinering og opplæring. Deling av testsaker reduserer dermed effektiviteten til alle testere ved å utføre fjerning av perspektiver.

I tillegg kan testere som har nok sofistikering til å grave utover brukeratferd og derved utforske og forutse årsaker til hvorfor applikasjoner kan mislykkes, verken være rikelig eller billig. Automatiseringstesting krever alltid noe mer overhead på tidspunktet for første oppsett.

Men som nevnt ovenfor, kan det gi gevinster og fortjeneste dramatisk i testhastigheter. Det gir også tilsvarende personalreduksjon innen et par dager. Skibaserte testmiljøer har redusert kostnadene ytterligere. Dette er ved å eliminere underutnyttet og kostbar testinfrastruktur.

d) Konsistens skal være den fjerde myten.

God nok må gjennomføres, henrettes og drives. For forskjellige testteam er klare distribusjoner subjektive beslutninger som bygger på oppfatningen av mange forskjellige manuelle testere. De har en kunnskap om at betydningen er at bugs faller gjennom sprekker.

Overlappende testdekning må fange de vanligste og mest kritiske problemene før utgivelser. Resten av feilene venter på vedlikeholdsutgivelser.

Det virkelige scenariet for den fjerde myten:

Kvaliteter er ikke kvalitative. Produksjonens beredskap må ikke være faktorer og meningsspørsmål. I et rent manuelt testmiljø varierer oppfatningene fra en test til en annen test og en tester til en annen tester. Dette fører til uberegnelige resultater av tester og konsistente dokumentasjoner.

Beslutninger blir kompliserte når det er hensyn til produktets beredskap. Det fører til svikt i samsvar, massevis avhugg og tapte inntekter. I tillegg er det oppretting av lommer med stammeløs fanget forståelse som går tapt når mennesker og ansatte går ut av døren.

Automatisering skaper igjen kvantifiserbare beregninger. Dette fungerer som sannhetens objektive kilder for å informere avgjørelser angående begrunnelsen av forretningsbeslutningen, produktets beredskap og utviklingen av diagramteam.

e) Motvilje er den femte myten.

Manuell testing er erstattet av automatiseringstesting. Mange forskjellige utviklere har adgang til testautomatisering fordi de forventer å erstatte testere som er manuelle med maskiner.

I tilfelle automatisering av tester gjentar lignende tester 1000 ganger med 100 prosent nøyaktighet, oppstår det spørsmål om hvorfor det er behov for mennesker til testformål. Automatisering av testskript kan også gjøres av maskiner.

Sanntidsbildet av den femte myten:

Manuelle testere blir bedre med automatiseringstesting. Maskiner og mennesker har gode scenarier for mange forskjellige ting og faktorer. Testere, som alltid gjør manuell testing, kan teste mer kreativt.

Automatiseringstesting frigjør dem fra å gjøre dette. Mens mennesker ser frem til nyere måter å bryte apper på, sørger automatisering for samsvar i det store spekteret av enheter. Dette er fra enhetstester til fullstendige regresjonstester. To tilnærminger trenger ikke fungere isolert.

Å utføre tester som utforskende manuelt mens back-ended systemer ikke har vært under belastning fra automatisert testing. Dette er gode måter å oppdage feil som dukker opp i produksjonsmiljøer. Automatiseringstesting erstatter ikke testere som er mennesker. Dette lar dem utføre givende og interessant arbeid.

Bedre konsistens, dekning, pris og hastighet legger opp til de kvalitetene som forbedres. Å spare penger og tid betyr at man kan gjøre mer testing og ikke mindre. Dette er tilfelle når man når milepæler for å være kritisk. Dette gjør at testing kan holde tritt sammen med team av smidige utviklinger i stedet for å stå på måter.

Så organisasjoner slipper kode mye oftere. Dette reduserer støt og mengder av mangler blir gitt. Dette betyr at utviklere jobber med rene koder. Fikseringen av feil har vært mindre komplisert dramatisk. Dette frigjør testere gjennom å fungere alene da portvoktere fokuserer på kreativitet. Undersøkende testing forbedrer dermed kvaliteten til produkter.

Automatiseringstesting av mobile brukergrensesnitt gir fordeler med tider og kvaliteter. Verktøy som er automatisert, gjør det enkelt for testere å vurdere brukergrensesnitt for apper gjennom utvidede områder av mobile enheter, sammen med å gjøre endringer for å enkelt øke brukeropplevelsene.

Konklusjon

En dårlig GUI er en ubehagelig opplevelse for brukeren. GUI-testing er sterkt anbefalt og viktig, spesielt når det gjelder smarte enheter, fordi skjermstørrelsen er relativt liten og mange varianter av enhetene er tilgjengelige i markedet.

Søknaden din kan se ut og oppføre seg annerledes på forskjellige enheter. Så det er viktig å teste appen på i det minste noen standardstørrelser og varianter av enheter.

Alle mobilapplikasjonene trenger UI-testing, men dybden av testene som kreves, er definert av kategorien eller formålet med applikasjonen. Du bør gjøre en fullstendig analyse av programmets brukergrensesnittfunksjoner mot telefonens modell- eller operativsystemversjoner før du fullfører testbedet.

Basert på denne analysen, bør du lage testsaker for testing. Bruk automatisering der det er mulig for å spare tid.

Hold øye med mens du tester brukergrensesnittet fordi det er enkelt, men det har stor innvirkning på salget av appen din.

Ta en titt på vår kommende opplæring for detaljert informasjon om Mobil responsiv test .

Anbefalt lesing

• Appium-veiledning for testing av Android- og iOS-mobilapper
• TOPP 15 Beste mobile testverktøy i 2021 for Android og iOS
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Mobile App Beta Testing Services (iOS og Android Beta Testing Tools)
• Hvorfor mobil testing er vanskelig?
• Komme i gang med Robotium - Det mest populære testprogrammet for brukergrensesnitt for Android-applikasjoner
• Testing Primer eBook Download
• 11 beste automatiseringsverktøy for testing av Android-applikasjoner (Android-app-testverktøy)