Testování systému na extrémně negativních scénářích. Pozitivní myšlení ve světě negativního testování

Velký zájem o kvalitu produktů. To vysvětluje celosvětovou dostupnost testerů software. Poskytováním tito lidé zajišťují jeho kvalitu.

Mnoho testerů nikdy nezapomene na negativní testování, i když ne všichni programátoři z toho mají radost. Taková kontrola je potřebná k ochraně proti hackerům, botům, útokům Dos/DDos.

Co je povolání specialistů na testování? Musí najít problémy, které ostatní nevidí. S negativním testováním neotálejte, jinak vystavujete systém nebezpečí.

Pozitivní a negativní testování

Začněme od začátku. Když jsou do testování zahrnuty testovací případy, existují 2 typy kontroly: pozitivní a negativní. Ten druhý má výhodu.

Pozitivní testování je proces kontroly správného chování podle technických požadavků a dokumentace. Pozitivní testování se provádí, aby bylo zajištěno, že systém dělá přesně to, co se očekává.

Negativní testování je proces kontroly nesprávného chování. Prostřednictvím takového testování se můžeme naučit, že si systém dokáže poradit s neočekávanými situacemi.

Pozitivní-negativní testování

Chcete-li provést testování softwaru, musíte mít intuici nebo lovecký instinkt. Specialista na testování je všestranný člověk, který může provádět obchodní analýzu i testování.

Testeři kontrolují, zda je proces prováděn správně: zda je v souladu s technickými požadavky a testovacími scénáři. Provádění pozitivních a negativních testů samostatně bude trvat déle než jejich provádění současně. Je to proto, že existují dvě testovací iterace.

Koneckonců, čím blíže je hodina X, tím rychleji čas plyne tím dříve potřebujete dokončit úkoly, opravit vady, uplatnit obchodní požadavky (které se mohou lišit) a mnohem více. Termín je nejžhavější čas!

Oddělování negativního a pozitivního testování je prostě v rozporu s povahou testera! Jeho úkolem je kontrolovat systém pro všechny možné akce koncového uživatele.

Lidé jsou obecně nelogičtí a mohou způsobit problémy v softwaru. Negativní testování pomůže vyhnout se problémům.

V mých kurzech pro školení začínajících testerů navrhuji, aby psali pozitivní a negativní testy pro:

1. Funkce výpočtu odmocniny v kalkulačce.
2. Práce s košíkem (přidávání / mazání / editace) v internetovém obchodě.

A toho jsem si všiml – s pozitivním testováním je vše v pořádku, kluci přicházejí s nápady odlišné typy testy (protože úkolem je vyjmenovat alespoň některé a nevyjmenovat vše, všechny, všechny, takže i když pracuji v týmu, nemusím se opakovat). Mnoho lidí má ale se záporem problémy, žádají upřesnění, protože „nenapadá nic jiného, ​​než zadat symboly do číselné hodnoty počtu zboží v košíku a vypočítat odmocninu záporného čísla“.

Proto jsem se rozhodl napsat vysvětlující článek.

Pozitivní testování

Tester je osoba, která poskytuje informace o produktu týmu. Rozhodli jsme se tedy udělat stejný internetový obchod, promysleli koncept, napsali kód a nyní je úkolem testování zjistit, zda vše funguje tak, jak potřebujeme.

A velký význam mají samozřejmě pozitivní testy. Pokud uživatel přijde na náš web a nemůže vložit položku do košíku, pak ho vůbec nebude zajímat, že při zadávání jakýchkoliv speciálních znaků nebo SQL injekcí píšeme krásné chybové hlášky.

Proto, když dostaneme něco na zkoušku, můžeme vesele spěchat na vylamování nových forem, ale potřebovat nejprve zkontrolujte správné skripty. Nejprve uspokojíme věrné a kompetentní uživatele a pak uděláme zbytek.

Pozitivní testování je tedy zaměřeno na ujištění, že hlavní funkčnost funguje. Všechny scénáře použití našeho systému jsou proveditelné a vedou k očekávanému výsledku, nikoli k chybám.

Podívejme se na příklad:

Hlavním testovacím případem je zkontrolovat, zda je skutečně vypočítána odmocnina správného čísla.

Lze ji rozdělit do následujících tříd ekvivalence:

• Po výpočtu odmocniny zůstane celé číslo (odmocnina 4 = 2)
• Po výpočtu odmocniny zůstane zlomkové číslo (odmocnina ze 3)

Hmm, co když nemáme jen zlomkové číslo po kořenové výpočty, ale také před ? Můžeme vzít kořen 2.2? Pozitivní test? Pozitivní!

Čísla můžete také rozdělit na malá, například do 100. Pak vezměte interval od 100 do velikosti int a třetí bude ještě větší, tolik, kolik se vejde do naší kalkulačky. 3 třídy ekvivalence, kontrolujeme jednu hodnotu z intervalu.

Nezapomeňme na hraniční hodnoty, zaškrtneme 0. Pozitivní test? Ale samozřejmě! Odmocnina 0 je 0, nejedná se o chybu!

Z toho hlavního snad všechno.

Ach, tam je prostor pro fantazii!

Uživatel může provádět tolik různých scénářů!! Nejprve si ale vezměme ty hlavní, nejkratší. Protože pokud nefungují, tak dlouhé řetězce (přidané – upravené – smazané – znovu přidané – atd.) rozhodně nestojí za kontrolu. Tak:

Myslíte, že to bude fungovat, když to bude fungovat samostatně? Néééé, kluci, vy jste testeři! Nikdy neberte programy za slovo! Už jste vymysleli scénář? Koukni na to!

Navíc takový scénář může selhat, tento produkt jsme již odstranili z košíku, že? Takže nám systém možná nedovolí jej znovu přidat. Jako "už jsi to vzdal, ahoj, všechno si pamatuji!" Je toto chování správné? Ne!

Je scénář sám o sobě pozitivní? Ano! I když už s notami perverze, musím uznat

Negativní testování

Musíme mít na paměti, že negativní testování není o nic méně důležité než pozitivní testování. Protože našimi uživateli jsou lidé, ne roboti. A lidé mají tendenci dělat chyby. A na tento lidský faktor musíme vždy pamatovat.

Pokud přijdu na stránky, objednám a vše proběhne v pořádku, přijdu tam znovu. Ale když přijdu, objednám a náhodou někde udělám chybu, třeba místo čísla vložím zprávu zkopírovanou z ICQ, tak chci vidět taktní poznámku, a ne pád celého systému.

Obecně platí, že v dnešní době je obvykle velký výběr stránek k vyřešení problému uživatele (například potřebujete něco koupit). Když se na ně uživatel podívá a uvědomí si, že funkce, které potřebuje, je všude, vybere si tu nejkrásnější a nejpohodlnější stránku.

Ale bez ohledu na to, jak pohodlný je takový web, pokud není schopen fungovat pod vlivem lidského faktoru, uživatel dříve nebo později odejde. „Krok doleva, krok doprava – provedení“, komu se to bude líbit? Chtěl bych mít možnost dělat chyby a opravovat chyby a nebýt fackován děsivými chybovými zprávami po celé obrazovce.

Proto provádíme negativní testy. Co je negativní testování? Toto jsou zjevně nesprávné údaje. Vstoupíme a uvidíme, jak se program chová, zda jsou chybové hlášky jasné...

Jak ale takové testy vytvořit? Podívejme se na příklady:

1. Funkce pro výpočet odmocniny v kalkulačce.

První věc, která vás napadne, je, co se stane, když vypočítáte odmocninu záporného čísla?

Ale co jiného vás tu napadne?

• Kořen z prázdnoty - pamatujte na hraniční hodnoty, nemůžeme zadat řetězec záporné délky, ale můžeme zadat hraniční hodnotu (řetězec nulové délky)!
• Kořen symbolů - musíte zkontrolovat, co systém řekne, pokud do něj zadáte nebo vložíte něco symbolického. Navíc rozdělujeme symboly na ruské, anglické a speciální symboly!
• Kořen významu "čtyři" - symboly lze také rozdělit na abrakadabra a "číslo typu". Mimochodem, pokud mluvíme o takovém „typu čísel“...
• Zkusme zadat řetězec, který představuje číslo . A vzít z toho kořen.

Vidíš? Ve skutečnosti těch testů není tak málo! Samostatně bych rád hovořil na téma „představení velmi velké číslo, co největší." Můžete to zkusit, proč ne? To však bude mít negativnější dopad na scénář kvadratury než na výpočet odmocniny.

V kořenu nelze zadat největší možné číslo, ale zadat číslo takové, aby se kořen z něj (zlomková hodnota) ukázal jako velmi dlouhý a nevešel se na obrazovku, takže co se stane potom, bude odříznutý nebo zlomený?

2. Práce s nákupním košíkem v internetovém obchodě.

Zde opět můžete najít číselné pole a pohrát si s ním, jako jsme to právě udělali s kalkulačkou. Pole „množství položky“ je zde velmi vhodné! Ale na druhou stranu je to nuda, jako různé aplikace a stejné testy?

Zapamatuj si jen 2 slova - různé karty !

Cítíš to? Nech mě to vysvětlit. Negativním testem pro smazání položky z košíku je pokus o odebrání již smazané položky. A zde jsou možnosti, jak to lze provést:

• Otevřete košík na 2 kartách prohlížeče. Nejprve jsme klikli na „smazat“ v jednom a poté ve druhém. Tedy pokus smazat něco, co jste sami již smazali z vlastního koše.
• Pokus o smazání produktu smazaného administrátorem. V 1 záložce pod adminem v zásadě smažeme produkt úplně a ve druhé se ho snažíme odstranit z košíku pod uživatelem.

A mimochodem, můžete také zkusit přidat produkt smazaný adminem nebo upravit jeho množství. A admin nesmí produkt smazat, ale přesunout do jiné kategorie. A tady se nic nesmí zlomit!!! Pokud bychom v případě smazání měli vidět správnou chybovou zprávu, pak v případě přenosu můžeme jednoduše pokračovat v práci.

Co se stane, když admin nepřesunul produkt v hierarchii obchodu (přesunul jej do jiné kategorie, produkt byl původně umístěn špatně), ale jednoduše jej opravil, upravil popis? Také by se nemělo nic rozbít!

A i když nemáme obchod, ale něco jiného, ​​vždy přemýšlejte o tom, jak můžete zkusit použít techniku ​​různých karet.

Můžeme si například vytvořit kartu - osobu, budovu, stejnou knihu, něco jiného... Zkuste to upravit ve 2 oknech. V jednom změňte jedno pole, uložte a ve druhém změňte další pole a také uložte. Nebo něco smažte a přidejte nebo změňte ve druhém okně.

Zkuste si s takovými věcmi vždy hrát, často to pro program končí katastrofálně. A i když se tým rozhodne, že takové vady prozatím neopraví, protože nejsou kritické, nezáleží na tom. Pro nás jde především o ně vědět ! Poskytněte informace a pak se rozhodněte, co s nimi uděláte...

Rád bych uvedl ještě jeden příklad z reálné praxe. Také webové rozhraní, kde můžete kliknout na „vytvořit“ a přidat novou kartu. Uživatel to přidá, ale pokaždé mu plíseň odpadne. Proč?

Začali to zjišťovat. A pochopili. Uživatel potřeboval vytvořit mnoho karet najednou (migrace), a tak několikrát klikl na „vytvořit“ se stisknutou klávesou Ctrl (otevřít v nové záložce). A pak jsem prošel záložky a vytvořil.

Zdálo by se, kde je negativní testování? Uživatel totiž výměnou stejné karty neprovádí protichůdné změny. Ne, vytváří nové, tedy zadává informace odlišný karty. Ale tak to systém myslel otevřené okno„nová karta“ s jednou věcí, hlasitě rozhořčená nad arogantními pokusy uživatele nacpat do ní tu či onu informaci.

Takže kluci, jděte do toho! Otevřete různé karty a pokračujte, hledejte informace o tom, jak přesně se váš program chová pod protichůdnými vlivy na něj?

PS - toto je úryvek z mé knihy pro začínající testery, napsané jako pomoc studentům mé školy pro testery

Přijďte nás navštívit! ツ

Aaaaa... Toto je poslední příspěvek v sérii! Je nejkratší, nejjednodušší a skládá se téměř výhradně ze skutečných příběhů. Pokud možno - hloupé a vtipné. Existuje dokonce video natočené speciálně pro záznam přímo v době psaní. Čerstvé, pane. Bohužel mě nenapadlo udělat snímek obrazovky se zprávou o pádu klienta Youtube; bylo by to v pořádku. Padl správně při nahrávání videa, které bylo vloženo do článku. Dobře, ať je to moje zamykací obrazovka.

Na začátku testování, bez ohledu na to, zda se jedná o nový projekt nebo projekt, který měl být pohřben, je obecně vždy jasné, kde začít. Pokud ovšem v době zahájení testování žádný z článků řetězu nefungoval správně. Testeři obvykle čtou požadavky a další dokumenty s neruskými názvy, jako je „BEC“, „ESArchi“ a „Uživatelský příběh“, a zjišťují, jak napsat testovací případ, aby zkontroloval provedení všech těchto dokumentů. To vše je na povrchu jasné a nemá smysl se tím zabývat. Je tu ale také chování samotného Androidu, které si někdy neuvědomují nejen analytici, ale dokonce ani architekti a někteří vývojáři. A když si pamatujeme, že pouze u vlastních se takových funkcí objeví poměrně hodně. A to nemluvím o stresových scénářích, kdy není paměť nebo je náhle vyjmuta baterie (jednou jsem se setkal s rozhořčením člověka na terminálu GNU/Linux, protože při zadávání neukazuje heslo, ale má zabugovanou klávesnici a nechápe, zda zadává heslo, nebo to zase nefunguje klávesnice), ale o standardním chování přizpůsobení Androidu a dokonce o chování, které je vlastní AOSP. Tedy standardní chování systému, které může negativně ovlivnit testovaný produkt. Takzvané negativní scénáře.

Stručně popíšu některé negativní scénáře a pokusím se uvést konkrétní příklady.

• Komunikační problémy. Nejjednodušším příkladem je Fly Mode. Například aplikace Google Keep notes buď nebyla testována v režimu letadla, nebo nalezené chyby neměly na vydání vliv. Je velmi snadné reprodukovat problém:
• Zapněte režim v letadle
• Klepněte na řádek Poznamenejte si...
• Na obrazovce, která se objeví, proveďte akci Odstranit
• Vychutnejte si animaci pohybu dříve uložených poznámek snímek po snímku

Kromě Fly Mode existuje také nestabilní připojení se ztrátou paketů a velmi pomalé připojení a uzavřené porty, přes který vaše aplikace běží, a dostupnost Wi-Fi připojení, ale bez přístupu k internetu.

• Žádný přístup do obchodu s aplikacemi. Chcete-li například otestovat nákupy v aplikaci, potřebujete, aby byla sestava zveřejněna ve speciální sekci obchodu. Pokud tam není, nebo se nejedná o stejnou verzi (mluvíme o kódu verze – interní verzi), tak nákup nezkoušejte. Pokud uživatel odjel na dovolenou do Číny, kde s připojením k Google Play vše je velmi smutné, licence, za kterou zaplatil peníze, by neměla spadnout.
• Provoz aplikace s omezenými oprávněními, pokud je cílová úroveň API nižší než 23, tedy nižší než Android 6, a když je verze API 23 a vyšší. V prvním případě je aplikace starší, ale oprávnění lze stále odebrat. V druhém případě začne dostávat nové výjimky, které dříve neznal.
• Režim úspory baterie. Implementace jak Doze, tak App Standby, stejně jako alternativní implementace od alternativně nadaných výrobců jako Samsung (a STAMINA od Sony v první verzi), kdy je vše implementováno strašně špatně, ale musíte s tím žít. Je přípustné, aby aplikace neprováděla kontroly včas, neposílala statistiky, neaktualizovala data. Není však přijatelné havarovat, zamrznout nebo nikdy nedokončit plánované úkoly.
• Změna data, času, časového pásma. Lidé mohou létat na dovolené a služební cesty do jiných zemí, kde je časové pásmo jiné. Pokud letadlo protne 180. poledník, může uživatel z pohledu aplikace skončit „ve včerejšku“.

  Skutečný příběh neúspěchu. Rodičovská kontrola v KIS pro Windows se objevila ve verzi 7.0 v roce 2006. Zároveň měl produkt vestavěný zpravodajský agent, vůbec ne takový, jaký je nyní. Předpokládalo se, že se přes něj budou posílat různé zprávy o hrozbách, všelijaké „co je nového“ a podobně. Vyskytla se chyba ve verzi vydání, kterou již uživatelé nainstalovali. Pokud nastavíte čas ve Windows zpět před zahájením licence, ochrana byla deaktivována. Přísně vzato, neadministrátoři nemohou změnit čas, ale před 10 lety firmy nijak zvlášť nehlídaly uživatelská práva a každý účetní tam měl místního správce. Jeden z našich klientů se usadil ve své malé kanceláři rodičovská kontrola aby uživatelé nemohli surfovat po internetu kromě autorizovaných stránek. Drakonowski nakonfiguroval a chránil nastavení heslem. Všechno fungovalo dobře, dokud vestavěný zpravodajský agent nedostal zprávu, že je čas aktualizovat nová verze 7.0.1, kde byla mimo jiné opravena chyba, kvůli které je ochrana deaktivována při zpětném nastavení času v opačném směru před začátkem licence. Uživatel si přečetl zprávy, byl šťastný a ochranu pomocí navržené metody vypnul. O pár dní později se tento jeho příběh objevil na tehdy populární bash.org.ru. Od té doby zprávy tohoto druhu již uživatelé nedostávají.

  A nemyslete si, že takové chyby nedělá. Vzpomeňte si na příběh s iOS, který se stal letos, ačkoli od začátku roku uplynuly pouze 3 měsíce ( Poznámka: ano, toto je docela stará přednáška, už dlouho jsem ji chtěl zveřejnit). Telefony se vypnou, pokud nastavíte čas blíže začátku výpočtu času unix. A jak Apple tuto chybu opravil? Zakázali měnit čas dále, než je kritické datum, což NEBYLO opravou problému. Útočníci začali zvedat své Wi-Fi body se jmény, která se běžně vyskytují ve všemožných McDonald's a přes ně přenášejí falešný čas. Zařízení se k takovým bodům automaticky připojila a detekovala NTP servery, ze kterých si vyžádala čas. Apple se jen neujistil, že iOS nepoužívá falešné NTP servery. Tak byl iOS znovu přestavěn.

• Změna národního prostředí systému a jazyka rozhraní. Uživatel má právo stokrát denně změnit jazyk systému a nikdo mu to nemůže zakázat. Úkolem testera je ujistit se, že produkt na to zaprvé správně reaguje (automaticky změní jazyk na požadovaný) a zadruhé vůbec nespadne. Kromě národního prostředí má uživatel právo změnit typ písma a velikosti písma a vybrat si takové, které mu vyhovuje číst. Aplikace by se neměla rozpadnout, pokud uživatel provede rozumné změny.
• tapjaking. Tuto věc jsem zmínil hned na první přednášce. Připomínám, že se jedná o zachycení klepnutí přijatých aktivitou aplikace A, zatímco se uživatel snažil dostat do aplikace B. Jednoduše aktivita aplikace A je transparentní. Vypadá to, že ne bezpečné řešení Google, ale takhle fungují aplikace pro ovládání jasu a teploty barev na zařízeních. Uživatelé považují takové aplikace za pohodlné a protože jim Android umožňuje pracovat bez nich přítomnost kořene, s tím je třeba počítat. Pokud máte například aplikaci, která k autorizaci používá kód nebo řekněme obrázek, musíte použít ochranu proti tapjackingu, například nastavit filterTouchesWhenObscured na hodnotu true.
• Přímé volání do aktivity. Už jsem to řekl, ale zopakujme to. Aktivity jsou jedním ze vstupních bodů do aplikace. Je docela přijatelné mít několik různých aktivit, které mohou volat externí aplikace, nikdy nevíte proč. Půjde o exportované aktivity. Ale může se stát, že pro vyvolání nějaké aktivity jí musíte předat parametry. A aplikace třetí strany je nepřenese. V lepším případě se uživateli zobrazí nějaká křivá obrazovka, v horším se vám aplikace zhroutí. Takže byste neměli, abych tak řekl, zbytečně ukazovat nahý zadek venku. Ve výchozím nastavení je exportovaný příznak nastaven na hodnotu true a pokud jste si jisti, že je externí aplikace nemají volat, měli byste jej nastavit na hodnotu false. Tester musí zkontrolovat, jak se aplikace bude chovat, pokud je její aktivace volána z jiných aplikací.
• Systémový zabiják. Obecně se tomu říká OOM Killer – Out Of Memory Killer. Systém začne KILLING, pokud aplikace, se kterou uživatel komunikuje v tomto konkrétním okamžiku, nemá dostatek paměti pro práci. Vrah samozřejmě není hloupý, řídí se určitými algoritmy a vybírá si cíle (systém například snadno zabije službu na pozadí, ale službu na popředí uloží do posledního; služba popředí je obvykle ta, která nakreslí svou ikonu v oznamovací oblasti, například - přehrávač ), ale to je podstata. Zpravidla na moderní zařízení OOM Killer není příliš násilný. V dnešní době je paměť nastavena na jeden gigabajt a více. To se ale netýká her. Hry jsou tak těžké, žerou tolik paměti, že bez ohledu na to, kolik do toho vložíte, stále to nebude stačit. A obecně platí, že čím více RAM dají do zařízení, tím tlustší budou aplikace a hry budou nejtlustší. Zůstanou přitom stejně fádní a nepotřební.

  Pointa je, že váš produkt zaručeně spadá pod OOM Killer. Vaším úkolem je zajistit, aby z toho nevzešlo nic špatného a produkt se zvedl, jakmile je aplikace ssbbw zablokována systémem (pokud to produkt samozřejmě vyžaduje). A systém to udělá při první příležitosti, nedovolí takovému ssbbw žít v pozadí.
  Dalším poznatkem je, že vaše aplikace by také neměla být ssbbw. Jakékoli úniky musí vývojář zjistit, než napíše skutečný kód. Vaše výkonnostní testy by rozhodně měly mít testovací scénáře, když opice generuje spoustu událostí. Pokud je kód napsán dobře, garbage collector uvolní paměť a systém nezabije proces aplikace. Pokud je vše špatně a aplikace vyteče ze všech trhlin, systém ji zastřelí. Samozřejmě se po tomto znovu vzlétne a už nebude žádná paměť, protože po zabití procesu popelář vše vyčistí, ale pokud návnada ve svém testu ukázala, že aplikace uniká za 15 minut, uživatel zažít tyto úniky ještě později, ale to vše se projeví stejně.

• Velká data. Pokud vaše aplikace pracuje s uživatelskými daty, buďte připraveni na to, že uživatel bez přemýšlení nakrmí něco velmi velkého. Například já jako uživatel plně očekávám, že si klient Youtube moje video stáhne, ať je toto video jakkoli těžké. Očekávám, že se archivátor vejde do jakékoli hloubky archivu, který váží 5x více než celý dostupný RAM zařízení. Tohle je fajn. Pokud vám někdo řekne, že „tak velké soubory nikdo nikdy nenakrmí“, pak s největší pravděpodobností reproduktor prostě není příliš dobrý vývojář.
• Nejhloupější a tím pádem nejvtipnější situace, která způsobí nefunkčnost aplikace, dokonce pád, je jednoduchá rotace obrazovky. Kolik podobných pádů bylo identifikováno během testovací fáze! Zvláště pokud se objeví nějaké vyskakovací okno. Při vyskakovacích oknech začne zkušený tester telefon okamžitě obracet! Stalo se také, že celý tým testoval produkt pouze na telefonech, kde bylo otáčení obrazovky u aplikace zablokováno. A pak, když byly tablety doručeny, se ukázalo, že aplikace na tabletech padaly téměř na každé obrazovce. Ale protože fragmenty. Na obrazovce a na telefonu byla různá rozhraní a nesprávné použití fragmentů vedlo ke smutnému výsledku.
• Dvojité, trojité klepnutí. Z nějakého důvodu si někteří lidé myslí, že nikdo neklepne vícekrát na prvky rozhraní. Ale ne! Dělám! A ne proto, že testuji, ale proto, že to možná mám ve svých rukou starý telefon na Androidu 4.0, který se již téměř nehýbe a jeho obrazovka není příliš citlivá. Nemusí být jasné, zda došlo ke kliknutí nebo ne, a výsledkem je dvojité klepnutí. Ne proto, že jsou „dvojité“ (ve smyslu ne ty, které se dělají s intervalem kratším než jedna sekunda), ale protože jich bylo dva nebo více, když aplikace „přemýšlela“. Například když tvořil seznam mnoha prvků.
• Jedna z pohodlných funkcí Androidu 6, pokud není dostatečně testována, vede k hrozným výsledkům. Do té míry, že jeho použití je v aplikaci výslovně zakázáno, což zatím Google povoluje. Tato funkce - zálohovat a obnovit ze zálohy. Mimochodem, není to novinka, zálohování se objevilo v Androidu 2.2, ale neznám jedinou aplikaci, která by tuto buchtu používala.
  Stvoření samo o sobě záložní kopie a jeho obnova není děsivá. Problémy začínají, pokud produkt používá vazbu na identifikátor zařízení a identifikátor instalace. I v rámci stejného zařízení to může vést k problémům, ale obnovení ze zálohy umožňuje samotný Android na libovolném zařízení se systémem Android 6 na palubě: systém zálohuje aplikace ze zařízení A a uživatel si koupí zařízení B a obnoví je všechny na to. A tyto aplikace fungují současně na dvou zařízeních, i když mají různé identifikátory. Pokud se jedná o aplikaci klient-server, kde veškerá komunikace probíhá pomocí tokenů, je zde spousta problémů.

  Bojovým příkladem je skvělá aplikace Talon for Twitter. Zařízení jsem dlouho neresetoval, a proto nevím, zda autor tuto chybu opravil. Když jsem mu to nahlásil, řekl mi, proč k chybě došlo (i když už vím proč!), ale neřekl, zda chování opraví. Obecně platí, že tato aplikace má jakýsi průvodce instalací, který mluví o možnostech tohoto klienta Twitteru a během cesty vyžaduje potřebná oprávnění. Vše je jasné podle pokynů Google, přímo z poznámek. Když byl průvodce nastavením dokončen a byla přijata potřebná oprávnění, byl na to upozorněn, aby nebylo nutné pokaždé znovu procházet nastavením. A aplikace byla zálohována spolu s tímto příznakem. Spolu s ním byla obnovena. Ačkoli jsou ve výchozím nastavení pro všechny aplikace nového typu (tj. úroveň targetApi >= 23) oprávnění zakázána. Spustíte aplikaci, ale nemůže správně fungovat. Protože neexistuje žádná kontrola dostupnosti oprávnění, všechny kontroly zůstávají v hlavním serveru počáteční nastavení, který se nespustil, protože příznak byl nastaven na „hlavní již bylo předáno“. Po spuštění navíc klient nenačítal tweety, což dalo ránu samotnému Twitteru. Protože zakopaný token nebyl na nové instalaci platný a bylo nutné požádat o nový, a tento požadavek byl také v prvním kroku proveden v průvodci instalací!

• V Androidu, počínaje verzí (pokud mě paměť neklame) 2.2.1, to bylo možné přesunout některá data aplikace na paměťovou kartu. Tato funkce se pomalu začala zabíjet, až jí v Androidu 6 dal Google druhý život a výrazně ji vylepšil. Pokud výrobce zařízení ve svém zvyku v této situaci neporušil chování AOSP, tak jakmile Android detekuje paměťovou kartu, nabídne na výběr, zda ji uživatel občas vytáhne nebo ne. Pokud uživatel řekne, že ji neplánuje deaktivovat, Android naformátuje kartu do své vlastní souborový systém a připojí jej jako součást hlavní paměti, což umožňuje instalaci aplikací tam. A zde je několik úskalí:
• Pokud aplikace používá pevně zakódované cesty, pak je vše ztraceno. Ale tohle je tak nevkus, že to doufám nikdo neudělá.
• Pokud se aplikace při prvním spuštění zeptala systému na cesty a uložila je navždy, pak to bude úplně stejné jako s pevně naprogramovanými

• Jak jsou aplikace aktualizovány, uživatelé získají nové verze z obchodu s aplikacemi a nainstalují je nad stávající. Protože kontrola aktualizace aplikace na novou verzi- povinný skript. V normální situaci vše by mělo být v pořádku, ale když musíte podporovat mnoho konkrétních zařízení s jejich specifickým chováním, formát nastavení se může změnit. To téměř nikdy nevede ke zhroucení, pokud je kód napsán více či méně efektivně a zpracovává různé výjimky. Ale už jen ztráta některých nastavení je špatná. Měli jsme například situaci, kdy uživatelé strávili měsíce vytvářením antispamového seznamu, blokováním čísel taxíků, bank a inkasních služeb a poté, po aktualizaci na novou verzi, byly všechny seznamy ztraceny. Právě proto, že se změnil formát nastavení a právě zde, přesně na tomto místě, nová verze produktu nastavení nenačetla.
• Kromě aktualizace produktu na novou verzi existuje vzácnější, ale mnohem tvrdší možnost - aktualizaci samotného firmwaru pro novou verzi, ale s funkčním produktem. Uvedu dva příklady, z nichž jeden již byl řečeno.
• Obvyklá aktualizace zabezpečení pro Android 5.1, která vzala a zakázala doživotní funkce operačního systému, který aplikace používala
• Po Aktualizace Androidu 4.4 na Androidu 5.0, cesty změněny nainstalované aplikace. Dříve byly nainstalované aplikace uloženy v jedné známé cestě (/data/app/com.package.name.apk). Jeden z našich produktů pro účely interní bezpečnosti kontroluje, ze které cesty je chráněná aplikace přístupná a zda se změnila. Přišla aktualizace na 5.0 a změnily se absolutní cesty pro již nainstalované aplikace (data/app/com.package.name/base.apk). Produkt vydal poplach, že aplikace byla ohrožena. Samozřejmě opraveno.

No, to je zatím vše. Nyní píšu zprávu o problémech specifických pouze pro konkrétní Verze Androidu, pouze pro konkrétní firmware, pouze pro konkrétní zařízení. Takže nevypínejte! Některé už však znáte – jsou popsány přímo v této sérii příspěvků.
Ahoj!

Při testování softwarový produkt Používá se obrovské množství různých typů testů. Nejširší a nejpodrobnější klasifikaci navrhl autor knihy „Testing Dot Com“ Roman Savin. Kombinoval typy testování podle takových charakteristik, jako je objekt, předmět testování, úroveň, pozitivita testování a stupeň automatizace testování. Klasifikace byla doplněna na základě takových zdrojů, jako je kniha Sama Kanera „Testování softwaru“ a online zdroj věnovaný testování „O testování – Testování softwaru“.

Testováním objektu

• · Funkční testování. Funkční testování je dnes jedním z nejčastěji používaných typů testování. Účelem takového testování je zjistit, jak dobře vyvíjený software splňuje požadavky zákazníka z hlediska funkčnosti. Jinými slovy, provádění funkčních testů vám umožňuje ověřit schopnost informační systémřešit uživatelské problémy.
• · Nefunkční testování. Umožňuje zkontrolovat shodu vlastností softwaru se zadanými nefunkčními požadavky. Nefunkční testování je tedy testování všech vlastností programu, které nesouvisí s funkčností systému. Takové vlastnosti mohou být prezentovány charakteristikami z hlediska parametrů, jako jsou:
• - Spolehlivost (schopnost systému reagovat na neočekávané situace).
• - Výkon (schopnost systému pracovat při velkém zatížení).
• - Pohodlí (studium uživatelského pohodlí s aplikací).
• - Škálovatelnost (schopnost škálovat aplikaci vertikálně i horizontálně).
• - Bezpečnost (výzkum možnosti narušení aplikace a odcizení uživatelských dat útočníky).
• - Přenositelnost (schopnost přenést aplikaci na konkrétní sadu platforem)

A mnoho dalších vlastností.

• · Testování uživatelského rozhraní. Jedná se o testování správného zobrazení prvků uživatelského rozhraní na různá zařízení, správnost jejich reakce na uživatele provádějící různé akce a také posouzení očekávaného chování programu jako celku. Takové testování umožňuje vyhodnotit, jak efektivně bude uživatel schopen s aplikací pracovat a jak moc vzhled aplikace odpovídá schváleným dokumentům vytvořeným projektanty. Při provádění testování uživatelského rozhraní je hlavním úkolem testera identifikovat vizuální a strukturální nedostatky v grafickém rozhraní aplikace, ověřit schopnost a snadnost navigace v aplikaci a zajistit, aby aplikace zpracovávala vstup z klávesnice, myši a dalších vstupů. zařízení správně. Testování uživatelského rozhraní je nezbytné, aby se zajistilo, že rozhraní vyhovuje schváleným požadavkům a standardům a že s ním uživatel může pracovat grafické rozhraní aplikací.
• · Testování použitelnosti. Jedná se o testovací metodu, která umožňuje vyhodnotit míru jednoduchosti používání aplikace, rychlost uživatelského učení při práci s programem a také to, jak moc jej uživatelé vyvíjeného produktu považují za srozumitelný a atraktivní v kontextu dané podmínky. Takové testování je nezbytné pro zajištění co nejpozitivnější uživatelské zkušenosti při práci s aplikací.
• · Testování bezpečnosti. Umožňuje identifikovat hlavní zranitelnosti softwaru ve vztahu k různým útokům ze strany vetřelců. Počítačové systémy Poměrně často jsou vystaveny kybernetickým útokům s cílem narušit provoz informačního systému nebo odcizit důvěrná data. Bezpečnostní testování umožňuje analyzovat skutečnou odezvu a efektivitu obranných mechanismů používaných v systému při pokusu o průnik. Během testování zabezpečení se tester pokouší provést stejné akce, jaké by provedl skutečný útočník. Když se tester pokusí hacknout systém, lze použít jakékoli prostředky: útok na systém pomocí speciálních utilit; pokusy zjistit přihlašovací jména a hesla pomocí externích prostředků; DDOS útoky; cílené generování chyb pro zjištění možnosti průniku do systému během procesu jeho obnovy; zneužití známých neopravených systémových zranitelností.
• · Testování instalace. Tímto pojmem se rozumí testování správnosti instalace (instalace) určitého softwarového produktu. Takové testování obvykle probíhá v uměle vytvořených prostředích za účelem zjištění stupně připravenosti softwaru k použití. Hlavní důvody pro provádění takových testů souvisí s potřebou ověřit správné chování softwarového produktu během automatizovaného nasazení nebo aktualizace. Zajištění správné a stabilní instalace softwaru je velmi důležitým faktorem při vytváření softwarového produktu, protože umožňuje uživatelům začít produkt používat rychleji a s menší námahou a zároveň zajišťuje, že se produkt chová stejně správně ve všech testovaných softwarových prostředích.
• · Testování konfigurace. Testování konfigurace je navrženo tak, aby vyhodnotilo výkon softwaru v různých konfiguracích systému. V závislosti na typu testovaného softwarového produktu může testování konfigurace sloužit různým účelům. Obvykle se jedná buď o určení optimální hardwarové konfigurace, která poskytuje dostatečné výkonové parametry pro fungování softwaru, nebo o kontrolu určité hardwarové konfigurace (nebo platformy, která kromě hardwaru zahrnuje software třetích stran nezbytný pro běh programu) pro kompatibilitu s testovaným produktem. Pokud mluvíme o softwaru klient-server, pak se testování konfigurace provádí zvlášť pro server a zvlášť pro klienta. Obvykle při testování kompatibility serveru s určitou konfigurací je úkolem najít optimální konfigurace, protože stabilita a výkon serveru jsou důležité. Zatímco při testování klienta se naopak snaží softwarové nedostatky v jakékoli konfiguraci identifikovat a pokud možno odstranit.
• · Testování spolehlivosti a zotavení z poruch (zátěžové testování). Tento typ testování se poměrně často provádí u softwaru, který pracuje s cennými uživatelskými daty, jejichž nepřetržitý provoz a rychlost zotavení z poruch jsou pro uživatele kritické. Testování selhání a obnova testuje schopnost programu rychle a úspěšně se zotavit ze selhání hardwaru, výpadků sítě nebo kritických chyb v samotném softwaru. To umožňuje posoudit možné následky poruchy a dobu potřebnou pro následnou obnovu systému. Na základě údajů získaných během testování lze posoudit spolehlivost systému jako celku a v případě neuspokojivého výkonu lze přijmout vhodná opatření zaměřená na zlepšení systémů obnovy.
• · Testování lokalizace. Lokalizační testování umožňuje zjistit, jak dobře je produkt přizpůsoben populaci určitých zemí a jak dobře odpovídá jeho kulturním charakteristikám. Typicky se berou v úvahu kulturní a jazykové nuance, konkrétně překlad uživatelského rozhraní, doprovodné dokumentace a souborů do konkrétního jazyka, testuje se také správnost formátů měn, čísel, časů a telefonních čísel.
• · Zátěžové testování. Testování zátěže umožňuje identifikovat maximální počet podobných úloh, které může program provádět paralelně. Nejoblíbenějším účelem zátěžového testování v kontextu klient-server aplikací je odhad maximálního počtu uživatelů, kteří mohou současně využívat služby aplikace.
• · Testování stability. Testování stability prověřuje funkčnost aplikace při dlouhodobém používání při mírné zátěži. V závislosti na typu aplikace jsou stanoveny určité požadavky na dobu nepřetržitého provozu. Testování stability se snaží identifikovat nedostatky aplikace, jako jsou úniky paměti, přítomnost výrazného přepětí zátěže a další faktory, které mohou aplikaci bránit v práci po dlouhou dobu.
• · Testování objemu. Úkolem objemového testování je identifikovat odezvu aplikace a posoudit možné zhoršení provozu softwaru s výrazným nárůstem objemu dat v databázi aplikace. Toto testování obvykle zahrnuje:
• - Měření doby provádění operací souvisejících se získáváním nebo změnou databázových dat při určité intenzitě požadavku.
• - Identifikace závislosti nárůstu provozní doby na objemu dat v databázi.
• - Definice maximální množství uživatelé, kteří jsou schopni současně pracovat s aplikací bez znatelných prodlev z databáze.
• Testování škálovatelnosti. Jedná se o typ testování softwaru určený k testování schopnosti produktu zvětšovat (nebo někdy zmenšovat) určité nefunkční funkce. Některé typy aplikací musí být snadno škálovatelné a zároveň samozřejmě zůstat provozuschopné a vydržet určitou uživatelskou zátěž.

Testování související se změnami

• · Sanity je jedním z typů testování, jehož účelem je prokázat výkon konkrétní funkce nebo modulu v souladu s technickými požadavky uvedenými zákazníkem. Sanitární testování se poměrně často používá k testování některé části programu nebo aplikace, když jsou v ní provedeny určité změny kvůli faktorům prostředí. Tenhle typ testování se obvykle provádí ručně.
• · Kouřové testování je krátká série testů, jejichž účelem je potvrdit, že nainstalovaná aplikace běží a plní funkce po sestavení nového nebo upraveného kódu. Po dokončení testování nejdůležitějších aplikačních segmentů jsou poskytnuty objektivní informace o přítomnosti či nepřítomnosti závad ve fungování testovaných segmentů. Na základě výsledků kouřového testování se rozhodne, zda aplikaci odeslat ke zlepšení nebo je potřeba ji plně otestovat.
• · Regresní testování - testování zaměřené na odhalování chyb v již testovaných oblastech. Regresní testování kontroluje, zda produkt neobsahuje chyby, které se mohly objevit v důsledku přidání nové části programu nebo opravy jiných chyb. Účelem tohoto typu testování je ujistit se, že aktualizace sestavení nebo oprava chyb nepovede k novým chybám.

Podle úrovně testování

• · Testování jednotek (Unit testy). Spočívá v kontrole každého jednotlivého modulu (originálního prvku systému) spuštěním automatizovaných testů v umělém prostředí. Implementace takových testů často využívají různé pahýly a ovladače k ​​simulaci provozu skutečného systému. Automatizované testování jednotek je úplně první příležitostí ke spuštění a kontrole zdrojového kódu. Vytvoření Unit testů pro všechny systémové moduly umožňuje velmi rychle identifikovat chyby v kódu, které se mohou objevit během vývoje.
• · Testování integrace. Jedná se o testování jednotlivých modulů systému na správnou interakci. Hlavním cílem integračního testování je najít defekty a identifikovat nesprávné chování spojené s chybami v interpretaci nebo implementaci interakce mezi moduly.
• · Testování systému. Jedná se o testování programu jako celku, kdy se ověřuje, zda program splňuje uvedené požadavky.
• · Přejímací zkoušky. Jedná se o komplexní test, který zjišťuje skutečnou úroveň připravenosti systému pro použití koncovými uživateli. Testování se provádí na základě sady testovacích scénářů pokrývajících hlavní obchodní operace systému.

Spuštěním kódu

• · Statické testování. Jedná se o identifikaci artefaktů, které se objevují během vývoje softwarového produktu prostřednictvím analýzy zdrojové soubory jako je dokumentace popř programový kód. Takové testování probíhá bez přímého spouštění kódu, kvalita zdrojových souborů a jejich soulad s požadavky se posuzuje ručně nebo pomocí pomocných nástrojů. Statické testování by mělo být provedeno před dynamickým testováním, takže chyby nalezené během fáze statického testování budou levnější. Z pohledu zdrojový kód, statické testování je vyjádřeno v revizi kódu. Obvykle revize kódu samostatné soubory je prováděna po každé změně těchto souborů programátorem, ale samotnou revizi může provádět buď jiný programátor, nebo vedoucí vývojář, nebo jednotlivý zaměstnanec zabývající se revizí kódu. Použití statického testování umožňuje udržovat kvalitu softwaru ve všech fázích vývoje a zkracuje dobu vývoje produktu.
• · Dynamické testování. Na rozdíl od statického testování tento typ testování zahrnuje spuštění zdrojového kódu aplikace. Dynamické testování tedy obsahuje mnoho dalších typů testování, které již byly popsány výše. Dynamické testování vám umožňuje identifikovat chyby v chování programu analýzou výsledků jeho provádění. Ukazuje se, že téměř všechny existující typy testování odpovídají třídě dynamického testování.

Podle zkušebního předmětu

• · Alfa testování. Toto testování se provádí na nejstarších verzích počítačového softwaru (nebo hardwarového zařízení). Alfa testování je téměř vždy prováděno samotnými vývojáři softwaru. Během procesu alfa testování vývojáři aplikací nacházejí a opravují chyby a problémy v programu. Obvykle během testování Alpha dochází k napodobování práce s programem vývojáři na plný úvazek, méně často k tomu dochází skutečnou práci potenciálním uživatelům i zákazníkům s produktem. Alfa testování se zpravidla provádí ve velmi rané fázi vývoje softwaru, ale v některých případech může být použito pro dokončený nebo téměř hotový produkt, například jako akceptační testování.
• · Beta testování. Testování produktu, který je stále ve vývoji. V beta testování je tento produkt zpřístupněn malému počtu uživatelů, aby mohli studovat a hlásit vznikající problémy, se kterými se uživatelé setkávají. Takové testování je nezbytné k nalezení chyb, které vývojáři možná přehlédli. Beta testování se obvykle provádí ve dvou fázích: uzavřené beta testování a otevřené beta testování. Uzavřený beta test testuje na přísně omezeném okruhu vybraných uživatelů. Takovými uživateli mohou být známí vývojářů nebo jejich kolegové, kteří přímo nesouvisejí s vývojem testovaného produktu. Otevřené beta testování se skládá z vytváření a zveřejňování otevřený přístup veřejná beta. V v tomto případě každý uživatel může fungovat jako beta tester. Zpětná vazba z těchto beta testerů se provádí pomocí recenzí na webu a analytických a protokolovacích systémů zabudovaných do programu akce uživatele Tyto systémy jsou potřebné k analýze chování uživatelů a odhalování potíží a chyb, se kterými se setkávají.

Podle pozitivity scénáře

• · Pozitivní testování. Testy s pozitivním scénářem ověřují schopnost programu vykonávat zamýšlenou funkci. Pro takové testování jsou zpravidla vyvíjeny testovací scénáře, jejichž provedení by za normálních provozních podmínek pro software nemělo způsobovat žádné potíže.
• · Negativní testování. K negativnímu testování softwaru dochází ve scénářích, které odpovídají abnormálnímu chování programu. Tyto testy kontrolují správné fungování programu v nouzových situacích. To pomáhá zajistit, aby program produkoval správné chybové zprávy, nepoškodil uživatelská data a obecně se choval správně v situacích, ve kterých není zamýšleno normální chování produktu. Hlavním cílem negativního testování je prověřit odolnost systému vůči různým vlivům, schopnost správně validovat vstupní data a řešit výjimečné situace, které vznikají jak v samotných softwarových algoritmech, tak v obchodní logice.

Podle stupně automatizace

• · Ruční testování. Ruční testování se provádí bez použití přídavných software, umožňuje vám otestovat program nebo web simulací uživatelských akcí. V tomto modelu se tester chová jako uživatel, který sleduje specifické skripty a současně analyzuje výstup programu a celkové chování.
• · Automatizované testování. Takové testování umožňuje prostřednictvím použití dodatečného softwaru pro automatizaci testování výrazně urychlit proces testování. Takový doplňkový software umožňuje sledovat a řídit provádění testů a porovnávat očekávané a skutečné výsledky programu. Podrobněji bude pojednáno později.