Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

 Windisch Gergely, 2010 Windisch Gergely 2014. ITIL – SDLC - Terheléstesztelés Óbudai Egyetem.

Hasonló előadás


Az előadások a következő témára: " Windisch Gergely, 2010 Windisch Gergely 2014. ITIL – SDLC - Terheléstesztelés Óbudai Egyetem."— Előadás másolata:

1  Windisch Gergely, 2010 Windisch Gergely ITIL – SDLC - Terheléstesztelés Óbudai Egyetem

2  Windisch Gergely, Bevezetés Óbudai Egyetem

3  Windisch Gergely, 2010 SDLC – Software Development LifeCycle •A szoftverfejlesztési életciklus részei –Project tervezés és kivitelezhetőség? – mekkora a feladat, megoldható-e? –Rendszer analízis és követelmény meghatározás – mit szeretne a felhasználó? mink van nekünk? –Rendszer tervezés (design) – hogyan valósíthatjuk meg, amire szüksége van a felhasználónak? –Implementáció – hogyan készítjük el a megoldást –Elfogadtatás (acceptance) és telepítés (deployment) – megfelel-e a megrendelőnek az elkészült mű? –Karbantartás – folyamatos megfigyelés, ha valami gond van, azt javítjuk Óbudai Egyetem

4  Windisch Gergely, 2010 ITIL projekt életciklus Óbudai Egyetem

5  Windisch Gergely, 2010 Application life cycle Óbudai Egyetem

6  Windisch Gergely, 2010 ITIL vs. SDLC •Az ITIL leírás nem lecseréli az SDLC-t, hanem magába foglalja azt Óbudai Egyetem

7  Windisch Gergely, 2010 Szoftver tesztelés életciklus Óbudai Egyetem

8  Windisch Gergely, 2010 Bevezető •Mi a célja szoftver tesztelésnek? –Próbáljuk definiálni a fogalmat Óbudai Egyetem

9  Windisch Gergely, 2010 Bevezető •Hibás definíciók "A az a folyamat, amikor megmutatjuk, hogy nincsenek hibák" "A tesztelés célja a program helyes működésének bemutatása" "A tesztelés az a folyamat, ahol meggyőződünk arról, hogy a program azt teszi, amit elvárunk tőle" Óbudai Egyetem

10  Windisch Gergely, 2010 Bevezető •Ezek a definíciók fordítottak. Ha azt akarjuk megmutatni, hogy a program hibátlanul működik, akkor olyan teszt eseteket választunk, amelyekre a program jól fog működni. Így viszont nem találjuk meg a hibákat, ezért a tesztelés nem ér túl sokat. Óbudai Egyetem

11  Windisch Gergely, 2010 Bevezető •A szoftver tesztelés az a folyamat, amikor a hibák feltárása céljából futtatjuk az alkalmazást. Óbudai Egyetem

12  Windisch Gergely, 2010 • Szoftver tesztelés két fő csoportra osztható – Funkcionális tesztelés • Győződjünk meg, hogy az alkalmazásunk hibamentes-e – adott inputra adott output, – helyes számítások, – specifikációkban előírtaknak megfelel – az újonann implementált / javított elemek milyen új hibát okoznak – Terhelés tesztelés • Milyen hibák jönnek elő a funkcionálisan hibátlan szoftveren nagy terhelés alatt Az órákon először nagyon röviden a funkcionális teszteléssel foglalkozunk, majd pedig rátérünk a terheléstesztelésre. Bevezető

13  Windisch Gergely, Funkcionális tesztelés Óbudai Egyetem

14  Windisch Gergely, 2010 Funkcionális tesztelés •Hibátlan szoftver nem létezik*. •A szoftvertesztelés témaköre igen szerteágazó. A legalsó szinten van a tényleges teszt végrehajtás, amit az emberek általában szoftvertesztelés néven ismernek. Itt derül ki, hogy az alkalmazásunk az általunk elvárt válaszokat adja-e a feltett kérdésekre. A szoftverek tesztelése azonban több annál, hogy ötletszerűen kattintunk az alkalmazásban, hátha találunk valami hibát. •A hatékony tesztelés legfontosabb eleme a tervezés. Meghatározni, hogy egy adott funkciónak mi az elvárt működése, megállapítani, hogy ez hogyan ellenőrizhető (mind az, hogy bekövetkezik, és az is, amikor nem), milyen bemenetre milyen választ kell kapnunk, majd kialakítani azokat a paramétereket, amelyekkel a válasz minősége pontosan meghatározható. Ezt követően a tesztelés manuális, kattintós része már nagyon egyszerű feladat. •Összetett alkalmazások esetében fontos a hibák követése - vagyis hogy egy hiba mikor került a rendszerbe, mikor javították ki, nem jött-e elő ismét egy későbbi verzióban. Óbudai Egyetem *:

15  Windisch Gergely, 2010 Bemelegítő feladat Van egy alkalmazásunk, amelyik vár három egész számot a felhasználótól, amik egy háromszög oldalai. A megadott oldalhosszok alapján eldönti, hogy az adott háromszög –Általános háromszög (minden oldala különböző) –Egyenlő szárú háromszög (két oldala egyenlő) –Egyenlő oldalú háromszög (mindhárom oldala azonos) A feladat: készítsen teszt eseteket (vagyis három beadandó számot), amelyekkel ellenőrizhető a program helyes működése Óbudai Egyetem

16  Windisch Gergely, 2010 Bemelegítő feladat tippek •15 különböző eset Óbudai Egyetem

17  Windisch Gergely, 2010 Különböző vizsgálatok alapján: • A HW költségek csökkennek • A gépek gyorsulnak • A SW fejlesztés költségei mégis nőnek • nagyobb gépek, komplexebb rendszerek • a minőség biztosítása még fontosabb Miért drága a szoftver fejlesztés? Óbudai Egyetem

18  Windisch Gergely, 2010 Forrás: [1] IT projectek sikeressége (idő/költségvetésen belül) ‏ Óbudai Egyetem

19  Windisch Gergely, 2010 •Az előző ábra mutatja, hogy milyen arányban voltak sikeresek a szoftver fejlesztési projektek. Három lehetséges kimenet: sikeres, sikertelen, kihívásokkal küszködő. –Sikeres, ha minden működött és időben készen volt az alkalmazás –Kihívásokkal küszködő, ha elcsúszott a fejlesztés, többe került, rész feladatok nem lettek megvalósítva (vagy nem úgy, ahogy eredetileg kellett volna) –Sikertelen, ha hosszú fejlesztés után végül törölték a munkát. •Az ábrából látható, hogy a sikeres projektek száma nem nőtt. Ez nagyon nagy plusz kiadást ró az iparágra, ami komoly drágulást eredményez. Óbudai Egyetem

20  Windisch Gergely, 2010 Sikeres projectek sikerességének okai: • Kellő támogatottság (18%) ‏ • Megrendelővel való kapcsolattartás (16%) ‏.. Mi okozta a sikert? Óbudai Egyetem

21  Windisch Gergely, 2010 Forrás: [1] Hibák bevezetése / fellelése Óbudai Egyetem

22  Windisch Gergely, 2010 Leggyakrabban előforduló hiba • A probléma már az igények összeállításakor megjelenik. A világosan meghatározott célok segítenek a sikeres munkavégzésben Hibák bevezetése / fellelése Óbudai Egyetem

23  Windisch Gergely, 2010 Forrás: [1] Hogyan ne vezessük a projectünket (1) ‏ Óbudai Egyetem

24  Windisch Gergely, 2010 Forrás: [1] Hogyan ne vezessük a projectünket (2) ‏ Óbudai Egyetem

25  Windisch Gergely, 2010 Forrás: [1] Hogyan ne vezessük a projectünket (3) ‏ Óbudai Egyetem

26  Windisch Gergely, 2010 Forrás: [1] Hogyan ne vezessük a projectünket (4) ‏ Óbudai Egyetem

27  Windisch Gergely, 2010 Az eredmény: hosszas fejlesztés után van egy elégedetlen ügyfelünk, rengeteg elpazarolt erőforrásunk, és egy megoldásunk, ami nem jó semmire. Mindez azért, mert a pontos specifikáció elmaradt. Hogyan ne vezessük a projectünket (5) ‏ Óbudai Egyetem

28  Windisch Gergely, 2010 Néhány iterációs lépés után aztán talán sikerül elkészíteni a terméket, amire a megrendelő vágyott. Miért baj ez, amennyiben végül a termék megfelelő lesz? Hogyan ne vezessük a projectünket (6) ‏ Óbudai Egyetem

29  Windisch Gergely, 2010 Forrás: [1] Hibajavítási költségek Óbudai Egyetem

30  Windisch Gergely, 2010 Forrás: [1] Szoftvertesztelés fejlődése Óbudai Egyetem

31  Windisch Gergely, 2010 Legkorszerűbb módszer, a rendszert üzleti folyamatokra bontják fel, és ezeket az egységeket tesztelik. Üzleti folyamat pl. utazási irodánál a repülőjegy vásárlás: • Bejelentkezés • Indulási paraméterek kiválasztása • Érkezési paraméterek kiválasztása • Járat választás • Bankszámla adatok megadása • Kijelentkezés Üzleti folyamat alapú tesztelés Óbudai Egyetem

32  Windisch Gergely, 2010 White box A tesztelő (tipikusan a programozó) tudja, hogy a tesztelendő kód mit csinál, hogyan működik pl: ellenőrzés, hogy adott inputra megfelelő-e az output Black box A tesztelő nem tudja, hogy a tesztelt funkció hogyan működik. Általában külön személyek végzik. Tesztelési technikák Óbudai Egyetem

33  Windisch Gergely, 2010 • Requirements verification • Megrendelő: mit szeretnék ettől a funkciótól? Mikor jó? • Mérhető eredmények megállapítása • Unit test (white box) ‏ • A kód terv szerinti működését nézi, elemenként • Integration test (black box) ‏ • Business Function test • Üzleti folyamatok ellenőrzése • Business Process test • Üzleti eljárások (belső működés tesztelése) ‏ • System test • A rendszer egészének működését ellenőrző teszt • Performance test • Helyesen működő alkalmazást vizsgáljuk abból a szempontból, hogy hogyan reagál egy adott terhelés esetén • User Acceptance test • Végső teszt, ami alapján a megrendelő eldöntheti, hogy az alkalmazást elfogadja-e. Különböző tesztelési fázisok Óbudai Egyetem

34  Windisch Gergely, 2010 • JUnit - unit tesztek • Eljárásoknak adott bemeneti érték, ellenőrzéssel • Bugzilla • Hiba követés • HP Quality Center (Business Process Testing) ‏ – Közös felületet ad a teljes tesztelési projectnek, a specifikációtól kezdve a hibakövetésig – Kiváltja a korábbi megoldásokat (Word, Excel) ‏ • HP Quick Test Professional – Automatizált tesztelést tesz lehetővé – Új kiadások régi funkcióinak tesztelésére alkalmas Tesztelést segítő alkalmazások Óbudai Egyetem

35  Windisch Gergely, Funkcionális tesztelés - HP Quality Center Óbudai Egyetem

36  Windisch Gergely, 2010 Minőség biztosítás lépései Forrás: [2] HP Quality Center Óbudai Egyetem HP Quality Center 5 lépést ajánl a fejlesztési projektben • Kiadások meghatározása: készítsünk egy tervet a különböző verziók kiadási ciklusairól • Követelmények meghatározása: Funkcionális is teljesítménybeli elvárások meghatározása • Tesztek tervezése: Olyan tesztek meghatározása és implementálása, amelyek segítségével a követelmények teljesítése pontosan mérhető • Tesztek lefuttatása: A megtervezet tesztek időzítése, megszervezése, futtatása • Hibakövetés: A megtalált hibák központi gyűjtése és figyelemmel kísérése.

37  Windisch Gergely, Terhelés tesztelés Óbudai Egyetem

38  Windisch Gergely, 2010 Az utóbbi 20 évben a számítógépes alkalmazások a munka automatizálásának eszközeivé váltak A munka hatékonysága és a termelékenység jelentősen növekedett Az együttműködés és az információ megosztása a gazdaság fejlődésének hajtóerejévé vált Az információmegosztás és a tranzakció feldolgozás a vállaltok üzletileg kritikus alkalmazásai lettek A szoftverfejlesztés technológiája sokat fejlődött az elmúlt évtizedekben, de az alkalmazások bonyolultsága is jelentősen növekedett A mai alkalmazások számtalan komponens összehangolt és hibátlan működését feltételezi Az alkalmazások bonyolultsága és a hibák előfordulásának lehetősége között szoros korreláció van Az alkalmazások bonyolultságának növekedésével a hibák feltárása egyre nehezebbé válik Bevezetés Óbudai Egyetem

39  Windisch Gergely, 2010 A gyorsan változó üzleti követelményekhez állandóan alkalmazkodni kell Ez együtt jár a számítógépes alkalmazások gyakori (éves, havi, heti) változtatásával A szoftverek gyakori változtatása jelentős kockázattal jár, amely az üzleti folyamatokon kívül a szoftverfejlesztési folyamatot is érinti A funkcionális működés és a terheléstesztelés automatizálása a szoftverfejlesztés folyamatának részévé vált Bevezetés Óbudai Egyetem

40  Windisch Gergely, 2010 Bevezetés Lassú a rendszer! Óbudai Egyetem

41  Windisch Gergely, 2010 Megoldás? Bevezetés Lassú a rendszer! Óbudai Egyetem

42  Windisch Gergely, 2010 Megoldás: ún VMV* módszer *: (Vegyünk még vasat!) Bevezetés Lassú a rendszer! Óbudai Egyetem

43  Windisch Gergely, 2010 Bevezetés Óbudai Egyetem Komplex webalkalmazás architektúra

44  Windisch Gergely, 2010 Bevezetés A terheléstesztelés: •Funkcionálisan hibátlan alkalmazás nagyon gyakran az élesbe állítás után tönkremegy •Túl sok user kapcsolódott •Egyszerre csináltak dolgokat •Lassú, használhatatlan lesz a rendszer •Terhelés tesztelés segítségével meggyőződhetünk arról, hogy hogyan reagál az alkalmazás az egyidejű nagy számú kérésekre. Óbudai Egyetem

45  Windisch Gergely, 2010 Bevezetés Teljesítmény tesztelés osztályozása •A teljesítmény tesztelést kétféle csoprtra oszthatjuk annak megfelelően, hogy mi a célunk vele. •Terhelés tesztelés (Load testing) - ebben az esetben az elvárt terhelést szimulálják, és ezzel ellenőrzik, hogy a rendszer teljesíti-e a szerződésben vállalt feltételeket •Pl: SLA kimondja, hogy egy adott tranzakció esetén 400 felhasználónál a válaszidő 2 másodperc lehet, akkor lemérik 400 felhasználóval az adott tranzakciót •Stressz teszt - Stressz teszt esetében az alkalmazás teherbírására kíváncsiak - nem az a kérdés, hogy kibír-e adott számú usert, hanem hogy hány user kell a teljes tönkremenetelhez. Óbudai Egyetem

46  Windisch Gergely, 2010 Mit jelent a terheléstesztelés? •A több (sok) összetevőből álló hardver/szoftver rendszer viselkedésének vizsgálata valós vagy a valóshoz közeli terhelés alatt •A szűk keresztmetszetek feltárása •A hibák kiküszöbölése a rendszer üzembe helyezése előtt Miért kell automatizálni a terheléses tesztelést? •Csökkenteni kell az alkalmazások, frissítések és javítások üzembe helyezésének kockázatát •Ehhez valós működési terhelést kell alkalmazni a rendszeren, miközben mérjük a rendszer teljesítményét, és a felhasználók tapasztalatait •Mindezt úgy kell elvégezni, hogy a felhasználói beavatkozásokat gépi úton, ún. virtuális felhasználókkal helyettesítjük •A felhasználói viselkedés különböző kombinációit kell tesztelni •Hardver/szoftver változtatás esetén a tesztet könnyen meg lehessen ismételni Terheléstesztelés – Automatikus terheléstesztelés Óbudai Egyetem

47  Windisch Gergely, 2010 •A több (sok) összetevőből álló hardver/szoftver rendszer viselkedésének vizsgálata valós vagy a valóshoz közeli terhelés alatt •A szűk keresztmetszetek feltárása •A hibák kiküszöbölése a rendszer üzembe helyezése előtt •Ismételhetőség (észrvesszük a hibát, reprodukáljuk, ellenőrizzük a javítást) •Kevesebb erőforrásigény •Pontosság, időzíthetőség Automatikus terheléstesztelés Automatizált terheléstesztelés előnyei Óbudai Egyetem

48  Windisch Gergely, 2010 Egy jól felépített teljesítmény (terhelés) tesztnek az alábbi kérdésekre kell választ adnia: •Az alkalmazás válaszideje megfelelő-e? •Képes-e az alkalmazás az elvárt terhelés kiszolgálására? •Képes-e az alkalmazás az üzleti folyamatok által elvárt mennyiségű tranzakció kezelésére? •Stabil-e az alkalmazás elvárt, vagy rendkívüli terhelés esetén? •A felhasználók pozitív élményt szereznek-e a mindennapi használat során? Az automatikus teljesítményteszt üzleti terminológiák alapján számszerűsíti a változások hatásait Megkönnyíti az üzembe helyezéssel ill. a változtatásokkal kapcsolatos döntés meghozatalát Csökkenti a kiesett időt és javítja a rendelkezésre állást Automatikus terheléstesztelés Óbudai Egyetem

49  Windisch Gergely, 2010 Automatikus terheléstesztelés Óbudai Egyetem Az alábbi ábra mutatja, ahogy egy alkalmazás válaszideje nagyon megnő 6000 felhasználó egyidejű kiszolgálása esetén.

50  Windisch Gergely, 2010 A LoadRunner összetevői: •Virtual User Generator: rögzíti a felhasználók kezelői beavatkozásait és automatikusan végrehajtható teljesítménytesztelő szkriptet készít (Virtual user script) •Controller: szervezi, ütemezi, irányítja, és megfigyeli a tesztelést •Load Generators: a virtuális felhasználók futtatásával létrehozzák a terhelést •Analysis: lehetővé teszi az eredmények megtekintését, elemzését és összehasonlítását •Launcher: biztosítja a LoadRunner összetevőinek elérést egyetlen helyről LoadRunner – HP-Mercury megoldás Óbudai Egyetem

51  Windisch Gergely, 2010 A LoadRunner (LR) kulcs terminológiái: •Scenario: Meghatározza azokat az eseményeket, amelyeket a tesztelés során végre kell hajtani (fájlban tárolva) •Vuser: A scenario-ban a LR a természetes személyeket virtuális felhasználókkal helyettesíti. A Vuser-ek emulálják a személyek kezelői beavatkozásait az alkalmazás használata során. A scenario akár több ezer felhasználót is tartalmazhat •Vuser script: A scenario végrehajtása során a Vuser által kiváltott beavatkozások egy Vuser script-ben vannak leírva •Transaction: A szerver teljesítményének méréséhez tranzakciókat kell definiálni. Egy tranzakció az egy egységként kezelt és mért üzleti folyamatok sorozatát tartalmazza LoadRunner – HP-Mercury megoldás Óbudai Egyetem

52  Windisch Gergely, 2010 A terhelés tesztelés lépései: •Tervezés: követelmények meghatározása (felhasználók száma, tipikus üzleti folyamatok, válaszidők) •Szkript-készítés: felhasználói műveletek elfogása •Forgatókönyv (Scenario) definiálása: a tesztkörnyezet felépítése az LR Controller segítségével •Forgatókönyv végrehajtása: a teszt végrehajtása az LR Controller segítségével •Eredményanalízis: grafikonok, jelentések készítése az LR Analysis segítségével, az eredmények értékelése LR – A terheléstesztelés folyamata Óbudai Egyetem


Letölteni ppt " Windisch Gergely, 2010 Windisch Gergely 2014. ITIL – SDLC - Terheléstesztelés Óbudai Egyetem."

Hasonló előadás


Google Hirdetések