Phenquestions
Testování jednotek
Testování jednotek je testování prováděné na jednotlivé funkci, třídě nebo modulu nezávisle na sobě, než testování plně funkčního softwaru. Pomocí rámce pro testování jednotek může programátor vytvářet testovací případy se vstupem a očekávaným výstupem. Když máte stovky, tisíce nebo desítky tisíc testovacích případů jednotek pro velký softwarový projekt, zajistíte, že všechny jednotlivé jednotky budou fungovat podle očekávání, jak budete pokračovat ve změně kódu. Při změně jednotky, která má testovací případy, je třeba prostudovat testovací případy pro daný modul a určit, zda jsou potřeba nové testovací případy, změnil se výstup nebo lze odebrat aktuální testovací případy. Vytvoření velkého množství testů jednotek je nejjednodušší způsob, jak dosáhnout vysokého pokrytí testovacích případů pro softwarový kódový základ, ale nezajistí, aby finální produkt fungoval jako systém podle očekávání.
Funkční testování
Funkční testování je nejběžnější formou testování. Když lidé odkazují na testování softwaru bez větších podrobností, mají často na mysli funkční testování. Funkční testování zkontroluje primární funkce softwaru podle očekávání. K popisu všech funkčních testovacích případů, které budou testovány, lze napsat testovací plán, který odpovídá hlavním rysům a schopnostem softwaru. Testování primární funkce bude „šťastná cesta “ testování, které se nepokouší software rozbít nebo jej použít v jakýchkoli náročných scénářích. To by mělo být absolutní minimum testování jakéhokoli softwarového projektu.
Testování integrace
Po testování jednotky a funkčním testování může existovat několik modulů nebo celý systém, který ještě nebyl testován jako celek. Nebo mohou existovat komponenty, které jsou do značné míry nezávislé, ale občas se používají společně. Jakékoli časové komponenty nebo moduly jsou testovány nezávisle, ale ne jako celý systém, pak by mělo být provedeno integrační testování, aby se ověřily funkce komponent společně jako funkční systém podle požadavků a očekávání uživatele.
Stresové testování
Přemýšlejte o zátěžovém testování, jako byste testovali raketoplán nebo letadlo. Co to znamená dát váš software nebo systém pod „STRES“? Stres není nic jiného než intenzivní zátěž konkrétního typu, která s největší pravděpodobností rozbije váš systém. Může to být podobné jako „Testování zátěže“ ve smyslu toho, že váš systém bude mít vysokou úroveň souběžnosti s mnoha uživateli, kteří do systému přistupují. Zdůraznění systému by se ale mohlo stát i na jiných vektorech. Například spuštění firmwaru na hardwarové součásti, když došlo k fyzickému poškození hardwaru a pracuje v degradovaném režimu. Stres je jedinečný pro všechny typy softwaru a systémy a návrh zátěžových testů by měly být vzaty v úvahu, jaké přirozené nebo nepřirozené příčiny s největší pravděpodobností váš software nebo systém stresují.
Testování zátěže
Zátěžové testování je specifický typ zátěžového testování, jak je popsáno výše, kdy je automatizováno velké množství souběžných připojení a přístupů uživatelů, aby se generovala simulace účinku velkého počtu autentických uživatelů přistupujících k vašemu softwarovému systému současně. Cílem je zjistit, kolik uživatelů může přistupovat k vašemu systému současně, aniž by došlo k poškození vašeho softwarového systému. Pokud váš systém snadno zvládne normální provoz 10 000 uživatelů, co se stane, pokud se váš web nebo software stane virálním a získá 1 milion uživatelů? Bude to nečekané "ZATÍŽENÍ" rozbít váš web nebo systém? Testování zátěže to bude simulovat, takže vám budoucí nárůst uživatelů vyhovuje, protože víte, že váš systém zvládne zvýšené zatížení.
Testování výkonu
Lidé mohou být naprosto frustrovaní a zoufalí, když software nesplňuje jejich výkonnostní požadavky. Výkon obecně znamená, jak rychle lze dokončit důležité funkce. Čím složitější a dynamičtější jsou funkce v systému k dispozici, tím důležitější a nejzřetelnější je testování jeho výkonu, vezměme si základní příklad, operační systém Windows nebo Linux. Operační systém je velmi složitý softwarový produkt a provádění testování výkonu na jeho systému může zahrnovat rychlost a načasování funkcí, jako je Bootup, instalace aplikace, hledání souboru, spuštění výpočtů na GPU a / nebo jakékoli jiné miliony akcí, které lze provést. Při výběru případů testování výkonu je třeba postupovat opatrně, aby se zajistilo, že budou testovány důležité a pravděpodobné nesprávné funkce.
Testování škálovatelnosti
Testování na vašem notebooku je dobré, ale ne dost dobré, když budujete sociální síť, e-mailový systém nebo superpočítačový software. Pokud má být váš software nasazen na 1 000 serverech, vše funguje unisono, pak testování, které provedete lokálně v jednom systému, neodhalí chyby, ke kterým dojde při nasazení softwaru „V měřítku“ na stovky tisíc instancí. Ve skutečnosti vaše testování pravděpodobně nikdy nebude možné spustit v plném rozsahu před vydáním do výroby, protože by bylo příliš nákladné a nepraktické vybudovat testovací systém s 1000 servery, které stojí miliony dolarů. Proto se testování škálovatelnosti provádí na více serverech, ale obvykle ne na plný počet produkčních serverů, aby se pokusily odhalit některé vady, které by mohly být nalezeny, protože vaše systémy jsou používány na větší infrastruktuře.
Testování statické analýzy
Statická analýza je testování, které se provádí kontrolou softwarového kódu bez jeho skutečného spuštění. Chcete-li provést statickou analýzu, obecně byste použili nástroj, existuje mnoho, jedním slavným nástrojem je Coverity. Před vydáním softwaru lze snadno provést statickou analýzu a v kódu můžete najít mnoho problémů s kvalitou, které lze vyřešit před vydáním. Naleznete chyby paměti, chyby zpracování datových typů, dereference nulového ukazatele, neinicializované proměnné a mnoho dalších vad. Jazyky jako C a C ++ velmi těží ze statické analýzy, protože jazyky poskytují programátorům velkou svobodu výměnou za velkou sílu, ale také to může způsobit velké chyby a chyby, které lze najít pomocí testování statické analýzy.
Testování vstřikování chyb
Některé chybové podmínky je velmi obtížné simulovat nebo spouštět, proto lze software navrhnout tak, aby uměle vnesl problém nebo závadu do systému, aniž by k závadě došlo přirozeně. Účelem testování vstřikování chyb je zjistit, jak software zvládá tyto neočekávané chyby. Reaguje elegantně na situaci, havaruje nebo produkuje neočekávané a nepředvídatelné problematické výsledky? Řekněme například, že máme bankovní systém a existuje modul pro interní převod finančních prostředků z ÚČTU A na ÚČET B. Tato operace přenosu je však volána až poté, co systém již před vyvoláním operace přenosu ověřil, že tyto účty existovaly. I když předpokládáme, že oba účty existují, operace přenosu má případ selhání, kdy jeden cílový nebo zdrojový účet neexistuje, a že může vyvolat chybu. Protože za normálních okolností tuto chybu nikdy nedostaneme kvůli předběžnému testování vstupů, abychom ověřili chování systému, když se přenos nezdaří kvůli neexistujícímu účtu, vložíme falešnou chybu do systému, který vrátí neexistující účet pro přenos a otestujte, jak v takovém případě reaguje zbytek systému. Je velmi důležité, aby byl kód pro vkládání chyb k dispozici pouze ve scénářích testování a nebyl uvolněn do výroby, kde by mohl způsobit zmatek.
Testování přetečení paměti
Při používání jazyků jako C nebo C ++ má programátor velkou zodpovědnost za přímé adresování paměti, což může v případě chyby způsobit závažné chyby v softwaru. Například pokud je ukazatel nulový a dereferencovaný, dojde k chybě softwaru. Pokud je objekt přidělen paměti a poté je zkopírován řetězec přes paměťový prostor objektu, může odkazování na objekt způsobit selhání nebo dokonce nespecifikované nesprávné chování. Proto je zásadní použít nástroj k pokusu o zachycení chyb přístupu k paměti v softwaru, který používá jazyky jako C nebo C ++, které by mohly mít tyto potenciální problémy. Mezi nástroje, které tento typ testování umí, patří Open Source Valgrind nebo proprietární nástroje jako PurifyPlus. Tyto nástroje mohou zachránit den, když není jasné, proč software havaruje nebo se chová špatně, a přímo směřovat na místo v kódu, který má chybu. Úžasné, správně?
Testování hraničních případů
Je snadné dělat chyby v kódování, když se nacházíte na hranici, která se nazývá. Například bankomat říká, že si můžete vybrat maximálně 300 $. Představte si tedy, že kodér při vytváření tohoto požadavku přirozeně napsal následující kód:
Pokud (poz < 300)startWithdrawl ()
jiný
chyba („Můžete vybrat% s“, částka);
Vidíte chybu?? Uživatel, který se pokusí vybrat 300 $, obdrží chybu, protože není menší než 300 $. Toto je chyba. Proto se hraniční testování provádí přirozeně. Hranice požadavku pak zajistí, aby software na obou stranách hranice i hranice fungoval správně.
Fuzz testování
Vysokorychlostní generování vstupu do softwaru může vyprodukovat co nejvíce možných kombinací vstupů, i když jsou tyto kombinace vstupů naprosto nesmyslné a nikdy by nebyly dodány skutečným uživatelem. Tento typ testování fuzz může najít chyby a chyby zabezpečení, které nebyly nalezeny jinými prostředky kvůli vysokému objemu vstupů a scénářů testovaných rychle bez ručního generování testovacích případů.
Průzkumné testování
Zavřete oči a představte si, co znamená slovo „Prozkoumat“. Pozorujete a zkoumáte systém, abyste zjistili, jak skutečně funguje. Představte si, že dostanete novou stolní židli na dobírku a má 28 dílů, vše v samostatných plastových sáčcích bez pokynů. Musíte prozkoumat svůj nový příjezd, abyste zjistili, jak funguje a jak je sestaven. S tímto duchem se můžete stát průzkumným testerem. Nebudete mít dobře definovaný plán testů testovacích případů. Prozkoumáte a prozkoumáte svůj software a hledáte věci, díky nimž řeknete úžasné slovo: „ZAJÍMAVÉ!“. Naučíte se dále zkoumat a najít způsoby, jak rozbít software, na který designéři nikdy nemysleli, a poté doručit zprávu, která podrobně popisuje řadu špatných předpokladů, chyb a rizik v softwaru. Více se o tom dozvíte v knize Prozkoumejte to.
Penetrační testování
Ve světě zabezpečení softwaru je penetrační testování jedním z hlavních prostředků testování. Všechny systémy, ať už biologické, fyzické nebo softwarové, mají hranice a hranice. Účelem těchto hranic je umožnit do systému přístup pouze konkrétním zprávám, osobám nebo komponentám. Přesněji řečeno, pojďme uvažovat o online bankovním systému, který pro vstup na web používá ověřování uživatelů. Pokud lze web hacknout a vstoupit do backendu bez řádného ověřování, jedná se o penetraci, kterou je třeba chránit před. Cílem penetračního testování je použít známé a experimentální techniky k obejití běžné bezpečnostní hranice softwarového systému nebo webu. Penetrační testování často zahrnuje kontrolu všech portů, které naslouchají a snaží se vstoupit do systému přes otevřený port. Mezi další běžné techniky patří vkládání SQL nebo prolomení hesla.
Regresní testování
Poté, co máte pracovní software nasazený v terénu, je důležité zabránit zavádění chyb do funkčnosti, která již fungovala. Účelem vývoje softwaru je zvýšit kapacitu vašeho produktu, zavést chyby nebo způsobit, že staré funkce přestanou fungovat, což se nazývá REGRESE. Regrese je chyba nebo vada, která byla zavedena, když dříve funkce fungovala podle očekávání. Nic nemůže zničit pověst vašeho softwaru nebo značky rychleji, než když do svého softwaru vložíte regresní chyby a necháte tyto chyby po vydání najít skutečným uživatelům.
Regresní testovací případy a testovací plány by měly být postaveny na základních funkcích, které musí pokračovat v práci, aby se zajistilo, že uživatelé mají s vaší aplikací dobré zkušenosti. Všechny klíčové funkce vašeho softwaru, které uživatelé očekávají, že budou fungovat určitým způsobem, by měli mít případ regresního testu, který lze provést, aby se zabránilo narušení funkčnosti nového vydání. Může to být kdekoli od 50 do 50 000 testovacích případů, které pokrývají základní funkce vašeho softwaru nebo aplikace.
Testování půlení zdrojového kódu
Do softwaru byla zavedena chyba, ale není zřejmé, která verze vydání novou chybu zavedla. Představte si, že od posledního známého času, kdy software pracoval bez chyby, existovalo 50 softwarových revizí, až do současnosti, kdy ..
Testování lokalizace
Představte si aplikaci počasí, která zobrazuje aktuální a předpokládané počasí ve vaší lokalitě a také popis povětrnostních podmínek. První částí testování lokalizace je zajistit správné zobrazení správného jazyka, abecedy a znaků v závislosti na geolokaci uživatele. Aplikace ve Velké Británii by měla být zobrazena v angličtině se znaky latinky; stejná aplikace v Číně by měla být zobrazena čínskými znaky v čínském jazyce. Když bude provedeno složitější testování lokalizace, bude s aplikací komunikovat širší okruh lidí z různých geolokací.
Testování přístupnosti
Někteří občané v naší komunitě mají zdravotní postižení, a proto mohou mít potíže s používáním vytvářeného softwaru, proto se provádí testování přístupnosti, aby se zajistilo, že populace se zdravotním postižením budou mít i nadále přístup k funkcím systému. Pokud například předpokládáme, že 1% populace je barvoslepý, a naše softwarové rozhraní předpokládá, že uživatelé dokážou rozlišovat mezi červenou a zelenou barvou, ale jedinci s barevnou slepotou NELZE rozlišovat. Proto bude dobře softwarové rozhraní obsahovat další narážky nad barvu, které naznačují význam. Do testování přístupnosti softwaru by byly zahrnuty i další scénáře kromě testování barevné slepoty, například úplná vizuální slepota, hluchota a mnoho dalších scénářů. Kvalitní softwarový produkt by měl být přístupný pro maximální procento potenciálních uživatelů.
Testování upgradu
Jednoduché aplikace v telefonu, operační systémy jako Ubuntu, Windows nebo Linux Mint a software provozující jaderné ponorky vyžadují časté upgrady. Samotný proces upgradu by mohl zavést chyby a vady, které by při nové instalaci neexistovaly, protože stav prostředí byl odlišný a proces zavádění nového softwaru nad starý mohl zavést chyby. Vezměme si jednoduchý příklad, máme notebook se systémem Ubuntu 18.04 a chceme upgradovat na Ubuntu 20.04. Jedná se o jiný proces instalace operačního systému než přímé čištění pevného disku a instalace Ubuntu 20.04. Proto po instalaci softwaru nebo některé z jeho odvozených funkcí nemusí fungovat 100% podle očekávání nebo stejně, jako když byl software nainstalován čerstvě. Nejprve bychom tedy měli zvážit testování samotného upgradu v mnoha různých případech a scénářích, abychom zajistili dokončení upgradu. A pak musíme také zvážit testování skutečného systému po upgradu, abychom se ujistili, že software byl položen a fungoval podle očekávání. Neopakovali bychom všechny testovací případy čerstvě nainstalovaného systému, což by byla ztráta času, ale s našimi znalostmi systému pečlivě promyslíme, co by se mohlo během aktualizace rozbít a strategicky přidat testovací případy pro tyto funkce.
Testování černé a bílé krabice
Černá skříňka a bílá skříňka jsou méně konkrétní metodiky testování a více typů kategorizace testování. V podstatě testování černé skříňky, které předpokládá, že tester neví nic o vnitřním fungování softwaru a sestaví testovací plán a testovací případy, které se pouze podívají na systém zvenčí, aby ověřily jeho funkci. Testování bílé skříňky provádějí softwaroví architekti, kteří rozumějí vnitřnímu fungování softwarového systému a navrhují případy se znalostí toho, co by se mohlo, mělo, mělo a pravděpodobně rozbije. Při testování černé i bílé krabice je pravděpodobné, že najdou různé typy vad.
Blogy a články o testování softwaru
Testování softwaru je dynamické pole a mnoho zajímavých publikací a článků, které aktualizují komunitu o nejmodernějším myšlení o testování softwaru. Všichni můžeme těžit z těchto znalostí. Zde je ukázka zajímavých článků z různých zdrojů blogů, které byste chtěli sledovat:
- 7 tipů, které je třeba dodržet před testováním bez požadavků; http: // www.testovací deníky.com /
- 60 nejlepších automatizačních testovacích nástrojů: Průvodce seznamem Ultimate; https: // testguild.com /
- Open Source Database Testing Tools; https: // www.softwarový testovací časopis.com /
- 100% pokrytí testu jednotky nestačí; https: // www.lepkavé mysli.com /
- Šupinaté testy na Googlu a jak je zmírňujeme; https: // testování.googleblog.com /
- Co je regresní testování? ; https: // test.io / blog /
- 27 nejlepších rozšíření pro Chrome pro vývojáře v roce 2020; https: // www.lambdatest.com /
- 5 klíčových kroků testování softwaru, které by měl provádět každý technik; https: // techbeacon.com /
Produkty pro testování softwaru
Většinu hodnotných testovacích úkolů lze automatizovat, takže by nemělo být překvapením, že používání nástrojů a produktů k provádění nesčetných úkolů zajišťování kvality softwaru je dobrý nápad. Níže uvádíme seznam důležitých a vysoce cenných softwarových nástrojů pro testování softwaru, které můžete prozkoumat a zjistit, zda mohou pomoci.
JUnit
Pro testování softwaru založeného na jazyce Java poskytuje JUnit komplexní testovací sadu pro testování jednotek a funkcí kódu, který je přátelský k prostředí Java.
Selen
Pro testování webových aplikací poskytuje Selenium schopnost automatizovat interakce s webovými prohlížeči, včetně testování kompatibility mezi prohlížeči. Toto je přední testovací infrastruktura pro automatizaci testování webu.
Okurka
Rámec testování založený na chování umožňuje podnikovým uživatelům, produktovým manažerům a vývojářům vysvětlit očekávané funkce v přirozeném jazyce a poté toto chování definovat v testovacích případech. Díky tomu jsou čitelnější testovací případy a jasné mapování na očekávané funkce uživatele.
Očistit
Najděte úniky paměti a poškození paměti za běhu spuštěním softwaru s integrovanou instrumentací Purify Plus, která sleduje využití paměti a upozorňuje na chyby v kódu, které není snadné najít bez instrumentace.
Valgrind
Open-source nástroje, které spustí váš software a umožní vám s ním pracovat a zároveň upozorňovat na chybovou zprávu o chybách kódování, jako jsou úniky paměti a poškození. Není třeba překompilovat nebo přidat instrumentaci do procesu kompilace, protože Valgrind má inteligenci dynamicky porozumět vašemu strojovému kódu a bez problémů vkládat instrumentaci, aby našel chyby kódování a pomohl vám vylepšit váš kód.
Krytí
Nástroj statické analýzy, který ve vašem softwaru najde chyby kódování ještě předtím, než svůj kód zkompilujete a spustíte. Coverity může najít chyby zabezpečení, porušení konvencí kódování i chyby a defekty, které váš kompilátor nenajde. Naleznete mrtvý kód, neinicializované proměnné a tisíce dalších typů vad. Je důležité vyčistit váš kód statickou analýzou, než jej vydáte do výroby.
JMeter
Open-source framework pro testování výkonu orientovaný na vývojáře založené na Javě, odtud název J. Testování webových stránek je jedním z hlavních případů použití JMeteru kromě testování výkonu databází, poštovních systémů a mnoha dalších serverových aplikací.
Metasploit
Pro zabezpečení a penetrační testování je Metasploit obecný rámec s tisíci funkcí a schopností. Pomocí interakční konzoly získáte přístup k předkódovaným exploitům a pokusíte se ověřit zabezpečení vaší aplikace.
Akademický výzkum v oblasti testování softwaru
- Výzkumná skupina pro testování University of Sheffield
- Laboratoř ověřování a ověřování softwaru University of Kentucky
- Výzkumná skupina pro testování softwaru na státní univerzitě v Severní Dakotě
- Inteligentní laboratoř pro testování systému; České vysoké učení technické v Praze
- NASA: Jon McBride Software Testing and Research (JSTAR)
- McMaster University; Laboratoř pro výzkum kvality softwaru
- Ontario Tech University; Laboratoř pro výzkum kvality softwaru
- University of Texas @ Dallas; STQA
Závěr
Role softwaru ve společnosti stále roste a zároveň se světový software stává složitějším. Aby svět fungoval, musíme mít metody a strategie pro testování a ověřování softwaru, který vytváříme prováděním funkcí, které má vykonávat. Pro každý složitý softwarový systém by měla být zavedena testovací strategie a plán testování, aby bylo možné i nadále ověřovat funkčnost softwaru, protože se stále zlepšuje a poskytuje svou funkci.
