20. Kontrollimine ja kvalifitseerimine tarkvara
Kontrollimine ja kinnitamine viitavad kontrolli- ja ülevaatusprotsessidele, mis kontrollivad tarkvara vastavust selle spetsifikatsioonidele ja kliendi nõuetele. Kontrollimine ja kvalifitseerimine hõlmab kõiki eluring Tarkvara - need algavad nõuete analüüsi etapis ja lõpevad programmikoodi kontrollimisega valmis tarkvarasüsteemi testimise etapis.
Kontrollimine ja tõendamine ei ole sama asi, kuigi neid on lihtne segi ajada. Lühidalt võib nende erinevust määratleda järgmiselt:
Kontrollimine annab vastuse küsimusele, kas süsteem on õigesti projekteeritud;
Sertifitseerimine annab vastuse küsimusele, kas süsteem töötab õigesti.
Nende definitsioonide kohaselt kontrollib kontrollimine, kas tarkvara vastab süsteemi spetsifikatsioonidele, eelkõige funktsionaalsetele ja mittefunktsionaalsetele nõuetele. Sertifitseerimine – rohkem üldine protsess. Valideerimisel tuleb veenduda, et tarkvaratoode vastab kliendi ootustele. Valideerimine viiakse läbi pärast kontrollimist, et teha kindlaks, kuidas süsteem vastab mitte ainult spetsifikatsioonile, vaid ka kliendi ootustele.
Nagu varem märgitud, on süsteeminõuete valideerimine tarkvaraarenduse algfaasis väga oluline. Sageli esineb nõuetes vigu ja puudusi; sellistel juhtudel ei vasta lõpptoode tõenäoliselt kliendi ootustele. Kuid loomulikult ei saa nõuete valideerimine paljastada kõiki nõuete spetsifikatsiooni probleeme. Mõnikord avastatakse lüngad ja vead nõuetes alles pärast süsteemi juurutamise lõppu.
Kontrollimise ja kinnitamise protsessid kasutavad süsteemide kontrollimiseks ja analüüsimiseks kahte peamist tehnikat.
1. Tarkvara kontroll. Süsteemi erinevate esituste, näiteks nõuete spetsifikatsiooni dokumentatsiooni, arhitektuursed diagrammid või programmi lähtekoodi analüüs ja kontrollimine. Kontrollimine toimub tarkvarasüsteemi arendusprotsessi kõikides etappides. Paralleelselt kontrolliga saab teostada programmide lähtekoodi ja nendega seotud dokumentide automaatset analüüsi. Kontrollimine ja automatiseeritud analüüs on staatilised kontrolli- ja valideerimismeetodid, kuna need ei vaja käivitatavat süsteemi.
2. Tarkvara testimine. Käivitatava koodi käivitamine koos testandmetega ning väljundi ja jõudluse uurimine tarkvaratoode et kontrollida süsteemi õiget toimimist. Testimine on dünaamiline kontrollimise ja kinnitamise meetod, kuna seda rakendatakse töötavale süsteemile.
Joonisel fig. Joonis 20.1 näitab kontrolli ja testimise kohta tarkvara arendusprotsessis. Nooled näitavad arendusprotsessi etappe, kus neid meetodeid saab rakendada. Selle skeemi järgi saab ülevaatust läbi viia süsteemi arendusprotsessi kõikides etappides ja testimist – prototüübi või käivitatava programmi loomisel.
Kontrollimeetodid hõlmavad programmi kontrollimist, automaatset lähtekoodi analüüsi ja ametlikku kontrolli. Kuid staatiliste meetoditega saab kontrollida ainult programmide vastavust spetsifikatsioonile, neid ei saa kasutada süsteemi korrektse toimimise kontrollimiseks. Lisaks ei saa staatiliste meetoditega testida mittefunktsionaalseid omadusi, nagu jõudlus ja töökindlus. Seetõttu viiakse mittefunktsionaalsete omaduste hindamiseks läbi süsteemi testimine.
Riis. 20.1. Staatiline ja dünaamiline kontrollimine ja tõendamine
Vaatamata tarkvara kontrollimise laialdasele kasutamisele on testimine endiselt valdav kontrolli- ja sertifitseerimismeetod. Testimine on programmide töö kontrollimine reaalsete andmetega, mida töödeldakse süsteemi töötamise ajal. Defektide ja nõuetele mittevastavuse olemasolu programmis tuvastatakse väljundandmete uurimisel ja nende hulgast anomaalsete tuvastamisel. Testimine viiakse läbi süsteemi juurutamise faasis (kontrollimaks, kas süsteem vastab arendajate ootustele) ja pärast selle juurutamist.
Tarkvara arendusprotsessi erinevates etappides erinevat tüüpi testimine.
1. Defektide testimine viiakse läbi programmi ja selle spetsifikatsiooni vahelise ebakõlade tuvastamiseks, mis on tingitud programmide vigadest või defektidest. Sellised testid on mõeldud süsteemi vigade tuvastamiseks, mitte selle toimimise simuleerimiseks.
2. Statistiline testimine hindab programmide jõudlust ja töökindlust, samuti süsteemi tööd erinevates töörežiimides. Testid on loodud selleks, et jäljendada süsteemi tegelikku tööd tegelike sisendandmetega. Süsteemi töökindlust hinnatakse programmide töös märgitud tõrgete arvu järgi. Toimivust hinnatakse, mõõtes katseandmete töötlemisel kogu tööaega ja süsteemi reageerimisaega.
Kontrollimise ja kvalifitseerimise peamine eesmärk on veenduda, et süsteem on "eesmärgile sobiv". Tarkvarasüsteemi sobivus ettenähtud otstarbele ei tähenda, et see peaks olema täiesti vigadeta. Pigem peaks süsteem mõistlikult hästi sobima eesmärkidega, milleks see mõeldud oli. Nõutud vastavuse kehtivus sõltub süsteemi eesmärgist, kasutajate ootustest ja tarkvaratoodete turutingimustest.
1. Tarkvara eesmärk. Vastavuse usaldusväärsuse tase sõltub sellest, kui kriitiline on arendatud tarkvara teatud kriteeriumide järgi. Näiteks peaks ohutuse seisukohalt oluliste süsteemide usaldusväärsuse tase olema oluliselt kõrgem kui prototüüpide samasugune usaldustase. tarkvarasüsteemid arendatakse välja, et näidata mõningaid uusi ideid.
2. Kasutajate ootused. Kurbusega tuleb tõdeda, et praegu on enamikul kasutajatel tarkvarale madalad nõudmised. Kasutajad on programmide töötamise ajal tekkivate tõrgetega nii harjunud, et nad ei ole selle üle üllatunud. Nad on valmis taluma süsteemitõrkeid, kui selle kasutamisest saadav kasu kaalub üles puudused. Alates 1990. aastate algusest on aga kasutajate tolerantsus tarkvarasüsteemide rikete suhtes järk-järgult vähenenud. Viimasel ajal on ebausaldusväärsete süsteemide loomine muutunud peaaegu vastuvõetamatuks, mistõttu peavad tarkvaraarenduse ettevõtted järjest rohkem tähelepanu pöörama tarkvara kontrollimisele ja valideerimisele.
3. Tarkvara turu tingimused. Tarkvarasüsteemi hindamisel peab müüja teadma konkureerivaid süsteeme, hinda, mida ostja on nõus süsteemi eest maksma, ja selle süsteemi eeldatavat turuletuleku aega. Kui arendusettevõttel on mitu konkurenti, on vaja enne täieliku testimise ja silumise lõppu määrata süsteemi turuletuleku kuupäev, vastasel juhul võivad konkurendid turule tulla esimestena. Kui kliendid ei soovi tarkvara kõrge hinnaga ostma, võivad nad olla valmis taluma rohkem süsteemitõrkeid. Kontrollimise ja kvalifitseerimise protsessi kulude kindlaksmääramisel tuleb kõiki neid tegureid arvesse võtta.
Reeglina leitakse süsteemis vigu kontrollimise ja atesteerimise käigus. Vigade parandamiseks tehakse süsteemis muudatusi. See silumisprotsess tavaliselt integreeritud muude kontrollimis- ja atesteerimisprotsessidega. Testimine (või üldisemalt kontrollimine ja kinnitamine) ja silumine on aga erinevad protsessid, millel on erinevad eesmärgid.
1. Kontrollimine ja kinnitamine on tarkvarasüsteemi defektide tuvastamise protsess.
2. Silumine - defektide (vigade) lokaliseerimise ja nende parandamise protsess (joon. 20.2).
Riis. 20.2. Silumisprotsess
Programmide silumiseks pole lihtsaid meetodeid. Kogenud silujad leiavad vead, võrreldes testimise väljundmustreid testitavate süsteemide väljundiga. Vea leidmiseks on vaja teadmisi veatüüpide, väljundmustrite, programmeerimiskeele ja programmeerimisprotsessi kohta. Tarkvaraarenduse protsessi tundmine on väga oluline. Silujad on teadlikud kõige levinumatest programmeerimisvigadest (nt loenduri suurendamine). Samuti võtab see arvesse teatud programmeerimiskeeltele omaseid vigu, näiteks neid, mis on seotud osutite kasutamisega C-keeles.
Vigade leidmine programmikoodis ei ole alati lihtne protsess, kuna viga ei pruugi asuda programmikoodi selle punkti lähedal, kus krahh toimus. Vigade isoleerimiseks töötab silur välja täiendavaid tarkvarateste, mis aitavad tuvastada programmis vea allika. Võimalik, et peate programmi täitmist käsitsi jälgima.
Interaktiivsed silumistööriistad on osa keeletoe tööriistade komplektist, mis on integreeritud koodi koostamise süsteemiga. Need pakuvad spetsiaalset programmi täitmiskeskkonda, mille kaudu pääsete juurde identifikaatorite tabelile ja sealt muutujate väärtustele. Kasutajad juhivad sageli programmi täitmist samm-sammult, astudes järjest lauselt lauseni. Pärast iga avalduse täitmist kontrollitakse muutujate väärtusi ja tuvastatakse võimalikud vead.
Programmis leitud viga parandatakse, misjärel on vaja programmi uuesti kontrollida. Selleks saate programmi uuesti üle vaadata või korrata eelmist testi. Kordustestimist kasutatakse selleks, et programmis tehtud muudatused ei tooks süsteemi uusi vigu, sest praktikas suur osa "veaparandustest" kas ei jõua täielikult lõpule või lisab programmi uusi vigu.
Põhimõtteliselt on vaja pärast iga parandamist uuesti testida kõik testid, kuid praktikas on see lähenemine liiga kulukas. Seetõttu määratakse testimisprotsessi planeerimisel süsteemi osade vahelised sõltuvused ja iga osa jaoks määratakse testid. Seejärel on võimalik programmi elemente jälgida nende elementide jaoks valitud spetsiaalsete testjuhtumite (kontrollandmete) abil. Kui jälitustulemused on dokumenteeritud, saab muudetud programmielemendi ja sellest sõltuvate komponentide testimiseks kasutada ainult kogu testandmete alamhulka.
Selle kursuse eesmärk on anda terviklik ülevaade tarkvara kontrollimise protsessist. Arutelu teemaks on verifitseerimise ja eelkõige tarkvara testimise valdkonnas kasutatavad erinevad lähenemised ja meetodid. Eeldatakse, et arendatav tarkvara on osa suuremast ühine süsteem. Selline süsteem sisaldab riistvara, informatsiooni ja organisatsioonilisi (inimkasutaja, inimoperaatori jne) komponente, mis võivad olla välja töötatud erinevate meeskondade poolt. Seetõttu on vaja arendusdokumente, mis määratlevad nõuded süsteemi erinevatele komponentidele ja nende koostoime reeglid. Lisaks eeldatakse, et süsteemirikked võivad kaasa tuua ühe või teise raskusastme tagajärgi, seetõttu on tarkvara arendamisel varjatud defektide tuvastamiseks kulutatud pingutused vajalikud ja õigustatud. Esiteks puudutab see tarkvara kontrollimise vahendeid ja protseduure. Kursus sisaldab mitmeid praktilisi harjutusi, mis illustreerivad lihtsa süsteemi näitel tarkvara verifitseerimise tehnikaid ja meetodeid Microsoft Visual Studio 2005 Team Edition for Software Testers keskkonnas. See väljaanne on osa õppekavade raamatukogust, mida arendab MSDN Academic Alliance (MSDN AA) akadeemiline koostööprogramm.
Allolev tekst ekstraheeritakse automaatselt algsest PDF-dokumendist ja on mõeldud ainult eelvaate eesmärgil.
Puuduvad pildid (pildid, valemid, graafikud).
Riis. 7 Testimine, kontrollimine ja valideerimine Tarkvara verifitseerimine on üldisem mõiste kui testimine. Taatluse eesmärk on saavutada kindlus, et taatletav objekt (nõuded või programmikood) vastab nõuetele, on realiseeritud ilma soovimatute funktsioonideta ning vastab proja standarditele. Kontrolliprotsess hõlmab ülevaatusi, koodide testimist, testitulemuste analüüsi, probleemiaruannete genereerimist ja analüüsi. Seega on üldiselt aktsepteeritud, et testimisprotsess on kontrolliprotsessi lahutamatu osa, sama eeldus on tehtud ka käesoleval koolitusel. Tarkvarasüsteemi valideerimine on protsess, mille eesmärk on tõestada, et oleme süsteemi arendamise tulemusena saavutanud eesmärgid, mida plaanisime selle kasutamisega saavutada. Teisisõnu, valideerimine on süsteemi vastavuse kontrollimine kliendi ootustele. Valideerimisega seotud probleemid ei kuulu selle reguleerimisalasse koolitus ja kujutavad endast eraldi huvitavat uurimisteemat. Kui vaadata neid kolme protsessi küsimusena, millele nad vastavad, siis testimine vastab küsimusele "Kuidas seda tehakse?" või "Kas arendatud programmi käitumine vastab nõuetele?" Kontrollimine - "Mida on tehtud?" või "Kas arendatud süsteem vastab nõuetele?" ja valideerimine on "Kas see tegi seda, mida ta peab tegema?" või "Kas väljatöötatud süsteem vastab kliendi ootustele?". 1.7. Elutsükli erinevatel etappidel loodud dokumentatsioon Kõikide arenguetappide sünkroniseerimine toimub igas etapis koostatavate dokumentide abil. Samal ajal luuakse dokumentatsioon nii elutsükli otseses segmendis - tarkvarasüsteemi väljatöötamise ajal kui ka vastupidises - selle kontrollimise ajal. Proovime V-kujulise elutsükli näitel jälgida, mis tüüpi dokumente igale segmendile luuakse ja millised seosed nende vahel eksisteerivad (joonis 8). Süsteeminõuete arendamise etapi tulemuseks on süsteemile sõnastatud nõuded - dokument, mis kirjeldab süsteemi töö üldpõhimõtteid, selle koostoimet süsteemiga " keskkond» - süsteemi kasutajad, samuti selle toimimist tagavad tarkvara ja riistvara. Tavaliselt koostatakse paralleelselt süsteemile esitatavate nõuetega verifitseerimisplaan ja määratletakse verifitseerimisstrateegia. Need dokumendid määratlevad üldise lähenemisviisi sellele, kuidas testimine toimub, milliseid metoodikaid rakendatakse ja milliseid tulevase süsteemi aspekte tuleks rangelt testida. Teine verifitseerimisstrateegia defineerimisega lahendatav ülesanne on määrata kindlaks erinevate verifitseerimisprotsesside koht ja nende seos arendusprotsessidega. 20 Süsteeminõuetega töötav verifitseerimisprotsess on nõuete valideerimise protsess, võrreldes neid kliendi tegelike ootustega. Tulevikku vaadates oletame, et valideerimisprotsess erineb valmissüsteemi kliendile üleandmisel läbiviidavatest vastuvõtutestidest, kuigi seda võib lugeda selliste testide osaks. Valideerimine on vahend tõestamaks mitte ainult süsteemi rakendamise õigsust kliendi seisukohast, vaid ka selle väljatöötamise aluseks olevate põhimõtete õigsust. Riis. 8 Tarkvarasüsteemide arendusprotsessid ja dokumendid Süsteeminõuded on funktsionaalsete nõuete arendusprotsessi ja projekti arhitektuuri aluseks. Selle protsessi käigus töötatakse välja üldised nõuded süsteemi tarkvarale, funktsioonidele, mida see täitma peab. Funktsionaalsed nõuded hõlmavad sageli süsteemi käitumismustrite määratlemist normaalsetes ja hädaolukorrad , andmetöötlusreeglid ja kasutajaliidese definitsioonid. Nõude tekst sisaldab reeglina sõnu "peab, peab" ja selle ülesehitus on kujul "Kui ABC-anduri temperatuuri väärtus jõuab 30 kraadini Celsiuse järgi või rohkem, peab süsteem helisignaali andmise lõpetama. ” Funktsionaalsed nõuded on süsteemiarhitektuuri väljatöötamise aluseks - selle struktuuri kirjeldus allsüsteemide ja selle keele struktuuriüksuste lõikes, milles rakendamine toimub - valdkonnad, klassid, moodulid, funktsioonid jne. Funktsionaalsetest nõuetest lähtuvalt koostatakse testinõuded - dokumendid, mis sisaldavad võtmepunktide määratlust, mida tuleb kontrollida, et veenduda funktsionaalsete nõuete täitmise korrektsuses. Testinõuded algavad sageli sõnadega "Kontrolli mida" ja sisaldavad linke nende vastavatele funktsionaalsetele nõuetele. Ülaltoodud funktsionaalse nõude katsenõuete näidised oleksid järgmised: "Veenduge, et kui ABC-anduri temperatuur langeb alla 30 kraadi Celsiuse järgi, annab süsteem hoiatusheli" ja "Veenduge, et kui ABC-anduri temperatuur ületab 30 kraadi Celsiuse järgi, siis süsteem ei piiksu." 21 Üks testnõuete kirjutamisel tekkiv probleem on osade nõuete põhimõtteline testimatus, näiteks nõuet “Kasutajaliides peab olema intuitiivne” ei saa testida ilma selge definitsioonita, mis on intuitiivne liides. Selliseid mittespetsiifilisi funktsionaalseid nõudeid muudetakse tavaliselt hiljem. Süsteemi arhitektuursed omadused võivad olla ka allikaks testinõuete koostamiseks, mis võtavad arvesse süsteemi tarkvararakenduse iseärasusi. Sellise nõude näide on näiteks "Kontrollige, et ABC-anduri temperatuuri väärtus ei ületaks 255". Funktsionaalsete nõuete ja arhitektuuri alusel kirjutatakse süsteemi programmikood ning selle kontrollimiseks koostatakse testimisnõuete alusel testimisplaan - testimisjuhtumite järjestuse kirjeldus, mis kontrollib süsteemi nõuetele vastavust. süsteemi juurutamine vastavalt nõuetele. Iga testjuhtum sisaldab konkreetset kirjeldust süsteemile sisendiks antud väärtuste kohta, väljundina oodatavaid väärtusi ja testi täitmise stsenaariumi kirjeldust. Olenevalt testimise objektist saab testimisplaani koostada kas programmina programmeerimiskeeles või sisendandmete failina tööriistakomplektile, mis käivitab testitava süsteemi ja edastab sellele testiplaanis määratud väärtused, või juhistena kasutajale.süsteem, mis kirjeldab vajalikke samme süsteemi erinevate funktsioonide testimiseks. Kõikide testjuhtumite täitmise tulemusena kogutakse statistika testi läbimise edukuse kohta - testjuhtumite protsent, mille puhul reaalsed väljundväärtused kattusid oodatud väärtustega, nn läbitud testid. Ebaõnnestunud testid on lähteandmed vigade põhjuste analüüsimiseks ja nende hilisemaks parandamiseks. Integreerimisetapis koondatakse üksikud süsteemimoodulid ühtseks tervikuks ja teostatakse testjuhtumid, mis kontrollivad kogu süsteemi funktsionaalsust. Viimases etapis tarnitakse valmis süsteem kliendile. Enne juurutamist viivad kliendi spetsialistid koos arendajatega läbi vastuvõtutestid – kontrollivad kasutaja jaoks kriitilise tähtsusega funktsioone vastavalt eelnevalt kinnitatud testprogrammile. Pärast testide edukat sooritamist antakse süsteem üle kliendile, vastasel juhul saadetakse see ülevaatamiseks. 1.8. Testimis- ja kontrolliprotsesside tüübid ja nende koht erinevates olelustsükli mudelites 1.8.1. Ühiktestimine Väikeste ühikute (protseduurid, klassid jne) suhtes tehakse ühikutesti. Suhteliselt väikese, 100-1000 rea suuruse mooduli testimisel on võimalik kontrollida kui mitte kõiki, siis vähemalt paljusid loogilisi harusid juurutamisel, erinevaid teid andmete sõltuvuse graafikus, parameetrite piirväärtusi. Vastavalt sellele konstrueeritakse testi katvuse kriteeriumid (kaetud on kõik operaatorid, kõik loogilised harud, kõik piiripunktid jne). . Ühiktestimine tehakse tavaliselt iga sõltumatu jaoks tarkvara moodul ja see on ehk kõige levinum testimisviis, eriti väikeste ja keskmise suurusega süsteemide puhul. 1.8.2. Integratsioonitestimine Kõikide moodulite õigsuse kontrollimine ei garanteeri kahjuks moodulite süsteemi korrektset toimimist. Kirjanduses käsitletakse mõnikord moodulite süsteemi testimise ebaõige korralduse "klassikalist" mudelit, mida sageli nimetatakse "suure hüppe" meetodiks. Meetodi olemus seisneb selles, et esmalt testitakse iga moodulit eraldi, seejärel kombineeritakse need süsteemiks ja testitakse kogu süsteemi. Suurte süsteemide puhul on see ebareaalne. Selle lähenemisviisi korral kulub vigade lokaliseerimisele palju aega ja testimise kvaliteet jääb madalaks. Alternatiiviks "suurele hüppele" on integratsioonitestimine, kui süsteemi etapiviisiliselt üles ehitades lisandub järk-järgult moodulirühmi. 1.8.3. Süsteemi testimine Täielikult juurutatud tarkvaratoode allutatakse süsteemi testimisele. Selles etapis ei huvita testijat mitte üksikute protseduuride ja meetodite rakendamise õigsus, vaid kogu programm tervikuna, nii nagu lõppkasutaja seda näeb. Testide aluseks on Üldnõuded programmile, sealhulgas mitte ainult funktsioonide rakendamise õigsusele, vaid ka jõudlusele, reageerimisajale, tõrgetele, rünnakutele, kasutaja vigadele jne. Süsteemi ja komponentide testimiseks kasutatakse kindlat tüüpi testide katvuskriteeriume (nt kas kõik tüüpilised tööstsenaariumid on hõlmatud, kõik ebatavaliste olukordadega stsenaariumid, paarisstsenaariumikoostised jne). 1.8.4. Koormustestimine Koormustestimine mitte ainult ei anna ennustavaid andmeid süsteemi jõudluse kohta koormuse all, mis on keskendunud arhitektuursete otsuste tegemisele, vaid annab ka operatiivteavet tehnilise toe meeskondadele ning projekti- ja konfiguratsioonihalduritele, kes vastutavad kõige produktiivsema süsteemi loomise eest. riist- ja tarkvara konfiguratsioonid. Koormustestimine võimaldab arendusmeeskonnal teha teadlikumaid otsuseid, mille eesmärk on välja töötada optimaalsed arhitektuursed kompositsioonid. Klient saab omalt poolt võimaluse teha vastuvõtuteste reaalsusele lähedastes tingimustes. 1.8.5. Ametlikud kontrollid Formaalne kontroll on üks viise kontrollida tarkvaraarenduse käigus loodud dokumente ja programmikoodi. Ametliku kontrolli käigus kontrollib spetsialistide rühm iseseisvalt kontrollitud dokumentide vastavust originaaldokumentidele. Taatluse sõltumatuse tagab asjaolu, et seda viivad läbi inspektorid, kes ei osalenud kontrollitava dokumendi väljatöötamises. 1.9. Sertifitseeritava tarkvara kontrollimine Anname mõned määratlused, mis määratlevad üldine struktuur Tarkvara sertifitseerimisprotsess: Tarkvara sertifitseerimine on protsess, mille käigus tehakse kindlaks ja ametlikult tunnustatakse, et tarkvara arendus on läbi viidud vastavalt teatud nõuetele. Sertifitseerimisprotsessi käigus toimub taotleja, sertifitseerimisasutuse ja järelevalveasutuse suhtlus, taotleja on organisatsioon, kes esitab vastavale sertifitseerimisasutusele taotluse sertifikaadi (vastavus, kvaliteet, sobivus jne) saamiseks. toode. Sertifitseerimisasutus – organisatsioon, mis vaatab läbi taotleja tarkvara sertifitseerimise taotluse ja koostab iseseisvalt või spetsiaalse komisjoni moodustamise teel protseduuride kogumi, mis on suunatud taotleja tarkvara sertifitseerimise protsessi läbiviimisele. 23 Järelevalveorgan - spetsialistidest koosnev komisjon, kes juhib sertifitseeritud sertifikaadi taotleja poolt väljatöötamise protsesse. infosüsteem ja selle protsessi teatud nõuetele vastavuse kohta arvamuse andmine, mis esitatakse sertifitseerimisasutusele kaalumiseks. Sertifitseerimine võib olla suunatud vastavussertifikaadi või kvaliteedisertifikaadi saamisele. Esimesel juhul on sertifitseerimise tulemuseks arendusprotsesside teatud kriteeriumidele vastavuse ja süsteemi funktsionaalsuse teatud nõuetele vastavuse tunnustamine. Selliste nõuete näideteks võivad olla juhenddokumendid. Föderaalteenistus tehnilise ja ekspordikontrolli kohta tarkvarasüsteemide turvalisuse valdkonnas. Teisel juhul on tulemuseks arendusprotsesside teatud kriteeriumitele vastavuse tunnustamine, mis tagab valmistatava toote sobiva kvaliteeditaseme ja selle kasutussobivuse teatud tingimustes. Selliste standardite näiteks on rida rahvusvahelisi kvaliteedistandardeid ISO 9000:2000 (GOST R ISO 9000-2001) või lennundusstandardeid DO-178B, AS9100, AS9006. Sertifitseeritava tarkvara testimisel on kaks üksteist täiendavat eesmärki: Esimene eesmärk on näidata, et tarkvara vastab sellele esitatavatele nõuetele. Teine eesmärk on näidata suure kindlustundega, et testimise käigus tuvastatakse vead, mis võivad põhjustada lubamatuid rikkeolukordi, nagu on kindlaks määratud süsteemi ohutuse hindamise protsessis. Näiteks vastavalt DO-178B standardi nõuetele on tarkvara testimise eesmärkide täitmiseks vajalik: Testid peavad esmalt põhinema tarkvaranõuetel; Testid tuleks kavandada nii, et kontrollitakse õiget toimimist ja luuakse tingimused võimalike vigade tuvastamiseks. Tarkvaranõuetel põhinevate testide täielikkuse ülevaatamine peaks kindlaks tegema, milliseid nõudeid ei testita. Programmikoodi struktuuril põhinev testide täielikkuse analüüs peaks välja selgitama, milliseid struktuure testimise käigus ei teostatud. See standard räägib ka nõuetepõhisest testimisest. See strateegia on osutunud vigade tuvastamisel kõige tõhusamaks. Nõuetest lähtuvate testjuhtumite valimise juhised hõlmavad järgmist: Tarkvara testimise eesmärkide saavutamiseks tuleks läbi viia kahte kategooria teste: tavaolukordade testid ja ebanormaalsete (mittevajalike, robustsete) olukordade testid. Tarkvara arendusprotsessile omaste tarkvaranõuete ja veaallikate jaoks tuleks välja töötada konkreetsed testjuhtumid. Tavaolukordade testide eesmärk on näidata tarkvara võimet reageerida tavapärastele sisenditele ja tingimustele vastavalt nõuetele. 24 Ebatavaliste olukordade testide eesmärk on näidata tarkvara võimet adekvaatselt reageerida ebatavalistele sisenditele ja tingimustele, teisisõnu ei tohiks see põhjustada süsteemi tõrkeid. Süsteemi rikkeolukordade kategooriad määratakse kindlaks õhusõiduki ja selles viibijate rikkeolukorra ohu kindlaksmääramise teel. Iga tarkvaraviga võib põhjustada tõrke, mis aitab kaasa tõrkeolukorrale. Seega on ohutuks tööks vajalik tarkvara terviklikkuse tase seotud süsteemi rikkeolukordadega. Rikete olukordi on viis taset, alates väiksemast kuni kriitiliseni. Vastavalt nendele tasemetele võetakse kasutusele tarkvara kriitilisuse taseme mõiste. Kriitilisuse tase määrab sertifitseerimisasutusele esitatava dokumentatsiooni koostise ja sellest tulenevalt ka süsteemi arendus- ja kontrolliprotsesside sügavuse. Näiteks võib DO-178B madalaima kriitilisuse taseme sertifitseerimiseks vajalike dokumentide liikide arv ja süsteemiarendustöö maht erineda kõige rohkem ühe või kahe suurusjärgu võrra sertifitseerimiseks vajalikust arvust ja mahust. kõrge tase. Konkreetsed nõuded määratakse kindlaks standardiga, mille järgi sertifitseerimist on kavas läbi viia. 25 TEEMA 2. Programmikoodi testimine (loengud 2-5) 2.1. Programmikoodi testimise ülesanded ja eesmärgid Programmikoodi testimine on programmikoodi täitmise protsess, mille eesmärk on tuvastada selles olemasolevad defektid. Defekti all mõistetakse siin programmikoodi lõiku, mille täitmine teatud tingimustel toob kaasa ootamatu süsteemikäitumise (s.o. käitumise, mis ei vasta nõuetele). Süsteemi ootamatu käitumine võib põhjustada tõrkeid selle töös ja tõrkeid, sel juhul räägivad need programmikoodi olulistest defektidest. Mõned vead põhjustavad väiksemaid probleeme, mis ei häiri süsteemi tööd, kuid muudavad sellega töötamise mõnevõrra keeruliseks. Sel juhul räägime keskmistest või väiksematest defektidest. Selle lähenemisviisiga testimise ülesanne on määrata kindlaks tingimused, mille korral süsteemidefektid ilmnevad, ja need tingimused registreerida. Testimisülesanded ei hõlma tavaliselt programmikoodi konkreetsete defektsete osade tuvastamist ega sisalda kunagi defektide parandamist – see on silumisülesanne, mis tehakse süsteemi testimise tulemuste põhjal. Programmikoodi testimise protseduuri rakendamise eesmärk on minimeerida lõpptootes esinevate defektide, eriti oluliste, arvu. Ainuüksi testimine ei saa garanteerida süsteemikoodi defektide täielikku puudumist. Kuid koos kontrolli- ja valideerimisprotsessidega, mille eesmärk on kõrvaldada vastuolud ja ebatäielikkus projekti dokumentatsioon(eelkõige süsteemile esitatavad nõuded), hästi korraldatud testimine tagab, et süsteem vastab nõuetele ja käitub nendele vastavalt kõikides ette nähtud olukordades. Suurendatud töökindlusega süsteemide, näiteks lennunduse, väljatöötamisel saavutatakse töökindlusgarantiid testimisprotsessi selge korralduse, selle seose määramise teiste olelusringi protsessidega, kvantitatiivsete tunnuste kasutuselevõtuga, mis võimaldavad hinnata testimise edukust. Samas, mida kõrgemad on nõuded süsteemi töökindlusele (selle kriitilisuse tasemele), seda rangemad on nõuded. Seega ei võta me kõigepealt arvesse konkreetse süsteemi testimise konkreetseid tulemusi, vaid üldine korraldus testimisprotsess, kasutades lähenemist "hästi organiseeritud protsess annab kvaliteetse tulemuse." Selline lähenemine on omane paljudele rahvusvahelistele ja tööstusharu kvaliteedistandarditele, millest räägitakse üksikasjalikumalt selle kursuse lõpus. Sellise lähenemisega arendatud süsteemi kvaliteet on organiseeritud arendus- ja testimisprotsessi tulemus, mitte iseseisev juhimata tulemus. Kuna tänapäevased tarkvarasüsteemid on väga suured, siis nende programmikoodi testimisel kasutatakse funktsionaalse dekomponeerimise meetodit. Süsteem on jagatud eraldi mooduliteks (klassid, nimeruumid jne), millel on nõuetega määratletud funktsionaalsus ja liidesed. Pärast seda testitakse iga moodulit eraldi – viiakse läbi ühiktestimine. Seejärel monteeritakse üksikud moodulid suuremateks konfiguratsioonideks – teostatakse integratsioonitestimine ja lõpuks testitakse süsteemi tervikuna – teostatakse süsteemi testimine. Programmikoodi seisukohalt on üksusel, integratsioonil ja süsteemi testimisel palju ühist, seega keskendume antud teemas ühikutestimisele, integratsiooni ja süsteemi testimise funktsioonidest tuleb juttu hiljem. 26 Ühikutestimise käigus testitakse iga moodulit nii nõuetele vastavuse kui ka programmikoodi probleemsete osade puudumise osas, mis võivad põhjustada tõrkeid ja tõrkeid süsteemis. Moodulid reeglina väljaspool süsteemi ei tööta – nad saavad andmeid teistelt moodulitelt, töötlevad neid ja annavad edasi. Ühelt poolt mooduli süsteemist isoleerimiseks ja võimalike süsteemivigade mõju välistamiseks ning teisest küljest mooduli kõigi vajalike andmete varustamiseks kasutatakse testkeskkonda. Testkeskkonna ülesanne on luua moodulile käituskeskkond, emuleerida kõiki väliseid liideseid, millele moodul ligi pääseb. Selles teemas käsitletakse testkeskkonna korralduse funktsioone. Tüüpiline testimisprotseduur on testjuhtumite ettevalmistamine ja läbiviimine (mida nimetatakse ka lihtsalt testideks). Iga testjuhtum kontrollib ühte "olukorda" mooduli käitumises ja koosneb mooduli sisendisse edastatud väärtuste loendist, andmetöötluse käivitamise ja täitmise kirjeldusest - teststsenaariumist ja loendist väärtused, mida oodatakse mooduli väljundis selle õige käitumise korral. Testistsenaariumid koostatakse nii, et välistatakse juurdepääs mooduli sisemistele andmetele, kogu interaktsioon peaks toimuma ainult selle väliste liideste kaudu. Testjuhtumi täitmist toetab testkeskkond, mis sisaldab testskripti programmilist juurutamist. Täitmine algab sisendi edastamisega moodulile ja skripti käivitamisega. Skripti täitmise tulemusena moodulilt saadud tegelik väljund salvestatakse ja võrreldakse oodatud väljundiga. Kui need ühtivad, loetakse test sooritatuks, vastasel juhul ei sooritata. Iga ebaõnnestunud test viitab kas testitava seadme või testimiskeskkonna defektile või testi kirjeldusele. Testjuhtumite kirjelduste komplekt on testiplaan – põhidokument, mis määratleb programmimooduli testimise protseduuri. Testiplaanis ei ole määratud mitte ainult testjuhtumid ise, vaid ka nende järgimise järjekord, mis võib samuti olla oluline. Testiplaanide ülesehitust ja iseärasusi käsitletakse selles teemas, testjuhtumite järjestusega seotud probleeme - teemas "Kordatavuse testimine". Tihti tuleb testimisel arvestada mitte ainult süsteemile esitatavate nõuetega, vaid ka testitava mooduli programmikoodi struktuuriga. Sel juhul on testid kavandatud nii, et need tuvastaksid tüüpilised vead programmeerijad, mis on põhjustatud nõuete valesti tõlgendamisest. Rakendatakse piirseisundi kontrolle, samaväärsuse klasside kontrolle. Nõuetega määratlemata võimaluste puudumine süsteemis garanteerib erinevad hinnangud programmikoodi katvusele testidega, s.t. hinnangud selle kohta, mitu protsenti teatud keelekonstruktsioonidest täidetakse kõigi testjuhtumite täitmise tulemusena. Sellest kõigest tuleb teema lõpus juttu. 2.2. Katsemeetodid 2.2.1. Must kast Süsteemi kui musta kasti testimise põhiidee seisneb selles, et kõik testijale kättesaadavad materjalid on süsteemile ja süsteemile endale esitatavad nõuded, millega ta saab töötada vaid mõningaid väliseid mõjutusi rakendades. selle sisenditele ja väljundi jälgimisel mingit tulemust. Kõik süsteemi juurutamise sisemised omadused on testija eest varjatud, seega on süsteem “must kast”, mille õiget käitumist nõuete suhtes tuleb kontrollida. 27 Programmikoodi seisukohalt võib must kast olla klasside (või moodulite) kogum, millel on teadaolevad välised liidesed, kuid ligipääsmatud lähtetekstid. Selle testimismeetodi testija põhiülesanne on järjepidevalt kontrollida, kas süsteemi käitumine vastab nõuetele. Lisaks peab testija testima süsteemi kriitilistes olukordades – mis juhtub, kui sisestatakse valed sisendväärtused. Ideaalses olukorras peaksid kõik kriitiliste olukordade variandid olema süsteemi nõuetes kirjeldatud ja testija saab nende nõuete jaoks välja mõelda ainult konkreetsed kontrollid. Tegelikkuses ilmnevad aga testimise tulemusena tavaliselt kahte tüüpi süsteemiprobleemid: 1. Süsteemi käitumise mittevastavus nõuetele 2. Süsteemi ebaadekvaatne käitumine olukordades, mida nõuded ette ei näe. Mõlemat tüüpi probleemide aruanded dokumenteeritakse ja neid jagatakse arendajatega. Samal ajal põhjustavad esimest tüüpi probleemid tavaliselt programmi koodi muutust, palju harvemini - nõuete muutumist. Nõuete muutmine võib sel juhul olla vajalik nende ebaühtluse (mitu erinevat nõuet kirjeldavad süsteemi käitumise erinevaid mudeleid samas olukorras) või ebakorrektsuse (nõuded ei vasta tegelikkusele) tõttu. Teist tüüpi probleemid nõuavad selgelt nõuete muutmist oma ebatäielikkuse tõttu – nõuetega on selgelt möödas olukord, mis viib süsteemi ebaadekvaatse käitumiseni. Samas võib ebaadekvaatse käitumise all mõista süsteemi täielikku kokkuvarisemist või üldiselt mistahes käitumist, mida nõuetes ei kirjeldata. Musta kasti testimist nimetatakse ka nõuete testimiseks. see on ainus teabeallikas katseplaani koostamiseks. 2.2.2. Klaasist (valge) kast Klaaskasti sarnase süsteemi testimisel on testeril juurdepääs mitte ainult süsteemile esitatavatele nõuetele, selle sisenditele ja väljunditele, vaid ka selle sisemisele struktuurile – näeb selle programmikoodi. Programmikoodi saadavus avardab testija võimalusi sellega, et ta näeb nõuete vastavust programmikoodi lõikudele ja näeb seeläbi, kas on olemas nõuded kogu programmikoodile. Programmikoodi, mille jaoks pole nõudeid, nimetatakse nõueteta koodiks. Selline kood on potentsiaalne süsteemi sobimatu käitumise allikas. Lisaks võimaldab süsteemi läbipaistvus süvendada selle probleeme tekitavate valdkondade analüüsi – sageli üks probleem neutraliseerib teise ja need ei teki kunagi korraga. 2.2.3. Mudelitestimine Mudelitestimine on mõnevõrra eemal klassikalistest tarkvara verifitseerimismeetoditest. Esiteks on see tingitud asjaolust, et testimise objektiks ei ole süsteem ise, vaid selle formaalsete vahenditega kujundatud mudel. Kui jätta kõrvale mudeli enda õigsuse ja rakendatavuse kontrollimise küsimused (arvatakse, et selle õigsust ja vastavust algsele süsteemile saab tõestada formaalsete vahenditega), siis on testija käsutuses üsna võimas tööriist analüüsimiseks. süsteemi üldine terviklikkus. Mudeliga töötades saate luua olukordi, mida reaalse süsteemi katselaboris luua ei saa. Süsteemi programmikoodi mudeliga töötades on võimalik analüüsida selle omadusi ja selliseid süsteemi parameetreid nagu algoritmide optimaalsus või stabiilsus. 28 Mudelite testimine ei ole aga levinud just seetõttu, et süsteemi käitumise formaalse kirjelduse väljatöötamisel tekkisid raskused. Üks väheseid erandeid on sidesüsteemid, mille algoritmiline ja matemaatiline aparatuur on üsna hästi arenenud. 2.2.4. Programmikoodi analüüs (ülevaatused) Paljudes olukordades on süsteemi kui terviku käitumise testimine võimatu – programmikoodi üksikuid sektsioone ei pruugita kunagi käivitada, samas kui need on nõuetega kaetud. Eranditöötlejad on näide sellistest koodiosadest. Kui näiteks kaks moodulit saadavad üksteisele arvväärtusi ja väärtuste valideerimise funktsioonid töötavad mõlemas moodulis, siis vastuvõtja mooduli kontrolli funktsioon ei aktiveeru kunagi, sest saatjas lõigatakse kõik valed väärtused ära. Sel juhul tehakse programmikoodi käsitsi analüüs korrektsuse osas, mida nimetatakse ka koodiülevaateks või kontrollideks. Kui kontrolli tulemusena tuvastatakse probleemsed kohad, edastatakse selle kohta teave koos regulaarsete testide tulemustega parandamiseks arendajatele. 2.3. Testikeskkond Suurem osa peaaegu iga keeruka süsteemi testimisest viiakse tavaliselt läbi automaatrežiim. Lisaks on testitav süsteem tavaliselt jagatud eraldi mooduliteks, millest igaüht testitakse esmalt teistest eraldi, seejärel tervikuna. See tähendab, et testimise läbiviimiseks on vaja luua mingi keskkond, mis tagab testitava mooduli käivitamise ja täitmise, edastab sellele sisendandmed, kogub reaalseid väljundandmeid, mis on saadud süsteemi töötamise tulemusena antud sisendandmetel . Pärast seda peaks keskkond võrdlema tegelikke väljundandmeid eeldatavatega ja selle võrdluse põhjal tegema järelduse mooduli käitumise vastavuse kohta etteantule (joonis 9). Testidraiveri oodatavad väljundandmed testimisel Töötlemise sisendandmete mooduli tegelikud väljundandmed 9 Testikeskkonna üldistatud skeem Testkeskkonda saab kasutada ka üksikute süsteemimoodulite võõrandamiseks kogu süsteemist. Süsteemimoodulite eraldamine testimise algfaasis võimaldab täpsemalt lokaliseerida nende programmikoodis tekkivaid probleeme. Mooduli toimimise toetamiseks süsteemist isoleeritult peaks testkeskkond modelleerima kõigi moodulite käitumist, mille funktsioonidele või andmetele testitav moodul ligi pääseb. 29
Saada oma head tööd teadmistebaasi on lihtne. Kasutage allolevat vormi
Üliõpilased, magistrandid, noored teadlased, kes kasutavad teadmistebaasi oma õpingutes ja töös, on teile väga tänulikud.
Majutatud aadressil http://www.allbest.ru/
abstraktne
Tarkvara kontrollimise ja testimise meetodid
Sissejuhatus
Inimesed kipuvad tegema vigu. Vigu on alati olnud ja jääb alati olema. IT keskkonnas käib nali, et kui programm esimest korda käima läheb ja kohe tööle hakkab, siis tuleb viga otsida.
Koos arenguga arvutiteadus, mis on tunginud kõikidesse eluvaldkondadesse, kasvab ka vigade arv programmides. Lisaks on vigade arvu kasv ebaproportsionaalne programmide arvu kasvuga. Igal aastal täiendatakse programmeerijate ridu bydlocoderitega (ja nende nimi on legion), kes arendavad vigade valdkonda eksponentsiaalselt.
Vead ei ole nähtavad igas piirkonnas. Näiteks ei huvita kedagi sellised brauserite nagu "amigo" vead ja haavatavused. Jah, ja kahjud sellistest vigadest on tühised: maksimaalne, mida tavakasutaja võib kaotada, on kontod sotsiaalvõrgustikes, poolteist tuhat keskpärast puhkusefotot ja pornokogu.
Kuid on valdkondi, kus programmeerimisvead võivad viia kõige kahetsusväärsemate tagajärgedeni. Üks esimesi juhtumeid, mis mul õnnestus leida, on kosmoselaev Mariner 1, mis hävis 22. juulil 1962, 293 sekundit pärast starti, pardaarvutiprogrammi vea tõttu. Hea, et siis surmajuhtumeid ei olnud.
Ja mis saab siis, kui Boeing-747 pardaarvuti, mille pardal on nelisada reisijat, teeb erandi?
Just selliste valdkondade jaoks, mida võib nimetada "tõsiseks", on leiutatud kontrolli- ja testimismeetodid.
Mõnes väliskirjanduses on tuvastatud verifitseerimise ja testimise protsessid ning mõnel pool käsitletakse testimist kui üht verifitseerimismeetodit. Teostan seda tööd oma parima arusaamise kohaselt, käsitlen eraldi kontrollimise ja testimise protsesse. Ausalt öeldes puudutan ka tarkvara valideerimise teemat.
1. Definitsioonid
Eluring(LC) tarkvara. See termin tähistab ajavahemikku alates ideest luua teatud probleemide lahendamiseks vajalike funktsioonidega tarkvara kuni kasutamise täieliku lõpetamiseni. Uusim versioon see programm.
Artefaktid tarkvara elutsükkel (SW). See hõlmab mitmesuguseid tarkvara loomisega seotud teabematerjale. Need on lähteülesanne, arhitektuuri kirjeldus, lähtekood, kasutaja dokumentatsioon ja muud dokumendid. Materjalid, mida arenduse käigus kasutati, kuid mida ei salvestatud juurdepääsetaval kujul (nt kommentaarid koodis ja arendajate kuritarvitamine vestluses), ei ole artefaktid.
2. Kontrollimine
Kontrollimisel kontrollitakse osade tarkvaraarenduse ja -hoolduse käigus loodud artefaktide vastavust teistele, mis on varem loodud või lähteandmetena kasutatud, samuti nende artefaktide ja nende arendusprotsesside vastavust reeglitele ja standarditele. Eelkõige kontrollitakse verifitseerimisega vastavust standardite normidele, tarkvarale esitatavate nõuete (lähiülesannete) kirjeldusele, disainilahendustele, lähtekoodile, kasutajadokumentatsioonile ja tarkvara enda toimimisele. Lisaks kontrollitakse nõuete täitmist disainilahendused, dokumentatsioon ja kood koostatakse vastavalt tarkvara arendamisel antud riigis, tööstusharus ja organisatsioonis vastuvõetud normidele ja standarditele ning ka sellele, et nende loomisel tehti kõik standardites ette nähtud toimingud vajalikus järjekorras. Kontrollimisel tuvastatud vead ja defektid on lahknevused või vastuolud mitme loetletud dokumendi, dokumentide ja programmi tegeliku toimimise vahel, standardite normide ning tegelike tarkvara arendamise ja hoolduse protsesside vahel. Samas on omaette ülesanne otsustada, millist dokumenti parandada (võib-olla mõlemat).
Ülaltoodud on kontrolli ametlik määratlus. Tegelikult on kõik palju lihtsam: kontrollimine määrab kas me teeme programmi õigesti?.
Seega on peamised kontrollimeetodid uurimine ja kontroll.
programmi ekspertiisi kontrollimine
3. Kinnitamine
Valideerimisprotsess kontrollib tarkvara arendamise ja hooldamise käigus loodud või kasutatud artefaktide vastavust selle tarkvara kasutajate ja klientide vajadustele ja nõuetele, võttes arvesse seadusi. ainevaldkond ja tarkvara kasutamise konteksti piirangud.
Ja jällegi, paljude sõnade taga on väga lihtne ülesanne: valideerimise käigus kontrollitakse, kas need kasutajad/kliendid vajavad programmi teatud funktsionaalsust. Kas tarkvaratoode vastab klientide ja lõppkasutajate soovidele.
4. Testimine
Testimine on tarkvara vigade tuvastamise protsess, käivitades testiandmetel tarkvarasüsteemi koodi, kogudes konkreetses töökeskkonnas täitmise dünaamikast jõudlusnäitajaid, tuvastades mitmesuguseid ebaregulaarsetest ja ebatavalistest olukordadest põhjustatud vigu, defekte, tõrkeid ja vigu. või tarkvara ebatavaline katkestamine.
Ajalooliselt oli esimene testimise tüüp silumine.
Silumine on programmiobjekti kirjelduse kontrollimine programmeerimiskeeles, et tuvastada selles vigu ja seejärel need kõrvaldada. Vead tuvastab kompilaator nende süntaktilise kontrolli käigus. Pärast silumist viiakse läbi kontroll, et kontrollida koodi õigsust ja valideerimine, et kontrollida, kas toode vastab määratud nõuetele.
1. Staatilised katsemeetodid
Staatilisi meetodeid kasutatakse kontrollide läbiviimisel ja komponentide spetsifikatsioonide ülevaatamisel ilma neid rakendamata. Staatilise analüüsi tehnika seisneb programmide struktuuri metoodilises ülevaatamises ja analüüsis, samuti nende õigsuse tõestamises. Staatiline analüüs on suunatud kõigis elutsükli etappides välja töötatud dokumentide analüüsile ning seisneb lähtekoodi kontrollis ja programmi otspunktis juhtimises.
Tarkvarakontroll on programmi antud spetsifikatsioonidele vastavuse staatiline kontroll, mis viiakse läbi elutsükli protsesside projekteerimise tulemuste (dokumentatsioon, nõuded, spetsifikatsioonid, diagrammid või programmi lähtekood) erinevate esitusviiside analüüsimise teel. Ülevaatused ja kontrollid projekteerimistulemustest ja nende vastavusest kliendi nõuetele annavad rohkem kõrge kvaliteet loodud tarkvarasüsteeme.
2. Dünaamilised testimismeetodid
Musta kasti meetod. Selle meetodi kasutamisel kasutatakse teavet lahendatava probleemi kohta, kuid programmi struktuuri kohta pole midagi teada. Selle põhimõtte järgi testimise eesmärk on tuvastada ühe testiga maksimaalne vigade arv, kasutades väikest võimalike sisendandmete alamhulka.
Selle põhimõtte järgi testimise meetodeid kasutatakse programmis realiseeritud funktsioonide testimiseks, kontrollides funktsioonide tegeliku käitumise ja eeldatava käitumise lahknevust, võttes arvesse nõuete spetsifikatsioone. Selle testimise ettevalmistamise ajal koostatakse seisunditabelid, põhjuse-tagajärje graafikud 1 ja rikkepiirkonnad. Lisaks koostatakse testikomplektid, mis võtavad arvesse funktsioonide käitumist mõjutavaid parameetreid ja keskkonnatingimusi.
Valge kasti meetod.
See meetod võimaldab teil uurida programmi sisemist struktuuri ja kõigi programmis esinevate vigade tuvastamine on kontrollvoo marsruutide ammendava testimise kriteerium, mille hulgas on järgmised:
Operaatori katvuse kriteerium – koondtestide komplekt peab tagama, et iga operaator läbib vähemalt korra;
Haru testimise kriteerium (teise nimega otsuse katvus või ülemineku katvus) – koondtestide komplekt peab tagama, et iga haru või väljumine läbitakse vähemalt korra.
3. Funktsionaalne testimine
Funktsionaalse testimise eesmärk on tuvastada vastuolusid rakendatud funktsioonide tegeliku käitumise ja eeldatava käitumise vahel vastavalt spetsifikatsioonile ja esialgsetele nõuetele. Funktsionaalsed testid peaksid hõlmama kõiki rakendatud funktsioone, võttes arvesse kõige tõenäolisemaid veatüüpe. Üksikuid teste kombineerivad testistsenaariumid on keskendunud funktsionaalsete probleemide lahendamise kvaliteedi kontrollimisele.
Funktsionaalsed testid luuakse vastavalt funktsioonide spetsifikatsioonidele, projekteerimisinfole ja tekstile programmeerimiskeeles ning nende abil määratakse funktsionaalsete ülesannete teostamise terviklikkus ja vastavus esialgsetele nõuetele.
Funktsionaalse testimise ülesanded hõlmavad järgmist:
Funktsionaalsete nõuete kogumi kindlaksmääramine;
Väliste funktsioonide tuvastamine ja funktsioonide järjestuste konstrueerimine vastavalt nende kasutamisele tarkvarasüsteemis;
Iga funktsiooni sisendandmete kogumi tuvastamine ja nende muutumise piirkondade määramine;
Testimiskomplektide ja funktsioonide testimise stsenaariumide koostamine;
Kõigi funktsionaalsete nõuete tuvastamine ja esitamine, kasutades programmi testjuhtumeid ja testimisvigu ning keskkonnaga suhtlemisel.
Disainiinfost koostatud testid on seotud andmestruktuuride, algoritmide, üksikute komponentide vaheliste liidestega ning neid kasutatakse komponentide ja nende liideste testimiseks. Peamine eesmärk on tagada rakendatavate funktsioonide ja nendevaheliste liideste terviklikkus ja järjepidevus.
5. ANSI/IEEE veatüübid-7 29 -8 3
Error (error) - programmi olek, milles saadakse valed tulemused, mille põhjuseks on vead (viga) programmi väidetes või tehnoloogiline protsess selle areng, mis viib valesti tõlgendamiseni taustainfo, mis viib vale lahenduseni.
Programmi defekt (viga) - arendaja vigade tagajärg mis tahes arendusetapis, mis võib sisalduda originaal- või disainispetsifikatsioonides, programmikoodide tekstides, töödokumentatsioonis jne. Programmi täitmise ajal võidakse tuvastada defekt või rike.
Ebaõnnestumine (tõrge) on programmi kõrvalekaldumine tööst või programmi suutmatus täita nõuete ja piirangutega määratletud funktsioone, mida käsitletakse kui sündmust, mis aitab kaasa programmi üleminekule vigade tõttu mittetoimivasse olekusse. , selles peituvad defektid või tõrked töökeskkonnas. Ebaõnnestumine võib olla tingitud järgmistest põhjustest:
vigane spetsifikatsioon või välja jäetud nõue, mis tähendab, et spetsifikatsioon ei kajasta täpselt seda, mida kasutaja kavatses;
Spetsifikatsioon võib sisaldada nõuet, mida antud riist- ja tarkvara puhul ei ole võimalik täita;
Programmi kujundus võib sisaldada vigu (näiteks andmebaas on kujundatud ilma kaitsevahenditeta volitamata juurdepääsu eest, kuid kaitse on vajalik);
Programm võib olla vale, s.t. see täidab ebatavalist algoritmi või pole seda täielikult rakendatud.
Järeldus
Tarkvara kontrollimise ja testimisega seotud vene GOST-id on "kodanlike" standardite tõlked, nagu ISO 12207, ANSI/IEEE-729-83 ja teised (neid on palju). Probleem on selles, et need rahvusvahelised standardid käsitlevad testimise ja kontrollimise küsimusi erinevalt. Mitte öelda, et need oleksid üksteisega täiesti vastuolus, kuid need võivad tekitada hämmingut.
Kõik need standardid koostati eelmise sajandi 80ndatel USA kosmosetööstuse jaoks. Järgnevatel aastatel neid parandati ja avaldati uuesti, kuid lahkarvamused ja vastuolud dokumentides jäid alles.
Järeldus: verifitseerimis-, valideerimis- ja testimismeetodite struktuuri tuleks pidada tingimuslikuks.
Bibliograafia
1. Tasuta entsüklopeedia wikipedia.org
2. Kuljamin V.V. Tarkvara verifitseerimismeetodid M.: Süsteemiprogrammeerimise instituut, 2008
3. Lavrishcheva E., Petrukhin V. Loeng "Programmide ja süsteemide kontrollimise ja testimise meetodid": NOU "INTUIT" http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130
Majutatud saidil Allbest.ru
...Sarnased dokumendid
Tarkvara elutsükkel on pidev protsess, mis algab otsusest tarkvara loomise vajaduse kohta ja lõpeb selle täieliku tegevuse lõpetamisega. Riley, Lehmani ja Boehmi lähenemine tarkvara elutsükli määratlemisele.
abstraktne, lisatud 11.01.2009
Programmi arendustehnoloogia kontseptsioon. Tarkvaradisaini alus. Elutsükli mudelid, mis tekkisid ajalooliselt tarkvaradisaini teooria väljatöötamise käigus. Spiraalsed (spiraal), kaskaad- ja iteratiivsed mudelid.
esitlus, lisatud 11.05.2015
Tarkvara testimise arenduslugu ja tüübid. Paigaldamine, regressioon, konfigureerimine, integreerimine, lokaliseerimine, üksuse testimine. Meetodid arendatud rakenduse ühikutestimise keerukuse vähendamiseks.
kursusetöö, lisatud 16.12.2015
Tarkvara testimise probleemi lahendamatus. Testimise tüübid ja tasemed. Üles- ja allavoolu testimisstrateegiad. "Valge" ja "musta" kasti meetodid. Automatiseeritud ja käsitsi testimine. Areng läbi testimise.
kursusetöö, lisatud 22.03.2015
Nõuded tarkvara projekteerimise tehnoloogiale (SW). Tarkvara kogu elutsükli etappide koosseis ja kirjeldus. Tarkvara elutsükli mudelite klassifikatsioon, nende omadused. Tarkvaraarenduse metoodikad, äärmuslikud programmeerimistehnikad.
esitlus, lisatud 19.09.2016
Tarkvara testimise ajalugu, selle rakendamise peamised eesmärgid ja omadused. Testimise tüübid ja tüübid, selle automatiseerimise tasemed. Kasutamine ja uurimine vajalikke tehnoloogiaid. Täistsükkel kogu seiresüsteemi käitamine.
lõputöö, lisatud 03.05.2018
Valdkonna peamised rahvusvahelised standardid infotehnoloogiad. rahvusvaheline standard ISO/IEC 9126 Kvaliteet ja elutsükkel. Kvaliteedi sisemiste ja väliste tunnuste iseloomustus. Tarkvara funktsionaalsuse analüüs.
aruanne, lisatud 13.06.2017
Tarkvaratehnika eesmärgid ja eesmärgid. Tarkvara mõiste. Kuus põhimõtet tõhus kasutamine tarkvara. Tarkvara tüübid: kogu süsteemi hõlmav, võrgupõhine ja rakenduslik. Tarkvara loomise põhimõtted.
kursusetöö, lisatud 29.06.2010
Peamiste elutsükli mudelite üldised omadused: kaskaad, inkrementaalne, spiraal. Etapp tarkvara arendusprotsessi osana, mis on piiratud kindla ajaraamiga ja lõpeb konkreetse toote väljalaskmisega.
esitlus, lisatud 27.12.2013
Venemaa informatiseerimine. Turg tarkvaratööriistad. Informatiseerimise valdkonna standardimise, sertifitseerimise ja litsentsimise põhiülesanded. Insenerimeetodite ja tööriistade komplekt tarkvara loomiseks. Tarkvara elutsükkel.
Kontrollimine ja kinnitamine viitavad kontrolli- ja ülevaatusprotsessidele, mis kontrollivad tarkvara vastavust selle spetsifikatsioonidele ja kliendi nõuetele. Verifitseerimine ja valideerimine hõlmavad tarkvara kogu elutsüklit – need algavad nõuete analüüsi etapist ja lõpevad programmikoodi kontrollimisega valmis tarkvarasüsteemi testimise etapis.
Kontrollimine ja tõendamine ei ole sama asi, kuigi neid on lihtne segi ajada. Lühidalt võib nende erinevust määratleda järgmiselt:
Kontrollimine annab vastuse küsimusele, kas süsteem on õigesti projekteeritud;
Sertifitseerimine annab vastuse küsimusele, kas süsteem töötab õigesti.
Nende definitsioonide kohaselt kontrollib kontrollimine, kas tarkvara vastab süsteemi spetsifikatsioonidele, eelkõige funktsionaalsetele ja mittefunktsionaalsetele nõuetele. Sertifitseerimine on üldisem protsess. Valideerimisel tuleb veenduda, et tarkvaratoode vastab kliendi ootustele. Valideerimine viiakse läbi pärast kontrollimist, et teha kindlaks, kuidas süsteem vastab mitte ainult spetsifikatsioonile, vaid ka kliendi ootustele.
Nagu varem märgitud, on süsteeminõuete valideerimine tarkvaraarenduse algfaasis väga oluline. Sageli esineb nõuetes vigu ja puudusi; sellistel juhtudel ei vasta lõpptoode tõenäoliselt kliendi ootustele. Kuid loomulikult ei saa nõuete valideerimine paljastada kõiki nõuete spetsifikatsiooni probleeme. Mõnikord avastatakse lüngad ja vead nõuetes alles pärast süsteemi juurutamise lõppu.
Kontrollimise ja kinnitamise protsessid kasutavad süsteemide kontrollimiseks ja analüüsimiseks kahte peamist tehnikat.
1. Tarkvara kontroll. Süsteemi erinevate esituste, näiteks nõuete spetsifikatsiooni dokumentatsiooni, arhitektuursed diagrammid või programmi lähtekoodi analüüs ja kontrollimine. Kontrollimine toimub tarkvarasüsteemi arendusprotsessi kõikides etappides. Paralleelselt kontrolliga saab teostada programmide lähtekoodi ja nendega seotud dokumentide automaatset analüüsi. Kontrollimine ja automatiseeritud analüüs on staatilised kontrolli- ja valideerimismeetodid, kuna need ei vaja käivitatavat süsteemi.
2. Tarkvara testimine. Käivitatava koodi käivitamine koos testandmetega ning tarkvaratoote väljundi ja jõudluse uurimine, et kontrollida, kas süsteem töötab õigesti. Testimine on dünaamiline kontrollimise ja kinnitamise meetod, kuna seda rakendatakse töötavale süsteemile.
Joonisel fig. Joonis 20.1 näitab kontrolli ja testimise kohta tarkvara arendusprotsessis. Nooled näitavad arendusprotsessi etappe, kus neid meetodeid saab rakendada. Selle skeemi järgi saab ülevaatust läbi viia süsteemi arendusprotsessi kõikides etappides ja testimist – prototüübi või käivitatava programmi loomisel.
Kontrollimeetodid hõlmavad programmi kontrollimist, automaatset lähtekoodi analüüsi ja ametlikku kontrolli. Kuid staatiliste meetoditega saab kontrollida ainult programmide vastavust spetsifikatsioonile, neid ei saa kasutada süsteemi korrektse toimimise kontrollimiseks. Lisaks ei saa staatiliste meetoditega testida mittefunktsionaalseid omadusi, nagu jõudlus ja töökindlus. Seetõttu viiakse mittefunktsionaalsete omaduste hindamiseks läbi süsteemi testimine.
Riis. 20.1. Staatiline ja dünaamiline kontrollimine ja tõendamine
Vaatamata tarkvara kontrollimise laialdasele kasutamisele on testimine endiselt valdav kontrolli- ja sertifitseerimismeetod. Testimine on programmide töö kontrollimine reaalsete andmetega, mida töödeldakse süsteemi töötamise ajal. Defektide ja nõuetele mittevastavuse olemasolu programmis tuvastatakse väljundandmete uurimisel ja nende hulgast anomaalsete tuvastamisel. Testimine viiakse läbi süsteemi juurutamise faasis (kontrollimaks, kas süsteem vastab arendajate ootustele) ja pärast selle juurutamist.
Tarkvara arendusprotsessi erinevates etappides kasutatakse erinevat tüüpi testimist.
1. Defektide testimine viiakse läbi programmi ja selle spetsifikatsiooni vahelise ebakõlade tuvastamiseks, mis on tingitud programmide vigadest või defektidest. Sellised testid on mõeldud süsteemi vigade tuvastamiseks, mitte selle toimimise simuleerimiseks.
2. Statistiline testimine hindab programmide jõudlust ja töökindlust, samuti süsteemi tööd erinevates töörežiimides. Testid on loodud selleks, et jäljendada süsteemi tegelikku tööd tegelike sisendandmetega. Süsteemi töökindlust hinnatakse programmide töös märgitud tõrgete arvu järgi. Toimivust hinnatakse, mõõtes katseandmete töötlemisel kogu tööaega ja süsteemi reageerimisaega.
peamine eesmärk Kontrollimine ja kvalifitseerimine – tagamaks, et süsteem on "eesmärgile sobiv". Tarkvarasüsteemi sobivus ettenähtud otstarbele ei tähenda, et see peaks olema täiesti vigadeta. Pigem peaks süsteem mõistlikult hästi sobima eesmärkidega, milleks see mõeldud oli. Nõutud vastavuse kehtivus sõltub süsteemi eesmärgist, kasutajate ootustest ja tarkvaratoodete turutingimustest.
1. Tarkvara eesmärk. Vastavuse usaldusväärsuse tase sõltub sellest, kui kriitiline on arendatud tarkvara teatud kriteeriumide järgi. Näiteks peaks ohutuskriitiliste süsteemide usaldusväärsuse tase olema oluliselt kõrgem kui tarkvarasüsteemide prototüüpide puhul, mida arendatakse mõne uue idee demonstreerimiseks.
2. Kasutajate ootused. Kurbusega tuleb tõdeda, et praegu on enamikul kasutajatel tarkvarale madalad nõudmised. Kasutajad on programmide töötamise ajal tekkivate tõrgetega nii harjunud, et nad ei ole selle üle üllatunud. Nad on valmis taluma süsteemitõrkeid, kui selle kasutamisest saadav kasu kaalub üles puudused. Alates 1990. aastate algusest on aga kasutajate tolerantsus tarkvarasüsteemide rikete suhtes järk-järgult vähenenud. Viimasel ajal on ebausaldusväärsete süsteemide loomine muutunud peaaegu vastuvõetamatuks, mistõttu peavad tarkvaraarenduse ettevõtted järjest rohkem tähelepanu pöörama tarkvara kontrollimisele ja valideerimisele.
3. Tarkvara turu tingimused. Tarkvarasüsteemi hindamisel peab müüja teadma konkureerivaid süsteeme, hinda, mida ostja on nõus süsteemi eest maksma, ja selle süsteemi eeldatavat turuletuleku aega. Kui arendusettevõttel on mitu konkurenti, on vaja enne täieliku testimise ja silumise lõppu määrata süsteemi turuletuleku kuupäev, vastasel juhul võivad konkurendid turule tulla esimestena. Kui kliendid ei soovi tarkvara kõrge hinnaga ostma, võivad nad olla valmis taluma rohkem süsteemitõrkeid. Kontrollimise ja kvalifitseerimise protsessi kulude kindlaksmääramisel tuleb kõiki neid tegureid arvesse võtta.
Reeglina leitakse süsteemis vigu kontrollimise ja atesteerimise käigus. Vigade parandamiseks tehakse süsteemis muudatusi. See silumisprotsess tavaliselt integreeritud muude kontrollimis- ja atesteerimisprotsessidega. Testimine (või üldisemalt kontrollimine ja kinnitamine) ja silumine on aga erinevad protsessid, millel on erinevad eesmärgid.
1. Kontrollimine ja kinnitamine on tarkvarasüsteemi defektide tuvastamise protsess.
2. Silumine - defektide (vigade) lokaliseerimise ja nende parandamise protsess (joon. 20.2).
Riis. 20.2. Silumisprotsess
Programmide silumiseks pole lihtsaid meetodeid. Kogenud silujad leiavad vead, võrreldes testimise väljundmustreid testitavate süsteemide väljundiga. Vea leidmiseks on vaja teadmisi veatüüpide, väljundmustrite, programmeerimiskeele ja programmeerimisprotsessi kohta. Tarkvaraarenduse protsessi tundmine on väga oluline. Silujad on teadlikud kõige levinumatest programmeerimisvigadest (nt loenduri suurendamine). Samuti võtab see arvesse teatud programmeerimiskeeltele omaseid vigu, näiteks neid, mis on seotud osutite kasutamisega C-keeles.
Vigade leidmine programmikoodis ei ole alati lihtne protsess, kuna viga ei pruugi asuda programmikoodi selle punkti lähedal, kus krahh toimus. Vigade isoleerimiseks töötab silur välja täiendavaid tarkvarateste, mis aitavad tuvastada programmis vea allika. Võimalik, et peate programmi täitmist käsitsi jälgima.
Interaktiivsed silumistööriistad on osa keeletoe tööriistade komplektist, mis on integreeritud koodi koostamise süsteemiga. Need pakuvad spetsiaalset programmi täitmiskeskkonda, mille kaudu pääsete juurde identifikaatorite tabelile ja sealt muutujate väärtustele. Kasutajad juhivad sageli programmi täitmist samm-sammult, astudes järjest lauselt lauseni. Pärast iga avalduse täitmist kontrollitakse muutujate väärtusi ja tuvastatakse võimalikud vead.
Programmis leitud viga parandatakse, misjärel on vaja programmi uuesti kontrollida. Selleks saate programmi uuesti üle vaadata või korrata eelmist testi. Kordustestimist kasutatakse selleks, et programmis tehtud muudatused ei tooks süsteemi uusi vigu, sest praktikas suur osa "veaparandustest" kas ei jõua täielikult lõpule või lisab programmi uusi vigu.
Põhimõtteliselt on vaja pärast iga parandamist uuesti testida kõik testid, kuid praktikas on see lähenemine liiga kulukas. Seetõttu määratakse testimisprotsessi planeerimisel süsteemi osade vahelised sõltuvused ja iga osa jaoks määratakse testid. Seejärel on võimalik programmi elemente jälgida nende elementide jaoks valitud spetsiaalsete testjuhtumite (kontrollandmete) abil. Kui jälitustulemused on dokumenteeritud, saab muudetud programmielemendi ja sellest sõltuvate komponentide testimiseks kasutada ainult kogu testandmete alamhulka.
Kontrollimise ja tõendamise planeerimine
Kontrollimine ja kinnitamine on kulukas protsess. Suurte süsteemide, näiteks keeruliste mittefunktsionaalsete piirangutega reaalajas süsteemide puhul kulub pool süsteemiarenduse eelarvest kontrollimise ja valideerimise protsessile. Seetõttu on selle protsessi hoolika planeerimise vajadus ilmne.
Tarkvarasüsteemide arendamise osana kontrollimise ja valideerimise planeerimine peaks algama võimalikult varakult. Joonisel fig. Joonisel 20.3 on näidatud tarkvaraarenduse mudel, mis võtab arvesse testimise planeerimise protsessi. See on koht, kus planeerimine algab juba spetsifikatsiooni ja süsteemi kavandamise etapis. Seda mudelit nimetatakse mõnikord V-mudeliks (V nägemiseks pöörake joonist 20.3 90°). See diagramm näitab ka kontrollimise ja tõendamise protsessi jaotust mitmeks etapiks, kusjuures igas etapis tehakse vastavad testid.
Riis. 20.3. Testide planeerimine arenduse ja testimise käigus
Kontrollimise ja sertifitseerimise kavandamise käigus on vaja kindlaks määrata süsteemi kontrollimise staatiliste ja dünaamiliste meetodite vaheline seos, määrata tarkvara kontrollimise ja testimise standardid ja protseduurid, kinnitada tehnoloogiline kaart tarkvara ülevaated (vt jaotis 19.2) ja koostada tarkvara testimisplaan. See, kas ülevaatus või testimine on olulisem, sõltub arendatava süsteemi tüübist ja organisatsiooni kogemusest. Mida kriitilisem on süsteem, seda rohkem tuleks tähelepanu pöörata staatilistele kontrollimeetoditele.
Kontrollimise ja valideerimise kava keskendub pigem testimisprotsessi standarditele kui konkreetsete testide kirjeldamisele. See plaan ei ole ainult juhendamiseks, see on mõeldud peamiselt süsteemiarenduse ja testimise spetsialistidele. Plaan võimaldab tehnilistel töötajatel saada süsteemitestidest täielikku ülevaadet ja oma tööd selles kontekstis planeerida. Lisaks annab plaan infot juhtidele, kes vastutavad selle eest, et testimismeeskonnal oleks olemas kogu vajalik riist- ja tarkvara.
Katseplaan ei ole fikseeritud dokument. Seda tuleks regulaarselt üle vaadata, kuna testimine sõltub süsteemi juurutamise protsessist. Näiteks kui süsteemi mõne osa juurutamine ei ole lõpetatud, siis ei ole võimalik süsteemi kokkupanekut testida. Seetõttu tuleb plaan perioodiliselt üle vaadata, et testimispersonali saaks kasutada muudel töödel.
Valideerimise ja kontrollimise kaks mõistet aetakse sageli segi. Lisaks aetakse süsteeminõuete valideerimist sageli segi süsteemi valideerimisega. Soovitan seda probleemi uurida.
Artiklis käsitlesin kahte lähenemist objektide modelleerimisele: tervikuna ja struktuurina. Käesolevas artiklis vajame seda jaotust.
Oletame, et meil on kavandatud funktsionaalne objekt. Olgu see objekt meie poolt vaadeldav osana mõne teise funktsionaalse objekti konstruktsioonist. Olgu objekti konstruktsiooni kirjeldus selline, et see sisaldab objekti kirjeldust. Sellises kirjelduses on objektil kirjeldus kui tervik, st selle interaktsiooni liideseid teiste objektidega kirjeldatakse Objekti konstruktsiooni raames. Olgu antud objekti kui struktuuri kirjeldus. Olgu olemas infoobjekt, mis sisaldab nõudeid objekti kui ehitise kirjelduse kujundamisele. Olgu olemas järeldusreegleid sisaldav teadmiste kogum, mille alusel saadakse objekti kui struktuuri kirjeldusest objekti kui terviku kirjeldusest kirjeldus. Teadmiste kogum on see, mida disaineritele instituutides õpetatakse – palju, palju teadmisi. Need võimaldavad objekti kohta teadmiste põhjal kujundada selle struktuuri.
Niisiis, võite alustada. Võime väita, et kui objekti tervikuna on õigesti kirjeldatud, kui teadmiste kogum on õige ja kui järgiti järeldamisreegleid, siis on sellest tulenev objekti ehituse kirjeldus õige. See tähendab selle kirjelduse põhjal funktsionaalne objekt, mis vastab tegelikud tingimused operatsiooni. Millised ohud võivad tekkida:
1. Objekti kohta ebaõigete teadmiste kasutamine. Inimeste meelest olev Objekti mudel ei pruugi tegelikkusele vastata. Nad ei teadnud näiteks maavärinate tegelikku ohtu. Sellest tulenevalt võivad nõuded objektile olla valesti sõnastatud.
2. Objekti teadmiste puudulik arvestus – midagi jääb vahele, tehakse vigu. Näiteks teadsid nad tuultest, kuid unustasid seda mainida. See võib viia objektile esitatavate nõuete ebapiisavalt täieliku kirjelduseni.
3. Vale teadmistepagas. Meile õpetati massi prioriteetsust muude parameetrite ees, kuid selgus, et peame kiirust suurendama.
4. Järeldusreeglite vale rakendamine objekti kirjeldusele. Loogikavead, objekti projekteerimise nõuetes on midagi puudu, nõuete jälg on katki.
5. Süsteemi projekteerimise kohta tehtud järelduste mittetäielik kirje. Kõik võeti arvesse, kõik arvutati, aga unustati kirjutada.
6. Loodud süsteem ei vasta kirjeldusele.
On selge, et kõik projekti artefaktid ilmuvad reeglina valminud kujul alles projekti lõpuks ja isegi mitte alati. Aga kui eeldada, et arendus on juga, siis on riskid sellised, nagu ma kirjeldasin. Iga riski kontrollimine on konkreetne toiming, millele saab anda nime. Kui kedagi huvitab, võib proovida need tingimused välja mõelda ja välja öelda.
Mis on kinnitamine? Vene keeles on kontrollimine reeglite järgimise kontroll. Reeglid on dokumendi kujul. See tähendab, et peaks olema dokument koos dokumenteerimisnõuetega. Kui dokumentatsioon vastab selle dokumendi nõuetele, on see läbinud kontrolli.
Mis on valideerimine? Vene keeles on valideerimine järelduste õigsuse kontrollimine. See tähendab, et peaks olema teadmiste kogum, mis kirjeldab, kuidas saada objekti andmete põhjal disaini kirjeldust. Nende järelduste rakendamise õigsuse kontrollimine on valideerimine. Valideerimine on muuhulgas kirjelduse järjepidevuse, täielikkuse ja arusaadavuse kontrollimine.
Nõuete valideerimist aetakse sageli segi nendele nõuetele tugineva toote valideerimisega. Seda ei tasu teha.
