Ras II Kolokvijum
Settings
-
+
.
- 1.U fazi implementacije softvera, programmer prevodi:
- A.
Zahteve korisnika u programski kod
- B.
Dokumentaciju u programski kod
- C.
Opise iz projekata u programski kod
- D.
Testove u programski kod
- 2.Svrha pisanja pseudokoda je:
- A.
Brzo ispitivanje razlicitih alternativa implementacije
- B.
Brzo testiranje napisanih programa
- C.
Laka izrada dokumentacije
- D.
Lako pronalazenje gresaka u kodu
- 3.Visekratno upotrebljive komponenete su komponenete koje:
- A.
Su ranije generisane tako da da se mogu ponovo primeniti
- B.
Su istrosene zbog ceste primene
- C.
Se generisu sa namerom da se mogu kasnije koristiti
- D.
Se sastoje iz nekoliko delova
- 4.4.Da bi se realizovala neka programska komponeneta,potrebno je utvrditi:
- A.
Strukture podataka koje ce biti koriscene
- B.
Testove koji ce biti primenjeni
- C.
Algoritme koji ce biti primenjeni
- D.
Nacin dokumentovanja komponenete
- 5.Programska dokumentacija moze biti:
- A.
Osnovna
- B.
Unustasnja
- C.
Spoljasnja
- D.
Sistemska
- 6.U procesu razvoja softvera,faza testiranja ima veliki znacaj zato sto:
- A.
Predstavlja fazu nakom koje se softver isporucuje naruciocu
- B.
Direktno utice na kvalitet softvera i buduci izgled proizvodjaca
- C.
Sluzi kao osnova za projektovanje sistema
- D.
Omogucava korisniku da bolje razume sistem
- 7.Softverske greske koje se obicno otklanjaju kompajliranjem programa:
- A.
Osnovne greske
- B.
Sintaksne greske
- C.
Sistemske greske
- D.
Semanticke greske
- 8.U slucaju nestanka napajanja,softverski sistem se moze oporaviti sprovodjenjem sledecih aktivnosti:
- A.
Ne preduzimati nista,vec nastaviti sa radom po dolasku napajanja
- B.
Izbrisati nekoliko transakcija koje su prethodile nestanku napajanja
- C.
Nakon ukljucivanja strujnog agregata,nastaviti sa radom
- D.
Zapamtiti poslednje transakcije i ponoviti ih po dolasku napajanja
- 9.Svrha testiranja softvera je da se:
- A.
Dokaze da program ispravno radi
- B.
Pronadju greske u programu
- C.
Korisnik uveri da su ispunjeni njegovi zahtevi
- D.
Dokaze da je program kvalitetan
- 10.Razlozi za uvodjenje posebnog tima za testiranje softvera su:
- A.
Tim za testiranje je subjektivniji od programera
- B.
Mnogi programeri,programiranje shvataju licno,kao dokaz njihove inteligencije i sposobnosti
- C.
Izbegava se konflikt izmedju osecaja odgovornosti za greske i potrebe da se one pronadju
- D.
Tim za testiranje usporava proces razvoja,pa su greske redje
- 11.Testiranje funkcionalnosti svake komponenete nezavisno od ostatka sistema naziva se:
- A.
Jedinicno testiranje
- B.
Primarno testiranje
- C.
Integraciono testiranje
- D.
Osnovno testiranje
- 12.Testiranje softvera se odvija u 5 faza,Oznaciti tacan redosled:
- A.
Jedinicno testiranje – integraciono testiranje – sistemsko testiranje – test prihvatanja – instalacioni test
- B.
Jedinicno testiranje - test prihvatanja - sistemsko testiranje – instalacioni test – integraciono testiranje
- C.
Sistemsko testiranje - integraciono testiranje - jedinicno testiranje - test prihvatanja - instalacioni test
- D.
Instalacioni test - jedinicno testiranje - integraciono testiranje - test prihvatanja - sistemsko testiranje
- 13..Radi jedinicnog testiranja modula u sistemu sa vecim brojem komponenata potrebno je razviti programsko okruzenje koje sadrzi:
- A.
Servere i klijente
- B.
Module i testove
- C.
Drajvere i stabove
- D.
Klase i objekte
- 14.Da bi se proverilo da li je programer ispravno protumacio dizajn pri pisanju programskog koda,formira se posebna grupa za pregled koda koja koristi sledece metode:
- A.
Letimicni pregled
- B.
Inspekciju koda
- C.
Objektivni pregled
- D.
Detaljni pregled
- 15.Metodi bele i crne kutije se sprovode u okviru:
- A.
Jedinicnog testiranja
- B.
Integracionog testiranja
- C.
Sistemskog testiranja
- D.
Uvodnog testiranja
- 16.Metod podele na klase ekvivalencije ima sledece osobine:
- A.
Razvrstava ulazne podatke u reprezentativne klase ekvivalencije
- B.
Formira medjusobno disjunktne klase ekvivalencije
- C.
Testira komponentu za sve vrednosti ulaza iz svake klase ekvivalencije
- D.
Formira medjusobno zavisne klase ekvivalencije
- 17.Metod testiranja pomocu uzrocno posledicnih grafova sprovodi se putem cetiri aktivnosti: 1-formiranje test primera,2-generisanje tabele odlucivanja,3-identifikovanje uzroka i posledica na osnovu specifikacije i 4-generisanje uzrocno posledicnog grafa,oznaciti tacan redosled
- A.
2-3-4-1
- B.
3-2-4-1
- C.
3-4-2-1
- D.
4-1-3-2
- 18.Integracija komponeneta koje su prosle jedinicno testiranje u jedinstven sistem radi daljeg testiranja,moze se vrsiti prema:
- A.
Sendvic integracija
- B.
Integracija po sirini
- C.
Integracija od dna ka vrhu
- D.
Otvorena integracija
- 19.Integraciono testiranje po principu velikog praska
- A.
Je najcesce koriscen metod
- B.
Ima vrlo malu verovatnocu uspesnosti
- C.
Koristi se samo u slučaju vrlo malih sistema
- D.
Omogucava lako nalazenje gresaka
- 20.Pri testiranju performansi sistema,testovi kapaciteta proveravaju:
- A.
Zahteve koji se odnose na vremena izvrsenja pojedinih funkcija i vremena odziva
- B.
Rad sistema na operativnim granicama u kratkom vremenskom periodu
- C.
Kako sistem obradjuje velike kolicine podataka
- D.
Kako sistem reaguje na otkaz
- 21.Pri testiranju performansi sistema,regresivni testovi
- A.
Se koriste samo jednom
- B.
Se koriste vise puta
- C.
Proveravaju da li je doslo do loseg rada funckija koje nisu obuhvacene konkretnom izmenom
- D.
Proveravaju da li je doslo do loseg rada funckija u kojoj je doslo do neke izmene
- 22.Izdvajanje dela programskog koda koji se odnose na ulazne i izlazne podatke u posebne komponente naziva se:
- A.
Lokalizacija ulaza i izlaza
- B.
Pseudokod
- C.
Testiranje ulaza i izlaza
- D.
Modelovanje ulaza i izlaza
- 23.Pseudokod se pise na
- A.
Visim programskim jezicima(C,...Java)
- B.
Prirodnom jeziku
- C.
Obicnom jeziku uz koriscenje sintaksnih elemenata iz postojecih programskih jezika
- D.
UML-u koriscenjem razlicitih dijagrama
- 24..Pri realizaciji neke programske komponente izbor struktura za cuvanje podataka:
- A.
Ne utice na efikasnost programa
- B.
Utice na slozenost programa
- C.
Ne moze da utice na izbor programskog jezika
- D.
Moze se preuzeti iz dizajna
- 25.Programeri cesto ulazu napor da neki algoritam realizuju tako da se sto brze izvrsava,cime se umnozava programski kod.Zbog toga se mogu javiti sledece posledice:
- A.
Vreme generisanja koda se produzava
- B.
Potrebno je manje test primera
- C.
Teze je razumeti napisan kod
- D.
Buduce izmene se lakse sprovode
- 26.Oznaciti tacna tvrdjenja u vezi sa kontrolnim strukturama koje se koriste pri realizaciji neke programske komponente:
- A.
Kontrolne strukture ne treba preuzimati iz dizajna sistema
- B.
Kontrolne strukture treba izabrati tako da se izbegnu veliki skokovi u programu
- C.
Kontrolne strukture treba da budu sto uniformnije
- D.
Kontrolne strukture upravljaju tokom izvrsavanja programa
- 27.Komentari u datotekama sa programskim kodom predstavljaju:
- A.
Unutrasnju programsku dokumentaciju
- B.
Spoljasnju programsku dokumentaciju
- C.
Osnovnu programsku dokumentaciju
- D.
Sistemsku programsku dokumentaciju
- 28.Zaglavlje koje se nalazi na pocetku datoteke sa programskim kodom kojim se realizuje neka komponenta sadrzi:
- A.
Test primere za komponentu
- B.
Naziv komponente i njeno mesto u sistemu
- C.
Nacin na koji se pristupa komponenti
- D.
Spisak slicnih komponenata u sistemu
- 29.Komentari u programskom kodu:
- A.
Se pisu levo od linija koda
- B.
Se pisu tokom izrade koda
- C.
Su brojni kada se koriste ilustrativna imena promenljivih
- D.
Sadrze samo informacije koje nisu vidljive iz koda
- 30.Dokumentacija koja opisuje sistem sa opsteg aspekta naziva se:
- A.
Unutrasnja dokumentacija
- B.
Spoljasnja dokumentacija
- C.
Osnovna dokumetacija
- D.
Sistemska dokumentacija
- 31.Za softverske greske i otkaze vaze sledeca tvrdjenja:
- A.
Greska je uzrok pojave nezeljenog efekta,a otkaz je sam taj efekat
- B.
Otkaz je uzrok pojave nezeljenog efekta,a greska je sam taj efekat
- C.
Otkazi se moraju ispraviti,dok otklanjanje gresaka nije uvek izvodljivo
- D.
Greske se moraju ispraviti,dok otklanjanje otkaza nije uvek izvodljivo
- 32.Softverske greske nastale usled lose implementacije postupka rada sa ulaznim podacima nazivaju se:
- A.
Sintaksne greske
- B.
Greske u postupku obrade
- C.
Greske u preciznosti
- D.
Ulazne greske
- 33.Softverske greske koje nastaju zbog toga sto primenjene formule ne mogu da daju rezultate sa potrebnim brojem decimala nazivaju se:
- A.
Greske zbog performansi
- B.
Greske u postupku obrade
- C.
Greske u preciznosti
- D.
Greske u vremenskoj koordinaciji
- 34.Softverske greske koje nastaju zbog nedovoljnih kapaciteta koriscenih struktura podataka nazivaju se
- A.
Greske zbog performansi
- B.
Greske u postupku obrade
- C.
Greske zbog prekoracenja
- D.
Greske u vremenskoj koordinaciji
- 35.Softverske greske koje nastaju kada sistem ne postize zatevanu brzinu rada,protok podataka i sl.nazivaju se:
- A.
Greske u postupku obrade
- B.
Greske zbog performansi
- C.
Greske zbog prekoracenja
- D.
Sintaksne greske
- 36.Greske u softveru koje nastaju zbog neodgovarajucih opisa sistema nazivaju se:
- A.
Sintaksne greske
- B.
Semanticke greske
- C.
Greske u kodu
- D.
Greske u dokumentaciji
- 37.Softverske greske se pojavljuju zbog neuskladjenosti redosleda izvrsavanja procesa nazivaju se:
- A.
Greske zbog prekoracenja
- B.
Greske zbog performansi
- C.
Greske u postupku obrade
- D.
Greske u vremenskoj koordinaciji
- 38.Softverske greske koje nastaju zbog ne pridrzavanja propisanih procedura nazivaju se:
- A.
Greske zbog nepostovanja standarda
- B.
Greske zbog performansi
- C.
Greske u vremenskoj koordinaciji
- D.
Proceduralne greske
- 39.Prilikom testiranja slozenog softverskog proizvoda,potrebno je obaviti sledece vrste testiranja
- A.
Primarno i sekundarno
- B.
Jedinicno,integraciono i sistemsko
- C.
Objektivno i subjektivno
- D.
Osnovno i dodatno
- 40.Testiranje saradnje i komunikacije izmedju komponenata sistema sa ciljem dobijanja kompletnog sistema koji radi,naziva se:
- A.
Komunikaciono testiranje
- B.
Integraciono testiranje
- C.
Povezano testiranje
- D.
Zavrsno testiranje
- 41.Testiranje da li sistem u potpunosti ispunjava sve zahteve korisnika tako da moze da bude isporucen,naziva se:
- A.
Jedinicno testiranje
- B.
Integraciono testiranje
- C.
Sistemsko testiranje
- D.
Korisnicko testiranje
- 42.Verifikacija softverskog sistema se radi putem
- A.
Jedinicnog i sistemskog testiranja
- B.
Integracionog i sistemskog testiranja
- C.
Sistemskog testiranja
- D.
Jedinicnog i integracionog testiranja
- 43.Validacija softverskog sistema se radi putem
- A.
Jedinicnog testiranja
- B.
Integracionog testiranja
- C.
Sistemskog testiranja
- D.
Jedinicnog i integracionog testiranja
- 44.Program koji simulira komponenetu koja poziva modul koji se testira naziva se:
- A.
Drajver
- B.
Stab
- C.
Podprogram
- D.
Interfejs
- 45.Program koji simulira modul koja se poziva iz komponenete koja se testira naziva se:
- A.
Drajver
- B.
Stab
- C.
Tester
- D.
Klaster
- 46.Metod pregleda koda u kome programer prezentira kod,a zatim se vodi diskusija u cilju pronalazenja gresaka,naziva se:
- A.
Inspekcija koda
- B.
Letimicni pregled
- C.
Detaljan pregled
- D.
Prezentacioni pregled
- 47.Metod pregleda koda u kome se provera koda i dokumentacije radi prema prethodno pripremljenoj listi pitanja naziva se:
- A.
Letimicni pregled
- B.
Metod liste
- C.
Provera sposobnosti
- D.
Inspekcija koda
- 48.Testiranje programa kao zatvorene kutije nepoznatog sadrzaja kod koje se vide samo ulazi i izlazi predstavlja
- A.
Metod Bele kutije
- B.
Metod crne kutije
- C.
Metod neprovidne kutije
- D.
Metod providne kutije
- 49.Testiranje programa kao otvorene kutije cija je unutrasnjost poznata predstavlja
- A.
Metod Bele kutije
- B.
Metod crne kutije
- C.
Metod neprovidne kutije
- D.
Metod providne kutije
- 50.Po metodu crne kutije razvijene su sledece tehnike funkcionalnog testiranja
- A.
Pokrivanje odluka
- B.
Podela na klase ekvivalencije
- C.
Pokrivanje iskaza
- D.
Uzrocno-posledicni graf
- 51.U metodu podele na klase ekvivalencije test primeri se formiraju tako da:
- A.
Jedan test primer moze da se primeni na sto vise legalnih klasa ekvivalencije
- B.
Se za svaku legalnu klasu ekvivalencije pise poseban test primer
- C.
Se za svaku nelegalnu klasu ekvivalencije pise poseban test primer
- D.
Jedan test primer moze da se primeni na sto vise nelegalnih klasa ekvivalencije
- 52.Analiza granicnih vrednosti se obavlja prema sledecim MAJERSOVIM preporukama:
- A.
Ako ulazni(izlazni)uslov predstavlja opseg vrednosti,testove treba napisati za krajeve opsega i za vrednosti odmah do krajeva.
- B.
Ako ulazni uslov precizira broj mogucih vrednosti,testove treba napisati za sve vrednosti
- C.
Ako je ulaz(ili izlaz)programa uredjen skup podataka,testove treba napisati za prvi i poslednji element u skupu
- D.
Ako je ulaz(ili izlaz)programa uredjen skup podataka,testove treba napisati samo za prvi element u skupu
- 53.Tehnika funkcionalnog testiranja koja omogucava automatsko generisanje test primera na osnovu zahteva,naziva se:
- A.
Podela na klase ekvivalencije
- B.
Analiza granicnih vrednosti
- C.
Uzrocno-posledicni grafovi
- D.
Pokrivanje iskaza
- 54.Po metodu bele kutije razvijene su sledece tehike strukturnog testiranja
- A.
Pokrivanje odluka
- B.
Podela na klase ekvivalencije
- C.
Pokrivanje uslova
- D.
Analiza grenicnih vrednosti
- 55.Testiranje programa tako da se svaki iskaz u njemu izvrsi bar jednom(kako bi se znalo da li u njemu postoji greska),naziva se:
- A.
Pokrivanje iskaza
- B.
Pokrivanje uslova
- C.
Izvrsavanje iskaza
- D.
Provera uslova
- 56.Testiranje programa tako da se svaka grana uslovnog iskaza izvrsi bar jednom,naziva se:
- A.
Pokrivanje iskaza
- B.
Pokrivanje odluka
- C.
Pokrivanje uslova
- D.
Pokrivanje testa
- 57.Testiranje programa tako da se svaka elementarna komponenata nekog slozenog uslova uzme vrednost iz dozvoljenog i nedozvoljenog skupa vrednosti,naziva se:
- A.
Pokrivanje iskaza
- B.
Pokrivanje izraza
- C.
Pokrivanje uslova
- D.
Pokrivanje odluka
- 58.Integracija komponeneta koje su prosle jedinicno testiranje u jedinstven sistem radi daljeg testiranja,moze se vrsiti prema sledecim strategijama:
- A.
Integracija po principu velikog praska
- B.
Postepena integracija
- C.
Integracija od vrha ka dnu
- D.
Hijerarhijska integracija
- 59.Integraciono testiranje koje se izvodi tako sto se sistem povezuje u celinu ukljucivanjem svih komponenata odjednom,a zatim se kao celina testira,naziva se:
- A.
Integracija po principu velikog praska
- B.
Integracija od vrha ka dnu
- C.
Sendvic integracija
- D.
Integracija od dna ka vrhu
- 60.Integraciono testiranje koje se izvodi tako sto se sistem najpre organizuje u hijerarhiju na cijem vrhu se nalazi glavni program,a zatim se testiranje obavlja po nivoima,pocevsi od najnizeg,naziva se:
- A.
Sendvic integracija
- B.
Integracija od dna ka vrhu
- C.
Integracija po principu velikog praska
- D.
Integracija od vrha ka dnu
- 61.Integraciono testiranje koje se izvodi tako sto se sistem organizuje u tri sloja,a zatim se testiranje obavlja tako da konvergira ka srednjem sloju,naziva se:
- A.
Integracija po principu velikog praska
- B.
Integracija od vrha ka dnu
- C.
Integracija od dna ka vrhu
- D.
Sendvic integracija
- 62.Integraciono testiranje od dna ka vrhu
- A.
Najvaznije komponente testira poslednje
- B.
Ne korsiti se u sistemima sa velikim brojem visekratno upotrebljivih komponenata
- C.
Najvaznije greske otkiriva vec na pocetku testiranja
- D.
Koristi se kada se vecina komponenata predstavlja funkcije opste namene koje se pozivaju iz drugih modula
- 63.Integraciono testiranje od vrha ka dnu
- A.
Prvo testira najvazije komponente
- B.
Ne zahteva generisanje stabova
- C.
Moze da bude po sirini i po dubini
- D.
Znacajne greske otkriva u kasnoj fazi testiranja
- 64.Sendvic integracija u fazi testiranja
- A.
Ne zahteva generisanje stabova
- B.
Organizuje komponenete u 3 sloja A,B i C
- C.
Lako se izvodi
- D.
Kombinuje stategije od dna ka vrhu i od vrha ka dnu
- 65.Sistemsko testiranje se odvija u cetiri faze:
- A.
Testiranje performansi – funkcionalno testiranje – instalaciono testiranje – testiranje prihvatljivosti
- B.
Testiranje prihvatljivosti - testiranje performansi - funkcionalno testiranje - instalaciono testiranje
- C.
Instalaciono testiranje - testiranje prihvatljivosti - funkcionalno testiranje - testiranje performansi
- D.
Funkcionalno testiranje - testiranje performansi - testiranje prihvatljivosti - instalaciono testiranje
- 66.Prilikom sistemeskog testiranja softvera,provera rada integracionog sistema prema zahtevima koje je postavio kupac,naziva se:
- A.
Testiranje performansi
- B.
Testiranje prihvatljivosti
- C.
Instalaciono testiranje
- D.
Funkcionalno testiranje
- 67.Prilikom sistemeskog testiranja softvera,provera nefunkcionalnih zahteva koje softver treba da ispuni po pitanju brzine , dr.naziva se:
- A.
Testiranje performansi
- B.
Testiranje prihvatljivosti
- C.
Instalaciono testiranje
- D.
Funkcionalno testiranje
- 68.Prilikom sistemeskog testiranja softvera,provera pri kojoj kupci testiraju softver i proveravaju da li on odgovara njihovom shvatanju zahteva naziva se:
- A.
Testiranje performansi
- B.
Testiranje prihvatljivosti
- C.
Instalaciono testiranje
- D.
Funkcionalno testiranje
- 69.Testiranje softvera u operativnom okruzenju naziva se
- A.
Testiranje performansi
- B.
Testiranje prihvatljivosti
- C.
Instalaciono testiranje
- D.
Funkcionalno testiranje
- 70.Funkcionalno testiranje u okviru sistemskog testiranja
- A.
Ima malu verovatnocu otkrivanja gresaka
- B.
Izvode programeri koji su pisali programski kod
- C.
Koristi test primere napravljene na osnovu specifikacije zahteva
- D.
Izvodi se po principu crne kutije,tj.proverava da li sistem obavlja neku funkciju,ne vodeci racuna o komponenti koja je za nju odgovorna
- 71.Pri testiranju performansi sistema,testovima konfiguracije se utvrdjuje:
- A.
Da li je realizacija interfejsa sa drugim sistemima iz okruzenja u skladu za zahtevima
- B.
Da li su odredjene funkcije dostupne iskljucivo onim korisnicima kojima su namenjene
- C.
Kako sistem obradjuje velike kolicine podataka
- D.
Ponasanje softvera u razlicitim hardversko/softverskim okruzenjima
- 72.Pri testiranju performansi sistema testovi opterecenja proveravaju:
- A.
Ponasanje softvera u razlicitim hardversko/softverskih okruzenjima
- B.
Kako sistem reaguje na otkaz
- C.
Rad sistema na operativnim granicama u kratkom vremenskom periodu
- D.
Da li su odredjene funkcije dostupne iskljucivo onim korisnicima kojima su namenjene
- 73.Pri testiranju performansi sistema testovi kapaciteta proveravaju:
- A.
Zahteve koji se odnose na vremena izvrsenja pojedinih funkcija i vremena odziva
- B.
Rad sistema na operativnim granicama u kratkom vremenskom periodu
- C.
Kako sistem obradjuje velike kolicine podataka
- D.
Kako sistem reaguje na otkaz
- 74.Pri testiranju performansi sistema,testovi kompatibilnosti proveravaju:
- A.
Ponasanje softvera u razlicitim hardversko/softverskim okruzenjima
- B.
Da li je sistem stabilan
- C.
Da li je realizacija interfejsa sa drugim sistemima iz okruzenja u skladu sa zahtevima
- D.
Da li su odredjene funkcije dostupne iskljucivo onim korisnicima kojima su namenjene
- 75.Pri testiranju performansi sistema,testovi bezbednosti ispituju:
- A.
Da li sistem moze da prevazidje otkaz usled gubitka napajanja
- B.
Rad sistema na operativnim granicama u kratkom vremenskom periodu
- C.
Da li su odredjene funkcije dostupne iskljucivo onim korisnicima kojima su namenjene
- D.
Da li se aplikacija lako koristi
- 76.Pri testiranju performansi sistema,vremenski testovi proveravaju:
- A.
Zahteve koji se odnose na vremenske uslove u kojima sistem radi (vlaga,temperatura i sl.)
- B.
Rad sistema pri maksimalnom opterecenju
- C.
Zahteve koji se odnose na vremena izvrsenja pojedinih funkcija i vremena odziva
- D.
Redosled izvrsenja funkcija
- 77.Pri testiranju performansi sistema,testovi okruzenja analiziraju:
- A.
Ponasanje softvera u razlicitim hardversko/softverskim okruzenjima
- B.
Zahteve koji se odnose na vremena izvrsenja pojedinih funkcija i vremena odziva
- C.
Sposobnost sistema da radi na lokaciji na kojoj je instaliran (vlaga,temperatura i sl.)
- D.
Da li je realizacija interfejsa sa drugim sistema iz okruzenja u skladu sa zahtevima
- 78.Pri testiranju performansi sistema,testovi oporavka ispituju:
- A.
Sposobnost sistema da radi na lokaciji na kojoj je instaliran
- B.
Kako sistem ispravlja sintaksne greske
- C.
Kako sistem reaguje na pojavu gresaka pri gubitku napajanja,gubitku podataka i sl.
- D.
Kako sistem reaguje na povecan broj korisnika
- 79.Pri testiranju performansi sistema,testovi upotrebljivosti analiziraju:
- A.
Korisnost primljenih struktura podataka
- B.
Vremena izvrsenja pojedinih funkcija
- C.
Estetski aspekt aplikacije
- D.
Konzistentnost korisnickog interfejsa
- 80.Testovi performansi koji proveravaju da li su sva predvidjena upustva u vezi sa sistemom zaista napisana nazivaju se:
- A.
Testovi upotrebljivosti
- B.
Testovi okruzenja
- C.
Testovi dokumentacije
- D.
Testovi konfiguracije
- 81.Pri testiranju performansi sistema,testovi odrzavanja proveravaju:
- A.
Estetski aspekt aplikacije
- B.
Napisanu dokumentaciju
- C.
Pomagala namenjena laksem nalazenju gresaka nakon isporuke
- D.
Ispravnost programskog koda
- 82.Testiranje prihvatljivosti u okviru sistemskog testiranja,kupac moze da izvede:
- A.
Paralelnim testiranjem
- B.
Uslovnim testiranjem
- C.
Pilot testiranjem
- D.
Demo testiranjem
- 83.Testiranje prihvatljivosti putem referetnog testiranja:
- A.
Izvodi tim za testiranje
- B.
Izvode kupci
- C.
Podrazumeva testiranje test primera koji predstavljaju uobicajene uslove u kojima treba sistem da radi
- D.
Podrazumeva poredjenje dva sistema,starog i novog
- 84.Testiranje prihvatljivosti primenom pilot testiranja:
- A.
Ne zahteva generisanje posebnih test primera vec se samo simulira svakodnevni rad na sistemu
- B.
Je manje zvanicno
- C.
Zahteva generisanje referetnih test primera
- D.
Podrazumeva istovremeni rad dva sistema,starog i novog
- 85.Ako se testiranje prihvatljivosti izvodi paralelnim testiranjem to:
- A.
Zahteva generisanje paralelnih test primera
- B.
Podrazumeva testiranje u paru
- C.
Podrazumeva istovremeni rad dva sistema,starog i novog
- D.
Omogucava korisnicima da se priviknu na novi sistem
- 86.Instalaciono testiranje u okviru sistemskog testiranja podrazumeva:
- A.
Izradu dokumentacije
- B.
Alokaciju potrebnih datoteka
- C.
Simulaciju svakodnevnog rada sistema
- D.
Konfigurisanje sistema u skladu sa okruzenjem
- 87.Proces testiranja softvera se odvija u cetiri faze.Oznaciti tacan redosled faza:
- A.
Izrada plana testiranja-evaluacija rezultata-specifikacija testova-realizacija testiranja
- B.
Izrada plana testiranja-specifikacija testova-realizacija testiranja-evaluacija rezultata
- C.
Evaluacija rezultata-izrada plana testiranja-specifikacija testova-realizacija testiranja
- D.
Specifikacija testova-izrada plana testiranja-realizacija testiranja-evaluacija rezultata
- 88.Organizacija procesa testiranja ukljucujuci jedinicno,integraciono i sistemsko testiranje,opisana je u:
- A.
Organizacionom planu
- B.
Planu testiranja
- C.
Specifikaciji testova
- D.
Projektnim zahtevima
- 89.Metod sejanja gresaka se koristi za:
- A.
Odredjivanje broja preostalih gresaka u kodu
- B.
Odredjivanje klasa ekvivalencije
- C.
Lakse pisanje test primera
- D.
Pronalazanje gresaka u kodu
- 90.Oznaciti tacna tvrdjena u vezi sa metodom sejanja gresaka:
- A.
Metod je jednostavan za izvodjenje
- B.
Reprezentativne greske se lako generisu
- C.
Metod se izvodi tako sto jedan clan tima za testiranje namerno ubaci poznati broj gresaka u program,a zatim ostali clanovi tima za testiranje pokusavaju da ih pronadju
- D.
Metod se izvodi tako sto se greske pronadjene u programu evidentiraju kako bi se mogle koristiti u kasnijim projektima
- 91.Skup testova se formira na osnovu:
- A.
Tabele istinosti
- B.
Tabele povezanosti testova i zahteva
- C.
Uzrocno posledicnih grafova
- D.
Posejanih gresaka
- 92.U realizaciji testiranja,test skriptovi predtavljaju:
- A.
Upustva za izvrsavanje testiranja,korak po korak
- B.
Tabele povezanosti testova i zahteva
- C.
Izvestaje testiranja
- D.
Evidenciju pronadjenih gresaka
- 93.Evaluacija rezultata testiranja se moze izvoditi na sledece nacine:
- A.
Merenjem ucinka ili delotvornosti testa
- B.
Merenjem brzine testiranja
- C.
Sejanjem gresaka
- D.
Merenjem efikasnosti faza testiranja
- 94.Po zavrsetku testiranja,ucinak ili delotvornost testa se racuna kao:
- A.
Odnos broja gresaka koje su pronadjene u datom testu i ukupnog broja otkrivenih gresaka
- B.
Odnos posejanih i pronadjenih gresaka
- C.
Odnos pronadjenih i nepronadjenih gresaka
- D.
Odnos broja gresaka pronadjenih pri testiranju i rada koji je ulozen u to testiraje
- 95.Efikasnost testiranja racuna se kao:
- A.
Odnos broja gresaka koje su pronadjene u datom testu i ukupnoh broja otkrivenih gresaka
- B.
Odnos broja gresaka pronadjenih pri testiranju i rada koji je ulozen u to testiranje
- C.
Odnos posejanih i pronadjenih gresaka
- D.
Odnos gresaka pronadjenih pri razvoju i tokom odrzavanja
- 96.Instalacija softvera predstavlja jednu od aktivnosti koje so obavljaju u fazi:
- A.
Testiranja
- B.
Isporuke
- C.
Odrzavanja
- D.
Pustanja u rad
- 97.Da bi korisnik sto bolje prihvatio softverski proizvod i razumeo nacin njegovog funkcionisanja,koriste se sledeca sredstva:
- A.
Obuka
- B.
Dokumentacija
- C.
Testiranje
- D.
Instalacija
- 98.Obuka koja se izvodi u fazi isporuke softvera moze biti namenjena:
- A.
Programeru
- B.
Krajnjem korisniku
- C.
Administratoru
- D.
Isporuciocu
- 99.Cilj obuke krajnjeg korisnika je da se korisnik:
- A.
Upozna sa korisnickim interfejsom,izgledima ekrana,znacenjem oznaka na ekranu,itd.
- B.
Obuci da koristi funkcije za podrsku koje su bitne za rad sistema
- C.
Upozna sa nacinom pokretanja i izvodjenja osnovnih funkcija sistema
- D.
Upozna sa organizacijom sistema u smislu kako sistem radi,a ne sta radi u domenu
- 100.Cilj obuke administratora je da se administrator:
- A.
Upozna sa korisnickim interfejsom,izgledima ekrana,znacenjem oznaka na ekranu,itd.
- B.
Obuci da koristi funkcije za podrsku koje su bitne za rad
- C.
Upozna sa nacinom pokretanja i izvodjenja osnovnih funkcija sistema
- D.
Upozna sa organizacijom sistema u smislu kako sistem radi,a ne sta radi u domenu
- 101.Nakon sprovedene obuke,administratori treba da budu osposobljeni da:
- A.
Izvedu manje izmene u softveru prema zahtevima korisnika
- B.
Ispravljaju greske u softveru
- C.
Pomognu krajnim korisnicima ukoliko im se u radu pojavi neka neregularna situacija
- D.
Uspostave uslove za normalan rad sistema
- 102.U zavisnosti od vrste sistema,sposobnosti predavaca i afiniteta prolaznika tokom obuke se mogu koristiti sledeca sredstva:
- A.
Strucni korisnici
- B.
Pregled koda
- C.
Demonstarcije
- D.
Test primeri
- 103.Pri izvodjenju obuke,lekcije i demonstarcije se izvode putem:
- A.
Test primera
- B.
Kratkih prezentacija ili predavanja
- C.
Citanja dokumentacije
- D.
Ispitivanja korisnika
- 104.Strucni korisnici ili demonstartori koji ucestvuju u izvodjenju obuke su pojedinci koji:
- A.
Instaliraju softver
- B.
Su ranije obuceni za rad na sistemu
- C.
Su programirali softver
- D.
Su pisali dokumentaciju
- 105.Prilikom dokumentovanja nekog softverskog proizvoda koriste se sledece tehnike:
- A.
Numeracija
- B.
Unakrsno referenciranje
- C.
Inkrementiranje
- D.
Eksploatacija
- 106.Softverski proizvod se isporucuje zajedno sa pratecom dokumentacijom koju cine:
- A.
Upustvo za projektanta
- B.
Upustvo za operatera
- C.
Upustvo za implementaciju
- D.
Upustvo za instalaciju
- 107.Odrzavanje softvera podrazumeva aktivnosti vezane za:
- A.
Izvodjenje izmena u fazi eksploatacije
- B.
Pracenje rada sistema u radnom okruzenju
- C.
Instaliranje i isporuku softvera
- D.
Testiranje i otklanjanje gresaka u softveru
- 108.Oznaciti tacna tvrdjenja u vezi sa aktivnostima tiima za odrzavanje softvera:
- A.
Tim ocenjuje kvalitet rada krajnjeg korisnika
- B.
Tim pruza informacije o sistemu
- C.
Tim ne moze da menja pratecu dokumentaciju
- D.
Tim pronalazi uzroke otkaza i otklanja ih
- 109.U fazi odrzavanja softvera,sprovode se sledece vrste odrzavanja:
- A.
Korektno odrzavanje
- B.
Korektivno odrzavanje
- C.
Preventivno odrzavanje
- D.
Zavrsno odrzavanje
- 110.U fazi odrzavanja softvera,sprovode se sledece vrste odrzavanja:
- A.
Sistemsko odrzavanje
- B.
Instalaciono odrzavanje
- C.
Adaptivno odrzavanje
- D.
Odrzavanje u cilju unapredjenja sistema
- 111.Kontrolisanje svakodnevnog rada softvera nakon isporuke i otklanjanje problema nastalih zbog pojave gresaka u softveru naziva se:
- A.
Korektivno odrzavanje
- B.
Odrzavanje radi unapredjenja sistema
- C.
Adaptivno odrzavanje
- D.
Preventivno odrzavanje
- 112.Nakon izmene u hardveru,softveru ili radnom okruzenju,potrebno je sprovesti sekundarne izmene u softveru.Ova aktivnost se naziva:
- A.
Korektivno odrzavanje
- B.
Adaptivno odrzavanje
- C.
Preventivno odrzavanje
- D.
Odrzavanje radi unapredjena sistema
- 113.Aktivnost kojom se u fazi odrzavanja sprovede izmene u cilju poboljsanja nekog dela sistema naziva se:
- A.
Adaptivno odrzavanje
- B.
Korektivno odrzavanje
- C.
Odrzavanje radi unapredjena sistema
- D.
Preventivno odrzavanje
- 114.Modifikovanje isporucenog softvera u cilju detekcije i korekcije prikrivenih gresaka pre nego sto se one ispolje naziva se:
- A.
Odrzavanje radi unapredjena sistema
- B.
Adaptivno odrzavanje
- C.
Korektivno odrzavanje
- D.
Preventivno odrzavanje
- 115.Problemi u odrzavanju softvera mogu nastati iz dledecih razloga:
- A.
Zbog visoke cene razvoja softvera
- B.
Nekonzistetnog skupa zahteva koje je postavio korisnik
- C.
Neodgovarajuceg nacina projektovanja ili implementacije sistema
- D.
Zbog personalnih i organizacionih problema
- 116.Na troskove odrzavanja softvera uticu:
- A.
Zivotni vek softvera
- B.
Programski jezik
- C.
Cena softvera
- D.
Vrsta aplikacije
Back to top
