Csak a tesztemen keresztül!

 Ha szoftvert fejlesztünk, akkor abban lesz hiba is. Semmi gond, majd készítünk unit tesztet, funkcionális tesztet, integrációs tesztet. Sőt a felhasználók is fogják tesztelni. Ha elegendően sok tesztet készítünk, futtatunk akkor minden rendben lesz. De nem! A tesztekkel egy dolgot tudunk igazolni: A szoftver az adott teszteket futtatva az adott környezetben hiba nélkül futott. Ha ezt sokszor mormoljuk mint az imát és minden nap örülünk, hogy ismét felkelt a nap, mert minden reggel ezt szokta tenni, akkor hajlamosak vagyunk elhinni, hogy nincs komoly hiba a szoftverünkben. A mormolás megkönnyítésére használhatunk Continous Integration szervert és minden commit után kapunk megnyugtató email-t, még mindig nincs benne hiba. Pedig van. Na jó, de biztos nincs minden funkció lefedve és a code coverage mérés, az majd segít. Hát nem.

Lássunk egy konkrét példát. Történt a minap, hogy egy C++ kódot kellett egy titkosítási funkcióval kibővíteni. A titkosításhoz szükséges password összeállításának egyik lépése az volt, hogy a Registry-ből ki kell olvasni a szerver azomosítóját. Mivel Windows operációs rendszert használunk mi sem egyszerűbb az erre használható függvényt meg kell hívni és már kapjuk is az eredményt. A függvény többek között két paramétert vár:

• az egyik egy buffer ahova az eredményt fogja tenni
• a másik a buffer részére lefoglalt méret, ebben eredményül a buffer-be töltött hosszat kapjuk vissza 

A függvény eredménye 0 vagy hiba kód. Az igazi eredmény persze a buffer-ből olvasható ki. Ezt az akadályt látszólag sikerrel vettük, hiszen a teszteken minden rendben volt. A titkosítás után a kititkosítás is rendben lefutott, pedig az egy másik modulban java-ban került megvalósításra (annyi könnyítés azért volt benne, hogy mind a két modul az openssl-t használta).  A tesztek után a felhasználói tesztek is rendben voltak és használatba került  a kód több ügyfélnél is. Aztán egyszercsak az egyik support-os kolléga jelezte, hogy nem tudta kititkosítani a titkosított állományt.  Fejvakarás, log level állítás és nyomozás után arra jutottunk, hogy itt bizony súlyos hiba történt. Ezt az állományt a mai számítási kapacitások mellett senki sem fogja tudni kititkosítani. Márpedig ez a két funkció (titkosítás és kititkosítás) csak együtt értelmes. Esetleg a kititkosítás megállja helyét egyedül is olyan értelemeben, hogy nem okoz kárt, azonban hasznot sem hoz, de a titkosítás önmagában vetekszik a csak írható memóriával.

És akkor mi történt???? Több hibát is vétettünk.

1. A függvény visszatérő értékét nem vettük figyelembe. Emocionálisan azzal magyarázható, hogy az eredmény a buffer-ben van.
2. A buffer-nek ugyan lefoglaltunk elég helyet (256 byte), de ezt a méretet nem adtuk át paraméterként. Ott csak a buffer-be töltött eredmény méretét vártuk.

Mivel nem töltöttük ki a lefoglalt terület méretét ennek következtében azon az egy byte-on egy véletlen szám szerepelt ami ott maradt a stack-en. Ez ugye 0 és 255 közötti lehetett bármi. Ha ez a bármi éppen több volt mint a kiolvasni kívánt registry érték hossza, esetünkben 29, akkor rendben lefutott a függvény. A probléma akkor jött csak elő ha a "véletlen számunk" kisebb volt mint 29. 

De akkor volt rá több mint 10% esély, hogy megtaláljuk a hibát!? Csak akkor ha egyforma eséllyel kapjuk bármelyik értéket.

Vajon mennyire volt ez a véletlen véletlen? Telepítés függő? Indítás függő? Futás függő? Ki tudja. Az biztos, hogy több száz titkosítás során nem jött elő a probléma.

És akkor most hogyan tovább? Ne teszteljünk? Vagy mit tegyünk még? 

Azt eddig is tudtuk, hogy a tesztelés nem javítja meg a talált hibákat. Most tegyük hozzá, hogy nem minden hibát lehet megtalálni teszteléssel. Szerencsére vannak egyéb módszerek is.

• Válasszunk olyan programozási nyelvet ami eleve kizárja az ilyen jellegű hibák elkövetését pl. Java. Nincs inicializálatlan memória terület, a hibákat kivétel kezeléssel oldja meg, típusos adatátadás, hogy csak azokat említsem ami ebben az esetben segített volna.
• Tervezési és/vagy kódolási formális/ nem formális felülvizsgálat.
• Kódolási konvenciók automatizált ellenőrzése
• pair programming
• quality assurance

Erről részletesebben itt. És gondoskodjunk olyan support-os kollégákról akik még az ilyen véletlenszerű rejtett hibákat is felfedik. 

Megvette az ORACLE a SUN-t. Szinte biztos, hogy nagyon sokan ki fogják cserélni a SUN Open ESB-t a rendszereik alatt OSB-re. Hogy szakmailag melyik a jobb, nem tudom. Hogy melyiket fogja hosszú távon támogatni a SUN (... ORACLE) szintén nem tudom. Gondolom a saját OSB nevű termékét, és ami ötletet érdemes, azt átveszi majd az Open ESB-től.

Viszont minden átállást tesztelni kell. És az infrístruktúra csere egy SOA környezetben érdekes feladat, mert nem azt kell tesztelni, hogy egy-egy szerviz megfelelően működik-e, hanem azt, hogy ugyanúgy működik-e. (Na persze az is jó kérdés, hogy mi az, hogy ugyanúgy.)

Jelenleg készítünk egy olyan soapUI kiegészítő szoftvert, amelyik pont ilyen feladat megoldására való, és szándékaink szerint elérhető lesz open source-ként. Minden egyes teszt esetet le kell futtatni a régi és az új környezetben, és minden futás bekerül adatbázisba. Amikor megvan, akkor az adatbáziban az azonos teszt esetek eredményeit összehasonlítjuk, és teszt riportot készítünk.

Van valakinek hasonlóval tapasztalata? Ötlete? Kérdése, kérése. Vagy akar valaki csak úgy beszólni. Elbírjuk.

Sokáig azt hittem, hogy az a termék, amit előállítottunk egy teszt automatizálási eszköz. Mert persze az is, hiszen a tesztek automatizáltan futnak le, de ma már a tesztek legtöbbje automatizált. Persze nem mindegyik, mert van amit nem lehet (értsd: érdemes) automatizálni.

Azután rá kellett jönnöm, hogy az igazi érték a Pegamentó-ban nem az, hogy a tesztek autmatikusan lefutnak, és az sem, hogy a tesztek nyilvántartása egy wiki szoftverben valósul meg, és ezzel verziózott, öndokumentált, és karbantartható.

Az igazi érték, hogy a tesztek üzleti szinten vannak leírva. Természetesen ott van alatta minden műszaki réteg, hiszen anélkül nem működne. De ez a legmagasabb szintű leírás más termékben nincs. (Egyet közben találtam, a thoughtworks twist valami hasonlóra törekszik.)

Ez a Business Level Testing (BLT, ami amerikai angol nyelvterületen a bacon, lettice, tomato szendvics rövidítése) a tesztelő számára olyan eszköz, amivel láttatni tudja a munkáját, és be tudja vonni a munkába az üzleti szakértőket, vezetőket. Ez persze plusz munka. De megéri. Szerintem.

Tesztelünk soapUI-jal. Sok milliárdos forgalmú ügyfél. Természetesen a soapUI Pro verziója sokkal kényelmesebben (értsd: hatékonyabban, gyorsabban) használható, mint az ingyenes. A megrendelésben szerepel, hogy az ingyenest kell használni. Egy soapuiPro, ha egyenként veszem 349USD (kb. 72000HUF). Nekünk van saját licencünk, tettünk eleget a soapUI-hoz, hogy kapjuk Ole-jéktől ajándékba minden évben, de a project budgetbe is beleférne. Az eredmény fut az ingyenessel is.

De a megrendelő cég saját emberei küzdenek az ingyenes verzióból hiányzó funkciók hiányával. Ez az olcsóbb?

Egyszer volt, hol nem volt, volt egyszer egy nagy cég, akinél teszteltünk, és azt láttuk, hogy bár az egész rendszer, SOA architektúra, szervizek és szervízek (sic!) működnek, de a SOAP válaszok sok esetben nem felelnek meg az XSD-nek. Ez ugyan a kutyát sem érdekelte, hát még a SOAP klienseket mennyire nem; így a WSDL-t nem teljesítő szerver és a kliens egész jól megvoltak mint valami vadházasságban, WSDL által nem szentesítve.

Javasoltuk (tudom, most már tudom, hogy naivitás volt), hogy ezen változtatni kellene. A SOA architektúra sok más mellett arról is szól, hogy kliensek és szerverek a SOAP hívások két oldalán nem csak úgy valahogy összetaláltkoznak, hanem bizony ezt a találkozást WSDL kell, hogy összekösse. Ha pedig akár a kérés, akár a válasz nem felel meg az XSD-nek: nincs vita, hogy ki a hibás.

Erről született is egy jegyzőkönyv, amit a megbeszélés során a projekt menedzser (nevét fedje sűrű homály, felejtés valamint titoktartási nyilatkozatok tömkelege) készített saját jegyzetei alapján. Ezt mindenki megkapta, a főnökök is, és mi is. Idézek belőle:

"A VVSC javaslata, hogy a szervizeket úgy kell kialakítani, hogy a szerviz válaszok megfeleljenek Vicces Dénesnek".

Ezek után, ha a műszaki projekt menedzser

1. nem tudja, mi az az XSD
2. nem meri ezt bevallani és megkérdezni, és
3. XSD helyett Vicces Dénes-t ír, mert így hallotta,

akkor milyen vállalati kultúrára számíthatunk? Egy ideig még sportoltunk, de rá kellett jönnünk, hogy a SOAP válaszok XML-jei soha nem fognak megfelelni ebben a cégben az XSD-nek, vagy ha igen, akkor az vagy a véletlen műve, vagy az már egy másik cég lesz.

A valuta árfolyamok elérhetőek a Magyar Nemzeti Banktól nem csak web oldalon keresztül, hanem SOAP híváson keresztül is. Gondoltam, hogy amikor ügyfélnek mutatok be SOAPui tesztet, demózok, akkor miért ne ezt a szolgáltatást használjam? A WSDL ezen az oldalon érhető el:

http://www.mnb.hu/arfolyamok.asmx?WSDL

Neki is álltam készíteni egy demo projektet, talán két perc az egész, hiszen a SOAPui mindent megold, csak kattintgatni kell, ha meg van a WSDL.

És akkor egy pillanatra megakadtam, amikor megkaptam az első SOAP választ.

Az összes árfolyam benne volt a válaszban, de egyetlen mezőben CDATA formátumban XML-ként. XML az XML-ben.

Aztán a következő pillanatban azt gondoltam, hogy ha a property transfer step-ben SOAP válasz Resultra lehet XPATH-t megadni, akkor biztos lehet egy properties test step egyik propertijére is. És lehetett. A mellékelt videómegmutatja, hogy hogyan:

Az egész folyamat, a teljes projekt felépítés látszik a videón. Érdemes átkapcsolni 480px-be, úgy jobban látszanak a feliratok.

Pár hete egy régi barátommal beszélgettem, aki elment tesztelőnek egy nagy céghez. Szép és jó, hogy egy olyan méretű (nagy nemzetközi multi) cég nem csak fejleszti a szoftvert, hane teszteli is. Kérdezgettem, hogy milyen technológiákat használnak, már csak amennyire el szabad ilyen dolgokat szigorúan szakmai érdeklődés szintjén árulni.

És akkor elhangzott egy kérdés, amire nem számítottam, és amire hirtelen nem is tudtam mit válaszolni:

Te hogyan tesztelnél egy olyan alkalmazást, aminek nincs specifikációja?

He? Ho? Hát sehogy. A tesztelés annak ellenőrzése, hogy a szoftver megfelel a specifikációnak. Vagy nem?

Végig gondolva rá kellett döbbennem, hogy nem. A fenti definíció, amely szerint a tesztelés azt ellenőrzi, hogy a szoftver megfelel-e a specifikációnak egy olyan műszaki definíció, amelyik a legtöbb esetben használható, de nem ez a tesztelés legfőbb célja. A legfőbb cél az, hogy a szoftver hasznpt hozzon a felhasználónak, az ügyfélnek. Csak ezt nehéz ellenőrizni. Ehelyett vizsgáljuk, hogy a szoftver a speckónak felel-e meg.

Máskor is felmerült már ez a kérdés, hogy mi az amire kíváncsiak vagyunk, és mi az amit mérünk. Annak idején, sok éve, amikor egyetemen oktattam, és ennek folyományaként vizsgáztatni is kellett, meg zárthelyiket iratni, az egyik hallgató a szememre vetette, hogy a zárthelyivel való mérés nem igazságos, hiszen nem a tudását méri, hanem azt, hogy a zárthelyiben megadott feladatot milyen jól oldja meg.

Szembesülnie kellett azzal, hogy nem álltam le vitázni vele, hanem ighazat adtam neki. A zárthelyi eredménye nem határozza meg, hogy milyen a tudása, csak összefügg vele, esetleg csak korrelál. Szinte minden esetben amikor mérünk nem azt mérjük amit tudni szeretnénk, mert az többnyire nem mérhető. Ehelyett mérünk valami mást, ami összefügg azzal amit tudni szeretnénk. Esetleg csak korrelál, és az igazat megvallva néha még azt sem.

A tesztelés is ilyen. Azt mérjük, hogy a szoftver megfelel-e a specifikációnak. Ha a specifikáció azt írja le, hogy mire van szüksége a megrendelőnek, akkor a szoftver specifikációnak való megfelelősége egészen jól korrelál a szoftver üzleti alkalmasságával. De ha nem fejlesztünk, hanem csak taknyolunk valamit, akkor nem biztos, hogy van specifikáció. Tesztelni meg akkor is kell.

Egyébként meg ez a taknyolás is egy olyan téma, amit sokan elítélnek, magam sem szeretem és próbálom is elkerülni ha egy projek ebbe az irányba kezd görbülni. De nem Isten ellen való vétek. Nem alapvetően rossz. Csak tudni kell, hogy mire való, mikor használható, és meddig lehet vele eljutni. Nevezhetjük agilis tervezésnek és fejlesztésnek is. Aztán refaktorálunk, de ez egy olyan téma amit már rágtunk eleget.

Visszatérve a specifikáció nélküli alkalmazás tesztelésére, csak úgy lehet tesztelni, ha tisztában vagyunk az üzleti igényekkel. Amilyen jól ismeri a tesztelő az üzleti igényeket, annyira lehet jó a teszt (nem biztos, hogy annyira lesz jó is, ahhoz még tesztelni is tudni kell). És ekkor jöttem rá, hogy miért olyan kevés a tesztelés a szoftver projektekben üzleti oldalon.

Aki az üzlethez ért (a domain-hez), az többnyire nemm ért a teszteléshez. Aki a teszteléshez ért, az nem ért az üzlethez. Ahhoz, hogy tesztelni lehessen tisztességesen, bizony kell a specifikáció, ami összekötné azt a két tudást. Ehhez pedig mindenképpen munkát kell befektetni a megrendelő részéről. Még akkor is, hogy ha a specifikáció kialakításában szakértők segítenek. Legalább nekik el kell mondani, hogy mit is szeretne. Ez pedig munka.

A legtöbb esetben pedig a nem informatikusok valamiért azt várják a szoftvertől, hogy az majd megoldja a problémákat. Pedig nem.

Az informatika segít, hogy mindenki megoldja a saját problémáját, de senki helyett nem oldja meg azokat.

Nem régen a következő levelet kaptam a blog.hu-n keresztül:

Ha lehet, egy érdekes szakmai kérdést szeretnék feltenni:
Van-e összefüggés a szoftver minősége és az alkalmazott fejlesztési módszertan között?

A saját megfigyelésem az, hogy az agilis módszerekkel fejlesztett szoftverekkel az ügyfelek elégedettebbek, de ugyanakkor ezen szoftverekkel rengeteg probléma van. Tipikusan olyan hibák, amik teszteletlen szoftver esetén bukkannak fel: regressziós hibák, összeomlások, a rendszer nem elérhető. Az üzemeltetés is egy rémálom

Az érdekelne, hogy ez a módszertan sajátossága, vagy csak az adott fejlesztők/menedzserek bénasága?

A válasz az, hogy igen. Ez a módszerek sajátossága, és fejlesztők, menedzserek bénasága. Azt is mondhatnám, hogy bénák választják az agilis módszertant, és az agilis módszertannal a profik is bénává lesznek, és sokszor a gyakorlatban ez így is van. De nem mindig. És ennek nem kellene így lennie.

A dolog nyitja, hogy mindig azt az eszközt kell használni, amelyik az adott feladatra és az adott ügyfélhez a legjobb. A módszertan csak egy eszköz, és semmi több. Egy olyan eszköz, amelyik arra szolgál, hogy emberek közötti együttműködést segítsen elő.

A vízesés módszernél a projekt elején hosszan tervezés van, és csak a projekt második felében kezdődik a fejlesztés. Türelmetlen, és tapasztalatlan ügyfél ettől nem boldog, nem elégedett. Sok idő elment, talán még fizetnie is kellett a tervekért és még nincs „semmi”.

Agilis fejlesztés esetén nem kell tervezni (?). Egyszerűen nekiállunk kódolni, elkezd működni a szoftver, legfeljebb újraírjuk. Ezzel elégedett az ügyfél, hiszen mindjárt van valami amit lát, hogy működik, mozog.

A vízesés projektek akkor szoktak megbukni, ha az ügyfél türelmetlen, nincs bizalma a fejlesztő csapatban, és leállítja a projektet. Na ilyenkor szív a fejlesztő csapat, ha nem fizettette ki előre a tervezési munkákat, és kezdődhet a pereskedés.

A vízesés projektek azonban úgy is megbukhatnak, ha a fejlesztő csapat ellógja a tervezést, és nincsenek rendes, jó tervek mire el kell kezdeni fejleszteni, és akkor nekiállnak agilisan kódolni. Ez persze nem csak úgy történhet, hogy ellógják a tervezést. Hasonló eset úgy is előfordul, hogy a tervezés során nem sikerül az ügyfélből „kiszedni” a megfelelő információt.

Az agilis projektek viszont lehetnek sikeresek is. Néha előfordul.

A személyes tapasztalatom az, hogy az agilis módszertant használók legnagyobb tévedése az a mondás, hogy agilis módszertan esetén nem kell tervezni. Kell. És minden olyan agilis projektnél amelyik sikeres volt is tervezés. Meglepő módon még akkor is, amikor a résztvevők szerint sem volt. Volt, csak nem vették észre, vagy nem tudtak róla.

Kiválóan lehet agilis módszertant alkalmazni olyan esetekben, amikor a feladat eléggé körülhatárolt, nem túl egyedi és olyan kertrendszerek állnak rendelkezésre, amelyek megadják az alap architektúrát, az alap szolgáltatásokat, és csak ezekhez kell valami kiegészítést készíteni. Ilyenkor valóban nem kell tervezni, mert a tervezés már megvolt akkor, amikor a kertrendszert elkészítették.

Ha például Groowiki-ben implementálok egy munkafolyamatot, akkor elég a munkafolyamatot leírnom XML-ben, megterveznem az egyes dokumentumok, és munkafolyamat lépések meta adatait (képernyőket) és le kell esetleg programozni a munkafolyamat elemi lépéseit. Nem kell architektúrát tervezni: neki lehet kezdeni, és egy nap alatt már mozog a kód, adatot lehet rögzíteni, lekérdezni, munkafolyamatot indítani. Két hetes sprintekkel ki lehet fejleszteni az összes folyamatot ami kell a cégnél, és minden sprintben lehet egy kicsit finomítani az előző sprintekben elkészült munkafolyamatokat. A projektben nem kellett tervezni.

De előtte, amikor a Groowiki workflow implementációja készült, akkor kellett.

A tesztelés megint egy külön téma, de ott meg aztán végképp nagyon rossz a tapasztalatom. Akár waterfall, akár agilis: tesztelés az nem nagyon szokott lenni. De, ahogy a levélíró is érzékeli: waterfall fejlesztésnél azért inkább. Ahhoz a habitushoz közelebb áll a fegyelem, a teszteléshez pedig fegyelem kell.

Összefoglalva: lehet egyik, és lehet másik módszertant alkalmazni, és egyik sem az ördögtől való. Vannak helyzetek, amikor még választani is lehet, hogy melyiket akarjuk. Van amikor a feladat, vagy az ügyfél miatt kell agilis, vagy éppen waterfall módszert választani, és van amikor keverni lehet vagy éppen kell a két módszertant: józan paraszti ésszel. És végül van olyan helyzet, amikor a probléma csak waterfall megközelítéssel és hozzáállással oldható meg, de az ügyfél viszont csak agilis módszertant visel el. Ilyenkor kell menekülni, különben vagy így, vagy úgy de bukik a projekt, és sem a fejlesztő csapat nem lesz boldog sem a felhasználó.

 

A múltkor ügyfélteszteltünk.

Átment a teszten.

Olvasom az elektronikus számlázásról szóló APEH közleményt:

http://www.apeh.hu/archiv/adoinfo/afa/afa_eszamla.html

Elektronikus számla bármilyen lehet. feltéve, hogy át lehet konvertálni, text fájlra, print fájl formátumra, vagy XML-re. Az XML-re van definíció leírás is. Rajz (feltehetően XMLSpy szoftverrel készült), DTD és XSD.

A kérdés az, hogy melyiknek kell megfelelni? Ki kellene mondania a közleménynek, hogy melyik a definíció. De nem mondja. És ha ellentmondás van közöttük, és lehet gyártani olyan XML-t ami mondjuk a DTD-nek megfelel de az XSD-nek nem?

Lehet tippelni!

Meg volt?

Akkor elárulom: lehet. Mondjuk egy számlán, XML-ben 25613413 forint összeg szerepel. A DTD-nek megfelel, ha egyébként jó formátumú, de az XSD-nek nem. Az XSD szerint a számlán szereplő forint összegek float típusúak. Azt pedig pontosan definiálja a szabvány, hogy az mekkora lehet.

Az áfa százalék az XSD szerint szabad szöveg?

És a példában tizedesvesszővel van az áfa százalék. Tudom, hogy nálunk az a szabvány, és nem a pont, de az XML-ben meg pontot kell használni.

Nincs ebből egy újabb, jobb verzió?

Miért UAT az UAT? Mármint a User Acceptance Teszt, vagy magyarul felhasználói átvételi/elfogadási teszt. Mert ez a neve. Na de azon túl? Mert a felhasználó csinálja?

Hát nem. Nem a felhasználó csinálja. Nem csak ő csinálja.

Itt kérem 3 betű van: U, A és T. A 'T'-t a user felhasználó csinálja. De az 'A'-t nem. Azt az ügyfél teszi meg. Persze sok esetben az ügyfél és a felhasználó ugyanaz a személy. De nem ugyanaz az aktor. Más szerep.

Az ügyfél felhasználó használja a programot, dolgozik vele, de nem ő fizet, és ezért nem ő fogadja el a szállítás során. "Az az úr akinek van pénze" ... és fizet. Persze az ügyfél sem fogadja el a programot, ha a felhasználó nem tudja használni. Az ügyfélnek az kell, hogy a felhasználó dolgozzon.

De ne bukjon el egy átvétel, ha formon egy gomb színe nem piros, ha attól még a rendszer használható. Persze kijavítjuk. Mindent kijavítunk, de addig is át lehetne venni, és lehetne használni.

Szóval miért hívja az elfogadott terminológia UAT-nak? Mert technikai és kicsit sem üzleti szemléletű az informatika? Pedig nem ártana.

Jó sok évvel ezelőtt, ügyfélként olvastam egy nagy, és igen közismert (többek között autógumit is gyártó) cég szoftver szállítási feltételeit.

Ha a szoftvert a megrendelő éles környezetben használatba veszi, az átvétel automatikusan elfogadottnak tekintendő.

Jogos. Vagy működik, és lehet használni, vagy nem. (Ezért sem jó név az, hogy UAT).

Az utv.hu-n olvasom

Újra fizetni kell

utv uv 2010-02-15 20:51:00

Tegnap reggeltől ismét ellenőrzi a parkolást a Budapesti Önkormányzati Parkolási Kft. (BÖP), a IX., XIII. kerületek teljes területén...

És nem értem. Tényleg azt gondoljuk, hogy azért kell fizetni mert ellenőrzik? Nem azért mert ez a szabály, mert közösen így döntöttünk egy adott cél érdekében? És ha nem ellenőrzik akkor nem kell fizetni?

Ha ez a gondolkodás mód működik a szoftver fejlesztésben is akkor ugye jó minőségű programot csak akkor kell készíteni, ha azt valaki ellenőrzi vagyis tudjuk, hogy lesz tesztelés is. Ha nincs teszt, akkor az a szerencsétlen végfelhasználó az már nem számít.

Vajon hány év vagy emberöltő kell ahhoz, hogy egy kicsit másképp gondolkodjunk? Tudom, hogy a kultúrális változások nem mennek ugrásszerűen, mi addig is tesztelünk.

http://kocka.blog.hu/2010/02/13/miert_vannak_hibas_programok

egy egész jó kis blogbejegyzés kockától abban a témában amivel mi foglalkozunk.

index.hu/belfold/2010/02/05/toroltek_a_diakok_adatait/ cikk szerint

Hiba történt csütörtök délután a középiskolás jelentkezéseket kezelő központi szerveren, így a hajnali fél három után rögzített adatok – vagyis a januári középiskolai felvételik és az érettségijelentkezések egy része – elveszett, írja az erettsegi.com.

Az Oktatási Hivatal szerint “a hiba jellege miatt nincs mód a problémával érintett iskolák, diákok körének meghatározására”.

Ne próbáljuk meg kitalálni, hogy mi történhetett, mit rontottak el, csak azt ami ebből az egy mondatból biztosan kikövetkeztethető.

Elvesztek adatok. De nem az összes, csak egy napi adat. Nem valószínű, hogy a tegnapi adatok operatív kópiája másik adatbázisban volt. Tehát van mentés, és ez igen dícséretes. Ez rendben van. Kürt Kft. évek óta teszi a dolgát, és szerencsére lassan van hatása, vannak adatmentések, megtanuljuk félteni az adatainkat.

Viszont folyamatos üzem közben elvesztek az adatok, ami két dolgot jelenthet:

• hardver hiba történt, és az adattárolási rendszerben single point of failure van, azaz nincs RAID
• szoftver hiba volt, ami törölte az adatokat.

Az első egy üzemeltetési "hiba". Nem biztos, hogy hiba. Lehet tudatos döntés is. Annak a költsége, hogy két mentés közötti adatmennyiséget újra be kell vinni (egy napi adat) szorozva a hibásodás valószínűségével sokkal kisebb, mint a RAID tároló plusz költsége. Ha ez így van, akkor helyes döntés volt, kisebb a TCO. Csak nehezen tudom elhinni, és félek, hogy itt megint az elszámolással van a gond. Mibe kerül az intézménynek, és mibe kerül nekünk mindannyiunknak. Félek, hogy ha azt a munkát és költséget is belevesszük, amit a diákok tanárok fognak most "ingyen" beáldozni akkor sokkal olcsóbb a rendes tároló eszköz. De ez már politika.

A másik lehetséges hiba: szoftver. És itt jön a tesztelés. (Nah, csak kilyukadtunk oda ahova indultunk....) És persze a tervezés.

(Nem emlékeszem olyan projektre az elmúlt három évben, ahol készítettünk volna olyan adat modellt, amelyik ne emlékezett volna a múltjára. Ha volt egy ZZZ nevű tábla, akkor ott volt egy ZZZ_LOG tábla is, amelyik majdnem ugyanolyan volt, mint a ZZZ, csak kerül bele még egy időpont mező is, és gyűjti azokat a sorokat, amik megváltoznak (pl. törlődnek). És egyszer kellett is.)

Milyenre tervezték ezt a rendszert? Hogyan tesztelték?

Amikor írom ezt a bejegyzést (2010-02-08 7:42) az üzemeltető Educatio Kft. honlapján semmilyen információ nincs az esetről. www.educatio.hu/nyilvanossag/hirek_kozlemenyek

Ezt a blogot azért írom, hogy ilyen eset minél kevesebb legyen.

Minden szoftverben van hiba. Ha a szoftverben nincs hiba, akkor jön egy olyan felhasználó, aki tudja úgy használni, hogy összeessen. És akkor elgondolkodhatsz azon, hogy a szoftverben van-e a hiba, vagy a felhasználóban.

De ha nem hobbi programról van szó, akkor a felhasználó egyben ügyfél is, és ez megválaszolja a kérdést.

Az ügyfélnek mindig igaza van.

Nemrég összeomlott egy olyan rendszer, ami több, mint öt éves és több helyen üzemel stabilan. Ilyen is van. Bejelentkezni a rendszerre nem lehet (éles, adatok, és security), hát akkor nyomozzunk vaktában. Lekértük a logokat napló fájlokat. Csak az látszott, hogy öt másodperc helyett négy óra alatt állt le a rendszer, amikor szabályosan megpróbálták leállítani.

Csak halkan megjegyzem, hogy az ügyfél kivárta (szerintem du. otthagyta a rendszert), és nem lőtte le a processzeket.

Lekértük az összes többi modul naplót is. Na ott már láttunk valamit. Hamarosan rájöttünk, hogy mi volt a rendszer gondja, a folyamatosan működő Linux rendszer alatt valaki vagy valami átállította a hozzáférési jogosultságokat, és nem fért hozzá a programunk olyan fájlokhoz ami kellett neki, és ezzel igencsak küzdött a szoftver. Nem számítottunk rá, hogy egy beüzemelt éles rendszert valaki nekiáll piszkálni. Meg lehetett volna úgy is csinálni a rendszert, hogy ne csücsüljön le, de erre nem gondoltunk. Amúgy most is úgy gondolnám, hogy ezt nem lett volna illendő egy üzemelési környezetben megtenni (mármint, hogy egyszercsak megváltozik a hozzáférési jogosultság) de valahogy megtörtént.

Leírtuk, ahogyan kell, tessék visszaadni a jogosultságot, program újraindul és működni fog. Jira issue resolv-ba, várjuk a visszajelzést. Visszajelzés:

Nem volt semmilyen jogosultság módosítás, nem tudjuk mi történhetett. Most sem állítottunk semmit, viszont most már működik.

Aha...

Ez most egy kicsit erősebben szakmai bejegyzés.

Kell-e unit teszt? (naná)

Korábban már volt szó unit tesztelésről, és felvetettem azt a kérdést is, hogy a unit teszteket vajon a program kód megírása előtt, vagy utána kell elkészíteni. (És kell-e egyáltalán?)

Hogy mostanában volt néhány komolyabb fejlesztési, és nem csak tesztelési illetve szakértői feladat, elkezdtük nagyon szigorúan venni magunkat, és írtuk rendületlenül a unit teszteket. Eleinte csak azért, mert elhatároztuk, hogy de most aztán fogunk, meg mert ezt láttuk az Atlassian kódjában is, és nekik hiszünk. Később viszont azért is, mert sokkal jobban lehetett haladni.

A modulok ki voltak osztva, és amelyikben több unit teszt készült ott bizony kevesebb bugot kellett kijavítani az integrációs tesztek során.

Ha valahol hiba volt, és nem volt unit teszt, akkor írtam egyet. De eleinte nem. Eleinte azt mondtam, hogy ott egye meg a fene, dühös vagyok, aki kódolta a csapatban nem írt unit tesztet, az ő dolga lett volna, én nem írom meg helyette. Na ez hülyeség volt.

Azt gondoltam, hogy kijavítom a hibát, lefordítom, deployolom Tomcat alá, bejelentkezek, és ellenőrzöm, hogy működik. Nem működött. Tomcat újra indít debug módban, debuggolás. Ah.. ja, persze, hiba megvan. Kijavítom a hibát, lefordítom, deployolom Tomcat alá, bejelentkezek, és ellenőrzöm, hogy működik. Nem működött...

Amikor a harmadik hibánál eljátszottam ezt és a ciklus mind a három esetben hat-nyolc hibajavítást jelentett (igen, gyenge vagyok, vagy csak nagyon nehéz más kódját javítani), és a Tomcat is a modulok miatt 30mp alatt indult, szóval másfél vagy inkább két órája szórakoztam, és nem láttam még a végét, hogy mikor indul el végre rendesen a program, akkor kezdtem arra hajlani, hogy ahol lehet kellene írni valami unit tesztet.

A unit teszttel rögtön lehet debuggolni, nem kell a Tomcat indulásra várni, se deploy, se arra hogy a modulok mind betöltődjenek. Meg kell írni és onnan 10mp múlva lehet debuggolni.

Igen, csak volt egy kis bökkenő: a kód egy szervletben futott, és mint ilyen használta a HttpServletRequest változót, amit a http kérésből állít elő a tomcat, a válaszhoz a HttpServletResponse változót, a konfigurációhoz az Apache commons config-ját, szóval ezeket nem olyan egyszerű megteremteni a teszt környezetben.

Persze átírhatom úgy a kódot, hogy ezeket ne használja, direktben, és a tesztelendő részt kiemelem, de nem lenne hatékony, nem lenne szép, és főleg: ne a nyúl vigye a puskát. Van olyan, hogy kódot tesztelhetőre írunk, de azért mindennek van határa.

No de akkor mi a megoldás?

Az első lépés az, hogy a kódot úgy írjuk meg, hogy valóban unitként működjön. Más szavakkal lehessen külön, az általa használt objektumoktól részben függetlenül használni. Ennek egyik módja, hogy minden olyan objektum, amit kívülről használ, az setter-rel beállítható legyen, és ha nem lett beállítva, akkor a getter (amit belülről is használunk és nem a privát mezőt) hozza létre. Például:

private HttpServletRequest req=null;
public void setReq( HttpServletRequest req){
  this.req = req;
  }
public HttpServletRequest  getReq(){
  if( this.req == null ){
    this.req = Context.getContext().getHttpServletRequest();
    }
  return this.req;
  }

A példában a Context egy thread local tár, ahova a servlet doGet és/vagy doPost metódusa helyezi el a servlet konténer által adott  HttpServletRequest változót. Ha servlet konténerben fut, akkor rendesen működik, ahogy kell, ha viszont unit teszt, akkor beállítok egy tesztelésre jó  HttpServletRequest változót.

Eddig az elmélet. Az ördög viszont a részletekben nem alszik. Hogyan lesz nekem egy olyan változóm, amelyik a tesztelésre jó, és implementálja a HttpServletRequest interfészt?

A válasz erre az EasyMock csomag ami az http://easymock.org/ oldalon érhető el. Képes rá, hogy futási időben állítson elő olyan osztályokat, amelyek extendálnak meglevő osztályokat, vagy implementálnak interfészeket, és meg lehet adni, hogy milyen hívásra milyen válaszokat adjanak. Ezeket a válaszokat a teszt előkészítése során határozzuk meg, és a teszt futtatása során adja őket vissza a run-time létrehozott osztály.

Példaként itt a groowiki egy konkrét teszt metódusa:

    public void testPHMethodAbsolute() throws Exception {
        HitContext context = HitContext.getContext();
        HttpServletRequest req =
              EasyMock.createMock(HttpServletRequest.class);
        HttpSession session = EasyMock.createMock(HttpSession.class);
        EasyMock.expect(req.getSession()).andReturn(session);
        EasyMock.expect(req.getPathInfo()).andReturn("/path");
        EasyMock.expect(req.getContextPath()).andReturn("");
        EasyMock.expect(req.getServletPath()).andReturn("");
        EasyMock.replay(req,session);
        context.setReq(req);
        ParameterHandler ph = new ParameterHandler();
        EasyMock.verify(req,session);
        assertEquals("kakukk/../alma is not alma",
              "alma",ph.absolute("kakukk", "../alma"));
    }

Az elején lekérjük a HitContext változót ami thread local, és a paraméter handler innen kéri le a req változót majd. A createMock metódussal hozzuk létre a teszt req és a teszt session objektumokat. Az expect static metódussal mondjuk meg, hogy milyen hívásokat várunk majd a tesztelt modultól, és milyen értéket kell majd visszaadni.

 Amikor ezek megvannak, akkor a replay() metódus jelzi, hogy innen kezdve már nem a teszt definiálása folyik, hanem a teszt maga. A végén a verify() metódus pedig ellenőrzi, hogy minden hívás megtörtént-e amit vártunk.

Tudom, nem ez az egyetlen mock csomag Java-hoz. Kommentekben várom, hogy ki mit szeret. Az általam ismert lista a http://www.mockobjects.com/ oldalról:

• jMock
• EasyMock
• rMock
• SevenMock
• Mockito

Vagy éppen a mockejb amit szintén használtunk már.
 

Öregszem. Már nincsen mindenkiről és mindenről olyan hamar kiforrott véleményem, mint régen. És megbocsátóbb is vagyok. Ha valaki bevág elém autóval, veszélyeztetve az épségemet, nem felkoncolnám először, hanem az jut eszembe: biztos jó oka van sietni. Pedig valószínűleg többnyire nincs. A gyerekeimet sem úgy nevelném, mint ahogy tettem, amikor kicsik voltak, és amikor még én is fiatalabb voltam. Ha nem működik rendesen egy szoftver, vagy nincs rendes dokumentációja (ez utóbbira jó példa az Apache Shiro, leánynevén JSecurity), nem dobom rögtön el, mondván: ez szar, tudok ezerszer jobbat írni (pedig de tényleg).

Levelezünk a JavaListán (javalist@javagrund.hu), és vélhetően fiatalabb kollégám szememre veti elnéző megfogalmazásomat. Azt találtam mondani, hogy egy szoftverben nem olyan nagy baj, ha egy hibás használat során (nem felhasználói hiba, hanem programozói hiba, programból nem úgy használunk egy drivert, mint ahogy azt kell) nem definiáltan működik, esetleg nem kezeli le azt a hibát, amelyet nem is ő követett el, hanem az a programozó, aki felhasználta a könyvtárat. Ki lettem oktatva, hogy pedig erre oda kell figyelni, és a konkrét esetben milyen egyszerű lett volna, és írjak csak én is olyan kódot, ami nem dúlja fel az egész rendszert a másik programozó apró hibája miatt.

Ebben igaza van kollégámnak, és meg is írtam neki, hogy egyetértünk. Ha tehetem nem írok ilyen kódot (persze nem szándékosan becsúszhat ilyen hiba, bármilyen: ezért működnek az atomreaktorok 40 éves, kipróbált technológiákkal (remélem)), de ha valakinek ilyen sikerül még nem kiáltom azt, hogy szar. Mert ez van. Ha szar, akkor szar. Akkor ezzel kell trágyázni. De még mindig jobb, mintha még Perl-ben kellene programozni (vagy nem?).

Nem úgy működik a program, mint ahogy várom. Na de hogy jövök én ahhoz, hogy várjak valamit? Maximum a dokumentáció alapján. Mit mond a JavaDoc? Sokszor semmit. Üres, kigenerált oldalak érdemi információ nélkül. Persze a metódusok nevei is lehetnek beszédesek, de azért mégis. A Javadoc az osztály, a metódus specifikációja. Ha nincs, akkor nincs specifikáció. Ha nincs, akkor nem lehet azt mondani, hogy a program unit szinten megfelel a specifikációjának, mert az nincs neki. Akkor azt sem lehet mondani, hogy hiba van benne, vagy, hogy nincs benne hiba.

Ugyanakkor azt látom, hogy olyan fejlesztő csapatok, mint az Atlassian gyakorlatilag nem írnak JavaDoc-ot. Lehetetlen mennyiségű unit tesztjük van (az jó, azt szeretjük), de JavaDoc szinte nulla.

Nemrég debuggoltam egy programot, amit hárman írunk. Nem működött egy funkció. Nézem a kódot: nem rosszul működik, hanem nincs implementálva. Elkezdem írni. Rákeresek egy metódusom nevére: nézd már! Ilyen van máshol is. Akkor ez mégis implementálva lett? És hol használja a projekt ezt az osztályt? Sehol. (bummer). Hogyan kellene használnom (ne írjam meg már mégegyszer). Nézem a kódot: értem. Majdnem jó, de hibás. Beleírok. Fel is kommentelem... hamár. Aztán nézem tovább. Következő metódus. Ez épp azt csinálja, ami az előzőből kimaradt. Ja, hogy ezt meg kell hívni a másik előtt. JavaDoc nem mondta, mert nem volt. Vissza a javításom, JavaDoc módosít.

Hogy csinálja az Atlassian JavaDoc nélkül? És hogyan használjam az Apache Shiro-t rendes dokumentáció nélkül? Hogyan döntsem el, hogy melyik a jövő útja? Apache Shiro? JAAS? Spring Security (leánynevén acegi)? A Seam egyes, erre a kérdésre adott részei? Bezzeg a Microsoft megoldások, vagy az ORACLE. Tonnaszámra van dokumentáció, sokszor nem is rossz, akár bele is fulladhatok.

Erről eszembe jutott az emberorvos, meg az állatorvos története, amikor az állatorvos megbetegedett, kihívta az emberorvost. Megkérdezi az ember orvos: mi a baj? hol fáj? Mire az állatorvos: "Ja, úgy könnyű!"

Hol van a dokumentáció? "Ja, úgy könnyű!"

Persze ha könnyű lenne, akkor nem lenne olyan élvezetes, nagyobb lenne a konkurencia, minden más hülye is programozással foglalkozna, és annyi munka se csurranna, mint amennyi kevés most a válság idején.

Olvasom a kevés dokumentációt az open source programokról... Lesz munkánk.

Annak idején regisztráltuk a gogle.hu-t talán jó lesz valamire alapon. Rá van irányítva a web oldalunkra. Sok haszna eleddig nem volt. Átlag évente kétszer felhív valaki emiatt. Nem szó szerint idézem az egyik legutóbbit:

"Kikérem magamnak, hogy a cégük betör a gépemre és átállítja a kezdőlapot!"

-- Biztosíthatom, hogy ilyesmiről szó nincsen. Nem törünk be senkinek a gépére. Miért gondolja, hogy bárki is betört a gépére?

"A maguk cége jön be nyitóoldalként."

-- És mit szeretne, hogy mi jöjjön be?

"A gugli."

Itt egy unalmas rész, végigvezetve a tisztelt felhasználót a böngésző beállításain egészen a böngésző kezdőlap beállításig.

-- És oda mi van beírva.

"Hát a gugli."

-- Egy o-val, vagy kettővel?

"Eggyel."

-- Kettővel kellene.

"Mér az számít?"

Szerinted? Szívesen mondtam volna, hogy csak annyira, mint szárnyalás, meg a szarnyalás, de nem sértek meg senkit ha egy mód van rá.

És ehhez kapcsolódik egy e heti megbeszélés. Tisztelt potenciális/lehetséges/stb ügyfél  informatikai szakértőjével beszélgetünk technológiákról, amikor ismét és ismét, szinte már kényszeresen visszatér a felhasználói felület kérdésére. Többször ismétlem, hogy webes felületet fogunk készíteni, és az milyen jól használható, de közben érzem, hogy valami nem stimmel, elbeszélünk egymás mellett. Végül kiböki, hogy hát, mert az "emberanyag" olyan, hogy nagyon egyszerűnek kell lennie a felületnek, hogy tudják kezelni. Mert amit el lehet rontani, azt el fogják. Volt olyan, hogy a mérőóra állást a numerikus mezőbe beírták betűkkel. Úgy, hogy huszonháromezerkettőszázötvenhárom? Igen úgy. Mindenre gondolni kell.

Akkor kezdtem megérteni, hogy miért nem triviális, és hogy az "mér számít".

Az FSF.hu Alapítvány pályázatot írt ki, a pályázat lezárult, az eredmények megtekinthetőek.

A pályázati oldal.

Az eredmény.

Mi is pályáztunk, nem nyertünk. Persze nem esett jól, de ez ilyen.

Várjuk a következő alkalmat.

A múltkor éppen Varsóban készülődtem a hotelszobából indulni ügyfélhez, a gép még be volt kapcsolva, hotelnek volt is internete, amikor pittyegett a skype, és bejelentkezett egy fülöp-szigeteki ember, hogy honnan tudná letölteni az ISOAPUI programunkat. Megmondtam neki. Szerintem megtalálható, de azért hamarosan próbálok javítani a webünk struktúráján. (Az ügyfélnek mindig igaza van, és nem az a lényeg, hogy megtalálható, hanem, hogy meg is találja.)

Ez a programunk base24 banki protokoll tesztelésére való, a SOAPui programot egészíti ki, és ingyenesen használható, open source. Ez volt itt a reklám helye.

Most egy héttel később megkérdeztem tőle, ugyanígy skype-on, hogy sikerült-e elindulni vele, fogják-e használni. Mondja, hogy sikerült, de nem ezt fogják használni, hanem

[3:43:05] stephen: Hi Peter
[3:43:57] stephen: My boss decided we will just develop our own host sim.

A főnököm úgy döntött, hogy kifejlesztjük a saját host szimulátorunkat.

[3:44:30] Peter Verhas: what was the reasoning?

Mivel indokolta?

[3:46:40] stephen: The project was move by next year so we still have lots of time to develop.

A projektet elhalasztották a jövő évre, így van egy csomó időnk fejleszteni.

[3:47:03] Peter Verhas: is that a reason to reinvent the wheel?
[3:47:31] Peter Verhas: when ISOAPUI is there free of charge ?
[3:47:47] Peter Verhas: does not seem to be a good reason

Ez ok feltalálni a melegvizet, amikor az ISOAPUI elérhető ingyenesen? Nem tűnik jó érvnek.

[3:48:45] stephen: yup I actually raise it also to them but they insist that we will just develop our own

Én is mondtam, de ragaszkodnak hozzá.

 

(Nem stephen a nick-je, a vezetéknevet kitöröltem.) A beszélgetés további része a téma szempontjából érdektelen.

Érti ezt valaki?

Pegamento az a módszertan és kötő szoftver ami lehetővé teszi, hogy a tesztelés teljesen automatizált legyen. Ez a rendszer a GreenPepper, SOAPui és a jövőben reményeink szerint más szoftvereket is összeköt, így a Confluence web oldalról lehet elindítani további programozás nélkül SOAPui-ban futtatható teszteket.

A videó elérhető a youtube-on. Mivel 11 perc, és  a youtube újabban csak 10 percet enged meg, ezért két felé lett vágva. Az első rész bemutatja a tesztek előkészítését SOAPui-ban, a második pedig a Confluence oldalakon a GreenPepper-ből indított tesztelést.

• első rész
• második rész

Remélem érdekes, és sok kérdést fog felvetni.

Tesztelni ne az teszteljen aki fejleszt. Ne csak ő. Ez elég evidens, de hogy miért is ne, annak igen emlékezetes példáját tapasztaltam tegnap.

Készítettünk egy videót a Pegamento tesztelési technológiáról (ez itt a reklám helye), de voltaképp mindegy is, hogy miről. A lényeg, hogy screen capture-ök, hangalámondás, magyarázat 11 percben felér két órányi cikk elolvasásával. Két nap alatt lehet elkészíteni, és mivel nem csináljuk minden nap még a fun factor is megvan kicsit.

A videó készítésekor nem csak slide-okat rajzolok, hanem futtatom is a bemutatandó rendszert és olvasom a szöveget, ami kihívás, mert az agyamat (két dolog egyszerre) ugyanúgy kihajtja 150%-ra mint a CPU-t. Most sem értem, hogy az 1.7MHz CPU honnan vesz időszeletet a screen capture programhoz, hogy az USB diszkre írja a tömörített videót, amikor fut alatta a Tomcat beépített HSQL-lel, Confluence, GreenPepper, SOAPui és a CPU előtte is 100%-on pörgött amikor a mintapéldákat beállítottam. Talán azon spórol, hogy a Chrome, mint kliens kevés CPU-t eszik.

Amikor készen lett megkértem a feleségemet, hogy nézze át. Mivel 11 perc, meg nem is szeretem hallgatni a saját hangomat, ezért kimentem mosogatni. Alig két és fél perc telt el, amikor kiabál, hogy itt egy hiba.

No fene!

Hiba?

Nem vártam, hogy hibát talál benne, inkább azt, hogy olyanokat mond, hogy ez a mondat magyartalan, vagy nagyon makogok meg hasonlók. Hiba? De hát mindent futtatva vettem fel, nincs benne csalás, működött. Mondjuk egyszer két snitt között újraindítottam a Tomcat-et, mert 1GB memória kevés az egész demo végigfuttatásához miközben a HSQL is ugyanabban a JVM-ben van, de az a snitt később van, szinte a legvégén, és nem is vártam, hogy azt észreveszi.

Meg különben is: feleségem végzettségét tekintve orvos. Ez meg egy elég mély szakmai videó. Az alatt a fél perc alatt amíg mellette álltam a videó indítása után majdnem be is aludt. Akkor most mi van? Rajzanak a fejemben a gondolatok, és nem értem.

Megtörlöm a kezem, és megyek a géphez. Megállítjuk a videót, visszatekerjük (ez is milyen jó szó, unokáim azt sem fogják tudni, hogy létezett valaha mágnesszalag, de a videót ők is tekerni fogják).

A kép alján egy XPath kifejezésben 'http://websevriceshare.com' az namespace. Mi ezzel a baj? A szerviz amit a demoban "tesztelünk" a webservice.com oldalról jön, maguk alól veszik a névteret is. Persze, le is törném a kezüket, ha mondjuk a verhas.com névteret használnák (vagy éppen örülnék?). De megtehetnék azt is.

De nem webservice hanem websevrice! (kimondva azonnal hallható a különbség)

Lassan felfogom, hogy mi a gond amit kiszúrt, és rájövök, hogy csak egy névtér elnevezés, aminek csak az a kritériuma, hogy egyedi legyen. Elgépelték, de senkit sem zavart.

"Azt nem mi rontottuk ... " kezdem. (Milyen érdekes az emberi elme. Nem az volt az első, hogy az nem hiba, hanem, hogy nem én voltam.) "... meg mindegy is. Az csak egy névtér."

"Egy mi?"

"Csak egy név. Az is lehetne ott, hogy habakukk. Nem számít."

És ha számított volna? Gondolja bárki is közületek, hogy tudva tudták, hogy el van írva, és direkt csinálták? Vagy a tesztelés során csak egyszerűen átsiklott, senki nem vette észre, és mindenhol a namesapce öröklődött copy-paste, copy-paste, mint a német írásmódú magyar vezetéknevek...

Ennek mi köze a teszteléshez? Mint bárminek, és mindennek.

A múltkor egy tesztelési projekt során futottam bele az alábbi problémáb...

Nem. Bevallom férfiasan, éppen nem teszteltünk, hanem fejlesztettünk. (Ami persze, nincs tesztelés nélkül, mielőtt valaki kötözködni kezdene! Jajj nekem...) De azért érdekes...

Szóval a felhasználói felületen felhasználó kereshet. Megadhat országot, időpontot, lábméretet valamint egy színt, és megadjuk válaszként, hogy mely webshopos termékek illenek legjobban az ízléséhez. A feltételeket és/vagy jelleggel, tehát egyet, többet, egyet sem, mindet: ízlése szerint.

Ha az SQL lekérést összerakom String-ből, akkor az SQL fordul minden lekérésre. Ha előre lefordított SQL-t akarok, akkor N darab paraméter esetén 2^N kérést kell előre megírni (kézzel, vagy kóddal). Az túl sok.

Mi legyen?

István kitalálta a tutit (már kétszer is, és másodszor rájött, hogy három éve ezt már egyszer megoldotta), de mi lenne, ha a kommentekből az derülne ki, hogy van mégutibb is.

A múltkor felajánlottam egy könyvet. Most meg nem.

Nyár van, és nemsokára elmegyek szabadságra, ezért nem adom fel a kérdést, hogy magyarázzátok meg ...

Szóval volt egy szoftver, ami a weben keresztül szolgált ki kéréseket. A válasz összeállítása X darab adatbázis kérés után alakult ki, de mindenképpen 2mp-en belül kellett lennie a válaszidőnek. Az volt a megoldás, hogy aszinkron elindul a "számolás" és ha nincs válasz 2mp-en belül, akkor egy majdnem ugyanolyan jó konzerv választ fog kapni a felhasználó, mint amilyen a pontosan kiszámolt lett volna.

Hogy ez milyen alkalmazásnál tehető meg? Pont annál amit írtunk. Mindegy.

Szóval a rendszer várt egy aszinkron szálra, és ha az nem futott le 2mp-en belül, akkor nem várta meg, hanem leállította, és adott egy konzerv választ.

A baj ott volt, hogy az aszinkron thread használt egy adatbázis kapcsolatot. Az az adatbázis kapcsolat pool, amivel teszteltünk egy idő után észrevette, hogy senki sem hivatkozik a kapcsolatra, és a GC során visszarakta az adatbázis kapcsolatot a pool-ba. Ezt jól le is teszteltük.

Aztán az éles rendszeren egy másik DB pool volt a rendszer alatt.

A rendszer pedig elindult. Amíg nem volt túlterhelve, addig nem volt gond, működött. Méretezve is úgy volt, hogy bírja a terhelést, és naponta úgy 10...15 alkalommal fordult csak elő, hogy nem sikerült válaszolni 2mp-en belül. A 200 kapcsolatos pool kb. egy hét alatt fogyott el. Ahogy fogyott a pool egyre többször adott a rendszer konzerv választ, de ez a meghalást, a pool fogyását nem gyorsította, mert sokszor úgy ölte meg a szálat, hogy az még meg sem kapta a connection-t.

A legszebb a dologban az volt, hogy a connection pool észrevette, hogy felszabadult a kapcsolat, és még le is loggolta, hogy visszarakta a pool-ba, de nem tette. Csak amikor elkezdtük loggolni a pool méretét, akkor derült ki, hogy hiába mondja azt, hogy visszarakta, az ilyenkor eggyel mindig csökkent, mint a szamárbőr.

A legcsúnyább pedig az volt a dologban, hogy gondoltunk rá, hogy ez lehet egy számunkra ismeretlen connection pool implementációval, és ezért a szoftverben volt egy

if( true ){

megöljük a thread-et

}

jellegű kód, és felette 10 sorban komment és magyarázat, hogy miért kell az 'if' után false-t írni, mert különben a szoftver elveszítheti a megölt thread-ben használt DB kapcsolatot, és inkább egyen még egy kis erőforrást a thread amíg lefut, mintsem elfogyjanak a kapcsolatok.

És néztük százszor, és néztük ezerszer a kódot, és csak éppen nem szúrta ki a szemünket, hogy a kommentben 'false' van írva, de a kódban 'true'. Két hétig. Stílusosan mondhatnám, hogy beégett a szemünkbe.

Ez történt.

Na és mi az a beégetéses teszt? Nem ez. A beégetéses teszt nem az, hogy jól beégünk, hanem az, hogy hajtjuk a szoftvert változó, de valamennyire reprodukálható inputtal, terheléssel, és nézzük, hogy nem ég-e be, bírja-e a terhelést, vagy rendszeresen újra kell indítani. Napokig, hetekig, hónapokig akár, attól függően, hogy mennyi az az időszak, ameddig a szoftvernek folyamatosan kell bírnia.

Nem biztos, hogy az a cél, hogy ne kelljen újraindítani. (A mi esetünkben az volt, az üzleti konzekvenciákat nem írom le, de nem volt jó referencia.) Lehet az is, hogy egy 5x8-as szoftvernél elég ha egy napot kibír újraindítás nélkül, éjjel úgyis újra lehet indítani (esetleg automatikusan), és nem ad semmi előnyt azzal a költséggel szemben amit a hibakeresés mondjuk 3 mérnöknapja jelent. Elvileg. Gazdaságilag. Közgazdász szemmel. Aztán nekem az egyik szemem közgazdás, a másik meg mérnök. (Csak ezt kellene eldönteni, hogy melyik.)

Mindig benne van a (mérnök) emberben, hogy ha olyan hiba van a szoftverben, ami miatt minden éjjel újra kell indítani, akkor az más disznóságokat is csinálhat. De, mint tudjuk ilyen szoftverrel is lehet világbirodalmat építeni. Közgazdász szemmel.

Nekem viszont csak az egyik szemem a kancsal. A közgazdász, vagy a mérnök?

Azért a kommentekbe, ha veszi valaki a fáradtságot, kérem megfejtésnek egy francia író nevét.