ITIL – SDLC - Terheléstesztelés

Az előadások a következő témára: "ITIL – SDLC - Terheléstesztelés"— Előadás másolata:

1 ITIL – SDLC - Terheléstesztelés
Windisch Gergely 2014. Óbudai Egyetem

2 1 Bevezetés Óbudai Egyetem

3 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 ITIL projekt életciklus
Óbudai Egyetem

5 Application life cycle
Óbudai Egyetem

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

7 Szoftver tesztelés életciklus
Óbudai Egyetem

8 Mi a célja szoftver tesztelésnek? Próbáljuk definiálni a fogalmat
Bevezető Mi a célja szoftver tesztelésnek? Próbáljuk definiálni a fogalmat Óbudai Egyetem

9 "A az a folyamat, amikor megmutatjuk, hogy nincsenek hibák"
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 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 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 Bevezető 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. 12

13 2. Funkcionális tesztelés
Óbudai Egyetem

14 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 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 Bemelegítő feladat tippek
15 különböző eset Óbudai Egyetem

17 Miért drága a szoftver fejlesztés?
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 Óbudai Egyetem

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

19 Sikeres, ha minden működött és időben készen volt az alkalmazás
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 Mi okozta a sikert? Sikeres projectek sikerességének okai:
Kellő támogatottság (18%)‏ Megrendelővel való kapcsolattartás (16%)‏ .. Óbudai Egyetem

21 Hibák bevezetése / fellelése
Forrás: [1] Óbudai Egyetem

22 Hibák bevezetése / fellelése
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 Óbudai Egyetem

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

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

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

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

27 Hogyan ne vezessük a projectünket (5)‏
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. Óbudai Egyetem

28 Hogyan ne vezessük a projectünket (6)‏
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? Óbudai Egyetem

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

30 Szoftvertesztelés fejlődése
Forrás: [1] Óbudai Egyetem

31 Üzleti folyamat alapú tesztelés
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 Óbudai Egyetem

32 Tesztelési technikák 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. Óbudai Egyetem

33 Különböző tesztelési fázisok
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. Óbudai Egyetem

34 Tesztelést segítő alkalmazások
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 Óbudai Egyetem

35 2.2 Funkcionális tesztelés - HP Quality Center
Óbudai Egyetem

36 HP Quality Center Minőség biztosítás lépései
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. Forrás: [2] Óbudai Egyetem

37 3 Terhelés tesztelés Óbudai Egyetem

38 A munka hatékonysága és a termelékenység jelentősen növekedett
Bevezetés 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 Óbudai Egyetem

39 A gyorsan változó üzleti követelményekhez állandóan alkalmazkodni kell
Bevezetés 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 Óbudai Egyetem

40 Bevezetés Lassú a rendszer! Óbudai Egyetem

41 Bevezetés Lassú a rendszer! Megoldás? Óbudai Egyetem

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

43 Bevezetés Komplex webalkalmazás architektúra Óbudai Egyetem

44 Túl sok user kapcsolódott Egyszerre csináltak dolgokat
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 Teljesítmény tesztelés osztályozása
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 Terheléstesztelés – Automatikus terheléstesztelés
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 Óbudai Egyetem

47 Automatikus terheléstesztelés
Automatizált terheléstesztelés előnyei 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 Óbudai Egyetem

48 Automatikus terheléstesztelés
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 Óbudai Egyetem

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

50 LoadRunner – HP-Mercury megoldás
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 Óbudai Egyetem

51 LoadRunner – HP-Mercury megoldás
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 Óbudai Egyetem

52 LR – A terheléstesztelés folyamata
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 Óbudai Egyetem