PSW_1_01_00_Uvod_TDD

Projektovanje softvera –

konstrukcija

(Uvod - Predmet rada)

Prof. dr Branko Perišić [email protected]

Mr. Maja Tumba Živanov, asistent [email protected]

PhD student, Igor Zečević, asistent [email protected]

mailto:[email protected]



O predmetu - 1

Cilj predmeta: Osposobiti studente za profesionalnu konstrukciju

softvera zasnovanu na:

• standardizaciji procesa i proizvoda faze dizajna i

konstrukcije softverskih sistema;

• timskom radu, znanjima i veštinama upravljanja

softevrskim projektom;

• primeni standarda vezanih za ARHITEKTURU

SOFTVERA, DIZAJN SOFTVERA i

KODIRANJE

• TESTIRANJU SOFTVERA i INSPEKCIJE

• DOKUMENTOVANJU SOFTVERA

• primeni standarda KVALITETA SOFTVERA

Pregled materije - 1

Osnovni pojmovi konstrukcije softvera.

Arhitektura softvera, objekti, šabloni, okviri i aplikacije.

Primarni prozor, sekundarni prozori, standard dizajna

dijaloga. Konstrukcija 2D grafičkih aplikacija.

Programerske konvencije.

Osnovni paterni u konstrukciji softvera.

Osnovne postavke kvalitetne konstrukcije softvera:

izbor metoda, tehnika i alata za konstrukciju softvera.

Struktura programskog koda, template-biblioteke,

kontejnerske klase – Java SWING i AWT.


Praćenje i evidentiranje manifestacija odstupanja

ponašanja programa od specifikacije i otkrivanje i

evidentiranje grešaka.

Rukovanje izuzecima.

Modelovanje i implementacija mehanizama zaštite i

očuvanja integriteta.


Mere i metrike u procesu konstrukcije softvera.

Testiranje na nivou klasa, unit-a, modula, funkcija.

Izrada test scenarija.

Proces upravljanja konstrukcijom softvera.

Inspekcije koda, agilne i tradicionalne metode

konstrukcije softvera.

Elemetni rukovanja konfiguracijom softvera.

Izrada dokumentacije, samodokumentujući kod,

eksterna dokumentacija i automatsko generisnje

dokumentacije.

Način realizacije

Predavanja i vežbe. (4 + 3)

Timski rad u grupama do 4(četiri) studenata na realizaciji

odabranog softverskog projekta (GeXX)

Način polaganja:

10% Ocene redovnost u nastavi (P).

50% Rad na projektu, ocena i odbrana projekta,

projektna dokumentacija i prezentacija projekta

(komercijalna i tehnička). Projekat je obavezan!

20% Test – projektovanje softvera – znanje

20% Zadatak – projektovanje softvera – veština

Način izvođenja

konačne ocene

Od(poena) Do(poena) Konačna ocena

0 25 Ponoviti

predmet

25 54 ne zadovoljava

55 64 6 (E)

65 74 7 (D)

75 84 8 (C)

85 94 9 (B)

95 100 10 (A)

Literatura

1. Shari Lawrence Pfleeger

SOFTWARE ENGINEERING

Theory and practice, Prentica Hall – 2006.g. Postoji

prevod u izdanju CET-a.

2. Ben Shniederman

DESIGNING THE USER INTERFACE 3. Branko Perišić

PROJEKTOVANJE SOFTVERA – radni

materijal

Korisne adrese:

1. www.swebok.org Software Engineering

Body Of Knowledge

2. www.sei.cmu.edu Software Engineering

Institute CarnegieMellonUniversity.

3. www.omg.org ObjectManagement Group

4. www.google.org

http://www.swebok.org/

http://www.sei.cmu.edu/

http://www.omg.org/

http://www.google.org/

Softverski proizvod!

Softverski proizvod – opšti model

Specifikacija

zahteva

Domen

problema

Specifikacija

dizajna

Domen

Rešenja

Implementacija

Domen izvršenja

veza rafinacije

veza rafinacije

SWEBOK - ponovo

SoftWare

Engineering

Body

Of

Knowledge

Specifikacija i

modelovanje

softvera

Metode razvoja softvera

1. Tradicionalne metode razvoja softvera

2. Agilne metode razvoja softvera

Extreme Programming

Scrum

Crystal Clear

Feature Driven Development

Adaptive Software Development

Dynamic Systems Development Model (DSDM) Methodology

Test-Driven Development

Continuous Integration

Pair Programming

Refactoring

Metode razvoja softvera

1. Tradicionalne metode razvoja softvera

2. Agilne metode razvoja softvera

Extreme Programming

Scrum

Crystal Clear

Feature Driven Development

Adaptive Software Development

DSDM

Test-Driven Development

Continuous Integration

Pair Programming

Refactoring

1. Odaberite neko svojstvo proizvoda!

2. Napišite TEST/TESTOVE!

3. Izvršite sve ranije testove i stvorite uslove

da novi TEST ne prođe!

4. Na bazi (3) konstruišite KOD koji korektno

implementira posmatrano svojstvo!

5. Izvršite SVE TESTOVE i potvrdite da svi

prolaze!

6. Refaktorišite KOD!

7. PONOVITE PROCES!

V-model klasičnog

testiranja

(TDD) - Testovima Upravljan Razvoj?

Motivacija:

– Ako nameravate sprovest testiranje po okončanju projektovanja

softverskog proizvoda iskustva pokazuju da za to tada nećete imati

vremena!

– Rešenje: Konstruišite testove pre konstrukcije KODA! (tada još

uvek imate dovoljno vremena!)

Ako se “stvari” sa projektom komplikuju, obično se javlja

bojazan da “sistem” ne funkcioniše.

– Rešenje: Obavite testiranje u cilju dobijanja poizitivne povratne

informacije (sve još uvek funkcioniše!), ili utvrdite gorku činjenicu da

sistem uopšte ili više ne funkcioniše!

Porast složenosti softverskog proizvoda u fazi projektovanja

obično dovodi do frustracija!

– Rešenje: Počnite sa najjednostavnijim elementima i u malim

koracima povečavajte kompleksnost!


Ako ne posedujete testove za konstuisani kod nemojte ga

KORISTITI niti ISPORUČITI!

– Ovo je jedino moguće ako prvo konstruišete TEST a potom KOD. Na

taj način se postiže bolji stepen pokrivenosti koda testovima

nego u slučaju post-festum testiranja kakvo je npr. FUNKCIONALNO

TESTIRANJE! (BlackBox)

Ako o PERFORMANSI rešenja razmišljate u finalnoj fazi

konstgrukcije proizvoda najčešće nećete moći jednostavno

“malo pobojšati performansu” sistema.

– Rešenje: Ponovno iskoristite jedinične (UNIT) testove kao testove

performanse i to u toku procesa razvoja. Nikada ne odgađajte test

performanse za KRAJ!(Iznenađenja mogu biti KOBNA!)


“Pre nego što pristupite kodiranju, razmislite štakod treba da implementira (radi). Konstruišitetest koji će pozivati metode koje još niste ninapisali”

TEST nije nešto što treba “raditi”, već je tonešto što treba “napisati” a zatim pokretatijednom, dva puta, tri puta,...

On je “parče” KODA

Zbog toga je testiranje po prirodi “automatizovano”

Potrebno ga je ponovo izvršiti čak i nakon “minornih” izmena(Regresiono testiranje)

TDD je programiranje koje za cilj imaminimizaciju rizika otkaza, investiranje “danas”da bi smo izbegli otkaze “sutra”!

TDD - Faze

Konstrukcija

TESTA

Kompilacija

Otklanjanje grešaka

u kompilaciji

Pokretanje testa

sa ciljem da “ne prođe”

Konstrukcija

KODA

Pokretanje testa sa

ciljem da “prođe”

Refaktorisanje koda

(i testiranje)

Testiranje

softvera

Osnovni

koncepti i

definicije

Nivoi Tehnike Mere Proces

Osnovi testiranja softvera – 29

Osnovni koncepti i definicije – 30

Terminologija

Teorijski osnov

Nefunkcionalnost

Greške

Izbor

Adekvatnost

Kriterijumi prestanka testiranja

Efektivnost

Ograničenja

Nedostižni putevi

Mogućnost testiranja


VERIFIKACIJA i VALIDACIJA U USLOVIMA

POSTOJANJA PROGRAMSKOG KODA

Testiranje:Testiranje softvera predstavlja dinamičku verifikaciju

ponašanja programa na konačnom uzorku test

slučajeva, pogodno odabranih iz obično beskonačnog

domena izvršavanja, u odnosu na očekivano

ponašanje.

Uspešan test je onaj test koji DETEKTUJE ranijeneotkrivenu grešku.

Dobar test je onaj test koji ima veliku verovatnoću otkrivanja

još neotkrivenih grešaka.


BITNI PREDUSLOVI

Izvršni oblik programa:

(implicira da su otklonjene sve sintaktičke greške, ispoštovani svi interni

standardi i svi delovi koda su na raspolaganju)

Opis očekivanog ponašanja:

(kriterijumi za proveru korektnosti programa)

Mogućnost uvida u ponašanje programa:

(obezbeđena izolacija programa koji se testira od ostatka sistema)

Opis domena funkcija:

(deo specifikacije koji definiše domen za koji se očekuje da program radi)

Metod za utvrđivanje da li se uočeno ponašanje slaže sa očekivanim

ponašanjem:

(izbeći pretpostavku da odsustvo patološkog ponašanja podrazumeva

korektnost)


(1) PLANIRANJE TESTA

Izrada plana testiranja, sa aspekta procesa testiranja, ima isti značaj

kao i specifikacija dizajna sa aspekta dizajna.

(2) PRIPREMA TEST PODATAKA

Osnovni problem je, uz poznat domen podataka i definisano

očekivano ponašanja, kako generisati skup test podataka koji

poseduje veliku verovatnoću otkrivanja još neotkrivenih grešaka?

(3) IDENTIFIKACIJA GREŠAKA (ERRORS)

Provera svih test-izlaza i dokumentovanje rezultata. Ako se ne izoluje

nijedna greška PROVERITI KOMPLETNOST SKUPA TEST-

PODATAKA!

(4) TESTIRANJE PO KOREKCIJI (regression testing)


Myer-Debugging principles:

Principi lociranja grešaka (Error-Locating Principles)

(a) Razmislite!

(b) Ako dođete do bezizlazne situacije, odložite za kratko

dalji rad.

(c) Ako dođete do bezizlazne situacije, opišite problem

nekom drugom.

(d) Koristite alate za otkrivanje grešaka (debugging

tools).

(e) Izbegavajte eksperimentisanje. Koristite ga kao

POSLEDNJE SREDSTVO.


Principi otklanjanja grešaka (Error-Repairing Principles)

(a) Gde ima jedna greška verovatno postoji i druga.

(b) Ispravite grešku, ne jedino njene simptome.

(c) Verovatnoća korektnosti ispravke nije 1.

(d) Verovatnoća korektnosti ispravke je obrnuto

proporcionalna veličini modula/programa.

(e) Budite svesni mogućnosti da OTKLANJANJE

GREŠKE MOŽE UNETI NOVE GREŠKE.

(f) Proces otklanjanja grešaka vas trebaPRIVREMENO VRATITI u fazu DIZAJNA.

(g) Menjajte IZVORNI KOD nikako OBJEKTNI!


EVOLUCIJA POJMA TESTIRANJE (po Boris Beizer-u)

FAZA - 0. Ne postoji razlika između testiranja i debugiranja,

bez debugiranja testiranje nema smisla.

FAZA - 1. Cilj testiranja je pokazati da softver radi.

FAZA - 2. Cilj testiranja je POKAZATI DA SOFTVER NE

RADI!

FAZA - 3. Cilj testiranja nije da dokaže BILO ŠTA već da

smanji RIZIK DA SOFTVER NE RADI na

prihvatljiv nivo.

FAZA - 4. Testiranje nije čin. To je mentalna disciplina koja

rezultira softverom niskog rizika.

STATIČKA ANALIZA analizira se tekst programa

DINAMIČKA ANALIZA analizira se ponašanje programa

Testiranje

softvera

Osnovni

koncepti i

definicije



Nivoi testiranja – 32

Objekat

Unit

Integration

System

Element

Prihvatanje

Instalacija

Alfa-Beta

Usklađenost

Funkcionalnost

Korektnost

Pouzdanost

Uticaj

Performansa

Opterećenje

Oporavak

Konfigurisanje

Korišćenje

Testiranje

softvera

Osnovni

koncepti i

definicije



Tehnike testiranja – 34

Na osnovu čega su

generisani?

Intuicija

Ad-hok

Specifikacija

Simetrično razdvajanje

Analiza graničnih vrednosti

Tabele odlučivanja

Konačni automati

Formalne specifikacije

Random testiranje

Kod

Dijagrami toka i poziva

Tokovi kontrola

Tokovi podataka

Greške

Pogađanje grešaka

Mutacije

Unittest

Unittest

Unittest

Intergation

test

Function

test

Performance

test

Acceptance

test

Installation

test

Integrated

modules

Functioning

system

Verified,

validated

software

.

.

.

Design

specification

System functional

requirements

Performance

requirements

Accepted

systemCustomer

requirements

specification

User

environment

System in use

Component

code

Component

code

Component

code

YAHOO!

Kriterijumi okončanja testiranja

Kada se testiranje završava?

Ovo je još uvek predmet istraživanja!

1. Jedan pogled: Testiranje se nikada ne završava… teret sejednostavno prebacuje sa projektanata na korisnike (kupce)!

2. Drugi pogled: Testiranje se završava kada više nemamosredstava da ga dalje finansiramo ili kada više za njeganema vremena!

3. Oslonac na statističke metode:

Pretpostavimo da broj grešaka logaritamski opada u funkcijivremena testiranja!

Utvrdimo broj grešaka u jediničnom periodu testiranja!

Odradimo aproksimaciju logaritamskom krivom!

Da li možemo zaključiti da: “smo u skladu sa eksperimentalnovalidiranim statističkim modelom dovoljno testirali ako sa 95%sigurnosti u najmanje 995 od 1000 sati rada dobijamo korektnufunkcionalnost!”

Projektovanje sofvera

Poglavlje 03.

Objekt Orijentisano

Testiranje

Objekt Orijentisano Testiranje

Strategije OO testiranja je nužno

razviti i primenjivati u fazama:

– Analize i Dizajna

– Testiranja KLASA (Jedinično testiranje)

– Integracije rešenja (Integracioni testovi)

– Validacije rešenja (Validacioni testovi)

– Izgradnje sistema (Sistemski testovi)

Analiza i Dizajn: Testiranje počinje evaluacijom OOA i OOD

modela. (Specifikacija i modelovanjesoftvera)– Kako testirati OOA modele (ZAHTEVI i Slučajevi

korišćenja USE-CASE)?

– Kako testirati OOD modele (Model KLASA,Dijagrami sekvence)?

PROLASCI kroz strukturu, IZRADAPOTOTIPOVA

Formalne inspekcije KOREKTNOSTI,KOMPLETNOSTI i KONZISTENTNOSTI

Aspekt Programiranja: Na koji način Objektna Orijentacija čini proces

tertiranja različitim u odnosu na strukturno iliprocedurno programiranje?

– Pojam “jedinično” (‘unit’) se sužava zbogenkapsulacije koju nameće klasifikacija (izborKLASA)

– Integracija se fokusira na KLASE i njihovKONTEKST u sklopu scenarija slučajevakorišćenja (Napomena: Slučajevi korišćenja seimplementiraju saradnjom klasa!) ili modelaizvršavanja (Npr. sinhronizacija tred-ova)

– Validacija se može i dalje oslanjati nakonvencionalne metode funkcionalnog testiranja(BlackBox).

Testiranje Analize i Dizajna

Sintaktička korektnost:

– Da li se UML notacija korektno koristi?

Semantička korektnost:

– Da li model korespondira sa realnim problemom?

– Da li se UML koristi u skladu sa pravilima?

– Da li je specifikacija dizajna korektna i razumljiva

(prisutne su sve klase i metode u sklopu UML

dijagrama)?

Testirenje konzistentnosti:

– Nekonzistentan model poseduje elemente koji se

jevljaju u jednom a ne javljaju u drugim delovima

modela!

Testiranje modela klasa

1. Analiza dijagrama slučajeva korišćenja i poređenje sa UMLdijagramom klasa. Neophodno je proveriti da li svaka saradnja klasa korektno modeluje

neki slučaj korišćenja i da li su svi slučajevi korišćenja prepoznati usklopu saradnje klasa. Proveriti adekvatnost delegiranih odgovornosti.(Napomena: Dobro definisana klasa poseduje mali broj jasnodefinisanih odgovornosti i implementira ih korektno!)

– Primer: naplatno mesto (blagajna). Očitavanje kreditne kartice – kao odgovornost klase koja podržava

plaćanje kreditnom karticom, se omogućava ako i samo ako suzadovoljeni uslovi koji se odnose na pravila saradnje vezana zakreditnu karticu!

2. Invertovanje veza u cilju potvrde da svaka saradnja preko koje sepokreće neki servis stvarno i dobija zahteve od strane racionalnogizvora.– Primer: Kreditnoj kartici se upućuje iznos koji je neophodno skinuti sa

računa?

Da li ste do sada testirali produkte Analize i Dizajna Vašegsoftverskog proizvoda?– Ako niste, šta mislite ko to treba da uradi?

Testiranje OO programa

Testiranje klasa Integracionotestiranje

Validaciono testiranjeSistemsko

testiranje

[1] Testiranje Klasa (UnitTesting)

Najmanja jedinica koju možemo testirati je KLASA koja neštoenkapsulira!

Neophodno je testirati svaku metodu kao deo hijerarhijeklasa jer HIJERARHIJA definiše KONTEKST u kome se onekoriste.

PRISTUP:

– Testirajte SVAKU METODU (i konstruktor) unutar klase!

– Testirajte ponašanje (vrednosti atribute) klase za svakumetodu!

U čemu se testiranja klasa bitno razlikuje odkonvencionalnog testiranja?– Konvencionalno testiranje se fokusira na transformaciju

ULAZA u IZLAZE. Testiranje KLASA se prvo fokusira naPOJEDINAČNE METODE, a zatim na njihovu SEKVENCU ucilju provere STANJA klase.

– White-box testiranje se i dalje može primeniti! (testiranjestrukture koda)

Jedinično testiranje (Unit testing)

Testiranje koje počinje sa najugneždenijom

komponentom koda.

Jedinično testiranje se fokusira na svaku

komponentu sistema.

Jedinične testove bi, u opštem slučaju,

trebalo sprovoditi u toku faze konstrukcije

Cilj je da se ispitaju komponente na sve

puteve kroz kod, strukture podataka i

granične uslove.

Uobičajene greške koje se

otkrivaju pri jediničnom testiranju:

– Pogrešno shvaćen ili nekorektan

redosled izračunavanja

– Rad sa pomešanim tipovima

– Nekorektna inicijalizacija

– Nepreciznost pri izračunavanju

– Nekorektna simbolička pretstava izraza

Poruke greške pretstavljaju ključne

element koji pomažu prilikom praćenja

uzroka problema.

Poruke treba da budu jasne i u

direktnoj korelaciji sa posmatranom

situacijom.

Proces testiranja klasa

Klasa koja se testira

Test slučaj

rezultati

Tester

Kako?

Zašto

ciklus?

Modul

stub stub

drajver

interfejs

lokalne strukture

podataka

nezavisne putanje

putanje rukovalaca

greškama

test slučaj

Kreiranje Test-slučajeva pri

testiranju klasa

1. Identifikujte JEDINSTVEN Test-slučaj- Eksplicitno povežite test-slučaj sa KLASOM i/ili METODOM koja/i je predmet testiranja.

2. Definišite SVRHU testa!

3. Svaki test-slučaj treba da sadrži:

a. Listu poruka i operacija koje će se pokrenuti ili pojaviti kaoPOSLEDICA izvršavanja TESTA.

b. Listu IZUZETAKA koji se mogu desiti u fazi testiranjaOBJEKTA!

c. Spisak SPOLJNJIH USLOVA koje je neophodno podesiti(promene u okruženju koje se moraju obaviti da bi se testiranjeodvijalo na korektan način)

d. Dodatne informacije koje mogu doprineti RAZUMEVANJU iliIMPLEMENTACIJI testa.

Savremeni alati za automatizaciju procesa jediničnog testiranja zadovoljavaju ove uslove.

Jedinično testiranje (Unit testing)– 35

Provera koda

• prolazak kroz kod (code walkthrough)

• inspekcija koda (code inspection)

Dokazivanje korektnosti programa

formalne tehnike (Ignorišu strukturu i

sintaksu programskog jezika. Mogu pokazati

da je dizajn komponente korektan ali

nemogu ništa reći o korektnosti

implementacije.)

• konverzija programskog koda u

njegov logički ekvivalent

• opis koda posretstvom potpunih

formalnih iskaza

• generisanje skupa teorema na

osnovu formalnih iskaza

• dokazivanje teorema

Jedinično testiranje (Unit testing) – 36

Dokazivanje korektnosti programa - nastavak

simboličko izvršavanje koda (vodi

računa o strukturi i sintaksi

programskog jezika. Koristi simbole

umesto promenljivih.)

automatsko dokazivanje teorema

Potpunost testova (Component testing) – 37

Testiranje iskaza – (Svaki iskaz u programskoj

komponenti se bar jednom izvrši u toku nekog

testa.)

Testiranje grana – (Za svaku tačku odlučivanja u

kodu programske komponente, svaka grana se

bira najmanje jednom u toku nekog testa.)

Testiranje putanja – (Svaka različita putanja kroz

kod programske komponente izvršava se bar

jednom u toku nekog testa.)


Testiranje putanje definicija-korišćenje – (Svaka

putanja od definicije bilo koje promenljive do

tačke njenog korišćenja se prolazi bar jednom u

toku nekog testa.)

Testiranje svih korišćenja – (Skup testova sadrži

najmanje jednu putanju od svake definicije od

svakog dostupnog korišćenja u dosegu te

definicije.)

Testiranje svih korišćenja u iskazima – (Za svaku

promenljivu i svaku definiciju te promenljive test

sadrži najmanje jednu putanju od definicije do

iskaz.)


Testiranje svih korišćenja u izračunavanjima – (Za

svaku promenjlivu i svaku definiciju te

promenljive test sadrži najmanje jednu putanju od

definicije do izraza izračunavanja.)

Testiranje toka transakcija

Izazovi testiranja klasa

ENKAPSULACIJA: – Teško je obezbediti “OTISAK-TRAG” (a snapshot) aktivnosti koje

klasa sprovodi bez PROŠIRIVANJA osnovnog skupa metodaklase metodama koje VIZUALIZIRAJU STANJE KLASE!

NASLEĐIVANJE i POLIMORFIZAM:– Svaki novi kontekst korišćenja (PODKLASE) zahteva ponavljanje

svih testova zbog toga što ranije testirana metoda može bitidrugačije implementirana u sklopu novog konteksta(POLIMORFIZAM).

– Druge metode (koje nisu nužno povezane sa metodom koja jepredmet testiranja) u sklopu podklase mogu REDEFINISATImetodu koja je predmet testiranja!

White-box testovi:– Analiza putanja, uslova, toka podataka i ciklički testovi se mogu

primeniti na svaku pojedinačnu METODU, ali NE TESTIRAJUDEJSTVA (INTERAKCIJE) između METODA!

Šta (prema Graham Dorothy R. 1996.) čini testiranje objekt-orijentisanih sistema lakšim odnosno težim 44

ModularnostNasleđivanje

Brži razvoj

Jednostavne

metode

Ponovno

korišćenje

Jednostavna

identifikacija

interfejsa

Enkapsulacija

Polimorfizam

Dinamičko

vezivanje

Složeni

interfejsi

Složenija

integracija

Lakšim čine Težim čine

Značajni aspekti domena testiranja u kojima se objekt-orijentisani sistemi razlikuju od tradicionalnih – 45

Planiranje i

upravljanje

Simulacija i

testiranje

opterećenja

Sprovođenje

testiranja

Razvoj testova

Analiza zahteva i

validacija

Generisanje

test scenarija

Analiza izvornog

koda

Analiza

prekrivanja

• mali broj alata podržava validaciju zahteva koji

su iskazani u formi objekata i metoda

• mnogi alati koji podržavaju generisanje scenarija

ne podržavaju objektne modele

• večina metrika vezanih za kod odnose se na

procedurne sisteme

• kako je izvor složenosti objektnih sistema

interakcija među objektima testiranje koda i

metode koje se odnose na kod gube na značaju.

“Slučajno” – (Random) testiranje klasa

1. Identifikujte METODE KLASE!

2. Definišite OGRANIČENJA vezana za njihovo korišćenje (npr.klasamora prvo biti inicijalizovana)

3. Identifikujte minimalnu test-sekvencu – (niz operacija koji opisujeminimalni životni vek klase)

4. Generišite niz slučajnih, ali validnih, test sekvenci – ( na ovajnačin se testiraju kompleksnije putanje u složenijim životnim tokovimaklase)

Primer:1. Pretpostavimo da Klasa-Račun, u sklopu bankarske aplikacije, poseduje

metode: otvaranje, podešavanje, uplata, isplata, provera stanja, pregledpromena i zatvaranje.

2. Minimalni životni vek uključuje: OTVARANJE a potom ZATVARANJEračuna.

3. Otvaranje – podešavanje – uplata – isplata – zatvaranje!

4. Otvaranje – podešavanje – uplata –* [uplata | isplata| provera stanja |pregled promena] – isplata – zatvaranje.

Generišite slučajne sekvenca na bazi gornjeg uzorka!


TESTIRANJE NA BAZI STRUKTURE

(WHITE-BOX)

(1) TESTIRANJE PUTEVA

(1.1.) SVI PUTEVI BAR JEDNOM U TOKU

TESTA (generalno nedostižno)(1.2.) PREKRIVANJE ISKAZA

(Statement testing coverage)

(1.3.) PREKRIVANJE GRANA

(Branch testign coverage)


TESTIRANJE NA BAZI FUNKCIONALNOSTI(Black-box)

1. DA LI RADI ONO ŠTO JE SPECIFICIRANO?

2. PONAŠANJE PROGRAMA:

(1) OČEKIVANI IZLAZ:

Za skup korektnih ULAZA znamo kakav izlaz treba biti. Ako se to ne dešava ---> BAR JEDNA GREŠKA.

(2) ODBIJANJE OBRADE AKO ULAZ NE PRIPADA DOMENU

(3) ISKLJUČENE MOGUĆNOSTI


(1) GREŠKE U ZAHTEVIMA:

(2) GREšKE U FUNKCIONALNOSTI i MOGUĆNOSTIMA

(3) STRUKTURALNE GREŠKE (structural bugs)

(4) GREŠKE U PODACIMA (Data)

(5) IMPLEMENTACIJA i KODIRANJE

(6) GREŠKE U INTEGRACIJI SOFTVERA

(7) GREŠKE U ARHITEKTURI SISTEMSKOG SOFTVERA

(8) DEFINISANJE i IZVRŠENJE TESTA

(9) NESPECIFICIRANE GREŠKE (ostale)

Greške u zahtevima

1.1. Netačna formulacija zahteva

1.2. Greška u logici

1.3. Nekompletnost zahteva

1.4. Mogućnost verifikacije

1.5. Pretstavljanje zahteva

1.6. Zahtev se promenio

1.2.1. NELOGIČAN

1.2.2. NERAZUMAN

1.2.3. NEDOSTIŽAN

1.2.4. NEKONZISTENTAN

1.1.1. NEKOREKTAN ZAHTEV

1.1.2. NEPOŽELJAN ZAHTEV

1.1.3. NEPOTREBAN ZAHTEV

1.3.1. NEJEDNOZNAČAN

1.3.2. NEKOMPLETAN

1.3.3. PRESPECIFICIRANNEMOGUĆE GA JE

VERIFIKOVATI I/ILI TESTIRATI 1.5.1. PREDSTAVLJANJE

ZAHTEVA JE NEADEKVATNO

1.5.2. NIJE U SKLADU SA

STANDARDIMA1.6.1. PROMENA OSOBINA

1.6.2. PROMENA DOMENA

1.6.3. PROMENA SPREGE SA

OKOLINOM



(2) GREŠKE U FUNKCIONALNOSTI i MOGUĆNOSTIMA








Greške u funkcionalnosti i mogućnostima

2.1. Korektnost osobina

2.2. Kompletnost svojstava

2.3. Kompletnost funkcionalnih varijanti

2.4. Greške u sklopu domena

2.5. Korisničke poruke i dijagnostika

2.6. Izuzci

2.2.1. NEPOSTOJEĆE

2.2.2. NESPECIFICIRANO

2.2.3. DUPLICIRANO SVOJSTVO

POGREŠNO SHVAĆENO

SVOJSTVO ILI INTERAKCIJA

2.3.1. NEPOSTOJEĆA

2.3.2. DODATNA NEPOTREBNA

2.3.3. DUPLICIRANA VARIJANTA 2.4.1. NESHVAĆEN DOMEN

2.4.2. NEKOREKTAN DOMEN

2.4.3. PROBLEMI SA GRANIČNIM

VREDNOSTIMA

12.5.1. NEKOREKTNE

KORISNIČKE PORUKE

2.5.2. NEKOREKTNE

DIJAGNOSTIČKE PORUKE 2.6.1. NEKOREKTNO

RUKOVANJE IZUZECIMA











Strukturalne greške

3.1. Kontrola toka i sekvenciranje

3.2. Greške pri procesiranju

3.1.1. NEDOSTIŽNI PUTEVI

3.1.2. NEDOSTIŽAN KOD

3.1.3. DUPLA LOGIKA, NEPOTPUNA

LOGIKA, NELOGIČNOST KONTROLNIH

PREDIKATA

3.1.4. GREŠKA U IZBORU VARIJANTI

3.1.5. PETLJE IMAJU NEKOREKTNU

POČETNU ILI KRAJNJU VREDNOST,

INKREMENT ili USLOV

3.1.6. NEKOREKTNA INICIJALIZACIJA

STANJA KONTROLE ili NEKOREKTNO

STANJE

3.2.1.GREŠKA U BAZNOM ALGORITMU

3.2.2.ARITMETIČKI PROBLEMI PRI

EVALUACIJI ARITMETIČKIH IZRAZA

(nekorektan operator, operand, nekorektno

ugneždenje zagrada, nekorektan znak)

3.2.3.GREŠKA KOD STRING OPERACIJA

3.2.4.PROBLEMI U INICIJALIZACIJI

3.2.5.PROBLEMI U SINHRONIZACIJI

3.2.6.PROBLEMI VEZANI ZA PRECIZNOST

3.2.7.PROBLEMI VEZANI ZA MEHANIZAM

INTERNE KONVERZIJE TIPOVA KOD

MEŠANJA TIPOVA

3.2.8.PROBLEMI VEZANI ZA OSLOBAĐANJE

RESURSA (cleanup)











Greške u podacima

4.1. Definicija podataka i struktura

4.2. Pristup i rukovanje podacima

4.1.1. NEKOREKTAN TIP U SKLOPU

DEFINICIJE

4.1.2. GREŠKA PRI DIMENZIONISANJU

4.1.3. NEKOREKTNA INICIJALNA ili

PODRAZUMEVANA (default) VREDNOST

4.1.4. OPSEG PROMENLJIVE (globalni a

treba lokalni i obrnuto)

4.1.5. PODATAK JE STATIČKI A TREBA

BITI DINAMIČKI ( i obrnuto)

4.1.6. NEDOVOLJAN PROSTOR

4.1.7. GREŠKA PRI PREKRIVANJU

ZONA PODATAKA

4.2.1. NEKOREKTAN TIP PODATKA, TIP

TRANSFORMACIJE ili JEDINICE ISKAZIVANJA

4.2.2. DIMENZIJE POGREŠNO

INICIJALIZOVANE

4.2.3.ALTERNATIVNI NAZIVI DINAMIČKI

DUPLICIRANI

4.2.4.PRISTUP POGREŠNOM OBJEKTU

4.2.5.PREKRŠAJ PRAVA PRISTUPA

4.2.6.ANOMALIJE U TOKOVIMA PODATAKA

4.2.7.GREŠKA PRI ZAKLJUČAVANJU

PODATAKA

4.2.8.GREŠKA PRI RESTAURACIJI PODATAKA

4.2.9.NEODGOVARAJUĆE RUKOVANJE

GRANIČNIM VREDNOSTIMA











Greške u implementaciji i kodiranju

5.1. Greške pri kodiranju i kucanju

5.2. Kršenje standarda i stila programiranja

5.3. Greška u dokumentaciji

5.2.1. SUVIŠE KOMPLEKSAN KONTROLNI TOK

5.2.2. UGNEŽDENJE PETLJI ili POZIVA DUBLJE

NEGO ŠTO DOZVOLJAVA IMPLEMENTACIONI

JEZIK.

5.2.3. KRŠENJE STANDARDA PRI DEKLARISANJU

PROMENLJIVIH

5.2.4. KRŠENJE STANDARDA PRI PRISTUPU

PODACIMA

5.2.5. KRŠENJE STANDARDA PRI POZIVU i

POVRATKU

5.2.6. GREŠKA U KORIŠĆENJU SKRAĆENICA

5.2.7. GREŠKA U KORIŠĆENJU KOMENTARA

5.1.1. NEPOZNAVANJE ili

POGREŠNA INTERPRETACIJA

SINTAKSE PROGRAMSKOG JEZIKA

5.1.2. GREŠKE PRILIKOM KUCANJA

5.3.1. NEKOREKTNA DOKUMENTACIJA

5.3.2. NEKONZISTENTNA DOKUMENTACIJA

5.3.3. PREOPŠIRNA DOKUMENTACIJA

5.3.4. NEKOMPLETNA DOKUMENTACIJA

5.3.5. NEPOSTOJANJE DOKUMENTACIJE











Greške u integraciji softvera

6.1. Interni interfejs

6.2. Eksterni interfejs i sinhronizacija 6.2.1. PROBLEMI SA

PREKIDIMA/TRAP-ovima

6.2.2. PROBLEMI SA

RUKOVAOCIMA UREĐAJA

6.2.3. PROBLEMI SA U/I

VREMENOM ODZIVA

6.2.4. PROBLEMI SA

PROPUSNOŠĆU KANALA

6.1.1. GREŠKA PRI SPREZANJU SA

INTERNIM MODULOM/IMA

6.1.2. PARAMETRI SPREGE NISU

KOREKTNI

6.1.3. POVRATNE VREDNOSTI NISU

KOREKTNE











Greške u arhitekturi sistemskog softvera

7.1. Greške u operativnom sistemu

7.2. Arhitektura softvera

7.2.1. GREŠKA PRI ZAKLJUČAVANJU

7.2.2. GREŠKA PRI SINHRONIZACIJI

7.2.3. GREŠKA U RUKOVANJU PRIPRITETIMA

7.2.4. GREŠKE PRI PROCEDURI OPORAVKA

7.2.5. GREŠKE U SKLOPU ACCOUNTING-

SISTEMA

7.2.6. NEKOREKTNA DIJAGNOSTIKA

7.2.7. NEKOREKTNA KONFIGURACIJA

(SYSGEN)

7.2.8. NEKOREKTNA ili NEADEKVATNA

PARAMETRIZACIJA OKRUŽENJA

7.1.1. GREŠKE KOD POZIVA i

PRENOSA PARAMETARA

7.1.2. GREŠKE PRI ALOKACIJI

PROSTORA











Greške u definisanju i izvršenju testova

8.1. Greške u dizajnu testa

8.2. Greške u izvršenju testa

8.3. Greške u test-dokumentaciji

8.2.1. GREŠKE U KOMANDAMA,

INICIJALIZACIJI BAZE PODATAKA,

KONFIGURACIJI BAZE ili SAMOM ČINU

VERIFIKACIJE

8.1.1. NERAZUMEVANJE ZAHTEVA

8.1.2. PRETPOSTAVLJEN JE

NEKOREKTAN REZULTAT

8.1.3. PRETPOSTAVLJEN JE POGREŠAN

TOK

8.1.4. NEKOREKTNA INICIJALIZACIJA

TESTA, TEST STRUKTURE PODATAKA,

SEKVENCE, KONFIGURACIJE ili

METODA VERIFIKACIJE











Model testiranja – neophodna podrška

PROCEDURE UNDER TEST DRIVERSTUB

CALL CALL

ACCESS TO NONLOCAL VARIABLES

Procedura

koja se

testira

Pristup globalnim promenljivim

POZIV POZIV

Model testiranja – oslonac na verifikacioni pattern

Zahtev Verifikator

Rezultat

verifikacije

Test

skriptovi

Skupljač

događaja

Test okruženje

Radno okruženje za testiranje


Poglavlje 00.01.

Testiranje Softvera


Poglavlje 00.02

Principi konstrukcije

softvera

Konstrukcija Softvera

1. Osnovni pojmovi konstrukcije softvera

2. Upravljanje konstrukcijom softvera

3. Praktični aspekti konstrukcije softvera

Osnovni pojmovi konstrukcije

softvera

Osnovni pojmovi konstrukcije softvera obuhvataju:

• Minimiziranje složenosti

• Predviđanje promena

• Konstruisanje sa ciljem efektivne naknadne

verifikacije

• Standarde u konstrukciji softvera

Prva tri principa se primenjuju i u sklopu dizajna

softvera (prisetimo se Specifikacije i modeliranja

softvera).


softvera -2

Minimiziranje složenosti

Ograničena mogućnost čoveka da simultano rukuje

složenošću i da održava tu sposobnost u dužem

vremenskom intervalu. (od 5 do 9 parametara)

Stavljanjem akcenta na kreiranje programskog koda

koji je jednostavan, pregledan i čitljiv pre nego

“inteligentan” ili “sofisticiran”.

Presudnu ulogu u tom procesu ima standardizacija


softvera -3

Predviđanje promena

Softver je, kao proizvod procesa inženjerstva, podložan

promenama u vremenu, tako da je mogućnost predikcije

(predviđanja) stepena njegovih promena i direktnog

uticaja tih promena na arhitekturu softverskog

proizvoda, od ključnog značaja za njegovu efikasnost i

efektivnost u uslovima operativnog korišćenja.

Sa druge strane softverski proizvodi imaju direktan

uticaj na promene u domenima primene i danas postaju

nezaobilazni elementi složenih poslovnih i/ili tehnoloških

sistema sa kojima koegzietiraju i koevoluiraju.

Te promene imaju direktne reperkusije na principe

konstrukcije softvera sa ciljem da se njegovo kasnije

menjanje učini što je moguć jednostavnijim.


softvera - 4

Konstruisanje “radi” verifikacije

Pod ovim pojmom se podrazumeva konstrukcija

softvera na način da je rezidualne greške, ugrađene u

proizvod u procesu njegovog inženjerstva, moguće, kroz

sve faze ciklusa, detektovati, izolovati i otkloniti.

Posebne tehnike koje obezbeđuju konstrukciju sa ciljem

efektivne naknadne verifikacije uključuju:

poštovanje standarda kodiranja sa ciljem omogućavanja

jednostavnog uvida i revidiranja koda,

sprovođenje jediničnog testiranja (unit testing),

organizovanje koda tako da je proces testiranja moguće

maksimalno automatizovati i

ograničavanje ili potpuno eliminisanje složenih i teško

razumljivih jezičkih konstrukcija.

Osnovni pojmovi konstrukcije softvera - 5

Standardi u konstrukciji softvera:

• standarde u domenu programskih jezika (Java, C++, C#, i sl.)

• standardi metoda komuniciranja (formati dokumenata i

sadržaja dokumenata)

• standarde vezane za platforme ( npr. standardizovani

interfejs za programski pristup funkcijama jezgra

operativnog sistema – sistemski pozivi)

• standardizovane alate i formalizme (npr. notacioni standardi,

UML i sl.)

Izbor spoljašnjih (globalnih) standarda posebno bitno utiče na:

programske jezike

alate za konstrukciju softvera i

specifikacije interfejsa

(npr. IEEE, ISO, Object Management Group (OMG) i sl.)

Upravljanje konstrukcijom

softvera

Oblast znanja iz domena upravljanja konstrukcijom

softvera podrazumeva komponente znanja i veština koje

obuhvataju:

Modele konstrukcije softvera (Construction Models)

Planiranje konstrukcije softvera (Construction

Planing)

Merenja u procesu konstrukcije softvera

(Construction Measurement)

Praktični aspekti konstrukcije

softvera

Pod konstrukcijom softvera podrazumevamo aktivnost

posredstvom koje softverski proizvod treba da dostigne

proizvoljna i nekada haotična ograničenja nametnuta

od strane realnog sveta i da ih egzaktno implementira.

S obzirom na bliskost procesa konstrukcije ambijentu

realnog okruženja u kome projektovani softverski proizvod

treba da funkcioniše u skladu sa definisanim ograničenjima,

konstrukcija softvera je značajnije upravljana

praktičnim aspektima u poređenju sa drugim

oblastima znanja, tako da se može reći da je softversko

inženjerstvo najbliže eksploatacionoj praksi baš u fazi

konstrukcije.

Praktični aspekti konstrukcije

softvera - 1

Sa aspekta SWEBOK sistematizacije praktični aspekti

konstrukcije softvera obuhvataju:

1. Dizajn u fazi konstrukcije (Construction Design)

2. Jezike za konstrukciju softvera (Construction Languages)

3. Kodiranje (Coding)

4. Testiranje u fazi konstrukcije (Construction Testing)

5. Ponovno (višekratno) korišćenje (Reuse)

6. Kvalitet konstrukcije (Construction Quality)

7. Integraciju softverskog proizvoda (Integration)

Dizajn u fazi konstrukcije

U sklopu određenih metodoloških pristupa a posebno u

inženjerskoj praksi značajan deo aktivnosti vezanih za dizajn

se pomera u fazu konstrukcije.

Elementi vezani za detaljni dizajn mogu se jedino efektivno

analizirati i kreirati u fazi konstrukcije budući da je to

poslednja faza u kojoj aspekti realnog domena primene

mogu uticati na proizvode iz domena rešenja (softver).

Dizajn u fazi konstrukcije se metodološki ne razlikuje od

aktivnosti dizajna u fazi dizajna softverskih proizvoda.

Jedina razlika leži u nivou detalja koji su u središtu pažnje

aktivnosti dizajna.

Jezici za konstrukciju

Pod pojmom jezici za konstrukciju podrazumevaju se

svi oblici komunikacije posredstvom kojih čovek može

specificirati izvršno programsko rešenje.

Razlikujemo sledeće kategorije jezika za konstrukciju:

Konfiguracioni jezici (configuration languages)

Jezici “slagalice” (Toolkit languages)

Programski jezici (Programming languages)

Jezici za konstrukciju - 1

Konfiguracioni jezici (configuration languages)

Najjednostavniji oblik jezika za konstrukciju predstavlja

konfiguracioni jezik koji omogućava projektantima-

programerima (softver inženjerima) izbor, iz ograničenog

skupa unapred definisanih mogućnosti, podešavanja

“generičkog” softverskog proizvoda u skladu sa

specifičnostima konkretne “instance”.

Tekstualne konfiguracione datoteke koje se koriste u

sklopu Microsoft Windows ili UNIX operativnih sistema

predstavljaju tipične primere produkata konfiguracionih

jezika.

Druga grupa primera obuhvata podešavanja stilova (look

and feel) grafičkog korisničkog interfejsa (npr. Windows

look and feel i sl.)


Jezici “slagalice” (Toolkit languages)

Jezici ove kategorije se koriste za konstrukciju

softverskog proizvoda na bazi:

integrisanih skupova ponovno iskoristivih

komponenti karakterističnih za određene

domene primene.

Mnogo su složeniji u odnosu na konfiguracione jezike i

mogu se kategorizirati kao:

aplikativni programski jezici (npr. skript jezici) ili

predstavljati jednostavne skupove interfejsa prema

komponentama-gradivnim elementima aplikacije.



Programski jezici predstavljaju najfleksibilnije jezike za

konstrukciju koji poseduju minimalnu ili nikakvu

zavisnost od domena primene tj. univerzalni su u sklopu

paradigme na kojoj su zasnovani (strukturni, objektni,

procedurni i sl.) ili modela životnog ciklusa softvera koji

se u konkretnom procesu inženjerstva primenjuje.

Za njihovo efikasno i efektivno korišćenje potrebno je

daleko više znanja, veštine i iskustva nego što je to slučaj

kod prethodne dve grupe jezika za konstrukciju.



U literaturi je moguće uočiti tri osnovne grupe notacija

koje se koriste u sklopu programskih jezika:

LINGVISTIČKE

FORMALNE

VIZUALNE


Lingvističke notacije se međusobno razlikuju na

osnovu atomičkih sintaktičkih konstrukcija

(reči) i složenih sintaktičkih konstrukcija

(rečenica ili iskaza).

Ispravnim korišćenjem jezičkih elemenata, uz

potpuno razumevanje značenja jednostavnih i

kompozitnih lingvističkih konstrukcija, moguće

je trenutno intuitivno razumevanje sleda

događaja u slučaju njihovog operativnog

izvršenja.


Formalne notacije se manje zasnivaju na intuitivnom,

svakodnevnom, značenju reči i iskaza a više na

konstrukcijama koje su podržane: preciznim,

jednoznačnim i formalnim (npr. matematičkim)

definicijama.

Formalne konstrukcione notacije i formalne metode

predstavljaju srž gotovo svih oblika sistemskog

programiranja, kod koga: preciznost, vremenska

usklađenost i mogućnost automatskog testiranja

predstavljaju važnije osobine u odnosu na intuitivno

jasnoću koja proizilazi iz oponašanja konstrukcija

govornih jezika. Formalne konstrukcione notacije koriste

precizan način kombinovanja simbola čime se izbegava

nejednoznačnost interpretacija tipičnu za konstrukcione

jezike koji oponašaju govorne.


Vizualne notacije se manje zasnivaju na

tekstualnim predstavama kararterističim za

lingvističke i formalne konstrukcione notacije već

na neposrednoj vizualnoj interpretaciji i

raspoređivanju grafičkih komponenti koje

predstavljaju elemente arhitekture konstruisanog

softvera.

Vizualne konstrukcione notacije su na izgled

ograničene činjenicom da nije jednostavno

formulisati “složene” konstrukcije jedino uz

oslonac na pomeranje grafičkih komponenti na

monitoru korisničke radne stanice.


Uprkos tome, one mogu predstavljati

izuzetno efikasno sredstvo u situacijama

kada se celokupan, ili veči deo,

programerskog posla zasniva na izgradnji i

podešavanju grafičkog korisničkog interfejsa

programskog proizvoda čije će detaljne

funkcionalne karakteristike i dinamičko

ponašanje biti utvrđeni naknadno (npr.

izrada prototipa i sl.).

Kodiranje

Kodiranje predstavlja aktivnost u procesu konstrukcije

softvera koja rezultira najdetaljnijom specifikacijom

ponašanja softverskog proizvoda, a podrazumeva:

Tehnike za kreiranje razumljivog i čitljivog izvornog

koda, uključujući i principe imenovanja programskih

elemenata i fizičkog rasporeda izvornog koda (source

code layout)

Korišćenje klasa, pobrojanih tipova, promenljivih,

imenovanih konstanti i ostalih elemenata koji čine

strukturu izvornog koda programskog rešenja.

Korišćenje kontrolnih struktura

Rukovanje greškama i izuzecima

Rukovanje tokom programa

Kodiranje - 2

Iskorišćenje resursa uz oslonac na mehanizme

međusobnog isključivanja i disciplinu u pristupu serijski

iskoristivim resursima (uključujući niti ili zaključavanje

tabela odnosno baze podataka)

Organizacija izvornog koda (iskazi, moduli, klase,

jedinice-units, paketi ili druge strukture)

Dokumentovanje izvornog koda (Code dokumentation)

Podešavanje koda (Code tuning)

Objektni model softverskog sistema

*

*

*

*

<<call>>

<<call>>

<<Implementira>>

<<call>>

SoftverskiProizvod

{abstract}

+ Oznaka softverskog proizvoda : int

ElementSoftverskogProizvoda

{abstract}

KompozicijaEementa

GUIelement

{abstract}

KonfiguracijaProizvoda

{abstract}

- GetConfig () : int

PrimarniProzor

{abstract}

Meni

{abstract}

Toolbar

{abstract} PodlogaZaCrtanje

{abstract}

KomandnoDugme

{abstract}

Tabela

{abstract}

Forma

{abstract}

Polje

{abstract}

RukovalacIzuzetcima

{abstract}

RukovalacGreskama

{abstract}

Repozitorijum

+

+

GetResultSet ()

SaveResultSet ()

: void

: void

LokalizacijaProizvoda

- GetLocalParam () : int

PersonalizacijaProizvoda

- GetProfile () : int

RepozitorijumElement


Poglavlje 00.02

Principi konstrukcije softvera

Documents

PSW_1_01_00_Uvod_TDD