Embed Size (px)
Citation preview
6/17/2011
1
1
Testiranje elektronskih
sistema (2)
6/17/2011
2
Timski rad je ključ uspeha!!!
2
6/17/2011
3
Testiranje mikroračunarskih sistema
• Izuzev grubih grešaka - otkaza kao što su gubitak napajanja ili takta, operacioni status (stanje) sistemazasnovanog na mikroprocesoru ne može se jasno odrediti tradicionalnim sredstvima.
• Sistemi bazirani na mikroprocesorima se karakterišu kompleksnom bas strukturom, zamršenim vremenskim kompleksnom bas strukturom, zamršenim vremenskim odnosima i još i softverski zavisnim funkcionisanjem. Takve karakteristike mogu da prikriju, odnosno učine nesagledivim izvor greške i dijagnostičku proceduru čine komplikovanom. Kako sistem izvršava operacije pod kontrolom softvera, ne postoji prost odnos izmeñu hardverskih elemenata i logičkih signala. To sveukazuje na činjenicu da je teško lokalizovati otkaz na osnovu radnih simptoma - ponašanja sistema.
6/17/2011
4
Teškoće:• U lokalizaciji otkaza radi otklanjanja, detektovane greške su
posledica najpre nepoznavanja gde je problem: u hardveru, u softveru, ili i u softveru i u hardveru.
• U nekim slučajevima se lako i jasno može odrediti u kojoj oblasti je otkaz, ali u većini slučajeva to nije jednostavno odrediti jer hardverski otkazi mogu ponekad biti maskirani kao softverski otkazi i obrnuto. (Npr. nekorektan rad nekog I/O porta ne mora da znači da je
sam port defektan. Problem može biti u grešci u softveru ili u (Npr. nekorektan rad nekog I/O porta ne mora da znači da je
sam port defektan. Problem može biti u grešci u softveru ili u otkazu u nekom drugom delu hardvera. Ili na primer, logički korektan softver i ispravan logički kontroler mogu se ponašati kao neispravni (u jednom trenutku kao da je kontroler neispravan, a u drugom kao da je softverska sekvenca instrukcija nekorektna) jer nisu ispoštovana vremenska ograničenja koja nameće na primer kontroler. Recimo, neposredno posle upisa komande u kontroler čitanje statusa kontrolera može da idicira neadekvatno stanje kontrolera jer je njemu potrebno "neko vreme" da promeni status.)
6/17/2011
5
• Lokalizaciju uzroka greške komplikujuelektrični otkazi (najčešće prolazni) logičkih signala. Naime, sistem može da otkaže zbog električnih problema kao što su graničnavremena uspona i pada digitalnog signala, ili
Teškoće, nastavak:
vremena uspona i pada digitalnog signala, iliekscesni šum velike amplitude, itd. Takvi otkazi su mogući i u sistemu čiji je projekat logički potpuno korektan i kod kojih se nije desio otkaz u nekoj samoj komponenti, to jest sve komponente sistema su ispravne.
6/17/2011
6
Projektovanje za testabilnost
• Kompleksnost i obimnost današnjih mikroračunarskih sistema i samih integrisanih kola nameću i potrebu razmišljanja o otkrivanju i otklanjanju otkaza sistema, odnosno testiranju još u fazi razvoja specifikacija sistema.
• Korišćenje specijalizovanih alata može da zahteva • Korišćenje specijalizovanih alata može da zahteva nedopustivo dugo vreme za otkrivanje i lokalizaciju otkaza, ako se o tom problemu na vreme nije posvetila potrebna pažnja.
• Projektovanje sistema podrazumeva korišćenje specijalizovanih metoda projektovanja za ostvarivanje mogućnosti sigurnog i efikasnog testiranja (Design for Testability - DFT).
6/17/2011
7
TESTIRANJE SOFTVERA
7
6/17/2011
8
Osnovni modeli testiranja
MODEL OSNOVNI CILJ
• FAZNI MODELDemonstracija: Utvrñivanje da softver
zadovoljava specifikacije
8
zadovoljava specifikacijeDestrukcija: Otkrivanje grešaka implementacije
• MODEL ŽIVOTNOG CIKLUSA Evaluacija: Otkrivanje grešaka u zahtevima,
projektu i implementaciji
Prevencija: Prevencija grešaka u zahtevima,projektu i implementaciji
6/17/2011
9
Fazni modeli i modeli životnog ciklusa
• Fazni modeli polaze od pretpostavke da je izvršenje programa osnovna aktivnost testiranja kroz koju se otkrivaju greške.
• Modeli životnog ciklusa pomeraju aktivnosti
9
• Modeli životnog ciklusa pomeraju aktivnosti testiranja sa kraja projekta na početak, uvodeći kao objekte testiranja, pored implementacije, zahtev i projekat. Testiranje se posmatra kao proces koji je u jakoj interakciji sa aktivnostima razvoja od samog početka projekta.
6/17/2011
10
Demonstracija: prečišćavanje i testiranje
• Razdvajanje pojmova prečišćavanja (debugging) i testiranja.
• Obe ove faze testiranja obuhvataju detekciju, lociranje, identifikovanje i korekcijugrešaka, s tim da se razlikuju ciljevi kojima se
10
grešaka, s tim da se razlikuju ciljevi kojima se teži pri odvijanju svake od aktivnosti.
• Cilj faze prečišćavanja softvera je obezbediti da se program odvija na računaru, dok je cilj faze testiranja obezbediti da softver rešava zadati problem.
6/17/2011
11
Destrukcija
• Definicija testiranja“Testiranje je proces demonstracije da greške nisu prisutne.”
11
• menja se u sledeću:“Testiranje je proces izvršenja programa s namerom da se nañu greške”
6/17/2011
12
Destrukcija, nastavak
• Model destrukcije razdvaja faze prečišćavanja i testiranja:
• U fazi testiranja detektuju se greške, dok se u fazi prečišćavanja greške lociraju,
12
se u fazi prečišćavanja greške lociraju, identifikuju i koriguju.
• Ovaj model se orijentiše na detekciju neispravnosti i implementaciju.
6/17/2011
13
Evaluacija
• Period orijentacije na evaluaciju dolazi sa uvoñenjem standarda u oblasti testiranja softvera.
• Ova metodologija testiranja integriše
13
• Ova metodologija testiranja integriše analizu, pregled i testiranje za vreme svih faza životnog ciklusa softvera.
6/17/2011
14
Prevencija
• Period orijentacije na prevenciju uvodi korišćenje i poboljšanje specifikacija softvera za vreme analize i projektovanja testova kao i korišćenje i poboljšanje koda za vreme izvršenja
14
korišćenje i poboljšanje koda za vreme izvršenja testova.
6/17/2011
15
Prevencija vs. evaluacija
• Model prevencije razlikuje se od modela evaluacije više po mehanizmu nego po cilju.
• Oba modela usmerena su na zahteve i projekat u cilju eliminisanja problema u implementaciji, ali model prevencije u prvi plan stavlja aktivnosti
15
model prevencije u prvi plan stavlja aktivnosti planiranja, analize i projektovanja testova, za razliku od modela evaluacije koji se oslanja na analizu softvera i tehnike pregleda koje su odvojene od samog testiranja.
6/17/2011
16
Evolucija testiranja
VREMENSKI PERIOD MODEL TESTIRANJA
- 1956 Prečišćavanje1957 - 1978 Demonstracija
16
1957 - 1978 Demonstracija1979 - 1982 Destrukcija1983 - 1987 Potvrñivanje1988 - Prevencija
6/17/2011
17
Razvoj softvera
• definisanje zahteva i ciljeva• izrada specifikacija softvera• projektovanje sistema
17
• projektovanje strukture programa• specificiranje interfejsa modula• kodiranje
6/17/2011
18
Prevencija
Tri komplementarna prilaza prevenciji i/ili otkrivanju grešaka koje se potencijalno akumuliraju prolaskom krozsve faze:1. Prvi prilaz je uvoñenje preciznosti u razvoju kako bi se
sprečilo nastajanje grešaka. 2. Drugi prilaz je uvoñenje posebnog verifikacionog
19
2. Drugi prilaz je uvoñenje posebnog verifikacionog koraka nakon svake faze razvoja, imajući za cilj otkrivanje što više grešaka pre no što se preñe na narednu fazu.
3. Treći prilaz predstavlja razdvajanje procesa testiranja po fazama, tako da se posebno testira svaka faza razvoja, čime se postiže fokusiranje na posebne klase grešaka.
6/17/2011
19
Tri faze testiranja
Proces testiranja prolazi kroz tri faze:
• Testiranje modula• Testiranje integracije
20
• Testiranje integracije• Testiranje sistema
6/17/2011
20
Testiranje modula
• Testiranje modula proverava da li se softverski modul ponaša shodno specifikacijama definisanim za vreme faze
21
specifikacijama definisanim za vreme faze detaljnog projektovanja.
6/17/2011
21
Testiranje integracije
• Testiranje integracije: povezuju se grupe prethodno testiranih modula i proverava da li se ponašaju onako kako su se ponašali za vreme njihovog nezavisnog
22
ponašali za vreme njihovog nezavisnog testiranja. Svrha testiranja integracije je da utvrdi da li se svaka ugrañena komponenta ponaša shodno specifikacijama dobijenim u fazi arhitekturnog projektovanja.
6/17/2011
22
Testiranje sistema
• Testiranje sistema: proverava da li se softverski sistem ugrañen u stvarno hardversko okruženje ponaša u skladu sa specifikacijama softverskih zahteva. U slučaju velikih i složenih sistema, koji uključuju više specifikacija softverskih zahteva,
23
uključuju više specifikacija softverskih zahteva, svaka glavna softverska komponenta testira se u odnosu na svoju specifikaciju, zatim se one integrišu i proverava se njihovo kombinovano ponašanje na nivou sistemskih zahteva.
6/17/2011
23
Dvodimenzionalni model vodopada razvojnog ciklusa softvera
24
6/17/2011
24
Relativna cena ispravke greške po fazamaFAZA RELATIVNA CENA ISPRAVKE
Zahtevi 0.1 - 0.2
Projektovanje 0.5
Kodiranje 1
25
Kodiranje 1
Testiranje modula 2
Testiranje prihvatljivosti 5
Održavanje 20
6/17/2011
25
Osnovna klasifikacija metoda testiranja
BLACK-BOX metode WHITE-BOX metode
Podela na klase ekvivalencije Pokrivanje naredbiAnaliza graničnih vrednosti Pokrivanje odluka
26
Analiza graničnih vrednosti Pokrivanje odlukaAnaliza uzročno-posledičnih Pokrivanje uslovagrafova Pokrivanje odluka/uslovaPogañanje grešaka Pokrivanje višestrukih
uslova
6/17/2011
26
WHITE-BOX testiranje bazira se na izvršenju programa, odnosno na pokrivanju logike (izvornog koda) programa, zbog čega se WHITE-BOX
27
programa, zbog čega se WHITE-BOX tehnike naj češće nazivaju tehnikama baziranim na implementaciji za razliku od BLACK -BOX tehika koje se nazivaju tehnikama baziranim na specifikacijama.
6/17/2011
27
Tehnike testiranja bazirane na implementaciji
Tehnike bazirane na implementaciji mogu segeneralno svrstati u dve kategorije:�tehnike usmerene na programske puteve
(path selection techniques),
28
(path selection techniques),�tehnike usmerene na podatke (test data
selection techniques).
6/17/2011
28
� Tehnike usmerene na programske puteve
• Tehnikama usmerenim na programske puteve polaznu osnovu predstavlja reprezentacija programa u obliku usmerenog grafa koji simbolizuje tok
29
usmerenog grafa koji simbolizuje tok upravljanja (control flow diagram), odnosno tok podataka u programu (data flow diagram).
6/17/2011
29
� Tehnike usmerene na programske puteve, nastavak
Tehnike usmerene na programske putevemogu se podeliti na:• tehnike koje pokrivaju tok upravljanja
(control flow coverage),
30
(control flow coverage),• tehnike koje pokrivaju tok podataka (data
flow coverage).
6/17/2011
30
� Tehnike usmerene na podatke
Tehnike usmerene na podatke mogu sepodeliti na:• tehnike bazirane na neispravnostima
31
• tehnike bazirane na neispravnostima(fault-based),
• tehnike bazirane na greškama (error-based).
6/17/2011
31
� Tehnike usmerene na podatke
• Tehnike bazirane na neispravnostimaselektuju testne podatke tako da otkriju odreñene klase neispravnosti, gde se pod neispravnošću podrazumeva pogreška u izvornom kodu, koja dovodi do nemogućnosti izvršenja funkcije
32
izvršenja funkcije• Tehnike bazirane na greškama usmerene su
na otkrivanje specifičnih tipova grešaka, pri čemu se pod greškom podrazumeva aktivnost programera koja dovodi do softvera koji sadrži grešku, a koja prilikom izvršenja programa dovodi do razmimoilaženja izmeñu dobijenih rezultata i pravih, odnosno očekivanih rezultata.
6/17/2011
32
Razvoj tehnika testiranja baziranih na implementaciji• Razvoj tehnika testiranja baziranih na
implementaciji ide u pravcu unapreñenja tehnika baziranih na neispravnostima i tehnika baziranih na greškama u programu.
• Tehnike bazirane na neispravnosti definišu
33
• Tehnike bazirane na neispravnosti definišu klase softverskih grešaka i identifikuju svojstva testova koji će efikasno otkriti njihovo prisustvo.
• Cilj tehnika baziranih na greškama je da identifikuju različite vrste grešaka koje programeri čine za vreme izrade softvera, i da razviju tehniku otkrivanja svih klasa grešaka
6/17/2011
33
Tehnike testiranja bazirane na specifikacijama
• Tehnike bazirane na specifikacijama mogu usmeriti pažnju na one aspekte problema koji su nekorektno implementirani i koji se tehnikama baziranim isključivo na implementaciji mogu otkriti samo slučajno. Zato po mišljenju većine
34
otkriti samo slučajno. Zato po mišljenju većine autora koji se bave teorijom testiranja, pristupi testiranju bazirani na specifikaciji i pristupi bazirani na implementaciji treba da se koriste tako da nadopunjuju jedni druge i da prednosti jedne tehnike pokrivaju mane druge tehnike.
6/17/2011
34
Selekcija testnih primera kroz životni ciklus softvera
Analiza ispecifikacija
zahteva
Arhitekturno projektovanje
Sistemski zahtevi
Specifikacija sprege modula
Selekcija odkorisnika
Selekcija test pri- mera iz specifi-
kacije sprege
Plan testiranja sistema
Plan testiranja integracije
35
Detaljno projektovanje
Implementacija/transformacija
Izvr{enje testova
Specifikacija projekta modula
Realizacija modula
Selekcija test pri- mera iz speci-
fikacije projekta
Selekcija test primera iz koda
Plan testiranjamodula
Plan testiranja modula
6/17/2011
35
36
6/17/2011
36
TESTIRANJE HARDVERA
37
6/17/2011
37
Struktura otkaza
38
6/17/2011
38
Postavljanje izlaznog kriterijuma:
• neotkriveni prekidi <1%• neotkriveni spojevi <1%
• netestirane komponente 0%• nedovoljno testirane komponente <2%• nedovoljno testirane komponente <2%
• testirano samo prisustvo <5%• prisustvo&orijentacija samo <5%
• netestirani otkazi na pinovima <5%• Otkazi pinova testirani u samo jednom stanju <20%
40
6/17/2011
39
Razmotriti testni alat tima
41
6/17/2011
40
Alat za testiranje sistema
Korišćenje instrumentacije opšte namene ne daje potrebnu dijagnostičku moć. Zato su razvijeni specijalizovani alati zaotkrivanje i lokalizaciju otkaza u mikroračunarskim sistemima:
42
mikroračunarskim sistemima:• emulatori u kolu
(prvenstveno mikroprocesora) i • logički analizatori.
6/17/2011
41
Upotrebiti projektne alate
43
6/17/2011
42
Trend kod veza na štampanoj ploči
Veličina i snaga veze
44
broj veza
godina
6/17/2011
43
Uzroci otkaza
temperatura
45
Source: U.S. Air Force Avionics Integrity Program
vlažnost
prašina vibracije
6/17/2011
44
Mogući uzroci otkaza – promene temperature
hladno
46
toplo
Naprezanje termi čkim širenjem
6/17/2011
45
Mogući uzroci otkaza – vibracije
krivljenje zbog naprezanja
47
Kidanje zbog naprezanja
6/17/2011
46
Postupci pri testiranju sistema:
• Vizuelna inspekcija.• Provera izvora napajanja i razvoda napajanja.• Provera statusa CPU-a, odnosno stanja mikroprocesora.• Provera basa i signala na njemu.• Provera memorijskog prostora (operativne memorije)
48
• Provera memorijskog prostora (operativne memorije)• Provera I/O kontrolera - najpre kontrolera za konzolni
ureñaj• Startovanje ugrañenih procedura samotestiranja• Provera kontrolera spoljašnje masovne memorije• Startovanje procedura samotestiranja i testiranja• Provera ostalih kontrolera u mikroračunarskom sistemu
6/17/2011
47
Vizuelna inspekcija
• Provera lemnih tačaka pomoću lupe, mikroskopa, termovizijske kamere, ...
49
6/17/2011
48
Provera izvora napajanja i razvoda napajanja
• Provera izvora kao modula• Provera razvoda napajanja• Provera da li svaki čip ima pravilno
50
• Provera da li svaki čip ima pravilno napajanje
6/17/2011
49
Provera statusa CPU-a, odnosno stanja mikroprocesora
• Provera takta• Provera reseta
51
• Provera samog procesora• Upotreba emulatora
6/17/2011
50
Provera bus-a i signala na njemu
• Pojave na dugim vezama• Prelazne otpornosti
52
6/17/2011
51
Provera operativne memorije
• Provera adresiranja• Provera vremena zapisa i čitanja• Provera informacije (prekid ili kratak spoj,
53
• Provera informacije (prekid ili kratak spoj, višestruki upis, greška oporavka, spavajuća bolest, ...)
6/17/2011
52
Provera ROM-a
54
6/17/2011
53
Provera memorijskog prostora
• Marširajuća 1:10000...0; 11000...0; 11100...0; ...; 11111...1
• Marširajuća 0:
55
• Marširajuća 0:01111...1; 00111..1; 00011...1; ...; 00000...0
• Šah:01010...1; 10101...0; 01010...1; ...
6/17/2011
54
Na kraju ...
56
6/17/2011
55
57
6/17/2011
56
58
