20. Verifikimi dhe kualifikimi software
Verifikimi dhe vlefshmëria i referohet proceseve të verifikimit dhe rishikimit që verifikojnë që softueri është në përputhje me specifikimet e tij dhe kërkesat e klientit. Verifikimi dhe kualifikimi mbulon të plotë cikli i jetes Software - ato fillojnë në fazën e analizës së kërkesave dhe përfundojnë me verifikimin e kodit të programit në fazën e testimit të sistemit të softuerit të përfunduar.
Verifikimi dhe vërtetimi nuk janë e njëjta gjë, megjithëse është e lehtë t'i ngatërroni ato. Shkurtimisht, ndryshimi midis tyre mund të përcaktohet si më poshtë:
Verifikimi i përgjigjet pyetjes nëse sistemi është projektuar siç duhet;
Certifikimi i përgjigjet pyetjes nëse sistemi funksionon si duhet.
Sipas këtyre përkufizimeve, verifikimi kontrollon nëse softueri është në përputhje me specifikimet e sistemit, në veçanti kërkesat funksionale dhe jofunksionale. Certifikimi - më shumë procesi i përgjithshëm. Gjatë vërtetimit, duhet të siguroheni që produkti softuer përmbush pritshmëritë e klientit. Verifikimi kryhet pas verifikimit për të përcaktuar se si sistemi përmbush jo vetëm specifikimet, por edhe pritshmëritë e klientit.
Siç u përmend më herët, vërtetimi i kërkesave të sistemit është shumë i rëndësishëm në fazat e hershme të zhvillimit të softuerit. Shpesh ka gabime dhe lëshime në kërkesat; në raste të tilla, produkti përfundimtar ndoshta nuk do të përmbushë pritshmëritë e klientit. Por, sigurisht, vërtetimi i kërkesave nuk mund të zbulojë të gjitha problemet në specifikimin e kërkesave. Ndonjëherë boshllëqet dhe gabimet në kërkesat zbulohen vetëm pasi të përfundojë implementimi i sistemit.
Proceset e verifikimit dhe të vërtetimit përdorin dy teknika kryesore për kontrollimin dhe analizimin e sistemeve.
1. Inspektimi i softuerit. Analiza dhe verifikimi i paraqitjeve të ndryshme të sistemit, si dokumentacioni i specifikimeve të kërkesave, diagramet arkitekturore ose kodi burimor i programit. Inspektimi kryhet në të gjitha fazat e procesit të zhvillimit të sistemit softuerik. Paralelisht me inspektimin, mund të kryhet analiza automatike e kodit burimor të programeve dhe dokumenteve përkatëse. Inspektimi dhe analiza e automatizuar janë metoda statike të verifikimit dhe vërtetimit sepse nuk kërkojnë një sistem të ekzekutueshëm.
2. Testimi i softuerit. Ekzekutimi i kodit të ekzekutueshëm me të dhënat e provës dhe ekzaminimi i prodhimit dhe performancës produkt software për të kontrolluar funksionimin e duhur të sistemit. Testimi është një metodë dinamike verifikimi dhe vlefshmërie sepse aplikohet në sistemin që funksionon.
Në fig. Figura 20.1 tregon vendin e inspektimit dhe testimit në procesin e zhvillimit të softuerit. Shigjetat tregojnë fazat në procesin e zhvillimit ku mund të zbatohen këto metoda. Sipas kësaj skeme, inspektimi mund të kryhet në të gjitha fazat e procesit të zhvillimit të sistemit, dhe testimi - kur krijohet një prototip ose program i ekzekutueshëm.
Metodat e inspektimit përfshijnë: inspektimin e programit, analizën automatike të kodit burimor dhe verifikimin formal. Por metodat statike mund të kontrollojnë vetëm konformitetin e programeve me specifikimet; ato nuk mund të përdoren për të kontrolluar funksionimin e saktë të sistemit. Përveç kësaj, karakteristikat jofunksionale si performanca dhe besueshmëria nuk mund të testohen me metoda statike. Prandaj, për të vlerësuar karakteristikat jofunksionale, kryhet testimi i sistemit.
Oriz. 20.1. Verifikimi dhe vërtetimi statik dhe dinamik
Pavarësisht përdorimit të gjerë të inspektimit të softuerit, testimi është ende metoda mbizotëruese e verifikimit dhe certifikimit. Testimi është një verifikim i funksionimit të programeve me të dhëna të ngjashme me ato reale, të cilat do të përpunohen gjatë funksionimit të sistemit. Prania në program e defekteve dhe mospërputhjeve me kërkesat zbulohet duke ekzaminuar të dhënat dalëse dhe duke identifikuar ato anormale midis tyre. Testimi kryhet gjatë fazës së zbatimit të sistemit (për të verifikuar nëse sistemi përmbush pritshmëritë e zhvilluesve) dhe pasi të ketë përfunduar zbatimi i tij.
Në faza të ndryshme të procesit të zhvillimit të softuerit, lloje te ndryshme duke testuar.
1. Testimi i defekteve kryhet për të zbuluar mospërputhjet midis programit dhe specifikimeve të tij, të cilat janë për shkak të gabimeve ose defekteve në programe. Teste të tilla janë krijuar për të zbuluar gabimet në sistem dhe jo për të simuluar funksionimin e tij.
2. Testimi Statistikor vlerëson performancën dhe besueshmërinë e programeve, si dhe funksionimin e sistemit në mënyra të ndryshme funksionimi. Testet janë krijuar për të imituar funksionimin aktual të sistemit me të dhëna hyrëse reale. Besueshmëria e sistemit vlerësohet nga numri i dështimeve të shënuara në punën e programeve. Performanca vlerësohet duke matur kohën totale të funksionimit dhe kohën e përgjigjes së sistemit gjatë përpunimit të të dhënave të testit.
Qëllimi kryesor i verifikimit dhe kualifikimit është të sigurohet që sistemi të jetë "i përshtatshëm për qëllimin". Përshtatshmëria e një sistemi softuerik për qëllimin e tij të synuar nuk nënkupton që ai duhet të jetë absolutisht pa gabime. Përkundrazi, sistemi duhet të jetë mjaft i përshtatshëm për qëllimet për të cilat është menduar. E detyrueshme vlefshmëria e pajtueshmërisë varet nga qëllimi i sistemit, pritjet e përdoruesve dhe kushtet e tregut për produktet softuerike.
1. Qëllimi i softuerit. Niveli i besueshmërisë së pajtueshmërisë varet nga sa kritik është softueri i zhvilluar sipas kritereve të caktuara. Për shembull, niveli i besimit për sistemet kritike për sigurinë duhet të jetë dukshëm më i lartë se i njëjti nivel besimi për prototipet. sistemet softuerike duke u zhvilluar për të demonstruar disa ide të reja.
2. Pritjet e përdoruesve. Duhet të theksohet me pikëllim se aktualisht, shumica e përdoruesve kanë kërkesa të ulëta për softuer. Përdoruesit janë mësuar aq shumë me dështimet që ndodhin gjatë ekzekutimit të programeve, saqë nuk habiten nga kjo. Ata janë të gatshëm të tolerojnë dështimet e sistemit nëse përfitimet e përdorimit të tij tejkalojnë të metat. Megjithatë, që nga fillimi i viteve 1990, toleranca e përdoruesve për dështimet në sistemet softuerike ka ardhur gradualisht në rënie. Kohët e fundit, krijimi i sistemeve jo të besueshme është bërë pothuajse i papranueshëm, kështu që kompanitë e zhvillimit të softuerit duhet t'i kushtojnë gjithnjë e më shumë vëmendje verifikimit dhe vërtetimit të softuerit.
3. Kushtet e tregut të softuerit. Kur vlerëson një sistem softuerësh, shitësi duhet të njohë sistemet konkurruese, çmimin që blerësi është i gatshëm të paguajë për sistemin dhe kohën e pritur për në treg për atë sistem. Nëse kompania e zhvillimit ka disa konkurrentë, është e nevojshme të përcaktohet data e hyrjes së sistemit në treg përpara përfundimit të testimit dhe korrigjimit të plotë, përndryshe konkurrentët mund të jenë të parët që do të hyjnë në treg. Nëse klientët nuk janë të gatshëm të blejnë softuer me një çmim të lartë, ata mund të jenë të gatshëm të tolerojnë më shumë dështime të sistemit. Gjatë përcaktimit të kostove të procesit të verifikimit dhe kualifikimit, duhet të merren parasysh të gjithë këta faktorë.
Si rregull, gabimet gjenden në sistem gjatë verifikimit dhe vërtetimit. Ndryshimet bëhen në sistem për të korrigjuar gabimet. Kjo procesi i korrigjimit zakonisht integrohen me procese të tjera verifikimi dhe vërtetimi. Sidoqoftë, testimi (ose më në përgjithësi, verifikimi dhe vlefshmëria) dhe korrigjimi janë procese të ndryshme që kanë qëllime të ndryshme.
1. Verifikimi dhe vërtetimi është procesi i zbulimit të defekteve në një sistem softuerik.
2. Debugging - procesi i lokalizimit të defekteve (gabimeve) dhe rregullimit të tyre (Fig. 20.2).
Oriz. 20.2. Procesi i korrigjimit
Nuk ka metoda të thjeshta për korrigjimin e programeve. Korrigjuesit me përvojë gjejnë gabime duke krahasuar modelet e daljes së provës me daljen e sistemeve nën provë. Për të gjetur një gabim kërkon njohuri për llojet e gabimeve, modelet e daljes, gjuhën e programimit dhe procesin e programimit. Njohja e procesit të zhvillimit të softuerit është shumë e rëndësishme. Korrigjuesit janë të vetëdijshëm për gabimet më të zakonshme të programimit (siç është rritja e një numëruesi). Ai gjithashtu merr parasysh gabimet që janë tipike për disa gjuhë programimi, për shembull, ato që lidhen me përdorimin e treguesve në gjuhën C.
Gjetja e gabimeve në kodin e programit nuk është gjithmonë një proces i thjeshtë, sepse defekti nuk është domosdoshmërisht i vendosur afër pikës në kodin e programit ku ndodhi përplasja. Për të izoluar gabimet, korrigjuesi zhvillon teste shtesë të softuerit që ndihmojnë në identifikimin e burimit të gabimit në program. Mund t'ju duhet të gjurmoni manualisht ekzekutimin e programit.
Mjetet ndërvepruese të korrigjimit janë pjesë e një grupi mjetesh mbështetëse gjuhësore që janë të integruara me sistemin e përpilimit të kodit. Ato ofrojnë një mjedis të veçantë të ekzekutimit të programit përmes të cilit mund të qaseni në tabelën e identifikuesve dhe prej andej në vlerat e variablave. Përdoruesit shpesh kontrollojnë ekzekutimin e një programi në një mënyrë hap pas hapi, duke kaluar nga deklarata në deklaratë në rend. Pas ekzekutimit të çdo deklarate, kontrollohen vlerat e variablave dhe identifikohen gabimet e mundshme.
Gabimi i gjetur në program korrigjohet, pas së cilës është e nevojshme të kontrolloni përsëri programin. Për ta bërë këtë, mund të riinspektoni programin ose të përsërisni testin e mëparshëm. Ritestimi përdoret për t'u siguruar që ndryshimet e bëra në program nuk sjellin gabime të reja në sistem, sepse në praktikë një përqindje e lartë e "rregullimeve të gabimeve" ose nuk plotësohen plotësisht ose futin gabime të reja në program.
Në parim, është e nevojshme të kryhen përsëri të gjitha testet gjatë ritestimit pas çdo rregullimi, por në praktikë, kjo qasje është shumë e shtrenjtë. Prandaj, gjatë planifikimit të procesit të testimit, përcaktohen varësitë midis pjesëve të sistemit dhe caktohen teste për secilën pjesë. Më pas është e mundur të gjurmohen elementët e programit duke përdorur raste të veçanta testimi (të dhëna kontrolli) të zgjedhura për këto elemente. Nëse rezultatet e gjurmës dokumentohen, atëherë vetëm një nëngrup i grupit total të të dhënave të testimit mund të përdoret për të testuar elementin e ndryshuar të programit dhe komponentët e tij të varur.
Qëllimi i këtij kursi është të ofrojë një pamje gjithëpërfshirëse të procesit të verifikimit të softuerit. Objekti i diskutimit janë qasjet dhe metodat e ndryshme të përdorura në fushën e verifikimit dhe, në veçanti, testimit të softuerit. Supozohet se softueri që po zhvillohet është pjesë e një më të madhe sistemi i përbashkët. Një sistem i tillë përfshin komponentë harduer, informacion dhe organizativ (përdorues njerëzor, operator njerëzor, etj.) të zhvilluara, ndoshta, nga ekipe të ndryshme. Prandaj, nevojiten dokumente zhvillimi që përcaktojnë kërkesat për komponentë të ndryshëm të sistemit dhe rregullat për ndërveprimin e tyre. Për më tepër, supozohet se dështimet e sistemit mund të çojnë në pasoja të një ashpërsie ose një tjetër, prandaj, gjatë zhvillimit të softuerit, përpjekjet e shpenzuara për identifikimin e defekteve të fshehura janë të nevojshme dhe të justifikuara. Para së gjithash, ka të bëjë me mjetet dhe procedurat e verifikimit të softuerit. Kursi përfshin një sërë ushtrimesh praktike që ilustrojnë teknikat dhe metodat e verifikimit të softuerit në mjedisin Microsoft Visual Studio 2005 Team Edition for Software Testers duke përdorur një sistem të thjeshtë si shembull. Ky botim është pjesë e Bibliotekës së Kurrikulës, e cila po zhvillohet nga Programi i Bashkëpunimit Akademik MSDN Academic Alliance (MSDN AA).
Teksti më poshtë nxirret automatikisht nga dokumenti origjinal PDF dhe është menduar vetëm për qëllime paraprake.
Imazhet (fotografitë, formulat, grafikët) mungojnë.
Oriz. 7 Testimi, verifikimi dhe vërtetimi Verifikimi i softuerit është një koncept më i përgjithshëm sesa testimi. Qëllimi i verifikimit është të arrihet siguria që objekti që verifikohet (kërkesat ose kodi i programit) përputhet me kërkesat, zbatohet pa funksione të padëshiruara dhe plotëson specifikimet dhe standardet e projektimit. Procesi i verifikimit përfshin inspektimet, testimin e kodit, analizën e rezultateve të testit, gjenerimin dhe analizën e raporteve të problemeve. Kështu, përgjithësisht pranohet se procesi i testimit është pjesë integrale e procesit të verifikimit, i njëjti supozim bëhet edhe në këtë kurs trajnimi. Validimi i një sistemi softuerësh është një proces qëllimi i të cilit është të vërtetojë se, si rezultat i zhvillimit të sistemit, ne kemi arritur qëllimet që kemi planifikuar të arrijmë përmes përdorimit të tij. Me fjalë të tjera, vlefshmëria është verifikimi i përputhshmërisë së sistemit me pritshmëritë e klientit. Çështjet që lidhen me vlefshmërinë janë jashtë fushëveprimit të kësaj kurs trajnimi dhe përfaqësojnë një temë më vete interesante për studim. Nëse i shikoni këto tre procese për sa i përket pyetjes që ata përgjigjen, atëherë testimi i përgjigjet pyetjes "Si bëhet?" ose "A i plotëson kërkesat sjellja e programit të zhvilluar?" Verifikimi - "Çfarë është bërë?" ose "A i plotëson sistemi i zhvilluar kërkesat?" dhe vërtetimi është "A bëri atë që duhet të bëjë?" ose “A i plotëson sistemi i zhvilluar pritshmëritë e klientit?”. 1.7. Dokumentacioni i krijuar në faza të ndryshme të ciklit jetësor Sinkronizimi i të gjitha fazave të zhvillimit ndodh me ndihmën e dokumenteve që krijohen në secilën fazë. Në të njëjtën kohë, dokumentacioni krijohet si në segmentin e drejtpërdrejtë të ciklit jetësor - gjatë zhvillimit të një sistemi softuerik, dhe në të kundërt - gjatë verifikimit të tij. Le të përpiqemi, duke përdorur shembullin e një cikli jetësor në formë V, të gjurmojmë se çfarë lloj dokumentesh krijohen në secilin prej segmenteve dhe çfarë marrëdhëniesh ekzistojnë midis tyre (Fig. 8). Rezultati i fazës së zhvillimit të kërkesave të sistemit është kërkesat e formuluara për sistemin - një dokument që përshkruan parimet e përgjithshme të funksionimit të sistemit, ndërveprimin e tij me " mjedisi» - përdoruesit e sistemit, si dhe softueri dhe hardueri që sigurojnë funksionimin e tij. Zakonisht, paralelisht me kërkesat për sistemin, krijohet një plan verifikimi dhe përcaktohet një strategji verifikimi. Këto dokumente përcaktojnë një qasje të përgjithshme se si do të kryhet testimi, cilat metodologji do të zbatohen dhe cilat aspekte të sistemit të ardhshëm duhet t'i nënshtrohen testimit rigoroz. Një detyrë tjetër e zgjidhur duke përcaktuar një strategji verifikimi është përcaktimi i vendit të proceseve të ndryshme të verifikimit dhe marrëdhëniet e tyre me proceset e zhvillimit. 20 Procesi i verifikimit që funksionon me kërkesat e sistemit është procesi i vërtetimit të kërkesave, duke i krahasuar ato me pritshmëritë reale të klientit. Duke parë përpara, le të themi se procesi i vlefshmërisë është i ndryshëm nga testet e pranimit të kryera kur sistemi i përfunduar i transferohet klientit, megjithëse mund të konsiderohet pjesë e testeve të tilla. Validimi është një mjet për të vërtetuar jo vetëm korrektësinë e zbatimit të sistemit nga këndvështrimi i klientit, por edhe korrektësinë e parimeve që qëndrojnë në themel të zhvillimit të tij. Oriz. 8 Proceset dhe dokumentet e zhvillimit të sistemit të softuerit Kërkesat e sistemit janë baza për procesin e zhvillimit të kërkesave funksionale dhe arkitekturën e projektit. Gjatë këtij procesi zhvillohen kërkesa të përgjithshme për softuerin e sistemit, për funksionet që ai duhet të kryejë. Kërkesat funksionale shpesh përfshijnë përcaktimin e modeleve të sjelljes së sistemit në normale dhe situatat emergjente , rregullat e përpunimit të të dhënave dhe përkufizimet e ndërfaqes së përdoruesit. Teksti i kërkesës, si rregull, përfshin fjalët "duhet, duhet" dhe ka strukturën e formës "Nëse vlera e temperaturës në sensorin ABC arrin 30 gradë Celsius ose më shumë, sistemi duhet të ndalojë lëshimin e një sinjali zanor. ” Kërkesat funksionale janë baza për zhvillimin e arkitekturës së sistemit - një përshkrim i strukturës së tij për sa i përket nënsistemeve dhe njësive strukturore të gjuhës në të cilën kryhet zbatimi - zona, klasa, module, funksione, etj. Bazuar në kërkesat funksionale, shkruhen kërkesat e testit - dokumente që përmbajnë përcaktimin e pikave kyçe që duhet të kontrollohen për t'u siguruar që zbatimi i kërkesave funksionale është i saktë. Kërkesat e testit shpesh fillojnë me fjalët "Kontrollo çfarë" dhe përmbajnë lidhje me kërkesat e tyre funksionale përkatëse. Shembuj të kërkesave të provës për kërkesat e mësipërme funksionale do të ishin "Verifikoni që nëse temperatura në sensorin ABC bie nën 30 gradë Celsius, sistemi lëshon një tingull paralajmërues" dhe "Verifikoni që nëse temperatura në sensorin ABC kalon 30 gradë Celsius, sistemi nuk bip." 21 Një nga problemet që lindin kur shkruani kërkesat e testit është paprovueshmëria themelore e disa kërkesave, për shembull, kërkesa "Ndërfaqja e përdoruesit duhet të jetë intuitive" nuk mund të testohet pa një përkufizim të qartë se çfarë është një ndërfaqe intuitive. Kërkesa të tilla funksionale jo specifike zakonisht modifikohen më pas. Karakteristikat arkitekturore të sistemit mund të shërbejnë gjithashtu si burim për krijimin e kërkesave të testimit që marrin parasysh veçoritë e zbatimit të softuerit të sistemit. Një shembull i një kërkese të tillë është, për shembull, "Kontrolloni që vlera e temperaturës në sensorin ABC të mos kalojë 255". Në bazë të kërkesave funksionale dhe arkitekturës, shkruhet kodi i programit të sistemit, dhe për ta kontrolluar atë, në bazë të kërkesave të testit, përgatitet një plan testimi - një përshkrim i sekuencës së rasteve të testimit që kontrollojnë përputhshmërinë e zbatimin e sistemit me kërkesat. Çdo rast testimi përmban një përshkrim specifik të vlerave të dhëna si hyrje në sistem, vlerat e pritshme si rezultate dhe një përshkrim të skenarit të ekzekutimit të testit. Në varësi të objektit të testimit, një plan testimi mund të përgatitet ose si një program në një gjuhë programimi, ose si një skedar të dhënash hyrëse për një paketë veglash që ekzekuton sistemin nën provë dhe i kalon atij vlerat e specifikuara në planin e testimit, ose si udhëzime për përdoruesin.sistemi që përshkruan hapat e nevojshëm që duhen ndërmarrë për të testuar funksionet e ndryshme të sistemit. Si rezultat i ekzekutimit të të gjitha rasteve të provës, mblidhen statistika mbi suksesin e kalimit të testit - përqindja e rasteve të provës për të cilat vlerat reale të prodhimit përkonin me ato të pritshme, të ashtuquajturat teste të kaluara. Testet e dështuara janë të dhënat fillestare për analizimin e shkaqeve të gabimeve dhe korrigjimin e tyre të mëvonshëm. Në fazën e integrimit, modulet individuale të sistemit grumbullohen në një tërësi të vetme dhe ekzekutohen rastet e provës që kontrollojnë të gjithë funksionalitetin e sistemit. Në fazën e fundit, sistemi i përfunduar i dorëzohet klientit. Para zbatimit, specialistët e klientit, së bashku me zhvilluesit, kryejnë teste pranimi - ata kontrollojnë funksionet që janë kritike për përdoruesin në përputhje me një program testimi të miratuar paraprakisht. Pas përfundimit me sukses të testeve, sistemi i transferohet klientit, në të kundërt dërgohet për rishikim. 1.8. Llojet e proceseve të testimit dhe verifikimit dhe vendi i tyre në modele të ndryshme të ciklit jetësor 1.8.1. Testimi i njësive Njësitë e vogla (procedurat, klasat, etj.) i nënshtrohen testimit të njësive. Kur testoni një modul relativisht të vogël me madhësi 100-1000 linjash, është e mundur të kontrolloni, nëse jo të gjitha, atëherë të paktën shumë degë logjike në zbatim, shtigje të ndryshme në grafikun e varësisë së të dhënave, vlerat kufitare të parametrave. Në përputhje me këtë, janë ndërtuar kriteret e mbulimit të testit (mbulohen të gjithë operatorët, të gjitha degët logjike, të gjitha pikat kufitare, etj.). . Testimi i njësisë zakonisht bëhet për çdo të pavarur modul softuerik dhe është ndoshta lloji më i zakonshëm i testimit, veçanërisht për sistemet e vogla dhe të mesme. 1.8.2. Testimi i integrimit Kontrollimi i korrektësisë së të gjitha moduleve, për fat të keq, nuk garanton funksionimin e duhur të sistemit të moduleve. Literatura nganjëherë diskuton modelin "klasik" të organizimit të gabuar të testimit të një sistemi modulesh, i quajtur shpesh metoda "kërcim i madh". Thelbi i metodës është që së pari të testoni secilin modul veç e veç, pastaj t'i kombinoni ato në një sistem dhe të testoni të gjithë sistemin. Për sistemet e mëdha, kjo është joreale. Me këtë qasje, do të shpenzohet shumë kohë për lokalizimin e gabimeve dhe cilësia e testimit do të mbetet e ulët. Një alternativë ndaj "kërcimit të madh" është testimi i integrimit, kur sistemi ndërtohet në faza, grupet e moduleve shtohen gradualisht. 1.8.3. Testimi i sistemit Një produkt softuer i implementuar plotësisht i nënshtrohet testimit të sistemit. Në këtë fazë, testuesi nuk është i interesuar për korrektësinë e zbatimit të procedurave dhe metodave individuale, por i gjithë programi në tërësi, siç e sheh përdoruesi përfundimtar. Baza për testet janë Kërkesat e përgjithshme në program, duke përfshirë jo vetëm korrektësinë e zbatimit të funksioneve, por edhe performancën, kohën e përgjigjes, rezistencën ndaj dështimeve, sulmet, gabimet e përdoruesit, etj. Për testimin e sistemit dhe komponentëve, përdoren lloje specifike të kritereve të mbulimit të testit (për shembull, janë të mbuluar të gjithë skenarët tipikë të punës, të gjithë skenarët me situata jonormale, kompozimet e skenarëve të çiftuar, etj.). 1.8.4. Testimi i ngarkesës Jo vetëm që testimi i ngarkesës siguron të dhëna parashikuese për performancën e sistemit nën ngarkesë, e cila është e përqendruar në marrjen e vendimeve arkitekturore, por gjithashtu ofron informacion operacional për ekipet e mbështetjes teknike, si dhe menaxherët e projektit dhe konfigurimit që janë përgjegjës për krijimin më produktiv. konfigurimet e harduerit dhe softuerit. . Testimi i ngarkesës lejon ekipin e zhvillimit të marrë vendime më të informuara që synojnë zhvillimin e kompozimeve arkitekturore optimale. Klienti, nga ana e tij, merr mundësinë për të kryer teste pranimi në kushte afër reales. 1.8.5. Inspektimet formale Inspektimi formal është një nga mënyrat për të verifikuar dokumentet dhe kodin e programit të krijuar gjatë procesit të zhvillimit të softuerit. Gjatë një inspektimi zyrtar, një grup specialistësh kontrollon në mënyrë të pavarur përputhshmërinë e dokumenteve të inspektuara me dokumentet origjinale. Pavarësia e verifikimit sigurohet nga fakti se ai kryhet nga inspektorë që nuk kanë marrë pjesë në hartimin e dokumentit që inspektohet. 1.9. Verifikimi i softuerit që po certifikohet Le të japim disa përkufizime që përcaktojnë strukturën e përgjithshme Procesi i certifikimit të softuerit: Certifikimi i softuerit është procesi i krijimit dhe njohjes formale se zhvillimi i softuerit është kryer në përputhje me kërkesa të caktuara. Gjatë procesit të certifikimit, ndodh ndërveprimi i aplikantit, autoritetit certifikues dhe autoritetit mbikëqyrës.Aplikanti është një organizatë që paraqet një kërkesë pranë Autoritetit përkatës Certifikues për marrjen e një certifikate (konformiteti, cilësia, përshtatshmëria, etj.) e një produkt. Organi certifikues – një organizatë që shqyrton aplikacionin e Aplikantit për Certifikimin e Softuerit dhe, qoftë në mënyrë të pavarur ose duke formuar një komision të posaçëm, prodhon një sërë procedurash që synojnë kryerjen e procesit të Certifikimit të Softuerit të Aplikantit. 23 Organi mbikëqyrës - një komision specialistësh që mbikëqyrin proceset e zhvillimit nga aplikanti i një certifikate sistemi i informacionit dhe dhënien e një mendimi për përputhjen e këtij procesi me disa kërkesa, i cili i paraqitet për shqyrtim organit certifikues. Certifikimi mund të synojë marrjen e një certifikate konformiteti ose një certifikate të cilësisë. Në rastin e parë, rezultati i certifikimit është njohja e përputhshmërisë së proceseve të zhvillimit me kritere të caktuara, dhe funksionaliteti i sistemit me kërkesa të caktuara. Dokumentet udhëzuese mund të shërbejnë si shembull i kërkesave të tilla. Shërbimi Federal mbi kontrollin teknik dhe eksportues në fushën e sigurisë së sistemeve softuerike. Në rastin e dytë, rezultati është njohja e konformitetit të proceseve të zhvillimit me kritere të caktuara, gjë që garanton një nivel të përshtatshëm të cilësisë së produktit të prodhuar dhe përshtatshmërinë e tij për përdorim në kushte të caktuara. Një shembull i standardeve të tilla është një seri standardesh ndërkombëtare të cilësisë ISO 9000:2000 (GOST R ISO 9000-2001) ose standardet e aviacionit DO-178B, AS9100, AS9006. Testimi i softuerit për t'u certifikuar ka dy qëllime plotësuese: Qëllimi i parë është të demonstrojë se softueri i plotëson kërkesat për të. Qëllimi i dytë është të demonstrohet me një nivel të lartë besimi se gabimet që mund të çojnë në situata të papranueshme dështimi, siç përcaktohet nga procesi i vlerësimit të sigurisë së sistemit, identifikohen gjatë procesit të testimit. Për shembull, sipas kërkesave të standardit DO-178B, për të përmbushur qëllimet e testimit të softuerit, është e nevojshme si më poshtë: Testet duhet së pari të bazohen në kërkesat e softuerit; Testet duhet të dizajnohen për të verifikuar funksionimin e saktë dhe për të krijuar kushte për identifikimin e gabimeve të mundshme. Rishikimi i plotësisë së testeve bazuar në kërkesat e softuerit duhet të përcaktojë se cilat kërkesa nuk janë testuar. Analiza e plotësisë së testeve bazuar në strukturën e kodit të programit duhet të përcaktojë se cilat struktura nuk janë ekzekutuar gjatë testimit. Ky standard flet edhe për testimin e bazuar në kërkesat. Kjo strategji është gjetur të jetë më efektive në zbulimin e gabimeve. Udhëzimet për zgjedhjen e rasteve të testimit bazuar në kërkesat përfshijnë si më poshtë: Për të arritur qëllimet e testimit të softuerit, duhet të kryhen dy kategori testesh: teste për situata normale dhe teste për situata jonormale (jo të nevojshme, të forta). Rastet specifike të testimit duhet të zhvillohen për kërkesat e softuerit dhe burimet e gabimeve të qenësishme në procesin e zhvillimit të softuerit. Qëllimi i testeve për situata normale është të demonstrojë aftësinë e softuerit për t'iu përgjigjur hyrjeve dhe kushteve normale në përputhje me kërkesat. 24 Qëllimi i testeve për situata jonormale është të demonstrojë aftësinë e softuerit për t'iu përgjigjur në mënyrë adekuate hyrjeve dhe kushteve jonormale, me fjalë të tjera, nuk duhet të shkaktojë dështimin e sistemit. Kategoritë e situatave të dështimit për sistemin përcaktohen duke përcaktuar rrezikun e situatës së dështimit për avionin dhe pasagjerët e tij. Çdo gabim në softuer mund të shkaktojë një dështim që do të kontribuojë në situatën e dështimit. Kështu, niveli i integritetit të softuerit që kërkohet për funksionimin e sigurt lidhet me situatat e dështimit të sistemit. Ekzistojnë 5 nivele të situatave të dështimit nga të vogla në kritike. Sipas këtyre niveleve, prezantohet koncepti i nivelit të kritikitetit të softuerit. Niveli i kritikitetit përcakton përbërjen e dokumentacionit të dorëzuar pranë autoritetit të certifikimit, dhe rrjedhimisht thellësinë e proceseve të zhvillimit dhe verifikimit të sistemit. Për shembull, numri i llojeve të dokumenteve dhe sasia e punës së zhvillimit të sistemit që kërkohet për certifikim për nivelin më të ulët të kritikitetit DO-178B mund të ndryshojnë me një ose dy rend të madhësisë nga numri dhe vëllimet e kërkuara për certifikim për më shumë. nivel të lartë. Kërkesat specifike përcaktohen nga standardi sipas të cilit është planifikuar të kryhet certifikimi. 25 TEMA 2. Testimi i kodit të programit (leksionet 2-5) 2.1. Detyrat dhe qëllimet e testimit të kodit të programit Testimi i kodit të programit është procesi i ekzekutimit të kodit të programit që synon identifikimin e defekteve ekzistuese në të. Një defekt këtu kuptohet si një pjesë e kodit të programit, ekzekutimi i të cilit, në kushte të caktuara, çon në sjellje të papritur të sistemit (d.m.th., sjellje që nuk i plotëson kërkesat). Sjellja e papritur e sistemit mund të çojë në dështime në funksionimin dhe dështimet e tij, në këtë rast ato flasin për defekte të rëndësishme në kodin e programit. Disa defekte shkaktojnë probleme të vogla që nuk prishin funksionimin e sistemit, por e vështirësojnë disi punën me të. Në këtë rast, flasim për defekte të mesme ose të vogla. Detyra e testimit me këtë qasje është të përcaktojë kushtet në të cilat shfaqen defektet e sistemit dhe të regjistrojë këto kushte. Detyrat e testimit zakonisht nuk përfshijnë identifikimin e seksioneve specifike me defekt të kodit të programit dhe kurrë nuk përfshijnë rregullimin e defekteve - kjo është një detyrë korrigjimi që kryhet bazuar në rezultatet e testimit të sistemit. Qëllimi i aplikimit të procedurës së testimit të kodit të programit është të minimizojë numrin e defekteve, veçanërisht të rëndësishme, në produktin përfundimtar. Vetëm testimi nuk mund të garantojë mungesën e plotë të defekteve në kodin e sistemit. Megjithatë, në kombinim me proceset e verifikimit dhe vlefshmërisë që synojnë eliminimin e mospërputhjeve dhe paplotësisë dokumentacionin e projektit(në veçanti, kërkesat për sistemin), testimi i mirëorganizuar siguron që sistemi të plotësojë kërkesat dhe të sillet në përputhje me to në të gjitha situatat e parashikuara. Kur zhvillohen sisteme të besueshmërisë së shtuar, për shembull, aviacioni, garancitë e besueshmërisë arrihen përmes një organizimi të qartë të procesit të testimit, duke përcaktuar lidhjen e tij me proceset e tjera të ciklit jetësor, duke prezantuar karakteristika sasiore që lejojnë vlerësimin e suksesit të testimit. Në të njëjtën kohë, sa më të larta të jenë kërkesat për besueshmërinë e sistemit (niveli i tij i kritikitetit), aq më të rrepta janë kërkesat. Kështu, para së gjithash, ne konsiderojmë jo rezultatet specifike të testimit të një sistemi të veçantë, por organizimi i përgjithshëm procesi i testimit, duke përdorur qasjen "një proces i mirëorganizuar jep një rezultat cilësor". Kjo qasje është e zakonshme për shumë standarde të cilësisë ndërkombëtare dhe të industrisë, të cilat do të diskutohen më në detaje në fund të këtij kursi. Cilësia e sistemit të zhvilluar me këtë qasje është rezultat i një procesi të organizuar të zhvillimit dhe testimit, dhe jo një rezultat i pavarur i pamenaxhuar. Meqenëse sistemet moderne softuerike janë shumë të mëdha, metoda e zbërthimit funksional përdoret gjatë testimit të kodit të programit të tyre. Sistemi është i ndarë në module të veçanta (klasa, hapësira emrash, etj.) që kanë funksionalitet dhe ndërfaqe të përcaktuara nga kërkesat. Pas kësaj, çdo modul testohet individualisht - kryhet testimi i njësisë. Më pas, modulet individuale grumbullohen në konfigurime më të mëdha - kryhet testimi i integrimit dhe së fundi, testohet sistemi në tërësi - kryhet testimi i sistemit. Nga pikëpamja e kodit të programit, njësia, integrimi dhe testimi i sistemit kanë shumë të përbashkëta, kështu që kjo temë do të fokusohet në testimin e njësisë, veçoritë e integrimit dhe testimit të sistemit do të diskutohen më vonë. 26 Gjatë testimit të njësisë, çdo modul testohet si për pajtueshmërinë me kërkesat ashtu edhe për mungesën e seksioneve problematike të kodit të programit që mund të shkaktojnë dështime dhe dështime në sistem. Si rregull, modulet nuk funksionojnë jashtë sistemit - ata marrin të dhëna nga module të tjera, i përpunojnë dhe i kalojnë ato. Për të izoluar nga njëra anë modulin nga sistemi dhe për të eliminuar ndikimin e gabimeve të mundshme të sistemit, dhe nga ana tjetër, për t'i siguruar modulit të gjitha të dhënat e nevojshme, përdoret një mjedis testimi. Detyra e mjedisit të testimit është të krijojë një mjedis ekzekutimi për modulin, për të imituar të gjitha ndërfaqet e jashtme që akseson moduli. Rreth veçorive të organizimit të mjedisit të testimit do të diskutohet në këtë temë. Një procedurë tipike testimi është përgatitja dhe ekzekutimi i rasteve të testimit (të referuara gjithashtu thjesht si teste). Çdo rast testimi kontrollon një "situatë" në sjelljen e modulit dhe përbëhet nga një listë vlerash të kaluara në hyrjen e modulit, një përshkrim i nisjes dhe ekzekutimit të përpunimit të të dhënave - një skenar testimi dhe një listë të vlerat që priten në daljen e modulit në rast të sjelljes së saktë të tij. Skenarët e testimit janë përpiluar në atë mënyrë që të përjashtojnë aksesin në të dhënat e brendshme të modulit, i gjithë ndërveprimi duhet të ndodhë vetëm përmes ndërfaqeve të tij të jashtme. Ekzekutimi i një rasti testimi mbështetet nga një mjedis testimi, i cili përfshin një zbatim programor të skriptit të testit. Ekzekutimi fillon duke kaluar të dhëna në modul dhe duke ekzekutuar skriptin. Prodhimi aktual i marrë nga moduli si rezultat i ekzekutimit të skriptit ruhet dhe krahasohet me ato të pritshme. Nëse përputhen, testi konsiderohet i kaluar, në të kundërt nuk kalohet. Çdo test i dështuar tregon ose një defekt në njësinë nën provë, ose në mjedisin e testimit, ose në përshkrimin e testit. Grupi i përshkrimeve të rasteve të provës është një plan testimi - dokumenti kryesor që përcakton procedurën për testimin e një moduli programi. Plani i testimit specifikon jo vetëm vetë rastet e testimit, por edhe rendin në të cilin ato ndjekin, gjë që gjithashtu mund të jetë e rëndësishme. Struktura dhe veçoritë e planeve të testimit do të diskutohen në këtë temë, problemet që lidhen me renditjen e rasteve të testimit - në temën "Përsëritshmëria e testimit". Gjatë testimit, shpesh është e nevojshme të merren parasysh jo vetëm kërkesat për sistemin, por edhe struktura e kodit të programit të modulit në provë. Në këtë rast, testet janë krijuar në mënyrë të tillë që të zbulojnë gabime tipike programuesit e shkaktuar nga keqinterpretimi i kërkesave. Zbatohen kontrollet e kushteve kufitare, kontrollet e klasës së ekuivalencës. Mungesa në sistemin e aftësive që nuk janë të specifikuara nga kërkesat garanton vlerësime të ndryshme të mbulimit të kodit të programit nga testet, d.m.th. vlerësimet se sa përqind e konstrukteve të caktuara gjuhësore janë ekzekutuar si rezultat i ekzekutimit të të gjitha rasteve testuese. E gjithë kjo do të diskutohet në fund të kësaj teme. 2.2. Metodat e testimit 2.2.1. Kutia e zezë Ideja kryesore në testimin e një sistemi si kuti e zezë është që të gjitha materialet që janë në dispozicion të testuesit janë kërkesat për sistemin që përshkruajnë sjelljen e tij dhe vetë sistemin, me të cilin ai mund të punojë vetëm duke aplikuar disa ndikime të jashtme. tek inputet e tij dhe duke vëzhguar outputet disa rezultate. Të gjitha tiparet e brendshme të zbatimit të sistemit janë të fshehura nga testuesi, kështu që sistemi është një "kuti e zezë", sjellja e saktë e së cilës në lidhje me kërkesat duhet të kontrollohet. 27 Nga pikëpamja e kodit të programit, një kuti e zezë mund të jetë një grup klasash (ose modulesh) me ndërfaqe të jashtme të njohura, por tekste burimore të paarritshme. Detyra kryesore e testuesit për këtë metodë testimi është të verifikojë vazhdimisht nëse sjellja e sistemit plotëson kërkesat. Për më tepër, testuesi duhet të testojë sistemin në situata kritike - çfarë ndodh nëse jepen vlera të pasakta të hyrjes. Në një situatë ideale, të gjitha variantet e situatave kritike duhet të përshkruhen në kërkesat për sistemin, dhe testuesi mund të dalë vetëm me kontrolle specifike për këto kërkesa. Megjithatë, në realitet, si rezultat i testimit, zakonisht zbulohen dy lloje problemesh të sistemit: 1. Mospërputhja e sjelljes së sistemit me kërkesat 2. Sjellja joadekuate e sistemit në situata që nuk parashikohen nga kërkesat. Raportet e të dy llojeve të çështjeve dokumentohen dhe ndahen me zhvilluesit. Në të njëjtën kohë, problemet e llojit të parë zakonisht shkaktojnë një ndryshim në kodin e programit, shumë më rrallë - një ndryshim në kërkesat. Ndryshimi i kërkesave në këtë rast mund të kërkohet për shkak të mospërputhjes së tyre (disa kërkesa të ndryshme përshkruajnë modele të ndryshme të sjelljes së sistemit në të njëjtën situatë) ose pasaktësie (kërkesat nuk korrespondojnë me realitetin). Problemet e llojit të dytë kërkojnë qartë ndryshime në kërkesat për shkak të paplotësueshmërisë së tyre - kërkesat e humbasin qartë situatën që çon në sjellje joadekuate të sistemit. Në të njëjtën kohë, sjellja joadekuate mund të kuptohet si një kolaps i plotë i sistemit, ose në përgjithësi çdo sjellje që nuk përshkruhet në kërkesat. Testimi i kutisë së zezë quhet gjithashtu testimi i kërkesave. ky është i vetmi burim informacioni për ndërtimin e një plani testimi. 2.2.2. Kutia e qelqit (e bardhë) Kur teston një sistem si një kuti xhami, testuesi ka akses jo vetëm në kërkesat për sistemin, hyrjet dhe daljet e tij, por edhe në strukturën e tij të brendshme - sheh kodin e programit të tij. Disponueshmëria e kodit të programit zgjeron aftësitë e testuesit me faktin se ai mund të shohë përputhshmërinë e kërkesave me seksionet e kodit të programit dhe në këtë mënyrë të shohë nëse ka kërkesa për të gjithë kodin e programit. Kodi i programit për të cilin nuk ka kërkesa quhet kod pa kërkesa. Një kod i tillë është një burim i mundshëm i sjelljes së papërshtatshme të sistemit. Përveç kësaj, transparenca e sistemit ju lejon të thelloni analizën e zonave të tij që shkaktojnë probleme - shpesh një problem neutralizon një tjetër dhe ato nuk ndodhin kurrë në të njëjtën kohë. 2.2.3. Testimi i modelit Testimi i modelit është disi i mënjanuar nga metodat klasike të verifikimit të softuerit. Para së gjithash, kjo për faktin se objekti i testimit nuk është vetë sistemi, por modeli i tij i krijuar me mjete formale. Nëse lëmë mënjanë çështjet e kontrollit të korrektësisë dhe zbatueshmërisë së vetë modelit (besohet se korrektësia dhe përputhshmëria e tij me sistemin origjinal mund të vërtetohet me mjete formale), atëherë testuesi ka në dispozicion një mjet mjaft të fuqishëm për të analizuar integritetin e përgjithshëm të sistemit. Duke punuar me modelin, mund të krijoni situata që nuk mund të krijohen në një laborator testimi për një sistem real. Duke punuar me modelin e kodit të programit të sistemit, është e mundur të analizohen vetitë e tij dhe parametrat e tillë të sistemit si optimaliteti i algoritmeve ose qëndrueshmëria e tij. 28 Megjithatë, testimi i modelit nuk është bërë i përhapur pikërisht për shkak të vështirësive që hasen në zhvillimin e një përshkrimi formal të sjelljes së sistemit. Një nga përjashtimet e pakta janë sistemet e komunikimit, aparati algoritmik dhe matematikor i të cilave është mjaft i zhvilluar. 2.2.4. Analiza e kodit të programit (inspektimet) Në shumë situata, testimi i sjelljes së sistemit në tërësi është i pamundur - seksione individuale të kodit të programit mund të mos ekzekutohen kurrë, ndërsa ato do të mbulohen nga kërkesat. Trajtuesit e përjashtimeve janë një shembull i seksioneve të tilla të kodit. Nëse, për shembull, dy module i dërgojnë vlerat numerike njëri-tjetrit dhe funksionet e vërtetimit të vlerës funksionojnë në të dy modulet, atëherë funksioni i kontrollit të modulit të marrësit nuk do të aktivizohet kurrë, sepse të gjitha vlerat e gabuara do të ndërpriten në transmetues. Në këtë rast, kryhet një analizë manuale e kodit të programit për korrektësinë, e quajtur gjithashtu rishikime ose inspektime të kodit. Nëse, si rezultat i inspektimit, identifikohen zonat problematike, atëherë informacioni në lidhje me këtë u transferohet zhvilluesve për korrigjim së bashku me rezultatet e testeve të rregullta. 2.3. Mjedisi i testimit Pjesa më e madhe e testimit të pothuajse çdo sistemi kompleks kryhet zakonisht në modaliteti automatik. Për më tepër, sistemi në provë zakonisht ndahet në module të veçanta, secila prej të cilave testohet fillimisht veçmas nga të tjerët, pastaj si një e tërë. Kjo do të thotë që për të kryer testimin, është e nevojshme të krijohet një mjedis që do të sigurojë nisjen dhe ekzekutimin e modulit në provë, kalimin e tij të të dhënave hyrëse, mbledhjen e të dhënave reale të daljes të marra si rezultat i funksionimit të sistemit në të dhënat hyrëse të dhëna. . Pas kësaj, mjedisi duhet të krahasojë të dhënat aktuale të daljes me ato të pritshme dhe, bazuar në këtë krahasim, të nxjerrë një përfundim në lidhje me përputhshmërinë e sjelljes së modulit me atë të specifikuar (Fig. 9). Të dhënat e pritshme të daljes nga drejtuesi i testit nën Modulin e rezultateve të të dhënave hyrëse të përpunimit të testit Studimet e të dhënave të daljes reale 9 Skema e përgjithësuar e mjedisit të testimit Mjedisi i testimit mund të përdoret gjithashtu për të tjetërsuar modulet individuale të sistemit nga i gjithë sistemi. Ndarja e moduleve të sistemit në fazat e hershme të testimit ju lejon të lokalizoni më saktë problemet që lindin në kodin e tyre të programit. Për të mbështetur funksionimin e një moduli të izoluar nga sistemi, mjedisi i testimit duhet të modelojë sjelljen e të gjitha moduleve, funksionet ose të dhënat e të cilëve aksesohen nga moduli nën testim. 29
Dërgoni punën tuaj të mirë në bazën e njohurive është e thjeshtë. Përdorni formularin e mëposhtëm
Studentët, studentët e diplomuar, shkencëtarët e rinj që përdorin bazën e njohurive në studimet dhe punën e tyre do t'ju jenë shumë mirënjohës.
Priti në http://www.allbest.ru/
abstrakte
Metodat e verifikimit dhe testimit të softuerit
Prezantimi
Njerëzit priren të bëjnë gabime. Gabimet kanë qenë gjithmonë dhe do të jenë gjithmonë. Ekziston një shaka në mjedisin IT që nëse programi fillon herën e parë dhe funksionon menjëherë, atëherë duhet të kërkoni një gabim.
Së bashku me zhvillimin Shkenca Kompjuterike, me depërtimin e tij në të gjitha sferat e jetës, numri i gabimeve në programe po rritet gjithashtu. Për më tepër, rritja e gabimeve është në disproporcion me rritjen e numrit të programeve. Çdo vit radhët e programuesve plotësohen me bydlocoder (dhe emri i tyre është legion), të cilët zhvillojnë fushën e gabimeve në mënyrë eksponenciale.
Gabimet nuk janë të dukshme në çdo zonë. Për shembull, askush nuk kujdeset për gabimet dhe dobësitë në shfletues si "amigo". Po, dhe humbjet nga gabime të tilla janë të parëndësishme: maksimumi që një përdorues i zakonshëm mund të humbasë është llogaritë në rrjetet sociale, një mijë e gjysmë foto pushimesh mediokre dhe një koleksion porno.
Por ka fusha në të cilat gabimet e programimit mund të çojnë në pasojat më fatkeqe. Një nga rastet e para që arrita të gjej është anija kozmike Mariner 1, e cila u shkatërrua më 22 korrik 1962, 293 sekonda pas nisjes, për shkak të një gabimi në programin kompjuterik në bord. Është mirë që atëherë nuk kishte vdekje.
Dhe çfarë do të ndodhë nëse kompjuteri në bord Boeing-747, me katërqind pasagjerë në bord, bën një përjashtim?
Pikërisht për zona të tilla që mund të quhen "serioze" janë shpikur metodat e verifikimit dhe testimit.
Në disa literaturë të huaj identifikohen proceset e verifikimit dhe testimit dhe në disa vende testimi konsiderohet si një nga metodat e verifikimit. Unë do ta kryej këtë punë në mënyrën më të mirë të të kuptuarit tim, do të konsideroj veçmas proceset e verifikimit dhe testimit. Gjithashtu, me drejtësi, do të prek temën e vlefshmërisë së softuerit.
1. Përkufizimet
Cikli i jetes softuer (LC). Ky term i referohet intervalit kohor që nis nga ideja e krijimit të softuerit me funksionalitetin e nevojshëm për zgjidhjen e problemeve të caktuara deri në ndërprerjen e plotë të përdorimit. Versioni i fundit këtë program.
Artefakte cikli jetësor i softuerit (SW). Kjo përfshin një sërë materialesh informacioni që lidhen me krijimin e softuerit. Këto janë termat e referencës, përshkrimi i arkitekturës, kodi burimor, dokumentacioni i përdoruesit dhe dokumente të tjera. Materialet që janë përdorur gjatë zhvillimit, por nuk janë regjistruar në një formë të aksesueshme (për shembull, komentet në kod dhe abuzimi i zhvilluesve në bisedë) nuk janë objekte.
2. Verifikimi
Verifikimi kontrollon përputhshmërinë e disa objekteve të krijuara gjatë zhvillimit dhe mirëmbajtjes së softuerit me të tjerët të krijuar ose përdorur më parë si të dhëna fillestare, si dhe përputhshmërinë e këtyre artefakteve dhe proceseve të zhvillimit të tyre me rregullat dhe standardet. Në veçanti, verifikimi kontrollon korrespondencën midis normave të standardeve, përshkrimin e kërkesave (kushtet e referencës) për softuerin, zgjidhjet e projektimit, kodin burimor, dokumentacionin e përdoruesit dhe funksionimin e vetë softuerit. Përveç kësaj, verifikohet se kërkesat zgjidhjet e projektimit, dokumentacioni dhe kodi hartohen në përputhje me normat dhe standardet e miratuara në një vend, industri dhe organizatë të caktuar gjatë zhvillimit të softuerit, dhe gjithashtu që kur u krijuan, të gjitha operacionet e specifikuara në standarde u kryen në sekuencën e kërkuar. Gabimet dhe defektet e zbuluara gjatë verifikimit janë mospërputhje ose kontradikta midis disa prej dokumenteve të listuara, midis dokumenteve dhe funksionimit aktual të programit, midis normave të standardeve dhe proceseve aktuale të zhvillimit dhe mirëmbajtjes së softuerit. Në të njëjtën kohë, vendosja se cili dokument do të korrigjohet (ndoshta të dyja) është një detyrë më vete.
Sa më sipër është përkufizimi zyrtar i verifikimit. Në fakt, gjithçka është shumë më e thjeshtë: verifikimi përcakton a po e bëjmë mirë programin?.
Kështu, metodat kryesore të verifikimit janë ekzaminimi dhe inspektimi.
verifikimi i ekspertizës së programit
3. Vleresimi
Procesi i vlefshmërisë kontrollon përputhshmërinë e çdo objekti të krijuar ose përdorur gjatë zhvillimit dhe mirëmbajtjes së softuerit me nevojat dhe kërkesat e përdoruesve dhe klientëve të këtij softueri, duke marrë parasysh ligjet fusha lëndore dhe kufizimet e kontekstit në të cilin përdoret softueri.
Dhe përsëri, pas shumë fjalëve, ka një shumë detyrë e thjeshtë: gjatë procesit të vlefshmërisë, kontrollohet nëse një funksionalitet i caktuar i programit u nevojitet këtyre përdoruesve/klientëve. A i plotëson produkti softuer dëshirat e klientëve dhe përdoruesve fundorë.
4. Testimi
Testimi është procesi i zbulimit të gabimeve në softuer duke ekzekutuar kodin e një sistemi softuerik në të dhënat e testit, duke mbledhur karakteristikat e performancës në dinamikën e ekzekutimit në një mjedis specifik operativ, duke identifikuar gabime, defekte, dështime dhe defekte të ndryshme të shkaktuara nga situata të parregullta dhe jonormale. ose ndërprerje jonormale e softuerit.
Historikisht, lloji i parë i testimit ishte korrigjimi.
Korrigjimi është kontrollimi i përshkrimit të një objekti programi në një gjuhë programimi në mënyrë që të zbulohen gabimet në të dhe më pas t'i eliminojnë ato. Gabimet zbulohen nga përpiluesi gjatë kontrollit të tyre sintaksor. Pas korrigjimit, verifikimi kryhet për të kontrolluar korrektësinë e kodit dhe vlefshmëria për të kontrolluar nëse produkti plotëson kërkesat e specifikuara.
1. Metodat e provës statike
Metodat statike përdoren gjatë inspektimeve dhe rishikimit të specifikimeve të komponentëve pa zbatimin e tyre. Teknika e analizës statike konsiston në shqyrtimin dhe analizimin metodik të strukturës së programeve, si dhe në vërtetimin e korrektësisë së tyre. Analiza statike ka për qëllim analizën e dokumenteve të zhvilluara në të gjitha fazat e ciklit jetësor dhe konsiston në inspektimin e kodit burimor dhe kontrollin nga fundi në fund të programit.
Inspektimi i softuerit është një kontroll statik i përputhshmërisë së programit me specifikimet e dhëna, i kryer duke analizuar paraqitje të ndryshme të rezultateve të projektimit (dokumentacioni, kërkesat, specifikimet, diagramet ose kodi burimor i programit) në proceset e ciklit jetësor. Rishikimet dhe inspektimet e rezultateve të projektimit dhe përputhshmëria e tyre me kërkesat e klientëve ofrojnë më shumë cilesi e larte krijuar sisteme softuerike.
2. Metodat dinamike të testimit
Metoda e kutisë së zezë. Kur përdoret kjo metodë, përdoret informacioni për problemin që zgjidhet, por asgjë rreth strukturës së programit nuk dihet. Qëllimi i testimit sipas këtij parimi është të identifikojë numrin maksimal të gabimeve me një test duke përdorur një nëngrup të vogël të të dhënave të mundshme hyrëse.
Metodat e testimit sipas këtij parimi përdoren për të testuar funksionet e zbatuara në program duke kontrolluar mospërputhjen midis sjelljes aktuale të funksioneve dhe sjelljes së pritur, duke marrë parasysh specifikimet e kërkesave. Gjatë përgatitjes për këtë testim, ndërtohen tabelat e gjendjes, grafikët shkak-pasojë 1 dhe zonat e ndarjes. Përveç kësaj, përgatiten grupe testimi që marrin parasysh parametrat dhe kushtet mjedisore që ndikojnë në sjelljen e funksioneve.
Metoda e kutisë së bardhë.
Kjo metodë ju lejon të eksploroni strukturën e brendshme të programit, dhe zbulimi i të gjitha gabimeve në program është një kriter për testimin e plotë të rrugëve të rrjedhës së kontrollit, ndër të cilat konsiderohen:
Kriteri i mbulimit të operatorit - një grup testesh në total duhet të sigurojë që secili operator të ketë kaluar të paktën një herë;
Kriteri i testimit të degës (aka mbulimi i vendimit ose mbulimi i tranzicionit) - grupi i testeve në total duhet të sigurojë që çdo degë ose dalje të kalojë të paktën një herë.
3. Testimi funksional
Qëllimi i testimit funksional është të zbulojë mospërputhjet midis sjelljes aktuale të funksioneve të zbatuara dhe sjelljes së pritshme sipas specifikimeve dhe kërkesave fillestare. Testet funksionale duhet të mbulojnë të gjitha funksionet e zbatuara, duke marrë parasysh llojet më të mundshme të gabimeve. Skenarët e testimit që kombinojnë teste individuale janë të përqendruara në kontrollimin e cilësisë së zgjidhjes së problemeve funksionale.
Testet funksionale krijohen sipas specifikimeve të funksioneve, informacionit të projektimit dhe tekstit në një gjuhë programimi dhe përdoren për të përcaktuar plotësinë e zbatimit të detyrave funksionale dhe përputhjen e tyre me kërkesat fillestare.
Detyrat e testimit funksional përfshijnë:
Identifikimi i një sërë kërkesash funksionale;
Identifikimi i funksioneve të jashtme dhe ndërtimi i sekuencave të funksioneve në përputhje me përdorimin e tyre në sistemin softuerik;
Identifikimi i grupit të të dhënave hyrëse të secilit funksion dhe përcaktimi i zonave të ndryshimit të tyre;
Ndërtimi i kompleteve të testimit dhe skenarëve për funksionet e testimit;
Identifikimi dhe prezantimi i të gjitha kërkesave funksionale duke përdorur rastet e testimit dhe gabimet e testimit në program dhe kur ndërveproni me mjedisin.
Testet e krijuara nga informacioni i projektimit lidhen me strukturat e të dhënave, algoritmet, ndërfaqet ndërmjet komponentëve individualë dhe përdoren për të testuar komponentët dhe ndërfaqet e tyre. Qëllimi kryesor është të sigurohet plotësia dhe konsistenca e funksioneve të zbatuara dhe ndërfaqeve ndërmjet tyre.
5. Llojet e gabimit ANSI/IEEE-7 29 -8 3
Gabim (gabim) - gjendja e programit, në të cilën prodhohen rezultate të pasakta, shkaku i të cilit janë të metat (të metat) në deklaratat e programit ose në procesi teknologjik zhvillimin e tij, gjë që çon në keqinterpretim informacion në sfond, pra çon në zgjidhjen e gabuar.
Defekt (gabim) në program - pasojë e gabimeve të zhvilluesit në çdo fazë të zhvillimit, të cilat mund të përmbahen në specifikimet origjinale ose të dizajnit, tekstet e kodeve të programit, dokumentacionin operacional, etj. Gjatë ekzekutimit të programit, mund të zbulohet një defekt ose dështim.
Dështimi (dështimi) është një devijim i programit nga funksionimi ose pamundësia e programit për të kryer funksionet e përcaktuara nga kërkesat dhe kufizimet, që konsiderohet si një ngjarje që kontribuon në kalimin e programit në një gjendje jofunksionale për shkak të gabimeve. , defekte të fshehura në të ose dështime në mjedisin funksional. Dështimi mund të jetë rezultat i arsyeve të mëposhtme:
Një specifikim i gabuar ose një kërkesë e lënë pas dore, që do të thotë se specifikimi nuk pasqyron me saktësi atë që përdoruesi synonte;
Specifikimi mund të përmbajë një kërkesë që nuk mund të përmbushet në harduerin dhe softuerin e dhënë;
Dizajni i programit mund të përmbajë gabime (për shembull, baza e të dhënave është projektuar pa mjete mbrojtëse kundër aksesit të paautorizuar të përdoruesit, por kërkohet mbrojtje);
Programi mund të jetë i pasaktë, d.m.th. ai kryen një algoritëm të pazakontë ose nuk është zbatuar plotësisht.
konkluzioni
GOST-të ruse në lidhje me verifikimin dhe testimin e softuerit janë përkthime të standardeve "borgjeze" si ISO 12207, ANSI/IEEE-729-83 dhe të tjera (ka shumë prej tyre). Problemi është se këto standarde ndërkombëtare i trajtojnë ndryshe çështjet e testimit dhe verifikimit. Për të mos thënë se ato kundërshtojnë plotësisht njëra-tjetrën, por mund të shkaktojnë hutim.
Të gjitha këto standarde u formuluan në vitet 80 të shekullit të kaluar për industrinë hapësinore të SHBA. Në vitet në vijim, ato u korrigjuan dhe u ribotuan, por mosmarrëveshjet dhe kontradiktat në dokumente mbetën.
Përfundim: struktura e verifikimit, vlefshmërisë dhe metodave të testimit duhet të perceptohet si e kushtëzuar.
Bibliografi
1. Enciklopedi e lirë wikipedia.org
2. Kulyamin V.V. Metodat e verifikimit të softuerit M.: Instituti për Programimin e Sistemit, 2008
3. Lavrishcheva E., Petrukhin V. Leksion "Metodat për kontrollimin dhe testimin e programeve dhe sistemeve": NOU "INTUIT" http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130
Organizuar në Allbest.ru
...Dokumente të ngjashme
Cikli jetësor i softuerit është një proces i vazhdueshëm që fillon me një vendim për nevojën e krijimit të softuerit dhe përfundon me tërheqjen e plotë të tij nga funksionimi. Qasja e Riley, Lehman dhe Boehm për përkufizimin e ciklit jetësor të softuerit.
abstrakt, shtuar 01/11/2009
Koncepti i teknologjisë së zhvillimit të programit. Baza e dizajnit të softuerit. Modelet e ciklit jetësor që u ngritën historikisht gjatë zhvillimit të teorisë së dizajnit të softuerit. Modele spirale (spiral), kaskadë dhe përsëritëse.
prezantim, shtuar 05/11/2015
Historia e zhvillimit dhe llojet e testimit të softuerit. Instalimi, regresioni, konfigurimi, integrimi, lokalizimi, testimi i njësisë. Metodat për reduktimin e kompleksitetit të testimit të njësive të aplikacionit të zhvilluar.
punim afatshkurtër, shtuar 16.12.2015
Pazgjidhshmëria e problemit të testimit të softuerit. Llojet dhe nivelet e testimit. Strategjitë e testimit në rrjedhën e sipërme dhe të poshtme. Metodat e kutisë "të bardhë" dhe "të zezë". Testim i automatizuar dhe manual. Zhvillimi përmes testimit.
punim afatshkurtër, shtuar 22.03.2015
Kërkesat për teknologjinë e projektimit të softuerit (SW). Përbërja dhe përshkrimi i fazave të ciklit të plotë të jetës së softuerit. Klasifikimi i modeleve të ciklit jetësor të softuerit, veçoritë e tyre. Metodologjitë e zhvillimit të softuerit, teknikat ekstreme të programimit.
prezantim, shtuar 19.09.2016
Historia e testimit të softuerit, qëllimet kryesore dhe veçoritë e zbatimit të tij. Llojet dhe llojet e testimit, nivelet e automatizimit të tij. Përdorimi dhe kërkimi teknologjitë e nevojshme. Cikli i plotë drejtimin e të gjithë sistemit të monitorimit.
tezë, shtuar 05.03.2018
Standardet kryesore ndërkombëtare në këtë fushë teknologjitë e informacionit. standard ndërkombëtar ISO/IEC 9126 Cilësia dhe cikli i jetës. Karakterizimi i atributeve të brendshme dhe të jashtme të cilësisë. Analiza e funksionalitetit të softuerit.
raport, shtuar 13.06.2017
Qëllimet dhe objektivat e inxhinierisë softuerike. Koncepti i softuerit. Gjashtë parime përdorim efektiv software. Llojet e softuerit: në të gjithë sistemin, rrjet dhe të aplikuar. Parimet e ndërtimit të softuerit.
punim afatshkurtër, shtuar 29.06.2010
Karakteristikat e përgjithshme të modeleve kryesore të ciklit jetësor: kaskadë, inkrementale, spirale. Një fazë si pjesë e procesit të zhvillimit të softuerit, e kufizuar në një kornizë kohore specifike dhe që përfundon me lëshimin e një produkti specifik.
prezantim, shtuar 27.12.2013
Informatizimi i Rusisë. Tregu mjete softuerike. Detyrat kryesore të standardizimit, certifikimit dhe licencimit në fushën e informatizimit. Një grup metodash dhe mjetesh inxhinierike për krijimin e softuerit. Cikli i jetës së softuerit.
Verifikimi dhe vlefshmëria i referohet proceseve të verifikimit dhe rishikimit që verifikojnë që softueri është në përputhje me specifikimet e tij dhe kërkesat e klientit. Verifikimi dhe vërtetimi mbulojnë ciklin e plotë të jetës së softuerit - ato fillojnë në fazën e analizës së kërkesave dhe përfundojnë me verifikimin e kodit të programit në fazën e testimit të sistemit të softuerit të përfunduar.
Verifikimi dhe vërtetimi nuk janë e njëjta gjë, megjithëse është e lehtë t'i ngatërroni ato. Shkurtimisht, ndryshimi midis tyre mund të përcaktohet si më poshtë:
Verifikimi i përgjigjet pyetjes nëse sistemi është projektuar siç duhet;
Certifikimi i përgjigjet pyetjes nëse sistemi funksionon si duhet.
Sipas këtyre përkufizimeve, verifikimi kontrollon nëse softueri është në përputhje me specifikimet e sistemit, në veçanti kërkesat funksionale dhe jofunksionale. Certifikimi është një proces më i përgjithshëm. Gjatë vërtetimit, duhet të siguroheni që produkti softuer përmbush pritshmëritë e klientit. Verifikimi kryhet pas verifikimit për të përcaktuar se si sistemi përmbush jo vetëm specifikimet, por edhe pritshmëritë e klientit.
Siç u përmend më herët, vërtetimi i kërkesave të sistemit është shumë i rëndësishëm në fazat e hershme të zhvillimit të softuerit. Shpesh ka gabime dhe lëshime në kërkesat; në raste të tilla, produkti përfundimtar ndoshta nuk do të përmbushë pritshmëritë e klientit. Por, sigurisht, vërtetimi i kërkesave nuk mund të zbulojë të gjitha problemet në specifikimin e kërkesave. Ndonjëherë boshllëqet dhe gabimet në kërkesat zbulohen vetëm pasi të përfundojë implementimi i sistemit.
Proceset e verifikimit dhe të vërtetimit përdorin dy teknika kryesore për kontrollimin dhe analizimin e sistemeve.
1. Inspektimi i softuerit. Analiza dhe verifikimi i paraqitjeve të ndryshme të sistemit, si dokumentacioni i specifikimeve të kërkesave, diagramet arkitekturore ose kodi burimor i programit. Inspektimi kryhet në të gjitha fazat e procesit të zhvillimit të sistemit softuerik. Paralelisht me inspektimin, mund të kryhet analiza automatike e kodit burimor të programeve dhe dokumenteve përkatëse. Inspektimi dhe analiza e automatizuar janë metoda statike të verifikimit dhe vërtetimit sepse nuk kërkojnë një sistem të ekzekutueshëm.
2. Testimi i softuerit. Ekzekutimi i kodit të ekzekutueshëm me të dhënat e testimit dhe ekzaminimi i prodhimit dhe performancës së produktit softuer për të verifikuar që sistemi po funksionon siç duhet. Testimi është një metodë dinamike verifikimi dhe vlefshmërie sepse aplikohet në sistemin që funksionon.
Në fig. Figura 20.1 tregon vendin e inspektimit dhe testimit në procesin e zhvillimit të softuerit. Shigjetat tregojnë fazat në procesin e zhvillimit ku mund të zbatohen këto metoda. Sipas kësaj skeme, inspektimi mund të kryhet në të gjitha fazat e procesit të zhvillimit të sistemit, dhe testimi - kur krijohet një prototip ose program i ekzekutueshëm.
Metodat e inspektimit përfshijnë: inspektimin e programit, analizën automatike të kodit burimor dhe verifikimin formal. Por metodat statike mund të kontrollojnë vetëm konformitetin e programeve me specifikimet; ato nuk mund të përdoren për të kontrolluar funksionimin e saktë të sistemit. Përveç kësaj, karakteristikat jofunksionale si performanca dhe besueshmëria nuk mund të testohen me metoda statike. Prandaj, për të vlerësuar karakteristikat jofunksionale, kryhet testimi i sistemit.
Oriz. 20.1. Verifikimi dhe vërtetimi statik dhe dinamik
Pavarësisht përdorimit të gjerë të inspektimit të softuerit, testimi është ende metoda mbizotëruese e verifikimit dhe certifikimit. Testimi është një verifikim i funksionimit të programeve me të dhëna të ngjashme me ato reale, të cilat do të përpunohen gjatë funksionimit të sistemit. Prania në program e defekteve dhe mospërputhjeve me kërkesat zbulohet duke ekzaminuar të dhënat dalëse dhe duke identifikuar ato anormale midis tyre. Testimi kryhet gjatë fazës së zbatimit të sistemit (për të verifikuar nëse sistemi përmbush pritshmëritë e zhvilluesve) dhe pasi të ketë përfunduar zbatimi i tij.
Lloje të ndryshme testimi përdoren në faza të ndryshme të procesit të zhvillimit të softuerit.
1. Testimi i defekteve kryhet për të zbuluar mospërputhjet midis programit dhe specifikimeve të tij, të cilat janë për shkak të gabimeve ose defekteve në programe. Teste të tilla janë krijuar për të zbuluar gabimet në sistem dhe jo për të simuluar funksionimin e tij.
2. Testimi Statistikor vlerëson performancën dhe besueshmërinë e programeve, si dhe funksionimin e sistemit në mënyra të ndryshme funksionimi. Testet janë krijuar për të imituar funksionimin aktual të sistemit me të dhëna hyrëse reale. Besueshmëria e sistemit vlerësohet nga numri i dështimeve të shënuara në punën e programeve. Performanca vlerësohet duke matur kohën totale të funksionimit dhe kohën e përgjigjes së sistemit gjatë përpunimit të të dhënave të testit.
objektivi kryesor Verifikimi dhe kualifikimi - për të siguruar që sistemi është "i përshtatshëm për qëllimin". Përshtatshmëria e një sistemi softuerik për qëllimin e tij të synuar nuk nënkupton që ai duhet të jetë absolutisht pa gabime. Përkundrazi, sistemi duhet të jetë mjaft i përshtatshëm për qëllimet për të cilat është menduar. E detyrueshme vlefshmëria e pajtueshmërisë varet nga qëllimi i sistemit, pritjet e përdoruesve dhe kushtet e tregut për produktet softuerike.
1. Qëllimi i softuerit. Niveli i besueshmërisë së pajtueshmërisë varet nga sa kritik është softueri i zhvilluar sipas kritereve të caktuara. Për shembull, niveli i besimit për sistemet kritike për sigurinë duhet të jetë dukshëm më i lartë se ai për prototipet e sistemeve softuerike që po zhvillohen për të demonstruar ndonjë ide të re.
2. Pritjet e përdoruesve. Duhet të theksohet me pikëllim se aktualisht, shumica e përdoruesve kanë kërkesa të ulëta për softuer. Përdoruesit janë mësuar aq shumë me dështimet që ndodhin gjatë ekzekutimit të programeve, saqë nuk habiten nga kjo. Ata janë të gatshëm të tolerojnë dështimet e sistemit nëse përfitimet e përdorimit të tij tejkalojnë të metat. Megjithatë, që nga fillimi i viteve 1990, toleranca e përdoruesve për dështimet në sistemet softuerike ka ardhur gradualisht në rënie. Kohët e fundit, krijimi i sistemeve jo të besueshme është bërë pothuajse i papranueshëm, kështu që kompanitë e zhvillimit të softuerit duhet t'i kushtojnë gjithnjë e më shumë vëmendje verifikimit dhe vërtetimit të softuerit.
3. Kushtet e tregut të softuerit. Kur vlerëson një sistem softuerësh, shitësi duhet të njohë sistemet konkurruese, çmimin që blerësi është i gatshëm të paguajë për sistemin dhe kohën e pritur për në treg për atë sistem. Nëse kompania e zhvillimit ka disa konkurrentë, është e nevojshme të përcaktohet data e hyrjes së sistemit në treg përpara përfundimit të testimit dhe korrigjimit të plotë, përndryshe konkurrentët mund të jenë të parët që do të hyjnë në treg. Nëse klientët nuk janë të gatshëm të blejnë softuer me një çmim të lartë, ata mund të jenë të gatshëm të tolerojnë më shumë dështime të sistemit. Gjatë përcaktimit të kostove të procesit të verifikimit dhe kualifikimit, duhet të merren parasysh të gjithë këta faktorë.
Si rregull, gabimet gjenden në sistem gjatë verifikimit dhe vërtetimit. Ndryshimet bëhen në sistem për të korrigjuar gabimet. Kjo procesi i korrigjimit zakonisht integrohen me procese të tjera verifikimi dhe vërtetimi. Sidoqoftë, testimi (ose më në përgjithësi, verifikimi dhe vlefshmëria) dhe korrigjimi janë procese të ndryshme që kanë qëllime të ndryshme.
1. Verifikimi dhe vërtetimi është procesi i zbulimit të defekteve në një sistem softuerik.
2. Debugging - procesi i lokalizimit të defekteve (gabimeve) dhe rregullimit të tyre (Fig. 20.2).
Oriz. 20.2. Procesi i korrigjimit
Nuk ka metoda të thjeshta për korrigjimin e programeve. Korrigjuesit me përvojë gjejnë gabime duke krahasuar modelet e daljes së provës me daljen e sistemeve nën provë. Për të gjetur një gabim kërkon njohuri për llojet e gabimeve, modelet e daljes, gjuhën e programimit dhe procesin e programimit. Njohja e procesit të zhvillimit të softuerit është shumë e rëndësishme. Korrigjuesit janë të vetëdijshëm për gabimet më të zakonshme të programimit (siç është rritja e një numëruesi). Ai gjithashtu merr parasysh gabimet që janë tipike për disa gjuhë programimi, për shembull, ato që lidhen me përdorimin e treguesve në gjuhën C.
Gjetja e gabimeve në kodin e programit nuk është gjithmonë një proces i thjeshtë, sepse defekti nuk është domosdoshmërisht i vendosur afër pikës në kodin e programit ku ndodhi përplasja. Për të izoluar gabimet, korrigjuesi zhvillon teste shtesë të softuerit që ndihmojnë në identifikimin e burimit të gabimit në program. Mund t'ju duhet të gjurmoni manualisht ekzekutimin e programit.
Mjetet ndërvepruese të korrigjimit janë pjesë e një grupi mjetesh mbështetëse gjuhësore që janë të integruara me sistemin e përpilimit të kodit. Ato ofrojnë një mjedis të veçantë të ekzekutimit të programit përmes të cilit mund të qaseni në tabelën e identifikuesve dhe prej andej në vlerat e variablave. Përdoruesit shpesh kontrollojnë ekzekutimin e një programi në një mënyrë hap pas hapi, duke kaluar nga deklarata në deklaratë në rend. Pas ekzekutimit të çdo deklarate, kontrollohen vlerat e variablave dhe identifikohen gabimet e mundshme.
Gabimi i gjetur në program korrigjohet, pas së cilës është e nevojshme të kontrolloni përsëri programin. Për ta bërë këtë, mund të riinspektoni programin ose të përsërisni testin e mëparshëm. Ritestimi përdoret për t'u siguruar që ndryshimet e bëra në program nuk sjellin gabime të reja në sistem, sepse në praktikë një përqindje e lartë e "rregullimeve të gabimeve" ose nuk plotësohen plotësisht ose futin gabime të reja në program.
Në parim, është e nevojshme të kryhen përsëri të gjitha testet gjatë ritestimit pas çdo rregullimi, por në praktikë, kjo qasje është shumë e shtrenjtë. Prandaj, gjatë planifikimit të procesit të testimit, përcaktohen varësitë midis pjesëve të sistemit dhe caktohen teste për secilën pjesë. Më pas është e mundur të gjurmohen elementët e programit duke përdorur raste të veçanta testimi (të dhëna kontrolli) të zgjedhura për këto elemente. Nëse rezultatet e gjurmës dokumentohen, atëherë vetëm një nëngrup i grupit total të të dhënave të testimit mund të përdoret për të testuar elementin e ndryshuar të programit dhe komponentët e tij të varur.
Planifikimi për verifikim dhe vërtetim
Verifikimi dhe vërtetimi është një proces i shtrenjtë. Për sisteme të mëdha, të tilla si sistemet në kohë reale me kufizime komplekse jofunksionale, gjysma e buxhetit të zhvillimit të sistemit shpenzohet në procesin e verifikimit dhe vlefshmërisë. Prandaj, nevoja për planifikim të kujdesshëm të këtij procesi është e dukshme.
Planifikimi për verifikim dhe vlefshmëri, si pjesë e zhvillimit të sistemeve softuerike, duhet të fillojë sa më shpejt që të jetë e mundur. Në fig. Figura 20.3 tregon një model të zhvillimit të softuerit që merr parasysh procesin e planifikimit të testit. Këtu fillon planifikimi që në fazat e specifikimit dhe të projektimit të sistemit. Ky model nganjëherë referohet si modeli V (për të parë V-në, rrotullojeni figurën 20.3 me 90°). Ky diagram tregon edhe ndarjen e procesit të verifikimit dhe vërtetimit në disa faza, me testet përkatëse të kryera në çdo fazë.
Oriz. 20.3. Planifikimi i testit gjatë zhvillimit dhe testimit
Në procesin e planifikimit të verifikimit dhe certifikimit, është e nevojshme të përcaktohet marrëdhënia midis metodave statike dhe dinamike për kontrollin e sistemit, të përcaktohen standardet dhe procedurat për inspektimin dhe testimin e softuerit, të miratohen harta teknologjike rishikoni softuerin (shih seksionin 19.2) dhe zhvilloni një plan testimi të softuerit. Nëse inspektimi apo testimi është më i rëndësishëm varet nga lloji i sistemit që po zhvillohet dhe përvoja e organizatës. Sa më kritik të jetë sistemi, aq më shumë vëmendje duhet t'i kushtohet metodave të verifikimit statik.
Plani i verifikimit dhe vërtetimit fokusohet në standardet e procesit të testimit në vend që të përshkruajë teste specifike. Ky plan nuk është vetëm për udhëzim, por është menduar kryesisht për profesionistët e zhvillimit dhe testimit të sistemit. Plani i mundëson stafit teknik të marrë një pamje të plotë të testeve të sistemit dhe të planifikojë punën e tyre në këtë kontekst. Përveç kësaj, plani ofron informacion për menaxherët që janë përgjegjës për të siguruar që ekipi i testimit të ketë të gjithë harduerin dhe softuerin e nevojshëm.
Plani i testimit nuk është një dokument fiks. Duhet të rishikohet rregullisht pasi testimi varet nga procesi i zbatimit të sistemit. Për shembull, nëse zbatimi i një pjese të sistemit nuk ka përfunduar, atëherë është e pamundur të testohet montimi i sistemit. Prandaj, plani duhet të rishikohet periodikisht në mënyrë që stafi testues të mund të përdoret në punë të tjera.
Dy konceptet e vërtetimit dhe verifikimit shpesh ngatërrohen. Për më tepër, vërtetimi i kërkesave të sistemit shpesh ngatërrohet me vërtetimin e sistemit. Unë sugjeroj ta shqyrtojmë këtë çështje.
Në artikull, kam konsideruar dy qasje për modelimin e objekteve: si një e tërë dhe si një strukturë. Në artikullin aktual, do të na duhet kjo ndarje.
Supozoni se kemi një objekt funksional të projektuar. Ky objekt le të konsiderohet prej nesh si pjesë e ndërtimit të një objekti tjetër funksional. Le të ketë një përshkrim të ndërtimit të Objektit, i tillë që të përmbajë një përshkrim të objektit. Në një përshkrim të tillë, objekti ka një përshkrim në tërësi, domethënë ndërfaqet e tij të ndërveprimit me objektet e tjera përshkruhen brenda kornizës së ndërtimit të Objektit. Le të jepet përshkrimi i objektit si strukturë. Le të ketë një objekt informacioni që përmban kërkesa për hartimin e përshkrimit të objektit si strukturë. Le të ketë një grup njohurish që përmban rregulla konkluzionesh, në bazë të të cilave një përshkrim i objektit si strukturë merret nga përshkrimi i objektit në tërësi. Trupi i njohurive është ajo që dizajnerëve u mësohet në institute - shumë, shumë njohuri. Ato lejojnë, në bazë të njohurive për objektin, të hartojnë strukturën e tij.
Pra, mund të filloni. Mund të pohojmë se nëse objekti në tërësi përshkruhet saktë, nëse trupi i njohurive është i saktë dhe nëse respektohen rregullat e konkluzionit, atëherë përshkrimi që rezulton i ndërtimit të objektit do të jetë i saktë. Kjo është, në bazë të këtij përshkrimi, një objekt funksional që korrespondon me kushte reale operacion. Cilat rreziqe mund të lindin:
1. Përdorimi i njohurive të pasakta për Objektin. Modeli i Objektit në mendjet e njerëzve mund të mos korrespondojë me realitetin. Ata nuk e dinin rrezikun e vërtetë të tërmeteve, për shembull. Prandaj, kërkesat për objektin mund të jenë të formuluara gabimisht.
2. Regjistrim jo i plotë i njohurive për Objektin - diçka mungon, bëhen gabime. Për shembull, ata dinin për erërat, por harruan ta përmendnin. Kjo mund të çojë në një përshkrim të pamjaftueshëm të plotë të kërkesave për objektin.
3. Njohuri e gabuar. Na mësuan përparësinë e masës ndaj parametrave të tjerë, por doli që duhej të rrisnim shpejtësinë.
4. Zbatimi i gabuar i rregullave të konkluzionit në përshkrimin e objektit. Gabime logjike, diçka mungon në kërkesat për projektimin e objektit, gjurma e kërkesave është prishur.
5. Regjistrim jo i plotë i konkluzioneve të marra rreth projektimit të sistemit. Gjithçka është marrë parasysh, gjithçka është llogaritur, por kanë harruar të shkruajnë.
6. Sistemi i krijuar nuk përputhet me përshkrimin.
Është e qartë se të gjitha artefaktet e projektit shfaqen, si rregull, në formën e tyre të përfunduar vetëm deri në fund të projektit, dhe madje edhe atëherë jo gjithmonë. Por, nëse supozojmë se zhvillimi është ujëvarë, atëherë rreziqet janë siç përshkrova. Kontrollimi i çdo rreziku është një operacion specifik që mund t'i jepet një emër. Nëse dikush është i interesuar, mund të përpiqeni të gjeni dhe shprehni këto kushte.
Çfarë është verifikimi? Në rusisht, verifikimi është një kontroll për pajtueshmërinë me rregullat. Rregullat janë në formën e një dokumenti. Kjo do të thotë, duhet të ketë një dokument me kërkesat e dokumentacionit. Nëse dokumentacioni plotëson kërkesat e këtij dokumenti, atëherë ai ka kaluar verifikimin.
Çfarë është vërtetimi? Në rusisht, vërtetimi është verifikimi i saktësisë së përfundimeve. Kjo do të thotë, duhet të ketë një grup njohurish që përshkruan se si të merrni një përshkrim të një dizajni bazuar në të dhënat e objektit. Kontrollimi i korrektësisë së zbatimit të këtyre përfundimeve është vërtetim. Vërtetimi është, ndër të tjera, kontrollimi i përshkrimit për qëndrueshmëri, plotësi dhe kuptueshmëri.
Shpesh, vërtetimi i kërkesave ngatërrohet me vërtetimin e një produkti të ndërtuar mbi këto kërkesa. Nuk ia vlen ta bësh këtë.
