Csak a tesztemen keresztül!

Szakmai gondolatok informatikai rendszerek teszteléséről.

Gazda

Friss topikok

  • Akron: @Verhás Péter: Az ügyfeled a cég (vezérigazgatóval, Józsi nénivel) A cég ellenőrzi le és veszi át ... (2018.01.31. 14:09) Miért UAT
  • Verhás Péter: @ hrgy: Egy kicsit felhúztam magam, de sebaj. A lényegi állításokban igazad van, ám a személyekre... (2011.10.09. 00:25) A tesztelés nem mindenható
  • crix: Ez a hozzáállás. Sajnos most is. Aztán csodálkoztak itt a népek, amikor bevállaltam a hétvégi munk... (2011.10.05. 16:56) Újra fizetni kell
  • crix: és milyen specifikáció mentén ment át az ügyfél? elég blind? (2011.10.05. 13:41) Ügyfélteszt
  • fqqdk: fitnesse, concordion, és cucumber integráció lesz? (2011.03.05. 13:42) Automatizált tesztelés és üzleti tesztelés

Társblogok

Terheléses teszt eredmény ellenőrzése

2009.07.06. 10:00 | Verhás Péter | 3 komment

Miért nem vizsgáljuk (minden esetben) terheléses tesztnél, hogy funkcionálisan működik-e a rendszer. Ez a tisztázandó alapkérdés az elmúlt két blog bejegyzésből. Mi az a terheléses teszt, és egyáltalán...

Milyen teszteket végzünk egy informatikai rendszernél, és miért úgy végezzük őket, ahogy? Hogyan is kezdjem, hogy hatékony legyen? Akárhogy nézem, mindig visszajutunk az elejére, hogy miért is tesztelünk. Ugye azért tesztelünk, hogy az üzemi rendszer úgy működjön, ahogy az az üzleti igényeknek megfelel. Ez a cél üdvös, de a technikai feltételeknek nem felel meg. Informatikusként ritkán foglalkozunk az ügyfél üzleti igényeivel, és ha igen, akkor már nem mint informatikus tesszük ezt, hanem üzleti konzulensként. Ezért ehelyett a tesztek céljaként azt tűzzük ki, hogy a rendszer úgy működjön, hogy a működés megfeleljen a specifikációnak. Mivel ez a cél egy teszttel hatékonyan nem érhető el, ezért sokféle tesztet készítünk, amelyek a rendszer különböző aspektusait tesztelik, és sokszor egymásra épülnek. Ezek a tesztek lehetnek:

  • fejlesztési unit tesztek

  • integrációs tesztek

  • rendszertesztek

  • terheléses tesztek

  • shock tesztek

  • beégetéses tesztek

  • felhasználói elfogadási tesztek (UAT)

  • üzembehelyezési teszt.

 

Persze a konkrét terminológia és hogy milyen tesztek is vannak nincs kőbe vésve, mint a tízparancsolat, ebben nem kell egyetérteni. A tesztek egymásra épülnek, és ha egy teszt nem fut le hibátlanul megfelelően, akkor nincs értelme nekiállni a következő tesztnek. Néha az is előfordul, hogy egy tesztet kihagyunk, mert az a döntés, hogy a teszt által vizsgált hiba típusának kicsi a valószínűsége és nem éri meg gazdaságilag a teszt. Például lehet olyan döntés, hogy egy shock tesztet nem végzünk el, mert a rendszer megkívánt rendelkezésre állása az éles környezetben megengedi, hogy üzemi időben leálljon a rendszer, és amúgy sem várunk nagy terhelést.

 

(shock teszt során a rendszert olyan terheléssel teszteljük, amely rövid ideig sokkal magasabb, mint a maximálisan megkívánt terhelés. A teszt célja annak vizsgálata, hogy a rendszer képes meghibásodás nélkül elviselni az extrém terhelést, és nem történik ennek hatására adatvesztés, vagy más meg nem engedhető hiba, illetve a rendszer képes-e a terhelés lecsökkenését követően automatikusan visszaállni normál üzemre.)

 

És akkor most lépjünk vissza az bejegyzés alapkérdéséhez: mi az a terheléses teszt, ami a rendszertesztet (funkcionális tesztet) követi, és miért nem vizsgáljuk a funkcionális megfelelőséget terheléses teszt során (minden esetben).

 

Nos elsősorban azért, mert nagyon drága lenne. A terheléses teszteknél a rendszert terheljük, amikhez terhelő ágenseket használunk. Ezeknek az a feladata, hogy szimulálják a majd az éles rendszerben fellépő terhelést. Ehhez igen nagy mennyiségű adatra van általában szükség, amit általában programból generálunk a tesztek során (a nagy mennyiség miatt). Ráadásul ezeknek az adatoknak fontos az eloszlása is, hogy ne olyanok legyenek, amelyek a működést egy partikuláris vonal mentén futtatják végig. (Például ha mindig ugyanannak az ügyfélnek az egyenlegét kérem le, akkor a rendszer a második kérés után már nem nyúl adatbázishoz, kiszolgál a cache-ből, és fals eredményt kapok.)

 

Ha az ágenseknek ezen kívül még az is a feladatuk, hogy ellenőrizzék a válaszadatokat, akkor rendkívüli módon megnő az adatok előállításának költsége. Nem csak a bemenő adatokat kellene előállítani, hanem a válaszadatokkal is rendelkeznie kell az ágensnek, hogy azt összehasonlítva a kapott válasszal ellenőrizni tudja, hogy az jó-e. Erre szokták azt tenni, hogy írnak egy programot, ami kiszámolja a választ...

 

ÁLLJ! PIROS LÁMPA! STOP!

 

Ilyen programunk van, éppen azt teszteljük. Ha az ágensben is szerepel az algoritmus az ellenőrzéshez, akkor az algoritmus eredményét hasonlítom az algoritmus eredményéhez. Naná, hogy egyezni fog! Ez nem jó megoldás. Persze azért ez sem ilyen ha nem fehér akkor fekete. Ha tisztában vagyok az elvi megfontolásokkal, és figyelembe veszem, akkor mint „részleges” megoldást, ismerve a hiányosságokat azért felhasználhatom ezt a megközelítést is. Például sikeres funkcionális teszt után kis terhelés mellett végigszámoltatom a tesztelt rendszerrel a terheléses teszt bemenő adatokra a válaszokat, elteszem, és vizsgálom, hogy nagy terhelés mellett is ugyanazt válaszolja-e. Részleges megoldás.

 

Egy másik megoldás, hogy az eredményeket eltesszük (amúgy is eltesszük, hiszen a teszt dokumentációjának a része), és utólag ellenőrizzük manuálisan, szúrópróba szerűen, hogy jók-e a válaszok. Részleges megoldás.

 

Szintén szokásos megoldás, hogy a terhelő ágensek terhelése mellett a funkcionális tesztek is, saját ágenssel futnak és ellenőrzik, hogy a funkcionális tesztek rendben mennek-e terhelés alatt. Részleges megoldás.

 

A teljes megoldás, hogy manuálisan annyi adatot előállítsunk, amennyi a terheléses teszthez kell, és a válaszokat is ellenőrizzük. Ez általában annyira drága, hogy nem éri meg. A hibák igen nagy százaléka kiszűrhető a részleges megoldásokkal is.

 

Amit viszont nem szabad: a terheléses teszt során kapott válaszokat teljesen figyelmen kívül hagyni. De ez már kiderült két héttel ezelőtt.

 

 

Jónak tűnik, vagy jó? MEGOLDÁS

2009.06.30. 16:34 | Verhás Péter | 7 komment

Itt a várva várt megoldás.

Hogy kicsit gonosz legyek, tulajdonképpen mindegy, ahogy mindegy, hogy "járt-e Cecil a Török utcában". Az igazi kérdés nem az, hogy a konkrét esetben mi volt a megoldás (azért meg fogom mondani), hanem az, hogy mi lehet az oka egy ilyen terhelési profilnak, és nyugodtan aludhatunk-e ha ilyet látunk.

A választ a kommentelők megadták: nem aludhatunk nyugodtan, ha nem tudjuk, hogy a rendszer miért viselkedik úgy, ahogy viselkedik, akkor azt ki kell nyomozni, mert ha nem, akkor marad egy adag bizonytalanság: vagy jó a program, vagy csak jónak tűnik.

A konkrét esetben a programban volt egy terhelést figyelő logika, és ha N darab szál aktív volt, akkor nem indított több kiszolgáló szálat, hanem olyan szálakat aktivált (thread pool-ból) az egyes beeső kérésekre, amelyek egyszerűen csak visszavágták, hogy: a gép túlterhelt, időszakosan nem elérhető, próbálja meg később. Mivel ez egy http interfész volt, ezért 503 hibakódot adott vissza.

 

503 Service Unavailable

 

Persze közben a gépet egyre jobban terhelte, és hiába jött vissza az 503 nagyon gyorsan a kérések egy kis (és egyre kisebb) százaléka továbbra is jó eredményt adott, de egyre lassabban. Emiatt az átlagos válaszidő nőtt. A szórás persze igen érdekes képet mutatott volna: egy csúcs az 503 válaszokra 1mp-en belül, és egy "normál" eloszlás egyre nagyobb T időpontnál.

A jó válasz itt hangzott el először:

Nuunius  · http://r2d2fishtank.blog.hu/2009.06.23. 10:10:11
eszembe jutott, hogy nem volt esetleg nézve h mi az üzenet ami visszajön a kérdésre. Akkor pedig lehet olyan ,hogy sima hibaüzenet jött válaszként, mint a villám. Aztán valahol betelt valami és akkor már nem volt képes feldolgozni a kéréseket...

Jónak tűnik, vagy jó?

2009.06.22. 07:48 | Verhás Péter | 28 komment

Nem mindegy. Mármint az, hogy a címben feltett kérdésre mi a válasz. Mert lehet valami jó, ha annak tűnik, de nem biztos, hogy az. Ahogyan ha valami rossznak tűnik, attól még... Szóval ami rossznak tűnik, az rossz is. És ezek miatt nem az a kihívás a tesztelésben, hogy megtaláljuk a hibákat, hanem az, hogy ha nincsenek hibák, akkor ebben biztosak lehessünk. (Szerencsére ez ritkán fordul elő.)

Amiről ez eszembe jutott, az egy pár évvel ezelőtti tesztelés volt. Egy webes alkalmazás terheléses tesztjében segédkeztünk egy fejlesztő csapatnak. Funkcionálisan teszteltük a szoftvert, tényleg jó válaszokat adott (egy idő után), már csak azt kellett kimérni, hogy nagy terheléseknél is elég gyorsan adja-e a válaszokat.

A teszt tesztelése során előbb kis terhelésnél néztük a válaszidőket, tulajdonképpen összeraktuk, kvázi teszteltük a tesztelést, hogy jól mérünk-e; utána pedig a névleges terhelésnél néztük meg, hogy megfelelően gyorsan válaszol-e a rendszer.

És láttuk, hogy ez jó.

Azaz majdnem. Ami zavart egy kicsit (az ilyenekre mindig nagyon oda kell figyelni), hogy ugyan 1TPS és 2 TPS terhelés esetén még elég kicsi volt az átlagos válaszidő, de már 10TPS környékén nagyobb, és igaz az is, hogy még 100TPS-nél is kisebb volt a válaszidő, mint a maximális megengedett de, de, de …

100TPS-nél kisebb volt a válaszidő, mint 10TPS-nél.

És szerintem ez nem volt jó.
 

De persze kit érdekel délután négykor, hogy hogyan hullámzik a válaszidő ha elegendően jó? A fejlesztő látja, hogy jó szoftvert ír, jön a válasz takkra, ahogy kell, foglalkozzunk a behűtött sörrel.

Momentán, engem érdekelt. Négy óra után ott maradtam (volt kulcsom) és nekiálltam mérni. Apró lépésekben, és a következő ábrát kaptam (csak a jelleg érdekes):

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Az átlag válaszidő természetesen nulláról indul (nincs kérdés, arra baromi gyorsan van válasz), majd növekszik, és meglepő módon egy idő után elkezd csökkenni, és a maximális megkövetelt terhelés esetén már elég kicsi, és csak sokára kezd el nőni, és száll el a végtelenbe.

Hogy mi is történt itt, azt egy hét múlva elárulom. Azok között, akik addig a helyes választ kitalálják és megkommentezik egy eredeti AltaVista Revolution könyvet sorsolok ki (igazi relikvia), amit majd az Angol utcai irodánkban adunk át.

Janó bá

2009.06.15. 10:00 | Verhás Péter | 1 komment

Így nyaranta, langyos estéken előfordul, hogy leülünk barátokkal beszélgetni az élet dolgairól, és két pohár száraz vörös bor után néha elfog a kétség, hogy valóban jól csináljuk-e az életben a dolgainkat. Jól nevelem-e a gyerekeimet, jól szeretem-e a feleségemet, tisztelem a szüleimet, rokonaimat, barátaimat, ügyfeleimet.

A múltkorában zsibbadás közben eszembe jutott Janó bá. Az öreg faluhelyen lakik, testvérem házával szemben, az utca túl oldalán, körülbelül háromszáz méterre a kocsmától. Alkoholista, bár sosem rúg be. Permanensen van ittas állapotban.

Egyszer kora délután érezve a szükségét, hogy a permanens állapotot fenntartsa, kitolta az utcára a biciklijét, gondosan behajtotta maga mögött a kaput, majd a földút közepén leguggolva megtapogatta a kerekeket, jól fel vannak-e fújva, majd tapasztalva, hogy minden rendben van, felült a biciklire, és mint akinek az élete múlik rajta – talán így is volt – eszetlen sebességgel elkezdte tekerni a pedált. A bicikli azonban nem mozdult. Illetve csak úgy tűnt egy pillanatra, mintha nem mozdulna, mintha az öreg az út közepén veszettül tekerve egy helyben maradna egy álló biciklin, valójában azonban ez csak egy igen rövid pillanat volt. Az öreg, még mindig tekerve a bicikli pedálját elkezdett lassan oldalra dőlni jobbra. Ilyenkor megáll az idő, mint egy lassított film pereg vissza szemem előtt a kép, ahogy az öreg teker, és dől, csak dől, de nem hagyja abba a tekerést, és a lábát nem teszi le oldalt, még a kezével sem engedi el a kormányt, csak teker, és dől, míg egy huppanással a tegnapi esőtől és a délelőtti napsütéstől szikkadt sárba nem cuppan az oldalára.

Az ember azt hinné, hogy összetöri magát, de nem. A részegeknek külön mentőangyaluk van, vagy inkább egész hadtest mentőangyal, aki nem hagyja ilyenkor, hogy megsérüljenek, vagy hogy megfagyjanak, amikor elalszanak az árokszélen mínusz húsz fokban. Mint Majoros közlegényt, aki a leszerelés napján 1985 februárjában elaludt Cegléden az árokban és a reggel már újra a laktanyában köszöntötte a fogdán. Janó bá sem törte össze magát. Leszedte magáról a biciklit, megkerülte, melléállt, mint az előbb, és újra felült a nyeregbe, és elkezdte tekerni a pedált, hogy már azon csodálkoztam, hogy ha a lánc le is van esve, a lába lendületétől, az őrült pörgés szelétől legalább el kellene indulnia annak a kerékpárnak. De az előre nem indult el, hanem megint lassan elkezdett dőlni jobbra, csak dőlt, dőlt, az öreg meg tekert, és tekert amíg újra le nem huppant a földre, pont mint az előbb.

Ezt már nem lehetett bírni, testvérem kinyitotta az ablakot, és még mielőtt az öreg harmadszor is elismételte volna a mutatványt odaszólt neki: „Janó bá, nem kellene feltenni a láncot?”

Az öreg addigra már ott állt a kerékpár mellett, készült volna felszállni rá. Lenézett a mezítelen fogaskerékre, és mintha teljesen természetes lenne, hogy eddig nem vette észre csak annyit válaszolt: „De igen.” Azzal lehajolt, megfogta a láncot, rutinosan felhelyezte a pedál fogaskerekére, felült a biciklire, és elkerekezett a kocsmába. A göcsörtös úton jobbra, balra imbolygott, mintha a felszáradt tócsákat kerülte volna.

Nem járt volna jobban az öreg, ha már az első huppanás előtt külső szakértőre bízza a tesztelést?

 

Pali és a kamatok

2009.06.01. 10:00 | Verhás Péter | 7 komment

Először két idézet a kommentlőktől a korábbi bejegyzésekre:

fqqdk 2009.05.30. 15:45:22

"Ami azt illeti, az egységteszteket a programozónak kell írnia"
 

brslc 2009.05.11. 10:54:00

"legjobban a program írója tudja tesztelni a programját, mégpedig úgy hogy a csak tesztelésre használható rutinokat ír"

Ahogy a nagykönyvben meg van írva:

  1. Elkészítjük a dokumentációt, hogy a rutin mit fog végrehajtani. Java esetében ez a kód elé írt JavaDoc dokumentáció és a metódus feje.

  2. Elkészítjük a unit teszteket, amelyek a dokumentáció alapján használják a metódusokat és tesztelik azokat.

  3. Elkészítjük a metódust, és futtatjuk a unit tesztet, és addig javítjuk a kódot, amíg a unit tesztek le nem futnak.

Mi a valóság, a gyakorlat?

  1. Ez OK, ez így van

  2. Ha fegyelmezettek vagyunk, akkor előre megírjuk a teszteket, de mivel már ismerjük, hogy mi jön a következő pontban, inkább csak utólag.

  3. Elkészítjük a metódust, és tapasztaljuk, hogy nem csak a metódusban, hanem a unit tesztben is vannak hibák, ezért addig reszeljük a kódot, és a tesztelő kódot, amíg azok meg nem felelnek egymásnak.

 

Jó ez így? Maradjunk abban, hogy nem rossz, és ha nem sikerül nagyon fegyelmezettnek lenni, akkor ez az elérhető legjobb.

 

És most akkor a tanmese

 

Főhősünket nevezzük Palinak a példa kedvéért, meg mert ez egy jó név, meg speciel tényleg így hívják: Pál.

 

Pál feladata volt egyebek mellett, hogy írjon egy kamatszámító metódust, aminek volt három paramétere: kamatperiódus kezdete, kamatperiódus vége és kamatozó összeg.

 

/**

* javadoc

*/

ForintÖsszeg kamatSzámítóMetódus(Időpont periódusVége,

                                                    Időpont periódusKezdete,

                                                    ForintÖsszeg forintÖsszeg){

. . .

}

 

 

A valóságban voltak még paraméterek, de a példa szempontjából mindegy. A kamatszámító kódban a periódus kezdetét és végét jelentő változók meg voltak cserélve, és emiatt (átadás után funkcionális integrációs tesztelésen derült ki) negatív kamatok jöttek ki. Ennek a hitelesek speciel örültek volna, és nem tudom, hogy Palinak van-e hitele az adott banktól …

Hibabejelentés, hibajegy, feladat diszpécselés (ki javítsa ki), javítás, új teszt, release gyártás, release szállítás, mintegy laza egy óra munka két változó megcserélése a kódban.

De ez hogy fordulhatott elő? Nem volt unit teszt?

De volt. A unit tesztben is meg voltak cserélve a változók a paraméter listában. És akkor most gondolkodjunk el a fent idézett két kommenten. Nem gondolom, hogy nincs igazuk. Nem gondolom, hogy igazuk van. Csak erősen gondolkodom...

Teljes körű tesztelés

2009.05.25. 10:00 | Verhás Péter | 2 komment

Na ez az ami nincs. A teljes körű tesztelés ugyanolyan mítosz, mint a hibátlan program. Minden programban van hiba, és logikailag ebből levezethető, hogy nincs teljes körű tesztelés. (Ha ugyanis lenne, akkor azt elvégezve megkapnánk a hibátlan programot.)

Mikor használjuk mégis ezt a kifejezést?

Én akkor ha nem figyelek oda, mert egyébként nem szeretem ezt a szófordulatot. Teszt esetek vannak, amelyeket tesztelünk, és az egy külön művészet a tesztelésen belül, hogy elegendően sok és sokrétű tesztesetünk legyen ahhoz, hogy a programunkban ne maradjon lényeges hiba.

Jó esetben. Mert minden igyekezet ellenére is előfordulhat, kis valószínűséggel, hogy mégis marad a programban lényeges hiba. Ebben az esetben persze a hibát kijavítjuk, dokumentáljuk, majd tesztesetet készítünk rá, hogy a későbbiekben, a szoftver egy újabb verziójában ez a hiba már ne jöhessen újra elő, illetve ha előjön, akkor észrevegyük tesztelés során.

Mit garantál akkor a tesztelés? Nos, szigorúan véve nem sokat. Azt, hogy azok a hibák, amelyekre vannak teszt esetek nem fordulnak elő a programban. (Persze ezt is csak akkor, ha a tesztelés megfelelő. Láttam már olyan tesztelést is, ahol átcsúsztak hibák emberi nemtörődömségből, vagy fáradtság miatt. Ezért kell a teszteket, amennyire lehet automatizálni.)

 

Ha viszont elég sok tesztesetünk van, és nem bután gyártottuk őket, a szoftver funkcióit elég jól lefedik, és akkor már a tesztelés elég sokat tud garantálni. Azt, hogy működik a szoftver.

 

Hogyan érjük el, hogy teszteljünk?

2009.05.18. 15:50 | Verhás Péter | 6 komment

Szoftverfejlesztés közben tesztelünk, mert jó. Számomra sok esetben a kódolás során az okoz örömet (flow) amikor elindul a program, elkezd működni, azt csinálja amit én akarok. Olyankor én vagyok az Isten. (Tudom, cseppnyi az én világom, de mégiscsak én teremtettem. Rajzolj nekem egy bárányt!)

Idáig tart az élvezet, és sokszor a hobbiprogramozás esetében itt véget is ér a tesztelés. Ezzel pedig a minőségi szoftver készítés nem csak véget ér, de el sem kezdődött. (OFF: Ez sajnos nagyon gyakran jellemző az OpenSource programok készítőire, és így az OpenSource programokra is, és ezért van sokakban előítélet, hogy ami OpenSource az szár. Pedig nem.)

A profi programot teljes körűen kell tesztelni (amennyire teljes körűen lehet, vagy amennyire teljes körűen érdemes/ erről később esetleg majd másik bejegyzésben). Ez meg már nem olyan élvezetes, nem jön olyan gyakran a flow érzés. Ugyanolyan lapátolós kubikos munka, mint a dokumentáció írás, csak éppen enélkül, mint ahogy dokumentáció nélkül sem megy a dolog.

Mi a teendő?

A szokásos válasz rendkívül egyszerű:

a szár munkát is el kell végezni, tesztelni kell. Főnökök korbácsot elő és addig nincs shipment, release és fizetés, amíg a tesztek nincsenek készen!

A nagy kövér veri a dobot, az őrök korbáccsal járnak a sorok között, a rabok meg eveznek a gályán, és a hajó révbe is ér (vagy elsüllyed). Nem lenne sokkal jobb vitorlázni? Gőzhajó? Netán hatalmas dízel motorok? Atommeghajtású Mary Queen II? Kurszk? Hova is akarunk menni? Azért néha jó a kenu is!

Csattog a korbács és a tesztek készen is lesznek, a programok pedig hibásak maradnak. Miért is? Mert a programozó nem kubikos földásó munkás, és nem is favágó sem pedig nem gályarab. Nem kilométerben gyártja az árkot és nem köbméterben vágja a fát, se a programokat nem milligrammra készíti. A programozó szabad madár, kreatív munkára termett, ha bezárják elpusztul, megszűnik programozó lenni, jobb esetben megszökik.

Az igazi programozó képtelen megbízhatóan tesztelni, legfeljebb ideig, óráig, aztán besokall, és elkezdi rosszul végezni a munkáját. Először csak a tesztelést, aztán a fejlesztést is, és utána rosszabbodik a helyzet: elkezd inni, veri a feleségét, gyerekét, vagy csak más munkahely után néz.

A válasz rendkívül egyszerű:

Legyen a tesztelés is fejlesztői munka.

Szokatlan? Annyira nem. Aki például Java nyelven fejleszt az szinte biztosan ismeri a Unit teszt fogalmát, és a Java-ban ehhez társuló Junit könyvtárat. Minden egyes unit-hoz, programozási egységhez egy, vagy több tesztet írunk, amelyeket minden fordítás után lefuttatunk. Ez egyértelműen a programozó dolga. Sokan azt vallják, hogy a unit teszteket a tervezést követően, és még a unit kódolása előtt kell megírni.

És mi a helyzet a felhasználói tesztekkel? Azokat kézzel kell végigcsinálni? Úgy szokták. De nem lehetne automatizálni?

Terheléses teszt? Beégetési, stabilitási (burn-in) teszt? Ezeket nem is nagyon lehet automatizálás nélkül végrehajtani.

Automatizáljunk minden tesztet!

Valahol a végén persze kell, hogy legyen egy ember (aki már tényleg nem fejlesztő), aki a teszt végső eredményét ellenőrzi. De ne ember legyen, aki leellenőrzi 12,874 darab tesztesetben, hogy klikkentés hatására valóban megváltozott a form harmadik sora, és piros lett a mikulás orra az ikonon ha megnyomtam az „alkohol” gombot, de ha nem, akkor maradt kék. Ezt program is el tudja végezni, olcsóbban, és jobb minőségben. És nem is őrül bele. És több időnk marad bárányt rajzolni.

 

Felhívás

2009.05.13. 11:41 | Verhás Péter | 1 komment

Témához kapcsolódik, gondoltam közzéteszem:

SZOFTVERTESZTELÉS

 
Szeretettel meghívjuk Önt és érdeklődő munkatársait az
NJSZT Újklub (IEEE CS-NJSZT Fórum)
Szoftvertechnológiai Fórumának
29. rendezvényére!

(A rendezvényen való részvétel díjtalan!)

2009. MÁJUS 27. (SZERDA) 10:00-13:00
Helyszín: BME, „I” Épület, B017 Előadóterem
1111 Budapest, Magyar Tudósok körútja 2.
Az előadások címe:

Requirements-based system testing
Előadó: Harry Sneed (ANECON GmbH)

Statikus analízis használata szofver
minőségének biztosítására
Előadó: Forgács István (4DSoft)

Hungarian Testing Board
Előadó: Stöckert Tamás (Lufthansa Systems)

Kérjük, hogy részvételi szándékát jelezze a mellékelt jelentkezési lap visszaküldésével
Konfár Lizának a titkarsag@njszt.hu címre vagy a (06 1) 472-2739 fax számra.
Jelentkezési határidő: 2009. május 22.
További információ: www.inf.u-szeged.hu/stf/

Aranyosné V. Gabriella
Neumann János Számítógép-tudományi Társaság
aranyos@njszt.hu
1054. Budapest, Báthori u. 16.
Tel: 06-1-472-2730, Fax: 06-1-472-2739

///////////////////////////////////////////////

Mi ott leszünk

Címkék: konferencia

Meztelen selypítő lányok

2009.05.11. 10:00 | Verhás Péter | 16 komment

Amikor egy ismerősömnek elmeséltem, hogy "Csak a tesztemen keresztül" címmel indítunk blogot, akkor rögtön azt kérdezte, hogy lesznek-e selypítő meztelen lányok, mert különben mi értelme van a „csak a tesztemen keresztül” vicces kifejezésnek. Röviden: nem lesznek, és aki csak a meztelen lányok szóra jött ide, az akár ne is olvasson tovább (aki meztelen pasikra vágyik az se reménykedjen sokáig): ez egy informatikai szakmai blog.

Arról akarok elmélkedni, hogy a mindennapi szakmai életemben milyen jó, kevésbé jó, esetleg rossz szokásokat, megoldásokat látok szoftver tesztelési témára. Teszem ezt azért, mert egyrészt ezzel foglalkozom, másrészt azért, mert azt gondolom, hogy sok tenni való van a területen.

A pék kenyeret süt, én tesztelek, a péknek mégsem jut eszébe, hogy blogot írjon a kenyérsütés rejtelmeiről. Mert a kenyérsütés csínját bínját mindenki ismeri olyan szinten, amennyire kell: a pék jól megsüti, te meg nem veszed meg ha mégsem. A szoftverrel ez nincs így.

A szoftvert a szoftveres megírja jól, az ügyfél meg megveszi, és ha nem jó a szoftver, akkor szív vele, mint félig sült kenyérrel hétvégén. Pakoljuk pirítóba, csinálunk belőle fasírtot, de azért az csak nem lesz friss ropogós. A szoftver is tesztelni kellene, mint a kenyeret. Megtekinteni, hogy szép barna-e, megtapogatni (zacskón keresztül), megszagolni.

Erről lesz szó.

 

süti beállítások módosítása