Testování bílá krabice
Testování použitelnosti
A) Zátěžové zkoušky
Testování výkonu
Funkční testování
Testování software
Testování je proces spouštění programu (nebo části programu) se záměrem (nebo účelem) najít chyby.
Existuje několik kritérií, podle kterých je obvyklé klasifikovat typy testování. Obvykle se rozlišují následující znaky:
I) Podle předmětu testování:
(určení nebo shromažďování ukazatelů výkonu a doby odezvy softwarového a hardwarového systému nebo zařízení v reakci na externí požadavek za účelem zjištění souladu s požadavky na tento systém)
b) Zátěžové testování
(hodnotí spolehlivost a stabilitu systému v podmínkách překročení limitů běžného provozu.)
c) Testování stability
4) Testování uživatelského rozhraní
5) Bezpečnostní testování
6) Testování lokalizace
7) Testování kompatibility
II) Podle znalosti systému:
1) Testování černé skříňky
(testuje se objekt, jehož vnitřní struktura není známa)
(kontroluje se vnitřní struktura programu, testovací data se získávají analýzou logiky programu)
III) Podle stupně automatizace:
1) Ruční testování
2) Automatizované testování
3) Poloautomatické testování
IV) Podle stupně izolace složek:
1) Testování součástek (jednotek).
2) Integrační testování
3) Testování systému
V) V době testování:
1) Alfa testování- uzavřený proces testování programu vývojáři nebo testery na plný úvazek. Alfa produkt je nejčastěji hotový jen z 50 %, existuje programový kód, ale chybí podstatná část designu.
2) Beta testování- těžké používání hotová verze programů s cílem identifikovat maximální počet chyb ve své práci pro jejich následné odstranění před konečným vstupem na trh, k masovému spotřebiteli. Do testování se zapojují dobrovolníci z řad běžných budoucích uživatelů.
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) splňuje požadavky, je implementován bez nezamýšlených funkcí a splňuje specifikace návrhu a normy ( ISO 9000-2000). 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ílná součást ověřovací proces.
Petrohrad
Státní elektrotechnická univerzita
oddělení MOEM
disciplínou
"Proces vývoje softwaru"
"Ověření softwaru"
Petrohrad
Účel ověření……………………………………………………………………… strana 3
Úvodní poznámky……………………………………………………………….. strana 3
Zvláštní a obecné cíle……………………………………………….. strana 4
Očekávané cvičení podle cílů……………………………………… strana 4
SG1 Příprava na ověření………………………………………………………..... strana 4
SG2 Provádění zkoušek (peer assessment)……………………………… strana 7
SG3 Implementace verifikace………………………………………………..... strana 9
Dodatek 1. Přehled automatizačních nástrojů pro proces ověřování……….. strana 11
Příloha 2. Hlavní moderní přístupy k ověření ……………….. strana 12
Seznam použité literatury……………………………………………….. strana 14
Integrovaný model dokonalosti a vyspělosti
Ověření (vyspělost 3)
cílová
Účelem ověření je poskytuje záruku, že vybraný middleware nebo koncový produkt splňuje specifikované požadavky.
vodní poznámky
Ověřování softwarových produktů je ověření hotového výrobku nebo jeho meziverzí aby byly splněny původní požadavky. To znamená nejen testování samotného programu, ale také auditování projektu, uživatelské a technické dokumentace atd.
Účelem ověřování softwarového systému je identifikovat a hlásit chyby, ke kterým může dojít během fází životního cyklu. Hlavní úkoly ověřování:
stanovení souladu požadavků vysoké úrovně se systémovými požadavky;
zohlednění požadavků vysoké úrovně v architektuře systému;
soulad s architekturou a požadavky na ni ve zdrojovém kódu;
určení souladu spustitelného kódu s požadavky na systém;
stanovení prostředků použitých k řešení výše uvedených úkolů, které jsou technicky správné a dostatečně úplné.
Verifikace zahrnuje ověřování hotových výrobků a ověřování meziproduktů vůči všem vybraným požadavkům, včetně požadavků zákazníků, požadavků na hotové výrobky a požadavků na jeho jednotlivé komponenty.
Verifikace je ze své podstaty inkrementální (inkrementální) proces od okamžiku svého vzniku po celou dobu vývoje produktů a veškeré práce na produktech. Verifikace začíná ověřením požadavků, poté následuje ověření všech meziproduktů v různých fázích jejich vývoje a výroby a končí ověřením finálního výrobku.
Ověřování meziproduktů v každé fázi jejich vývoje a výroby výrazně zvyšuje pravděpodobnost, že finální výrobek bude splňovat požadavky zákazníka, požadavky na hotový výrobek a požadavky na jeho jednotlivé komponenty.
Verifikace a Validace procesů jsou v podstatě příbuzné procesy, jejichž cílem je však získat různé výsledky. Účelem Validace je prokázat, že hotový produkt skutečně plní svůj původní účel. Cílem ověření je ujistit se, že produkt přesně splňuje určité požadavky. Jinými slovy, Ověření zajišťuje, že „ děláš to správně“ a Ověření je, že „ děláš správnou věc”.
Ověření by mělo být provedeno co nejdříve v příslušných procesech (jako je dodávka, vývoj, provoz nebo údržba), aby se vyhodnotila nákladová efektivita a výkon. Tento proces může zahrnovat analýzu, ověřování a testování (testování).
Tento proces lze provádět s různou mírou nezávislosti účinkujících. Míra nezávislosti výkonných umělců může být rozdělena jak mezi různé subjekty v organizaci samotné, tak subjekty v jiné organizaci, s různou mírou rozdělení odpovědnosti. Tento proces se nazývá proces nezávislé ověření pokud je implementující organizace nezávislá na prodejci, vývojáři, provozovateli nebo správci.
Odborné posudky (odbornost) jsou důležitou součástí verifikace jako osvědčený nástroj pro efektivní odstraňování závad. Důležitým závěrem je potřeba vyvinout hlubší porozumění a porozumění pracovním verzím produktu, stejně jako pracovním postupům používaným k identifikaci možných závad a vytvoření příležitosti ke zlepšení, pokud je to nutné.
Součástí zkoušek je metodická studie prací prováděných odborníky za účelem zjištění závad a dalších požadovaných změn.
Hlavní metody odborného posouzení jsou:
inspekce
end-to-end strukturální kontrola
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 Objektu. 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.
tým zahrnuje více než dva lidi nevyhnutelně vyvolává otázku rozdělení rolí, práv a povinností v týmu. Konkrétní soubor rolí je určen mnoha faktory – počtem účastníků vývoje a jejich osobními preferencemi, přijatou metodikou rozvoje, vlastnostmi projektu a dalšími faktory. Téměř v každém vývojovém týmu lze rozlišit následující role. Některé z nich mohou zcela chybět, přičemž jednotliví lidé mohou plnit více rolí najednou, ale celková kompozice se mění jen málo.Zákazník (žadatel). Tato role náleží zástupci organizace, která objednala vyvíjený systém. Žadatel je obvykle omezen ve své interakci a komunikuje pouze s projektovými manažery a specialistou na certifikaci nebo implementaci. Obvykle má zákazník právo měnit požadavky na produkt (pouze ve spolupráci s manažery), číst projektovou a certifikační dokumentaci, která ovlivňuje netechnické vlastnosti vyvíjeného systému.
Projektový manažer. Tato role poskytuje komunikační kanál mezi zákazníkem a projektovým týmem. Produktový manažer řídí očekávání zákazníka a rozvíjí a udržuje obchodní kontext projektu. Jeho práce přímo nesouvisí s prodejem, je zaměřen na produkt, jeho úkolem je definovat a poskytovat požadavky zákazníka. Projektový manažer má právo měnit požadavky na produkt a finální dokumentaci k produktu.
Programový manažer. Tato role řídí komunikaci a vztahy v rámci projektového týmu, působí určitým způsobem jako koordinátor, vyvíjí a spravuje funkční specifikace, udržuje harmonogram projektu a podává zprávy o stavu projektu a iniciuje zásadní rozhodnutí pro projekt.
Testování- proces spouštění programu za účelem zjištění chyby.
testovací data- vstupy, které se používají k testování systému.
Testovací situace (testovací případ)- vstupy pro testování systému a očekávané výstupy v závislosti na vstupech, pokud systém pracuje v souladu se specifikací požadavků.
Dobrý testovací případ- situace, která má vysokou pravděpodobnost odhalení dosud nezjištěné chyby.
test štěstí- test, který odhalí dosud nezjištěnou chybu.
Chyba- činnost programátora ve fázi vývoje vedoucí k tomu, že software obsahuje vnitřní vadu, která při provozu programu může vést k nesprávnému výsledku.
Zamítnutí- nepředvídatelné chování systému, vedoucí k neočekávanému výsledku, který by mohl být způsoben závadami v něm obsaženými.
V procesu testování softwaru se tedy zpravidla kontroluje následující.
Ověření a ověření ( ověřování a validace-PROTI& proti) jsou navrženy tak, aby analyzovaly, ověřovaly správné provedení a shodu softwaru se specifikacemi a požadavky zákazníka. Tyto metody kontroly správnosti programů a systémů znamenají:
- ověření je ověření správnosti vytvoření systému v souladu s jeho specifikací;
- Validace je ověření správnosti plnění zadaných požadavků na systém.
Verifikace pomáhá učinit závěr o správnosti vytvořeného systému po dokončení jeho návrhu a vývoje. Validace vám umožňuje stanovit proveditelnost specifikovaných požadavků a zahrnuje řadu akcí pro získání správných programů a systémů, jmenovitě:
- plánování inspekcí a kontrolních postupů designová rozhodnutí a požadavky;
- poskytování úrovně automatizace návrhu programu pomocí CASE-prostředků;
- kontrola správného fungování programů testovacími metodami na sadách cílových testů;
- přizpůsobení produktu provoznímu prostředí atd.
Validace provádí tyto činnosti přezkoumáním a inspekcí specifikací a výstupů návrhu ve fázích životního cyklu, aby se potvrdilo, že došlo ke správné implementaci počátečních požadavků a že jsou splněny stanovené podmínky a omezení. Úkoly ověřování a validace zahrnují kontrolu úplnosti, konzistence a jednoznačnosti specifikace požadavků a správnosti plnění funkcí systému.
Ověření a ověření podléhají:
- hlavní součásti systému;
- rozhraní komponent (softwarové, technické a informační) a interakce objektů (protokoly a zprávy), které zajišťují implementaci systému v distribuovaných prostředích;
- prostředky přístupu k databázi a souborům (transakce a zprávy) a ověřování prostředků ochrany před neoprávněným přístupem k údajům různých uživatelů;
- dokumentace pro software a pro systém jako celek;
- testy, zkušební postupy a vstupní data.
Jinými slovy, hlavní systematické metody správnosti programu jsou:
- ověření validace PS komponent a specifikace požadavků;
- Kontrola PS stanovit shodu programu s danými specifikacemi;
- testování výstupní kód PS na testovacích datech ve specifickém operačním prostředí k identifikaci chyb a defektů způsobených různými závadami, anomáliemi, poruchami zařízení nebo havárií systému (viz kapitola 9).
ISO/IEC 3918-99 a 12207 zahrnují procesy ověřování a validace. Pro ně jsou definovány cíle, úkoly a akce k ověření správnosti vytvořeného produktu (včetně pracovních, meziproduktů) ve fázích životního cyklu a souladu s jeho požadavky.
Hlavním úkolem verifikačních a validačních procesů je zkontrolovat a potvrditže konečný software je vhodný pro daný účel a splňuje požadavky zákazníka. Tyto procesy vám umožňují identifikovat chyby v pracovních produktech fází životního cyklu, aniž byste zjišťovali důvody jejich výskytu, a také stanovit správnost softwaru ve vztahu k jeho specifikaci.
Tyto procesy spolu souvisí a jsou definovány jedním pojmem – „verifikace a validace“ (V&V 7).
Ověření se provádí:
- ověření správnosti překladu jednotlivých komponent do výstupního kódu, jakož i popisů rozhraní sledováním vztahů komponent v souladu se zadanými požadavky zákazníka;
- analýza správnosti přístupu k souborům nebo databázi s přihlédnutím k postupům přijatým v nástrojích systému používaných pro manipulaci s daty a předávání výsledků;
- ověření prostředků ochrany součástí pro shodu s požadavky zákazníka a jejich dohledání.
Po kontrole jednotlivých komponent systému je provedena jejich integrace, ověření a validace integrovaného systému. Systém je testován na množství testovacích sad, aby se zjistilo, zda jsou testovací sady adekvátní a dostatečné pro dokončení testu a stanovení správnosti systému.
Myšlenku vytvoření mezinárodního projektu o formální verifikace navrhl T. Hoare, byla diskutována na sympoziu o ověřeném softwaru v únoru 2005 v Kalifornii. V říjnu téhož roku byl na konferenci IFIP v Curychu přijat mezinárodní projekt na dobu 15 let s cílem vyvinout „holistický automatizovaný soubor nástrojů pro kontrolu správnosti PS“.
Formuloval tyto hlavní úkoly:
- vývoj jednotné teorie konstrukce a analýzy programů;
- vybudování komplexní integrované sady ověřovacích nástrojů pro všechny fáze výroby, včetně vývoje specifikací a jejich ověřování, generování testovacích případů, zdokonalování, analýzy a ověřování programů;
- vytvoření úložiště formálních specifikací a ověřených softwarových objektů odlišné typy a typy.
Tento projekt předpokládá, že verifikace pokryje všechny aspekty tvorby a kontroly správnosti softwaru a stane se všelékem na všechny potíže spojené s neustálým výskytem chyb ve vytvářených programech.
V praxi bylo vyzkoušeno mnoho formálních metod pro dokazování a ověřování stanovených programů. Hotovo velká práce mezinárodní komise ISO/IEC v rámci norma ISO/ IEC 12207:2002 o standardizaci procesů verifikace a validace softwaru. Slibná je kontrola správnosti formálními metodami různých programovacích objektů.
Úložiště je úložiště programů, specifikací a nástrojů používaných při vývoji a testování, hodnocení hotových komponent, nástrojů a polotovarů metod. Má tyto obecné úkoly:
- akumulace ověřených specifikací, metod důkazů, programových objektů a implementací kódu pro komplexní aplikace;
- kumulace různých ověřovacích metod, jejich návrh ve formě vhodné pro hledání a výběr realizované teoretické myšlenky pro další aplikaci;
- vývoj standardních formulářů pro nastavení a výměnu formálních specifikací různých programovacích objektů, jakož i nástrojů a hotových systémů;
- vývoj interoperability a interakčních mechanismů pro přenos hotových ověřených produktů z úložiště do nových distribuovaných a síťových prostředí za účelem vytvoření nových PS.
Tento projekt by měl být vypracován do 50 let. Dřívější projekty si stanovily podobné cíle: zlepšení kvality softwaru, formalizace modelů služeb, snížení složitosti pomocí PIC, vytvoření ladicích nástrojů pro vizuální diagnostiku chyb a jejich odstranění atd. K zásadní změně v programování však nedošlo ani v smysl pro vizuální ladění nebo v dosahování Vysoká kvalita NA. Proces vývoje pokračuje.
Nový mezinárodní projekt ověřování softwaru vyžaduje od svých účastníků nejen znalosti teoretické aspekty specifikace programu, ale také vysoce kvalifikované programátory pro jeho implementaci v následujících letech.
