PIC vs ATMEL #2

[SZIGETI Szabolcs]

Hali!

> Mar csak azert sem jo a #if, mert annak a sor vegen van vege,
> a sorveg pedig a #define-t is bevegzi.
> Tehat?

Ugyan mar nem emlekszem mi volt az eredeti kerdes, de a C-ben egy \
kozvetlenul a sor vegen azt jelenti, hogy a kovetkezo sorban folyatatodik az
a sor. Vagyis tetszoleges hosszu sort tudsz gyartani. Szamtalan pelda van
kilemeteres #define-okra.


> Ezt most nem ertem. A teszteles azt jelenti, hogy a programnak
> beadunk minden elkepzelheto bemeno adatot, es ellenorizzuk hogy minden
> adatra a vart valaszt adja-e. Mi pontosan ezt csinaljuk.
> Szerinted hogy kene? Es azt miert csak C-ben lehet?

Hajaj!

Sajnos itt a hiba. Konyvtarakra rug a programteszteles, es a
szoftverminosegbiztositas irodalma. Mindenki boldog lenne, ha ilyan egyszeru
lenne a teszteles. (Esetleg BME-s infosok emlekezhetnek a Szamitogep labor 4
(projekt labor) cimu targyra. Ott a feladat egy szoftverprojekt
veghezvitele, es bizony a dolog nagy reszet a *tervezett* es
*szisztematikus* es *tobblepcsos* teszteles adja. Ha valaki olyat csinal,
hogy jatszom a programmal egy ideig, es ha nem dol ossze, akkor jo, hat az
bizony bukta.

Es -ellentetben som mas egyetemi dologgal- a valaos eletben is valahogy igy
van.

Mondog egy igen egyszeru peldat: egy programrol akkor tudunk egyatalan
barmit is megmondani, ha egyatalan futtatjuk. Elso kozelitesben ez azt
jelenti, hogy a program minden sorat kell futtatni, ami kb azt jelenti, hogy
minden felteteles elagazas minden agat egyszer lefuttatjuk. A haromsoros
programokon tul ez nem egy trivialis taszk.

Komoly szoftvertesztelo eszkozok leteznek, amelyek a programot pl, futas
kozben analizalva (nem feltetlenul csak C persze) megmondjak, hogy egyreszt
minden sora lefutott-e, masreszt megmondjak, hogy milyen bemenetet kell adni
neki, hogy ez megtortenjen. Emlekeim szerint ilyen egyebkent digitalis
aramkorre is van, addig nem enged tovabblepni mondjuk, amig olyan
tesztvektort nem adzs, hogy minden flip-flopot megmozgasson.

Az altalad emlegetett minden bemenetet kiprobalunk mar csak azert is
ertelmetlen, mert ha egy programod csak egy 32 bites szamot eszik (es ennel
csak bonyolultabb programok vannak), akkor is 4 milliard kulonbozo bemenete
van. De lehet, hogy a kimenet csak egy ertek eseten mas. Vagyis amit az
elozo modszerrel 4 miliard lepesben meg lehet oldani, azt egy korrekt teszt
megoldas kettoben megold. Es akkor nem ragoznam, ha ket 32 bites szam a
bemenet, es a hiba akkor jon elo, ha az egyik 1275746 a masik pedig 8726589,
akkor mi van? A program elemzesevel (kezzel, geppel, mindegy) ezek az esetek
feltarhatoak, es szisztematikus tesztesetek generalhatoak. Amelyeket
raadasul a fejlesztes soran ujra es ujra lefuttatsz, hogy nem rontottal-e
valamit a regebben megirt kodokban.

Itt persze nem az automatizalt eszkozon van a lenyeg, hanem azon, hogy a
programtesztelesnek is van tudomanya. Ez minimum azt jelenti, hogy kezzel,
vagy bonyolult esetben geppel teszteseteket generalunk, amely lehetoleg
aprogram minel jobban behatarolt reszet vizsgalja, igy ha nem mukodik,
tudod, hogy hol a hiba. Ezek utan legyartod a tesztesetet, az
elfogadhatosagi kriteriumokat stb. Es tesztelsz. Es akkor meg nem beszeltunk
az integracios tesztekrol, arrol a kerdesrol, hogy a program valoban azt
csinalja-e ami a specifikacio, vagy arrol, hogy hol vannak ateljesitmenybeli
gondok, stb.

Es lehetne meg sok mas ilyen, szoftver minoseggel foglalkozo kerdesrol irni,
javaslom a megfelelo szakiroldalom megtekinteset, tanulsagos.

Szabolcs