Windisch Gergely 2014.

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

2. 1 Bevezetés

3. SDLC – Software DevelopmentLifeCycle • A szoftverfejlesztési életciklus részei • Project tervezéséskivitelezhető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

4. ITIL projekt életciklus http://www.technologyuk.net/computing/project_management/project_lifecycle.shtml

5. Application life cycle http://www.ibm.com/developerworks/tivoli/library/t-appmgtlife/index.html

6. ITIL vs. SDLC http://www.itsmsolutions.com/newsletters/DITYvol4iss23.htm Az ITIL leírás nem lecseréli az SDLC-t, hanem magába foglalja azt

7. Szoftver tesztelés életciklus http://www.buzzle.com/articles/software-testing-life-cycle.html

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

9. 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"

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.

11. Bevezető A szoftver tesztelés az a folyamat, amikor a hibák feltárása céljából futtatjuk az alkalmazást.

12. Bevezető • Szoftvertesztelés két fő csoportra osztható • Funkcionálistesztelés • Győződjünk meg, hogyazalkalmazásunkhibamentes-e • adottinputraadott output, • helyesszámítások, • specifikációkbanelőírtaknakmegfelel • az újonann implementált / javított elemek milyen új hibát okoznak • Terheléstesztelés • Milyenhibákjönnekelő a funkcionálisanhibátlanszoftverennagyterhelésalatt • 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.

13. 2. Funkcionális tesztelés

14. Funkcionális tesztelés *: http://www.fastcompany.com/magazine/06/writestuff.html?page=0%2C0 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.

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

16. Bemelegítő feladat tippek 15 különböző eset

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

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

19. 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.

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

21. Hibák bevezetése / fellelése Forrás: [1]

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 sikeresmunkavégzésben

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

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

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

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

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.

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?

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

30. Szoftvertesztelés fejlődése Forrás: [1]

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

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.

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.

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ösfelületet ad a teljestesztelésiprojectnek, a specifikációtólkezdve a hibakövetésig • Kiváltja a korábbimegoldásokat (Word, Excel)‏ • HP Quick Test Professional • Automatizáltteszteléstteszlehetővé • Újkiadásokrégifunkcióinaktesztelésérealkalmas

35. 2.2 Funkcionális tesztelés - HP Quality Center

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]

37. 3 Terhelés tesztelés

38. 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

39. 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

40. Bevezetés Lassú a rendszer!

41. Bevezetés Lassú a rendszer! Megoldás?

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

43. Bevezetés Komplex webalkalmazás architektúra

44. 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.

45. 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.

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

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

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

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.

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