Što je testiranje modula? Definicija, primjeri

⚡ Pametni sažetak

Testiranje modula provjerava pojedinačne podprograme, potprograme, klase i procedure, a ne sastavljeni program, tako da se nedostaci pojavljuju unutar malog, dobro razumljivog bloka koda gdje ih je lako pronaći i popraviti.

🎯 Cilj: Cilj je otkriti greške u modulu, a ne pokazati da modul radi.
⚪ Orijentacija: Tehnika je uglavnom bijela kutija, dopunjena slučajevima crne kutije preuzetim iz specifikacije.
⏩ Paralelizam: Nekoliko modula može se testirati istovremeno, što skraćuje ukupni prozor testiranja.
🔗 Dvije metode: Moduli se kombiniraju inkrementalno, korak po korak ili neinkrementalno u jednom prolazu.
🧰 Skele: Drajveri dostavljaju testne podatke modulu, dok stubovi zamjenjuju module koje poziva.
🆚 Vlasništvo: Testeri pišu modularne testove nakon kodiranja, dok programeri pišu unit testove tijekom njega.
⚠️ Izazovi: Neinkrementalni rad, pogrešno shvaćeni duplirani testovi i često otklanjanje pogrešaka troše većinu truda.

Pročitaj više

Što je testiranje modula?

Testiranje modula je vrsta testiranja softvera koja provjerava pojedinačne podprograme, potprograme, klase ili procedure u programu. Umjesto testiranja cijelog softverskog programa odjednom, testiranje modula preporučuje testiranje manjih gradivnih blokova programa.

Testiranje modula je uglavnom orijentirano na bijelu kutiju. Cilj testiranja modula nije pokazati ispravno funkcioniranje modula, već pokazati prisutnost pogreške u njemu. Ta inverzija je važna: izvođenje koje ne pronađe ništa potvrdilo je vrlo malo, dok je izvođenje koje otkrije nedostatak obavilo svoj posao.

Testiranje na razini modula također omogućuje uvođenje paralelizma u proces testiranja, jer stvara priliku za istovremeno testiranje više modula umjesto čekanja na potpunu izgradnju.

Zašto raditi testiranje modula

Testiranje modula se preporučuje jer mijenja ekonomičnost otkrivanja nedostataka.

Vjerojatnost identificiranja pogrešaka ili grešaka u manjim dijelovima programa postaje veća.
Više modula može se testirati istovremeno, te stoga pristup podržava paralelno testiranje.
Složenost testiranja može se lako upravljati, budući da se svaki modul razmatra zasebno.
Kvar pronađen unutar jednog modula je tracmoguće je s malom količinom koda, pa vrijeme otklanjanja pogrešaka naglo pada.

Kako napraviti testiranje modula?

Projektiranje a testni slučaj je važan segment testiranja modula. Prilikom dizajniranja testnih slučajeva za testiranje modula, tester mora uzeti u obzir dvije stvari.

Specifikacija za modul
Izvorni kod modula

Analizirajte logiku modula koristeći jedan ili više od bijela kutija metode, a zatim nadopuniti ove testne slučajeve primjenom Crna kutija metode prema specifikaciji modula. Realne vrijednosti su jednako važne kao i odabrani putevi, stoga pripremite podaci ispitivanja uz slučajeve, a ne nakon njih.

Nakon što su testni slučajevi dizajnirani, sljedeći korak je kombiniranje modula za testiranje. Korištena metoda je ili inkrementalna ili neinkrementalni metoda.

Neinkrementalna metoda — svi moduli se testiraju neovisno. Prvo se kombiniraju svi moduli, a zatim se testira cijeli program.
Inkrementalna metoda — svaki se modul prvo testira, a zatim postupno dodaje u testiranu kolekciju. Izvodi se postupno ponovno testiranje.
Unutar inkrementalnog testiranja postoje dva pristupa, odozgo prema dolje i odozdo prema gore testiranje.
Za izvršavanje modula s odabranim podacima potreban je upravljački program za opskrbu testnim podacima, praćenje izvršavanja i bilježenje rezultata.

Izbor između dvije metode je kompromis između napora postavljanja i dijagnosticiranja.

Aspekt	Inkrementalna metoda	Neinkrementalna metoda
Kombinacija	Jedan modul odjednom, dodan u testiranu kolekciju	Svi moduli kombinirani, a zatim testirani zajedno
Potrebna skela	Više drivera i stubova, pisanih progresivno	Manje duplih testova, budući da su prisutni pravi moduli
Pronalazak pogreške	Snažno — kvar ukazuje na modul koji je upravo dodan	Slabo — kvar može nastati bilo gdje
Najprikladniji za	Velike konstrukcije s mnogo interaktivnih modula	Mali programi s malo modula i niskim stupnjem povezanosti

Drajveri i stubovi u testiranju modula

Gore spomenuti upravljački program je jedna polovica para. Budući da se modul koji se testira rijetko nalazi na vrhu ili dnu lanca poziva, testeri zamjenjuju lažnim kodom ono što nedostaje s bilo koje strane.

vozač — zamjenjuje pozivni modul iznad onog koji se testira. On daje testne podatke, poziva modul, prati izvršenje i bilježi rezultate. Testiranje odozdo prema gore ovisi o upravljačkim programima, jer su niži moduli spremni prije viših.
iskrčiti — zamjenjuje pozvani modul ispod onog koji se testira. Prihvaća poziv i vraća fiksni, poznati odgovor kako bi modul koji se testira mogao dovršiti svoj put. Testiranje od vrha prema dolje ovisi o stubovima, jer su viši moduli spremni prvi.

Obrađeni slučaj čini uparivanje konkretnim. Ako je modul za izračun plaćanja završen, dok ekran za plaćanje koji ga poziva nije, vozač unosi u modul skup ukupnih iznosa narudžbe i bilježi što se vraća. Ako je usluga pretraživanja poreza koju modul poziva također nedovršena, odrezak vraća fiksnu poreznu stopu tako da se izračun i dalje izvršava. Nijedan dio skele se ne isporučuje; oba se odbacuju nakon što stignu pravi moduli, zbog čega se nerazumijevanje testa doublesa kasnije navodi kao ponavljajući izazov.

Primjeri savjeta za testiranje modula

Evo nekoliko savjeta koje treba uzeti u obzir prije izvođenja testiranja modula.

Revpregledajte testne slučajeve prije njihove upotrebe.
Izbjegnite zabunu oko izvora odstupanja.
Koristite automatizirane alate za testiranje.
Ispitajte varijable koje bi trebale ostati nepromijenjene.
Zamijenite module između testera kako biste izbjegli samotestiranje.
Ponovno upotrijebite testne slučajeve.

Peti savjet nosi veću težinu nego što njegova duljina sugerira. Programer koji testira samo modul koji je upravo napisan ponavlja iste pretpostavke koje su proizvele grešku, pa je rotiranje modula između ljudi jedno od najjeftinijih mogućih poboljšanja kvalitete.

Jedinično testiranje u odnosu na testiranje modula

Ta se dva termina u mnogim timovima koriste naizmjenično, no autorstvo i opseg se razlikuju.

Testiranje modula	Ispitivanje jedinice
Testovi modula zbirka su testova koje je napisao tester nakon što je programer napisao neki kod	Jedinstveni testovi su skup testova koje je napisao programer tijekom procesa razvoja softvera
Testiranje modula može uključivati kombiniranje jediničnih testova	Testiranje jedinica može testirati jedinice izolirano

Testiranje modula vs. testiranje komponenti vs. testiranje integracije

Testiranje modula također se nalazi uz dvije susjedne razine koje je lako pomiješati s njim. Tablica ih dijeli prema tome što se testira i tko to obično provodi.

Aspekt	Testiranje modula	Ispitivanje komponenti	Integracijsko testiranje
Pod testom	Jedan potprogram, klasa ili procedura	Jedna samostalna komponenta sa svojim neposrednim ovisnostima	Sučelja između kombiniranih modula
Uobičajeni vlasnik	Tester, nakon što je kod napisan	Ispitivač	Tester integracije
Skele	Vozači i skraćeni dijelovi	Stubovi za vanjske ovisnosti	Progresivno manje dvostrukih testova
Otkriven nedostatak	Logička greška unutar modula	Pogreška u ponašanju komponente	Greška sučelja i prijenosa podataka

U svakodnevnoj upotrebi testiranje komponenti i testiranje modula često se tretiraju kao ista aktivnost, dok integracijsko testiranje počinje tek nakon što su pojedinačni moduli samostalno položeni.

Izazovi u testiranju modula

Ovo su izazovi s kojima se timovi najčešće susreću kada se uvodi testiranje modula.

Neinkrementalno testiranje zahtijeva više posla — kombiniranje svega prvo znači da jedan jedini neuspjeh može poslati testere natrag kroz cijeli program.
Test nesporazuma duplira — stub koji vraća nerealnu vrijednost stvara zeleni niz koji ništa ne dokazuje.
Često testiranje otklanjanja grešaka — kod za izradu skela nosi svoje nedostatke, a vrijeme utrošeno na popravljanje upravljačkog programa je vrijeme koje nije utrošeno na testiranje modula.
Potrebno je razumjeti kod — orijentacija bijele kutije znači da tester koji ne može pročitati modul ne može za njega dizajnirati smislene slučajeve.

Pitanja i odgovori

Obitelj xUnit pokriva većinu jezika, s mocking bibliotekama koje isporučuju stubove i alatom za pokrivanje koji pokazuje koji su putovi dosegnuti. Izbor slijedi jezik modula, a ne razinu testiranja.

Model čita izvorni kod modula, nabraja grane i predlaže slučaj za svaku, uključujući granične vrijednosti koje ručni prolaz često propušta. RevPrikaz ostaje neophodan jer generirani slučajevi potvrđuju što kod radi, a ne što specifikacija zahtijeva.

Da, a scaffolding je mjesto gdje takvi asistenti najbolje funkcioniraju, budući da je upravljački program ili stub repetitivan kod poznatog oblika. Vraćene vrijednosti i dalje zahtijevaju ljudsku odluku, jer stub koji izgleda uvjerljivo može sakriti upravo taj nedostatak koji se traži.

Dovoljno da je svaka grana i svaka granica u modulu barem jednom iskorištena. Sam postotni cilj je zavaravajući, jer visoka pokrivenost izjavama i dalje može ostaviti cijele ishode odluke neispitanima.

Nakon što se modul kompajlira i prije nego što se njegova sučelja zajedno testiraju, to je prva razina testiranja koja se primjenjuje na isporučeni kod, zbog čega nedostaci uočeni ovdje nikada ne dosežu faze integracije ili sustava.

Slijedite postojeći kod. Odozgo prema dolje odgovara projektima gdje se prva piše upravljačka logika, a niži moduli se zatvaraju; odozdo prema gore odgovara projektima gdje se prvi postavljaju pomoćni moduli, a zatim ih pozivaju upravljački programi.

Modul se čisto kompajlira, njegova specifikacija je dostupna, njegove ovisnosti su ili prisutne ili su zaustavljene, a testni podaci su spremni. Početak bez specifikacije pretvara vježbu u opis koda.

Testiranje nikada ne može dokazati da modul nema nedostataka, već samo da je preživio isprobane slučajeve. Stoga projektiranje izvršavanja koja pokušavaju oštetiti modul vraća više informacija od projektiranja izvršavanja za koja se očekuje da će uspjeti.