Projektiranje in organizacija informacijskih sistemov

1. Projektiranje in organizacija informacijskih sistemov Odkrivanje in nadzor napak

2. Kdaj testiramo? • Sproti! • Če nečesa ne preverimo takoj, bomo kasneje pozabili • Če testiranje odlagamo do konca, bo zanj zmanjkalo časa • Popravljanje napak je tem dražje, čim kasneje se ga lotimo • eXtreme Programming:testni primeri se pišejo preden začnemo programirati • Klasičen razvoj: sproti (tik pred ali tik po)

3. Vrste testiranja: avtomatski testi • Funkcijsko testiranje • testiranje s testnimi primeri • ne upošteva implementacijskih detajlov (testiranje črne škatle, black box) • problem je sestavljanje testnih primerov • če jih sestavi avtor kode, bo samo ponovno spregledal, kar je spregledal pri programiranju • če jih sestavi kdo drug, manj dobro ve, na kaj paziti • testni primer mora pokriti vse razrede možnih “vhodov” • mejni primeri: ničle, prazni seznami, seznami enakih elementov... • Strukturni testi • testni primeri, ki testirajo čim več poti v programu • nedosegljiv ideal: vse možne poti • dosegljivo: vsi stavki ali vsaka izbira v vsakem vejanju (if, case...) • upoštevamo zgradbo programa (testiranje bele (steklene) škatle, white box) • torej je nemogoče pisati testne skripte vnaprej • obstajajo orodja, ki merijo, katera koda se je izvedla in kolikokrat • V Visual Studio 2005 so orodja za testiranje že vdelana

4. Test enote (unit test) v Pythonu import randomimport unittestclass TestSequenceFunctions(unittest.TestCase): def setUp(self): self.seq = range(10) def testshuffle(self): random.shuffle(self.seq) self.seq.sort() self.assertEqual(self.seq, range(10)) def testchoice(self): element = random.choice(self.seq) self.assert_(element in self.seq) def testsample(self): self.assertRaises(ValueError, random.sample, self.seq, 20) for element in random.sample(self.seq, 5): self.assert_(element in self.seq)unittest.main()

5. PyUnit / JUnit / SUnit / ... xUnit • Razredi za samodejno testiranje • Potrebujejo preproste funkcije, v katere vstavimo stavke kot • assert(cond) • assertEqual(a, b), assertNotEqual(a, b) • assertAlmostEqual(a, b[,places]), assertAlmostNotEqual(a, b[,places]) • assertRaises(exception, callable, *args) • ... • To je testiranje bele škatle, če so testi dovolj drobni, ali črne, če ne. • Težava • te funkcije je potrebno napisati • napisati jih je potrebno tako, da zelo natančno testirajo vsako situacijo v najmanjšem delčku kode • To testiranje je nujni del skrajnega programiranja (XP); nekateri ga povezujejo z njim, v resnici pa je starejše

6. Regresijski testi • Testi, ki preverjajo ali to, kar je nekoč delovalo, še deluje • Lahko pa preverjajo, ali deluje enako dobro • sestavlja prevajalnik še vedno tako hitro kodo kot prej? • Pogosto: ali je hrošč, ki je bil odpravljen, še vedno odpravljen • regresijske teste tedaj sestavljajo primeri, ki nekoč niso delovali • (osebno se mi zdi ponovno pojavljanje hrošča redko) • (velja pa argument: koda, ki vsebuje hrošče, je zapletena ali pa jo je pisal slab programer in v obeh primerih je potrebna resnejšega preverjanja)

7. Vrste testiranj: Ročno testiranje • Analiziramo kodo, programa (navadno (po možnosti?)) ne izvajamo • Prevajalniki • so deklarirane spremenljivke uporabljene? • ali spremenljivkam prirejamo, preden iz njih beremo? • ... Osebna izkušnja: • v strogo tipiziranih objektnih jezikih (npr. C++) je, ob pravilni uporabi, sintaktična pravilnost blizu semantični • v višjenivojski jezikih a la Python: ni šans • Branje • kodo preberemo stokrat • boljše: nekdo drug prebere našo kodo stokrat (peer review) • “Inšpekcije”: skupine (npr štirje člani) berejo in si razlagajo kodo: • moderator “predseduje” • bralca ali inšpektorja bereta in poskušata razumeti • avtor kode prisostvuje, vendar ne sugerira, kvečjemu odgovarja

8. Ročni pregledi kode • Dobro je vzdrževati seznam pogostih napak • Nekaj tipičnih • napačna raba podatkov • neinicializirane spremenljivke • indeksi izven meja tabele • kazalci v prazno • napake v deklaracijah • deklaracije napačnih tipov (int namesto float) • deklaracija istega imena istem bloku ali v podbloku • napake v izračunu • deljenje z ničlo... • napake v izrazih • “manjše” namesto “manjše ali enako” • napačna prioriteta operatorjev • napake v poteku • neskončne zanke • zanke, ki naredijo korak preveč ali premalo

9. Ročni pregledi kode • Uporabni v vseh fazah, tudi pri načrtovanju, pogoj je le jasen dokument (ne nujno program), ki ga lahko preverjamo • Dobro za moralo, utrjuje skupinskega duha • Odlično sredstvo za poučevanje: manj izkušeni člani (avtorji ali bralci) se naučijo novih algoritmov, stila, zanesljivih jezikovnih konstrukcij, trikov... • Pomanjkljivosti: • nevarnost površnosti • pravo testiranje je destruktiven proces • dobro je imeti hudobne sodelavce • skupina si mora za to vzeti čas

10. Testiranje med življenjskim ciklom • Analiza zahtev • so popolne? konsistentna? izvedljive? jih je mogoče testirati? • Zasnova • podobni kriteriji kot pri analizi zahtev • zasnova je formalnejša, zato jo je lažje preverjati • Implementacija • “pravo testiranje” – to o čemer smo govorili prej • Vzdrževanje • regresijski testi

11. Beleženje napak • Za seznam napak je nujno že v začetku projekta vzpostaviti repozitorij • Za vsako odkrito napako je potrebno vedeti • v kateri različici se pojavi • jo je mogoče reproducirati in kako (priložiti podatke...) • kdo jo je odkril • kdo je zadolžen za popravljanje • ali je popravljena in kako, v kateri različici • Nekaj programov: • Bugzilla (www.bugzilla.org/) • najbolj znan odprtokodni program za sledenje hroščem • prevelik, prezapleten (Perl) • Mantis (http://www.mantisbt.org/) • JIRA in podobni komercialni programi

12. JIRA

13. Mantis

14. Mantis – Bogomoljka • Zastonj (GPL) • Zahteve • Php • MySQL • spletni strežnik (Apache, IIS) • Funkcije • sporočanje hroščev • zadolževanje • spreminjanje statusa • obveščanje po elektronski pošti • filtri (po statusu, poročevalcu, zadolženemu...) • Grd uporabniški vmesnik • Zelo prilagodljiv(posebej, če poznate Php)