[Java lista] Szoftver-tesztelés

2010. Sze. 7., K, 00:28:39 CEST

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

--------- következő rész ---------
Egy nem text típusú csatolt állomány át lett konvertálva...
Név: smime.p7s
Típus: application/pkcs7-signature
Méret: 3792 bytes
Leírás: nem elérhető
Url : http://javagrund.hu/pipermail/javalist/attachments/20100907/b498b6d3/attachment.bin 