[Java lista] Válasz: Re: Szoftver-tesztelés
istvan.ketler at lhsystems.com
istvan.ketler at lhsystems.com
2010. Sze. 7., K, 15:46:52 CEST
Igaz hogy 15 evvel ezelott eltem sajat cegbol, de akkor a vevoim meg dijaztak az oszinteseget. Tobb nehez helyzetben is segitett, hogy oszinten feltartam a reszemrol felmerulo hibakat. Tobb uj vevom is jott ugy, hogy XY ceg ajanlotta.
Lehet, hogy azota mas lett a piac, de akkoriban nem probaltuk masra tolni a felelossegeket. De nem hiszem, hogy ma ez jobban kene.
Udv
Ivan
Sent from my cellular
------ Eredeti üzenet ------
Feladó: javalist-bounces at javagrund.hu <javalist-bounces at javagrund.hu>
Címzett: javalist at javagrund.hu <javalist at javagrund.hu>
Elküldve: Tue Sep 07 14:29:51 2010
Tárgy: Re: [Java lista] Szoftver-tesztelés
Valójában nem is a fejleszto/szállító cég feladata a User Acceptance Test elvégzése, hanem a User vagyis a vevo feladata és költsége. Ideális esetben ez a tevékenység a minosé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 amitol eltérünk és mennyire. Számomra a másik rendszer fejlesztojének mocskolása nem elfogadható. Már csak azért is érdemes ezzel óvatosnak lenni, mert lehet, hogy o letesztelte tisztességesen és dokumentálni is tudja. Hosszútávon mindenképp kifizetodo az "egyetemi szintu" tesztelés.
Én mockolok nem mocskolok.
üdv
vi
Verhás István
JIRA szakérto
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 fejleszto cég elkövette azt a hibát, hogy a külso
> 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 fejlesztojét (joggal vagy anélkül) amíg a felhasználó
> bele nem egyezik, hogy az o 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ú leveldbol 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 megeheto apránként. Persze több ido is kell hozzá mint egy szendvicshez. Konkrétan például a leírásodban folyamatosan keveredik a modul/rendszer szintu funkcionális teszt és az integrációs teszt. Modul/rendszer alatt értem azt amire azt írod, hogy belso vagyis amihez képest külso rendszerek is kapcsolódnak. A modul szintu funkcionális tesztelés során egyetlen külso rendszert sem szabad/célszeru bekapcsolni a tesztbe, hanem azok helyett mockolt külso 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 elojön a hiba az integrációs teszt során, akkor igen jó eséllyel tudsz rámutatni az éppen bekapcsolt külso szolgáltatásra mint hibaforrásra. Igen a külso rendszereket sem egyszerre célszeru 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 elobbi ügymenet adott fázisában könnyebben menedzselheto a felelosség kérdése és nincs vagy legalábbis kevesebb az egymásra mutogatás.
>> A classpath probléma maven-el is elofordulhat, de azért ahhoz nagyon ügyesnek kell lenni.
>> üdv
>> vi
>>
>> Verhás István
>> JIRA szakérto
>> 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 kezdodik és legalább egy tucat külso 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 muködését viszont
>>> igazi muvészet - foképp, ha a kódbázis kétharmada a külso rendszerekkel való
>>> kommunikációért felelos... :)
>>>
>>> Ha ehhez hozzávesszük, hogy a külso rendszerek közül van, amelyiknek csak és
>>> kizárólag éles verziója van éles adatokkal, akkor ez eléggé aknamezové teheti
>>> a teszteket, ilyenkor szokták a félosebb idoszakokban azt mondani, hogy majd
>>> kieso órákban éles üzemben teszteljük, legfeljebb visszaállunk. :)
>>>
>>> Van eset, amikor a külso rendszernek van ugyan teszt környezete, de csak
>>> idonként érheto el, és akkor is jelentosen 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 üzembol érkezo módosítást
>>> kérünk.
>>>
>>> Van olyan, amikor egy a külso rendszer teszt környezete egyben fejlesztoi
>>> környezet (jobb esetben integrációs környezet), ekkor egy hibás válasz esetén
>>> tesztelo legyen a talpán, aki eldönti, hogy mi és hol okozta a hibát.
>>>
>>> Van olyan, amikor nem a külso rendszer teszt környezete a hibás, hanem a két
>>> helyet összeköto (teszt- vagy backup-)hálózaton tesztelnek vagy javítanak a
>>> hálózatért felelos emberek, az öt évvel ezelott megszunt cég meghalt
>>> fejlesztoje á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örnyezetbol 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 mukö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 mukö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éro verziójú - jar fájl a classpath-on, és valami fájlrendszerbeli ok miatt
>>> az összes szerver a jót találta meg elsore, ezért nem próbálkozott meg a rossz
>>> betöltésével, a különc szerveren viszont a rosszat találta meg elsore, ezért
>>> volt hibás - persze miért ne az éles környezetben történjen ilyen... :)
>>>
>>> További problémák lehetnek a muködési paraméterek különbözosé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 rendszerrol 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 feltuno módon, esetleg mukö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 üzembol
>>> 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ó
>>> mukö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 muködtek volna... :)
>>>
>>> Szóval összefoglalva: egy közepesen összetett program és/vagy rendszer
>>> esetén én még nem láttam azonosan muködo 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
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck
További információk a(z) Javalist levelezőlistáról