[Java lista] Szoftver-tesztelés

2010. Sze. 7., K, 07:55:46 CEST

Kedves István,

Egyetemi szinten tökéletes amit írtál. De az élet nagyon sokszor mást
mutat. Ha valaki mint fejlesztő cég elkövette azt a hibát, hogy a külső
rendszerek "mockolását" nem vette bele a projekt scope-jába - márpedig
elköveti, mert másképp nem nyerhet, mert túl drága lesz - akkor ez így
marad. Ilyenkor politikailag egy módszer marad: addig kell mocskolni a
másik rendszer fejlesztőjét (joggal vagy anélkül) amíg a felhasználó
bele nem egyezik, hogy az ő költségére pluszban ki lehesen fejleszteni a
mockolást. Akinek van jobb ötlete, írja meg! :)

Üdv,
Ákos

On Tue, 2010-09-07 at 00:28 +0200, Istvan Verhas wrote:
> Szia Gábor!
> 
> Hosszú leveldből számomra az világli ki, hogy számodra a tesztelés egy összetett és bonyolultan egymáshoz kapcsolódó rendszerek esetén túl nagy falat. Van egy jó hírem, ez a nagy falat is megehető apránként. Persze több idő is kell hozzá mint egy szendvicshez. Konkrétan például a leírásodban folyamatosan keveredik a modul/rendszer szintű funkcionális teszt és az integrációs teszt. Modul/rendszer alatt értem azt amire azt írod, hogy belső vagyis amihez képest külső rendszerek is kapcsolódnak. A modul szintű funkcionális tesztelés során egyetlen külső rendszert sem szabad/célszerű bekapcsolni a tesztbe, hanem azok helyett mockolt külső szolgáltatásokkal kell tesztelni. Ideális esetben a partner(ek) is megteszik ezt és utána az integrációs teszt már csak egy pipa. A valóságban, amikor a partnerek ezt nem teszik meg, akkor is nagyon hasznos ez a szétválasztás mert amikor előjön a hiba az integrációs teszt során, akkor igen jó eséllyel tudsz rámutatni az éppen bekapcsolt külső szolgáltatásra mint hibaforrásra. Igen a külső rendszereket sem egyszerre célszerű bekapcsolni, hanem egyesével. Ha a funkcionális tesztelés automatizáltan futtatható, akkor ez nem okoz plusz költséget vagy elhanyagolható.
> Az integrációs teszt elvégzéséhez természetesen szükség van az integrációs teszt környezetre. Ha ez nem áll rendelkezésre akkor az előbbi ügymenet adott fázisában könnyebben menedzselhető a felelősség kérdése és nincs vagy legalábbis kevesebb az egymásra mutogatás.
> A classpath probléma maven-el is előfordulhat, de azért ahhoz nagyon ügyesnek kell lenni.
> üdv
> vi
>    
> Verhás István
> JIRA szakértő
> Verhás & Verhás Szoftver Manufaktúra Kft.
> istvan at verhas.com
> t: +36(30)3997117
> skype: verhasi
> 
> On Sep 5, 2010, at 10:18 PM, Auth Gábor wrote:
> 
> > 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
> > _______________________________________________
> > Javalist mailing list
> > Javalist at javagrund.hu
> > http://javagrund.hu/mailman/listinfo/javalist
> 
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist

-- 
Üdvözlettel,
Gábriel Ákos