Cieľom tohto kurzu je predstaviť komplexný pohľad na proces overovania softvéru. Predmetom diskusie sú rôzne prístupy a metódy používané v oblasti overovania a najmä testovania softvéru. Predpokladá sa, že vyvíjaný softvér je súčasťou všeobecnejšieho systému. Takýto systém zahŕňa hardvérové, informačné a organizačné komponenty (ľudský používateľ, ľudský operátor atď.), ktoré môžu byť vyvinuté rôznymi tímami. Preto sú potrebné vývojové dokumenty, ktoré definujú požiadavky na rôzne komponenty systému a pravidlá ich interakcie. Okrem toho sa predpokladá, že zlyhania systému môžu viesť k následkom tej či onej závažnosti, preto je pri vývoji softvéru potrebné a opodstatnené úsilie vynaložené na identifikáciu skrytých chýb. V prvom rade ide o nástroje a postupy overovania softvéru. Kurz obsahuje množstvo praktických cvičení, ktoré na príklade jednoduchého systému ilustrujú techniky a metódy verifikácie softvéru v prostredí Microsoft Visual Studio 2005 Team Edition for Software Testers. Táto publikácia je súčasťou knižnice kurzov, ktorá sa vyvíja ako súčasť programu akademickej spolupráce MSDN Academic Alliance (MSDN AA).
Nižšie uvedený text je získaný automatickou extrakciou z pôvodného PDF dokumentu a slúži ako náhľad.
Chýbajú obrázky (obrázky, vzorce, grafy).
Ryža. 7 Testovanie, overovanie a validácia Overovanie softvéru je všeobecnejší pojem ako testovanie. Účelom overenia je zabezpečiť, aby overovaná položka (požiadavky alebo programový kód) spĺňala požiadavky, bola implementovaná bez neúmyselných funkcií a spĺňala konštrukčné špecifikácie a normy. Proces overovania zahŕňa inšpekcie, testovanie kódu, analýzu výsledkov testov, generovanie a analýzu správ o problémoch. Preto sa všeobecne uznáva, že proces testovania je neoddeliteľnou súčasťou procesu overovania a rovnaký predpoklad sa používa aj v tomto školiacom kurze. Validácia softvérového systému je proces, ktorého účelom je dokázať, že vývojom systému sme dosiahli ciele, ktoré sme jeho používaním plánovali dosiahnuť. Inými slovami, validácia je kontrola, či systém spĺňa očakávania zákazníka. Otázky súvisiace s validáciou presahujú rámec tohto školiaceho kurzu a predstavujú samostatnú zaujímavú tému na štúdium. Ak sa pozriete na tieto tri procesy z hľadiska otázky, na ktorú odpovedajú, testovanie odpovedá na otázku „Ako sa to robí? alebo „Spĺňa správanie vyvinutého programu požiadavky?“, overenie – „Čo sa urobilo?“ alebo „Spĺňa vyvinutý systém požiadavky?“ a validácia je „Urobil, čo bolo potrebné?“ alebo "Spĺňa vyvinutý systém očakávania zákazníka?" 1.7. Dokumentácia vytvorená v rôznych fázach životného cyklu K synchronizácii všetkých fáz vývoja dochádza pomocou dokumentov, ktoré sa vytvárajú v každej fáze. V tomto prípade sa dokumentácia vytvára tak na priamom segmente životného cyklu - pri vývoji softvérového systému, ako aj na opačnom - pri jeho overovaní. Pokúsme sa na príklade životného cyklu v tvare V vysledovať, aké typy dokumentov sa vytvárajú na každom zo segmentov a aké vzťahy medzi nimi existujú (obr. 8). Výsledkom štádia vývoja systémových požiadaviek sú formulované požiadavky na systém - dokument popisujúci všeobecné princípy fungovania systému, jeho interakciu s „prostredím“ - používateľmi systému, ako aj softvér a hardvér, ktorý zabezpečiť jeho prevádzku. Typicky sa súbežne so systémovými požiadavkami vytvára plán overovania a definuje sa stratégia overovania. Tieto dokumenty definujú všeobecný prístup k tomu, ako sa bude testovanie vykonávať, aké techniky sa použijú a aké aspekty budúceho systému bude potrebné dôkladne otestovať. Ďalšou úlohou riešenou definovaním stratégie overovania je určenie umiestnenia rôznych procesov overovania a ich prepojenia s procesmi vývoja. 20 Proces overovania pracujúci so systémovými požiadavkami je proces overovania požiadaviek a ich porovnávania so skutočnými očakávaniami zákazníka. Pri pohľade do budúcnosti povedzme, že proces validácie sa líši od akceptačných testov vykonávaných pri odovzdávaní hotového systému zákazníkovi, hoci ho možno považovať za súčasť takýchto testov. Validácia je prostriedkom na preukázanie nielen správnosti implementácie systému z pohľadu zákazníka, ale aj správnosti princípov jeho vývoja. Ryža. 8 Procesy a dokumenty pri vývoji softvérových systémov Systémové požiadavky sú základom pre proces vývoja funkčných požiadaviek a architektúry projektu. Počas tohto procesu sa vyvinú všeobecné požiadavky na systémový softvér a funkcie, ktoré musí vykonávať. Funkčné požiadavky často zahŕňajú definovanie vzorcov správania systému v normálnych a abnormálnych situáciách, pravidlá pre spracovanie údajov a definície používateľského rozhrania. Text požiadavky spravidla obsahuje slová „musí, musí“ a má štruktúru v tvare „Ak hodnota teploty na snímači ABC dosiahne 30 stupňov Celzia alebo viac, systém musí zastaviť vydávanie zvukového signálu. “ Funkčné požiadavky sú základom pre vývoj architektúry systému - popis jeho štruktúry z hľadiska subsystémov a štruktúrnych jednotiek jazyka, v ktorom sa implementácia vykonáva - oblasti, triedy, moduly, funkcie atď. Na základe funkčných požiadaviek sú spísané požiadavky na skúšky – dokumenty obsahujúce definíciu kľúčových bodov, ktoré je potrebné skontrolovať, aby sa zabezpečila správna implementácia funkčných požiadaviek. Požiadavky na test často začínajú slovami „Test That“ a obsahujú odkazy na ich zodpovedajúce funkčné požiadavky. Príklad testovacích požiadaviek pre vyššie uvedenú funkčnú požiadavku by bol „Overte, že keď teplota na snímači ABC klesne pod 30 stupňov Celzia, systém vydá varovné pípnutie“ a „Overte, že keď je hodnota teploty na snímači ABC vyššia ako 30 stupňov Celzia“, systém nevydáva zvukový signál." 21 Jedným z problémov, ktorý vzniká pri písaní požiadaviek na test, je zásadná netestovateľnosť niektorých požiadaviek, napríklad požiadavku „Používateľské rozhranie musí byť intuitívne“ nemožno overiť bez jasnej definície toho, čo predstavuje intuitívne rozhranie. Takéto nešpecifické funkčné požiadavky sa zvyčajne následne upravujú. Architektonické vlastnosti systému môžu slúžiť aj ako zdroj pre vytváranie testovacích požiadaviek, ktoré zohľadňujú vlastnosti softvérovej implementácie systému. Príkladom takejto požiadavky je napríklad „Skontrolujte, či hodnota teploty na snímači ABC nepresahuje 255“. Na základe funkčných požiadaviek a architektúry je napísaný systémový kód a na jeho overenie je na základe testovacích požiadaviek pripravený testovací plán - popis postupnosti testovacích prípadov, ktoré kontrolujú súlad implementácie systému s požiadavkami. Každý testovací prípad obsahuje špecifický popis hodnôt dodaných na vstup systému, hodnoty očakávané na výstupe a popis scenára vykonávania testu. V závislosti od testovacieho objektu môže byť testovací plán pripravený buď vo forme programu v niektorom programovacom jazyku, alebo vo forme vstupného dátového súboru pre sadu nástrojov, ktorá spúšťa testovaný systém a prenáša do neho hodnoty. V dôsledku vykonania všetkých testovacích prípadov sa zhromažďujú štatistiky o úspešnosti testovania - percento testovacích prípadov, pre ktoré sa skutočné výstupné hodnoty zhodovali s očakávanými, takzvané úspešné testy. Neúspešné testy sú počiatočnými údajmi pre analýzu príčin chýb a ich následnú opravu. Vo fáze integrácie sa jednotlivé moduly systému poskladajú do jedného celku a vykonajú sa testovacie prípady, ktoré preveria celú funkčnosť systému. V poslednej fáze je hotový systém dodaný zákazníkovi. Pred implementáciou zákaznícki špecialisti spolu s vývojármi vykonajú akceptačné testy - kontrolujú funkcie kritické pre užívateľa v súlade s vopred schváleným testovacím programom. Ak sú testy úspešne ukončené, systém sa odovzdá zákazníkovi, v opačnom prípade je odoslaný na revíziu. 1.8. Typy procesov testovania a overovania a ich miesto v rôznych modeloch životného cyklu 1.8.1. Testovanie jednotiek Malé moduly (postupy, triedy atď.) podliehajú testovaniu jednotiek. Pri testovaní relatívne malého modulu s veľkosťou 100-1000 riadkov je možné skontrolovať, ak nie všetky, tak aspoň veľa logických vetiev v implementácii, rôzne cesty v grafe závislosti dát a hraničné hodnoty parametrov. V súlade s tým sú konštruované kritériá pokrytia testov (sú pokryté všetky operátory, všetky logické vetvy, všetky hraničné body atď.). . Testovanie jednotiek sa zvyčajne vykonáva na každom nezávislom softvérovom module a je pravdepodobne najbežnejším typom testovania, najmä pre malé až stredne veľké systémy. 1.8.2. Integračné testovanie Kontrola správnosti všetkých modulov, žiaľ, nezaručuje správne fungovanie systému modulov. V literatúre sa niekedy diskutuje 22 o „klasickom“ modeli nesprávnej organizácie testovania systému modulov, často nazývanom metóda „veľkého skoku“. Podstatou metódy je najprv otestovať každý modul samostatne, potom ich spojiť do systému a otestovať celý systém. Pre veľké systémy je to nereálne. S týmto prístupom sa veľa času strávi lokalizáciou chýb a kvalita testovania zostane nízka. Alternatívou k „veľkému skoku“ je integračné testovanie, kedy sa systém stavia na etapy, skupiny modulov sa pridávajú postupne. 1.8.3. Systémové testovanie Plne implementovaný softvérový produkt je predmetom systémového testovania. Testera v tejto fáze nezaujíma správna implementácia jednotlivých postupov a metód, ale celý program ako celok, ako ho vidí koncový používateľ. Testy vychádzajú zo všeobecných požiadaviek na program, medzi ktoré patrí nielen správna implementácia funkcií, ale aj výkon, doba odozvy, odolnosť voči zlyhaniam, útokom, chybám používateľov atď. Na testovanie systému a komponentov sa používajú špecifické typy kritérií pokrytia testov (napríklad sú pokryté všetky typické pracovné scenáre, všetky scenáre s abnormálnymi situáciami, párové zloženie scenárov atď.). 1.8.4. Testovanie záťaže Testovanie záťaže poskytuje nielen prediktívne údaje o výkone systému pri záťaži, ktoré usmerňujú architektonické rozhodnutia, ale poskytuje aj prevádzkové informácie tímom technickej podpory, ako aj projektovým a konfiguračným manažérom, ktorí sú zodpovední za vytváranie najproduktívnejších hardvérových a softvérových konfigurácií. Záťažové testovanie umožňuje vývojovému tímu robiť informovanejšie rozhodnutia zamerané na vývoj optimálnych architektonických kompozícií. Zákazník zo svojej strany dostane možnosť vykonať akceptačné testy za podmienok blízkych skutočným. 1.8.5. Formálne kontroly Formálna kontrola je jedným zo spôsobov, ako overiť dokumenty a programový kód vytvorený počas procesu vývoja softvéru. Počas formálnej kontroly tím špecialistov nezávisle overuje zhodu kontrolovaných dokumentov s originálnymi dokumentmi. Nezávislosť inšpekcie je zabezpečená tým, že ju vykonávajú inšpektori, ktorí sa nepodieľali na vypracovaní kontrolovaného dokumentu. 1.9. Overenie certifikovaného softvéru Uveďme niekoľko definícií, ktoré definujú všeobecnú štruktúru procesu certifikácie softvéru: Certifikácia softvéru je proces potvrdenia a oficiálneho uznania, že vývoj softvéru bol vykonaný v súlade s určitými požiadavkami. Počas procesu certifikácie dochádza k interakcii medzi žiadateľom, certifikačným orgánom a dozorným orgánom. Žiadateľom je organizácia, ktorá podáva žiadosť príslušnému certifikačnému orgánu o získanie certifikátu (zhody, kvality, vhodnosti atď.). produktu. Certifikačný orgán je organizácia, ktorá posudzuje žiadosť Žiadateľa o certifikáciu softvéru a buď samostatne, alebo vytvorením špeciálnej komisie vykoná súbor postupov zameraných na vykonanie procesu certifikácie softvéru Žiadateľa. 23 Dozorný orgán - komisia odborníkov, ktorí sledujú procesy vývoja certifikovaného informačného systému žiadateľa a vyjadrujú sa k súladu tohto procesu s určitými požiadavkami, ktoré predkladajú na posúdenie certifikačnému orgánu. Certifikácia môže byť zameraná na získanie certifikátu zhody alebo certifikátu kvality. V prvom prípade je výsledkom certifikácie uznanie súladu vývojových procesov s určitými kritériami a funkčnosti systému s určitými požiadavkami. Príkladom takýchto požiadaviek sú usmernenia Federálnej služby pre technickú a exportnú kontrolu v oblasti bezpečnosti softvérových systémov. V druhom prípade je výsledkom uznanie súladu vývojových procesov s určitými kritériami, ktoré zaručujú primeranú úroveň kvality vyrábaného produktu a jeho vhodnosť na použitie v určitých podmienkach. Príkladom takýchto noriem je séria medzinárodných noriem kvality ISO 9000:2000 (GOST R ISO 9000-2001) alebo leteckých noriem DO-178B, AS9100, AS9006. Testovanie certifikovateľného softvéru má dva doplnkové účely: Prvým účelom je preukázať, že softvér spĺňa požiadavky naň. Druhým cieľom je s vysokou mierou istoty preukázať, že chyby, ktoré by mohli viesť k neprijateľným poruchovým situáciám, ako sú definované v procese hodnotenia bezpečnosti systému, sú identifikované počas procesu testovania. Napríklad DO-178B vyžaduje na splnenie cieľov testovania softvéru nasledovné: Testy musia byť primárne založené na softvérových požiadavkách; Testy by mali byť navrhnuté tak, aby overili správne fungovanie a odhalili potenciálne chyby. Analýza úplnosti testov na základe softvérových požiadaviek by mala určiť, ktoré požiadavky sa netestujú. Analýza úplnosti testov na základe štruktúry programového kódu by mala určiť, ktoré štruktúry neboli počas testovania vykonané. Táto norma hovorí aj o testovaní založenom na požiadavkách. Zistilo sa, že táto stratégia je najúčinnejšia pri identifikácii chýb. Pokyny na výber testovacích prípadov na základe požiadaviek zahŕňajú nasledovné: Na dosiahnutie cieľov testovania softvéru sa musia vykonať dve kategórie testov: testy pre normálne situácie a testy pre abnormálne (nepožiadavky, robustné) situácie. Mali by sa vyvinúť špecifické testovacie prípady pre softvérové požiadavky a zdroje chýb, ktoré sú súčasťou procesu vývoja softvéru. Účelom testov pre bežné situácie je preukázať schopnosť softvéru reagovať na bežné vstupy a podmienky podľa potreby. 24 Účelom testov pre abnormálne situácie je preukázať schopnosť softvéru adekvátne reagovať na abnormálne vstupy a podmienky, inými slovami, nemal by spôsobiť zlyhanie systému. Kategórie porúch pre systém sú stanovené určením závažnosti poruchovej situácie lietadla a jeho cestujúcich. Akákoľvek chyba v softvéri môže spôsobiť poruchu, ktorá prispieva k poruchovej situácii. Úroveň integrity softvéru potrebná na bezpečnú prevádzku teda súvisí so situáciami zlyhania systému. Existuje 5 úrovní poruchových situácií od nevýznamných až po kriticky nebezpečné. Podľa týchto úrovní sa zavádza koncept úrovne kritickosti softvéru. Úroveň kritickosti určuje zloženie dokumentácie poskytovanej certifikačnému orgánu, a teda hĺbku procesov vývoja a overovania systému. Napríklad počet typov dokumentov a množstvo práce na vývoji systému potrebné na certifikáciu na najnižšiu úroveň kritickosti DO-178B sa môže líšiť o jeden až dva rády od počtu a rozsahu potrebného na certifikáciu na najvyššiu úroveň. Konkrétne požiadavky určuje norma, podľa ktorej sa certifikácia plánuje. 25 TÉMA 2. Kód testovacieho programu (2.-5. prednáška) 2.1. Úlohy a ciele testovania programového kódu Testovanie programového kódu je proces vykonávania programového kódu, ktorého cieľom je identifikovať chyby v ňom existujúce. Chybou sa tu rozumie úsek programového kódu, ktorého spustenie za určitých podmienok vedie k neočakávanému správaniu systému (t. j. správaniu, ktoré nespĺňa požiadavky). Neočakávané správanie systému môže viesť k poruchám a poruchám, v tomto prípade ide o významné chyby v programovom kóde. Niektoré závady spôsobujú menšie problémy, ktoré nenarúšajú fungovanie systému, no trochu sťažujú prácu s ním. V tomto prípade hovoria o stredných alebo menších chybách. Úlohou testovania týmto prístupom je určiť podmienky, za ktorých sa objavujú systémové chyby a tieto stavy zaznamenať. Testovacie úlohy zvyčajne nezahŕňajú identifikáciu konkrétnych defektných častí programového kódu a nikdy nezahŕňajú opravu defektov – ide o ladiacu úlohu, ktorá sa vykonáva na základe výsledkov testovania systému. Účelom použitia postupu testovania programového kódu je minimalizovať počet chýb, najmä tých významných, v konečnom produkte. Samotné testovanie nemôže zaručiť úplnú absenciu chýb v systémovom kóde. V kombinácii s overovacími a validačnými procesmi zameranými na odstránenie nejednotnosti a neúplnosti projektovej dokumentácie (najmä systémových požiadaviek) však dobre organizované testovanie poskytuje záruku, že systém spĺňa požiadavky a správa sa v súlade s nimi vo všetkých zamýšľaných situáciách. Pri vývoji systémov so zvýšenou spoľahlivosťou, napríklad leteckých, sa záruky spoľahlivosti dosahujú jasnou organizáciou procesu testovania, určením jeho prepojenia s inými procesmi životného cyklu a zavedením kvantitatívnych charakteristík, ktoré umožňujú posúdiť úspešnosť testovania. Navyše, čím vyššie sú požiadavky na spoľahlivosť systému (jeho úroveň kritickosti), tým prísnejšie sú požiadavky kladené. V prvom rade teda neberieme do úvahy konkrétne výsledky testovania konkrétneho systému, ale celkovú organizáciu testovacieho procesu s použitím prístupu „dobre organizovaný proces produkuje vysokokvalitný výsledok“. Tento prístup je spoločný pre mnohé medzinárodné a priemyselné štandardy kvality, ktoré budú podrobnejšie diskutované na konci tohto kurzu. Kvalita vyvinutého systému s týmto prístupom je dôsledkom organizovaného procesu vývoja a testovania, a nie nezávislým nekontrolovateľným výsledkom. Keďže moderné softvérové systémy sú pomerne veľké, pri testovaní ich programového kódu sa používa metóda funkčného rozkladu. Systém je rozdelený na samostatné moduly (triedy, menné priestory atď.), ktoré majú funkčnosť a rozhrania definované požiadavkami. Potom sa každý modul otestuje samostatne - vykoná sa testovanie jednotky. Potom sa jednotlivé moduly poskladajú do väčších konfigurácií – vykoná sa integračné testovanie a nakoniec sa otestuje systém ako celok – vykoná sa testovanie systému. Z hľadiska kódu majú jednotky, integrácia a testovanie systému veľa spoločného, preto sa táto téma zameria na testovanie jednotiek, pričom o vlastnostiach integrácie a testovania systému sa bude diskutovať neskôr. 26 Pri jednotkovom testovaní je každý modul testovaný tak na zhodu s požiadavkami, ako aj na absenciu problematických oblastí programového kódu, ktoré by mohli spôsobiť poruchy a poruchy v systéme. Moduly spravidla mimo systému nepracujú – prijímajú dáta z iných modulov, spracúvajú ich a prenášajú ďalej. Aby sa na jednej strane modul izoloval od systému a eliminoval sa vplyv prípadných systémových chýb a na druhej strane sa modulu poskytli všetky potrebné dáta, používa sa testovacie prostredie. Úlohou testovacieho prostredia je vytvoriť runtime prostredie pre modul a emulovať všetky externé rozhrania, ku ktorým modul pristupuje. Funkcie organizácie testovacieho prostredia budú diskutované v tejto téme. Typický testovací postup pozostáva z prípravy a vykonania testovacích prípadov (tiež nazývaných jednoducho testy). Každý testovací príklad kontroluje jednu „situáciu“ v správaní modulu a pozostáva zo zoznamu hodnôt odovzdaných na vstup modulu, popisu spustenia a vykonávania spracovania dát – testovacieho skriptu a zoznamu hodnoty, ktoré sa očakávajú na výstupe modulu, ak sa správa správne. Testovacie skripty sú zostavené tak, aby sa vylúčil prístup k interným údajom modulu, všetka interakcia by mala prebiehať iba cez jeho externé rozhrania. Vykonanie testovacieho prípadu je podporované testovacím prostredím, ktoré zahŕňa softvérovú implementáciu testovacieho skriptu. Spustenie začína odovzdaním vstupných údajov modulu a spustením skriptu. Aktuálne výstupné dáta prijaté z modulu ako výsledok vykonania skriptu sa uložia a porovnajú s očakávanými. Ak sa zhodujú, test sa považuje za úspešný, inak sa považuje za neúspešný. Každý neúspešný test indikuje buď chybu v testovanom module, alebo v testovacom prostredí, alebo v popise testu. Súbor popisov testovacích prípadov tvorí testovací plán - hlavný dokument, ktorý definuje testovací postup pre softvérový modul. Plán testovania špecifikuje nielen samotné testovacie prípady, ale aj poradie, v ktorom sa objavujú, čo môže byť tiež dôležité. Štruktúra a vlastnosti testovacích plánov budú diskutované v tejto téme problémy spojené s poradím testovacích prípadov budú diskutované v téme „Testovanie opakovateľnosti“. Pri testovaní je často potrebné brať do úvahy nielen systémové požiadavky, ale aj štruktúru programového kódu testovaného modulu. V tomto prípade sú testy navrhnuté tak, aby odhalili typické chyby programátora spôsobené nesprávnou interpretáciou požiadaviek. Používajú sa kontroly hraničných podmienok a kontroly tried ekvivalencie. Absencia schopností v systéme, ktoré nie sú špecifikované požiadavkami, je zaručená rôznymi odhadmi pokrytia programového kódu testami, t.j. odhad, aké percento určitých jazykových konštruktov je dokončených v dôsledku vykonania všetkých testovacích príkladov. To všetko sa bude diskutovať na konci tejto témy. 2.2. Skúšobné metódy 2.2.1. Čierna skrinka Hlavnou myšlienkou pri testovaní systému ako čiernej skrinky je, že všetky materiály, ktoré má tester k dispozícii, sú požiadavkami na systém, popisujúc jeho správanie a samotný systém, s ktorým môže pracovať len aplikovaním niektorých vonkajších vplyvov. jeho vstupy a pozorovanie výstupov nejaký výsledok. Všetky interné vlastnosti implementácie systému sú pred testerom skryté, systém je teda „čiernou skrinkou“, ktorej správne správanie vo vzťahu k požiadavkám je potrebné overiť. 27 Z pohľadu softvérového kódu môže byť čierna skrinka množina tried (alebo modulov) so známymi externými rozhraniami, ale nedostupnými zdrojovými kódmi. Hlavnou úlohou testera pri tejto testovacej metóde je dôsledne overovať, či správanie systému spĺňa požiadavky. Okrem toho musí tester skontrolovať fungovanie systému v kritických situáciách - čo sa stane, ak sa zadajú nesprávne vstupné hodnoty. V ideálnej situácii by mali byť všetky varianty kritických situácií popísané v systémových požiadavkách a tester môže prísť len s konkrétnymi testami týchto požiadaviek. V skutočnosti sa však v dôsledku testovania zvyčajne identifikujú dva typy systémových problémov: 1. Nekonzistentnosť správania systému s požiadavkami 2. Nevhodné správanie systému v situáciách, ktoré požiadavky neustanovujú. Oba typy problémov sú hlásené a hlásené vývojárom. Problémy prvého typu zároveň zvyčajne spôsobujú zmeny v programovom kóde, oveľa menej často - zmeny požiadaviek. Zmena požiadaviek môže byť v tomto prípade nevyhnutná z dôvodu ich nejednotnosti (niekoľko rôznych požiadaviek popisuje rôzne modely správania sa systému v rovnakej situácii) alebo nesprávnosti (požiadavky nezodpovedajú skutočnosti). Problémy druhého typu si jednoznačne vyžadujú zmenu požiadaviek z dôvodu ich nekompletnosti – požiadavky jednoznačne vynechávajú situáciu vedúcu k nevhodnému správaniu systému. Nevhodné správanie možno v tomto prípade chápať ako úplný kolaps systému, alebo vo všeobecnosti akékoľvek správanie, ktoré nie je popísané v požiadavkách. Testovanie čiernej skrinky sa tiež nazýva testovanie požiadaviek, pretože... toto je jediný zdroj informácií na zostavenie plánu testovania. 2.2.2. Sklenený (biely) box Pri testovaní systému ako preskleného boxu má tester prístup nielen k požiadavkám na systém, jeho vstupom a výstupom, ale aj k jeho vnútornej štruktúre – vidí jeho programový kód. Dostupnosť programového kódu rozširuje možnosti testera v tom, že môže vidieť zhodu požiadaviek s časťami programového kódu a tým zistiť, či existujú požiadavky na celý programový kód. Programový kód, pre ktorý neexistujú žiadne požiadavky, sa nazýva kód, na ktorý sa nevzťahujú požiadavky. Takýto kód je potenciálnym zdrojom nevhodného správania systému. Transparentnosť systému navyše umožňuje prehĺbiť analýzu jeho oblastí, ktoré spôsobujú problémy – často jeden problém neutralizuje druhý a nikdy sa nevyskytujú súčasne. 2.2.3. Testovanie modelov Testovanie modelov sa trochu líši od klasických metód overovania softvéru. V prvom rade je to spôsobené tým, že predmetom testovania nie je samotný systém, ale jeho model navrhnutý formálnymi prostriedkami. Ak ponecháme bokom otázky kontroly správnosti a použiteľnosti samotného modelu (predpokladá sa, že jeho správnosť a súlad s pôvodným systémom je možné preukázať formálnymi prostriedkami), potom má tester k dispozícii pomerne silný nástroj na analýzu celkovú integritu systému. Pri práci s modelom môžete vytvárať situácie, ktoré sa nedajú vytvoriť v testovacom laboratóriu pre reálny systém. Pri práci s modelom programového kódu systému môžete analyzovať jeho vlastnosti a také parametre systému, ako je optimálnosť algoritmov alebo jeho stabilita. 28 Modelové testovanie sa však nerozšírilo práve kvôli ťažkostiam, ktoré sa vyskytli pri vytváraní formálneho opisu správania systému. Jednou z mála výnimiek sú komunikačné systémy, ktorých algoritmický a matematický aparát je pomerne dobre rozvinutý. 2.2.4. Analýza programového kódu (inšpekcie) V mnohých situáciách je testovanie správania systému ako celku nemožné - jednotlivé sekcie programového kódu sa nemusia nikdy spustiť, ale budú pokryté požiadavkami. Príkladom takýchto sekcií kódu sú obslužné programy výnimiek. Ak si napríklad dva moduly navzájom odovzdávajú číselné hodnoty a funkcie kontroly hodnôt fungujú v oboch moduloch, potom sa funkcia kontroly prijímacieho modulu nikdy neaktivuje, pretože všetky chybné hodnoty budú vo vysielači odrezané. V tomto prípade sa vykoná manuálna analýza správnosti programového kódu, nazývaná aj kontrola kódu alebo inšpekcia. Ak sa v dôsledku kontroly zistia problémové oblasti, informácie o tom sa odošlú vývojárom na opravu spolu s výsledkami pravidelných testov. 2.3. Testovacie prostredie Väčšina testovania takmer každého zložitého systému sa zvyčajne vykonáva v automatickom režime. Okrem toho je testovaný systém zvyčajne rozdelený na samostatné moduly, z ktorých každý sa testuje najskôr oddelene od ostatných, potom ako celok. To znamená, že pre testovanie je potrebné vytvoriť prostredie, ktoré zabezpečí spustenie a spustenie testovaného modulu, prenesie do neho vstupné dáta a zbiera reálne výstupné dáta získané ako výsledok fungovania systému na danom vstupné Data. Potom musí prostredie porovnať skutočné výstupné dáta s očakávanými a na základe tohto porovnania urobiť záver o súlade správania modulu so zadaným (obr. 9).
20. Overenie a certifikácia softvéru
Verifikácia a validácia sú procesy testovania a kontroly, ktoré overujú, či softvér spĺňa jeho špecifikácie a požiadavky zákazníkov. Verifikácia a certifikácia pokrývajú celý životný cyklus softvéru – začínajú vo fáze analýzy požiadaviek a končia overením programového kódu vo fáze testovania hotového softvérového systému.
Overenie a certifikácia nie sú to isté, hoci je ľahké si ich pomýliť. Stručne, rozdiel medzi nimi možno definovať takto:
Verifikácia odpovedá na otázku, či bol systém vytvorený správne;
Certifikácia odpovedá na otázku, či systém funguje správne.
Podľa týchto definícií overenie overuje súlad softvéru so špecifikáciou systému, najmä s funkčnými a nefunkčnými požiadavkami. Certifikácia je všeobecnejší proces. Pri certifikácii je potrebné zabezpečiť, aby softvérový produkt spĺňal očakávania zákazníka. Certifikácia nasleduje po overení, aby sa zistilo, ako dobre systém spĺňa nielen špecifikácie, ale aj očakávania zákazníka.
Ako už bolo uvedené, v počiatočných fázach vývoja softvéru je veľmi dôležitá certifikácia systémových požiadaviek. Chyby a opomenutia sú v požiadavkách bežné; v takýchto prípadoch konečný produkt pravdepodobne nesplní očakávania zákazníka. Validácia požiadaviek však samozrejme nemôže identifikovať všetky problémy v špecifikácii požiadaviek. Niekedy sa nedostatky a chyby v požiadavkách zistia až po dokončení implementácie systému.
Procesy overovania a certifikácie využívajú dve hlavné techniky na overovanie a analýzu systémov.
1. Kontrola softvéru. Analyzujte a overujte rôzne reprezentácie systému, ako je dokumentácia so špecifikáciou požiadaviek, architektonické diagramy alebo zdrojový kód programu. Kontrola sa vykonáva vo všetkých fázach procesu vývoja softvérového systému. Súbežne s kontrolou je možné vykonávať automatickú analýzu zdrojového kódu programu a súvisiacich dokumentov. Inšpekcia a automatizovaná analýza sú statické overovacie a validačné metódy, pretože nevyžadujú spustiteľný systém.
2. Testovanie softvéru. Spustite spustiteľný kód s testovacími údajmi a preskúmajte výstupné a výkonnostné charakteristiky softvérového produktu, aby ste si overili, či systém funguje správne. Testovanie je dynamická metóda overovania a certifikácie, pretože sa aplikuje na bežiaci systém.
Na obr. Obrázok 20.1 ukazuje miesto kontroly a testovania v procese vývoja softvéru. Šípky označujú tie fázy vývojového procesu, v ktorých možno tieto metódy použiť. Podľa tejto schémy možno vykonať kontrolu vo všetkých fázach procesu vývoja systému a testovanie možno vykonať v prípadoch, keď bol vytvorený prototyp alebo spustiteľný program.
Metódy kontroly zahŕňajú: kontrolu programu, automatickú analýzu zdrojového kódu a formálne overenie. Ale statické metódy môžu kontrolovať len súlad programov so špecifikáciami, nemožno ich použiť na kontrolu správneho fungovania systému. Navyše nefunkčné charakteristiky ako výkon a spoľahlivosť nie je možné overiť pomocou statických metód. Preto sa na vyhodnotenie nefunkčných charakteristík vykonáva testovanie systému.
Ryža. 20.1. Statické a dynamické overovanie a certifikácia
Napriek širokému využívaniu kontroly softvéru je testovanie stále prevládajúcou metódou overovania a certifikácie. Testovanie je test fungovania programov s údajmi podobnými reálnym údajom, ktoré sa budú spracovávať počas prevádzky systému. Prítomnosť chýb a nezhôd v programe sa zisťuje preskúmaním výstupných údajov a identifikáciou anomálnych medzi nimi. Testovanie sa vykonáva vo fáze implementácie systému (na kontrolu, či systém spĺňa očakávania vývojárov) a po dokončení jeho implementácie.
V rôznych fázach procesu vývoja softvéru sa používajú rôzne typy testovania.
1. Testovanie defektov vykonávané na zistenie nezrovnalostí medzi programom a jeho špecifikáciou, ktoré sú spôsobené chybami alebo chybami v programoch. Takéto testy sú určené na identifikáciu chýb v systéme a nie na simuláciu jeho činnosti.
2. Štatistické testovanie vyhodnocuje výkon a spoľahlivosť programov, ako aj chod systému v rôznych prevádzkových režimoch. Testy sú určené na simuláciu reálnej prevádzky systému s reálnymi vstupnými údajmi. Spoľahlivosť systému sa hodnotí podľa počtu porúch zaznamenaných pri prevádzke programov. Výkon sa hodnotí meraním celkového času vykonávania operácií a času odozvy systému pri spracovaní testovacích údajov.
Hlavným účelom overovania a kvalifikácie je zabezpečiť, aby bol systém „vhodný na daný účel“. Súlad softvérového systému s určeným účelom neznamená, že by mal byť úplne bezchybný. Systém musí skôr primerane dobre slúžiť účelom, na ktoré bol určený. Úroveň požadovaného spoľahlivosť súladu závisí od účelu systému, očakávaní používateľov a podmienok na softvérovom trhu.
1. Účel softvéru.Úroveň dôvery v súlad závisí od toho, nakoľko kritický je vyvíjaný softvér podľa určitých kritérií. Napríklad úroveň spoľahlivosti systémov kritických z hľadiska bezpečnosti by mala byť výrazne vyššia ako úroveň spoľahlivosti prototypových softvérových systémov vyvinutých na demonštráciu niektorých nových nápadov.
2. Očakávania používateľov. Je smutné konštatovať, že v súčasnosti má väčšina používateľov nízke softvérové nároky. Používatelia sú tak zvyknutí na zlyhania, ktoré sa vyskytujú počas spustenia programov, že ich to neprekvapuje. Sú ochotní tolerovať zlyhania systému, ak výhody jeho používania prevažujú nad nevýhodami. Od začiatku 90. rokov však tolerancia používateľov voči poruchám softvérových systémov postupne klesá. V poslednej dobe je vytváranie nespoľahlivých systémov prakticky neprijateľné, preto spoločnosti vyvíjajúce softvérové produkty musia venovať čoraz väčšiu pozornosť overovaniu a certifikácii softvéru.
3. Podmienky na trhu so softvérom. Pri hodnotení softvérového systému musí predávajúci poznať konkurenčné systémy, cenu, ktorú je kupujúci ochotný za systém zaplatiť, a cieľový dátum uvedenia systému na trh. Ak má vývojárska spoločnosť viacero konkurentov, je potrebné určiť dátum vstupu systému na trh pred ukončením úplného testovania a ladenia, inak môžu byť konkurenti prví, ktorí vstúpia na trh. Ak zákazníci nie sú ochotní kupovať softvér za vysokú cenu, môžu byť ochotní tolerovať ďalšie zlyhania systému. Všetky tieto faktory treba brať do úvahy pri určovaní nákladov na proces overovania a certifikácie.
Pri overovaní a certifikácii sa spravidla zistia chyby v systéme. V systéme sa vykonávajú zmeny na opravu chýb. Toto proces ladenia Typicky integrované s inými procesmi overovania a kvalifikácie. Testovanie (alebo všeobecnejšie overovanie a certifikácia) a ladenie sú však rôzne procesy, ktoré majú rôzne ciele.
1. Verifikácia a certifikácia je proces zisťovania chýb v softvérovom systéme.
2. Ladenie je proces lokalizácie defektov (chýb) a ich opravy (obr. 20.2).
Ryža. 20.2. Proces ladenia
Neexistujú žiadne jednoduché metódy na ladenie programov. Skúsení debuggeri zisťujú chyby porovnaním vzorcov testovacieho výstupu s výstupom testovaných systémov. Lokalizácia chyby vyžaduje znalosť typov chýb, výstupných vzorov, programovacieho jazyka a procesu programovania. Znalosti o procese vývoja softvéru sú veľmi dôležité. Debuggery poznajú najčastejšie chyby programátora (napríklad tie, ktoré súvisia so zvýšením hodnoty počítadla). Do úvahy sa berú aj chyby typické pre určité programovacie jazyky, napríklad tie, ktoré súvisia s používaním ukazovateľov v jazyku C.
Lokalizácia chýb v programovom kóde nie je vždy jednoduchý proces, pretože chyba sa nemusí nevyhnutne nachádzať v blízkosti miesta v programovom kóde, kde sa problém vyskytol. Na lokalizáciu chýb programátor debuggeru vyvíja dodatočné softvérové testy, ktoré pomáhajú identifikovať zdroj chyby v programe. Môže byť potrebné manuálne sledovať spustenie programu.
Interaktívne nástroje na ladenie sú súčasťou sady nástrojov jazykovej podpory, ktoré sú integrované so systémom kompilácie kódu. Poskytujú špeciálne prostredie na vykonávanie programu, prostredníctvom ktorého je možné pristupovať k tabuľke identifikátorov a odtiaľ k premenným hodnotám. Používatelia často riadia vykonávanie programu krok za krokom, pričom postupujú od príkazu k príkazu. Po vykonaní každého príkazu sa skontrolujú hodnoty premenných a identifikujú sa možné chyby.
Chyba zistená v programe je opravená, po ktorej je potrebné znova skontrolovať program. Ak to chcete urobiť, môžete program znova skontrolovať alebo zopakovať predchádzajúce testovanie. Opätovné testovanie sa používa na zabezpečenie toho, aby zmeny vykonané v programe nezaviedli do systému nové chyby, pretože v praxi vysoké percento „oprav chýb“ buď úplne zlyhá, alebo do programu zavedie nové chyby.
V zásade by sa počas opätovného testovania po každej oprave mali všetky testy spustiť znova, ale v praxi je tento prístup príliš drahý. Preto sa pri plánovaní procesu testovania určujú závislosti medzi časťami systému a ku každej časti sa priraďujú testy. Potom je možné sledovať softvérové prvky pomocou špeciálnych testovacích prípadov (testovacích údajov) prispôsobených týmto prvkom. Ak sú výsledky sledovania zdokumentované, potom je možné na testovanie zmeneného softvérového prvku a jeho závislých komponentov použiť iba podmnožinu celého súboru testovacích údajov.
Verifikácia (potvrdenie správnosti) - pozostáva z kontroly a preukázania správnosti vypracovaného programu vo vzťahu k súboru formálnych vyhlásení prezentovaných v špecifikácii a úplného definovania vzťahu medzi vstupnými a výstupnými údajmi tohto programu. V tomto prípade je vzťah medzi premennými na vstupe a výstupe programu analyzovaný nie vo forme hodnôt ako pri testovaní, ale vo forme opisov ich vlastností, ktoré sa prejavujú pri akomkoľvek spracovaní týchto riadených premenných. v programe.
Verifikácia programu v zásade eliminuje potrebu testovania a ladenia, keďže zároveň na vyššej úrovni konceptov a popisov všetkých premenných sa stanovuje správnosť procesov, ich spracovania a transformácií.
Podstatu každého programu môžu predstavovať opisy vzťahov medzi vstupnými a výstupnými údajmi. Tieto vzťahy sú formalizované 1 špecifikáciou softvéru. V reálnom vývoji nie je formalizácia týchto vzťahov zlá a niektoré vzťahy sa vyjasňujú v procese tvorby programu. Takto neúplne definované nestačia na preukázanie správnosti programov. Až po úplnej a presnej formalizácii všetkých podmienok a väzieb medzi vstupnými a výstupnými údajmi je možné ich použiť na automatické overovanie.
Metóda induktívnych výrokov.
Na preštudovanie tejto metódy sú programu dodávané vyhlásenia o vlastnostiach jeho premenných v určitých bodoch:
a) Vstupné premenné sa počas vykonávania programu nemenia;
b) Sú opísané stavy premenných v medziľahlých bodoch;
c) Výstupné premenné sú opísané pomocou vzťahov medzi premennými po dokončení programu.
Verifikácia pozostáva z postupného preukazovania, že zo vstupných premenných a transformácií vykonaných v prvom kroku vyplýva pravdivosť tvrdenia vytvoreného v ďalšom medziľahlom bode.
Na overenie programov sú potrebné tri jazyky:
· Jazyk na písanie programových textov;
· Jazyk na formulovanie podmienok overovania;
· Formačný jazyk a dôkaz správnosti.
Keďže sa tieto jazyky do značnej miery líšia, táto okolnosť je jednou z aplikácií overovania.
Dôkaz o správnosti má tieto výhody:
1. Predstavuje jasný formalizovaný proces.
2. Vyžaduje analýzu. Proces dokazovania správnosti umožňuje skúmať časti programov, ktoré by sa inak analyzovali len náhodne.
3. objasňuje medzivýsledky výpočtov. Vypisovanie výrazov núti programátora jasne formulovať svoje predpoklady o výsledkoch výpočtov vo vybraných bodoch programu.
4. Identifikuje závislosti. V procese dokazovania programov človek začína chápať, aké predpoklady o vstupných údajoch nie sú explicitne testované v rôznych častiach programu.
Nevýhody metódy:
1. Obtiažnosť; Aj pre malé jednoduché programy sú výpočty veľmi zložité, čo môže viesť k chybám.
2. Chyby Vzhľadom na zložitosť metódy je ľahké robiť chyby ako pri tvorbe dokazovaných tvrdení, tak aj pri dokazovaní.
3. Ťažkosti pri práci s poliami.
4. Nedostatok výkonného matematického aparátu.
5. Vysoká pracovná náročnosť Testovanie programu vyžaduje viac práce ako jeho písanie (2 až 6-krát).
6. Nedostatok expresivity. Často nie je ľahké sformulovať ziskové vyhlásenie pre to, čo sa intuitívne javí ako veľmi jednoduchý výpočet:
7. Ťažkosti s pochopením.
8. Potreba tréningu. Táto metóda si vyžaduje rozsiahly tréning a tréning.
Overenie a overenie ( overenie a overenie-V& V) sú určené na analýzu, overenie správnosti vykonávania a zhody softvéru so špecifikáciami a požiadavkami zákazníka. Tieto metódy na kontrolu správnosti programov a systémov znamenajú:
- overenie je kontrola, či je systém správne zostavený v súlade s jeho špecifikáciou;
- Validácia je kontrola správneho plnenia špecifikovaných systémových požiadaviek.
Verifikácia pomáha urobiť záver o správnosti vytvoreného systému po dokončení jeho návrhu a vývoja. Validácia vám umožňuje určiť realizovateľnosť špecifikovaných požiadaviek a zahŕňa množstvo akcií na získanie správnych programov a systémov, a to:
- plánovacie postupy na kontrolu a monitorovanie návrhových rozhodnutí a požiadaviek;
- zabezpečenie úrovne automatizácie návrhu programu pomocou nástrojov CASE;
- kontrola správneho fungovania programov pomocou testovacích metód na súboroch cieľových testov;
- prispôsobenie produktu prevádzkovému prostrediu a pod.
Validácia vykonáva tieto činnosti preskúmaním a kontrolou špecifikácií a výsledkov návrhu fáz životného cyklu, aby sa potvrdilo, že došlo k správnej implementácii počiatočných požiadaviek a že sú splnené špecifikované podmienky a obmedzenia. Úlohy overovania a validácie zahŕňajú kontrolu úplnosti, konzistentnosti a jednoznačnosti špecifikácie požiadaviek a správneho výkonu funkcií systému.
Overenie a validácia podlieha:
- hlavné komponenty systému;
- rozhrania komponentov (softvérové, technické a informačné) a interakcie objektov (protokoly a správy) zabezpečujúce vykonávanie systému v distribuovaných prostrediach;
- prostriedky na prístup k databáze a súborom (transakcie a správy) a kontrolu prostriedkov ochrany pred neoprávneným prístupom k údajom rôznych používateľov;
- dokumentácia k softvéru a systému ako celku;
- testy, skúšobné postupy a vstupné údaje.
Inými slovami, hlavné systematické metódy pre správnosť programu sú:
- overenie validácia softvérových komponentov a špecifikácií požiadaviek;
- PS inšpekcia stanoviť súlad programu s danými špecifikáciami;
- testovanie výstupný kód softvéru na testovacích dátach v špecifickom operačnom prostredí na identifikáciu chýb a defektov spôsobených rôznymi defektmi, anomálnymi situáciami, poruchami zariadení alebo núdzovým ukončením systému (pozri kapitolu 9).
Normy ISO/IEC 3918-99 a 12207 zahŕňajú procesy overovania a validácie. Pre nich sú definované ciele, ciele a činnosti na overenie správnosti vytvoreného produktu (vrátane pracovných a medziproduktov) v etapách životného cyklu a súlad s jeho požiadavkami.
Hlavným cieľom procesov overovania a validácie je skontrolujte a potvrďteže konečný softvér je vhodný na daný účel a spĺňa požiadavky zákazníka. Tieto procesy umožňujú identifikovať chyby v produktoch práce fáz životného cyklu bez identifikácie príčin ich výskytu a tiež stanoviť správnosť softvéru vo vzťahu k jeho špecifikácii.
Tieto procesy sú vzájomne prepojené a sú definované jedným pojmom – „overovanie a validácia“ (V&V 7).
Počas overovania sa vykonáva:
- kontrola správnosti prekladu jednotlivých komponentov do výstupného kódu, ako aj popisov rozhraní sledovaním prepojení komponentov v súlade so špecifikovanými požiadavkami zákazníka;
- analýza správnosti prístupu k súborom alebo databázam, berúc do úvahy postupy na manipuláciu s údajmi a prenos výsledkov prijatých v používaných systémových nástrojoch;
- kontrola súčiastok na ochranu zariadení z hľadiska súladu s požiadavkami zákazníka a vykonávanie ich sledovania.
Po kontrole jednotlivých komponentov systému sa vykoná ich integrácia, ako aj overenie a validácia integrovaného systému. Systém sa testuje s rôznymi testovacími sadami, aby sa určila primeranosť a dostatočnosť týchto sád na dokončenie testovania a stanovenie správnosti systému.
Myšlienku vytvorenia medzinárodného projektu formálneho overovania navrhol T. Hoar, diskutovalo sa o ňom na sympóziu o overenom softvéri vo februári 2005 v Kalifornii. V októbri toho istého roku bol na konferencii IFIP v Zürichu prijatý medzinárodný projekt na obdobie 15 rokov s cieľom vyvinúť „komplexnú automatizovanú sadu nástrojov na kontrolu správnosti softvéru“.
Formuluje tieto hlavné úlohy:
- vývoj jednotnej teórie konštrukcie a analýzy programov;
- vybudovanie komplexnej, integrovanej sady overovacích nástrojov pre všetky výrobné fázy, vrátane vývoja a overovania špecifikácií, generovania testovacích prípadov, zdokonaľovania programu, analýzy a overovania;
- vytvorenie úložiska formálnych špecifikácií a overených softvérových objektov rôznych typov a typov.
Tento projekt predpokladá, že verifikácia pokryje všetky aspekty tvorby a kontroly správnosti softvéru a stane sa všeliekom na všetky neduhy spojené s neustálym výskytom chýb vo vytvorených programoch.
Mnoho formálnych metód na dokazovanie a overovanie špecifikovaných programov prešlo praktickým testovaním. Veľa práce vykonala medzinárodná komisia ISO/IEC v rámci normy ISO/IEC 12207:2002 na štandardizáciu procesov overovania a validácie softvéru. Sľubná je kontrola správnosti rôznych programovacích objektov pomocou formálnych metód.
Úložisko je úložisko programov, špecifikácií a nástrojov používaných pri vývoji a testovaní, hodnotení hotových komponentov, nástrojov a príprav metód. Sú mu pridelené tieto všeobecné úlohy:
- akumulácia overených špecifikácií, metód dôkazu, softvérových objektov a implementácií kódu pre komplexné aplikácie;
- akumulácia rôznych overovacích metód, ich návrh vo forme vhodnej na vyhľadávanie a výber realizovanej teoretickej myšlienky pre ďalšiu aplikáciu;
- vývoj štandardných formulárov na špecifikáciu a výmenu formálnych špecifikácií rôznych programovacích objektov, ako aj nástrojov a hotových systémov;
- vývoj interoperability a interakčných mechanizmov na prenos hotových overených produktov z úložiska do nových distribuovaných a sieťových prostredí na vytvorenie nového softvéru.
Očakáva sa, že tento projekt sa bude rozvíjať počas obdobia 50 rokov. Predchádzajúce projekty si stanovili podobné ciele: zlepšenie kvality softvéru, formalizácia modelov služieb, zníženie zložitosti pomocou PIC, vytvorenie ladiacich nástrojov na vizuálnu diagnostiku chýb a ich odstraňovanie atď. K zásadnej zmene v programovaní však nedošlo ani z hľadiska vizuálneho ladenia. alebo dosiahnutie vysokej kvality softvéru. Proces vývoja pokračuje.
Nový medzinárodný projekt overovania softvéru si od svojich účastníkov vyžaduje nielen znalosť teoretických aspektov špecifikácií programu, ale aj vysokokvalifikovaných programátorov pre jeho implementáciu v najbližších rokoch.
Softvérové systémy sú teraz všadeprítomné: takmer každé elektronické zariadenie obsahuje softvér toho či onoho druhu. Bez vhodného softvéru si v modernom svete nie je možné predstaviť priemyselnú výrobu, školy a univerzity, zdravotníctvo, finančné a vládne inštitúcie. Mnoho používateľov používa softvér na sebavzdelávanie, zábavu atď. Vytvorenie špecifikácie požiadaviek, vývoj, úprava a údržba takýchto softvérových systémov je podstatou technickej disciplíny. softvérové inžinierstvo(softvérové inžinierstvo, SE).
Aj jednoduché softvérové systémy majú vysoký stupeň zložitosti, takže ich vývoj si vyžaduje použitie celého arzenálu technických a inžinierskych metód. Preto je softvérové inžinierstvo strojárstvo disciplína, kde špecialisti využívajú teóriu a metódy informatiky na úspešné riešenie rôznych typov neštandardných problémov. Ale, samozrejme, nie každý softvérový projekt je z rôznych dôvodov úspešne dokončený. Pokrok je badateľný: za posledných 30 rokov sa softvér veľmi skomplikoval, objavili sa programy, ktoré používateľom ponúkajú veľké možnosti služieb na prácu s nimi.
Treba poznamenať, že softvérové inžinierstvo sa vyvíja predovšetkým v reakcii na nové výzvy pri budovaní veľkých softvérových systémov na mieru pre priemysel, vládu a obranu. Na druhej strane je v súčasnosti rozsah softvéru veľmi široký: od hier na špecializovaných herných konzolách, ako aj softvérových produktov pre osobné počítače až po veľmi veľké škálovateľné distribuované systémy.
Pri vytváraní softvérového produktu stojí inžinier pred mnohými otázkami rôzneho druhu, ako sú napríklad požiadavky na softvér, modely systému, špecifikácie softvéru, spoľahlivosť vytvoreného produktu atď. Tento článok sa zaoberá jedným z najťažších krokov pri vytváraní akéhokoľvek softvérového produktu – overovaním a certifikáciou. Práca poskytuje všeobecnú predstavu o overovaní a certifikácii softvéru, čitateľ sa oboznámi s metódami statického overovania, dynamického overovania a metód certifikácie kritických systémov.
1. Všeobecné informácie o overení a certifikácii softvéru.
1.1. Úvod do overovania a kvalifikácie
Overovanie a kvalifikácia sú procesy testovania a analýzy, ktoré overujú, či softvér spĺňa jeho špecifikácie a požiadavky zákazníkov. Verifikácia a certifikácia pokrývajú celý životný cyklus softvéru – začínajú vo fáze analýzy požiadaviek a končia overením programového kódu vo fáze testovania softvérového systému.
Overovanie a certifikácia sú úplne odlišné pojmy, no často sa zamieňajú. Aby sme ich rozlíšili, odvodíme hlavný rozdiel medzi týmito pojmami. Overenie odpovedá na otázku, či je to správne vytvorené a certifikácia odpovedá na otázku, či je správna Tvorba systému. Z toho vyplýva, že overovaním sa kontroluje súlad softvéru so špecifikáciami systému, najmä funkčnými a nefunkčnými požiadavkami. Certifikácia je všeobecnejší proces. Počas certifikácie je cieľom inžiniera dokázať zákazníkovi, že produkt spĺňa jeho očakávania. Vykonáva sa certifikácia po overenie.
V počiatočných fázach vývoja softvéru je certifikácia systémových požiadaviek veľmi dôležitá. V požiadavkách sa veľmi často vyskytujú chyby, nedostatky a opomenutia, ktoré môžu viesť k tomu, že produkt nespĺňa plány zákazníka. Inžinier sa musí s týmto problémom vysporiadať. Ako však vieme, je ťažké odstrániť všetky chyby v požiadavkách. Jednotlivé chyby je možné odhaliť až pri implementácii softvérového produktu.
Procesy overovania a certifikácie využívajú dve hlavné metódy kontroly a analýzy systémov: kontrolu softvéru a testovanie softvéru. Kontrola softvéru zahŕňa analýzu a kontrolu rôznych reprezentácií systému, ako je napríklad dokumentácia. Kontrola prebieha vo všetkých fázach vývoja softvérového systému. Súbežne s kontrolou je možné vykonávať automatickú analýzu zdrojového kódu programov a súvisiacich dokumentov. Inšpekcia a automatizovaná analýza sú statické overovacie a validačné metódy, pretože nevyžadujú spustiteľný systém. Testovanie softvéru je analýza výstupných údajov a výkonnostných charakteristík softvérového produktu na overenie správnej činnosti systému. Testovanie je dynamická metóda overovania a certifikácie, pretože sa aplikuje na spustiteľný systém.
Na obr. Obrázok 1.1 ukazuje miesto kontroly a testovania v procese vývoja softvéru. Šípky označujú tie fázy vývojového procesu, v ktorých možno tieto metódy použiť.
Ryža. 1.1. Statické a dynamické overovanie a certifikácia
Podľa tejto schémy je možné vykonávať kontrolu vo všetkých fázach vývoja systému a testovanie je možné vykonávať v prípadoch, keď bol vytvorený prototyp alebo spustiteľný program. Metódy kontroly zahŕňajú: kontrolu programu, automatickú analýzu zdrojového kódu a formálne overenie. Pri statických metódach je však možné kontrolovať len súlad programov so špecifikáciami, s ich pomocou nie je možné určiť správne fungovanie systému. Navyše nefunkčné charakteristiky ako výkon a spoľahlivosť nie je možné overiť pomocou statických metód. Preto by sa malo vykonať testovanie systému na analýzu nefunkčných charakteristík. V súčasnosti, napriek rozšírenému využívaniu kontroly softvéru, je testovanie stále prevládajúcou metódou overovania a certifikácie. Testovanie je test fungovania programov s údajmi podobnými reálnym údajom, ktoré sa budú spracovávať počas prevádzky systému. Problémy v prevádzke softvéru sa zisťujú analýzou výstupných údajov, medzi ktorými sa identifikujú a skúmajú anomálne.
V rôznych fázach procesu vývoja softvéru sa používajú rôzne typy testovania. Testovanie defektov vykonávané s cieľom identifikovať nezrovnalosti medzi softvérovým produktom a jeho špecifikáciou, ktoré sú spôsobené chybami v programovom kóde. Takéto testy sú určené na identifikáciu chýb v systéme a nie na simuláciu jeho činnosti. Štatistické testovanie hodnotí výkon a spoľahlivosť programov, ako aj chod programu pri použití rôznych režimov jeho prevádzky. Testy sú určené za účelom simulácie, simulujúcej skutočnú prevádzku systému s reálnymi výstupnými údajmi. Spoľahlivosť systému je určená počtom porúch zaznamenaných pri prevádzke programov. Výkon sa hodnotí meraním celkového času vykonávania operácií a času odozvy systému pri spracovaní testovacích údajov.
Samozrejme, medzi týmito dvoma testovacími metódami nie sú jasné hranice. Počas testovania môže tester intuitívne pochopiť spoľahlivosť softvéru a počas štatistického testovania je možné identifikovať chyby softvéru.
Hlavným účelom overovania a kvalifikácie je zabezpečiť, aby bol systém „vhodný na daný účel“. Súlad softvérového systému s určeným účelom neznamená, že by mal byť úplne bezchybný. Systém musí skôr dobre slúžiť účelom, na ktoré bol navrhnutý. Úroveň požadovaného spoľahlivosť súladu závisí od účelu systému, očakávaní používateľov a podmienok na softvérovom trhu.
Účel softvéru.Úroveň spoľahlivosti zhody závisí od dôležitosti (kritickosti) vyvíjaného softvérového produktu podľa niektorých kritérií. Napríklad softvér pre lekársku inštaláciu „Zariadenie srdca a pľúc“ je superkritický, pretože ľudský život závisí od kvality fungovania systému. Môžeme uviesť príklad systémov s nízkou kritickosťou. Ide najmä o prototypy softvérových systémov vyvinutých na demonštráciu niektorých nových nápadov.
Pri overovaní a certifikácii v systéme sa spravidla zistia chyby, ktoré je potrebné opraviť. Po oprave chýb musíte program znova skontrolovať. Ak to chcete urobiť, môžete program znova skontrolovať alebo zopakovať testovanie. Vývojár by mal vedieť, že neexistujú žiadne jednoduché metódy na opravu chýb v programoch. Opätovné testovanie sa musí vykonať, aby sa zabezpečilo, že zmeny vykonané v programe nezanesú do systému nové chyby, pretože v praxi sa vysoké percento „oprav chýb“ buď nedokončí úplne, alebo do programu vnesú nové chyby. Pri vývoji veľkých systémov je každé opätovné testovanie celého systému veľmi drahé; zároveň sa z dôvodu úspory financií stanovujú prepojenia a závislosti medzi časťami systému a vykonáva sa testovanie týchto jednotlivých častí.
2. Overenie a certifikácia softvéru
2.1. Plánovanie overenia a kvalifikácie
Overovanie a certifikácia sú drahé procesy. Pre komplexné systémy je typický napríklad nasledujúci pomer: polovica z celkového rozpočtu vyčleneného na implementáciu systému sa minie na overovanie a certifikáciu. Preto je zrejmá potreba starostlivého plánovania overovania a kvalifikácie.
Plánovanie overovania a kvalifikácie by sa malo začať čo najskôr. Obrázok 2.1 ukazuje model vývoja softvéru, ktorý zohľadňuje proces plánovania testov.
Ryža. 2.1. plánovanie testov počas vývoja a testovania,
Špecifikácia požiadaviek
Špecifikácia systému - špecifikácia systému
Návrh systému - návrh systému
Detailed Design - detailný dizajn
Plán akceptačných skúšok – plánovanie akceptačných skúšok
Plán testovania systémovej integrácie – plánovanie testovania systémovej zostavy
Plán testovania integrácie subsystému – plánovanie testovania zostavy subsystému
Modul a unit code and tess – kódovanie a testovanie modulov a komponentov
Test integrácie subsystémov – testovanie zostavy subsystémov
Test systémovej integrácie – testovanie zostavy systému
Akceptačný test – akceptačné testy
Služba je softvérový produkt.
Obrázok ukazuje, že proces overovania a certifikácie je rozdelený do niekoľkých etáp a v každej fáze sa vykonáva špecifický test.
V procese plánovacieho overovania a certifikácie je potrebné určiť vzťah medzi statickými a dynamickými metódami overovania systému, určiť normy a postupy inšpekcií a vypracovať plán testovania programu. Typ vyvíjaného systému určuje, či by sa mala venovať väčšia pozornosť kontrole alebo testovaniu. Čím je systém kritickejší, tým väčšia pozornosť by sa mala venovať metódam statického overovania.
Plán testovania softvéru musí obsahovať: popis hlavných fáz testovacieho procesu, schopnosť sledovať požiadavky (testovanie by sa malo plánovať tak, aby sa všetky požiadavky testovali samostatne), prvky, ktoré sa majú testovať (všetky „výstupy“ vývoja softvéru). mal by byť identifikovaný proces, ktorý je potrebné otestovať), harmonogram testovania (vypracuje sa časový harmonogram testovania a alokácia zdrojov sa uskutoční podľa tohto harmonogramu, pričom harmonogram testov bude naviazaný na všeobecnejší harmonogram vývoja projektu), postupy zaznamenávania testov (pre overenie správneho vykonania testov), hardvérové a softvérové požiadavky, obmedzenia (snažte sa predvídať všetky nepriaznivé faktory ovplyvňujúce procesy testovania, napr. nedostatok financií, personálu...).
Tak ako iné plány, ani plán testovania nie je pevný dokument. Mal by sa pravidelne kontrolovať, pretože testovanie závisí od procesu implementácie systému. Napríklad, ak implementácia niektorej časti systémov nie je dokončená, potom nie je možné otestovať zostavu systému. Revízia plánu umožňuje zamestnancov (aktuálne nezamestnaných) využiť na iné pracovné miesta.
2.2. Kontrola softvérových systémov
Systémové testovanie programov si vyžaduje vývoj obrovského množstva testov, ich vykonávanie a overovanie. To znamená, že tento proces je dosť náročný na prácu a nákladný. Každý test je schopný odhaliť jednu alebo menej často niekoľko chýb v programe. Dôvodom je, že zlyhania spôsobené chybami v systéme často vedú k zničeniu údajov. Preto je ťažké povedať, koľko chýb je „zodpovedných“ za zlyhanie systému.
Kontrolné programy si nevyžadujú ich dokončenie, takže kontrola môže byť vykonaná aj v počiatočných fázach vývoja. Pri kontrole sa kontroluje pôvodné zobrazenie systému. Môže to byť model systému, špecifikácia alebo program napísaný v jazyku vysokej úrovne. Detekcia chýb je dosiahnutá využitím znalosti uvažovaného systému a sémantiky jeho pôvodnej reprezentácie. Každá chyba môže byť posudzovaná samostatne, bez toho, aby ste venovali pozornosť tomu, ako ovplyvňuje správanie systému.
Inšpekcia sa ukázala ako účinná metóda na zisťovanie chýb a je výrazne lacnejšia ako rozsiahle testovanie. Kontrolou sa dá odhaliť viac ako 60 % všetkých chýb a pri formálnejšom prístupe (s použitím matematických metód) viac ako 90 %. Proces kontroly môže tiež vyhodnotiť ďalšie kvalitatívne charakteristiky systémov: súlad s normami, prenosnosť a udržiavateľnosť.
V systémových komponentoch je identifikácia chýb prostredníctvom kontroly efektívnejšia ako prostredníctvom testovania. Po prvé, v jednej inšpekčnej relácii môžete zistiť veľa chýb softvérového kódu; Pri testovaní sa zvyčajne zistí iba jedna chyba v jednej relácii, pretože chyby môžu viesť k úplnému zastaveniu (zlyhaniu) systému a účinky chýb sa môžu navzájom prekrývať. Po druhé, inšpekcia využíva znalosti o predmete a programovacom jazyku. Inšpekčný špecialista musí poznať typy chýb, čo umožňuje zamerať sa na konkrétne typy chýb.
Je jasné, že kontrola nemôže nahradiť testovanie. Inšpekcia sa najlepšie používa v počiatočných fázach na identifikáciu najväčšieho počtu chýb. Inšpekcia overuje, či softvér zodpovedá svojim špecifikáciám, ale takto napríklad nie je možné posúdiť dynamické správanie systému. Okrem toho je iracionálne kontrolovať kompletné systémy zostavené z niekoľkých podsystémov. Na tejto úrovni je možné len testovanie.
Je chybou domnievať sa, že testovanie a inšpekcia sú konkurenčnými metódami overovania a certifikácie. Každý z nich má svoje výhody a nevýhody. V procese overovania a kvalifikácie by sa preto mala kontrola a testovanie používať spoločne.
Niekedy sa počas inšpekcií v organizácii vyskytujú ťažkosti. Odborníci s rozsiahlymi skúsenosťami s testovaním softvéru sa zdráhajú súhlasiť s tým, že inšpekcia je efektívnejšia metóda na odstránenie systémových chýb ako testovanie. Manažéri sú voči týmto technológiám opatrní, pretože implementácia inšpekcie si vyžaduje dodatočné náklady. Konečné úspory nákladov pri používaní inšpekcie sa dosahujú iba vďaka skúsenostiam odborníkov, ktorí ju vykonávajú.
2.3. Kontrola programu
Kontrola programov je prezeranie a kontrola programov s cieľom odhaliť v nich chyby. Myšlienku formalizovaného procesu overovania programu sformulovala spoločnosť IBM v sedemdesiatych rokoch minulého storočia. V súčasnosti je táto metóda overovania široko používaná. Na jeho základe bolo vyvinutých mnoho ďalších metód, ale všetky sú založené na základnej myšlienke inšpekčnej metódy, podľa ktorej skupina špecialistov vykonáva dôkladnú kontrolu a analýzu zdrojového kódu zdrojového kódu. program. Hlavným rozdielom medzi inšpekciou a inými metódami hodnotenia kvality programov je to, že jej cieľom je odhaliť nedostatky, a nie skúmať všeobecné problémy projektu. Chyby sú buď chyby v zdrojovom kóde alebo nesúlad programu so štandardmi.
Proces kontroly je formalizovaný. Zúčastňuje sa na ňom malá skupina ľudí (zvyčajne nie viac ako štyria ľudia). Každý v skupine má svoju rolu. Prítomní musia byť: autor, recenzent, kontrolór, koordinátor. Recenzent „vysloví“ kód programu, inšpektor ho skontroluje a koordinátor je zodpovedný za organizáciu procesu. Keď organizácie získajú viac skúseností s inšpekciami, môžu sa objaviť ďalšie návrhy na pridelenie rolí tímu (napríklad jedna osoba môže mať viacero rolí, takže počet členov inšpekčného tímu sa môže líšiť).
Na začatie procesu kontroly programu sú potrebné nasledujúce podmienky: prítomnosť presnej špecifikácie kódu (bez úplnej špecifikácie nie je možné zistiť chyby v kontrolovanom softvérovom komponente); členovia inšpekčného tímu musia mať dôkladné znalosti noriem vývoja; Skupina musí mať k dispozícii najnovšiu syntakticky správnu verziu programu (nemá zmysel kontrolovať kód, ktorý je „takmer hotový“).
Ryža. 2.2. Proces kontroly
Na obr. Obrázok 2.2 znázorňuje všeobecný proces kontroly. Je prispôsobený požiadavkám organizácií využívajúcich kontrolu programu.
Samotný proces kontroly by mal byť relatívne krátky (nie viac ako dve hodiny) a zameraný len na zisťovanie závad, anomálií a nedodržiavania noriem. Inšpekčný tím by nemal navrhovať spôsoby nápravy chýb ani odporúčať akékoľvek zmeny iných softvérových komponentov.
Po kontrole autor zmení program a opraví zistené chyby. Počas fázy revízie koordinátor rozhodne, či je potrebná opätovná kontrola. Ak nie je potrebná opätovná kontrola, všetky zistené závady sa zdokumentujú.
Procesom kontroly získava organizácia skúsenosti, aby sa výsledky kontroly mohli použiť na zlepšenie celého procesu vývoja softvéru. Pri obhliadke sa vykonáva rozbor zistených závad. Kontrolný tím a autori kontrolovaného kódu zisťujú príčiny porúch. Aby sa zabránilo výskytu podobných defektov v budúcich systémoch, je potrebné vždy, keď je to možné, odstrániť príčiny defektov, čo znamená vykonať zmeny v procese vývoja softvérových systémov.
Zabezpečenie kontroly softvéru si vyžaduje kvalifikovaný manažment a správny postoj k výsledkom jeho implementácie. Inšpekcia je otvorený proces zisťovania chýb, pri ktorom sa o chybách jednotlivých programátorov dozvie celá skupina programátorov. Manažéri musia jasne rozlišovať medzi kontrolou kódu a hodnotením personálu. Pri posudzovaní odborných kvalít by sa za žiadnych okolností nemali brať do úvahy chyby zistené pri kontrole. Vedúci inšpekčných tímov musia byť dôkladne vyškolení, aby dobre riadili proces a vytvorili kultúru vzťahov, ktorá zabezpečí, že chyby budú podporované a chyby nebudú obviňované.
2.4. Automatická statická analýza programov
Statické programové analyzátory sú softvérové nástroje, ktoré skenujú zdrojový kód programu a identifikujú možné chyby a nezrovnalosti. Analyzátory nevyžadujú spustiteľný program. Analyzujú text programu a rozpoznávajú rôzne typy príkazov. Analyzátory môžu skontrolovať, či sú príkazy napísané správne, vyvodiť závery o toku riadenia programu a v mnohých prípadoch vypočítať množinu údajových hodnôt používaných programom. Analyzátory dopĺňajú nástroje na detekciu chýb, ktoré poskytuje kompilátor jazyka.
Účelom automatizovanej statickej analýzy je upozorniť recenzenta na anomálie v programe, ako sú premenné, ktoré sa používajú bez inicializácie alebo ktoré sú inicializované, ale v programe sa nepoužívajú.
Statická analýza pozostáva z niekoľkých fáz.
1. Analýza kontrolného toku. Identifikácia a výber cyklov, ich vstupných a výstupných bodov, identifikácia nepoužitého kódu.
2. Analýza využitia dát. Kontrola premenných v programe. V tejto fáze môžete tiež identifikovať podmienené vyhlásenia s nadbytočnými podmienkami.
3. Analýza rozhrania. Kontrola súladu rôznych častí programu, správnosti deklarácie postupov a ich používania. Tento krok sa ukáže ako zbytočný, ak sa použije jazyk s prísnou kontrolou typu.
4. Analýza toku údajov. Určujú sa závislosti medzi vstupnými a výstupnými premennými. Hoci táto analýza neidentifikuje konkrétne chyby, poskytuje úplný zoznam hodnôt použitých v programe. Preto sa chybný výstup údajov ľahko zistí.
5. Analýza vetiev programu. V tejto fáze sémantickej analýzy sú určené všetky vetvy programu a zvýraznené príkazy vykonané v každej vetve. Analýza vetiev programu výrazne pomáha porozumieť riadeniu programu a umožňuje analyzovať každú vetvu samostatne.
Je potrebné poznamenať, že analýza toku údajov a analýza vetvy programu generujú obrovské množstvo informácií. Tieto informácie neidentifikujú konkrétne chyby, ale skôr predstavujú program v rôznych aspektoch. Kvôli obrovskému množstvu generovaných informácií sú tieto kroky niekedy vylúčené z procesu analýzy a používajú sa iba v počiatočných štádiách na zistenie anomálií vo vyvíjanom programe. Statické analyzátory sú užitočné najmä pri používaní programovacích jazykov ako C. C nemá silnú kontrolu typu, a preto je kontrola vykonávaná kompilátorom C obmedzená. V tomto prípade sa pomocou statickej analýzy identifikuje široká škála chýb, čo je obzvlášť dôležité pri vývoji kritických systémov.
Analýza založená na nástrojoch nenahrádza kontrolu, pretože existujú typy chýb, ktoré statická analýza nedokáže odhaliť. Analyzátory môžu napríklad odhaliť nedeklarované premenné, ale nebudú schopné odhaliť nesprávne priradenia. Samozrejme, pre jazyky ako C je statická analýza účinnou metódou na zisťovanie chýb. Ale v moderných jazykoch (ako je Java) boli odstránené konštrukcie, ktoré prispievajú k výskytu mnohých chýb. Všetky premenné musia byť deklarované, neexistujú žiadne príkazy bezpodmienečného skoku, takže je nepravdepodobné, že by sa náhodne vytvoril nepoužívaný kód, a správa pamäte je automatická.
2.5 Metóda čistej miestnosti.
Vývoj softvéru pre čisté miestnosti využíva prísny proces kontroly na odstránenie chýb. Cieľom tejto metódy je vytvoriť softvér bez chýb. Názov „čistá miestnosť“ je analogický s výrobou polovodičových kryštálov, kde rast kryštálov bez defektov prebieha v ultračistej atmosfére (čisté priestory).
Existuje päť kľúčových bodov pri vývoji softvéru pomocou metódy čistej miestnosti:
1. Formálna špecifikácia. Vypracuje sa formálna špecifikácia. Na zaznamenanie špecifikácie sa používa stavový model, ktorý zobrazuje reakcie systému.
2. Vývoj krok za krokom. Vývoj softvéru je rozdelený do niekoľkých etáp, ktoré sa nezávisle od seba testujú metódou „čistej miestnosti“.
3. Štruktúrované programovanie. Používa sa obmedzený počet riadiacich štruktúr. Proces vývoja programu je postup postupného upresňovania špecifikácie.
4. Statické overenie. Overenie pomocou statickej metódy prísnej kontroly softvéru. Testovanie kódu sa nevykonáva pre jednotlivé prvky.
5. Statické testovanie systému. V každom kroku sa testuje pomocou statických metód na posúdenie spoľahlivosti softvérového systému.
V prvých fázach vývoja softvéru sú pre zákazníka najdôležitejšie systémové funkcie implementované metódou „čistej miestnosti“. Menej dôležité funkcie systému sa pridávajú v ďalších fázach. Zákazník tak má možnosť otestovať systém pred jeho plnou implementáciou.
Proces vývoja softvéru pre čisté priestory je navrhnutý tak, aby zabezpečil dôslednú kontrolu programu, sprevádzanú dôsledným matematickým dôkazom konzistencie a správnosti transformácií.
Vývoj veľkých systémov pomocou metódy „čistej miestnosti“ zvyčajne vykonávajú tri skupiny vývojárov: skupina špecifikácií, skupina vývojárov (vyvíja a testuje softvér) a certifikačná skupina (vyvíja kontrolné testy).
V dôsledku použitia metódy „čistej miestnosti“ softvérový produkt obsahuje veľmi málo chýb a jeho cena je nižšia ako cena vyvinutá tradičnými metódami. Počas procesu vývoja sa zistilo, že statická kontrola je pri použití tejto metódy nákladovo efektívna. Obrovské množstvo defektov je objavených pred spustením programu a sú opravené počas procesu vývoja softvéru.
3. Testovanie softvéru
3.1. Plánovanie testov
Pri plánovaní procesu overovania softvéru a kvalifikácie musia projektoví manažéri určiť, kto bude zodpovedný za rôzne fázy testovania. V mnohých prípadoch sú programátori zodpovední za testovanie svojich programov, modulov alebo objektov. Ďalšou etapou je zodpovednosť systémovej integračnej (montážnej) skupiny, ktorá integruje jednotlivé softvérové moduly do jedného systému a testuje tento systém ako celok.
Pre kritické systémy by mal byť proces testovania formálnejší. Táto formalizácia predpokladá, že za všetky fázy testovania sú zodpovední nezávislí testeri, všetky testy sa vyvíjajú samostatne a počas testovania sa vedú podrobné záznamy. Na testovanie kritických systémov nezávislý tím vyvíja testy založené na špecifikáciách každého komponentu. Pri vývoji nekritických systémov sa nevytvárajú podrobné špecifikácie pre každý komponent. Testovanie komponentov je teda zvyčajne založené iba na pochopení vývojárov toho, čo by mal komponent robiť.
Testovanie zostavy by malo vychádzať z existujúcej špecifikácie systému.
V kontexte testovania existuje množstvo rozdielov medzi objektovo orientovanými systémami (OOS) a funkčne orientovanými (FOS) systémami. Vo FOS existuje jasný rozdiel medzi hlavnými programovými prvkami a súhrnom týchto prvkov. V OOS to tak nie je. Preto v OOS neexistujú jasné hranice medzi testovaním komponentov a testovaním zostavy. V takýchto systémoch je proces testovania pokračovaním procesu vývoja.
3.2. Testovanie defektov
Účelom testovania defektov je identifikovať skryté chyby v softvérovom systéme pred jeho dodaním zákazníkovi. Testovanie defektov je opakom kvalifikácie, ktorá overuje, či systém spĺňa svoju špecifikáciu. Počas certifikácie musí systém správne fungovať so všetkými špecifikovanými testovacími údajmi. Pri testovaní defektov sa spustí test, ktorý spôsobí, že program nebude fungovať správne, a preto identifikuje defekt. Testovanie defektov ukazuje Dostupnosť, nie absencia chýb v programe.
Úplné testovanie, keď sú skontrolované všetky možné sekvencie vykonávania programu, je nemožné. Testovanie by preto malo byť založené na určitej podmnožine všetkých možných testovacích scenárov.
Zo skúseností s testovaním veľkých softvérových produktov môžu nezvyčajné kombinácie funkcií niekedy spôsobiť chyby, no najčastejšie používané funkcie vždy fungujú správne.
Existuje niekoľko metód na testovanie defektov.
Testovanie čiernej skrinky je, že celý systém je reprezentovaný ako „čierna skrinka“, ktorej správanie je možné určiť iba štúdiom vstupných údajov a zodpovedajúcich výstupných údajov. Iným názvom tejto metódy je funkčné testovanie, pretože sa analyzujú iba vykonané funkcie.
Štrukturálne testovanie. Metóda štrukturálneho testovania zahŕňa vytváranie testov založených na štruktúre systému a jeho implementácii. Tento prístup sa niekedy nazýva testovanie „bielej skrinky“, „čistej skrinky“ alebo „sklenenej skrinky“, aby sa odlíšilo od testovania čiernej skrinky. Štrukturálne testovanie sa zvyčajne aplikuje na relatívne malé softvérové prvky. Pri tomto prístupe tester analyzuje kód a používa znalosti o štruktúre komponentu na získanie testovacích údajov. Napríklad z analýzy kódu môžete určiť, koľko kontrolných testov je potrebné vykonať, aby sa všetky príkazy počas testovania vykonali aspoň raz.
Testovacie pobočky. Toto je metóda štrukturálneho testovania, ktorá testuje všetky nezávisle spustiteľné vetvy komponentu alebo programu. Ak sa vykonajú všetky nezávislé pobočky, všetky príkazy sa musia vykonať aspoň raz. Okrem toho sa všetky podmienené príkazy testujú s hodnotami pravdivých aj nepravdivých podmienok. V OOS sa testovanie vetví používa na testovanie metód spojených s objektmi. Počet vetiev v programe je zvyčajne úmerný jeho veľkosti. Keď sú softvérové moduly integrované do systému, metódy štrukturálneho testovania už nie sú realizovateľné. Preto sa pri testovaní jednotlivých programových prvkov a modulov zvyčajne používajú metódy testovania pobočiek. Pri testovaní vetiev sa netestujú všetky možné kombinácie vetiev programu. Okrem najtriviálnejších softvérových komponentov bez slučiek sa takáto úplná kontrola komponentu ukazuje ako nereálna, keďže v programoch so slučkami existuje nekonečné množstvo možných kombinácií vetiev. V programe môžu byť chyby, ktoré sa objavia len s určitou kombináciou vetiev, aj keď sú všetky príkazy testované aspoň raz.
3.3. Testovanie zostavy
Po otestovaní všetkých jednotlivých softvérových komponentov je systém zostavený, výsledkom čoho je čiastočný alebo úplný systém. Proces systémovej integrácie zahŕňa zostavenie a testovanie výsledného systému, počas ktorého sa identifikujú problémy, ktoré vznikajú pri interakcii komponentov. Testy, ktoré overujú zostavenie systému, musia byť vytvorené na základe špecifikácie systému. Testovanie zostavy by malo začať ihneď po vytvorení pracovných verzií komponentov systému.
Pri testovaní zostavy vzniká problém s lokalizáciou zistených chýb. Medzi komponentmi systému sú zložité vzťahy a keď sa medzi nimi zistia anomálne výstupy, môže byť ťažké určiť zdroj chyby. Aby ste uľahčili izoláciu chýb, mali by ste na zostavenie a testovanie systému použiť metódu krok za krokom. Najprv by ste mali vytvoriť minimálnu konfiguráciu systému a otestovať ju. Potom je potrebné pridať nové komponenty do minimálnej konfigurácie a znova otestovať, a tak ďalej, kým nie je systém úplne zostavený.
Testovanie smerom nadol a nahor. Techniky testovania zhora nadol (TT) a testovania zdola nahor (BT) odrážajú rôzne prístupy k systémovej integrácii. Pri integrácii zhora nadol sú komponenty na vysokej úrovni integrované a testované pred dokončením ich návrhu a implementácie. Pri integrácii zdola nahor sú komponenty nižšej úrovne najprv integrované a testované pred vývojom komponentov vyššej úrovne.
NT je neoddeliteľnou súčasťou procesu vývoja systémov zhora nadol, v ktorom sa najskôr vyvíjajú komponenty najvyššej úrovne, po ktorých nasledujú komponenty na nižších úrovniach hierarchie. Program je reprezentovaný ako jeden abstraktný komponent s podkomponentmi, ktoré sú stubmi. Stuby majú rovnaké rozhranie ako komponent, ale s obmedzenou funkčnosťou. Akonáhle je komponent najvyššej úrovne naprogramovaný a otestovaný, jeho podkomponenty sú implementované a testované rovnakým spôsobom. Proces pokračuje, kým nie sú implementované komponenty najnižšej úrovne. Potom sa testuje celý systém.
Naopak, vo VT sú najskôr integrované a testované moduly umiestnené na nižších úrovniach hierarchie. Potom sa zostavia a otestujú vyššie uvedené moduly a tak ďalej, až kým sa neotestuje posledný modul. Tento prístup nevyžaduje úplný architektonický návrh systému, a preto môže začať už v ranom štádiu vývoja.
Testovanie rozhrania. Testovanie rozhrania (IT) sa vykonáva v prípadoch, keď sú moduly alebo subsystémy integrované do väčších systémov. Každý modul alebo subsystém má definované rozhranie, ktoré je volané inými komponentmi systému. Účelom TI je identifikovať chyby, ktoré vznikajú v systéme v dôsledku chýb v rozhraniach alebo v dôsledku nesprávnych predpokladov o rozhraniach.
Tento typ testovania je obzvlášť dôležitý pri objektovo orientovanom programovaní. Objekty sú z veľkej časti definované pomocou rozhraní a možno ich opätovne použiť v rôznych kombináciách s rôznymi objektmi v rôznych systémoch. Pri testovaní jednotlivých objektov nie je možné identifikovať chyby rozhrania, pretože sú výsledkom interakcií medzi objektmi a nie izolovaného správania jedného objektu.
Medzi komponentmi programu môžu existovať rôzne typy rozhraní a podľa toho aj rôzne typy chýb rozhrania.
Ryža. 3.1. Testovanie rozhrania
TI je zložitý proces, pretože niektoré chyby sa môžu vyskytnúť len za neobvyklých podmienok. Ďalší problém môže vzniknúť z interakcií medzi chybami v rôznych softvérových moduloch alebo objektoch. Chyby v jednom objekte sa dajú zistiť iba vtedy, keď sa správanie iného objektu stane nepredvídateľným.
Metódy statického testovania sú zvyčajne nákladovo efektívnejšie ako špeciálne testovanie. V jazykoch s prísnou kontrolou typu kompilátor pomáha zisťovať chyby rozhrania, zatiaľ čo v jazykoch so slabým riadením typu môže chyby detekovať statický analyzátor. Okrem toho sa pri kontrole programov môžete zamerať špeciálne na kontrolu rozhraní komponentov.
Záťažové testovanie. Keď je systém plne integrovaný, je možné posúdiť integračné vlastnosti systému, ako je výkon a spoľahlivosť. Aby sa zabezpečilo, že systém zvládne danú záťaž, sú vyvinuté testy na meranie výkonu. Typicky sa vykonáva séria testov s postupným zvyšovaním zaťaženia, kým výkon systému nezačne klesať.
3.4. Testovacie nástroje
Testovanie je nákladná a časovo náročná fáza vývoja softvérových systémov. Preto bola vytvorená široká škála nástrojov na podporu procesu testovania, ktoré výrazne znižujú náklady na testovanie. Na obr. Obrázok 3.2 ukazuje možné testovacie nástroje a vzťahy medzi nimi.
Ryža. 3.2. Testovacie nástroje
Na tomto obrázku:
Organizátor testov riadi vykonávanie testov, generátor testovacích údajov generuje testovacie údaje pre testovaný program (vyberá testovacie údaje z databázy alebo používa šablóny na generovanie náhodných údajov), orákulum generuje očakávané výsledky testov, porovnávač súborov porovnáva výsledky súčasného testovania s výsledkami predchádzajúceho testovania a informuje o zistených rozdieloch, generátor správ generuje testovacie správy, dynamický analyzátor pridá do programu kód na počítanie, koľkokrát sa každý príkaz vykoná, simulátor simuluje vykonávanie programu.
4. Certifikácia kritických systémov
Verifikácia a certifikácia kritických systémov má veľa spoločného s podobnými procesmi vykonávanými na akomkoľvek inom softvérovom systéme. Charakter kritických systémov (CS) je však taký, že okrem bežnej analýzy a testovania systému sú potrebné aj procesy na preukázanie jeho spoľahlivosti. Vyžaduje sa to z dvoch dôvodov. Prvým dôvodom je náklady na zlyhanie CS. V CS sú náklady na zlyhanie oveľa vyššie ako v iných. Preto je ekonomicky výhodnejšie investovať viac peňazí do overovania a certifikácie, ako trpieť straty z porúch. Druhý dôvod - certifikácia vlastností funkčnej spoľahlivosti. Zákazníci CS musia mať istotu, že systém spĺňa určité ukazovatele funkčnej spoľahlivosti. Z týchto dôvodov sú náklady na overenie a certifikáciu CS výrazne vyššie ako pri iných systémoch.
4.1. Certifikácia spoľahlivosti
Aby sa zabezpečilo, že systém spĺňa požiadavky, jeho doba prevádzky sa musí merať v porovnaní s výkonom typického používateľa. Proces merania ukazovateľov spoľahlivosti pozostáva zo štyroch etáp: najprv sa preštudujú podobné existujúce systémy (určí sa prevádzkový profil), potom sa pripravia testovacie dáta, ďalšou fázou je samotné testovanie a posledným krokom je výpočet ukazovateľov spoľahlivosti. Táto metóda sa niekedy nazýva statické testovanie, ktorého účelom je vyhodnotenie spoľahlivosti systému. Statické testovanie je opakom testovania defektov, ktoré sa vykonáva na zistenie chýb v systéme. Táto metóda však nie je taká jednoduchá na uplatnenie v praxi. Ťažkosti vznikajú z niekoľkých dôvodov:
Neistota prevádzkového profilu (profily nemusia presne odrážať skutočné využitie systému)
Vysoké náklady na generovanie testovacích údajov (ak nie je možné automaticky generovať testovacie údaje, potom vytvorenie veľkého množstva testovacích údajov vyžaduje veľa času a teda aj peňazí)
Štatistická neistota v prípade vysokej spoľahlivosti (pre presné meranie ukazovateľov spoľahlivosti je potrebné vygenerovať štatisticky významný počet porúch).
Prevádzkový profil (OP) odráža prax používania systému. Pozostáva zo špecifikácie tried vstupných údajov a pravdepodobnosti ich výskytu. Ak je softvérový systém inovatívny, je ťažké predpovedať, ako sa bude používať. Systém využívajú rôzne skupiny používateľov s rôznymi očakávaniami, znalosťami a skúsenosťami. Nové systémy nemajú žiadnu históriu používania a na prácu s nimi používatelia často používajú metódy, ktoré vývojári nezamýšľali. Ďalším problémom je, že OP sa môže pri používaní systému meniť. Všetky tieto dôvody často bránia vypracovaniu spoľahlivého OP. V takýchto situáciách je ťažké posúdiť mieru neistoty pri meraní ukazovateľov spoľahlivosti systému.
Počas certifikácie softvéru by sa manažéri mali zamerať na testovanie systému. Keďže testovanie je veľmi nákladný proces, je dôležité ho dokončiť čo najskôr, aby sa systém neskôr nemusel znova testovať. Testovanie je ukončené, ak je dosiahnutá požadovaná úroveň bezporuchovej prevádzky. Niekedy sa však ukáže, že požadovaná úroveň spoľahlivosti sa nikdy nedosiahne. V tomto prípade musí manažér urobiť ťažké rozhodnutie o prepracovaní niektorých častí systému alebo o prerokovaní zmluvy so zákazníkom.
4.2. Bezpečnostné záruky
Získavanie záruk bezpečnosti systému a certifikácia jeho spoľahlivosti sú rôzne procesy. Spoľahlivosť je možné kvantifikovať pomocou rôznych číselných ukazovateľov. Bezpečnosť nie je možné spoľahlivo kvantifikovať, a preto ju nemožno merať počas testovania systému.
Bezpečnostná certifikácia preto určuje úroveň spoľahlivosti systému, ktorá sa môže pohybovať od „veľmi nízkej“ po „veľmi vysokú“. Vyžaduje si to odborné posúdenie bezpečnosti. V mnohých prípadoch je definícia bezpečnosti založená na skúsenostiach organizácie vyvíjajúcej systém. Ak už má organizácia vopred vyvinuté, spoľahlivo fungujúce bezpečné systémy, potom je rozumné predpokladať, že podobné bezpečné systémy budú v tejto organizácii vyvinuté. Na druhej strane, hodnotenie bezpečnosti by malo vychádzať zo skutočnej architektúry systému, výsledkov overovania a kvalifikácie a procesov, ktoré boli použité pri vývoji systému.
4.3. Overovanie a certifikácia
Overovanie a certifikácia systémov kritických z hľadiska bezpečnosti má veľa spoločného s testovaním akýchkoľvek systémov s vysokými požiadavkami na spoľahlivosť. Na odhalenie najväčšieho počtu chýb by ste mali pri hodnotení bezpečnosti používať komplexné testovanie a statické testovacie metódy. Avšak kvôli extrémne nízkej poruchovosti, ktorá je vlastná mnohým CS, pomocou statického testovania nie je vždy možné kvantifikovať bezporuchovú prevádzku, pretože to vyžaduje veľmi veľký počet testov. Tieto testy poskytujú iba dôvody na to, aby sa ten alebo ten CS považoval za bezpečný.
Pri vytváraní CS je dôležitá komplexná analýza vyvíjaného systému. Pre CS je potrebných päť typov systémovej analýzy:
1. Analýza správneho fungovania systému
2. Analýza možnosti zmeny a zrozumiteľnosti architektúry systému
3. Analýza súladu algoritmu spracovania a štruktúry údajov so správaním systému definovaným v špecifikácii
4. Analýza konzistencie programového kódu, algoritmov a dátových štruktúr.
5. Analýza primeranosti testovacích scenárov k systémovým požiadavkám.
Všetky dôkazy o bezpečnosti systému sú založené na nasledujúcom predpoklade: počet chýb v systéme, ktoré vedú k núdzovým situáciám, je oveľa menší ako celkový počet chýb v systéme. Bezpečnostné úsilie by sa malo zamerať na identifikáciu potenciálne nebezpečných chýb. Ak sa ukáže, že tieto chyby sa nezobrazujú alebo nezobrazujú, ale nevedú k vážnym následkom, potom sa systém považuje za spoľahlivý. Dôkazy o správnosti programu boli navrhnuté ako metódy overovania softvéru pred viac ako 25 rokmi. Tieto metódy sa však používajú najmä v laboratóriách. Praktické problémy konštrukcie dôkazu správnosti softvéru sú také zložité, že niektoré organizácie považujú použitie týchto metód pri vývoji konvenčných systémov za neprimerane drahé. Ale, ako už bolo spomenuté vyššie, pre množstvo CS je ekonomicky výhodné použiť dôkazy o správnosti systému namiesto odstraňovania následkov porúch.
Hoci nie je nákladovo efektívne vypracovať dôkazy o správnosti pre väčšinu systémov, niekedy je potrebné vyvinúť bezpečnostné dôkazy, ktoré dokazujú, že daný program spĺňa bezpečnostné požiadavky. Pri preukazovaní bezpečnosti nie je potrebné preukazovať zhodu programu so špecifikáciou. Je len potrebné ukázať, že vykonávanie programu nevedie k zlyhaniam s nebezpečnými následkami.
Záver
V tejto práci sa zaoberali otázkami overovania a certifikácie softvéru. Bolo dokázané, že ide o veľmi zložité kroky pri vývoji akéhokoľvek produktu, ktoré si vyžadujú pozornosť, najvyššiu kvalifikáciu, trpezlivosť inžinierov a veľké investície od organizácie. Bez ohľadu na to, aké drahé sú tieto procesy, ekonomické výhody ich použitia sú zrejmé, pretože systém bez porúch nespôsobuje straty. Malo by sa pamätať na to, že núdzové situácie sú zriedkavé udalosti (najmä v kompresorovej stanici), takže je takmer nemožné ich simulovať počas testovania systému. Zistilo sa, že bezpečnostné požiadavky nikdy nevylučujú nedôveryhodné správanie systému. Testovanie a iné kvalifikačné procesy nemôžu úplne preukázať zhodu systému s bezpečnostnými požiadavkami.
V súčasnosti je hodnotenie bezpečnosti systémov čoraz dôležitejšie, keďže systémy sa čoraz viac prepájajú cez internet. Bezpečnostné požiadavky sú v niektorých ohľadoch podobné bezpečnostným požiadavkám. Predovšetkým definujú abnormálne správanie systému, a nie jeho „prevádzkové“ správanie. Vo všeobecnosti však nie je možné definovať toto správanie z hľadiska jednoduchých systémom riadených obmedzení.
Pre koncových používateľov je veľmi ťažké overiť bezpečnosť systému. Preto boli v Európe vyvinuté systémy kritérií hodnotenia bezpečnosti, ktoré kontrolujú špeciálne vyškolení odborníci. Dodávatelia hotového softvéru môžu svoje finálne produkty predložiť na hodnotenie a certifikáciu podľa rôznych bezpečnostných kritérií.
Overovanie a certifikácia by sa mali stať povinnými krokmi vo vývoji softvéru, dokonca aj tými najjednoduchšími. Každá firma vyrábajúca softvér musí vytvoriť personál zo zamestnancov, ktorí sa budú zaoberať len overovaním a certifikáciou: sú to testovací inžinieri, inšpekční inžinieri atď. Organizácie musia brať do úvahy ekonomickú situáciu na softvérovom trhu, želania používateľov (už má bolo zaznamenané, že požiadavky používateľov na softvér rastú).
Ak splníme všetky tieto požiadavky, potom s najväčšou pravdepodobnosťou príde deň, keď budeme obklopení systémami, ktoré fungujú bez porúch.
Literatúra.
1. Sommerville I. Software Engineering, 6. vydanie: Prel. z angličtiny – M.: Vydavateľstvo. Dom. “Williams”, 2002. – 624 s.: chorý.
2. A.G. Gein, V.G. Žitomirskij. Základy informatiky a výpočtovej techniky: vzorky. Učebnica Pre 10-11 ročníkov. priem. školy – 3. vyd. – M.: Školstvo, 1993. – 254 s.: chor.
3. Yu G. Karpov. Teória automatov. – Petrohrad: Peter, 2002 – 224 s.: chor.
4. Elektronický archív pre softvérových inžinierov. http://www.cs.queensu.ca/Software-Engineering/
5. Otázky a odpovede softvérového inžinierstva. http://www.cs.queensu.ca/Software-Engineering/questions.html
6. Zdroje servera Carnegie Mellon Software Engineering Institute. http://www.sei.cmu.edu/
7. SybaseDevel.Ru – ruský portál pre vývojárov. http://www.sybasedevel.ru
Bitdefender Antivirus: Efektívny Defender bez otázok
Význam slova neúspešný
Recenzia Samsung Galaxy A7 (2017): nebojte sa vody a šetrite Oplatí sa kúpiť samsung a7
Vytvorenie zálohy firmvéru v systéme Android
Ako nakonfigurovať swap súbor?