Testimi i integrimit. Zhvillimi i një produkti softuerik për kalimin e testeve

Shënim: Leksioni është i dyti nga tre që mbulojnë nivelet e procesit të verifikimit. Tema e kësaj leksioni është procesi i testimit të integrimit, detyrat dhe qëllimet e tij. Janë marrë parasysh aspektet organizative të testimit të integrimit - klasifikimet strukturore dhe kohore të metodave të testimit të integrimit, planifikimi i testimit të integrimit. Qëllimi i kësaj leksioni: të japë një ide mbi procesin e testimit të integrimit, komponentët e tij teknikë dhe organizativë

20.1. Objektivat dhe qëllimet e testimit të integrimit

Rezultati i testimit dhe verifikimit të moduleve individuale që përbëjnë sistemin e softuerit duhet të jetë një përfundim se këto module janë në përputhje të brendshme dhe në përputhje me kërkesat. Sidoqoftë, modulet individuale rrallë funksionojnë më vete, kështu që detyra tjetër pas testimit të moduleve individuale është testimi i ndërveprimit të saktë të disa moduleve të kombinuara në një tërësi të vetme. Ky lloj testimi quhet integrimin. Qëllimi i tij është të sigurojë korrektësinë bashkëpunimi komponenti i sistemit.

Testimi i integrimit quajtur edhe testimi i arkitekturës së sistemit. Nga njëra anë, ky emër është për shkak të faktit se testet e integrimit përfshijnë kontrolle të të gjitha llojeve të mundshme të ndërveprimeve midis moduleve të softuerit dhe elementeve që përcaktohen në arkitekturën e sistemit - kështu, testet e integrimit kontrollojnë plotësinë ndërveprimet në zbatimin e sistemit që testohen. Nga ana tjetër, rezultatet e testeve të integrimit janë një nga burimet kryesore të informacionit për procesin e përmirësimit dhe qartësimit të arkitekturës së sistemit, ndërfaqeve ndërmodule dhe ndërkomponente. Kjo është, nga ky këndvështrim, testet e integrimit kontrollojnë korrektësi ndërveprimi i komponentëve të sistemit.

Një shembull i kontrollit të korrektësisë së ndërveprimit mund të jenë dy module, njëra prej të cilave grumbullon mesazhe protokolli në lidhje me skedarët e marrë, dhe e dyta shfaq këtë protokoll në ekran. Kërkesat funksionale për sistemin thonë se mesazhet duhet të shfaqen në rend të kundërt kronologjik. Megjithatë, moduli i ruajtjes së mesazheve i ruan ato në rend të drejtpërdrejtë dhe moduli i daljes përdor pirgun për të nxjerrë rend i kundërt. Testet e njësisë që prekin secilin modul individualisht nuk do të kenë asnjë efekt këtu - situata e kundërt është mjaft e mundshme, në të cilën mesazhet ruhen në rend të kundërt dhe dalin duke përdorur një radhë. Një problem i mundshëm mund të zbulohet vetëm duke kontrolluar ndërveprimin e moduleve duke përdorur testet e integrimit. Pika kryesore këtu është se sistemi në tërësi nxjerr mesazhe në rend kronologjik të kundërt, d.m.th., duke kontrolluar modulin e daljes dhe duke gjetur se ai nxjerr mesazhe në rendin përpara, ne nuk mund të garantojmë se kemi zbuluar një defekt.

Si rezultat i kryerjes së testimit të integrimit dhe eliminimit të të gjitha defekteve të identifikuara, fitohet një arkitekturë konsistente dhe holistike e sistemit softuer, d.m.th. mund të supozojmë se testimin e integrimit po teston arkitekturën dhe kërkesat funksionale të nivelit të ulët.

Testimi i integrimit, si rregull, është një proces përsëritës në të cilin testohet funksionaliteti i një grupi modulesh gjithnjë e më në rritje.

20.2. Organizimi i testimit të integrimit

20.2.1. Klasifikimi strukturor i metodave të testimit të integrimit

Si rregull, testimi i integrimit kryhet pas përfundimit të testimit të njësisë për të gjitha modulet e integruara. Megjithatë, kjo nuk është gjithmonë rasti. Ekzistojnë disa metoda për kryerjen e testimit të integrimit:

• testimi nga poshtë-lart;
• testim monolit;
• testimi nga lart-poshtë.

Të gjitha këto teknika mbështeten në njohuritë e arkitekturës së sistemit, e cila shpesh përshkruhet si diagrame strukturash ose diagrame të thirrjes së funksionit. Çdo nyje në një diagram të tillë përfaqëson një modul softuerësh, dhe shigjetat ndërmjet tyre përfaqësojnë varësinë e thirrjeve ndërmjet moduleve. Dallimi kryesor midis teknikave të testimit të integrimit është drejtimi i lëvizjes përgjatë këtyre diagrameve dhe gjerësia e mbulimit për përsëritje.

Testimi nga poshtë lart. Kur përdoret kjo metodë, nënkuptohet që të gjitha modulet e softuerit të përfshirë në sistem fillimisht testohen dhe vetëm atëherë kombinohen për testimin e integrimit. Me këtë qasje, lokalizimi i gabimeve thjeshtohet shumë: nëse modulet testohen veçmas, atëherë një gabim kur ato punojnë së bashku është një problem me ndërfaqen e tyre. Me këtë qasje, zona e kërkimit të testuesit për probleme është mjaft e ngushtë, dhe për këtë arsye probabiliteti për të identifikuar saktë një defekt është shumë më i lartë.

Oriz. 20.1.

Megjithatë, metodë nga poshtë-lart testimi ka një pengesë domethënëse - nevojën për të zhvilluar një drejtues dhe cung për testimin e njësisë përpara se të kryeni testimin e integrimit dhe nevojën për të zhvilluar një drejtues dhe cung për testimin e integrimit të një pjese të moduleve të sistemit (Fig. 20.1)

Nga njëra anë ka drejtues dhe priza - mjet i fuqishëm testimi, nga ana tjetër, zhvillimi i tyre kërkon burime të konsiderueshme, veçanërisht kur përbërja e moduleve të integruara ndryshon, me fjalë të tjera, një grup drejtuesish mund të kërkohet për testimin e njësive të secilit modul, një drejtues të veçantë dhe cung për testimin e integrimit. nga dy module nga grupi, një i veçantë për testimin e integrimit të tre moduleve, etj. Kjo është kryesisht për shkak të faktit se integrimi i modulit eliminon nevojën për disa cung, dhe gjithashtu kërkon një ndryshim të drejtuesit që mbështet teste të reja që prekin module të shumta.

Testimi monolit sugjeron që komponentët individualë të sistemit nuk i janë nënshtruar testimeve serioze. Avantazhi kryesor këtë metodë- nuk ka nevojë për të zhvilluar një mjedis testimi, drejtues dhe cung. Pasi të jenë zhvilluar të gjitha modulet, kryhet integrimi i tyre, pastaj testohet sistemi në tërësi. Kjo qasje nuk duhet të ngatërrohet me testimin e sistemit, i cili është subjekt i leksionit të ardhshëm. Përkundër faktit se testimi monolit do të kontrollojë funksionimin e të gjithë sistemit në tërësi, detyra kryesore e këtij testimi është të identifikojë problemet me ndërveprimin e moduleve individuale të sistemit. Detyra e testimit të sistemit është të vlerësojë cilësinë dhe karakteristikat sasiore sistemet për sa i përket pranueshmërisë së tyre nga përdoruesi përfundimtar.

Testimi monolit ka një sërë disavantazhesh serioze.

• Është shumë e vështirë të identifikohet burimi i gabimit (identifikimi i kodit të gabuar). Shumica e moduleve duhet të supozojnë se ka një gabim. Problemi ka të bëjë me përcaktimin se cili nga gabimet në të gjitha modulet e përfshira çoi në rezultat. Kjo mund të sjellë efekte gabimi. Përveç kësaj, një gabim në një modul mund të bllokojë testimin e një tjetri.
• Është e vështirë të organizosh rregullime të gabimeve. Si rezultat i testimit, testuesi regjistron problemin e gjetur. Defekti në sistem që shkaktoi këtë problem do të rregullohet nga zhvilluesi. Meqenëse, si rregull, modulet në testim shkruhen njerëz të ndryshëm, lind një problem - cili prej tyre është përgjegjës për gjetjen dhe eliminimin e defektit? Me një "përgjegjësi kolektive" të tillë, shpejtësia e eliminimit të defekteve mund të bjerë ndjeshëm.
• Procesi i testimit është i automatizuar dobët. Avantazhi (pa shtesë software që shoqëron procesin e testimit) rezulton të jetë një disavantazh. Çdo ndryshim i bërë kërkon përsëritjen e të gjitha testeve.

Testimi nga lart-poshtë supozon se procesi i testimit të integrimit ndjek zhvillimin. Së pari, testohet vetëm niveli më i lartë i kontrollit të sistemit, pa më shumë module nivel të ulët. Më pas, gradualisht, ato të nivelit më të ulët integrohen me modulet e nivelit më të lartë. Si rezultat i përdorimit të kësaj metode, nuk ka nevojë për drejtues (roli i drejtuesit kryhet nga një modul sistemi i nivelit më të lartë), por nevoja për cungë mbetet (Fig. 20.2).

Ekspertë të ndryshëm të testimit kanë mendime të ndryshme se cila metodë është më e përshtatshme për testimin real të sistemeve softuerike. Jordan e argumenton këtë testimi nga lart-poshtë më e pranueshme në situata reale, dhe Myers beson se çdo qasje ka avantazhet dhe disavantazhet e veta, por në përgjithësi metoda nga poshtë-lart është më e mirë.

Literatura shpesh përmend një metodë të testimit të integrimit të sistemeve softuerike të orientuara nga objekti, e cila bazohet në identifikimin e grupeve të klasave që së bashku kanë një funksion të mbyllur dhe të plotë. Në thelb, kjo qasje nuk është një lloj i ri i testimit të integrimit, ai thjesht ndryshon elementin minimal që rezulton nga integrimi. Kur integroni module në gjuhët e programimit procedural, mund të integroni çdo numër modulesh, me kusht që të zhvillohen cungët. Kur integrohen klasa në grupe, ekziston një kufizim mjaft i lirë në plotësinë e funksionalitetit të grupimit. Megjithatë, edhe në rastin e sistemeve të orientuara nga objekti, është e mundur të integrohen çdo numër klasash duke përdorur klasa cung.

Pavarësisht nga metoda e përdorur e testimit të integrimit, është e nevojshme të merret parasysh shkalla e mbulimit të funksionalitetit të sistemit nga testet e integrimit. Punimi propozoi një metodë për vlerësimin e shkallës së mbulimit bazuar në thirrjet e kontrollit ndërmjet funksioneve dhe flukseve të të dhënave. Me këtë vlerësim, kodi i të gjitha moduleve në diagramin e strukturës së sistemit duhet të ekzekutohet (të gjitha nyjet duhet të mbulohen), të gjitha thirrjet duhet të ekzekutohen të paktën një herë (të gjitha lidhjet ndërmjet nyjeve në diagramin e strukturës duhet të mbulohen), të gjitha sekuencat e thirrjeve duhet të ekzekutohet të paktën një herë (të gjitha shtigjet në diagramin e strukturës duhet të mbulohen).

Asnjë zhvillim i softuerit nuk është i plotë pa testuar kodin e ekzekutueshëm. Në fakt, ajo merr gjysmën e kohës totale të zhvillimit dhe më shumë se gjysmën e kostos së projektit. Megjithatë, kjo është një pjesë integrale e procesit të krijimit të aplikacioneve, programeve dhe sistemeve të reja.

Testimi i integrimit si pjesë e një pune të madhe

Një nga mënyrat për të kontrolluar cilësinë e softuerit është testimi i integrimit, inputi i të cilit merret nga modulet individuale të testuara në fazën e mëparshme.

Ndryshe nga opsioni modular, i cili identifikon gabimet e lokalizuara në çdo funksion ose klasë individuale, testimi i integrimit është kërkimi i defekteve që lidhen me zbatimin e ndërveprimit midis në pjesë të veçanta produkt i krijuar. Testimi funksional i integrimit përdor metodën e "kutisë së bardhë", domethënë, inxhinieri i cilësisë ka akses dhe njohuri për tekstet e secilit modul individual, si dhe parimet e ndërveprimit midis tyre.

Metodat e montimit të moduleve

Metoda monolitike do të thotë që të gjitha modulet që do t'i nënshtrohen testimit të integrimit në të ardhmen, mblidhen së bashku në të njëjtën kohë. Situatat pothuajse me siguri lindin kur një pjesë e kompleksit në provë nuk është ende gati.

Në këtë rast, ai zëvendësohet me "cung" ose drejtues të zhvilluar shtesë.

Së bashku me metodën monolitike, ekziston një metodë rritëse (quhet gjithashtu hap pas hapi), pasi vëllimi i kodit nën provë rritet gradualisht, duke bërë të mundur lokalizimin e zonave me defekte në marrëdhëniet midis pjesëve individuale.

Metoda inkrementale përfshin dy mënyra për të shtuar module:

• nga lart-poshtë ose në ngjitje,
• nga poshtë-lart - në zbritje.

Karakteristikat e testimit monolit dhe në rritje

Disavantazhi kryesor i llojit monolit të montimit është numër i madh koha dhe kostot e punës shpenzohen për simulimin e pjesëve që mungojnë të kompleksit të testuar. Duket se cungët janë një mjet testimi mjaft i përshtatshëm, por situatat lindin kur në proces është e nevojshme të rikrijohen pjesë të simuluara të programit. Për shembull, nëse përbërja e moduleve të testuara ndryshon. Për më tepër, efikasiteti i gjetjes së defekteve nuk është aq i lartë kur puna nuk është me një produkt të vërtetë, por vetëm me një komponent fiktive. E njëjta pengesë shoqëron gjithashtu testimin në rritje me një metodë ndërtimi nga poshtë-lart.

Në të njëjtën kohë, një nga disavantazhet metodë hap pas hapiështë nevoja për të organizuar dhe krijuar një mjedis për ekzekutimin e moduleve në një sekuencë të caktuar. Është gjithashtu praktikisht e pamundur të zhvillohen paralelisht nivelet e sipërme dhe të poshtme.

Natyrisht, të dyja metodat e montimit, monolit dhe rritës, kanë jo vetëm disavantazhe, por edhe avantazhe. Në rastin e parë, ekzistojnë mundësi të shkëlqyera për zhvillimin paralel të të gjitha klasave dhe funksioneve të përfshira në testim, si në faza fillestare, dhe pas modifikimit. Metoda hap pas hapi është më pak punë intensive: modulet shtohen gradualisht, dhe gabimet dhe defektet gjithashtu zbulohen gradualisht. Kjo dihet se zvogëlon kohën e shpenzuar për kërkimin e tyre.

Përfitimet e Testimit të Integrimit

Në këtë fazë, një punë kolosale kryhet për të kontrolluar marrëdhëniet e të gjitha niveleve, pa të cilat, natyrisht, testimi i mëtejshëm është i pamundur.

Testimi i integrimit të softuerit ka një sërë përparësish:

• kontrollimi i ndërfaqes së ndërveprimit ndërmjet moduleve individuale të programit;
• kontrolli i marrëdhënieve midis zgjidhjeve softuerike komplekse të testuara dhe të palëve të treta;
• testimi i funksionimit të përbërësve të jashtëm të zgjidhjes;
• kontrollin e përputhshmërisë së dokumentacionit të projektit në lidhje me ndërveprimin e moduleve individuale.

Korrigjimi i defekteve

Testimi i integrimit është i plotë, por kjo nuk është e gjitha. Gabimet e gjetura regjistrohen dhe dërgohen te zhvilluesi për korrigjim, pas së cilës procesi fillon përsëri.

Së pari, është e nevojshme të kontrollohet nëse defektet e identifikuara janë eliminuar. Së dyti, kur kodi burim u ndryshua, mund të lindin gabime të reja në funksionimin e programit dhe ndërveprimin me softuerin e palëve të treta.

Edhe pse tani ka një numër të madh metodash të kontrollit të cilësisë, ka ende shumë rol të rëndësishëm testimi i integrimit luan një rol. Një shembull i këtij lloji verifikimi mund të tregojë qartë pengesat në zhvillimin dhe dokumentacionin e softuerit.

Testoni automatizimin

Në varësi të vëllimit kompleks origjinal mund të lindin të dhënat dhe fusha lëndore e zhvillimit, problemi i kohës së testimit dhe kompleksiteti i ngjarjes në tërësi.

Për më së shumti verifikimi efektiv zhvillimi duhet të përdoret sasi e madhe futni të dhëna dhe kushte, të cilat është e pamundur të përballohen "me dorë". Për të zgjidhur këtë problem përdoret automatizimi i testimit. Ashtu si llojet e tjera, testimi i integrimit gjithashtu mund të automatizohet. Kjo do të reduktojë kohën e përgjithshme të zhvillimit dhe gjithashtu do të rrisë efikasitetin e procesit të zbulimit të gabimeve.

Sidoqoftë, testimi i automatizimit nuk mund të zëvendësojë plotësisht punën e një inxhinieri cilësor, por vetëm ta plotësojë atë.

Pra, testimi i integrimit është një pjesë integrale e zhvillimit të çdo softueri dhe një nga fazat e të gjithë procesit të kontrollit të cilësisë së produktit. Si çdo metodë, ajo ka një sërë avantazhesh dhe disavantazhesh, por pa përdorimin e saj, zhvillimi i softuerit me cilësi të lartë bëhet i pamundur.

Përkthimi: Anna Radionova

Ka shumë lloje të testeve të softuerit. Praktikat BDD mund të aplikohen në çdo aspekt të testimit, por kornizat BDD nuk përdoren në të gjitha llojet e testeve. Skriptet e sjelljes janë në thelb funksionale testet - ata kontrollojnë që produkti që testohet funksionon saktë. Mjetet mund të përdoren për testimin e performancës, ndërsa kornizat BDD nuk janë krijuar për këtë qëllim. Qëllimi i këtij artikulli është kryesisht të përshkruajë rolin e automatizimit BDD në Piramidën e Testimit. Lexoni artikullin BDD 101: Testimi manual për të kuptuar se si përdoret BDD në testimin manual. (Të gjitha informacionet mbi BDD mund të gjenden në faqen Automation Panda BDD)

Piramida e testimit

Megjithatë, Praktikat BDD mund të aplikohen në testet e njësive.Çdo test njësi duhet të fokusohet në komponentin kryesor: një thirrje, një variacion i vetëm, një kombinim i caktuar i hyrjes; në sjellje.Në zhvillimin e mëtejshëm, specifikimi i sjelljes së veçorive ndan qartë testet e njësisë nga testet e më shumë nivel të lartë. Zhvilluesi i veçorive është gjithashtu përgjegjës për shkrimin e testeve të njësisë, ndërsa një inxhinier tjetër është përgjegjës për integrimin dhe testet nga fundi në fund. Specifikimi i sjelljes është një lloj marrëveshjeje zotëri që testet e njësive do të jenë një entitet i veçantë.

Integrimi dhe testimi nga fundi në fund

Kornizat e testimit BDD manifestohen më qartë në nivelet e integrimit dhe testimit nga fundi në fund.

Specifikimet e sjelljes përshkruajnë qartë dhe në mënyrë koncize se për çfarë synohet saktësisht rasti i testimit. Hapat mund të shkruhen në nivelin e integrimit ose nga fundi në fund. Testet e shërbimit mund të shkruhen duke përdorur specifikimet e sjelljes, si në Karate. Testet nga fundi në fund janë në fakt teste të integrimit me shumë hapa. Ju lutemi vini re shembulli tjetër, e cila, në pamje të parë, duket modeli bazë ndërveprimi me përdoruesin, por, në fakt, është një test i madh nga fundi në fund:

E dhënë një përdorues është regjistruar në faqen e mediave sociale
Kur përdoruesi shkruan një postim të ri
Pastaj burimi kryesor i përdoruesit shfaq postimin e ri
Dhe burimet e shtëpisë së të gjithë miqve shfaqin postimin e ri

Publikim i lehtë për rrjeti social përfshin proceset e ndërveprimit me ndërfaqen, thirrjet për shërbimet mbështetëse dhe bërjen e ndryshimeve në bazën e të dhënave në kohë reale. Të përshkruara rrugë të plotë duke kaluar nëpër sistem. Hapat e automatizuar mund t'i mbulojnë këto nivele në mënyrë të qartë ose të nënkuptuar, por ato mbulohen patjetër nga testi.

Teste të gjata nga fundi në fund

Termat shpesh kuptohen ndryshe nga njerëz të ndryshëm. Kur njerëzit thonë "teste nga fundi në fund", ata nënkuptojnë teste të gjata, të njëpasnjëshme: testet që mbulojnë sjellje të ndryshme produktet njëra pas tjetrës. Kjo deklaratë i bën adhuruesit e BDD-së të dridhen, sepse bie ndesh me rregullin bazë të BDD: një skenar, një sjellje. Sigurisht, duke përdorur kornizat BDD ju mund të krijoni teste të gjata nga fundi në fund, por ju duhet të mendoni me kujdes nëse dhe si ta bëni këtë.

Ekzistojnë pesë parime themelore për shkrimin e skripteve afatgjata nga fundi në fund në BDD:

1. Nuk ka nevojë të shqetësoheni për këtë. Nëse procesi BDD është konfiguruar saktë, atëherë çdo sjellje individuale tashmë mbulohet plotësisht nga skenarët e testimit. Çdo skript duhet të mbulojë të gjitha klasat ekuivalente të të dhënave hyrëse dhe dalëse. Kështu, skriptet e gjata nga fundi në fund do të jenë kryesisht dyfishim i mbulimit të testit. Në vend që të humbni kohë në zhvillim, është më mirë të braktisni automatizimin e skripteve të gjata nga fundi në fund, si ato që nuk japin shumë vlerë dhe të shpenzoni më shumë kohë në testimin manual dhe eksplorues.
2. Bashkoni skriptet ekzistuese në të reja. Çdo çift Kur-Atëherë përfaqëson sjellje individuale. Hapat nga skriptet ekzistuese mund të ripërcaktohen në skriptet e tjera dhe kërkojnë vetëm rifaktorim të vogël. Kjo thyen praktikat e mira të Gherkinit dhe mund të rezultojë në skriptet që funksionojnë gjatë, por është mënyra më praktike për të ripërdorur hapat për skriptet e gjera nga fundi në fund. Shumica e kornizave BDD nuk mbështesin rendit hap pas hapi, dhe nëse mbështetet, atëherë hapat duhet të rishkruhen që kodi të funksionojë. (Kjo qasje është më praktike, por më pak tradicionale.)
3. Ndërtoni kontrollet në hapat Given dhe Kur. Kjo strategji shmang dyfishimin e çifteve When-Then dhe siguron që kontrollet të kryhen. Korrektësia e çdo hapi kontrollohet gjatë gjithë procesit duke përdorur tekstin Gherkin. Megjithatë, mund të kërkohen një sërë hapash të rinj.
4. Trajtoni një sekuencë sjelljesh si sjellje unike, individuale.. Kjo mënyra më e mirë duke menduar për skenarë afatgjatë nga fundi në fund, sepse rrit të menduarit e sjelljes. Një skenar afatgjatë është i vlefshëm vetëm nëse konsiderohet si sjellje unike. Skenari duhet të shkruhet për të theksuar këtë veçanti. Përndryshe, ky nuk është një skenar që ia vlen të përdoret. Skriptet e tilla shpesh janë deklarative dhe të nivelit të lartë.
5. Mos përdorni korniza BDD dhe shkruani teste ekskluzivisht duke përdorur mjete automatizimi. Gherkin është krijuar për të mundësuar bashkëpunimin e sjelljes, ndërsa testet e gjata nga fundi në fund zgjidhin çështjet e intensitetit të punës së cilësisë së cilësisë. Një biznes mund të ofrojë specifikime të sjelljes, por kurrë nuk do të shkruajë teste nga fundi në fund. Rishkrimi i specifikimeve të sjelljes në skriptet e gjata nga fundi në fund mund të bllokojë zhvillimin. shumë zgjidhja më e mirëështë bashkëjetesa: testet e pranimit mund të shkruhen duke përdorur Gherkin, dhe testet e gjata nga fundi në fund mund të shkruhen duke përdorur mjete programimi. Të dy grupet e testeve mund të automatizohen duke përdorur të njëjtën bazë kodi, ato mund të kenë të njëjtat module mbështetëse dhe madje metoda për përcaktimin e hapave.

Zgjidhni qasjen që i përshtatet më së miri ekipit tuaj.

Nga pikëpamja teknologjike, testimi i integrimit është një zhvillim sasior i testimit të njësive, pasi, si testimi i njësive, ai operon në ndërfaqet e moduleve dhe nënsistemeve dhe kërkon krijimin e një mjedisi testimi, duke përfshirë Stubs në vend të moduleve që mungojnë. Dallimi kryesor midis modularit dhe testimin e integrimit përbëhet nga qëllimet, domethënë llojet e defekteve që do të zbulohen, të cilat, nga ana tjetër, përcaktojnë strategjinë për zgjedhjen e të dhënave hyrëse dhe metodat e analizës. Në veçanti, në nivelin e testimit të integrimit, teknikat që lidhen me mbulimin e ndërfaqeve, të tilla si thirrjet e funksioneve ose metodave, ose analizimi i përdorimit të objekteve të ndërfaqes, si p.sh. burimet globale, mjetet e komunikimit të ofruara sistemi operativ.

Problemi zgjidhet me metodën testimin e integrimit, - testimi i lidhjeve intermodulare të zbatuara gjatë ekzekutimit të softuerit të testimit të kompleksit K përdor një model "kuti të bardhë" në nivel modular. Meqenëse testuesi e njeh tekstin e programit në detaje përpara se të thërrasë të gjitha modulet e përfshira në kompleksin nën testim, përdorimi i kritereve strukturore në këtë fazë është i mundur dhe i justifikuar.

Testimi i integrimit përdoret në fazën e montimit të moduleve të testuara nga njësia në një kompleks të vetëm. Ekzistojnë dy metoda të njohura për montimin e moduleve:
monolit, e karakterizuar nga integrimi i njëkohshëm i të gjitha moduleve në një kompleks të testuar
Rritëse, e karakterizuar nga një ndërtim hap pas hapi (modul pas modul) i një grupi programesh me testim hap pas hapi të kompleksit të montuar. Në metodën rritëse, ekzistojnë dy strategji për shtimin e moduleve:
o Testimi nga lart-poshtë dhe përkatës nga poshtë-lart.
o Testimi "nga poshtë lart" dhe, në përputhje me rrethanat, nga lart-poshtë.

Veçoritë testim monolit janë si më poshtë: për të zëvendësuar modulet që nuk janë zhvilluar në kohën e testimit, me përjashtim të atij më të lartë, është e nevojshme të zhvillohen shtesë drejtues (drivers testues) dhe/ose cung (cung), duke zëvendësuar modulet e niveleve më të ulëta që mungonin. në momentin e seancës së testimit.

Një krahasim i qasjeve monolitike dhe integrale jep sa vijon:
Testimi monolit kërkon shumë punë lidhur me zhvillimin shtesë të drejtuesve dhe cungëve dhe vështirësinë e identifikimit të gabimeve që shfaqen në hapësirën e kodit të mbledhur.
Testimi hap pas hapi shoqërohet me më pak mundim në identifikimin e gabimeve për shkak të një rritje graduale të vëllimit të kodit të testuar dhe, në përputhje me rrethanat, lokalizimit të zonës së shtuar të kodit të testuar.
Testimi monolit ofron mundësi të mëdha paralelizimi i punës, veçanërisht në fazën fillestare të testimit.

Veçoritë testimi nga lart-poshtë janë si më poshtë: organizimi i një mjedisi për radhën e ekzekutueshme të thirrjeve nga modulet e testuara të moduleve të testuara, zhvillimi dhe përdorimi i vazhdueshëm i cungëve, organizimi i testimit prioritar të moduleve që përmbajnë operacione shkëmbimi me mjedisin, ose module kritike për algoritmin që testohet.

Të metat testimi nga lart-poshtë:
Problemi i zhvillimit të cungjeve mjaft "inteligjente", d.m.th. cungë të aftë për t'u përdorur kur simulojnë mënyra të ndryshme funksionimi të kompleksit të kërkuar për testim
Kompleksiteti i organizimit dhe zhvillimit të një mjedisi për zbatimin e ekzekutimit të moduleve në sekuencën e kërkuar
Zhvillimi paralel i moduleve të niveleve të larta dhe të ulëta çon në zbatimin jo gjithmonë efektiv të moduleve për shkak të përshtatjes (specializimit) të moduleve ende të patestuara të niveleve më të ulëta në modulet tashmë të testuara të niveleve të sipërme.

Të metat testimi nga poshtë-lart:
Vonesa në kontrollimin e veçorive konceptuale të kompleksit të testuar
Nevoja për të zhvilluar dhe përdorur drejtuesit

Karakteristikat e testimit të integrimit për programimin procedural

Procesi i ndërtimit të një grupi testesh gjatë testimit strukturor përcaktohet nga parimi mbi të cilin bazohet ndërtimi i Grafikut të Modelit të Programit (GMP). Kjo përcakton grupin e shtigjeve të provës dhe gjenerimin e testeve që korrespondojnë me shtigjet e provës.

Qasja e parë për zhvillimin e softuerit është programimi procedural (modular). Programimi tradicional procedural përfshin shkrimin e kodit burimor në një stil imperativ, i cili përshkruan një sekuencë të caktuar të ekzekutimit të komandës, si dhe përshkrimin e një projekti softuerësh duke përdorur dekompozim funksional. Gjuhët si Pascal dhe C janë të domosdoshme. Në to, rendi i linjave burimore të kodit përcakton rendin në të cilin transferohet kontrolli, duke përfshirë ekzekutimin vijues, zgjedhjen e kushteve dhe ekzekutimin e përsëritur të seksioneve të programit. Çdo modul ka disa pika hyrjeje (nëse kodi është shkruar rreptësisht - një) dhe disa pika daljeje (nëse kodi është shkruar rreptësisht - një). Projektet komplekse softuerike kanë një strukturë hierarkike modulare dhe testimi i moduleve është hapi fillestar i procesit të testimit të softuerit. Ndërtimi i një modeli grafik të një moduli është një detyrë e parëndësishme dhe testimi kryhet pothuajse gjithmonë sipas kriterit të mbulimit të degës C1, d.m.th. çdo hark dhe çdo kulm i grafikut të modulit duhet të përfshihet në të paktën një nga shtigjet e testimit.

Klasat dhe llojet e testeve.

Ekzistojnë dy klasa kryesore të testeve: tradicionale Dhe jo tradicionale.

Testi ka përbërjen, integriteti Dhe strukturën. Ai përbëhet nga:

• detyrat;
• rregullat për zbatimin e tyre;
• notat për kryerjen e çdo detyre;
• rekomandime për interpretimin e rezultateve të testit.

Testoni integritetin nënkupton marrëdhënien e detyrave, përkatësinë e tyre në një faktor të përbashkët të matur. Çdo detyrë testuese përmbush rolin e saj të caktuar dhe për këtë arsye asnjëra prej tyre nuk mund të hiqet nga testi pa humbur cilësinë e matjes.

Struktura e testit formon një mënyrë për të lidhur detyrat me njëra-tjetrën. Në thelb, kjo është e ashtuquajtura struktura e faktorit, në të cilën çdo detyrë lidhet me të tjerat nëpërmjet përmbajtjen e përgjithshme dhe variacioni i përgjithshëm i rezultateve të testit.

Një test tradicional është një unitet i të paktën tre sistemeve:

• një sistem kuptimplotë njohurish i përshkruar në gjuhën e disiplinës akademike që testohet;
• një sistem zyrtar detyrash me vështirësi në rritje;
• karakteristikat statistikore detyrat dhe rezultatet e testimit.

Testi tradicional pedagogjik duhet parë në dy mënyra domethënëse: si metodë e matjes pedagogjike dhe si rezultat i aplikimit të testit.

ato st është një sistem detyrash që formojnë integritetin më të mirë metodologjik. Integriteti i testit është ndërveprimi i qëndrueshëm i detyrave që formojnë testin si një sistem në zhvillim.

Testet homogjene

Testet tradicionale përfshijnë teste homogjene Dhe heterogjene.

Test homogjen përfaqëson një sistem detyrash me vështirësi në rritje, formë specifike dhe përmbajtje specifike - një sistem i krijuar për qëllime objektive, cilësore, dhe metodë efektive vlerësimin e strukturës dhe matjen e nivelit të gatishmërisë së studentëve në një disiplinë akademike.

Testet homogjene janë më të zakonshme se të tjerat. Në pedagogji, ato janë krijuar për të kontrolluar njohuritë në një disiplinë akademike ose në një seksion të tillë, për shembull, një disiplinë akademike voluminoze si fizika. Në një test pedagogjik homogjen, nuk lejohet përdorimi i detyrave që zbulojnë veti të tjera. Prania e kësaj të fundit cenon kërkesën e pastërtisë disiplinore të testit pedagogjik. Në fund të fundit, çdo test mat diçka të paracaktuar.

Testet heterogjene

Test heterogjen përfaqëson një sistem detyrash me vështirësi në rritje, formë specifike dhe përmbajtje specifike - një sistem i krijuar me qëllim të një metode objektive, cilësore dhe efektive për vlerësimin e strukturës dhe matjen e nivelit të gatishmërisë së studentëve në disa disiplina akademike..

Shpesh teste të tilla përfshijnë gjithashtu detyra psikologjike për të vlerësuar nivelin e zhvillimit intelektual.

Në mënyrë tipike, testet heterogjene përdoren për një vlerësim gjithëpërfshirës të të diplomuarve në shkollë, vlerësimin e personalitetit kur aplikoni për një vend pune dhe për zgjedhjen e aplikantëve më të përgatitur për pranim në universitete. Meqenëse çdo test heterogjen përbëhet nga teste homogjene, interpretimi i rezultateve të testit kryhet bazuar në përgjigjet e detyrave të secilit test (këtu quhen shkallë) dhe, përveç kësaj, përmes metoda të ndryshme grumbullimi i pikëve bëhen përpjekje për të dhënë vlerësimi i përgjithshëm gatishmëria e subjektit të testimit.

Interpretimi i rezultateve të testimit kryhet kryesisht në gjuhën e testologjisë, bazuar në mesataren aritmetike, modalitetin ose medianën dhe në të ashtuquajturat norma të përqindjes, duke treguar se sa përqind kanë testuesit. rezultati i testit më keq se çdo lëndë e marrë për analizë me rezultatin e tij të testit. Ky interpretim quhet me orientim normativ.

Testet integruese

Integruese mund të quhet një test i përbërë nga sistemet e detyrave që plotësojnë kërkesat e përmbajtjes integruese, formës së testit, vështirësisë në rritje të detyrave që synojnë një diagnozë përfundimtare të përgjithësuar të gatishmërisë së një të diplomuari të një institucioni arsimor.

Diagnostifikimi kryhet duke paraqitur detyra të tilla, përgjigjet e sakta për të cilat kërkojnë njohuri të integruara (të përgjithësuara, të ndërlidhura qartë) në fushën e dy dhe më shumë disiplinat akademike. Krijimi i testeve të tilla u jepet vetëm atyre mësuesve që kanë njohuri për një sërë disiplinash akademike, kuptojnë rolin e rëndësishëm të lidhjeve ndërdisiplinore në të nxënit dhe janë në gjendje të krijojnë detyra, përgjigjet e sakta për të cilat kërkojnë që nxënësit të kenë njohuri të ndryshme. disiplinat dhe aftësinë për të zbatuar njohuri të tilla.

Testimi integrues paraprihet nga organizimi të mësuarit integrues. Fatkeqësisht, forma aktuale e mbajtjes së orëve mësimore, e kombinuar me fragmentimin e tepërt të disiplinave akademike, së bashku me traditën e mësimdhënies. disiplinat individuale(dhe jo kurset e përgjithësuara) do të pengojnë zbatimin e një qasjeje integruese në proceset e trajnimit dhe monitorimit të gatishmërisë për një kohë të gjatë.

Përparësia e testeve integruese ndaj atyre heterogjene qëndron në përmbajtjen më të madhe informative të secilës detyrë dhe në numrin më të vogël të vetë detyrave.

Testet adaptive

Fizibiliteti i kontrollit adaptiv rrjedh nga nevoja për të racionalizuar testimin tradicional.

Çdo mësues e kupton se nuk ka nevojë t'i japë një nxënësi të përgatitur mirë detyra të lehta dhe shumë të lehta, sepse probabiliteti i vendimi i duhur. Për më tepër, materialet e lehta nuk kanë potencial të dukshëm zhvillimi. Në mënyrë simetrike, për shkak të probabilitetit të lartë të një vendimi të gabuar, nuk ka kuptim t'i jepni detyra të vështira një studenti të dobët. Dihet që detyrat e vështira dhe shumë të vështira zvogëlohen motivimi i të nxënit shumë studentë.

Më së shumti karakteristike kryesore detyrat e testit adaptiv janë niveli i tyre i vështirësisë, i marrë në mënyrë empirike, që do të thotë: përpara se të shkosh në bankë, çdo detyrë i nënshtrohet testimit empirik për mjaftueshëm numër i madh studentë tipikë të popullatës së interesit. Fjalët "kontigjent interesi" synojnë të përfaqësojnë këtu kuptimin e konceptit më rigoroz të njohur në shkencë "popullata e përgjithshme".

Testimi ka përparësitë e mëposhtme mbi metodat e tjera kontrolli pedagogjik:

· rritjen e shpejtësisë së kontrollit të cilësisë së njohurive dhe aftësive të marra nga nxënësit;

· zbatimi i mbulimit edhe pse sipërfaqësor, por të plotë të gjithçkaje material edukativ;

· reduktimi i ndikimit ndikim negativ mbi rezultatet e testimit të faktorëve të tillë si disponimi, niveli i kualifikimeve dhe karakteristika të tjera të një mësuesi të caktuar, d.m.th. minimizimi faktor subjektiv gjatë vlerësimit të përgjigjeve;

· objektivitet i lartë dhe, si rezultat, një efekt stimulues pozitiv pozitiv në aktiviteti njohës student;

· fokusimi në moderne mjete teknike, për përdorim në mjedisin e sistemeve të trajnimit dhe monitorimit kompjuterik;

· mundësia e përpunimit matematikor dhe statistikor të rezultateve të kontrollit dhe si rrjedhojë e rritjes së objektivitetit të kontrollit pedagogjik;

· zbatimi i parimit të individualizimit dhe diferencimit të trajnimit nëpërmjet përdorimit të testeve adaptive;

· aftësia për të rritur frekuencën dhe rregullsinë e kontrollit duke reduktuar kohën e nevojshme për të përfunduar detyrat dhe duke automatizuar inspektimin;

· lehtësimin e procesit të integrimit të sistemit arsimor të vendit në atë europian.

Testet mund të klasifikohen në bazë të mëposhtme:

1. Fusha e lëndës aplikimi i testeve: njëlëndore, shumëlëndore, integruese.
Integruese mund të quhet një test i përbërë nga detyra të tilla, përgjigjet e sakta të të cilave kërkojnë njohuri të integruara (të ndërlidhura, të përgjithësuara) të dy ose më shumë disiplinave akademike. Përdorimi i testeve të tilla në shkollë, monitoruese dhe edukative, është një mjet i shkëlqyer për zbatimin e lidhjeve ndërdisiplinore në mësimdhënie.

2. Orientimi i përgjithshëm i dizajnit të testit: i orientuar drejt normativës ose i orientuar nga kriteri (i orientuar nga lënda).
Në me orientim normativ qasje, testet janë zhvilluar për të krahasuar lëndët sipas nivelit arritjet arsimore.
Kryesor shenjë dalluese lëndë specifike testimi është interpretimi i performancës së testit nga pikëpamja e përmbajtjes së tij semantike. Theksi është në një fushë të përmbajtjes të përcaktuar rreptësisht (çfarë mund dhe dinë testuesit), dhe jo në atë se si duken ata në krahasim me të tjerët.

3.didaktike-psikologjike orientimi në test: test i arritjeve për të kontrolluar njohuritë e teorisë; një test arritjesh për të monitoruar aftësitë dhe aftësitë e shkallëve të ndryshme të kompleksitetit në një lëndë të caktuar, një test aftësie për të mësuar (diagnoza e aftësive reale arsimore në një gamë të caktuar lëndore ose njohurish ciklike - matematikore, gjuhësore, etj.).

4.Orientimi në një fazë të caktuar të kontrollit: testet paraprake të kontrollit, testet kontrolli aktual, testet përfundimtare të kontrollit.

5. Aktiviteti dominues i subjektit gjatë kryerjes së testeve– me gojë, me shkrim, kompjuter.

6. Numri i objekteve të kontrollit: teste që kanë një objekt kontrolli (për shembull, numrin e operacioneve të kryera në nivelin e duhur) ose disa (cilësi, sasi, shpejtësi, sekuencë strikte, ndërgjegjësimi për të njëjtat operacione).

7. Shkalla e homogjenitetit detyrat e testimit : teste me forma homogjene ose heterogjene të ndërtimit të detyrave.

8. Faktori i shpejtësisë: me shpejtësi të lartë (me regjistrim të detyrueshëm të kohës së ekzekutimit) dhe jo të shpejtë.

9. Formulari i organizimit të testit: masë, individuale, grupore.

Më vete, ekzistojnë të ashtuquajturat adaptive teste të bazuara në parimin e individualizimit të të nxënit. Çdo mësues e kupton se nuk ka kuptim t'i japësh detyra të lehta dhe shumë të lehta një nxënësi të mirë, ashtu siç nuk ka kuptim t'i japësh detyra të vështira një nxënësi të dobët. Në teori dimensionet pedagogjike Një masë e vështirësisë së detyrës dhe një masë e nivelit të njohurive u gjetën të krahasueshme në një shkallë. Pas ardhjes së kompjuterëve, kjo masë formoi bazën e metodës së kontrollit të njohurive adaptive, ku vështirësia dhe numri i detyrave të paraqitura rregullohen në varësi të përgjigjeve të nxënësve.