[Java lista] Szoftver-tesztelés

[Auth Gábor]

Halihó!

2010. szeptember 5. 21.11.07 dátummal András Csányi az alábbiakat írta:
>>  Tegye fel a kezét, akinél egy közepesen összetett program a teszt- és az
>> éles környezetben azonosan viselkedett... :) 
>>  Egy kezet se látok...  akkor meg minek annyit tesztelni? :D
> Gábor, közepesen összetett programteszt...?

  Mondom közepesen összetett program... :)

> Ha nem tudod megcsinálni azt, hogy a tesztkörnyezetben futó szoftver
> és az éles környezetben futó szoftver ugyanúgy viselkedjen, akkor
> valamit benéztél. :)

  Vagy nem láttál még közepesen összetett rendszert, ez kb. 5-10 millió 
programsortól kezdődik és legalább egy tucat külső rendszerhez kapcsolódik. 
Ekkora "saját" rendszert nem kihívás tesztelni, ha viszont SOA elvek mentén 
állandóan önmagát hívja keresztül-kasul, akkor az egész működését viszont 
igazi művészet - főképp, ha a kódbázis kétharmada a külső rendszerekkel való 
kommunikációért felelős... :)

  Ha ehhez hozzávesszük, hogy a külső rendszerek közül van, amelyiknek csak és 
kizárólag éles verziója van éles adatokkal, akkor ez eléggé aknamezővé teheti 
a teszteket, ilyenkor szokták a félősebb időszakokban azt mondani, hogy majd 
kieső órákban éles üzemben teszteljük, legfeljebb visszaállunk. :)

  Van eset, amikor a külső rendszernek van ugyan teszt környezete, de csak 
időnként érhető el, és akkor is jelentősen limitált teljesítménnyel. Ennél 
csak az rosszabb, amikor közös interfésze van az éles és teszt rendszernek, és 
a kérés egy paramétere - jó esetben ez egy flag, rossz esetben 0-y közötti 
azonosítóval teszt adatok, x-végtelen között éles azonosítók vannak, s ez 
rendelkezik arról, hogy most tesztelünk vagy éles üzemből érkező módosítást  
kérünk.

  Van olyan, amikor egy a külső rendszer teszt környezete egyben fejlesztői 
környezet (jobb esetben integrációs környezet), ekkor egy hibás válasz esetén 
tesztelő legyen a talpán, aki eldönti, hogy mi és hol okozta a hibát. 

  Van olyan, amikor nem a külső rendszer teszt környezete a hibás, hanem a két 
helyet összekötő (teszt- vagy backup-)hálózaton tesztelnek vagy javítanak a 
hálózatért felelős emberek, az öt évvel ezelőtt megszűnt cég meghalt 
fejlesztője által fejlesztett modul pedig misztikus hibaüzenetekkel 
szórakoztatja az üzemeltetést, aztán az üzemeltetés a fejlesztést, azok pedig 
hosszas tanácstalanság után halkan rákérdeznek, hogy a hálózattal van-e valami 
gond, mire kiderül, hogy van azzal gond, de a hálózatosok úgy gondolták, hogy 
50 százalékos csomagvesztés egy teszt környezetben nem ok arra, hogy szóljanak 
róla.

  Van olyan, amikor egy-egy szerver költözik karbantartás vagy gépterem 
reorganizáció kapcsán, vagy az élesben éppen meghibásodott, ezért a teszt 
környezetből pótolták, és amíg megjön a megrendelt dolog, addig fél lábon vagy 
ülve kibírja a teszt rendszer az a három hónapocskát. Persze három hónapig 
csak álom a teszt és az éles azonos működése.

  Arról nem is beszélnék, amikor ránézésre szinte bitre ugyanaz az alkalmazás 
szerver teszt rendszeren gond nélkül működik, éles környezetben pedig az egyik 
láb baromságokat csinál - megtörtént eset. Nem kellett végül fekete kakast 
áldozni éjfélkor a gépteremben, az ok triviális volt. Volt két azonos - de 
eltérő verziójú - jar fájl a classpath-on, és valami fájlrendszerbeli ok miatt 
az összes szerver a jót találta meg elsőre, ezért nem próbálkozott meg a rossz 
betöltésével, a különc szerveren viszont a rosszat találta meg elsőre, ezért 
volt hibás - persze miért ne az éles környezetben történjen ilyen... :)

  További problémák lehetnek a működési paraméterek különbözősége, hiszen a 
teszt rendszernek teszt adatbázist kell elérnie, teszt felhasználókkal, és jól 
látható módon jeleznie kell minden felhasználóval való kapcsolata esetén, hogy 
teszt rendszerről van szó. Ezért az éles üzemhez más paraméterezéssel kell 
futnia, mint teszt környezetben, és itt szoktak eltérések mutatkozni, jó 
esetben feltűnő módon, esetleg működésképtelenséget okozva (hálózatilag 
elszeparált éles és teszt környezet), rossz esetben sunyi módon az éles üzembe 
tett modul a teszt környezethez csatlakozik, vagy fordítva.

  Ezen túl gyakori, hogy a teszt környezetben nincs annyi és olyan gép, hogy 
terheléses, illetve stressz teszteket lehessen futtatni. Gyakran éles üzemből 
levedlett gépek kerülnek a teszt környezetbe, gyakran még ilyen gépek se. 
Mostanában divat a virtualizáció, így sok esetben az éles környezet fizikai 
hardveren fut, a teszt környezet pedig virtualizálva, ez is jelenthet apró 
működésbeli különbségeket.

  Olyan céget igen keveset láttam, ahol sikerült volna elérni a "klasszikus" 
éles-, teszt-éles-, stressz-teszt- és/vagy QA-teszt-, felhasználói-teszt- 
és/vagy funkcionális-teszt-, illetve integrációs környezeteket. Olyat még 
egyet se, ahol ezek mind egyformán működtek volna... :)

  Szóval összefoglalva: egy közepesen összetett program és/vagy rendszer 
esetén én még nem láttam azonosan működő teszt és éles környezetet... :)
-- 
http://www.javaforum.hu -=- http://www.enaplo.hu
Auth Gábor -=- http://www.javaforum.hu/web/10/authgabor