[Java lista] Szoftver-tesztelés

2010. Sze. 8., Sze, 14:30:59 CEST

Ezt egy másik sportágban lehet megtanulni, agyaggalamb lövészet a neve. Én nem értek hozzá. Eddig sikerült mindig a projekt elvállalása előtt tisztázni, hogy céltáblára vagy repülő agyaggalambra lövünk és csak a céltáblát vállaltuk be.
ü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 8, 2010, at 10:30 AM, Gábriel Ákos wrote:

> 
> Még egy: ahhoz, hogy mockoljunk, stabil API kell, a mockolt szolgáltatás
> részéről, ugye? Mit csinálunk, ha a mockolt szolgáltatás szállítója ezt
> nem tartja be? Bármilyen okból... (és itt legalább 3-at tudok mondani)
> 
> 
> On Tue, 2010-09-07 at 14:29 +0200, Istvan Verhas wrote:
>> Valójában nem is a fejlesztő/szállító cég feladata a User Acceptance Test elvégzése, hanem a User vagyis a vevő feladata és költsége. Ideális esetben ez a tevékenység a minőségbiztosítás része és egy harmadik független (a szállítótól független) fél végzi el.
>> Azt én is tudom, hogy az elmélet és a gyakorlat csak elméletben azonos.
>> Azért néha mégsem árt átgondolni, hogy mi az amitől eltérünk és mennyire. Számomra a másik rendszer fejlesztőjének mocskolása nem elfogadható. Már csak azért is érdemes ezzel óvatosnak lenni, mert lehet, hogy ő letesztelte tisztességesen és dokumentálni is tudja. Hosszútávon mindenképp kifizetődő az "egyetemi szintű" tesztelés.
>> Én mockolok nem mocskolok.
>> 
>> ü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 7, 2010, at 7:55 AM, Gábriel Ákos wrote:
>> 
>>> 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... :)
> 
> -- 
> Üdvözlettel,
> Gábriel Ákos
> 
> 
> _______________________________________________
> 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/20100908/1634291c/attachment-0001.bin 