Patikra ( verification) ir Atestavimas ( validation)

Patikra ( verification) ir Atestavimas ( validation) • Užtikrina, kad programinės įrangos sistemos atitiktų vartotojų poreikius (Ką užtikrina patikra ir atestavimas?)

Tikslai • Pristatyti programinės įrangos patikrą (verification) ir atestavimą ( validation) ir aptarti jų skirtumus • Apibūdinti programų peržiūros procesus ir jų įtaką tikrinimui ir atestavimui ( T&A) • Paaiškinti statinę analizę kaip atestavimo metodą • Apibūdinti bedefektinį (Cleanroom) programinės įrangos kūrimo procesą

Nagrinėjamos temos • Patikros ir atestavimo planavimas • Programinės įrangos peržiūra • Automatizuota statinė analizė • Bedefektinis programinės įrangos kūrimas

Patikra ir Atestavimas • Patikra: • “Ar mes teisingai kuriame produktą?” • Programinė įranga turi atitikti specifikaciją • Atestavimas: • “Ar mes kuriame teisingą produktą?” • Programinė įranga turi daryti tai ko vartotojas reikalauja ( Į kokius klausimus atsako patikra ir atestavimas?)

P & A procesas • P&A proceso gyvavimo ciklas (life-cycle): P&A turi būti taikoma kiekvienoje programinės įrangos kūrimo proceso pakopoje. (Koks yra P&Agyvavimo ciklas?) • Yra du principiniai P&A tikslai: • Atskleisti sistemos klaidas • Įvertinti ar sistema yra naudotina darbinėje situacijoje ( Kokie principiniai P&A tikslai?)

Statinė ir dinaminė patikra • Programinės įrangos peržiūra ( inspection).Susijusi su statinės sistemos atvaizdavimo analize, atskleidžiant problemas (statinė patikra) • Gali būti papildyta su priemonėmis susijusiomis su dokumentų ir kodo analize • Programinės įrangos testavimas.Susijęs su produkto elgsenos sužadinimu ( bandymu) ir stebėjimu (dinaminė patikra) • Sistema yra bandoma su testiniais duomenimis ir yra stebima jos darbinė elgsena (Kuo skiriasi statinė ir dinaminė patikra?)

Statinė ir dinaminėpatikra Statinėpatikra Detalus projektas Reikalavimų specifikacija Aukšto lygio projektas Formali specifikacija Programa Dinaminėpatikra Prototipas

Programų testavimas • Gali parodyti klaidas bet ne jų nebuvimą • Sėkmingas testas – tas, kuris atskleidžia vieną ar daugiau klaidų • Vienintelis P&A metodas, taikomas nefunkciniams reikalavimams • Programų testavimas turi būti panaudotas apjungiant kartu su statine patikra, kad būtų pilna P& A apimtis ( Ką galima pasakyti apie programų testavimą?)

Testavimo tipai • Klaidų testavimas • Testavimas skirtas sistemos klaidų atskleidimui. • Sėkmingas testas yra tas , kuris išryškina klaidas • Statistinis testavimas • Testavimas pagrįstas atsitiktiniu įvedamų duomenų generavimu. Naudojama patikimumo įvertinimui. ( Kokie yra testavimo tipai?)

P& A paskirtis • Patikra ir atestavimas turi parodyti, kad ši programinė įranga yra tinkama skirtam tikslui • Tai nereiškia kad ši programa bus visai be klaidų • Bet ji bus pakankamai gera numatomam naudojimui, ir naudojant bus pasiektas reikiamas pasitikėjimo lygis ( Kokia P&A paskirtis?)

Pasitikėjimas P & A ( confidence) • Priklauso nuo sistemos tikslų, vartotojo lūkesčių ir marketingo aplinkos • Programines įrangos funkcijos • Pasitikėjimo lygis priklauso nuo to, kiek programinė įranga yra kritinė (svarbi) organizacijai. • Vartojo lūkesčiai • Vartotojai gali būti nereiklūs kai kurioms programinės įrangos rūšims. • Marketingo aplinka • Ankstyvas produkto pateikimas rinkai gali būti svarbesnis nei tolesnė defektų paieška programoje. ( Nuo ko priklauso pasitikėjimas P&A ?)

Testavimas ir derinimas • Defektų testavimas ir derinimas yra skirtingi procesai • Patikra ir atestavimas yra skirtas klaidos buvimo programoje nustatymui • Derinimas yra skirtas defektų vietos nustatymui ir ištaisymui • Derinimo metu formuojamos hipotezės apie programos veikimą, po to, testuojant šias hipotezes, randamas sistemos defektas. ( Kuo skiriasi testavimas ir derinimas?)

Derinimo procesas Testavimo rezultatai Testavimo kriterijai Specifikacija Klaidos vietos nustatymas Klaidų taisymo projektavimas Klaidos ištaisymas Programos testavimas iš naujo ( Kokie veiksmai vykdomi derinimo proceso metu?)

Nagrinėjamos temos • Patikros ir atestavimo planavimas • Programinės įrangos peržiūra • Automatizuota statinė analizė • Bedefektinis programinės įrangos kūrimas

P & A planavimas • Atidus planavimas yra būtinas norint gauti geriausią rezultatą iš testavimo ir peržiūros procesų. • Planavimas turi prasidėti anksti kūrimo procese. • Planavimas turi nustatyti pusiausvyrą tarp statinio tikrinimo ir testavimo. • Testo planavimas labiau nustato testavimo standartus nei apibūdina produkto testus. ( Kas tvirtinama apie P & A planavimą?)

Kūrimo ir testavimo modelis Reikalavimų specifikacija Sistemos specifikacija Sistemos projektas Detalus projektas Sistemos integracijos tikrinimo planas Posistemių integracijos tikrinimo planas Modulių ir vienetų kodavimas ir testavimas Priėmimo testo planas Sistemos integracijos testas Posistemių integracijos testas Naudojimas Priėmimo testas (Kaip grafiškai atvaizduojamas kūrimo ir testavimo modelis?)

Programinės įrangos testo plano struktūra • Testavimo procesas • Reikalavimų sekamumas (traceability) • Testuojami vienetai • Testavimo tvarkaraštis • Testų užrašymo procedūros • Techninės ir programinės įrangos reikalavimai • Apribojimai (Kokia testo plano struktūra?)

Nagrinėjamos temos • Tikrinimo ir atestavimo planavimas • Programinės įrangos peržiūra • Automatizuota statinė analizė • Bedefektinis programinės įrangos kūrimas

Programinės įrangos peržiūra • Siejasi su žmonėmis, nagrinėjančiais išeities tekstus, siekiant atrasti anomalijas ir klaidas. • Nereikalauja vykdyti sistemos, todėl gali būti naudojama prieš realizaciją. • Gali būti taikoma bet kokiam sistemos atvaizdavimui (reikalavimams, projektui, testų duomenims ir t.t.). • Tai labai efektyvi metodika klaidų suradimui. ( Kas būdinga programinės įrangos peržiūrai?)

Peržiūros privalumai • Daug defektų gali būti atrasta per vieną peržiūrą. Testuojant vienas defektas gali paslėpti kitą, taigi reikalingi keli vykdymai. • Pakartotinai panaudojamos srities ir programavimo žinios, kai taisytojai supažindinami su dažniausiai pasitaikančių klaidų tipais. (Kokie peržiūros privalumai?)

Peržiūra ir testavimas • Peržiūra ir testavimas yra vienas kitą papildantys ir neprieštaraujantys tikrinimo metodai. • Abu turėtų būti naudojami P&A proceso metu • Peržiūra gali išsiaiškinti atitikimą specifikacijai, bet ne atitikimą realiems užsakovų reikalavimams. • Peržiūra negali patikrinti nefunkcinių charakteristikų (tokių kaip našumas, tinkamumas naudoti ir t.t.) ( Koks santykis tarp peržiūros ir testavimo?)

Programų peržiūra • Formalizuotas metodas dokumentų peržiūrai • Skirtas defektų aptikimui (ne taisymui) • Defektas gali būti loginės klaidos, kodo anomalijos, kurios gali signalizuoti apie klaidingą būseną (pvz., neinicializuotą kintamąjį) arba neatitikimą standartams (Kas tai yra programų peržiūra?)

Peržiūros išankstinės sąlygos • Turi būti prieinama tiksli specifikacija • Komandos nariai turi būti susipažinę su organizacijos standartais • Turi būti prieinamas sintaksiškai teisingas kodas • Klaidų tikrinimo sąrašas turi būti paruoštas • Vadovybė turi susitaikyti su tuo, kad peržiūra padidina kaštus ankstyvame programinės įrangos kūrimo etape • Vadovybė neturėtų naudoti peržiūros personalui įvertinti (Kokios išanktinės sąlygos keliamos peržiūrai?)

Peržiūros procesas Planavimas Tolimesnis efektyvumo didinimas Apžvalga Individualus pasiruošimas Įvertinimas Peržiūros pasitarimas (Kokie veiksmai vykdomi peržiūros proceso metu?)

Peržiūros procedūra • Sistemos apžvalga pristatoma peržiūros komandai • Kodai ir kita susijusi dokumentacija yra paskirstoma peržiūros komandai iš anksto • Įvyksta tikrinimas, ir atrastos klaidos yra pažymimos • Padaromi pakeitimai, kad pataisyti atrastas klaidas • Pakartotina peržiūra gali būti reikalinga arba ne (Kas būdinga peržiūros procedūrai?)

Peržiūros komandos • Sudaromos iš mažiausiai 4 narių • Tikrinamo kodo autorius • Peržiūrėtojas – tas, kuris randa klaidas, trūkumus ar nesuderinamumus • Pranešėjas – tas, kuris skaito kodą komandai • Pirmininkas – tas, kuris vadovauja pasitarimui ir žymi atrastas klaidas • Kiti vaidmenys – raštininkas ir vadovas ( Kas būdinga peržiūros komandai?)

Peržiūros tikrinimų klaidų sąrašas • Dažniausiai pasitaikančių klaidų sąrašas turėtų būti naudojamas viso tikrinimo metu • Klaidų tikrinimo sąrašas priklauso nuo programavimo kalbos • Kuo silpnesnis tipų tikrinimas, tuo didesnis klaidų tikrinimo sąrašas • Pvz: inicializacija, konstantų pavadinimai, ciklų pabaigos, masyvų ribos ir t.t. (Kas būdinga peržiūros metu tikrinamų klaidų sąrašui?)

(Kas tikrinama peržiūros metu?) Tikrinimai peržiūros metu Klaidų klasė Tikrinimai peržiūros metu Duomenų klaidos Ar visi programų kintamieji aprašyti prieš panaudojimą? Ar visos konstantos turi vardus? Ar apatinė masyvo riba turėtų būti 0,1 ar dar kita? Ar viršutinė masyvo riba turėtų būti lygi masyvo dydžiui ar –1? Kontrolės klaidos Ar kiekvienam sąlyginiam sakiniui yra teisinga sąlyga? Ar kiekvienas ciklas turi pabaigą? Ar sudėtiniai sakiniai yra teisingai apskliausti? Ar variantų sakiniuose visi variantai numatyti? Įvedimo/išvedimo klaidos Ar visi įvedimo kintamieji panaudoti? Ar visi išvedimo kintamieji įgauna reikšmes prieš juos panaudojant? Sąsajos klaidos Ar visos funkcijos ir procedūros turi teisingą parametrų skaičių? Ar sutampa formalūs ir realūs parametrai? Ar parametrai išdėstyti teisinga tvarka? Jei komponentai naudojasi ta pačia atmintimi, ar jie turi tą patį atminties struktūros modelį? Saugojimo valdymo klaidos Jeigu struktūra su nuoroda į ją yra pakeista, ar visos nuorodos yra pakeistos teisingai? Jei dinaminis saugojimas yra naudojamas, ar teisingai nurodyta vieta? Ar atmintis yra atlaisvinama, kai baigiama ja naudotis? Išimčių valdymo klaidos Ar yra numatytos visos klaidų atsiradimo sąlygos?

Peržiūros tempas • 500 sakinių per valandą apžvalgos metu • 125 kodo sakiniai per valandą per individualų pasiruošimą • 90-125 sakiniai per valandą gali būti peržiūrėti klaidų klasės požiūriu • Dėl to tikrinimas yra brangus procesas • 500 kodo eilučių patikrinimui reikia 40 žmogaus darbo valandų (Koks peržiūros tempas?)

Automatizuota statinė analizė • Statiniai analizatoriai – programinės įrangos įrankiai išeities teksto apdorojimui • Jie išnagrinėja programos tekstą, bando surasti potencialiai klaidingas sąlygas ir atkreipti į jas P&A komandos dėmesį • Labai efektyvi pagalba peržiūrai. Priedas prie peržiūros, bet ne jos pakaitalas (Kokia statinių analizatorių paskirtis?)

Klaidų klasės Statinės analizės tikrinimai Duomenų klaidos Kintamieji panaudoti prieš inicializaciją. Kintamieji aprašyti bet niekada nepanaudoti. Kintamieji aprašyti dukart, bet nepanaudoti tarp aprašymų. Galimi masyvo ribų pažeidimai. Nedeklaruoti kintamieji Kontrolės klaidos Nepasiekimas kodas. Nesąlyginės šakos į ciklus Įvedimo/išvedimo klaidos Kintamieji išvedami dukart be tarpinio priskyrimo Sąsajos klaidos Parametrų tipų nesutapimai. Parametrų kiekio nesutapimai. Funkcijų rezultatų nepanaudojimas. Funkcijos ir proceūros be kreipinių. Saugojimo valdymo klaidos Žymekliai be ryšio. Žymeklių aritmetika. Tikrinimai statinės analizės metu (Kokie tikrinimai atliekami statinės analizės metu?)

Statinės analizės etapai • Valdymo srauto analizė. Tikrina ciklus su daug išėjimo ir įėjimo taškų, randa nepasiekiamą kodą ir t.t. • Duomenų naudojimo analizė. Randa neaprašytus kintamuosius, kintamuosius aprašytus dukart be tarpinio priskyrimo, kintamuosius, kurie aprašyti bet niekada nepanaudoti ir t.t. • Sąsajos(interfeiso) analizė. Tikrina paprogramių ir procedūrų aprašymų neprieštaringumą bei jų panaudojimą

Statinės analizės etapai • Infomacijos srauto analizė. Nustato išeities (output) reikšmių priklausomybes. Neieško anomalijų, bet išryškina informaciją kodo peržiūrai ar analizei • Kelių analizė. Parenka programos vykdymo kelią ir nurodo operatorius, vykdomus šiuo keliu. Be to, labai naudinga apžvalgos metu • Abu šie etapai dirba su labai daug informacijos. Jie turi būti naudojami apdairiai (Kokie statinės analizės etapai?)

138% more lint_ex.c #include <stdio.h> printarray (Anarray) int Anarray; { printf(“%d”,Anarray); } main () { int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; } 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored LINT statinė analizė

Statinės analizės naudojimas • Ypač vertinga, kai naudojama tokia kalba, kaip C, turinti silpną tipavimą (typing), ko pasekoje kompiliatorius neaptinka daug klaidų • Mažiau rentabili kalboms kaip Java, turinčioms stiprų tipų tikrinimą, todėl galinčioms rasti daug klaidų kompiliavimo metu (Ką galima pasakyti apie statinės analizės naudojimą?)

Bedefektinis (cleanroom) programinės įrangos kūrimas • Pavadinimas kilo iš ‘cleanroom’ procesų puslaidininkių gamyboje. Naudojama defektų išvengimo, bet ne defektų pašalinimo filosofija • Toks programinės įrangos kūrimo procesas remiasi: • palaipsniniu kūrimu • formalia specifikacija • statiniu tikrinimu, naudojant korektiškumo argumentus • statistiniu testavimu, nustatant programos patikimumą (Kuo remiasi bedefektinis programinės įrangos kūrimas?)

Bedefektinis procesas Formalus sistemos specifikavimas Klaidų perdarymas PĮ kūrimo pakopų apibrėžimas Struktūrinės programos konstravimas Formalus kodo patikrinimas Kūrimo pakopų integravimas Operacinio profilio kūrimas Statistinių testų projektavimas Integruotos sistemos testavimas (Kaip grafiškai atvaizduojamas bedefektinis procesas?)

Bedefektinio proceso charakteristikos • Formali specifikacija, naudojanti būsenų perėjimo modelį • Palaipsninis kūrimas • Struktūrinis programavimas - naudojamos ribotos valdymo ir abstrakčios konstrukcijos • Statinis tikrinimas, naudojantis griežtą peržiūrą • Statistinis sistemos testavimas (Kas būdinga bedefektiniam procesui?)

Palaipsninis kūrimas Įšaldyta specifikacija Reikalavimų nustatymas Formali specifikacija Programinės įrangos pristatymas PĮ kūrimo pakopos formavimas Užklausa apie reikalavimų pasikeitimą (Kas būdinga palaipsniniui kūrimui bedefektiniam procese?)

Formali specifikacija ir peržiūra • Sistemos specifikacija yra būsenų modelis, o peržiūros proceso metu tikrinama, ar programa atitinka šį modelį • Programavimo metodas apibrėžtas taip, kad atitikimas tarp modelio ir sistemos būtų aiškus • Matematiniai argumentai (ne įrodymai) naudojami, norint padidinti pasitikėjimą peržiūros procesu (Koks santykis tarp peržiūros ir formalių specifikacijų bedefektinio proceso metu?)

Bedefektinio proceso grupės • Specifikacijų grupė. Atsakinga už sistemos specifikacijos kūrimą ir palaikymą • Kūrimo grupė. Atsakinga už programinės įrangos kūrimą ir tikrinimą. Programinė įranga NĖRA vykdoma ir net nekompiliuojama šio proceso metu • Sertifikacijos grupė. Atsakinga už programinės įrangos statistinių testų kūrimą. Naudojamas patikimumo augimo modelis, norint nustatyti, kada patikimumas yra tinkamas (Kokios darbo grupės išskiriamos bedefektinio proceso metu?)

Bedefektinio proceso vertinimas • IBM rezultatai buvo labai įspūdingi tik su keletu klaidų pristatytose sistemose • Nepriklausomas įvertinimas rodo, kad procesas yra nedaug brangesnis nei kiti metodai • Mažiau klaidų negu ‘tradiciniame’ kūrimo procese • Nevisai aišku, kaip šį metodą panaudoti aplinkoje su mažiau motyvuotais arba žemesnės kvalifikacijos inžinieriais (Kaip vertinamas bedefektinis procesas?)

Esminiai aspektai • Patikra ir atestavimas nėra tas pats. Patikra parodo atitikimą specifikacijai; Atestacija parodo, kad programa atitinka užsakovo norus • Testo planas turi būti pagrindas testavimo procesui • Statinio tikrinimo metodai apima patikrinimą ir programos analizę, norint surasti defektus

Esminiai aspektai • Programos peržiūra yra labai efektyvi klaidų suradimui • Peržiūrimas programos kodas yra tikrinamas mažų grupių, norint surasti programinės įrangos defektus • Statinės analizės priemonės gali surasti programos anomalijas, kurios gali nurodyti klaidas, esančias kode • Bedefektinis procesas priklauso nuo palaipsninio kūrimo, statinio tikrinimo ir statistinio testavimo

Patikra ( verification) ir Atestavimas ( validation)