Testování softwaru je výzkumný proces, testování softwarového produktu , jehož cílem je ověřit shodu mezi skutečným chováním programu a jeho očekávaným chováním na konečné sadě testů vybraných určitým způsobem ( ISO /IEC TR 19759:2005) [ 1] .
Testování byly dány různé definice v různých časech a v různých zdrojích, včetně:
První softwarové systémy byly vyvíjeny v rámci vědeckovýzkumných programů nebo programů pro potřeby resortů obrany. Testování těchto produktů bylo prováděno přísně formalizovaným způsobem se záznamem všech testovacích postupů, testovacích dat a získaných výsledků. Testování bylo rozděleno do samostatného procesu, který začal po dokončení kódování, ale obvykle jej prováděli stejní pracovníci.
V 60. letech minulého století byl kladen velký důraz na „vyčerpávající“ testování, které by mělo být prováděno pomocí všech cest v kódu nebo všech možných vstupů. Bylo poznamenáno, že za těchto podmínek není úplné testování softwaru možné, protože za prvé je počet možných vstupů velmi velký, za druhé existuje mnoho cest a za třetí je obtížné najít problémy v architektuře a specifikacích. Z těchto důvodů bylo „vyčerpávající“ testování odmítnuto a považováno za teoreticky nemožné.
Na počátku 70. let bylo testování softwaru označováno jako „proces demonstrování správnosti produktu“ nebo „činnost ověřování správného fungování softwaru“. V rodícím se softwarovém inženýrství bylo ověření softwaru označováno jako „důkaz správnosti“. Zatímco koncept byl teoreticky slibný, v praxi byl časově náročný a nebyl dostatečně komplexní. Bylo rozhodnuto, že důkaz správnosti je neefektivní metoda testování softwaru. V některých případech se však prokázání správného fungování používá dodnes, například akceptační zkoušky. V druhé polovině 70. let bylo testování chápáno jako spouštění programu se záměrem najít chyby, nikoli prokázat, že funguje. Úspěšný test je test, který odhalí dříve neznámé problémy. Tento přístup je přímo opačný než ten předchozí. Tyto dvě definice představují „paradox testování“, který je založen na dvou opačných tvrzeních: na jedné straně vám testování umožňuje ujistit se, že produkt funguje dobře, a na druhé straně odhaluje chyby v programech, což ukazuje, že produkt nefunguje. Druhý cíl testování je produktivnější z hlediska zlepšování kvality, protože neumožňuje ignorovat softwarové chyby.
V 80. letech se testování rozšířilo o prevenci defektů. Návrh testu je nejúčinnější známou technikou prevence chyb. Zároveň se začaly vyjadřovat myšlenky, že je potřeba metodika testování, konkrétně, že testování by mělo zahrnovat kontroly v průběhu celého vývojového cyklu, a mělo by jít o řízený proces. Při testování je nutné kontrolovat nejen sestavený program, ale také požadavky, kód, architekturu a samotné testy. „Tradiční“ testování, které existovalo až do počátku 80. let, se týkalo pouze zkompilovaného hotového systému (dnes běžně označovaného jako systémové testování), ale od té doby se testeři zapojují do všech aspektů životního cyklu vývoje. To umožnilo dříve najít problémy v požadavcích a architektuře, a tím zkrátit dobu vývoje a rozpočet. V polovině 80. let se objevily první nástroje pro automatizované testování. Počítač měl být schopen provést více testů než člověk a navíc spolehlivěji. Zpočátku byly tyto nástroje extrémně jednoduché a neuměly psát skripty ve skriptovacích jazycích.
Počátkem 90. let začal pojem „testování“ zahrnovat plánování, navrhování, vytváření, údržbu a provádění testů a testovacích prostředí, a to znamenalo přechod od testování k zajišťování kvality, pokrývající celý cyklus vývoje softwaru. V této době se začaly objevovat různé softwarové nástroje na podporu testovacího procesu: pokročilejší automatizační prostředí s možností vytvářet skripty a generovat sestavy, systémy pro správu testů a software pro zátěžové testování. V polovině 90. let, s rozvojem internetu a rozvojem velkého množství webových aplikací, si začalo získávat zvláštní oblibu „agilní testování“ (obdoba agilních programovacích metodologií).
Existuje několik kritérií, podle kterých je obvyklé klasifikovat typy testování. Obvykle jsou následující:
Podle předmětu testováníU bezplatného softwaru s otevřeným zdrojovým kódem fáze alfa testování charakterizuje funkční obsah kódu a beta testování charakterizuje fázi opravy chyb. Zároveň jsou zpravidla v každé fázi vývoje koncovým uživatelům k dispozici průběžné výsledky práce.
Níže popsané techniky – testování bílé skříňky a testování černé skříňky – předpokládají, že se kód spouští, a rozdíl je pouze v informacích, které má tester k dispozici. V obou případech se jedná o dynamické testování .
Při statickém testování se programový kód nespouští - program je analyzován na základě zdrojového kódu, který je načten ručně nebo analyzován speciálními nástroji. V některých případech se neanalyzuje zdrojový kód, ale přechodný kód (jako je bytecode nebo MSIL kód ).
Statické testování také zahrnuje požadavky na testování , specifikace , dokumentaci .
Po provedení změn v další verzi programu regresní testy potvrdí, že provedené změny neovlivnily výkon zbývajících funkcí aplikace. Regresní testování lze provádět ručně i pomocí nástrojů pro automatizaci testování .
Testeři používají testovací scénáře na různých úrovních: jak při testování komponent, tak při integraci a testování systému. Testovací skripty jsou obvykle psány pro testování komponent, které s největší pravděpodobností selžou, nebo chyba, která není včas nalezena, může být drahá.
V závislosti na přístupu vývojáře testu ke zdrojovému kódu testovaného programu se rozlišuje mezi „ testováním (strategií) bílé skříňky “ a „ testováním (strategií) černé skříňky “.
Při testování bílé skříňky (také nazývané testování průhledné skříňky ) má vývojář testu přístup ke zdrojovému kódu programů a může psát kód, který odkazuje na knihovny testovaného softwaru. To je typické pro testování komponent, kdy se testují pouze části systému. Zajišťuje, že konstrukční prvky jsou do určité míry funkční a stabilní. Testování bílého pole používá metriky pokrytí kódu nebo testování mutací .
Při testování černé skříňky má tester přístup k programu pouze přes stejná rozhraní jako zákazník nebo uživatel, nebo přes externí rozhraní, která umožňují připojení jiného počítače nebo jiného procesu k systému za účelem testování. Testovací komponenta může například virtuálně stisknout klávesy nebo tlačítka myši v testovaném programu pomocí mechanismu procesní komunikace s jistotou, že vše probíhá dobře, že tyto události způsobí stejnou odezvu jako skutečné stisknutí kláves a tlačítek myši. Testování černé skříňky se zpravidla provádí pomocí specifikací nebo jiných dokumentů, které popisují požadavky na systém. Typicky je u tohoto typu testování kritériem pokrytí součet pokrytí struktury vstupních dat , pokrytí požadavků a pokrytí modelu (v testování založeném na modelu ).
Při testování v šedém poli má vývojář testu přístup ke zdrojovému kódu, ale při přímém spouštění testů přístup ke kódu obvykle není vyžadován.
Zatímco „alfa“ a „beta testování“ se týkají fází před uvedením produktu na trh (a také implicitně velikosti testovací komunity a omezení testovacích metod), testování bílé skříňky a černé skříňky označuje způsoby, jakými tester dosáhne cíle.
Beta testování je obecně omezeno na techniky černé skříňky (ačkoli konzistentní podskupina testerů obvykle pokračuje v testování bílé skříňky souběžně s beta testováním). Pojem "beta testování" tedy může označovat stav programu (blíže k vydání než "alfa") nebo může označovat určitou skupinu testerů a proces, který tato skupina provádí. To znamená, že tester může pokračovat v práci na testování white-box, i když je program již "beta", ale v tomto případě není součástí "beta testování".
Pokrytí kódu ukazuje procento zdrojového kódu programu, který byl během testování spuštěn („pokryt“). Podle metod měření, pokrytí operátora, pokrytí podmínek, pokrytí trasy, pokrytí funkcí atd.
| Vývoj softwaru | |
|---|---|
| Proces | |
Koncepty na vysoké úrovni | |
| Pokyny |
|
Vývojové metodiky | |
| Modelky |
|
| Pozoruhodné postavy |
|