Dizajn vodjen testiranjem

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 :