Testimine valge kast

Kasutatavuse testimine

A) Koormustestimine

Jõudluskatsed

Funktsionaalne testimine

Testimine tarkvara

Testimine on programmi (või programmi osa) käivitamise protsess, mille eesmärk (või eesmärk) on leida vigu.

Testimistüüpide klassifitseerimisel on tavaks mitu kriteeriumi. Tavaliselt eristatakse järgmisi märke:

I) Vastavalt testimise objektile:

(tarkvara- ja riistvarasüsteemi või seadme jõudluse ja reaktsiooniaja näitajate määramine või kogumine vastusena välisele päringule, et teha kindlaks vastavus selle süsteemi nõuetele)

b) stressitestid

(hindab süsteemi töökindlust ja stabiilsust normaalse töö piire ületavates tingimustes.)

c) Stabiilsuse testimine

4) Kasutajaliidese testimine

5) Turvatestimine

6) lokaliseerimise testimine

7) Ühilduvuse testimine

II) Süsteemi tundmise kaudu:

1) Musta kasti testimine

(testimisel on objekt, mille sisemine struktuur on teadmata)

(kontrollitakse programmi sisestruktuuri, testandmed saadakse programmiloogikat analüüsides)

III) Automatiseerituse astme järgi:

1) Käsitsi testimine

2) Automatiseeritud testimine

3) Poolautomaatne testimine

IV) Vastavalt komponentide isolatsiooniastmele:

1) Komponentide (ühikute) testimine

2) Integratsiooni testimine

3) Süsteemi testimine

V) Testimise ajaks:

1) Alfa testimine- programmi testimise suletud protsess täiskohaga arendajate või testijate poolt. Alfatoode on enamasti vaid 50% valmis, programmikood on olemas, kuid oluline osa disainist on puudu.

2) Beetatestimine- tugev kasutamine valmis versioon programmid, et teha kindlaks maksimaalne vigade arv oma töös nende hilisemaks kõrvaldamiseks enne lõplikku turuletulekut massitarbijale. Testimisse on kaasatud vabatahtlikud tavaliste tulevaste kasutajate hulgast.

Tarkvara kontrollimine on üldisem mõiste kui testimine. Verifitseerimise eesmärk on saavutada kindlus, et kontrollitav objekt (nõuded või programmikood) vastab nõuetele, on realiseeritud ilma soovimatute funktsioonideta ning vastab proja standarditele ( ISO 9000-2000). Kontrolliprotsess hõlmab ülevaatusi, koodide testimist, testitulemuste analüüsi, probleemiaruannete genereerimist ja analüüsi. Seega on üldiselt aktsepteeritud, et testimisprotsess on lahutamatu osa kontrollimise protsess.

Peterburi

Riiklik Elektrotehnikaülikool

MOEM osakond

distsipliini järgi

"Tarkvara arendusprotsess"

"Tarkvara kinnitamine"

Peterburi

Kontrollimise eesmärk…………………………………………………………………… lk 3

Sissejuhatavad märkused………………………………………………………………….. lk 3

Eri- ja üldeesmärgid…………………………………………….. lk 4

Eeldatav praktika eesmärkide järgi………………………………………… lk 4

SG1 Ettevalmistus kontrollimiseks……………………………………………………… lk 4

SG2 Eksamite läbiviimine (vastastikune hindamine)………………………… lk 7

SG3 Kontrollimise rakendamine…………………………………………………… lk 9

Lisa 1. Ülevaade kontrolliprotsessi automatiseerimisvahenditest……….. lk 11

Lisa 2. Põhi kaasaegsed lähenemised kontrollimiseks…………….. lk 12

Kasutatud kirjanduse loetelu…………………………………………………….. lk 14

Tipptaseme ja küpsuse integreeritud mudel

Kinnitamine (3. küpsusaste)

Sihtmärk

Kontrollimise eesmärk on tagades, et valitud vahevara või lõpptoode vastab määratud nõuetele.

1. vee noodid

Tarkvaratoodete kontrollimine on valmistoote või selle vaheversioonide kontrollimine esialgsetele nõuetele vastama. See tähendab mitte ainult programmi enda testimist, vaid ka projekti, kasutaja- ja tehnilise dokumentatsiooni jne auditeerimist.

Tarkvarasüsteemi verifitseerimise eesmärk on tuvastada ja teavitada vigu, mis võivad tekkida elutsükli etappides. Kontrollimise peamised ülesanded:

kõrgetasemeliste nõuete süsteeminõuetele vastavuse määramine;

süsteemi arhitektuuri kõrgetasemeliste nõuete arvestamine;

vastavus arhitektuurile ja sellele esitatavatele nõuetele lähtekoodis;

käivitatava koodi süsteemi nõuetele vastavuse määramine;

ülaltoodud ülesannete lahendamiseks kasutatavate vahendite kindlaksmääramine, mis on tehniliselt korrektsed ja piisavalt täielikud.

Kontrollimine hõlmab valmistoodete kontrollimist ja vahetoodete vastavust kõikidele valitud nõuetele, sealhulgas klientide nõudmistele, valmistoodetele esitatavatele nõuetele ja selle üksikutele komponentidele esitatavatele nõuetele.

Kontrollimine on oma olemuselt järkjärguline (inkrementaalne) protsess alates selle loomise hetkest kogu toodete arendamise ja kogu toodetega seotud töö vältel. Kontrollimine algab nõuete kontrollimisega, seejärel järgneb kõikide vahetoodete kontrollimine nende arendamise ja valmistamise eri etappides ning lõpeb lõpptoote kontrollimisega.

Vahetoodete kontrollimine nende arendamise ja valmistamise igas etapis suurendab oluliselt tõenäosust, et lõpptoode vastab kliendi nõuetele, valmistootele esitatavatele nõuetele ja selle üksikutele komponentidele esitatavatele nõuetele.

Protsesside kontrollimine ja valideerimine on oma olemuselt seotud protsessid, mille eesmärk on siiski saada erinevaid tulemusi. Valideerimise eesmärk on näidata, et valmistoode tegelikult täidab oma esialgset eesmärki. Kontrollimise eesmärk on veenduda, et toode vastab täpselt teatud nõuetele. Teisisõnu tagab kinnitamine, et " sa teed seda õigesti" ja kinnitamine on see, et " sa teed õiget asja”.

Kontrollimine tuleks asjakohastes protsessides (nt tarnimine, arendus, käitamine või hooldus) võimalikult varakult rakendada, et hinnata kulutõhusust ja toimivust. See protsess võib hõlmata analüüsi, kontrollimist ja testimist (testimist).

Seda protsessi saab läbi viia esinejate erineva sõltumatuse astmega. Esinejate sõltumatuse aste võib jaguneda nii organisatsiooni enda erinevate üksuste kui ka mõne teise organisatsiooni üksuste vahel, kusjuures vastutuse jaotus on erinev. Seda protsessi nimetatakse protsessiks sõltumatu kontrollimine kui rakendusorganisatsioon on müüjast, arendajast, operaatorist või hooldajast sõltumatu.

Eksperthinnangud (asjatundlikkus) on kontrollimise oluline osa, kuna see on väljakujunenud tööriist defektide tõhusaks kõrvaldamiseks. Oluliseks väljavõtteks sellest on vajadus arendada sügavamat arusaamist ja arusaamist toote tööversioonidest, samuti töövoogudest, mida kasutatakse võimalike defektide tuvastamiseks ja vajaduse korral võimaluse loomiseks parendusteks.

Ekspertiis hõlmab ekspertide tehtud töö metoodilist uurimist, et tuvastada defekte ja muid vajalikke muudatusi.

Peamised eksperthinnangu meetodid on:

ülevaatus

otsast lõpuni struktuurikontroll

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 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äreldusreegleid, 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.

meeskonda kuulub rohkem kui kaks inimest, tekitab paratamatult küsimuse rollide, õiguste ja kohustuste jaotusest meeskonnas. Konkreetse rollide komplekti määravad paljud tegurid – arenduses osalejate arv ja nende isiklikud eelistused, vastuvõetud arendusmetoodika, projekti omadused ja muud tegurid. Peaaegu igas arendusmeeskonnas saab eristada järgmisi rolle. Mõned neist võivad täiesti puududa, samas kui üksikud inimesed võivad täita mitut rolli korraga, kuid üldine koosseis muutub vähe.

Klient (taotleja). See roll kuulub süsteemi arendamise tellinud organisatsiooni esindajale. Tavaliselt on taotleja suhtlemine piiratud ja suhtleb ainult projektijuhtide ja sertifitseerimis- või rakendusspetsialistiga. Tavaliselt on kliendil õigus muuta tootele esitatavaid nõudeid (ainult koostöös juhtidega), tutvuda projekteerimise ja sertifitseerimise dokumentatsiooniga, mis mõjutab arendatava süsteemi mittetehnilisi omadusi.

Projektijuht. See roll loob suhtluskanali kliendi ja projektimeeskonna vahel. Tootejuht juhib kliendi ootusi ning arendab ja hoiab projekti ärikonteksti. Tema töö ei ole otseselt seotud müügiga, ta on keskendunud tootele, tema ülesanne on defineerida ja pakkuda kliendi nõuded. Projektijuhil on õigus muuta tootele esitatavaid nõudeid ja tootele esitatavat lõppdokumentatsiooni.

Programmijuht. See roll juhib suhtlust ja suhteid projektimeeskonna sees, tegutseb mingil moel koordinaatorina, töötab välja ja haldab funktsionaalseid spetsifikatsioone, haldab projekti ajakava ja annab aru projekti oleku kohta ning algatab projekti jaoks kriitilisi otsuseid.

Testimine- programmi käivitamise protsess vea tuvastamiseks.

katseandmed- sisendid, mida kasutatakse süsteemi testimiseks.

Katseolukord (testjuhtum)- sisendid süsteemi testimiseks ja eeldatavad väljundid olenevalt sisenditest, kui süsteem töötab vastavalt nõuete spetsifikatsioonile.

Hea testjuhtum- olukord, kus on suur tõenäosus avastada veel avastamata viga.

õnne test- test, mis tuvastab veel avastamata vea.

Viga- programmeerija tegevus arendusetapis, mis toob kaasa asjaolu, et tarkvara sisaldab sisemist defekti, mis võib programmi töö ajal põhjustada vale tulemuse.

Keeldumine- süsteemi ettearvamatu käitumine, mis viib ootamatu tulemuseni, mis võib olla põhjustatud selles sisalduvatest defektidest.

Seega kontrollitakse tarkvara testimise käigus reeglina järgmist.

Kontrollimine ja kinnitamine ( kontrollimine ja kinnitamine-V& v) on loodud selleks, et analüüsida, kontrollida tarkvara õiget toimimist ja vastavust kliendi spetsifikatsioonidele ja nõuetele. Need programmide ja süsteemide õigsuse kontrollimise meetodid tähendavad:

• verifitseerimine on süsteemi loomise õigsuse kontrollimine vastavalt selle spetsifikatsioonile;
• Valideerimine on süsteemile määratud nõuete täitmise õigsuse kontrollimine.

Kontrollimine aitab teha järelduse loodud süsteemi õigsuse kohta pärast selle projekteerimise ja arendamise lõpetamist. Valideerimine võimaldab teil kindlaks teha kindlaksmääratud nõuete teostatavuse ja sisaldab mitmeid toiminguid õigete programmide ja süsteemide hankimiseks, nimelt:

• inspekteerimis- ja kontrolliprotseduuride kavandamine disainilahendused ja nõuded;
• programmide kavandamise automatiseerimise taseme tagamine CASE-vahenditega;
• programmide korrektse toimimise kontrollimine sihttestide komplektide testimismeetoditega;
• toote kohandamine töökeskkonnaga jne.

Valideerimine teostab neid tegevusi, vaadates läbi ja kontrollides spetsifikatsioone ja projekteerimisväljundeid olelusringi etappides, et kinnitada, et esialgsed nõuded on õigesti rakendatud ning et kindlaksmääratud tingimused ja piirangud on täidetud. Verifitseerimise ja valideerimise ülesannete hulka kuulub nõuete spetsifikatsiooni täielikkuse, järjepidevuse ja ühemõttelisuse ning süsteemi funktsioonide täitmise õigsuse kontrollimine.

Kontrollimine ja kinnitamine toimub järgmistel juhtudel:

• süsteemi põhikomponendid;
• komponentide liidesed (tarkvara, tehnilised ja informatiivsed) ja objektide interaktsioonid (protokollid ja sõnumid), mis tagavad süsteemi teostuse hajutatud keskkondades;
• juurdepääsuvahendid andmebaasile ja failidele (tehingud ja sõnumid) ning kaitsevahendite kontrollimine erinevate kasutajate andmetele volitamata juurdepääsu eest;
• tarkvara ja süsteemi kui terviku dokumentatsioon;
• testid, katseprotseduurid ja sisendandmed.

Teisisõnu on programmi korrektsuse peamised süstemaatilised meetodid järgmised:

• kontrollimine PS komponentide ja nõuete spetsifikatsiooni valideerimine;
• PS ülevaatus teha kindlaks programmi vastavus etteantud spetsifikatsioonidele;
• testimine PS-i väljundkood testandmetel konkreetses töökeskkonnas, et tuvastada erinevatest vigadest, kõrvalekalletest, seadmete riketest või süsteemi krahhidest põhjustatud vigu ja defekte (vt 9. peatükk).

ISO/IEC 3918-99 ja 12207 hõlmavad verifitseerimis- ja valideerimisprotsesse. Nende jaoks määratletakse eesmärgid, ülesanded ja tegevused, et kontrollida loodud toote (sh töö-, vahetoodete) õigsust elutsükli etappidel ja vastavust selle nõuetele.

Verifitseerimis- ja valideerimisprotsesside põhiülesanne on kontrollige ja kinnitage et lõplik tarkvara on otstarbekohane ja rahuldab kliendi nõudmisi. Need protsessid võimaldavad tuvastada vigu elutsükli etappide töötoodetes, ilma nende esinemise põhjuseid välja selgitamata, samuti teha kindlaks tarkvara õigsus selle spetsifikatsiooni suhtes.

Need protsessid on omavahel seotud ja on määratletud ühe terminiga – "verification and validation" (V&V 7).

Kontrollimine toimub:

• üksikute komponentide väljundkoodiks tõlkimise õigsuse kontrollimine, samuti liideste kirjeldused, jälgides komponentide seoseid vastavalt kliendi määratud nõuetele;
• failidele või andmebaasile juurdepääsu õigsuse analüüs, võttes arvesse andmetega manipuleerimiseks ja tulemuste edastamiseks kasutatavates süsteemivahendites kasutatavaid protseduure;
• komponentide kaitsevahendite kontrollimine kliendi nõuetele vastavuse tagamiseks ja nende jälgimine.

Pärast süsteemi üksikute komponentide kontrollimist viiakse läbi nende integreerimine, samuti integreeritud süsteemi kontrollimine ja valideerimine. Süsteemi testitakse paljude testikomplektidega, et teha kindlaks, kas testikomplektid on testi lõpuleviimiseks ja süsteemi õigsuse kindlakstegemiseks piisavad ja piisavad.

Idee luua rahvusvaheline projekt ametliku kontrollimise kohta pakkus välja T. Hoare, seda arutati 2005. aasta veebruaris Californias verifitseeritud tarkvara sümpoosionil. Seejärel, sama aasta oktoobris, Zürichis toimunud IFIP konverentsil võeti 15-aastaseks perioodiks vastu rahvusvaheline projekt, mille eesmärk oli töötada välja "terviklik automatiseeritud tööriistade komplekt PS-i õigsuse kontrollimiseks".

See sõnastas järgmised peamised ülesanded:

• ühtse konstrueerimise teooria väljatöötamine ja programmide analüüs;
• tervikliku integreeritud kontrollitööriistade komplekti loomine kõigi tootmisetappide jaoks, sealhulgas spetsifikatsioonide väljatöötamine ja nende kontrollimine, testjuhtumite genereerimine, programmide täiustamine, analüüs ja kontrollimine;
• formaalsete spetsifikatsioonide ja kontrollitud tarkvaraobjektide hoidla loomine erinevad tüübid ja tüübid.

See projekt eeldab, et kontrollimine hõlmab kõiki tarkvara loomise ja õigsuse kontrollimise aspekte ning sellest saab imerohi kõikidele probleemidele, mis on seotud pidevate vigade esinemisega loodavas programmis.

Praktikas on testitud paljusid ametlikke meetodeid konkreetsete programmide tõestamiseks ja kontrollimiseks. Valmis suur töö rahvusvahelise komitee ISO/IEC raames ISO standard/ IEC 12207:2002 tarkvara verifitseerimis- ja valideerimisprotsesside standardimise kohta. Erinevate programmeerimisobjektide õigsuse kontrollimine formaalsete meetodite abil on paljulubav.

Repositoorium on programmide, spetsifikatsioonide ja tööriistade hoidla, mida kasutatakse väljatöötamisel ja testimisel, valmis komponentide, tööriistade ja meetodite toorikute hindamisel. Sellel on järgmised üldised ülesanded:

• kontrollitud spetsifikatsioonide, tõestusmeetodite, programmiobjektide ja koodirakenduste kogumine keeruliste rakenduste jaoks;
• erinevate kontrollimeetodite akumuleerimine, nende kujundamine realiseeritud teoreetilise idee otsimiseks ja edasiseks rakendamiseks väljavalimiseks sobival kujul;
• tüüpvormide väljatöötamine erinevate programmeerimisobjektide formaalsete spetsifikatsioonide, samuti tööriistade ja valmissüsteemide seadmiseks ja vahetamiseks;
• koostalitlusvõime ja interaktsioonimehhanismide arendamine kontrollitud valmistoodete hoidlast uutesse hajutatud ja võrgukeskkondadesse ülekandmiseks, et luua uusi PS-sid.

See projekt peaks välja töötama 50 aasta jooksul. Varasemad projektid on seadnud sarnased eesmärgid: tarkvara kvaliteedi parandamine, teenindusmudelite vormistamine, keerukuse vähendamine PIC-ide kasutamise kaudu, silumistööriistade loomine vigade visuaalseks diagnoosimiseks ja nende kõrvaldamiseks jne. Samas pole ka programmeerimises toimunud põhimõttelist muutust selles mõttes, et visuaalne silumine või saavutamine Kõrge kvaliteet PEAL. Arendusprotsess jätkub.

Uus rahvusvaheline tarkvara verifitseerimisprojekt eeldab osalejatelt mitte ainult teadmisi teoreetilised aspektid programmi spetsifikatsioonid, aga ka kõrgelt kvalifitseeritud programmeerijad selle rakendamiseks lähiaastatel.