View
301
Download
1
Category
Preview:
Citation preview
Design-driven testing
(Dizajn vođen testiranjem)
Mentor: Studenti:
mr. Alem Čolaković, dipl.ing. Minela Hasanović, 6545
Irma Hodžić, 6531
Predmetni nastavnik: Merima Omerika, 6516
Doc.dr. Mugdim Bublin Anela Lavić, 6541
Lemana Korić, 6664
Amina Ćurovac, 6665
UVOD
• DDT (design-driven testing) – dizaj vođen testiranjem - proizvodnja test slučajeva, kako bi verifikovali da su svi naznačeni scenariji završeni
• Testiranje je proces koji bi trebao početi mnogo prije kodiranja
• Testiranje slijedi ubrzo nakon preliminarnog dizajna
Dizajn vođen testiranjem u teoriji
Usvojiti testiranje - pronalazak kvara = pobjeda
Testiranja? kako i kada se koriste?
Za svaki kontrolor na svakom robusnom dijagramu...
...za svaku operaciju na svakoj klasi
Za realne sisteme - elementi dijagrama stanja kao osnova za testove slučajeva
provjera nivoa zahtjeva?
Koristiti matricu slijedivosti
Uraditi scenario nivoa pihvatljivosti
Proširiti teme u testnim scenarijima
Koristiti okvir testiranja kao što je JUnit
Održavanje testova jedinica dobro preciziranim!
Različite vrste testiranja
• Testiranje - skup interativnih i inkremantalnih razvojnih ciklusa
• Test dokazuje da proizvod odgovara specificiranoj namjeni
• veoma čvrsto povezani sa zahtjevima – dokaz da softver odgovara svojoj specificiranoj namjeni
• Test jedinica - testiranje individualnih softverskih komponenti.
Integracioni test - vrši se da se otkriju greške u sučeljima i u interakciji između integrisanih komponenti
Test kompatibilnosti -testiranje da sistem sarađuje dobro sa ostalim „vanjskim“ sistemima, sa kojima se zahtjeva da komunicira
SYSTEM TESTING
Test sistema - funkcionalni i behavioralni dizajn test slučaja.
Test prihvatljivosti - da se utvrdi da li sistem zadovoljava zahtjeve naznačene u ugovoru.
• Beta test - Provodi se od strane krajnjeg korisnika koji nije drugačije uključen u razvoj
Kao i slijedeći testovi:
• Nefunkcionalni test zahtjeva • Test izvodljivosti • Test regresije• Test otpornosti na stres• Test zapremine
Vođenje test slučajeva iz dijagrama robusnosti
• Sa ICONIX Procces-om, ulažemo trud kako bi napisali korištene slučajeve, i identifikujemo objekte koji sudjeluju u korištenom slučaju, kao i funkcije koje ti objekti obavljaju na dijagramu robusnosti .
• Radom sa dijagramom robusnosti, možemo kreirati dijagram test slučaja, koji prikazuje test slučaja za svakog kontrolora.
Korištenje agilnog dodatka za ICONIX/EA
• nterprise Arhitect (EA) ima poseban dodatak koji automatizira mnogo “prijelaznog” posla kada premještamo između dijagrama u ICONIX Process-u.
• dodatak će automatski kreirati set robusnih dijagrama za dijagram korištenog slučaja i dodatak će popuniti sekvencijalni dijagram
• Za potrebe testiranja, dodatak automatski kreira dijagram test slučaja od kontrolora na robusnom dijagramu
• Onda je moguće napisati izvršni test jedinica za svaki test slučaj
Korištenje agilnog dodatka za ICONIX/EA
Vođenje test jedinica sa test slučajeva
• Uputstva za vođenje test jedinica iz test slučajeva:
1. Za svaki test slučaj, kreiramo jednu klasu test jedinica.
2. Za svaki test scenario, kreiramo jednu testnu metodu u klasi testova jedinica.
3. Napisati test jedinica sa ugla kontrolora.
Kratki uvod u JUnit
• Za kodiranje primjera kasnije u ovom poglavlju koristit ćemo JUnit, popularnu Java-baziranu okvirnu test jedinicu.. Iako se izvorni kod može razlikovati ovisno o jeziku/implementaciji,
package test.com.iconixsw.bookstore.web;import junit.framework.*;public class AddToShoppingCartTest extends TestCase { public AddToShoppingCartTest (String testName) { super(testName); } public void testShoppingCartEmpty() throws
Exception { ShoppingCart cart = new ShoppingCart(); assertEquals("Cart should be empty", 0,
cart.getNumItems()); } public void testItemAdded() throws Exception { ShoppingCart cart = new ShoppingCart(); LineItem item = new LineItem(); cart.addItem(item); assertEquals("Cart should contain 1 item", 1, cart.getNumItems()); }}
Imamo primjer klase testa jedinica:
Pisanje efektivnih testova jedinica
• Prije nego počnemo na primjeru, vrijedno je istaći neke najbolje prakse za pisanje dobrih testova jedinica
• Tehnike efektivnih testova jedinica sa perspektivnim dizajnom-vođenog testiranja mogu se sažeti veoma jezgrovito
Dizaj vođen testiranjem u praksi
Dizaj vođen testiranjem u praksi
• Korištenje projekta Internet knjižare• Onda koristimo test slučajeve da
potvrdimo da:
1. detaljni dizajn se poklapa sa korištenim slučajem
2. kod se poklapa sa detaljnim dizajnom i čini ono za šta je namijenjen
Testiranje Prikaz Početne Stranice
• U ovom dijelu, kreirat ćemo test scenario za Kontrolora Prikaz Početne Stranice, najjednostavnijeg u grupi, i onda ćemo napisati JUnit test klasu.
• Test slučaj za ovog kontrolora je jednostavan, zapravo, trebamo samo jedan test scenario za ovaj test slučaj zato što postoji malo toga što može krenuti “naopako”.
Pokretanje testova iz test paketa
package test.com.iconixsw.bookstore;import test.com.iconixsw.bookstore.web.*;import junit.framework.*; public class BookstoreTestSuite { public static Test suite() { TestSuite suite = new TestSuite();
suite.addTestSuite(DisplayHomePageTest.class); // add more tests here . . . return suite; } public static void main(String[] args) { junit.textui.TestRunner.run(suite()); }}
Testiranje Preuzmi Detalje Knjige Kontroler
• U ovom dijelu, kreiramo test scenario za Preuzmi Detalje Knjige Kontroler, i onda pišemo i pokrećemo njegovu JUnit test klasu.
• Da dodamo test slučaj u EA, dvoklikom otvorimo prozorčić Postavke i odaberemo Scenario tab. Onda možemo dodati osnovni i alternativni scenario u test slučaj.
• Sada kada imamo sastavljen test, trebali bi ga pokrenuti kroz JUnit, ali bi prvobitno trebali vidjeti neuspjeh testa kako bi potvrdili da test radi. Da bi to uradili samo ćemo kratko promijeniti initData() metodu.
• Jednostavno smo promjenili 1 u 5 tako da lažni DAO ne vrati knjigu sa ID oznakom 1. Pokretanje testa sada će donijeti slijedeće rezultate:
__________________________________.FTime: 0There was 1 failure:1) testBookIdFound
(test.com.iconixsw.bookstore.dao.RetrieveBookDetailsTest)
junit.framework.AssertionFailedError: ID 1 should be found at test.com.iconixsw.bookstore.dao. RetrieveBookDetailsTest.
testBookIdFound(RetrieveBookDetailsTest.java:29)FAILURES!!!Tests run: 1, Failures: 1, Errors: 0__________________________________
• Na ovaj način možemo se uvjeriti da će test raditi ispravno kada dođe do stvarnog neuspjeha testa. Sada kada vratimo vrijednost ponovo 1 i uradimo ponovo test dobit ćemo slijedeće rezultate:
____________________________________________________________
.Time: 0OK (1 test)____________________________________________________
___________
Deset najvećih grešaka dizajna vođenog testiranjem
• 10. Pretjerivati sa mock(lažnim) objektima
• 9. Duplicirati scenarije alternativnih kurseva u alternativne test scenarije za osnovne kurs kontrolore
• 8. Zaboraviti da povežemo testove sa zahtjevima.
• 7. Ostaviti testiranje nakon što je napisan kod
• 6. Zamijeniti testiranje sa dizajnom
• 5. Ignorisati vruće tačke problema
• 4. Koristiti nasilno testiranje umjesto identifikovanje i ciljanje gorućih problema iz preliminarnog dizajna
• 3. Koristiti pogrešnu vrstu testiranja za pogrešnu situaciju
• 2. Zaboraviti uraditi testiranje uopće.
Testirati toliko
temeljito
da nikada ne
objavite proizvod!!!
Zaključak
• različiti oblici korištenih slučajeva – vođenih testiranjem
• vrste testova koje se koriste -kako i kada?• dizajn vođen testiranjem na primjeru
Internet knjižare • osnovnih i alternativnih scenarija kao i
postupak transformiranja robusnih dijagrama u sekvencijali ili dijagram test slučaja.
Testovi ne dokazuju puno ako nisu uvezani na mikroskopskom
nivou sa zahtjevima!!!
H v a l a n a p a ž n j i
Test passed
T e s t :
Recommended