Előadást letölteni
Az előadás letöltése folymat van. Kérjük, várjon
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
Hasonló előadás
© 2024 SlidePlayer.hu Inc.
All rights reserved.