20. Ověřování a kvalifikace software
Verifikace a validace odkazuje na procesy ověřování a kontroly, které ověřují, že software odpovídá jeho specifikaci a požadavkům zákazníka. Ověření a kvalifikace pokrývá celé životní cyklus Software - začínají ve fázi analýzy požadavků a končí ověřením programového kódu ve fázi testování hotového softwarového systému.
Ověření a atest není totéž, i když je snadné je zaměnit. Stručně, rozdíl mezi nimi lze definovat takto:
Verifikace odpovídá na otázku, zda je systém správně navržen;
Certifikace odpovídá na otázku, zda systém funguje správně.
Verifikace podle těchto definic kontroluje, zda software odpovídá specifikaci systému, zejména funkčním a nefunkčním požadavkům. Certifikace – více obecný proces. Během ověřování se musíte ujistit, že softwarový produkt splňuje očekávání zákazníka. Validace se provádí po ověření s cílem zjistit, jak systém splňuje nejen specifikaci, ale také očekávání zákazníka.
Jak již bylo zmíněno dříve, ověřování systémových požadavků je velmi důležité v raných fázích vývoje softwaru. V požadavcích se často vyskytují chyby a opomenutí; v takových případech konečný produkt pravděpodobně nebude splňovat očekávání zákazníka. Validace požadavků však samozřejmě nemůže odhalit všechny problémy ve specifikaci požadavků. Někdy se mezery a chyby v požadavcích odhalí až po dokončení implementace systému.
Procesy ověřování a validace používají dvě hlavní techniky pro kontrolu a analýzu systémů.
1. Kontrola softwaru. Analýza a ověření různých reprezentací systému, jako je dokumentace specifikace požadavků, architektonická schémata nebo zdrojový kód programu. Kontrola se provádí ve všech fázích procesu vývoje softwarového systému. Souběžně s kontrolou lze provádět automatickou analýzu zdrojového kódu programů a souvisejících dokumentů. Inspekce a automatizovaná analýza jsou statické metody ověřování a validace, protože nevyžadují spustitelný systém.
2. Testování softwaru. Spouštění spustitelného kódu s testovacími daty a zkoumání výstupu a výkonu softwarový produkt pro kontrolu správné funkce systému. Testování je dynamická metoda ověřování a ověřování, protože je aplikována na běžící systém.
Na Obr. Obrázek 20.1 ukazuje místo kontroly a testování v procesu vývoje softwaru. Šipky označují fáze vývojového procesu, kde lze tyto metody použít. Podle tohoto schématu lze provádět kontrolu ve všech fázích procesu vývoje systému a testování - když je vytvořen prototyp nebo spustitelný program.
Kontrolní metody zahrnují: kontrolu programu, automatickou analýzu zdrojového kódu a formální ověření. Statické metody však mohou pouze kontrolovat shodu programů se specifikací, nelze je použít ke kontrole správného fungování systému. Navíc nefunkční charakteristiky jako výkon a spolehlivost nelze testovat statickými metodami. Proto se pro vyhodnocení nefunkčních charakteristik provádí testování systému.
Rýže. 20.1. Statické a dynamické ověřování a atestace
Navzdory rozšířenému používání kontroly softwaru je testování stále převládající metodou ověřování a certifikace. Testování je ověření chodu programů s daty podobnými skutečným, které budou zpracovány za provozu systému. Přítomnost závad a nesrovnalostí s požadavky v programu se zjišťuje zkoumáním výstupních dat a identifikací anomálních mezi nimi. Testování se provádí během implementační fáze systému (pro ověření, že systém splňuje očekávání vývojářů) a po dokončení jeho implementace.
V různých fázích procesu vývoje softwaru, různé druhy testování.
1. Testování defektů vedeny za účelem zjištění nesrovnalostí mezi programem a jeho specifikací, které jsou způsobeny chybami nebo závadami v programech. Tyto testy jsou navrženy tak, aby odhalovaly chyby v systému, a ne aby simulovaly jeho provoz.
2. Statistické testování vyhodnocuje výkon a spolehlivost programů a také provoz systému v různých provozních režimech. Testy jsou navrženy tak, aby napodobovaly skutečný provoz systému s reálnými vstupními daty. Spolehlivost systému je hodnocena počtem poruch zaznamenaných při práci programů. Výkon je hodnocen měřením celkové doby provozu a doby odezvy systému při zpracování testovacích dat.
Hlavním účelem ověřování a kvalifikace je ujistit se, že systém je „vhodný pro daný účel“. Vhodnost softwarového systému pro zamýšlený účel neznamená, že by měl být absolutně bez chyb. Systém by spíše měl být přiměřeně vhodný pro účely, pro které byl určen. Požadované platnost shody závisí na účelu systému, očekávání uživatelů a tržních podmínkách pro softwarové produkty.
1. Účel softwaru.Úroveň spolehlivosti shody závisí na tom, jak kritický je vyvinutý software podle určitých kritérií. Například úroveň spolehlivosti systémů kritických pro bezpečnost by měla být výrazně vyšší než stejná úroveň spolehlivosti prototypů. softwarové systémy je vyvíjen, aby demonstroval některé nové nápady.
2. Očekávání uživatelů. Se smutkem je třeba poznamenat, že v současné době má většina uživatelů nízké nároky na software. Uživatelé jsou tak zvyklí na poruchy, ke kterým dochází při běhu programů, že je to nepřekvapí. Jsou ochotni tolerovat selhání systému, pokud výhody jeho používání převažují nad nevýhodami. Od počátku 90. let však tolerance uživatelů k poruchám softwarových systémů postupně klesá. V poslední době je vytváření nespolehlivých systémů téměř nepřijatelné, a tak společnosti zabývající se vývojem softwaru musí věnovat verifikaci a validaci softwaru stále více pozornosti.
3. Podmínky na trhu se softwarem. Při hodnocení softwarového systému musí prodávající znát konkurenční systémy, cenu, kterou je kupující ochoten za systém zaplatit, a očekávanou dobu uvedení tohoto systému na trh. Pokud má vývojářská společnost více konkurentů, je nutné určit datum vstupu systému na trh před ukončením plného testování a ladění, v opačném případě mohou konkurenti vstoupit na trh jako první. Pokud zákazníci nejsou ochotni nakupovat software za vysokou cenu, mohou být ochotni tolerovat více selhání systému. Při stanovení nákladů na proces ověřování a kvalifikace je třeba vzít v úvahu všechny tyto faktory.
Chyby jsou v systému zpravidla nalezeny při ověřování a atestaci. V systému se provádějí změny za účelem opravy chyb. Tento proces ladění obvykle integrován s dalšími ověřovacími a atestačními procesy. Nicméně testování (nebo obecněji verifikace a validace) a ladění jsou různé procesy, které mají různé cíle.
1. Verifikace a validace je proces zjišťování závad v softwarovém systému.
2. Ladění - proces lokalizace defektů (chyb) a jejich opravy (obr. 20.2).
Rýže. 20.2. Proces ladění
Neexistují žádné jednoduché metody pro ladění programů. Zkušení debuggerové najdou chyby porovnáním testovacích výstupních vzorů s výstupem testovaných systémů. Lokalizace chyby vyžaduje znalost typů chyb, výstupních vzorů, programovacího jazyka a procesu programování. Znalost procesu vývoje softwaru je velmi důležitá. Ladicí programy jsou si vědomy nejběžnějších programovacích chyb (jako je zvýšení čítače). Bere také v úvahu chyby, které jsou typické pro určité programovací jazyky, například ty spojené s používáním ukazatelů v jazyce C.
Lokalizace chyb v kódu programu není vždy jednoduchý proces, protože chyba se nemusí nutně nacházet poblíž bodu v kódu programu, kde došlo k havárii. Aby izoloval chyby, debugger vyvíjí další softwarové testy, které pomáhají identifikovat zdroj chyby v programu. Možná budete muset ručně sledovat provádění programu.
Interaktivní ladicí nástroje jsou součástí sady nástrojů jazykové podpory, které jsou integrovány se systémem kompilace kódu. Poskytují speciální prostředí pro provádění programu, jehož prostřednictvím můžete přistupovat k tabulce identifikátorů a odtud k hodnotám proměnných. Uživatelé často řídí provádění programu způsobem krok za krokem, postupným přecházením od příkazu k příkazu. Po provedení každého příkazu jsou zkontrolovány hodnoty proměnných a identifikovány možné chyby.
Chyba nalezená v programu je opravena, poté je nutné program znovu zkontrolovat. Chcete-li to provést, můžete znovu zkontrolovat program nebo zopakovat předchozí test. Opakované testování se používá k zajištění toho, aby změny provedené v programu nezanesly do systému nové chyby, protože v praxi se vysoké procento „oprav chyb“ buď nedokončí úplně, nebo do programu zavedou nové chyby.
V zásadě je nutné po každé opravě spouštět všechny testy znovu při retestování, ale v praxi je tento přístup příliš drahý. Proto se při plánování procesu testování zjišťují závislosti mezi částmi systému a pro každou část jsou přiřazeny testy. Poté je možné sledovat prvky programu pomocí speciálních testovacích případů (řídících dat) vybraných pro tyto prvky. Pokud jsou zdokumentovány výsledky trasování, pak lze k testování změněného programového prvku a jeho závislých komponent použít pouze podmnožinu celkové sady testovacích dat.
Účelem tohoto kurzu je poskytnout komplexní pohled na proces ověřování softwaru. Předmětem diskuse jsou různé přístupy a metody používané v oblasti verifikace a zejména testování softwaru. Předpokládá se, že vyvíjený software je součástí většího společný systém. Takový systém zahrnuje hardwarové, informační a organizační (lidský uživatel, lidský operátor atd.) komponenty vyvinuté případně různými týmy. Proto jsou potřeba vývojové dokumenty, které definují požadavky na různé součásti systému a pravidla pro jejich interakci. Kromě toho se předpokládá, že selhání systému mohou vést k důsledkům té či oné závažnosti, proto je při vývoji softwaru úsilí vynaložené na identifikaci skrytých defektů nezbytné a oprávněné. Především se jedná o prostředky a postupy ověřování softwaru. Kurz obsahuje sérii praktických cvičení, která na příkladu jednoduchého systému ilustrují techniky a metody verifikace softwaru v prostředí Microsoft Visual Studio 2005 Team Edition for Software Testers. Tato publikace je součástí Curriculum Library, kterou vyvíjí program MSDN Academic Alliance (MSDN AA) Academic Collaboration Program.
Níže uvedený text je automaticky extrahován z původního dokumentu PDF a je určen pouze pro účely náhledu.
Obrázky (obrázky, vzorce, grafy) chybí.
Rýže. 7 Testování, ověřování a validace Verifikace softwaru je obecnější pojem než testování. Účelem ověření je dosáhnout ujištění, že ověřovaný objekt (požadavky nebo programový kód) odpovídá požadavkům, je implementován bez nezamýšlených funkcí a splňuje specifikace návrhu a normy. Proces ověřování zahrnuje inspekce, testování kódu, analýzu výsledků testů, generování a analýzu zpráv o problémech. Obecně se tedy uznává, že proces testování je nedílnou součástí ověřovacího procesu, stejný předpoklad platí i v tomto školení. Validace softwarového systému je proces, jehož účelem je prokázat, že v důsledku vývoje systému jsme dosáhli cílů, kterých jsme jeho používáním plánovali dosáhnout. Jinými slovy, validace je ověření souladu systému s očekáváním zákazníka. Problémy související s validací jsou mimo rozsah tohoto výcvikový kurz a představují samostatné zajímavé téma pro studium. Pokud se podíváte na tyto tři procesy z hlediska otázky, na kterou odpovídají, pak testování odpovídá na otázku "Jak se to dělá?" nebo "Splňuje chování vyvinutého programu požadavky?" Ověření - "Co bylo provedeno?" nebo "Splňuje vyvinutý systém požadavky?" a ověření je "Udělal to, co má?" nebo "Splňuje vyvinutý systém očekávání zákazníka?". 1.7. Dokumentace vytvořená v různých fázích životního cyklu K synchronizaci všech fází vývoje dochází pomocí dokumentů, které se v každé fázi vytvářejí. Dokumentace přitom vzniká jak v přímém segmentu životního cyklu - při vývoji softwarového systému, tak ve zpětném - při jeho ověřování. Pokusme se na příkladu životního cyklu ve tvaru V vysledovat, jaké typy dokumentů jsou na každém ze segmentů vytvořeny a jaké vztahy mezi nimi existují (obr. 8). Výsledkem fáze vývoje požadavků na systém jsou formulované požadavky na systém - dokument popisující obecné principy fungování systému, jeho interakci s " životní prostředí» - uživatelé systému, jakož i software a hardware zajišťující jeho provoz. Obvykle se souběžně s požadavky na systém vytváří plán ověřování a definuje se strategie ověřování. Tyto dokumenty definují obecný přístup k tomu, jak bude testování prováděno, jaké metodiky budou aplikovány a jaké aspekty budoucího systému by měly být podrobeny přísnému testování. Dalším úkolem řešeným definováním verifikační strategie je určení místa různých verifikačních procesů a jejich vztahů s vývojovými procesy. 20 Proces ověřování, který pracuje se systémovými požadavky, je proces ověřování požadavků, jejich porovnávání se skutečnými očekáváními zákazníka. Při pohledu do budoucna řekněme, že proces validace se liší od akceptačních testů prováděných při předání hotového systému zákazníkovi, i když jej lze považovat za součást takových testů. Validace je prostředkem k prokázání nejen správnosti implementace systému z pohledu zákazníka, ale také správnosti principů jeho vývoje. Rýže. 8 Procesy a dokumenty vývoje softwarového systému Systémové požadavky jsou základem pro proces vývoje funkčních požadavků a architekturu projektu. Během tohoto procesu jsou vyvíjeny obecné požadavky na software systému, na funkce, které musí vykonávat. Funkční požadavky často zahrnují definici vzorců chování systému v normálních a nouzové situace , pravidla pro zpracování dat a definice uživatelského rozhraní. Text požadavku zpravidla obsahuje slova „měl by, musí“ a má strukturu ve tvaru „Pokud hodnota teploty na snímači ABC dosáhne 30 stupňů Celsia nebo více, systém musí přestat vydávat zvukový signál. “ Funkční požadavky jsou základem pro vývoj architektury systému - popis jeho struktury z hlediska subsystémů a strukturních jednotek jazyka, ve kterém je implementace prováděna - oblasti, třídy, moduly, funkce atd. Na základě funkčních požadavků jsou sepsány zkušební požadavky – dokumenty obsahující definici klíčových bodů, které je nutné zkontrolovat, aby bylo zajištěno, že implementace funkčních požadavků je správná. Požadavky na testy často začínají slovy „Check what“ a obsahují odkazy na jejich odpovídající funkční požadavky. Příklad testovacích požadavků pro výše uvedený funkční požadavek by byl „Ověřte, že pokud teplota na senzoru ABC klesne pod 30 stupňů Celsia, systém vydá varovný zvuk“ a „Ověřte, že pokud teplota na senzoru ABC překročí 30 stupňů Celsia, systém nepípne." 21 Jedním z problémů, které vznikají při psaní požadavků na testy, je zásadní netestovatelnost některých požadavků, např. požadavek „Uživatelské rozhraní musí být intuitivní“ nelze testovat bez jasné definice toho, co je intuitivní rozhraní. Takové nespecifické funkční požadavky jsou obvykle následně upraveny. Architektonické vlastnosti systému mohou také sloužit jako zdroj pro vytváření testovacích požadavků, které zohledňují vlastnosti softwarové implementace systému. Příkladem takového požadavku je například „Zkontrolujte, zda hodnota teploty na snímači ABC nepřesahuje 255“. Na základě funkčních požadavků a architektury je napsán programový kód systému a pro jeho kontrolu je na základě testovacích požadavků připraven testovací plán - popis sekvence testovacích případů, které kontrolují shodu implementace systému s požadavky. Každý testovací případ obsahuje konkrétní popis hodnot dodaných jako vstup do systému, hodnoty očekávané jako výstup a popis scénáře provedení testu. V závislosti na předmětu testování může být plán testování připraven buď jako program v programovacím jazyce, nebo jako vstupní datový soubor pro sadu nástrojů, která provádí testovaný systém a předává mu hodnoty stanovené v plánu testování, nebo jako pokyny pro uživatele systému, který popisuje nezbytné kroky, které je třeba provést pro testování různých funkcí systému. V důsledku provedení všech testovacích případů se shromažďují statistiky o úspěšnosti absolvování testu - procento testovacích případů, u kterých se skutečné výstupní hodnoty shodovaly s očekávanými, takzvané úspěšné testy. Neúspěšné testy jsou výchozími daty pro analýzu příčin chyb a jejich následnou opravu. Ve fázi integrace se jednotlivé moduly systému sestaví do jednoho celku a provedou se testovací případy, které prověří celou funkčnost systému. V poslední fázi je hotový systém dodán zákazníkovi. Před implementací provedou specialisté zákazníka společně s vývojáři akceptační testy - prověří funkce, které jsou pro uživatele kritické v souladu s předem schváleným testovacím programem. Po úspěšném absolvování testů je systém předán zákazníkovi, jinak je odeslán k revizi. 1.8. Typy procesů testování a ověřování a jejich místo v různých modelech životního cyklu 1.8.1. Testování jednotek Malé jednotky (procedury, třídy atd.) jsou podrobeny testování jednotek. Při testování relativně malého modulu o velikosti 100-1000 řádků je možné zkontrolovat, když ne všechny, tak alespoň mnoho logických větví v implementaci, různé cesty v grafu závislosti dat, hraniční hodnoty parametrů. V souladu s tím jsou konstruována kritéria pokrytí testu (jsou pokryty všechny operátory, všechny logické větve, všechny hraniční body atd.). . Testování jednotek se obvykle provádí pro každého nezávislého softwarový modul a je možná nejběžnějším typem testování, zejména pro malé a středně velké systémy. 1.8.2. Integrační testování Kontrola správnosti všech modulů bohužel nezaručuje správné fungování systému modulů. V literatuře se někdy hovoří o „klasickém“ modelu nesprávné organizace testování systému modulů, často nazývaném metodou „velkého skoku“. Podstatou metody je nejprve otestovat každý modul zvlášť, poté je spojit do systému a otestovat celý systém. U velkých systémů je to nereálné. S tímto přístupem bude mnoho času vynaloženo na lokalizaci chyb a kvalita testování zůstane nízká. Alternativou k „velkému skoku“ je integrační testování, kdy se systém staví na etapy, skupiny modulů se přidávají postupně. 1.8.3. Systémové testování Plně implementovaný softwarový produkt je podroben systémovému testování. Testera v této fázi nezajímá správnost implementace jednotlivých postupů a metod, ale celého programu jako celku, jak jej vidí koncový uživatel. Základem pro testy jsou Obecné požadavky do programu, včetně nejen správnosti implementace funkcí, ale také výkonu, doby odezvy, odolnosti proti poruchám, útokům, chybám uživatelů atd. Pro testování systému a komponent se používají specifické typy kritérií pokrytí testů (například jsou pokryty všechny typické pracovní scénáře, všechny scénáře s abnormálními situacemi, párové složení scénářů atd.). 1.8.4. Testování zátěže Nejenže zátěžové testování poskytuje prediktivní data o výkonu systému při zátěži, která se zaměřuje na architektonická rozhodnutí, ale také poskytuje provozní informace týmům technické podpory, stejně jako projektovým a konfiguračním manažerům, kteří jsou zodpovědní za vytváření nejproduktivnějších konfigurace hardwaru a softwaru.. Zátěžové testování umožňuje vývojovému týmu činit informovanější rozhodnutí zaměřená na vývoj optimálních architektonických kompozic. Zákazník ze své strany získává možnost provádět akceptační testy v podmínkách blízkých reálným. 1.8.5. Formální kontroly Formální kontrola je jedním ze způsobů, jak ověřit dokumenty a programový kód vytvořený během procesu vývoje softwaru. Při formální kontrole skupina specialistů nezávisle kontroluje shodu kontrolovaných dokumentů s originálními dokumenty. Nezávislost ověřování je zajištěna tím, že jej provádějí inspektoři, kteří se nepodíleli na vypracování kontrolovaného dokumentu. 1.9. Ověření certifikovaného softwaru Uveďme některé definice, které definují celková struktura Proces certifikace softwaru: Certifikace softwaru je proces stanovení a formálního uznání, že vývoj softwaru byl proveden v souladu s určitými požadavky. V průběhu certifikačního procesu dochází k interakci Žadatele, Certifikačního orgánu a Dozorového orgánu Žadatelem je organizace, která podává příslušnému Certifikačnímu orgánu žádost o získání certifikátu (shody, kvality, vhodnosti atd.) certifikátu. produkt. Certifikační orgán – organizace, která posuzuje žádost Žadatele o certifikaci softwaru a samostatně nebo vytvořením zvláštní komise vypracuje soubor postupů zaměřených na provedení procesu certifikace softwaru Žadatele. 23 Dozorčí orgán - komise specialistů, kteří dohlížejí na procesy vývoje Žadatelem certifikovaného informační systém a poskytnutí stanoviska o souladu tohoto procesu s určitými požadavky, které je předloženo k posouzení certifikačnímu orgánu. Certifikace může být zaměřena na získání certifikátu shody nebo certifikátu kvality. V prvním případě je výsledkem certifikace uznání souladu vývojových procesů s určitými kritérii a funkčnosti systému s určitými požadavky. Jako příklad takových požadavků mohou sloužit pokyny. Federální služba o technické a exportní kontrole v oblasti bezpečnosti softwarových systémů. Ve druhém případě je výsledkem uznání shody vývojových procesů s určitými kritérii, což zaručuje odpovídající úroveň kvality vyráběného produktu a jeho vhodnost pro použití v určitých podmínkách. Příkladem takových norem je řada mezinárodních norem kvality ISO 9000:2000 (GOST R ISO 9000-2001) nebo leteckých norem DO-178B, AS9100, AS9006. Testování softwaru, který má být certifikován, má dva doplňkové cíle: Prvním cílem je prokázat, že software splňuje požadavky na něj. Druhým cílem je prokázat s vysokou mírou jistoty, že chyby, které mohou vést k nepřijatelným poruchovým situacím, jak je stanoveno procesem hodnocení bezpečnosti systému, jsou identifikovány během procesu testování. Například podle požadavků normy DO-178B je pro splnění cílů testování softwaru nutné následující: Testy musí nejprve vycházet z požadavků na software; Testy by měly být navrženy tak, aby ověřily správnou funkci a vytvořily podmínky pro identifikaci potenciálních chyb. Kontrola úplnosti testů na základě požadavků na software by měla určit, které požadavky se testovat nebudou. Analýza úplnosti testů na základě struktury programového kódu by měla určit, které struktury nebyly během testování provedeny. Tato norma také hovoří o testování na základě požadavků. Bylo zjištěno, že tato strategie je nejúčinnější při odhalování chyb. Směrnice pro výběr testovacích případů na základě požadavků zahrnují následující: Aby bylo dosaženo cílů testování softwaru, měly by být provedeny dvě kategorie testů: testy pro normální situace a testy pro abnormální (nepožadované, robustní) situace. Měly by být vyvinuty specifické testovací případy pro softwarové požadavky a zdroje chyb, které jsou součástí procesu vývoje softwaru. Účelem testů pro běžné situace je prokázat schopnost softwaru reagovat na běžné vstupy a podmínky v souladu s požadavky. 24 Účelem testů pro abnormální situace je prokázat schopnost softwaru adekvátně reagovat na abnormální vstupy a podmínky, jinými slovy, nemělo by způsobit selhání systému. Kategorie poruchových situací pro systém jsou stanoveny určením nebezpečí poruchové situace pro letadlo a jeho osoby na palubě. Jakákoli chyba v softwaru může způsobit selhání, které přispěje k situaci selhání. Úroveň integrity softwaru požadovaná pro bezpečný provoz tedy souvisí se situacemi selhání systému. Existuje 5 úrovní poruchových situací od méně závažných po kritické. Podle těchto úrovní je zaveden koncept úrovně kritičnosti softwaru. Míra kritičnosti určuje skladbu dokumentace předkládané certifikační autoritě, a tím i hloubku procesů vývoje a ověřování systému. Například počet typů dokumentů a množství práce na vývoji systému potřebné pro certifikaci pro nejnižší úroveň kritičnosti DO-178B se může lišit o jeden nebo dva řády od počtu a objemů požadovaných pro certifikaci pro většinu vysoká úroveň. Konkrétní požadavky jsou stanoveny normou, podle které se plánuje provedení certifikace. 25 TÉMA 2. Testování programového kódu (přednášky 2-5) 2.1. Úkoly a cíle testování programového kódu Testování programového kódu je proces provádění programového kódu zaměřený na identifikaci existujících defektů v něm. Vadou se zde rozumí úsek programového kódu, jehož provedení za určitých podmínek vede k neočekávanému chování systému (tj. chování, které nesplňuje požadavky). Neočekávané chování systému může vést k poruchám v jeho provozu a poruchám, v tomto případě hovoří o významných vadách v kódu programu. Některé závady způsobují drobné problémy, které nenaruší fungování systému, ale poněkud znesnadňují práci s ním. V tomto případě hovoříme o středních nebo menších vadách. Úkolem testování tímto přístupem je určit podmínky, za kterých se objevují systémové závady, a tyto stavy zaznamenat. Testovací úlohy obvykle nezahrnují identifikaci konkrétních vadných částí programového kódu a nikdy nezahrnují opravu defektů – jedná se o ladicí úlohu, která se provádí na základě výsledků testování systému. Účelem aplikace postupu testování programového kódu je minimalizovat počet defektů, zejména těch významných, ve finálním produktu. Samotné testování nemůže zaručit úplnou absenci defektů v systémovém kódu. Ovšem v kombinaci s ověřovacími a validačními procesy zaměřenými na odstranění nesrovnalostí a neúplností projektová dokumentace(zejména požadavky na systém), dobře organizované testování zajišťuje, že systém splňuje požadavky a chová se v souladu s nimi ve všech předpokládaných situacích. Při vývoji systémů se zvýšenou spolehlivostí, například letectví, se záruky spolehlivosti dosahují jasnou organizací testovacího procesu, určením jeho propojení s dalšími procesy životního cyklu, zavedením kvantitativních charakteristik, které umožňují vyhodnotit úspěšnost testování. Zároveň platí, že čím vyšší jsou požadavky na spolehlivost systému (jeho kritičnost), tím jsou požadavky přísnější. Nejprve tedy nezohledňujeme konkrétní výsledky testování konkrétního systému, ale obecná organizace testovací proces s využitím přístupu „dobře organizovaný proces dává kvalitní výsledek“. Tento přístup je společný mnoha mezinárodním a průmyslovým standardům kvality, které budou podrobněji diskutovány na konci tohoto kurzu. Kvalita vyvinutého systému s tímto přístupem je výsledkem organizovaného procesu vývoje a testování, nikoli nezávislým neřízeným výsledkem. Protože moderní softwarové systémy jsou velmi velké, používá se při testování jejich programového kódu metoda funkčního rozkladu. Systém je rozdělen na samostatné moduly (třídy, jmenné prostory atd.), které mají funkčnost a rozhraní definovaná požadavky. Poté je každý modul testován jednotlivě - je provedeno jednotkové testování. Poté se jednotlivé moduly sestavují do větších konfigurací – provádí se integrační testování a nakonec se testuje systém jako celek – provádí se testování systému. Z hlediska programového kódu má unit, integrace a testování systému mnoho společného, proto se toto téma zaměří na unit testing, o vlastnostech integrace a testování systému bude řeč později. 26 Při testování jednotek je každý modul testován jak na shodu s požadavky, tak na absenci problematických částí programového kódu, které mohou způsobit poruchy a výpadky v systému. Moduly mimo systém zpravidla nepracují – přijímají data z jiných modulů, zpracovávají je a předávají dál. Aby bylo možné modul na jedné straně izolovat od systému a eliminovat vliv případných systémových chyb, a na druhé straně poskytnout modulu všechna potřebná data, je použito testovací prostředí. Úkolem testovacího prostředí je vytvořit runtime prostředí pro modul, emulovat všechna externí rozhraní, ke kterým modul přistupuje. V tomto tématu se bude diskutovat o funkcích organizace testovacího prostředí. Typickým testovacím postupem je příprava a provedení testovacích případů (označovaných také jednoduše jako testy). Každý testovací případ kontroluje jednu „situaci“ v chování modulu a skládá se ze seznamu hodnot předávaných na vstup modulu, popisu spouštění a provádění zpracování dat – testovacího scénáře a seznamu hodnoty, které jsou očekávány na výstupu modulu v případě jeho správného chování. Testovací scénáře jsou sestaveny tak, aby byl vyloučen přístup k interním datům modulu, veškerá interakce by měla probíhat pouze přes jeho externí rozhraní. Provedení testovacího případu je podporováno testovacím prostředím, které zahrnuje programovou implementaci testovacího skriptu. Spuštění začíná předáním vstupu modulu a spuštěním skriptu. Skutečný výstup přijatý z modulu jako výsledek provádění skriptu je uložen a porovnán s očekávanými. Pokud se shodují, je test považován za splněný, jinak není úspěšný. Každý neúspěšný test indikuje buď závadu v testované jednotce, v testovacím prostředí nebo v popisu testu. Soubor popisů testovacích případů je plán testování - hlavní dokument, který definuje postup testování programového modulu. Plán testování specifikuje nejen samotné testovací případy, ale také jejich pořadí, což může být také důležité. Struktura a vlastnosti testovacích plánů budou diskutovány v tomto tématu, problémy spojené s pořadím testovacích případů - v tématu "Opakovatelnost testování". Při testování je často nutné zohlednit nejen požadavky na systém, ale také strukturu programového kódu testovaného modulu. V tomto případě jsou testy navrženy tak, aby detekovaly typické chyby programátorů způsobených nesprávnou interpretací požadavků. Uplatňují se kontroly okrajových podmínek, kontroly tříd ekvivalence. Absence v systému schopností, které nejsou specifikovány požadavky, zaručuje různé odhady pokrytí programového kódu testy, tzn. odhaduje, jaké procento určitých jazykových konstruktů je provedeno v důsledku provedení všech testovacích případů. To vše bude probráno na konci tohoto tématu. 2.2. Zkušební metody 2.2.1. Černá skříňka Hlavní myšlenkou při testování systému jako černé skříňky je, že všechny materiály, které má tester k dispozici, jsou požadavky na systém, které popisují jeho chování a systém samotný, se kterým může pracovat pouze aplikací některých vnějších vlivů ke svým vstupům a pozorování výstupů nějaký výsledek. Všechny vnitřní vlastnosti implementace systému jsou před testerem skryty, systém je tedy „černou skříňkou“, jejíž správné chování ve vztahu k požadavkům je třeba kontrolovat. 27 Z hlediska programového kódu může být černou skříňkou sada tříd (nebo modulů) se známými externími rozhraními, ale nepřístupnými zdrojovými texty. Hlavním úkolem testera u této testovací metody je důsledně ověřovat, že chování systému odpovídá požadavkům. Kromě toho musí tester testovat systém v kritických situacích - co se stane, když jsou zadány nesprávné vstupní hodnoty. V ideální situaci by měly být všechny varianty kritických situací popsány v požadavcích na systém a tester může přijít pouze s konkrétními kontrolami těchto požadavků. Ve skutečnosti se však v důsledku testování obvykle odhalí dva typy systémových problémů: 1. Nesoulad chování systému s požadavky 2. Neadekvátní chování systému v situacích, které požadavky neumožňují. Zprávy o obou typech problémů jsou zdokumentovány a sdíleny s vývojáři. Problémy prvního typu přitom obvykle způsobují změnu programového kódu, mnohem méně často - změnu požadavků. Změna požadavků v tomto případě může být vyžadována z důvodu jejich nejednotnosti (několik různých požadavků popisuje různé modely chování systému ve stejné situaci) nebo nesprávnosti (požadavky neodpovídají skutečnosti). Problémy druhého typu jednoznačně vyžadují změny v požadavcích pro svou neúplnost - požadavky zjevně postrádají situaci, která vede k neadekvátnímu chování systému. Neadekvátní chování lze přitom chápat jako úplné zhroucení systému nebo obecně jakékoli chování, které není popsáno v požadavcích. Testování černé skříňky se také nazývá testování požadavků. toto je jediný zdroj informací pro sestavení testovacího plánu. 2.2.2. Skleněná (bílá) krabice Při testování systému jako skleněné krabice má tester přístup nejen k požadavkům na systém, jeho vstupům a výstupům, ale také k jeho vnitřní struktuře - viz jeho programový kód. Dostupnost programového kódu rozšiřuje možnosti testera tím, že vidí shodu požadavků s částmi programového kódu a tím vidí, zda jsou požadavky na celý programový kód. Programový kód, pro který neexistují žádné požadavky, se nazývá kód bez požadavků. Takový kód je potenciálním zdrojem nevhodného chování systému. Transparentnost systému navíc umožňuje prohloubit analýzu jeho oblastí, které způsobují problémy – často jeden problém neutralizuje jiný a nikdy se nevyskytují současně. 2.2.3. Testování modelu Testování modelu je poněkud vzdálené od klasických metod ověřování softwaru. Za prvé je to dáno tím, že předmětem testování není samotný systém, ale jeho formálními prostředky navržený model. Pokud ponecháme stranou problematiku kontroly správnosti a použitelnosti samotného modelu (předpokládá se, že jeho správnost a shodu s původním systémem lze prokázat formálními prostředky), pak má tester k dispozici poměrně silný nástroj pro analýzu celkovou integritu systému. Při práci s modelem můžete vytvářet situace, které nelze vytvořit v testovací laboratoři pro skutečný systém. Při práci s modelem programového kódu systému je možné analyzovat jeho vlastnosti a parametry systému, jako je optimalita algoritmů nebo jeho stabilita. 28 Modelové testování se však nerozšířilo právě kvůli obtížím, s nimiž se setkáváme při vytváření formálního popisu chování systému. Jednou z mála výjimek jsou komunikační systémy, jejichž algoritmický a matematický aparát je poměrně dobře rozvinutý. 2.2.4. Analýza programového kódu (inspekce) V mnoha situacích je testování chování systému jako celku nemožné - jednotlivé sekce programového kódu nemusí být nikdy provedeny, zatímco budou pokryty požadavky. Obsluha výjimek je příkladem takových částí kódu. Pokud si například dva moduly posílají číselné hodnoty a funkce ověřování hodnot fungují v obou modulech, pak se kontrolní funkce modulu přijímače nikdy neaktivuje, protože všechny chybné hodnoty budou ve vysílači oříznuty. V tomto případě se provádí manuální analýza správnosti kódu programu, nazývaná také revize kódu nebo inspekce. Pokud jsou v důsledku kontroly identifikovány problémové oblasti, informace o tom jsou předány vývojářům k opravě spolu s výsledky pravidelných testů. 2.3. Testovací prostředí Většina testování téměř jakéhokoli složitého systému se obvykle provádí v automatický režim. Testovaný systém je navíc obvykle rozdělen do samostatných modulů, z nichž každý je testován nejprve odděleně od ostatních, poté jako celek. To znamená, že pro provádění testování je nutné vytvořit nějaké prostředí, které zajistí spuštění a provedení testovaného modulu, předá mu vstupní data, shromáždí reálná výstupní data získaná jako výsledek běhu systému na daných vstupních datech. . Poté by mělo prostředí porovnat skutečná výstupní data s očekávanými a na základě tohoto srovnání vyvodit závěr o souladu chování modulu se zadaným (obr. 9). Testovací ovladač Očekávaná výstupní data během testu Zpracování vstupních dat Modul výsledků skutečných výstupních dat 9 Zobecněné schéma testovacího prostředí Testovací prostředí lze také využít k odcizení jednotlivých modulů systému od celého systému. Oddělení systémových modulů v raných fázích testování umožňuje přesněji lokalizovat problémy, které vznikají v jejich programovém kódu. Pro podporu provozu modulu v izolaci od systému by testovací prostředí mělo modelovat chování všech modulů, k jejichž funkcím nebo datům má testovaný modul přístup. 29
Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář
Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu ve svém studiu a práci, vám budou velmi vděční.
Hostováno na http://www.allbest.ru/
abstraktní
Metody ověřování a testování softwaru
Úvod
Lidé mají tendenci dělat chyby. Chyby vždy byly a budou. V IT prostředí existuje vtip, že pokud se program spustí napoprvé a hned funguje, tak je potřeba hledat chybu.
Spolu s vývojem počítačová věda, s jeho pronikáním do všech sfér života roste i počet chyb v programech. Růst chyb je navíc neúměrný růstu počtu programů. Každý rok se řady programátorů doplňují o bydlokodéry (jmenují se legie), kteří exponenciálně rozvíjejí pole chyb.
Chyby nejsou viditelné ve všech oblastech. Nikoho například nezajímají chyby a zranitelnosti v prohlížečích jako „amigo“. Ano, a ztráty z takových chyb jsou zanedbatelné: maximum, které může běžný uživatel ztratit, jsou účty na sociálních sítích, jeden a půl tisíce průměrných fotografií z dovolené a sbírka porna.
Existují však oblasti, ve kterých mohou chyby v programování vést k nejnešťastnějším důsledkům. Jedním z prvních případů, které se mi podařilo najít, je kosmická loď Mariner 1, která byla zničena 22. července 1962, 293 sekund po startu, kvůli chybě v programu palubního počítače. Je dobře, že tehdy nedošlo k žádnému úmrtí.
A co se stane, když palubní počítač Boeingu-747 se čtyřmi stovkami pasažérů na palubě vyhodí výjimku?
Právě pro oblasti, které lze nazvat „seriózní“, byly vynalezeny metody ověřování a testování.
V některé zahraniční literatuře jsou procesy ověřování a testování identifikovány a někde je testování považováno za jeden ze způsobů ověřování. Tuto práci provedu podle svého nejlepšího porozumění, samostatně zvažuji procesy ověřování a testování. Pro spravedlnost se také dotknu tématu validace softwaru.
1. Definice
Životní cyklus(LC) software. Tento termín označuje časový interval od myšlenky na vytvoření softwaru s potřebnou funkčností k vyřešení určitých problémů až do úplného ukončení používání. Nejnovější verze tento program.
Artefaktyživotní cyklus softwaru (SW). Patří sem různé informační materiály související s tvorbou softwaru. Jedná se o zadání, popis architektury, zdrojový kód, uživatelskou dokumentaci a další dokumenty. Materiály, které byly použity při vývoji, ale nebyly zaznamenány v přístupné podobě (například komentáře v kódu a zneužití vývojářů v chatu), nejsou artefakty.
2. Ověření
Ověření kontroluje shodu některých artefaktů vytvořených v průběhu vývoje a údržby softwaru s jinými dříve vytvořenými nebo použitými jako počáteční data a také shodu těchto artefaktů a jejich vývojových procesů s pravidly a standardy. Ověřením se kontroluje zejména soulad mezi normami norem, popis požadavků (referenčních podmínek) na software, konstrukční řešení, zdrojový kód, uživatelská dokumentace a fungování samotného softwaru. Kromě toho je ověřeno, že požadavky konstrukční řešení, dokumentace a kód jsou vypracovány v souladu s normami a standardy přijatými v dané zemi, odvětví a organizaci při vývoji softwaru a také, že při jejich vytvoření byly všechny operace specifikované v normách provedeny v požadovaném pořadí. Chyby a závady zjištěné při ověřování jsou nesrovnalosti nebo rozpory mezi několika uvedenými dokumenty, mezi dokumenty a skutečným provozem programu, mezi normami standardů a skutečnými procesy vývoje a údržby softwaru. Samostatným úkolem je přitom rozhodnout, který dokument se má opravit (možná oba).
Výše uvedené je oficiální definice ověřování. Ve skutečnosti je vše mnohem jednodušší: ověření určuje děláme program správně?.
Hlavními metodami ověřování jsou tedy zkoumání a kontrola.
ověření odbornosti programu
3. Validace
Proces validace kontroluje shodu jakýchkoli artefaktů vytvořených nebo použitých během vývoje a údržby softwaru s potřebami a požadavky uživatelů a zákazníků tohoto softwaru, přičemž je třeba vzít v úvahu zákony předmětová oblast a omezení kontextu, ve kterém se software používá.
A opět se za spoustou slov skrývá velmi jednoduchý úkol: při procesu validace se kontroluje, zda tito uživatelé/zákazníci potřebují určitou funkcionalitu programu. Splňuje softwarový produkt přání zákazníků a koncových uživatelů?
4. Testování
Testování je proces odhalování chyb v softwaru prováděním kódu softwarového systému na testovacích datech, shromažďování výkonnostních charakteristik v dynamice provádění v konkrétním operačním prostředí, identifikace různých chyb, defektů, selhání a nedostatků způsobených nepravidelnými a abnormálními situacemi. nebo abnormální ukončení softwaru.
Historicky prvním typem testování bylo ladění.
Ladění je kontrola popisu programového objektu v programovacím jazyce s cílem odhalit v něm chyby a následně je odstranit. Chyby jsou detekovány kompilátorem při jejich syntaktické kontrole. Po odladění se provede verifikace pro kontrolu správnosti kódu a validace pro kontrolu, zda produkt splňuje zadané požadavky.
1. Statické zkušební metody
Statické metody se používají při provádění kontrol a přezkoumávání specifikací komponent bez jejich implementace. Technika statické analýzy spočívá v metodickém přezkoumání a analýze struktury programů a také v prokazování jejich správnosti. Statická analýza je zaměřena na analýzu dokumentů vytvořených ve všech fázích životního cyklu a spočívá v kontrole zdrojového kódu a end-to-end kontrole programu.
Softwarová kontrola je statická kontrola souladu programu s danými specifikacemi, prováděná analýzou různých reprezentací výsledků návrhu (dokumentace, požadavky, specifikace, schémata nebo zdrojový kód programu) v procesech životního cyklu. Více poskytují revize a kontroly výsledků návrhu a jejich soulad s požadavky zákazníků vysoká kvalita vytvořené softwarové systémy.
2. Dynamické zkušební metody
Metoda černé skříňky. Při použití této metody jsou použity informace o řešeném problému, ale není známo nic o struktuře programu. Cílem testování podle tohoto principu je identifikovat maximální počet chyb v jednom testu pomocí malé podmnožiny možných vstupních dat.
Testovací metody podle tohoto principu se používají k testování funkcí implementovaných v programu kontrolou nesouladu mezi skutečným chováním funkcí a očekávaným chováním s přihlédnutím ke specifikacím požadavků. Během přípravy na toto testování jsou sestaveny stavové tabulky, grafy příčin a následků 1 a oblasti poruch. Kromě toho jsou připraveny testovací sady, které berou v úvahu parametry a podmínky prostředí ovlivňující chování funkcí.
Metoda bílé krabice.
Tato metoda umožňuje prozkoumat vnitřní strukturu programu a detekce všech chyb v programu je kritériem pro vyčerpávající testování tras řídicích toků, mezi které patří:
Kritérium pokrytí operátora - sada testů v souhrnu musí zajistit, aby každý operátor prošel alespoň jednou;
Kritérium testování větví (neboli pokrytí rozhodování nebo pokrytí přechodu) – sada testů v agregaci musí zajistit, aby každá větev nebo výstup prošel alespoň jednou.
3. Funkční testování
Účelem funkčního testování je odhalit nesrovnalosti mezi skutečným chováním implementovaných funkcí a očekávaným chováním podle specifikace a výchozích požadavků. Funkční testy by měly pokrývat všechny implementované funkce s ohledem na nejpravděpodobnější typy chyb. Testovací scénáře, které kombinují jednotlivé testy, jsou zaměřeny na kontrolu kvality řešení funkčních problémů.
Funkční testy jsou vytvářeny podle specifikací funkcí, návrhových informací a textu v programovacím jazyce a slouží ke zjištění úplnosti implementace funkčních úloh a jejich souladu s výchozími požadavky.
Mezi úkoly funkčního testování patří:
Identifikace souboru funkčních požadavků;
Identifikace externích funkcí a konstrukce sekvencí funkcí v souladu s jejich použitím v softwarovém systému;
Identifikace souboru vstupních dat každé funkce a určení oblastí jejich změny;
Konstrukce testovacích sad a scénářů pro testovací funkce;
Identifikace a prezentace všech funkčních požadavků pomocí testovacích případů a testovacích chyb v programu a při interakci s prostředím.
Testy vytvořené z návrhových informací jsou spojeny s datovými strukturami, algoritmy, rozhraními mezi jednotlivými komponentami a slouží k testování komponent a jejich rozhraní. Hlavním cílem je zajistit úplnost a konzistenci implementovaných funkcí a rozhraní mezi nimi.
5. Typy chyb ANSI/IEEE-7 29 -8 3
Chyba (chyba) - stav programu, ve kterém jsou vytvářeny nesprávné výsledky, jejichž příčinou jsou chyby (chyby) ve výpisech programu nebo v technologický postup jeho vývoj, což vede k dezinterpretaci informace o pozadí, což vede ke špatnému řešení.
Defekt (chyba) v programu - důsledek chyb vývojáře v jakékoli fázi vývoje, které mohou být obsaženy v originále nebo specifikacích návrhu, textech programových kódů, provozní dokumentaci atd. Během provádění programu může být zjištěna závada nebo selhání.
Selhání (selhání) je odchylka programu od fungování nebo neschopnost programu plnit funkce definované požadavky a omezeními, která je považována za událost, která přispívá k přechodu programu do nefunkčního stavu v důsledku chyb. , latentní vady nebo poruchy ve fungujícím prostředí. Selhání může být způsobeno následujícími důvody:
Chybná specifikace nebo vynechaný požadavek, což znamená, že specifikace přesně neodráží to, co uživatel zamýšlel;
Specifikace může obsahovat požadavek, který nelze na daném hardwaru a softwaru splnit;
Návrh programu může obsahovat chyby (např. databáze je navržena bez prostředků ochrany proti neoprávněnému přístupu uživatele, ale ochrana je nutná);
Program může být nesprávný, tzn. provádí neobvyklý algoritmus nebo není plně implementován.
Závěr
Ruské GOST týkající se ověřování a testování softwaru jsou překlady „buržoazních“ norem, jako jsou ISO 12207, ANSI/IEEE-729-83 a další (je jich spousta). Problém je v tom, že tyto mezinárodní standardy řeší otázky testování a ověřování odlišně. Neříkám, že si úplně odporují, ale mohou způsobit zmatek.
Všechny tyto normy byly formulovány v 80. letech minulého století pro americký vesmírný průmysl. V následujících letech byly opraveny a znovu publikovány, ale neshody a rozpory v dokumentech zůstaly.
Závěr: struktura metod ověřování, validace a testování by měla být vnímána jako podmíněná.
Bibliografie
1. Volná encyklopedie wikipedia.org
2. Kulyamin V.V. Metody ověřování softwaru M.: Institut pro systémové programování, 2008
3. Lavrishcheva E., Petrukhin V. Přednáška "Metody pro kontrolu a testování programů a systémů": NOU "INTUIT" http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130
Hostováno na Allbest.ru
...Podobné dokumenty
Životní cyklus softwaru je nepřetržitý proces, který začíná rozhodnutím o nutnosti vytvořit software a končí jeho úplným vyřazením z provozu. Rileyho, Lehmanův a Boehmův přístup k definici životního cyklu softwaru.
abstrakt, přidáno 01.11.2009
Koncepce technologie vývoje programu. Základ návrhu softwaru. Modely životního cyklu, které vznikly historicky během vývoje teorie návrhu softwaru. Spirálové (spirální), kaskádové a iterační modely.
prezentace, přidáno 05.11.2015
Historie vývoje a typy testování softwaru. Instalace, regrese, konfigurace, integrace, lokalizace, testování jednotek. Metody pro snížení složitosti unit testování vyvíjené aplikace.
semestrální práce, přidáno 16.12.2015
Nerozhodnutelnost problému testování softwaru. Typy a úrovně testování. Upstream a Downstream testovací strategie. Metody "bílé" a "černé" krabice. Automatické a ruční testování. Vývoj prostřednictvím testování.
semestrální práce, přidáno 22.03.2015
Požadavky na technologii návrhu softwaru (SW). Složení a popis fází kompletního životního cyklu softwaru. Klasifikace modelů životního cyklu softwaru, jejich vlastnosti. Metodiky vývoje softwaru, extrémní programovací techniky.
prezentace, přidáno 19.09.2016
Historie testování softwaru, hlavní cíle a rysy jeho implementace. Typy a typy testování, úrovně jeho automatizace. Použití a výzkum potřebné technologie. Celý cyklus provoz celého monitorovacího systému.
práce, přidáno 03.05.2018
Hlavní mezinárodní standardy v oboru informační technologie. mezinárodní standard ISO/IEC 9126 Kvalita a životní cyklus. Charakterizace vnitřních a vnějších atributů kvality. Analýza funkčnosti softwaru.
zpráva, přidáno 13.06.2017
Cíle a cíle softwarového inženýrství. Pojem software. Šest principů efektivní využití software. Typy softwaru: celosystémový, síťový a aplikovaný. Principy tvorby softwaru.
semestrální práce, přidáno 29.06.2010
Obecná charakteristika hlavních modelů životního cyklu: kaskádový, inkrementální, spirálový. Fáze jako součást procesu vývoje softwaru, omezená na konkrétní časový rámec a končící vydáním konkrétního produktu.
prezentace, přidáno 27.12.2013
Informatizace Ruska. Trh softwarové nástroje. Hlavní úkoly standardizace, certifikace a licencování v oblasti informatizace. Soubor inženýrských metod a nástrojů pro tvorbu softwaru. Životní cyklus softwaru.
Verifikace a validace odkazuje na procesy ověřování a kontroly, které ověřují, že software odpovídá jeho specifikaci a požadavkům zákazníka. Verifikace a validace pokrývají celý životní cyklus softwaru – začínají ve fázi analýzy požadavků a končí verifikací programového kódu ve fázi testování hotového softwarového systému.
Ověření a atest není totéž, i když je snadné je zaměnit. Stručně, rozdíl mezi nimi lze definovat takto:
Verifikace odpovídá na otázku, zda je systém správně navržen;
Certifikace odpovídá na otázku, zda systém funguje správně.
Verifikace podle těchto definic kontroluje, zda software odpovídá specifikaci systému, zejména funkčním a nefunkčním požadavkům. Certifikace je obecnější proces. Během ověřování se musíte ujistit, že softwarový produkt splňuje očekávání zákazníka. Validace se provádí po ověření s cílem zjistit, jak systém splňuje nejen specifikaci, ale také očekávání zákazníka.
Jak již bylo zmíněno dříve, ověřování systémových požadavků je velmi důležité v raných fázích vývoje softwaru. V požadavcích se často vyskytují chyby a opomenutí; v takových případech konečný produkt pravděpodobně nebude splňovat očekávání zákazníka. Validace požadavků však samozřejmě nemůže odhalit všechny problémy ve specifikaci požadavků. Někdy se mezery a chyby v požadavcích odhalí až po dokončení implementace systému.
Procesy ověřování a validace používají dvě hlavní techniky pro kontrolu a analýzu systémů.
1. Kontrola softwaru. Analýza a ověření různých reprezentací systému, jako je dokumentace specifikace požadavků, architektonická schémata nebo zdrojový kód programu. Kontrola se provádí ve všech fázích procesu vývoje softwarového systému. Souběžně s kontrolou lze provádět automatickou analýzu zdrojového kódu programů a souvisejících dokumentů. Inspekce a automatizovaná analýza jsou statické metody ověřování a validace, protože nevyžadují spustitelný systém.
2. Testování softwaru. Spuštění spustitelného kódu s testovacími daty a prozkoumání výstupu a výkonu softwarového produktu za účelem ověření, že systém funguje správně. Testování je dynamická metoda ověřování a ověřování, protože je aplikována na běžící systém.
Na Obr. Obrázek 20.1 ukazuje místo kontroly a testování v procesu vývoje softwaru. Šipky označují fáze vývojového procesu, kde lze tyto metody použít. Podle tohoto schématu lze provádět kontrolu ve všech fázích procesu vývoje systému a testování - když je vytvořen prototyp nebo spustitelný program.
Kontrolní metody zahrnují: kontrolu programu, automatickou analýzu zdrojového kódu a formální ověření. Statické metody však mohou pouze kontrolovat shodu programů se specifikací, nelze je použít ke kontrole správného fungování systému. Navíc nefunkční charakteristiky jako výkon a spolehlivost nelze testovat statickými metodami. Proto se pro vyhodnocení nefunkčních charakteristik provádí testování systému.
Rýže. 20.1. Statické a dynamické ověřování a atestace
Navzdory rozšířenému používání kontroly softwaru je testování stále převládající metodou ověřování a certifikace. Testování je ověření chodu programů s daty podobnými skutečným, které budou zpracovány za provozu systému. Přítomnost závad a nesrovnalostí s požadavky v programu se zjišťuje zkoumáním výstupních dat a identifikací anomálních mezi nimi. Testování se provádí během implementační fáze systému (pro ověření, že systém splňuje očekávání vývojářů) a po dokončení jeho implementace.
V různých fázích procesu vývoje softwaru se používají různé typy testování.
1. Testování defektů vedeny za účelem zjištění nesrovnalostí mezi programem a jeho specifikací, které jsou způsobeny chybami nebo závadami v programech. Tyto testy jsou navrženy tak, aby odhalovaly chyby v systému, a ne aby simulovaly jeho provoz.
2. Statistické testování vyhodnocuje výkon a spolehlivost programů a také provoz systému v různých provozních režimech. Testy jsou navrženy tak, aby napodobovaly skutečný provoz systému s reálnými vstupními daty. Spolehlivost systému je hodnocena počtem poruch zaznamenaných při práci programů. Výkon je hodnocen měřením celkové doby provozu a doby odezvy systému při zpracování testovacích dat.
hlavním cílem Ověření a kvalifikace – aby bylo zajištěno, že systém je „vhodný pro daný účel“. Vhodnost softwarového systému pro zamýšlený účel neznamená, že by měl být absolutně bez chyb. Systém by spíše měl být přiměřeně vhodný pro účely, pro které byl určen. Požadované platnost shody závisí na účelu systému, očekávání uživatelů a tržních podmínkách pro softwarové produkty.
1. Účel softwaru.Úroveň spolehlivosti shody závisí na tom, jak kritický je vyvinutý software podle určitých kritérií. Například úroveň spolehlivosti systémů kritických z hlediska bezpečnosti by měla být výrazně vyšší než úroveň spolehlivosti prototypových softwarových systémů vyvíjených k demonstraci nějaké nové myšlenky.
2. Očekávání uživatelů. Se smutkem je třeba poznamenat, že v současné době má většina uživatelů nízké nároky na software. Uživatelé jsou tak zvyklí na poruchy, ke kterým dochází při běhu programů, že je to nepřekvapí. Jsou ochotni tolerovat selhání systému, pokud výhody jeho používání převažují nad nevýhodami. Od počátku 90. let však tolerance uživatelů k poruchám softwarových systémů postupně klesá. V poslední době je vytváření nespolehlivých systémů téměř nepřijatelné, a tak společnosti zabývající se vývojem softwaru musí věnovat verifikaci a validaci softwaru stále více pozornosti.
3. Podmínky na trhu se softwarem. Při hodnocení softwarového systému musí prodávající znát konkurenční systémy, cenu, kterou je kupující ochoten za systém zaplatit, a očekávanou dobu uvedení tohoto systému na trh. Pokud má vývojářská společnost více konkurentů, je nutné určit datum vstupu systému na trh před ukončením plného testování a ladění, v opačném případě mohou konkurenti vstoupit na trh jako první. Pokud zákazníci nejsou ochotni nakupovat software za vysokou cenu, mohou být ochotni tolerovat více selhání systému. Při stanovení nákladů na proces ověřování a kvalifikace je třeba vzít v úvahu všechny tyto faktory.
Chyby jsou v systému zpravidla nalezeny při ověřování a atestaci. V systému se provádějí změny za účelem opravy chyb. Tento proces ladění obvykle integrován s dalšími ověřovacími a atestačními procesy. Nicméně testování (nebo obecněji verifikace a validace) a ladění jsou různé procesy, které mají různé cíle.
1. Verifikace a validace je proces zjišťování závad v softwarovém systému.
2. Ladění - proces lokalizace defektů (chyb) a jejich opravy (obr. 20.2).
Rýže. 20.2. Proces ladění
Neexistují žádné jednoduché metody pro ladění programů. Zkušení debuggerové najdou chyby porovnáním testovacích výstupních vzorů s výstupem testovaných systémů. Lokalizace chyby vyžaduje znalost typů chyb, výstupních vzorů, programovacího jazyka a procesu programování. Znalost procesu vývoje softwaru je velmi důležitá. Ladicí programy jsou si vědomy nejběžnějších programovacích chyb (jako je zvýšení čítače). Bere také v úvahu chyby, které jsou typické pro určité programovací jazyky, například ty spojené s používáním ukazatelů v jazyce C.
Lokalizace chyb v kódu programu není vždy jednoduchý proces, protože chyba se nemusí nutně nacházet poblíž bodu v kódu programu, kde došlo k havárii. Aby izoloval chyby, debugger vyvíjí další softwarové testy, které pomáhají identifikovat zdroj chyby v programu. Možná budete muset ručně sledovat provádění programu.
Interaktivní ladicí nástroje jsou součástí sady nástrojů jazykové podpory, které jsou integrovány se systémem kompilace kódu. Poskytují speciální prostředí pro provádění programu, jehož prostřednictvím můžete přistupovat k tabulce identifikátorů a odtud k hodnotám proměnných. Uživatelé často řídí provádění programu způsobem krok za krokem, postupným přecházením od příkazu k příkazu. Po provedení každého příkazu jsou zkontrolovány hodnoty proměnných a identifikovány možné chyby.
Chyba nalezená v programu je opravena, poté je nutné program znovu zkontrolovat. Chcete-li to provést, můžete znovu zkontrolovat program nebo zopakovat předchozí test. Opakované testování se používá k zajištění toho, aby změny provedené v programu nezanesly do systému nové chyby, protože v praxi se vysoké procento „oprav chyb“ buď nedokončí úplně, nebo do programu zavedou nové chyby.
V zásadě je nutné po každé opravě spouštět všechny testy znovu při retestování, ale v praxi je tento přístup příliš drahý. Proto se při plánování procesu testování zjišťují závislosti mezi částmi systému a pro každou část jsou přiřazeny testy. Poté je možné sledovat prvky programu pomocí speciálních testovacích případů (řídících dat) vybraných pro tyto prvky. Pokud jsou zdokumentovány výsledky trasování, pak lze k testování změněného programového prvku a jeho závislých komponent použít pouze podmnožinu celkové sady testovacích dat.
Plánování ověřování a atestace
Verifikace a validace je nákladný proces. U velkých systémů, jako jsou systémy pracující v reálném čase se složitými nefunkčními omezeními, je polovina rozpočtu na vývoj systému vynaložena na proces ověřování a validace. Potřeba pečlivého plánování tohoto procesu je tedy zřejmá.
Plánování verifikace a validace v rámci vývoje softwarových systémů by mělo začít co nejdříve. Na Obr. Obrázek 20.3 ukazuje model vývoje softwaru, který bere v úvahu proces plánování testů. Zde začíná plánování již ve fázi specifikace a návrhu systému. Tento model je někdy označován jako V-model (pro zobrazení V otočte obrázek 20.3 o 90°). Tento diagram také ukazuje rozdělení procesu ověřování a atestace do několika fází, přičemž v každé fázi se provádějí odpovídající testy.
Rýže. 20.3. Plánování testů během vývoje a testování
V procesu plánování ověřování a certifikace je nutné určit vztah mezi statickými a dynamickými metodami pro kontrolu systému, stanovit standardy a postupy pro kontrolu a testování softwaru, schválit technologická mapa revize softwaru (viz oddíl 19.2) a vypracování plánu testování softwaru. Zda je důležitější kontrola nebo testování, závisí na typu vyvíjeného systému a zkušenostech organizace. Čím kritičtější je systém, tím větší pozornost by měla být věnována metodám statického ověřování.
Plán ověřování a validace se zaměřuje spíše na standardy testovacího procesu než na popis konkrétních testů. Tento plán není jen orientační, je určen hlavně pro odborníky na vývoj a testování systémů. Plán umožňuje technickému personálu získat úplný obrázek o testech systému a plánovat svou práci v tomto kontextu. Plán navíc poskytuje informace manažerům, kteří jsou zodpovědní za to, že testovací tým má veškerý potřebný hardware a software.
Testovací plán není pevný dokument. Měl by být pravidelně kontrolován, protože testování závisí na procesu implementace systému. Pokud například není dokončena implementace některé části systému, není možné otestovat sestavení systému. Proto musí být plán pravidelně revidován, aby bylo možné zkušební personál využít v jiných zaměstnáních.
Tyto dva pojmy validace a ověřování jsou často zaměňovány. Ověření systémových požadavků je navíc často zaměňováno s ověřováním systému. Doporučuji se na tento problém podívat.
V článku jsem zvažoval dva přístupy k objektovému modelování: jako celek a jako strukturu. V aktuálním článku budeme toto rozdělení potřebovat.
Předpokládejme, že máme navržený funkční objekt. Nechť je tento objekt námi uvažován jako součást stavby jiného funkčního objektu. Nechť je popis konstrukce objektu takový, aby obsahoval popis objektu. V takovém popisu má objekt popis jako celek, to znamená, že jeho rozhraní interakce s jinými objekty jsou popsána v rámci konstrukce objektu. Nechť je uveden popis objektu jako struktury. Nechť existuje informační objekt obsahující požadavky na návrh popisu objektu jako konstrukce. Nechť existuje soubor znalostí, který obsahuje odvozovací pravidla, na jejichž základě se získá popis objektu jako struktury z popisu objektu jako celku. Soubor znalostí je to, co se designéři učí v ústavech – hodně, hodně znalostí. Umožňují na základě znalostí o objektu navrhnout jeho strukturu.
Takže můžete začít. Můžeme tvrdit, že pokud je objekt jako celek správně popsán, je-li soubor znalostí správný a byla-li dodržena pravidla vyvozování, pak bude výsledný popis konstrukce objektu správný. Tedy na základě tohoto popisu funkční objekt odpovídající reálných podmínkáchúkon. Jaká rizika mohou nastat:
1. Použití nesprávných znalostí o Předmětu. Model Předmětu v myslích lidí nemusí odpovídat realitě. Neznali skutečné nebezpečí například zemětřesení. V souladu s tím mohou být požadavky na objekt nesprávně formulovány.
2. Neúplný záznam znalostí o Předmětu – něco chybí, dělají se chyby. Věděli například o větrech, ale zapomněli to zmínit. To může vést k nedostatečně úplnému popisu požadavků na objekt.
3. Špatný soubor znalostí. Naučili nás přednost hmotnosti před ostatními parametry, ale ukázalo se, že musíme zvýšit rychlost.
4. Nesprávná aplikace odvozovacích pravidel na popis objektu. Logické chyby, něco chybí v požadavcích na návrh objektu, je porušena stopa požadavků.
5. Neúplný záznam získaných závěrů o návrhu systému. Se vším se počítalo, se vším se počítalo, ale zapomněli napsat.
6. Vytvořený systém neodpovídá popisu.
Je jasné, že všechny artefakty projektu se zpravidla objeví ve své dokončené podobě až na konci projektu, a i to ne vždy. Ale pokud předpokládáme, že vývoj je vodopád, pak jsou rizika taková, jak jsem popsal. Kontrola každého rizika je specifická operace, kterou lze pojmenovat. Pokud má někdo zájem, můžete zkusit tyto podmínky vymyslet a vyslovit.
Co je ověření? V ruštině je ověření kontrolou dodržování pravidel. Pravidla jsou ve formě dokumentu. To znamená, že by měl existovat dokument s požadavky na dokumentaci. Pokud dokumentace splňuje požadavky tohoto dokumentu, prošla ověřením.
Co je validace? Validace je v ruštině ověření správnosti závěrů. To znamená, že by měl existovat soubor znalostí, který popisuje, jak získat popis návrhu na základě objektových dat. Kontrola správnosti aplikace těchto závěrů je validací. Validace je mimo jiné kontrola konzistence, úplnosti a srozumitelnosti popisu.
Validace požadavků je často zaměňována s validací produktu postaveného na těchto požadavcích. Nemá cenu to dělat.
