Výukový program pro testování mobilního uživatelského rozhraní (testování grafického uživatelského rozhraní pro aplikace pro iOS a Android)

mobile ui testing tutorial gui testing ios

Průvodce testováním uživatelského rozhraní mobilních aplikací: Naučte se provádět testy uživatelského rozhraní iOS a Android

S vzkvétajícím trhem pro mobilní telefony se testování mobilních aplikací stalo každým dnem vzrušujícím.

otestovat můj web v různých prohlížečích

Pouhým spuštěním funkčních testů v mobilní aplikaci nemůžete aplikaci odhlásit. Existuje několik dalších typů testování, jako je testování v terénu, testování sítě, testování uživatelského rozhraní, testování životnosti baterie atd., Které je třeba provést.

Testování uživatelského rozhraní je jedním z důležitých testů při testování mobilních aplikací a nemělo by se brát na lehkou váhu.

Grafické uživatelské rozhraní vytváří mnoho rozdílů v tom, jak zajímavé a interaktivní uživatel najde vaši aplikaci. Důležitost slušného a atraktivního grafického uživatelského rozhraní lze výrazněji pocítit v prostředí inteligentních zařízení, kde je velikost obrazovky mnohem menší ve srovnání s obrazovkou notebooku nebo stolního počítače.

Co se naučíte:

• Důležitost testování uživatelského rozhraní mobilní aplikace
• Jak se rozhodnout, kolik je vyžadováno testování uživatelského rozhraní?
• Pokyny: Co testovat při testování uživatelského rozhraní mobilních aplikací
  • # 1) Rozlišení obrazovky
  • # 2) Velikost obrazovky
  • # 3) Různé prvky uživatelského rozhraní
  • # 4) Styl: Barevné a motivové schéma zařízení
  • # 5) Multi-touch nebo Single touch
  • # 6) Dlouhé nebo krátké stisknutí
  • # 7) Umístění
• Jak testovat varianty uživatelského rozhraní v různých verzích OS?
• Skutečná zařízení nebo emulátory: Co si vybrat pro testování uživatelského rozhraní?
  • Profesionálové
  • Nevýhody
• Ruční nebo automatizované testování uživatelského rozhraní?
• Nástroje pro testování uživatelského rozhraní mobilních aplikací
• Kontrolní seznam pro testování uživatelského rozhraní mobilní aplikace
• 5 mýtů o automatickém testování mobilního uživatelského rozhraní
  • Mýtus 1: Rychlost
  • Mýtus 2: Pokrytí
  • Mýtus 3: Náklady
  • Mýtus 4: Konzistence
  • Mýtus 5: Neochota
• Mýtus a realita
• Závěr
• Doporučené čtení

Důležitost testování uživatelského rozhraní mobilní aplikace

Jako uživatel budete mít chuť používat aplikaci, která postrádá interakci uživatele a ztěžuje pochopení, jak ji používat?

Když uživatelé používají mobilní aplikaci poprvé, pozornost si neukradne jen výkon, ale také atraktivní uživatelské rozhraní. Aplikace přátelská k uživatelskému rozhraní prodává více ve srovnání s aplikací, která je nejlépe vyvinutá, ale má ošklivé uživatelské rozhraní.

Pokud má aplikace na jednom zařízení dokonalé a skvělé uživatelské rozhraní, ale na druhém zařízení je zcela zkroucené jen proto, že má jinou velikost nebo jiný operační systém, zanechá velmi špatný dojem. Obchodní úspěch aplikace bude negativně ovlivněn.

Propagujete aplikaci, kde je tlačítko příliš malé na to, aby blokovalo celou sadu funkcí?

Nejsou pro uživatele tyto nepříjemné zážitky? Vzhledem k výše uvedeným případům se stává velmi důležité otestovat uživatelské rozhraní aplikace. Dvěma hlavními verzemi, které je třeba provést pro mobilní aplikace, jsou uživatelská přívětivost a vzhled napříč různými modely a verzemi OS.

Následuje příklad toho, jak by mělo být uživatelské rozhraní dokonalé v různých velikostech obrazovky:

Jak se rozhodnout, kolik je vyžadováno testování uživatelského rozhraní?

Následující graf označuje různé vertikály, ve kterých lze mobilní aplikace kategorizovat:

(obraz zdroj )

Z výše uvedeného grafu můžete zjistit, že herní aplikace zaujímají většinu tržního podílu přibližně 24,43% a poté následují obchodní a vzdělávací aplikace.

• Aplikace vyvinuté jako herní aplikace vyžadují důkladné testování po všech stránkách, protože uživatelské rozhraní je největším přispěvatelem k získání úspěchu bez ohledu na to, zda se jedná o nativní nebo hybridní aplikaci
• Obchodní aplikace se kvůli svému úspěchu nemusí zcela spoléhat na uživatelské rozhraní, protože ve většině případů jsou cílové skupiny trénovány k používání aplikace. Tyto aplikace proto mohou mít jednoduché uživatelské rozhraní.
• Aplikace vyvinuté pro vzdělávací účely vyžadují důkladné testování uživatelského rozhraní.
• Komerční aplikace, jako je nakupování, cestování atd., Také vyžadují kompletní testování uživatelského rozhraní napříč zařízeními a různými verzemi OS.

Stručně řečeno, v závislosti na účelu aplikace lze rozhodnout o hloubce testování uživatelského rozhraní, ale testování uživatelského rozhraní by mělo být vždy prováděno alespoň na 3 různých verzích operačního systému.

Pokyny: Co testovat při testování uživatelského rozhraní mobilních aplikací

Při testování uživatelského rozhraní v mobilní aplikaci je třeba ověřit různé vlastnosti.

Následuje několik charakteristik, které by měly být testovány pro každou aplikaci:

# 1) Rozlišení obrazovky

Následuje několik běžných rozlišení obrazovky, která se berou v úvahu při vytváření testovacích postelí:

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

Všechna tato rozlišení jsou nutností pro testování, pokud máte v aplikaci rozložení s více sloupci.

Proto je třeba ověřovat počínaje od nejmenšího po největší rozlišení. Kromě toho, pokud má vaše aplikace dlouhý seznam karet s informacemi, je třeba je také testovat na jiném rozlišení pro jejich zabalení informací.

( zdroj obrázku )

# 2) Velikost obrazovky

Existuje příliš mnoho variací velikostí obrazovky a dostupných rozlišení. Obzvláště v chytrých zařízeních nejsou velikosti ovládacích prvků statické, mají vztah k dostupné velikosti obrazovky.

Během testování se ujistěte, že velikost ovládacích prvků vypadá esteticky dobře a ovládací prvky jsou zcela viditelné na obrazovce bez jakéhokoli posouvání. Vyzkoušejte grafické uživatelské rozhraní na různých zařízeních s různými velikostmi a rozlišeními obrazovky.

Emulátory jsou pro tento účel dobré, ale nic neodpovídá skutečnému zařízení. Nezapomeňte tedy testovat alespoň na dvou nebo třech reálných zařízeních. Nezapomeňte také otestovat orientaci na šířku a na výšku, pokud to zařízení podporuje.

Aplikaci musíte otestovat v běžně používaných rozlišeních, abyste zajistili její použitelnost.

Tady musíte pochopit jen málo věcí:

Rozdíl mezi velikostí obrazovky a rozlišením: Velikost obrazovky je délka obrazovky v palcích měřená úhlopříčně nebo od jednoho rohu k druhému rohu obrazovky. Rozlišení obrazovky je šířka a výška, Příklad 640w × 480h, což představuje počet pixelů procházejících obrazovkou vynásobený několika pixely klesajícími.

# 3) Různé prvky uživatelského rozhraní

Prvky uživatelského rozhraní, jako jsou tlačítka, nadpisy, ikony, obrázky, výběrová pole, textová pole, zaškrtávací políčka atd., Jsou některé z různých prvků, které je třeba ověřit z hlediska jejich vzhledu a velikosti na obrazovce.

Zejména u textových polí, pokud se softwarová klávesnice zobrazí po klepnutí v textovém poli, je třeba otestovat a ověřit.

Nejdůležitější je důkladné testování velikostí tlačítek, protože si pamatuji, že v naší aplikaci při testování na telefonu Galaxy S jsme našli blokátor, kde tlačítko zablokovalo celou aplikaci jen proto, že tlačítko vypadalo příliš malé na to, aby na něj bylo možné kliknout.

Poloha prvků uživatelského rozhraní by měla být také ověřena podle požadavku, tj. Pokud mají být všechny zarovnány na střed nebo doleva atd.

# 4) Styl: Barevné a motivové schéma zařízení

Uživatelské rozhraní aplikace a barevné schéma by měly být v souladu s různými barvami a schématy motivů telefonu. Barva a téma telefonu Samsung se velmi liší od barev a motivů telefonů Nokia nebo MI .

Proto musíte ověřit, zda aplikace vypadá konzistentně napříč takovými telefony.

Vaše aplikace má specifický design. A styl ovládacích prvků by měl odpovídat tomuto designu. Možná jste viděli mnoho aplikací, kde některé ovládací prvky, např. panely mají zaoblené hrany a další ovládací prvky, např. textová pole mají ostré hrany.

Ačkoli tyto typy problémů neovlivňují použitelnost nebo funkčnost aplikace, stále konzistentní vzhled aplikace pomáhá budovat přátelský vztah mezi aplikací a uživatelem.

Jednou z nejdůležitějších věcí ve velkém stylu je písmo různých stránek. Písmo by mělo být dobře otestováno, aby nedocházelo k nesrovnalostem ve vzhledu a chování aplikace.

Většinu času se zaměřujeme na text, který je viditelný v normálních situacích, a ignorujeme text, který se objevuje v konkrétních situacích. Příkladem takového typu textu jsou zprávy o úspěchu a neúspěchu.

Dalším důležitým faktorem ve stylu je vztah mezi barvou písma a situací, ve které je text zobrazen.

Například, Červená barva se používá pro chybové zprávy, zelená pro úspěch, žlutá pro varování a modrá pro hypertextové odkazy.

# 5) Multi-touch nebo Single touch

Pokud vaše aplikace podporuje vícedotykovou funkci, jako je přiblížení nebo zmenšení zmenšení atd., Musíte tuto funkci důkladně otestovat a vytvořit pro všechny příslušné obrazovky mnoho testovacích případů.

# 6) Dlouhé nebo krátké stisknutí

Dlouhé stisknutí ikony zobrazí kontextovou nabídku, zatímco krátký dotyk provede první akci nabídky. Pokud je tato funkce poskytována ve vaší aplikaci, musíte tuto funkci a všechny funkce kolem ní ověřit.

# 7) Umístění

Místo a poloha jsou dvě slova, která se používají alternativně, a je zajímavé, že se dále používají k vyjádření dvou různých konceptů, které jsou vysvětleny níže:

1) Někdy je to oblast na obrazovce, kde se objeví ovládací prvek.

Například, Záhlaví je umístěno na horní stránky, Štítky jsou Vlevo zarovnáno a Textová pole jsou Správně zarovnáno, atd. Zde jsou „nahoře“, „vlevo zarovnáno“ a „vpravo zarovnáno“ relativní polohy ovládacích prvků.

dva) Někdy je to pořadí kontroly mezi ostatními ovládacími prvky.

Například, při získávání osobních údajů je křestní jméno následoval příjmením. Nebo by měl být formát ovládacích prvků požadujících adresu USA objednat - PSČ, město, stát.

U obou těchto situací mluvíme o umístění ovládacích prvků.

Při testování umístění a polohy ovládacích prvků se ujistěte, že je vše logicky umístěno na obrazovku a vykazuje dobrý estetický smysl.

Existují situace, kdy se jeden nebo více ovládacích prvků objeví na více než jedné obrazovce. V této situaci musíte zajistit, aby se na všech stránkách zobrazovaly na stejném místě a ve stejném relativním pořadí.

Jak testovat varianty uživatelského rozhraní v různých verzích OS?

Uživatelské rozhraní se liší podle verze operačního systému a se spuštěním nové verze se v uživatelském rozhraní provádí vylepšení.

Pojďme sledovat uživatelské rozhraní 3 nejnovějších OS, které jsou aktuálně k dispozici, a pochopit, jak tyto varianty ovlivňují mobilní aplikaci.

Oni jsou:

1. Lízátko
2. Ibišek
3. Nugát

Při pohledu na výše uvedený seznam nových uživatelských rozhraní nebo funkčních funkcí je jako QA potřeba navrhnout kolem toho testovací případy.

1) Lízátko:

• Vytvořte testovací případy pro účinek nového designu na vaši aplikaci.
• Ne nutně pro všechny obrazovky, ale vytvářejte testovací případy pro přístup k novým zkratkám ve vaší aplikaci.

2) Marshmallow:

• Pokud se vaše aplikace zabývá emodži, vytvořte testovací případy a ověřte nové emodži. Emodži často používají aplikace, které uživatelům umožňují psát recenze nebo chatovat.
• Když je vaše aplikace publikována a nainstalována poprvé, bude možná nutné požádat o povolení, takže je třeba provést testování UI nové obrazovky oprávnění. A vytvořit testovací případy pro stejné.
• Pokud vaše aplikace používá Chytré karty Google, musíte vytvořit testovací případy, abyste otestovali uživatelské rozhraní aktualizované funkce Chytrých karet Google.

3) Nugát:

• Je třeba provést důkladné testování vaší aplikace pro režim reality daydream, a proto podle toho vytvářet testovací případy.
• Vytvořte testovací případy a ověřte možnosti nabídky pro vaši aplikaci.
• Pokud se vaše aplikace zabývá emodži a GIFy, vytvořte testovací případy k ověření nového emodži a možnosti odesílat GIFy.

Skutečná zařízení nebo emulátory: Co si vybrat pro testování uživatelského rozhraní?

Když musíte testovat mobilní aplikaci, můžete přemýšlet o tom, co by testovací postel měla být?

Zda testovat na skutečném zařízení nebo emulátoru nebo na obou? Na to neexistuje pevná odpověď, protože výběr závisí na tom, co chcete otestovat.

Při testování funkčnosti, výkonu, síťové odezvy, polního testu atd. Byste měli vždy upřednostňovat skutečné zařízení. Ale pro věci, jako je uživatelské rozhraní, byste si měli vybrat emulátory spolu s některými skutečnými zařízeními.

Profesionálové

Výhody použití emulátorů pro testování uživatelského rozhraní jsou:

1) Není prakticky možné shromáždit zařízení všech rozlišení a to by také stálo obrovské množství peněz. Emulátory však nic nestojí.
dva) Pomocí emulátoru můžete vytvořit všechna rozlišení obrazovky a kombinace OS.
3) Pokud máte pouze jednu sadu reálných zařízení, ale tým QA má více než 1 osobu, pak všechny QA nemohou testovat paralelně stejné testovací lože. S emulátorem může každý QA vytvořit na svém počítači stejnou kombinaci a testovat paralelně.
4) Testování na emulátoru je méně časově náročné a ve srovnání se skutečným zařízením je rychlejší.
5) Běžné chyby související s uživatelským rozhraním, jako je zarovnání atd., Lze snadno zachytit na emulátorech.

Nevýhody

Nevýhody zahrnují:

1) Gesta nelze testovat na emulátorech. Najednou lze napodobit pouze jedno gesto.
dva) Nelze také testovat fyzické vstupy GPS, výpadku nebo slabé sítě atd.
3) Neexistuje žádný způsob, jak vytvořit emulátor pro telefony Sony, LG, Nexus atd.
4) Na emulátoru není možné vytvořit skutečné prostředí s nízkou baterií nebo nízkou pamětí atd.

Proto by mělo být rozhodnuto v závislosti na vaší aplikaci a požadavku na testování.

Ruční nebo automatizované testování uživatelského rozhraní?

Bez testování nelze vydat žádný produkt, ať už jde o počítačovou nebo webovou aplikaci nebo mobilní aplikaci. Jako QA se snažíme najít a nahlásit každou vadu, ale přesto jsou hlášeny zákazníky.

Víš proč?

Protože zdlouhavé testy, kterým se často vyhýbáme nebo jim chybíme, takže zanecháváme nezjištěné chyby. Také 100% pokrytí, hloubkové provedení není možné při ručním testování.

Testování uživatelského rozhraní je docela jednoduché a přímočaré a musíte se jen podívat, jak to vypadá vašemu oku. Pokud je to provedeno ručně, je to velmi časově náročné. Většinu času, které potřebujeme k vytvoření obrovských dat pro testování uživatelského rozhraní, jako je svitek, se také zobrazí, pouze pokud řádky karet překročí určitý počet.

Vytváření velkých dat je velmi časově náročné. Automatizovaná sada může vyřešit oba problémy.

Naopak, pokud jsou funkce nebo uživatelské rozhraní aplikace stále v měnící se fázi, nemá smysl investovat do automatizace. Podobně, pokud jsou funkce aplikace zásadní, je lepší testovat ručně.

V závislosti na následujících ukazatelích byste se tedy měli rozhodnout, zda otestovat ručně nebo automatizovat:

• Povaha vaší aplikace.
• Stabilita vaší aplikace.
• Dostupné zdroje jako pracovní síla ke studiu nástrojů a jejich porovnání.
• Kolik času vyžaduje investované studium a rozběh automatizačního nástroje?
• Je klient připraven investovat čas do rozběhu a studia?

Nástroje pro testování uživatelského rozhraní mobilních aplikací

Následuje seznam 5 nástrojů, které lze použít k testování uživatelského rozhraní mobilní aplikace pro Android a / nebo iOS.

(Pro nástroje pro testování funkčnosti y můžete odkazovat na seznam automatizačních nástrojů v naší automatizaci nástroje pro testování aplikací pro Android strana).

# 1) Selendroid

Selendroid je jedním z nejlepších a nejvíce doporučených nástrojů pro automatizaci mobilních aplikací pro testování uživatelského rozhraní.

Lze jej použít pro nativní i hybridní aplikace. Lze jej použít pouze pro aplikace pro Android a testy API klienta se zapisují pomocí Selendroid 2. Lze jej také použít s více než jedním zařízením a je plně kompatibilní s JSON.

# 2) Testdroid

Jedná se o cloudový nástroj, který lze použít pro různá zařízení, různá rozlišení obrazovky a verze OS pro Android i iOS. Testování paralelních zařízení je velkou výhodou tohoto nástroje a je dobrým nástrojem pro testování uživatelského rozhraní. Pomáhá vývojářům zlepšit čas potřebný k uvedení na trh.

# 3) SeeTest

Je to placený nástroj a lze jej použít pro Android, iOS, Windows, Symbian atd.

Jedná se o nástroj pro různé platformy, a proto výhodou je, že na všech platformách lze spustit stejný test. Lze jej použít pro všechny mobilní aplikace a testy lze spustit paralelně na více než jednom zařízení.

# 4) Automatizace uživatelského rozhraní

Toto je oficiální nástroj pro testování uživatelského rozhraní pro Apple a je to nejlepší nástroj pro automatizaci aplikací pro iOS. I když je těžké se ho naučit, nabízí velkou výhodu v knihovnách, výkonu, testování uživatelského rozhraní atd.

# 5) Calabash

Lze jej použít pro testování systému Android i iOS pro nativní nebo hybridní aplikace. Je to nástroj pro různé platformy a nejlépe se používá k automatizaci gest, snímků obrazovky, tvrzení atd. Lze jej použít na skutečných zařízeních s dotykovou obrazovkou. Má také podporu pro okurku.

nejlepší služba pro obnovu dat z pevného disku

Když vývojáři testují aplikaci jednotkami, mohou také provádět testování uživatelského rozhraní pomocí aplikace Android Studio, ale lze ji použít pouze pro aplikace pro Android.

Doporučené čtení => Automatizujte testy uživatelského rozhraní

Kontrolní seznam pro testování uživatelského rozhraní mobilní aplikace

Níže je uveden kontrolní seznam pro testery, aby bylo zajištěno, že grafické uživatelské rozhraní bude na chytrých zařízeních testováno úplně dobře:

5 mýtů o automatickém testování mobilního uživatelského rozhraní

Automatizované testování mobilního uživatelského rozhraní je považováno za hodně zásadní, když vyvstává otázka úspěchu aplikace. Existují však některé mýty týkající se automatizovaného testování.

Takové mýty nemusí být pravdivé, protože mohou být povrchní. Ponořením se do procesu automatizovaného testování zmizí. Pojďme se do nich ponořit hlouběji.

Mýtus 1: Rychlost

Tento mýtus je velmi běžný. Většina lidí souvisejících s IT průmyslem má mýtus, že provádění „testování automatizace“ trvá déle ve srovnání s „manuálním testováním“. Tato skutečnost je do jisté míry pravdivá v několika scénářích.

Důvodem je to, že ruční testování přináší rychlé výsledky ve srovnání s Automated Mobile UI Testing. To je však případ pouze v předběžných a počátečních fázích.

S opakovaným druhem testování potřebujete buď přidání mnohem více funkcí testování, nebo snížení testovacích kvalit. Zatímco s automatizovaným testováním vždy pokaždé spustíte podobné úrovně testování, což má za následek dlouhodobou úsporu času.

Mýtus 2: Pokrytí

V současném scénáři jsou nová zařízení Android pravidelně uváděna na trhy. A počet aplikací těchto operačních systémů (OS) se zvyšuje. Pak existují operační systémy, jako je iOS, které mají ještě více aplikací vytvořených pro každodenní použití.

Ruční testování tolika aplikací se stává velmi obtížným. V případech automatizovaného testování však bude stačit údržba cloudových serverů. Pomocí automatizovaného testování je možné celkové a úplné pokrytí testů aplikací.

Mýtus 3: Náklady

Faktem je, že automatizované testování aplikací stojí více ve srovnání s náklady na ruční testování. To však platí pouze v případě, že se provádějí testy pro základní funkce aplikace. S tím, jak se prostředí aplikace a software komplikuje, se manuální testování dražší.

Je to proto, že pro dosažení optimálních výsledků testu jsou zapotřebí sofistikovanější nástroje. Spolu s těmito sofistikovanými testovacími nástroji existuje potřeba vysoce vyškoleného personálu, který by tyto nástroje dokázal spravovat. To bude vyžadovat jejich zaškolení.

Ruční testování se tak stává nákladnějším ve srovnání s automatizovaným.

Mýtus 4: Konzistence

V případě ručního testování vždy existuje prostor pro různé vnímání, které se u jednotlivých testerů liší. To také závisí na zvažovaných testech, prostředích a aplikacích spolu s operačním systémem (OS).

Když na software použijete ruční testování, existují díry, kterými by mohlo projít několik chyb. Ruční testování je tedy dobré pouze pro detekci základních chyb. Automatizované testování běží na skriptech bez prostoru pro různé vnímání, takže je spolehlivý.

Mýtus 5: Neochota

Není pravda, že automatizované testování nahradilo lidské bytosti, ale spíše pro zlepšení manuálního testeru. Automatizované testy poskytují automatické výsledky opakovaně, několikrát s maximální přesností. Vyvstává tedy otázka, proč je potřeba lidí?

Automatizované testování vyžaduje psaní scénářů a plánování celého postupu testování. Tento úkol vyžaduje lidské úsilí. Postup automatizovaného testování pomáhá ušetřit čas a peníze, takže takové zdroje využijete ke zdokonalení postupů ručního testování. Vývoj lepších nástrojů zase pomůže při zdokonalování již existujících postupů automatizovaného testování.

Výše uvedené je několik nejpopulárnějších mýtů, které převládají v odvětví automatizovaného testování. To je třeba vymýtit pro zdokonalení Automatizovaného testování mobilního uživatelského rozhraní.

Mýtus a realita

Faktem je, že i ty nejsofistikovanější vývojové společnosti používají ruční testování mobilních telefonů nebo vůbec neprovádějí kompletní testování. Podle průzkumů Xamarin 2014 provádí testování pomocí automatizovaného uživatelského rozhraní 13,2% vývojářů mobilních telefonů. Podle studií Forrester Research pouze 53% vývojářů provádí zběžné testy na jednotlivých zařízeních.

Pět nejčastějších faktorů, proč týmy mobilních telefonů neautomatizovaly kvality mobilních aplikací, a pět důvodů, proč nemají jen skutečný smysl, jsou následující:

bezplatné mýdlové webové služby pro testování

a) Rychlost je první mýtus.

Osoba si nemůže vzít čas na automatizaci. V roce 2014 představili prodejci 7000 nových typů zařízení Android. Pak existovalo 10 000 API, které byly specifické pro mobilní telefony. Aplikace mobilních telefonů se dodává rychleji a rychle se mění. Díky Quality Assurance (QA) v režimech neustálého chřipky není čas na vytváření testovacích skriptů, které by je zase synchronizovaly s pravidelně se měnícími funkcemi.

Praktický scénář prvního mýtu:

Jeden v současné době ztrácí drahocenný čas. Je to velmi pravdivé. Ruční testování je rychlejší než automatické testování. Ale toto je pro úplně první testovací běh. Při dalších bězích jakékoli okrajové výhody, které ruční testování přinese erozi. To je téměř okamžitě. Spolu se všemi opakovanými testovacími běhy nebo přidáváním funkcí by vývojáři aplikací měli buď zmenšit rozsah testování zpět, nebo další testovací prostředky.

Spolu s konečným rozpočtováním to nakonec vede k začarovaným cyklům těch kvalit, které se zmenšují. V reakci na interakce s daty a negativní recenze uživatelů ze zařízení, která nebyla testována, si týmy přejí rozšířit pokrytí zařízení. To dále zvyšuje důraz na QA oddělení již jako kapacity.

Spočívá v tom, že podnik bojuje za údržbu, výzkum a pořizování zařízení při provádění testů. Dokonce i nejlépe financované manuální programy testování uživatelského rozhraní se zkrátily směrem k dokončenému pokrytí.

V USA vyžadují mobilní týmy testování na 188 zařízeních, aby pokryly 100 procent marketingových akcií. Podle průzkumu Xamarin z roku 2014 většina vývojových týmů testuje často na 25 nebo méně zařízeních.

Více než čtvrtina těchto vývojářských komunit cílí na pět nebo méně zařízení. V reálných testovacích situacích se automatizace vyplácí téměř okamžitě a okamžitě. Hned při prvním testování je vidět, že spotřebitelé zrychlují časové osy testování čtyřikrát. Je to celé ruční testování, když běžíte proti padesáti nebo více zařízením.

Běhy, které jsou v posloupnosti, byly mnohem rychlejší. Přesto existuje zkrácení pro téměř celý týden testování na pouhé použití několika hodin.

b) Pokrytí je druhý mýtus.

Fragmentace je příčinou nemožnosti rozšíření pokrytí zařízení. Spolu s více než 19 000 zařízeními jedinečných Androidů a permutací desítek pro formování operačních systémů a faktorů pro iOS se mnoho týmů domnívá, že na poskytovaných trzích není možné pokrýt většinu zařízení.

Na několika z těchto zařízení tedy existuje výchozí testování jako dost dobré.

Realita druhého mýtu:

Jeden mohl dokončit pokrytí zařízení. V případě, že lidé udržují zařízení interně v hrsti, dělají hodně. Nákup zařízení je obtížný.

Udržování jejich peněz, nákladů a času zase zpřístupňuje jejich testery tam, kde a kdy je to pociťováno, vytváří logistické logjamy. Společnost Gartner uvedla, že mobilní vývojáři by měli hledat způsoby, jak dosáhnout vysokých rychlostí automatizace, aby udrželi krok s tempem platformy a šířením změn. To bylo v hostování. Různé funkce používají interní správu.

Cesta k takové automatizaci je prostřednictvím cloudových služeb třetích stran. Cloudové služby třetích stran pomáhají bezpečně automatizovat procesy načítání aplikací, spouštění testovacích skriptů, hlášení výsledků a opětovné nastavení záloh zařízení pro standardy továren. Podmnožiny testů aplikací běží paralelně a tím také urychlují výsledky.

Při testování dále na širokém spektru reálných zařízení umožňují testovací cloudy všem týmům přesně vědět, jak aplikace funguje, což eliminuje typické dohady vývoje mobilních zařízení.

Příklad: Produktoví manažeři stanovují méně systémových požadavků spolu s důvěrnými informacemi, které jsou oprávněné ve výkonu zařízení. Vývojáři obdrží vizuální objektivní potvrzení o opravování chyb, než se zaváže novější verze. A to bez ohledu na to, kde a kdy pracují.

c) Náklady jsou třetím mýtem.

Jednotlivci si mohou dovolit pouze manuální testování. Testování automatizace vyžaduje vytvoření testovacích skriptů, křivek učení pro zaměstnance QA a infrastruktury. Spousta týmů již bojuje o dodržení termínů. Už překročili rozpočet. Zdá se tedy, že testování automatizace je na dlouhou vzdálenost.

Praktický scénář třetího mýtu:

Ruční testování šetří peníze pouze v případě, že lidé obětují pokrytí. Ruční testování se zdá méně nákladné pouze ve většině prostých prostředí.

V případě testování zahrnuje rychlou „kontrolu vnitřností“ základních funkcí méně zařízení, pak se ruční testování jeví jako výhodné. Ale jakékoli podobnosti s pokrytím testu a komplexním zařízením způsobí, že testování ručně bude mnohem nákladnější než testování automatizace. To může být rychlé dokonce.

Ruční testování pouze váží přidáním více lidí a mas. Náklady nemají žádnou skutečnou linearitu. Rozšiřování personálu podle požadavků přináší obrovské režijní náklady ve formě koordinace a školení. Rozdělení testovacích případů tím snižuje účinnost všech testerů odstraněním perspektiv.

Kromě toho nemusí být testeři, kteří mají dostatek sofistikovanosti na to, aby překonali chování uživatelů, a tím prozkoumali a předvídali důvody, proč aplikace mohou selhat, ani hojné, ani levné. Testování automatizace vždy vyžaduje o něco více režijních nákladů v době počátečního nastavení.

Ale jak je uvedeno výše, může při testovacích rychlostech dramaticky vytvářet zisky a zisky. Rovněž za pár dní vytvoří odpovídající snížení počtu zaměstnanců. Cloudová testovací prostředí dále snižují náklady. Důvodem je vyloučení nedostatečně využívané a drahé místní testovací infrastruktury.

d) Důslednost má být čtvrtým mýtem.

Musí být provedeno, provedeno a operováno dost dobré. Pro různé testovací týmy jsou připravená nasazení subjektivní rozhodnutí postavená na vnímání mnoha různých ručních testerů. Mají znalosti, že to znamená, že chyby padají prasklinami.

Před vydáním musí překrývající se pokrytí testů zachytit nejběžnější a nejdůležitější problémy. Zbytek chyb čeká na vydání údržby.

Skutečný scénář čtvrtého mýtu:

Vlastnosti nejsou kvalitativní. Připravenost inscenací nesmí být činiteli a názory. V čistě manuálním testovacím prostředí se vnímání liší od jednoho testu k druhému a od jednoho testera k druhému testeru. To vede k nepravidelným výsledkům testů a nedůsledné dokumentaci.

Rozhodování se komplikuje, když se uvažuje o připravenosti produktů. Vede to k selhání dodržování předpisů, hromadnému rozčarování a ztrátě příjmů. Kromě toho dochází k vytváření kapes kmenových nezachycených porozumění, která se ztratí, když lidé a zaměstnanci vyjdou ze dveří.

Automatizace zase vytváří kvantifikovatelné metriky. To slouží jako objektivní zdroje pravdy pro informování rozhodnutí týkajících se odůvodnění obchodního rozhodnutí, připravenosti produktu a postupu týmů grafů.

e) Neochota je pátý mýtus.

Ruční testování bylo nahrazeno automatizačním testováním. Spousta různých vývojářů má přístup k automatizaci testů, protože očekávají, že nahradí testery, kteří pracují ručně, stroji.

V případě, že automatizace testů opakuje podobné testy 1000krát se 100 procentní přesností, objeví se dotazy, proč jsou pro účely testování potřeba lidé. Automatizaci testovacích skriptů mohou provádět také stroje.

Obrázek pátého mýtu v reálném čase:

Ruční testeři jsou díky automatizačnímu testování lepší. Stroje a lidé mají dobré scénáře se spoustou různých věcí a faktorů. Testeři, kteří ruční testování provádějí vždy, mohou testovat kreativněji.

Automatizační testování je od toho osvobozuje. Zatímco se lidé těší na novější způsoby rozbíjení aplikací, automatizace zajišťuje shodu v celé řadě zařízení. Toto je od testů jednotek po úplné testy regrese. 2 přístupy nemusí fungovat izolovaně.

Provádět zkouškové manuální testy, zatímco back-endové systémy nebyly zatíženy automatizovaným testováním. Jedná se o vynikající způsoby, jak objevit chyby, které se objevují v prostředích produkcí. Testování automatizace nenahrazuje testery, kteří jsou lidmi. To jim umožňuje provádět odměňování a zajímavou práci.

Lepší konzistence, pokrytí, náklady a rychlost přispívají k vylepšeným kvalitám. Úspora peněz a času znamená, že je možné provést více testů a ne méně. To je případ, kdy člověk dosáhne milníků, které jsou kritické. To umožňuje testování držet krok společně s týmy agilního vývoje, místo aby stál v cestě.

Organizace tedy vydávají kód mnohem častěji. To snižuje dopady a množství vad, které jsou dané sestavení. To znamená, že vývojáři pracují s čistými kódy. Opravy chyb byly méně komplikované dramaticky. Toto osvobozuje testery díky tomu, že se gatekeepers zaměřují na kreativitu. Průzkumné testování tak zlepšuje kvalitu produktů.

Automatizační testování mobilních uživatelských rozhraní nabízí výhody týkající se časů a kvalit. Automatizované nástroje usnadňují testerům posuzování uživatelských rozhraní aplikací prostřednictvím rozšířených rozsahů mobilních zařízení spolu s prováděním úprav pro snadné zvýšení uživatelských zkušeností.

Závěr

Špatné grafické uživatelské rozhraní je pro uživatele nepříjemným zážitkem. Testování grafického uživatelského rozhraní je vysoce doporučeno a důležité, zejména pokud jde o inteligentní zařízení, protože zde je velikost obrazovky poměrně malá a na trhu je k dispozici spousta variací zařízení.

Vaše aplikace může na různých zařízeních vypadat a chovat se odlišně. Je tedy důležité otestovat aplikaci alespoň na některých standardních velikostech a variantách zařízení.

Všechny mobilní aplikace vyžadují testování uživatelského rozhraní, ale hloubka požadovaného testování je definována kategorií nebo účelem aplikace. Než dokončíte testovací postel, měli byste provést kompletní analýzu funkcí uživatelského rozhraní aplikace oproti modelu telefonu nebo verzi operačního systému.

Na základě této analýzy byste měli vytvořit testovací případy pro testování. Pokud je to možné, používejte automatizaci, abyste ušetřili čas.

Při testování uživatelského rozhraní mějte otevřené oči, protože je to jednoduché, ale má to velký vliv na prodej vaší aplikace.

Podívejte se na náš nadcházející výukový program, kde najdete podrobné informace o Mobilní responzivní test .

Doporučené čtení

• Výukový program Appium pro testování mobilních aplikací pro Android a iOS
• TOP 15 nejlepších nástrojů pro mobilní testování v roce 2021 pro Android a iOS
• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Beta testovací služby pro mobilní aplikace (nástroje pro testování beta verze iOS a Android)
• Proč je mobilní testování těžké?
• Začínáme s Robotium - nejoblíbenější nástroj pro testování uživatelského rozhraní aplikací pro Android
• Testování stahování e-knih Primer
• 11 nejlepších automatizačních nástrojů pro testování aplikací pro Android (nástroje pro testování aplikací pro Android)