Integracijos testavimas. Programinės įrangos produkto testų išlaikymui kūrimas

Anotacija: Paskaita yra antroji iš trijų, apimanti patikrinimo proceso lygius. Šios paskaitos tema – integracijos testavimo procesas, jo uždaviniai ir tikslai. Nagrinėjami organizaciniai integracijos testavimo aspektai - integracijos testavimo metodų struktūrinė ir laiko klasifikacija, integracijos testavimo planavimas. Šios paskaitos tikslas: suteikti idėją apie integracijos testavimo procesą, jo techninius ir organizacinius komponentus

20.1. Integracijos testavimo uždaviniai ir tikslai

Atskirų modulių, sudarančių programinės įrangos sistemą, testavimo ir patikrinimo rezultatas turėtų būti išvada, kad šie moduliai yra nuoseklūs ir atitinka reikalavimus. Tačiau atskiri moduliai retai veikia savarankiškai, todėl kita užduotis po atskirų modulių testavimo yra kelių modulių, sujungtų į vieną visumą, teisingos sąveikos patikrinimas. Šis testavimo tipas vadinamas integracija. Jo tikslas yra užtikrinti teisingumą bendradarbiavimą sistemos komponentas.

Integracijos testavimas taip pat vadinamas sistemos architektūros testavimas. Viena vertus, šis pavadinimas atsirado dėl to, kad integravimo testai apima visų galimų sąveikų tarp programinės įrangos modulių ir elementų, kurie yra apibrėžti sistemos architektūroje, tipų patikrinimus – taigi integravimo testai tikrina. užbaigtumas sąveikos testuojamame sistemos diegime. Kita vertus, integravimo testų rezultatai yra vienas iš pagrindinių informacijos šaltinių tobulinant ir išaiškinant sistemos architektūrą, tarpmodulių ir komponentų sąsajas. Tai yra, šiuo požiūriu integracijos testai tikrina teisingumas sistemos komponentų sąveika.

Sąveikos teisingumo tikrinimo pavyzdys gali būti du moduliai, iš kurių vienas kaupia protokolo pranešimus apie gautus failus, o antrasis šį protokolą atvaizduoja ekrane. Sistemos funkciniai reikalavimai nurodo, kad pranešimai turi būti rodomi atvirkštine chronologine tvarka. Tačiau pranešimų saugojimo modulis juos saugo tiesiogine tvarka, o išvesties modulis naudoja krūvą, kad išvestų į atvirkštine tvarka. Vienetiniai testai, liečiantys kiekvieną modulį atskirai, čia neturės jokios įtakos – visiškai įmanoma priešinga situacija, kai pranešimai saugomi atvirkštine tvarka ir išvedami naudojant eilę. Galima problema gali būti aptikta tik patikrinus modulių sąveiką naudojant integravimo testus. Esminis dalykasčia yra tai, kad visa sistema pranešimus išveda atvirkštine chronologine tvarka, t.y. patikrinę išvesties modulį ir nustatę, kad jis išveda pranešimus į priekį, negalime garantuoti, kad aptikome defektą.

Atlikus integracijos testavimą ir pašalinus visus nustatytus defektus, gaunama nuosekli ir holistinė programinės sistemos architektūra, t.y. galime manyti, kad integracijos testavimas išbando architektūrą ir žemo lygio funkcinius reikalavimus.

Integracijos testavimas, kaip taisyklė, tai kartotinis procesas, kurio metu tikrinamas vis didėjančio modulių rinkinio funkcionalumas.

20.2. Integracijos testavimo organizavimas

20.2.1. Integracijos testavimo metodų struktūrinė klasifikacija

Paprastai integracijos testavimas atliekamas baigus visų integruotų modulių vienetų testavimą. Tačiau taip būna ne visada. Yra keli integracijos testavimo būdai:

• bandymai iš apačios į viršų;
• monolitinis bandymas;
• bandymas iš viršaus į apačią.

Visi šie metodai remiasi žiniomis apie sistemos architektūrą, kuri dažnai vaizduojama kaip struktūros diagramos arba funkcijų iškvietimo diagramos. Kiekvienas mazgas tokioje diagramoje reiškia programinės įrangos modulį, o rodyklės tarp jų rodo skambučių priklausomybes tarp modulių. Pagrindinis skirtumas tarp integravimo testavimo metodų yra judėjimo pagal šias diagramas kryptis ir aprėpties plotis per iteraciją.

Testavimas iš apačios į viršų. Naudojant šį metodą, numanoma, kad visi programinės įrangos moduliai, esantys sistemoje, pirmiausia yra testuojami ir tik tada sujungiami integracijos testavimui. Taikant šį metodą, klaidų lokalizavimas yra labai supaprastintas: jei moduliai tikrinami atskirai, tada klaida, kai jie veikia kartu, yra jų sąsajos problema. Taikant šį metodą, testuotojo problemų paieškos sritis yra gana siaura, todėl tikimybė teisingai nustatyti defektą yra daug didesnė.

Ryžiai. 20.1.

Tačiau metodas iš apačios į viršų testavimas turi reikšmingą trūkumą – prieš atliekant integravimo testavimą reikia sukurti tvarkyklę ir stubus vienetų testavimui bei poreikis sukurti tvarkyklę ir stubus, skirtus dalies sistemos modulių integravimo testavimui (20.1 pav.)

Vienoje pusėje yra tvarkyklės ir kištukai - galingas įrankis testavimas, kita vertus, jų kūrimas reikalauja didelių resursų, ypač kai keičiasi integruotų modulių sudėtis, kitaip tariant, gali prireikti vieno tvarkyklių rinkinio kiekvieno modulio vienetiniam testavimui, atskiros tvarkyklės ir šaknų integracijos testavimui. dviejų modulių iš komplekto, atskiras trijų modulių integracijos testavimui ir kt. Taip yra visų pirma dėl to, kad modulių integravimas pašalina kai kurių dalių poreikį, be to, reikia pakeisti tvarkyklę, kuri palaiko naujus bandymus, turinčius įtakos keliems moduliams.

Monolitinis bandymas rodo, kad atskiri sistemos komponentai nebuvo rimtai išbandyti. Pagrindinis privalumas šis metodas- nereikia kurti bandomosios aplinkos, tvarkyklių ir stubų. Sukūrus visus modulius, atliekama jų integracija, tada testuojama visa sistema. Šio požiūrio nereikėtų painioti su sistemos testavimu, kuris bus kitos paskaitos tema. Nepaisant to, kad atliekant monolitinį testavimą bus patikrintas visos sistemos veikimas kaip visuma, pagrindinis šio testavimo uždavinys yra nustatyti atskirų sistemos modulių sąveikos problemas. Sistemos testavimo uždavinys – įvertinti kokybę ir kiekybines charakteristikas sistemų priimtinumo galutiniam vartotojui požiūriu.

Monolitinis bandymas turi nemažai rimtų trūkumų.

• Labai sunku nustatyti klaidos šaltinį (nustatyti klaidingą kodo dalį). Daugelis modulių turėtų manyti, kad yra klaida. Problema kyla dėl to, kad reikia nustatyti, kurios iš visų susijusių modulių klaidų lėmė rezultatą. Tai gali sukelti klaidų poveikį. Be to, vieno modulio klaida gali blokuoti kito modulio testavimą.
• Sunku organizuoti klaidų taisymus. Atlikus testavimą, testeris užfiksuoja rastą problemą. Sistemos defektą, dėl kurio atsirado ši problema, ištaisys kūrėjas. Kadangi, kaip taisyklė, testuojami moduliai yra parašyti skirtingi žmonės, iškyla problema – kuris iš jų atsakingas už defekto suradimą ir pašalinimą? Esant tokiam „kolektyviniam neatsakingumui“, defektų pašalinimo greitis gali smarkiai sumažėti.
• Testavimo procesas menkai automatizuotas. Privalumas (be papildomų programinė įranga lydintys testavimo procesą) pasirodo esąs trūkumas. Kiekvienas atliktas pakeitimas reikalauja pakartoti visus testus.

Testavimas iš viršaus į apačią daroma prielaida, kad integracijos testavimo procesas vyksta po kūrimo. Pirma, testuojamas tik aukščiausias sistemos valdymo lygis, be modulių daugiau žemas lygis. Tada palaipsniui žemesnio lygio moduliai integruojami su aukštesnio lygio moduliais. Dėl šio metodo panaudojimo nereikia tvarkyklių (vairuotojo vaidmenį atlieka aukštesnio lygio sistemos modulis), tačiau stubų poreikis išlieka (20.2 pav.).

Skirtingi testavimo ekspertai turi skirtingas nuomones, kuris metodas yra patogesnis realiam programinės įrangos sistemų testavimui. Jordanas tai tvirtina bandymas iš viršaus į apačią priimtiniausias in realias situacijas, ir Myersas mano, kad kiekvienas metodas turi savų privalumų ir trūkumų, tačiau apskritai metodas „iš apačios į viršų“ yra geresnis.

Literatūroje dažnai minimas objektinės programinės įrangos sistemų integracijos testavimo metodas, pagrįstas klasių grupių, kurios kartu turi tam tikrą uždarą ir pilną funkcionalumą, identifikavimu. Iš esmės šis metodas nėra naujo tipo integracijos testavimas, jis tiesiog pakeičia minimalų elementą, atsirandantį dėl integracijos. Integruodami modulius procedūrinėmis programavimo kalbomis, galite integruoti bet kokį modulių skaičių, jei yra sukurti stubai. Integruojant klases į grupes, yra gana laisvi klasterio funkcionalumo išsamumo apribojimai. Tačiau net ir į objektus orientuotų sistemų atveju galima integruoti bet kokį skaičių klasių naudojant stub klases.

Nepriklausomai nuo naudojamo integracijos testavimo metodo, būtina atsižvelgti į sistemos funkcionalumo aprėpties integravimo testais laipsnį. Darbe pasiūlytas aprėpties laipsnio įvertinimo metodas, pagrįstas valdymo skambučiais tarp funkcijų ir duomenų srautų. Su šiuo įvertinimu turi būti vykdomas visų sistemos struktūros schemoje esančių modulių kodas (turi būti padengti visi mazgai), visi iškvietimai turi būti vykdomi bent vieną kartą (turi būti padengti visi ryšiai tarp mazgų struktūros schemoje), visos skambučių sekos. turi būti vykdomas bent vieną kartą (turi būti padengti visi struktūros diagramos keliai).

Joks programinės įrangos kūrimas nėra baigtas neišbandžius vykdomojo kodo. Tiesą sakant, tai užima pusę viso kūrimo laiko ir daugiau nei pusę projekto išlaidų. Tačiau tai yra neatsiejama naujų programų, programų ir sistemų kūrimo proceso dalis.

Integracijos testavimas kaip didelio darbo dalis

Vienas iš programinės įrangos kokybės kontrolės būdų yra integracinis testavimas, kurio įvestis paimama iš atskirų modulių, išbandytų ankstesniame etape.

Skirtingai nuo modulinės parinkties, kuri nustato klaidas, lokalizuotas kiekvienoje atskiroje funkcijoje ar klasėje, integracijos testavimas yra defektų, susijusių su sąveikos tarp atskirose dalyse sukurtas produktas. Integraciniam funkciniam testavimui naudojamas „baltosios dėžutės“ metodas, tai yra, kokybės inžinierius turi prieigą prie kiekvieno atskiro modulio tekstų ir išmano juos bei jų tarpusavio sąveikos principus.

Modulio surinkimo būdai

Monolitinis metodas reiškia, kad visi moduliai, kuriems ateityje bus taikomas integracijos testavimas, yra surenkami kartu vienu metu. Beveik neabejotinai atsiranda situacijų, kai dalis bandomojo komplekso dar nėra paruošta.

Tokiu atveju jis pakeičiamas papildomai sukurtais „stubeliais“ arba tvarkyklėmis.

Kartu su monolitiniu metodu yra prieauginis metodas (jis taip pat vadinamas žingsnis po žingsnio), nes bandomojo kodo tūris palaipsniui didėja, todėl galima lokalizuoti sritis, kuriose yra atskirų dalių santykių defektų.

Prieauginis metodas apima du modulių pridėjimo būdus:

• iš viršaus į apačią arba didėjančia tvarka,
• iš apačios į viršų – besileidžiantis.

Monolitinio ir prieauginio testavimo ypatumai

Pagrindinis monolitinio tipo surinkimo trūkumas yra didelis skaičius laiko ir darbo sąnaudos išleidžiamos imituojant trūkstamas bandomojo komplekso dalis. Atrodytų, kad stubai yra gana patogus testavimo įrankis, tačiau pasitaiko situacijų, kai procese reikia iš naujo sukurti imituojamas programos dalis. Pavyzdžiui, jei pasikeičia testuojamų modulių sudėtis. Be to, defektų radimo efektyvumas nėra toks didelis, kai dirbama ne su realia preke, o tik su fiktyviu komponentu. Tas pats trūkumas taip pat yra susijęs su laipsnišku bandymu taikant „iš apačios į viršų“ metodą.

Tuo pačiu vienas iš trūkumų žingsnis po žingsnio metodas yra poreikis organizuoti ir sukurti aplinką moduliams vykdyti tam tikra seka. Lygiagrečiai plėtoti viršutinį ir apatinį lygius taip pat praktiškai neįmanoma.

Žinoma, abu surinkimo būdai, monolitiniai ir inkrementiniai, turi ne tik trūkumų, bet ir privalumų. Pirmuoju atveju yra puikios galimybės lygiagrečiai plėtoti visas su testavimu susijusias klases ir funkcijas, kaip ir pradinis etapas, ir po modifikavimo. Žingsnis po žingsnio metodas yra mažiau darbo reikalaujantis: moduliai pridedami palaipsniui, o klaidos ir defektai taip pat palaipsniui atrandami. Tai, kaip žinoma, sumažina laiką, praleistą jų paieškai.

Integracijos testavimo pranašumai

Šiame etape atliekamas didžiulis darbas siekiant patikrinti visų lygių ryšius, be kurių, žinoma, neįmanoma atlikti tolesnių bandymų.

Programinės įrangos integravimo testavimas turi keletą privalumų:

• atskirų programos modulių sąveikos sąsajos tikrinimas;
• santykių tarp išbandytų kompleksinių ir trečiųjų šalių programinės įrangos sprendimų kontrolė;
• išorinių sprendimo komponentų veikimo testavimas;
• projektinės dokumentacijos dėl atskirų modulių sąveikos atitikties kontrolė.

Defektų taisymas

Integracijos testavimas baigtas, bet tai dar ne viskas. Rastos klaidos įrašomos ir siunčiamos kūrėjui taisyti, o po to procesas prasideda iš naujo.

Pirmiausia reikia patikrinti, ar nustatyti defektai buvo pašalinti. Antra, pakeitus šaltinio kodą, gali atsirasti naujų klaidų, susijusių su programos veikimu ir sąveika su trečiųjų šalių programine įranga.

Nors dabar yra daug kokybės kontrolės metodų, jų vis dar yra daug svarbus vaidmuo integracijos testavimas vaidina svarbų vaidmenį. Šio tipo patikrinimo pavyzdys gali aiškiai parodyti programinės įrangos kūrimo ir dokumentacijos kliūtis.

Testavimo automatika

Priklausomai nuo apimties originalus kompleksas duomenų ir kūrimo dalyko, gali kilti testavimo laiko problema ir viso įvykio sudėtingumas.

Daugiausiai veiksmingas patikrinimas plėtra turi būti naudojama didžiulė sumaįvesties duomenis ir sąlygas, kurių neįmanoma susidoroti „rankiniu būdu“. Šiai problemai išspręsti naudojama testavimo automatika. Kaip ir kiti tipai, integracijos testavimas taip pat gali būti automatizuotas. Tai sumažins bendrą kūrimo laiką ir padidins klaidų aptikimo proceso efektyvumą.

Tačiau testavimo automatika negali visiškai pakeisti kokybiško inžinieriaus darbo, o tik jį papildyti.

Taigi integracijos testavimas yra neatsiejama bet kokios programinės įrangos kūrimo dalis ir vienas iš viso produkto kokybės tikrinimo proceso etapų. Kaip ir bet kuris metodas, jis turi nemažai privalumų ir trūkumų, tačiau jo nenaudojant aukštos kokybės programinės įrangos kūrimas tampa neįmanomas.

Vertimas: Anna Radionova

Yra daugybė programinės įrangos testų tipų. BDD praktika gali būti taikoma bet kokiam testavimo aspektui, tačiau BDD sistemos naudojamos ne visų tipų testuose. Elgesio scenarijai iš esmės yra funkcinis testai – jie patikrina, ar testuojamas produktas veikia tinkamai. Įrankius galima naudoti našumo testavimui, o BDD sistemos nėra skirtos šiam tikslui. Šio straipsnio pagrindinis tikslas yra apibūdinti BDD automatizavimo vaidmenį testavimo piramidėje. Perskaitykite straipsnį BDD 101: Rankinis testavimas, kad suprastumėte, kaip BDD naudojamas atliekant rankinį testavimą. (Visą informaciją apie BDD galite rasti Automation Panda BDD puslapyje)

Testavimo piramidė

Nepaisant to, BDD praktika gali būti taikoma vienetiniams testams. Kiekvienas vieneto testas turėtų sutelkti dėmesį į pagrindinį komponentą: vieną skambutį, vieną variantą, tam tikrą įvesties derinį; įjungta elgesį.Tolesnėje ypatybių elgsenos specifikacijoje aiškiai atskiriami vienetų testai nuo daugiau bandymų aukšto lygio. Funkcijų kūrėjas taip pat yra atsakingas už vienetų testų rašymą, o kitas inžinierius yra atsakingas už integravimą ir galutinius testus. Elgesio specifikacija yra tarsi džentelmeniškas susitarimas, kad vienetų testai bus atskiras subjektas.

Integracija ir galutinis testavimas

BDD testavimo sistemos aiškiausiai atsiskleidžia integracijos ir galutinio testavimo lygiais.

Elgesio specifikacijose aiškiai ir glaustai aprašoma, ko tiksliai bandomasis atvejis yra skirtas. Žingsniai gali būti parašyti integracijos arba galutinio lygio lygiu. Paslaugų testai gali būti parašyti naudojant elgesio specifikacijas, kaip ir karatė. Nuo galo iki galo bandymai iš tikrųjų yra kelių žingsnių integracijos testai. Atkreipkite dėmesį sekantis pavyzdys, kuri, iš pirmo žvilgsnio, atrodo pagrindinis modelis sąveika su vartotoju, bet iš tikrųjų yra didelis galutinis testas:

Duota vartotojas yra prisijungęs prie socialinės žiniasklaidos svetainės
Kada vartotojas rašo naują įrašą
Tada vartotojo namų sklaidos kanale rodomas naujas įrašas
Ir visi draugai“ pagrindiniame kanale rodomas naujas įrašas

Lengva publikuoti socialinis tinklas apima sąveikos su sąsaja procesus, iškvietimus į backend paslaugas ir duomenų bazės pakeitimų atlikimą realiuoju laiku. Aprašyta pilnas kelias einantis per sistemą. Automatiniai veiksmai gali tiesiogiai arba netiesiogiai aprėpti šiuos lygius, tačiau testas juos tikrai apima.

Ilgi bandymai nuo galo iki galo

Sąvokas skirtingi žmonės dažnai supranta skirtingai. Kai žmonės sako „testai nuo galo iki galo“, jie turi omenyje ilgus, nuoseklius testus: bandymai, kurie apima kitoks elgesys produktai vienas po kito. Šis teiginys priverčia BDD šalininkus pašiurpti, nes prieštarauja pagrindinei BDD taisyklei: vienas scenarijus, vienas elgesys. Žinoma, naudodami BDD sistemas galite sukurti ilgus galutinius testus, bet reikia gerai pagalvoti, ar ir kaip tai padaryti.

Yra penki pagrindiniai principai, kaip rašyti ilgai veikiančius galutinius scenarijus BDD:

1. Nereikia dėl to jaudintis. Jei BDD procesas nustatytas teisingai, kiekvienas individualus elgesys jau yra visiškai įtrauktas į testavimo scenarijus. Kiekvienas scenarijus turi apimti visas įvesties ir išvesties duomenų lygiavertiškumo klases. Taigi ilgi scenarijai nuo galo iki galo daugiausia bus bandymo aprėpties dubliavimas. Užuot gaišus laiką kūrimui, geriau atsisakyti ilgų galutinių scenarijų automatizavimo, nes tie, kurie nesuteikia didelės vertės, ir daugiau laiko skiria rankiniam ir tiriamajam testavimui.
2. Sujunkite esamus scenarijus į naujus. Kiekviena „Kada-Tada“ pora reiškia individualus elgesys. Esamų scenarijų žingsniai gali būti iš naujo apibrėžti į kitus scenarijus ir reikalauja tik nedidelio pertvarkymo. Tai pažeidžia gerąją Gherkin praktiką ir gali sukelti ilgai veikiančius scenarijus, tačiau tai yra praktiškiausias būdas pakartotinai panaudoti veiksmus, skirtus dideliems tiesioginiams scenarijus. Dauguma BDD sistemų nepalaiko žingsnis po žingsnio tvarka, o jei palaikoma, veiksmus reikia perrašyti, kad kodas veiktų. (Šis metodas yra praktiškiausias, bet mažiau tradicinis.)
3. Sudėkite čekius į veiksmus „Duota“ ir „Kada“.. Taikant šią strategiją išvengiama „Kada-Tada“ porų dubliavimo ir užtikrinama, kad būtų atliekami patikrinimai. Kiekvieno žingsnio teisingumas tikrinamas viso proceso metu naudojant Gherkin tekstą. Tačiau gali prireikti kelių naujų veiksmų.
4. Elgesio seką traktuokite kaip unikalų, individualų elgesį.. Tai geriausias būdas galvodami apie ilgalaikius scenarijus iki galo, nes tai sustiprina elgesio mąstymą. Ilgalaikis scenarijus yra vertingas tik tada, kai jis laikomas unikaliu elgesiu. Scenarijus turėtų būti parašytas siekiant pabrėžti šį unikalumą. Priešingu atveju tai nėra vertas naudoti scenarijus. Tokie scenarijai dažnai yra deklaratyvūs ir aukšto lygio.
5. Nenaudokite BDD struktūrų ir nerašykite testų naudodami automatizavimo įrankius. Gherkin sukurtas taip, kad būtų galima bendradarbiauti elgsenos srityje, o ilgi galutiniai testai išsprendžia kokybės užtikrinimo darbo intensyvumo problemas. Įmonė gali pateikti elgesio specifikacijas, bet niekada nerašys galutinių testų. Elgsenos specifikacijų perrašymas į ilgus galutinius scenarijus gali blokuoti plėtrą. Daug geriausias sprendimas yra sambūvis: priėmimo testai gali būti parašyti naudojant Gherkin, o ilgai trunkantys galutiniai testai gali būti parašyti naudojant programavimo įrankius. Abu testų rinkiniai gali būti automatizuoti naudojant tą pačią kodo bazę, jie gali turėti tuos pačius palaikymo modulius ir netgi žingsnių apibrėžimo metodus.

Pasirinkite metodą, kuris geriausiai tinka jūsų komandai.

Technologiniu požiūriu integracinis testavimas yra kiekybinis vienetinio testavimo plėtojimas, nes, kaip ir vienetinis testavimas, jis veikia modulių ir posistemių sąsajose ir reikalauja sukurti testavimo aplinką, įskaitant Stubus vietoj trūkstamų modulių. Pagrindinis skirtumas tarp modulinės ir integracijos testavimas susideda iš tikslų, tai yra defektų tipų, kuriuos reikia aptikti, o tai savo ruožtu lemia įvesties duomenų atrankos strategiją ir analizės metodus. Visų pirma, integracijos testavimo lygiu, metodai, susiję su sąsajų padengimu, pvz., funkcijų arba metodų iškvietimais, arba sąsajos objektų naudojimo analize, pvz. pasaulinių išteklių, suteiktos ryšio priemonės operacinė sistema.

Problema išspręsta metodu integracijos testavimas, - K komplekso programinės įrangos vykdymo metu įdiegtų tarpmodulinių jungčių testavimas. Kadangi testuotojas, prieš iškviesdamas visus į testuojamą kompleksą įtrauktus modulius, detaliai žino programos tekstą, struktūrinių kriterijų naudojimas šiame etape yra galimas ir pagrįstas.

Integracijos testavimas naudojamas vienetinių modulių surinkimo į vieną kompleksą etape. Yra du žinomi modulių surinkimo būdai:
Monolitinis, pasižymintis tuo, kad vienu metu integruoti visi moduliai į išbandytą kompleksą
Prieauginis, kuriai būdingas laipsniškas (modulis po modulio) programų rinkinio sukūrimas su surinkto komplekso žingsnis po žingsnio testavimu. Taikant prieauginį metodą, yra dvi modulių pridėjimo strategijos:
o „Iš viršaus į apačią“ ir atitinkamas „iš apačios į viršų“ bandymas.
o „Iš apačios į viršų“ ir atitinkamai iš viršaus į apačią bandymas.

Ypatumai monolitinis bandymas yra tokie: norint pakeisti testavimo metu nesukurtus modulius, išskyrus viršutinį, reikia papildomai kurti tvarkykles (bandomąsias tvarkykles) ir/ar stubus (stubus), pakeičiant trūkusius žemesnio lygio modulius. bandymo sesijos metu.

Palyginus monolitinius ir integruotus metodus, gaunama:
Monolitinis bandymas reikalauja daug darbo, susijusio su papildomu tvarkyklių ir skilčių kūrimu bei sudėtingu klaidų, atsirandančių surinkto kodo erdvėje, identifikavimu.
Žingsnis po žingsnio bandymas yra susijęs su mažesniu klaidų nustatymu dėl laipsniško išbandyto kodo apimties didėjimo ir atitinkamai papildomos bandomojo kodo srities lokalizavimo.
Monolitinis bandymas numato puikias galimybes darbo lygiagretinimas, ypač pradiniame testavimo etape.

Ypatumai bandymas iš viršaus į apačią yra šios: vykdomos iškvietimų eilės aplinkos organizavimas išbandytais testuojamų modulių moduliais, nuolatinis stubų kūrimas ir naudojimas, modulių, kuriuose atliekamos mainų operacijos su aplinka, arba modulių, kurie yra svarbūs testuojamam algoritmui, prioritetinio testavimo organizavimas. .

Trūkumai bandymas iš viršaus į apačią:
Pakankamai „protingų“ stuburų išvystymo problema, t.y. stuburai, galintys būti naudojami imituojant įvairius testavimui reikalingo komplekso veikimo režimus
Aplinkos, skirtos modulių vykdymui reikiama seka, organizavimo ir kūrimo sudėtingumas
Lygiagretus aukštesniųjų ir žemesnių lygių modulių kūrimas lemia ne visada efektyvų modulių diegimą dėl dar neišbandytų žemesnių lygių modulių pritaikymo (specializavimo) prie jau išbandytų aukštesniųjų lygių modulių.

Trūkumai bandymai iš apačios į viršų:
Vėluojama patikrinti konceptualias bandomojo komplekso ypatybes
Poreikis kurti ir naudoti tvarkykles

Procesinio programavimo integravimo testavimo ypatybės

Bandymų rinkinio konstravimo procesą atliekant konstrukcijų testavimą lemia principas, kuriuo grindžiamas Programos modelio grafiko (GMP) konstravimas. Tai nustato bandymo kelių rinkinį ir testų, atitinkančių bandymo kelius, generavimą.

Pirmasis požiūris į programinės įrangos kūrimą yra procedūrinis (modulinis) programavimas. Tradicinis procedūrinis programavimas apima šaltinio kodo rašymą imperatyviu stiliumi, kuris nurodo tam tikrą komandų vykdymo seką, taip pat programinės įrangos projekto aprašą naudojant funkcinį skaidymą. Tokios kalbos kaip Pascal ir C yra būtinos. Juose kodo šaltinio eilučių tvarka nusako valdymo perdavimo tvarką, įskaitant nuoseklų vykdymą, sąlygų pasirinkimą ir pakartotinį programos sekcijų vykdymą. Kiekvienas modulis turi kelis įėjimo taškus (jei kodas griežtai parašytas – vieną) ir kelis išėjimo taškus (jei kodas griežtai parašytas – vieną). Sudėtingi programinės įrangos projektai turi modulinę hierarchinę struktūrą, o modulių testavimas yra pradinis programinės įrangos testavimo proceso žingsnis. Modulio grafinio modelio sudarymas yra nereikšminga užduotis, o testavimas beveik visada atliekamas pagal atšakos aprėpties C1 kriterijų, t.y. kiekvienas lankas ir kiekviena modulio grafiko viršūnė turi būti bent viename iš testavimo būdų.

Testų klasės ir tipai.

Yra dvi pagrindinės testų klasės: tradicinis Ir netradicinis.

Testas turi kompozicija, vientisumas Ir struktūra. Jį sudaro:

• užduotys;
• jų taikymo taisyklės;
• kiekvienos užduoties atlikimo pažymiai;
• rekomendacijos, kaip interpretuoti testo rezultatus.

Patikrinkite vientisumą reiškia užduočių ryšį, jų priklausymą bendram matuojamam veiksniui. Kiekviena bandymo užduotis atlieka jai priskirtą vaidmenį, todėl nė viena iš jų negali būti pašalinta iš testo neprarandant matavimo kokybės.

Bandymo struktūra formuoja būdą susieti užduotis viena su kita. Iš esmės tai yra vadinamasis faktoriaus struktūra, kurioje kiekviena užduotis yra susijusi su kitomis per bendras turinys ir bendras testo balo kitimas.

Tradicinis testas yra bent trijų sistemų vienybė:

• prasminga žinių sistema, aprašyta tikrinamos akademinės disciplinos kalba;
• formali vis sudėtingėjančių užduočių sistema;
• statistinės charakteristikos užduotis ir testų rezultatus.

Į tradicinį pedagoginį testą reikia žiūrėti dviem reikšmingais aspektais: kaip pedagoginio matavimo metodas ir kaip testo taikymo rezultatas.

tie st yra užduočių sistema, kuri sudaro geriausią metodinį vientisumą. Testo vientisumas yra stabili užduočių, kurios sudaro testą kaip besivystančią sistemą, sąveika.

Homogeniniai testai

Tradiciniai testai apima testus vienalytis Ir nevienalytis.

Homogeninis testas atstovauja vis sudėtingesnių, specifinės formos ir specifinio turinio užduočių sistema – sistema, sukurta siekiant objektyvaus, kokybinio ir efektyvus metodas vienos akademinės disciplinos struktūros vertinimas ir studentų pasirengimo lygio matavimas.

Homogeniniai testai yra labiau paplitę nei kiti. Pedagogikoje jie yra sukurti valdyti žinias vienoje akademinėje disciplinoje arba vienoje tokios, pavyzdžiui, didelės akademinės disciplinos, kaip fizikos, skyriuje. Vienarūšiame pedagoginiame teste neleidžiama naudoti užduočių, kurios atskleidžia kitas savybes. Pastarojo buvimas pažeidžia pedagoginio testo drausminio grynumo reikalavimą. Juk kiekvienas testas matuoja kažką iš anksto nustatyto.

Heterogeniniai testai

Heterogeninis testas atstovauja didėjančio sudėtingumo, specifinės formos ir specifinio turinio užduočių sistema - sistema, sukurta siekiant objektyvaus, kokybiško ir veiksmingo metodo, skirto kelių akademinių disciplinų struktūrai įvertinti ir studentų pasirengimo lygiui matuoti..

Dažnai tokie testai taip pat apima psichologines užduotisįvertinti intelektualinio išsivystymo lygį.

Įprastai heterogeniniai testai naudojami visapusiškam abiturientų vertinimui, asmenybės vertinimui kreipiantis dėl darbo, atrenkant labiausiai pasiruošusius stojantiesiems į universitetus. Kadangi kiekvienas heterogeninis testas susideda iš vienarūšių testų, testo rezultatų interpretavimas atliekamas remiantis kiekvieno testo užduočių atsakymais (čia jie vadinami skalėmis) ir, be to, per įvairių metodų bandoma duoti balų sumavimą bendras įvertinimas tiriamojo pasirengimas.

Testo rezultatai daugiausiai interpretuojami testologijos kalba, remiantis aritmetiniu vidurkiu, režimu arba mediana ir vadinamosiomis procentilių normomis, parodančiomis, kiek procentų testuojančiųjų turi testo rezultatas blogesnis nei bet kuris tiriamasis, paimtas analizuoti su savo testo rezultatu. Šis aiškinimas vadinamas orientuota į normatyvinę.

Integraciniai testai

Integruojantis gali būti vadinamas testu, susidedančiu iš užduočių sistemos, atitinkančios integracinio turinio, testo formos reikalavimus, didėjančių užduočių, skirtų apibendrintai galutinei mokymo įstaigos absolvento pasirengimo diagnozei, sudėtingumą..

Diagnostika atliekama pateikiant tokias užduotis, kurių teisingiems atsakymams reikia integruotų (apibendrintų, aiškiai tarpusavyje susijusių) žinių dviejų ir daugiau akademinės disciplinos. Kurti tokius testus gali tik tie mokytojai, kurie išmano daugybę akademinių disciplinų, supranta tarpdalykinių ryšių svarbą mokymuisi ir geba kurti užduotis, kurių teisingi atsakymai reikalauja iš mokinių turėti įvairių žinių. disciplinas ir gebėjimą pritaikyti tokias žinias.

Prieš integruojamąjį testavimą organizuojama integracinis mokymasis. Deja, dabartinė pamokų vedimo forma, kartu su pernelyg dideliu akademinių disciplinų susiskaidymu, kartu su mokymo tradicija. individualios disciplinos(o ne apibendrinti kursai) ilgą laiką trukdys įgyvendinti integracinį metodą mokymo ir pasirengimo stebėsenos procesuose.

Integruojamųjų testų pranašumas prieš heterogeninius yra didesnis kiekvienos užduoties informacinis turinys ir mažesnis pačių užduočių skaičius.

Adaptyvūs testai

Adaptyviosios kontrolės galimybė atsiranda dėl poreikio racionalizuoti tradicinį testavimą.

Kiekvienas mokytojas supranta, kad gerai paruoštam mokiniui nereikia duoti lengvų ir labai lengvų užduočių, nes teisingas sprendimas. Be to, lengvos medžiagos neturi pastebimo vystymosi potencialo. Simetriškai, dėl didelės klaidingo sprendimo tikimybės, nėra prasmės duoti sunkių užduočių silpnam mokiniui. Yra žinoma, kad sunkios ir labai sunkios užduotys sumažėja mokymosi motyvacija daug studentų.

Labiausiai pagrindinė savybė adaptyvaus testo užduotys yra jų sudėtingumo lygis, gautas empiriškai, o tai reiškia: prieš patenkant į banką kiekviena užduotis yra empiriškai patikrinama didelis skaičius tipiški dominančios populiacijos studentai. Žodžiai „interesų kontingentas“ čia reiškia griežtesnės sąvokos, žinomos moksle „bendra populiacija“, reikšmę.

Bandymas turi šiuos pranašumus, palyginti su kitais metodais pedagoginė kontrolė:

· studentų įgytų žinių ir įgūdžių kokybės tikrinimo spartos didinimas;

· įgyvendinimas nors ir paviršutiniškas, bet visapusiškai aprėptas mokomoji medžiaga;

· poveikio mažinimas neigiamą įtaką apie tokių veiksnių kaip nuotaika, kvalifikacijos lygis ir kitos konkretaus mokytojo charakteristikos tikrinimo rezultatus, t.y. sumažinimas subjektyvus veiksnys vertinant atsakymus;

· didelis objektyvumas ir dėl to didesnis teigiamas stimuliuojantis poveikis pažintinė veikla studentas;

· orientuotis į šiuolaikišką techninėmis priemonėmis, skirtas naudoti kompiuterių mokymo ir stebėjimo sistemų aplinkoje;

· galimybė matematiškai ir statistiškai apdoroti kontrolės rezultatus ir dėl to didinti pedagoginės kontrolės objektyvumą;

· mokymų individualizavimo ir diferencijavimo principo įgyvendinimas naudojant adaptacinius testus;

· galimybė padidinti kontrolės dažnumą ir reguliarumą, sumažinant užduočių atlikimo laiką ir automatizuojant patikrinimą;

· palengvinti šalies švietimo sistemos integracijos į europinę procesą.

Testai gali būti klasifikuojami pagal šiuos kriterijus:

1. Dalyko sritis testų taikymas: vieno dalyko, kelių dalykų, integracinis.
Integruojantis gali būti vadinamas testu, susidedančiu iš tokių užduočių, kurių teisingiems atsakymams reikia integruotų (susijusių, apibendrintų) dviejų ar daugiau akademinių disciplinų žinių. Tokių testų naudojimas mokykloje – tiek stebėjimas, tiek auklėjimas – puiki priemonė tarpdalykiniams ryšiams diegti mokyme.

2. Bendra bandymo dizaino orientacija: orientuotas į normatyvą arba į kriterijų (orientuotas į dalyką).
At orientuota į normatyvinę požiūrio, rengiami testai, skirti lyginti dalykus pagal lygius švietimo pasiekimai.
Pagrindinis skiriamasis ženklas dalykinis testavimas – tai testo atlikimo interpretavimas jo semantinio turinio požiūriu. Pabrėžiama griežtai apibrėžta turinio sritis (ką gali ir žino testuotojai), o ne tai, kaip jie atrodo, palyginti su kitais.

3.Didaktinė-psichologinė testo orientacija: pasiekimų testas teorijos žinioms kontroliuoti; pasiekimų testas, skirtas stebėti įvairaus sudėtingumo tam tikro dalyko gebėjimus ir įgūdžius, mokymosi gebėjimų testas (tikrųjų ugdymosi gebėjimų diagnozė tam tikrame dalyko diapazone arba ciklinių žinių – matematinių, kalbinių ir kt.).

4.Orientacija į tam tikrą kontrolės etapą: preliminarūs kontroliniai testai, testai srovės valdymas, galutiniai kontroliniai testai.

5. Dominuojanti tiriamojo veikla atliekant testus– žodžiu, raštu, kompiuteriu.

6. Valdymo objektų skaičius: testai, kuriuose yra vienas valdymo objektas (pavyzdžiui, operacijų, atliekamų tinkamu lygiu, skaičius) arba keli (kokybė, kiekis, greitis, griežta seka, žinojimas apie tas pačias operacijas).

7. Homogeniškumo laipsnis testo užduotys : testai su vienarūšėmis arba nevienalytėmis konstravimo užduočių formomis.

8. Greičio faktorius: didelės spartos (su privalomu vykdymo laiko fiksavimu) ir negreitai.

9. Bandymo organizavimo forma: masinis, individualus, grupinis.

Atskirai yra vadinamieji prisitaikantis testus, pagrįstus mokymosi individualizavimo principu. Kiekvienas mokytojas supranta, kad geram mokiniui nėra prasmės duoti lengvas ir labai lengvas užduotis, kaip ir silpnam mokiniui nėra prasmės duoti sunkių užduočių. Teoriškai pedagoginiai matmenys buvo nustatyta, kad užduoties sunkumo matas ir žinių lygio matas yra palyginami vienoje skalėje. Atsiradus kompiuteriams, ši priemonė sudarė pagrindą adaptyviam žinių kontrolės metodui, kai pateikiamų užduočių sudėtingumas ir skaičius reguliuojamas priklausomai nuo mokinių atsakymų.