Testování výkonu mobilních aplikací

⚡ Chytré shrnutí

Testování výkonu mobilních aplikací měří, jak rychle se aplikace spouští, kolik baterie a paměti spotřebovává, jak rychle reagují její API a jak elegantně se chová v nespolehlivých sítích.

  • 🔘 Tři kategorie: Výkon zařízení, výkon serveru nebo API a výkon sítě společně pokrývají všechna úzká hrdla mobilních zařízení.
  • ☑️ Signály zařízení: Základními kontrolami zařízení jsou doba spouštění, vybíjení baterie, spotřeba paměti, hardwarové odchylky a obnovení na pozadí.
  • (Tj. Signály serveru: Velikost datové zátěže, počet volání API na akci a zdokumentovaný plán přepnutí na záložní systém pro případ výpadku serveru.
  • 🧪 Síťové signály: Jitter, ztráta paketů a změny rychlosti musí vést k jasnému hlášení, nikoli k zamrznutí obrazovky.
  • 🛠️ Nástroje: RobotiumObjevují se zde , MonkeyRunner a Automator, ačkoli první dva již nejsou udržovány.
  • 📊 Připravenost: O tom, zda bude sestavení dodáno, rozhoduje kontrolní seznam zahrnující RAM, dobu odezvy, souběžnost a odolnost proti pádům.

Testování výkonu mobilních aplikací napříč vrstvami zařízení, serveru a sítě

U každé mobilní aplikace je výkon velmi důležitý. Pokud vaše mobilní aplikace nefunguje dobře, koncový uživatel ji odinstaluje a najde si jinou aplikaci, která funguje lépe.

Vaši mobilní aplikaci je třeba důkladně otestovat, než ji vydáte koncovému uživateli.

Strategie testování mobilních aplikací

Výkon aplikací na mobilním telefonu nebo jakémkoli chytrém zařízení se obvykle měří v následujících třech kategoriích.

  • Výkon zařízení
  • Výkon serveru/API
  • Výkon sítě

Níže uvedený diagram mapuje tyto tři vrstvy na jejich kontroly.

Graf strategie testování mobilních aplikací s rozdělením kontrol výkonu zařízení, serverů a sítí

Výkon zařízení

Když klient zažívá pomalou aplikaci, je naštvaný.

Pro výkon zařízení zkontrolujete následující:

  • Spuštění aplikace: Jak dlouho trvá spuštění vaší aplikace? Je to první výkonnostní parametr, který posuzuje uživatel. Obecně platí, že poté, co uživatel klepne na ikonu aplikace, by se první obrazovka měla zobrazit za 1-2 sekundy.
  • Výdrž baterie při používání aplikace: Při neustálém používání některé mobilní aplikace spotřebovávají hodně energie baterie a zahřívají telefon. K tomu obvykle dochází, když aplikace využívá více zdrojů, než je nutné, což zatěžuje procesor.
  • Spotřeba paměti: Kdy Testování aplikace, měla by být zkontrolována spotřeba paměti aplikací. Implementací určitých funkcí do aplikace se také zvyšuje spotřeba paměti. Například v Android aplikace, když jsou implementována oznámení push, pak se spotřeba paměti zvyšuje.

    V některých případech bylo pozorováno, že využití paměti celým operačním systémem je pouhých 14 %, ale nová aplikace spotřebovává 11 %. Tyto faktory je tedy třeba řešit před nasazením aplikace do reálného světa nebo předáním klientovi.

  • Hardwarová/softwarová varianta: Při testování mobilní aplikace je povinné kontrolovat aplikace na různých zařízeních. Může se stát, že aplikace běží hladce na jednom zařízení, ale ne na druhém. Stejně jako u různých prodejců Android zařízení, můžeme aplikaci zkontrolovat na telefonech Samsung, HTC a Lenovo. Podobně je třeba aplikaci otestovat s různými specifikacemi RAM a procesoru, jako je 1 GB nebo 2 GB.
  • Použití s ​​jinými aplikacemi: Když testovaná aplikace běží paralelně s jinými aplikacemi, nemělo by docházet k rušení. Nejlepší způsob, jak to zkontrolovat, je přepnout testovanou aplikaci a jiné aplikace.
  • Aplikace na pozadí: Když je aplikace běžící na pozadí načtena, měla by zůstat ve stejném stavu, v jakém byla předtím. Pokud se tento scénář správně neošetří, dojde ke ztrátě dat. Související případy životního cyklu jsou popsány v testování přerušení.

Výkon serveru/API

Když aplikace interaguje se serverem prostřednictvím API, doba odezvy se stává kritickou pro výkon. Pro výkon serveru zkontrolujete:

  • Data do a ze serveru: Aplikace by měla efektivně zpracovávat data odesílaná ze serveru. Načítání dat by nemělo trvat příliš dlouho. V některých aplikacích jsou data odesílána ve specifickém formátu, takže před zobrazením v aplikaci by měla být převedena do relevantního formátu. V tomto procesu se aplikace někdy zpomalí a doba odezvy se prodlužuje.
  • Volání API generovaná z aplikace: Počet volání z testované aplikace na server generovaných z aplikace by měl být nižší. V některých případech se pro stejnou funkci provádí více volání API. Pro lepší výkon by to mělo být řešeno menším počtem hovorů.
  • Doba výpadku serveru: Z jakéhokoli důvodu, pokud je server nedostupný nebo mimo provoz, můžeme ukládat data do nativní databáze. Takže kdykoli je server nedostupný, můžeme zobrazit data uložená v nativní databázi. Dalším řešením by mohly být záložní databázové servery, tj. pokud je jeden ze serverů nedostupný nebo je ve fázi údržby, měl by být záložní server k dispozici pro přepnutí. Záložní server by měl být v nepřetržité replikaci a synchronizaci s hlavním serverem.

Výkon sítě

Je třeba měřit výkon aplikace v různých sítích a síťových vlastnostech.

Pro výkon sítě zkontrolujete následující věci.

  • Nervozita: Pokud dojde ke zpoždění při příjmu informací v síti, nazývá se to jittery. Je to problém s nespojenými sítěmi nebo sítěmi s přepínáním paketů. Jak jsou informace distribuovány do paketů, pakety mohou cestovat po odlišné cestě od odesílatele k přijímači. Když data dorazí na zamýšlené místo, stanou se zakódovaná, než byla původně odeslána. V případě Jitters by mobilní aplikace měla být dostatečně schopná to zvládnout.

    Koncovému uživateli musíte zobrazit příslušná oznámení, buď aby požadavek znovu odeslal, nebo počkal, až systém znovu odpoví.

  • Ztráta paketů: V případě úplné ztráty paketů by aplikace měla být schopna znovu odeslat žádost o informace nebo by měla odpovídajícím způsobem generovat výstrahy. Pokud data nejsou úplná, uživatel nebude schopen porozumět informacím zobrazeným v aplikaci. To může být pro uživatele stresující. Je tedy lepší zobrazit vhodnou zprávu nebo vyzvat uživatele, aby to zkusil znovu.
  • Rychlost sítě: Aplikaci je třeba otestovat v různých sítích s proměnnou rychlostí. Aplikace by měla být testována v sítích 3G, 4G a 5G. To zahrnuje jak Wi-Fi, tak mobilní sítě. Také by mělo být monitorováno chování aplikace, zejména pokud jsou obě sítě dostupné a dochází k přepínání z jedné sítě do druhé.

    Například se může v aplikaci vyskytnout problém u uživatelů při přepínání telefonní sítě ze 4G na Wi-Fi a naopak. V takovém případě aplikace přestane reagovat a pro použití může být nutné ji restartovat.

Odstraňování problémů s výkonem mobilních aplikací

Po zjištění problémů/problémů Testování výkonuJe čas trace a opravte chyby.

Problém 1) Zpožděná nebo pomalá odezva mobilní aplikace.

Příčinou tohoto zpoždění může být RAM, mezipaměť atd.

Musíte zabít nepotřebné procesy nebo vymazat mezipaměť. Odstraňování problémů s připojením může vyřešit některé problémy, které způsobují zpoždění

Problém 2) Restartování aplikace, zamykání, zamrzání nebo nereagování.

Může to být opraveno některým z následujících kroků

  • Optimalizace aplikačních kódů
  • Software by měl být opraven a aktualizován.
  • Automatické obnovení
  • Správa RAM nebo v některých případech ROM při používání externích karet
  • Wiping rozdělení mezipaměti
  • Ověření fungování aplikace s jinými aplikacemi a API třetích stran
  • Mapaping mobilní aplikace podle zařízení

Užitečné nástroje pro testování mobilních aplikací

Nástroje pro testování mobilních aplikací se liší podle zařízení nebo mobilního OS. Některé běžné nástroje pro testování výkonu mobilních aplikací jsou

ANDROID

  • Robotium Je to jako Selenium pro mobilní aplikace. Tester může zaznamenat a přehrát několik kroků, které jsou nutné k provedení testování.
  • Opičí běžec MonkeyRunner může spouštět testy na skutečných zařízeních připojených k PC nebo emulátorům. Nástroj má API, které umožňuje ovládat smartphone, tablet nebo emulátor zvenčí Android kód.

⚠️ Poznámka k verzi: Oba Android záznamy jsou starší. Robotium neměla žádné vydání od roku 2016 a Google označuje MonkeyRunner za neudržovaný, což týmům ukazuje na UI Automator a jeho uiautomatorviewer místo toho inspektor.

APPLE

  • Automat (Mac) Automator je aplikace vyvinutá společností Apple pro macOSImplementuje vytváření pracovních postupů metodou „point-and-click“ (nebo „drag-and-drop“) pro automatizaci opakujících se úkolů do dávek pro rychlejší úpravy. To šetří čas a úsilí oproti lidskému zásahu při ručním upravování každého souboru zvlášť.

Oblasti využití

Mezi klíčové výzvy, kterým čelíte při testování výkonu, patří

  • Organizace různých mobilních platforem a jejich operačních systémů
  • Simulace konektivity jako 3G, 4G, 5G nebo Wi-Fi atd.
  • Omezení mobilních zařízení, jako je spotřeba baterie a zdrojů
  • Použitelnost mobilního telefonu
  • Různé velikosti mobilních zařízení pro spuštění stejné aplikace

Nastavte testovací prostředí mobilních aplikací

Chcete-li nakonfigurovat testovací prostředí, musíte:

  • Pochopení mobilní aplikace, kterou je třeba otestovat
  • Identifikace různých operačních systémů, na kterých je třeba aplikaci spustit
  • Vytvoření testovacího nastavení
  • Sestavte emulátory nebo simulátory
  • Prototyping skutečného nastavení
  • Výběr vhodného nástroje pro testování

Kontrolní seznam pro testování výkonu mobilních aplikací

Testování výkonu mobilních aplikací je důležitým měřítkem před vydáním. Pro kontrolu se provádí testování výkonu

  • Kolik paměti RAM je potřeba k používání této aplikace?
  • Pro ověření rychlosti a doby odezvy APP v různých sítích a za různých okolností.
  • Zajistěte realistickou uživatelskou zkušenost v několika síťových podmínkách
  • Zajistěte dosažení požadovaných výsledků v případě více připojení
  • Ujistěte se, že aplikace nespadne.
  • Zajištění dobrého výkonu mobilních aplikací při používání dat, Wi-Fi nebo jiného připojení
  • Sledování doby provozuschopnosti a úzká hrdla používání mobilního rozhraní API
  • Pro zajištění maximálního počtu současných uživatelů
  • Nakonec zkontrolujte mobilní aplikaci na její limity

Nejčastější dotazy

Obvyklým cílem je méně než dvě sekundy na zařízení střední třídy, což odpovídá výše uvedenému pravidlu. Měřte 95. percentil spíše než průměr, protože pomalá zařízení dominují skutečným stížnostem.

Událost ANR je „Aplikace nereaguje“, která se vyvolá, když… Android bloky hlavního vlákna. Míra bez pádů je podíl relací, které skončily bez pádu. Google Play de-prioritizují aplikace, které překračují zveřejněné prahové hodnoty pro kteroukoli z těchto možností.

Šedesát snímků za sekundu je základní hodnota pro rolování a animaci a novější displeje cílí na devadesát nebo více. Vynechané snímky, nazývané „jank“, se berou jako špatná kvalita, i když nedochází k žádnému pádu.

Strojové učení vyhodnocuje každou metriku pro každý model zařízení jako výchozí bod, takže regrese je označena spíše pro podobný hardware než pro jedno globální číslo. Také seskupuje pomalé traces, čímž se seřadí, které úzké hrdlo ovlivňuje nejvíce relací.

Copilot dobře navrhuje opakující se strukturu, například kostru načítacího skriptu nebo smyčku, která zachycuje vzorky paměti. Prahové hodnoty a výběr zařízení odrážejí váš produkt, proto si před důvěryhodností každého vygenerovaného tvrzení (assertion) prohlédněte.

Používejte obojí. Emulátory poskytují levné a opakovatelné běhy sítě a API uvnitř kanálu. Pro vybíjení baterie, tepelné omezení a chování specifické pro dodavatele, které emulátory nemohou věrně reprodukovat, jsou vyžadována skutečná zařízení.

JMeter je běžnou volbou open-source pro řízení souběžných požadavků na stejných koncových bodech, které aplikace používá. Měří kapacitu serveru, kterou nástroje na straně zařízení nikdy nevidí.

Zaznamenaný limit pro dobu spouštění, paměť nebo velikost balíčku, který sestavení automaticky kontroluje. Jeho překročení selže sestavení, takže regrese jsou zachyceny v době sloučení, nikoli po vydání.

Shrňte tento příspěvek takto: