Statikus technikák és Műszaki teszttervezési technikák

Átírás

1 Statikus technikák és Műszaki teszttervezési technikák Bevezetés a tananyagba Tesztelési Technikák 3 Statikus technikák 4 Műszaki teszttervezési technikák (Dinamikus tesztelés) 1

2 Tesztelési technikák Tesztelési Technika alatt egy tervet értünk, amely egy módszert ad a teszteléshez. Lényegében két tervezési technikát különböztetünk meg: Statikus technikák (Static Techniques) Műszaki teszttervezési technikák (Dinamikus technikák, Dynamic Techniques) Tesztelés bemutatása 2

3 3.1 A statikus technikák és a tesztelési folyamat A dinamikus teszttel ellentétben melyhez a szoftver futtatása szükséges a kód- vagy a projekt dokumentációk manuális vizsgálata Jóval a dinamikus tesztek futtatása előtt végrehajtható (hibák javítása gazdaságosabb) Eszközök használata is lehetséges Magába foglalja a Felülvizsgálatokat Statikus elemzés: a szoftverelemek elemzése azok futtatása nélkül (Static analysis) 3.1 A statikus technikák és a tesztelési folyamat Tesztelés céljának eléréséhez két megközelítés alkalmazható: statikus tesztelés, dinamikus tesztelés. Dinamikus tesztelés jellemzői: lefuttatjuk a szoftvert, majd a kapott kimeneti értéket elemezzük Manuálisan vagy adott eszközzel történik Programhibák kimutatására, kód minőségi jellemzőinek maghatározására alkalmas Ugyanakkor több szoftvertermék elemzésére nem alkalmas (pl. dokumentációk) 3

4 3.1 A statikus technikák és a tesztelési folyamat Statikus és dinamikus technikák egymást jól kiegészítik Különböző típusú hibák megtalálása Statikus technika: szabványoktól való eltérés, hiányzó követelmények, műszaki tervezés hibái, karbantarthatatlan kódspecifikációk, inkonzisztensspecifikációk 3.1 A statikus technikák és a tesztelési folyamat Gyakran ismeretterjesztő, kommunikációs céljai is vannak Résztvevők megismerik a szoftvertermék tartalmát és megértik saját szerepüket Előre tudnak tervezni a fejlesztés következő szakaszára Például a felülvizsgálatok gyakran a projekt mérföldkövei A talált hibák segítik meghatározni a tesztelés célját Egyes esetekben a felhasználók is részt vesznek, így az ügyféllel folytatott kommunikáció eszköze is lehet 4

5 3.1 A statikus technikák és a tesztelési folyamat A felülvizsgálatokkal javulás érhető el a termelékenység és termék minősége között (Gilb és Graham, 1993, van Veenendaal 1999) Programhibák korai fázisban történő csökkenése a tesztelésre és karbantartásra fordított csökkenését eredményezi Statikus tesztelés egyéb előnyei: lehetővé teszi a termék korai validációját 3.1 A statikus technikák és a tesztelési folyamat Statikus tesztelés egyéb előnyei: Lehetővé teszi a termék korai validációját (nem csak késői szakaszban átvételi teszttel) Átdolgozás költségei alacsonyak Fejlesztés termelékenységi mutatói javulnak Közös információcsere Minőségi kérdések szerepének hangsúlya 5

6 3.1 A statikus technikák és a tesztelési folyamat * Altom Consulting's home page that shows the relationship between when a bug is found and the cost of resolving the problem. Their tagline for the company that relates to this graphic: "We believe in testing as early as possible to minimize the impact and cost of fixing defects." 3.2 A felülvizsgálat folyamata 6

7 3.2 A felülvizsgálat folyamata 1 Informális felülvizsgálat Átvizsgálás Technikai felülvizsgálat Inspekció 3.2 A felülvizsgálat folyamata A felülvizsgálatok típusai a nagyon informálistól a nagyon formálisig terjednek. Formalitás mértéke függ az alábbiaktól: fejlesztési folyamat érettsége, jogi és egyéb szabályozó tényezők, auditkövetés szükségessége 7

8 3.2 A felülvizsgálat folyamata A felülvizsgálatok típusai a nagyon informálistól a nagyon formálisig terjednek. Informális felülvizsgálat Két személy a csoportból is végezhet informális felülvizsgálatot Nem dokumentált Informális felülvizsgálat a legelterjedtebb Dokumentáció, kód életciklusában többször is alkalmazható Programhibákat keresnek, felülvizsgálati megbeszélés keretében megvitatnak 3.2 Formális felülvizsgálat fázisai Formális felülvizsgálatok egy merev folyamatot követnek Hat fő lépésből áll: 1 Tervezés 2 Kezdő lépések 3 Egyéni felkészülés 4 Felülvizsgálati megbeszélés 5 Átdolgozás 6 Ellenőrzés 8

9 3.2 A felülvizsgálat folyamata Tervezés Felülvizsgálati kérelemmel kezdődik (szerző a moderátornak) Moderátor kijelölése a felülvizsgálat ütemezése céljából (dátum, időpontok, helyszínek, meghívók) Számolni kell a felülvizsgálatokban való aktív részvételhez szükséges időre Inspekciónál a moderátor ellenőrzi e belépési feltételeket és meghatározza a kilépési feltételeket Ne pazaroljuk a felülvizsgálók idejét olyan dokumentumra, amely nem áll készen inspekcióra (Túl sok hiba) 3.2 A felülvizsgálat folyamata Minimum belépési feltételek: A moderátor nem talál nagy számú hibát pl. 30 percnyi ellenőrzés után 3 jelentékeny hiba egy oldalon A felülvizsgálandó dokumentum sorai számozottak Előzőleg automatizált ellenőrző teszt Hivatkozások stabilak és hozzáférhetőek Szerző csatlakozik felülvizsgálati csoporthoz és magabiztos a dokumentum minőségében 9

10 3.2 A felülvizsgálat folyamata Belépési feltételek teljesülése után, szerző és moderátor dönt arról, hogy a dokumentáció mely részével kezdődik a felülvizsgálat Maximális oldalszám függ a felülvizsgálat céljától, típusától, a dokumentáció típusától, szervezeten belüli tapasztalatoktól Maximális méret oldal, de formális felülvizsgálatnál 1-2 oldal 3.2 A felülvizsgálat folyamata Ezután felülvizsgáló csapat kiválasztása Csapat mérete: 4-6 résztvevő (szerzővel és moderátorral) Minden résztvevő más-más feladatot kap, így a résztvevők más-más hibatípusra összpontosítanak Így a felülvizsgálók nem találják meg ugyanazokat a hibákat Feladatok kiosztása a moderátor feladata 10

11 3.2 A felülvizsgálat folyamata Példa a feladatok kiosztására: 3.2 A felülvizsgálat folyamata Magasabb szintű dokumentációra való összpontosítás például a műszaki tesztterv megfelel e a követelményeknek Szabványokra összpontosítás - például belső konzisztencia, egyértelműség, egyezményes elnevezések, sablonok Azonos szintű kapcsolódó dokumentumok szoftverfunkciók közötti kölcsönhatások Használatra történő összpontosítás - tesztelhetőség és karbantarthatóság 11

12 3.2 A felülvizsgálat folyamata A moderátornak lehetősége van arra, hogy a feladatkörök egyikét is betöltse Így jobban rálát a részletekre Hatékonyabban vezeti a megbeszéléseket Felülvizsgálat így hatékonyabb Javasolt, hogy a moderátor a szabványoknak való megfelelősséget ellenőrizze, objektívebb feladatkör 3.2 A felülvizsgálat folyamata Kezdő lépések: Felülvizsgálat opcionális eleme a kezdeti megbeszélés Cél: közös hang megtalálása, munka iránti elkötelezettség növelése Kezdeti lépések megbeszélése motiváló lehet és hat az eredményességre - 70%-al jelentékenyebb hibatalálatok (van Veenendaal és van der Zwan, 2000) Megbeszélhetik a kezdeti ellenőrző vizsgálat eredményét és a belépési/kilépési kritériumokat 12

13 3.2 A felülvizsgálat folyamata Kezdő lépések: Kezdeti megbeszélés során a célok és dokumentáció bemutatása Nagyszámú dokumentumok esetén a dokumentumok közötti kapcsolat bemutatása Feladatkörök, ellenőrzési arány, vizsgálandó oldalak, folyamatváltozások, egyéb kérdések meghatározása Dokumentumok szétosztása 3.2 A felülvizsgálat folyamata Egyéni felkészülés: Résztvevők egyénileg dolgoznak a felülvizsgálandó dokumentumon A résztvevők hibákat azonosítanak Minden eredményt rögzítenek, lehetőleg naplózási űrlapok használatával (Gépelési hibákat is rögzítik, de ezekről nem beszélnek a megbeszélés során) Ellenőrző listák használatával eredményesebb a felülvizsgálat (például a kódolási problémákat tartalmazó listák) 13

14 3.2 A felülvizsgálat folyamata Egyéni felkészülés: Fontos az óránként vizsgálandó oldalak száma, azaz az ellenőrzési sebesség Az ellenőrzési sebesség az alábbiaktól függ: dokumentum típusa, komplexitása, kapcsolódó dokumentumok száma, felülvizsgáló tapasztalatai Az ellenőrzési sebesség általában óránként 5-10 oldal, inspekció esetén lehet egy oldal is óránként Adatok gyűjtésével meghatározható az ellenőrzési sebesség mértéke 3.2 A felülvizsgálat folyamata Felülvizsgálati megbeszélés: Szakaszai: naplózási szakasz, tárgyalási szakasz, döntési szakasz Meghatározott kérdések (hibák) tárgyalása oldalanként Szerző vagy jegyzőkönyvvezető naplózza őket Inspekciónál hasznos az erre kijelölt személy Érdemi viták mellőzése, megvitatásra szoruló kérdéseket a tárgyalási szakaszban beszélik meg Minden hibát súlyosságának megfelelően naplózni kell 14

15 3.2 A felülvizsgálat folyamata Felülvizsgálati megbeszélés súlyossági szintek: Kritikus: A hibák tovaterjedő kárt okozhatnak. A hiba kiterjedése és hatóköre az inspekció alatt álló dokumentumon túlnyúlik Jelentékeny: A hibák tovaterjedő kárt okozhatnak (például hibás implementációhoz vezethet) Elhanyagolható: Nem valószínű, hogy a hibák további károkat okozhatnak (például szabványoktól való eltérés) Helyesírási hibák kezelése: Résztvevők feljegyzik ezeket a felülvizsgált dokumentumban, megbeszélés végén átadják a szerzőnek 3.2 A felülvizsgálat folyamata Felülvizsgálati megbeszélés: Hangsúlyos, hogy meghatározott időkereten belül a legtöbb hibát naplózzuk, ezért a moderátor e megfelelő naplózási sebesség betartására törekszik (percenkénti naplózott hibák) Jól működő naplózás sebessége: percenként 1-2 naplózott hiba 15

16 3.2 A felülvizsgálat folyamata Felülvizsgálati megbeszélés: Formálisabb felülvizsgálatnál megvitatandó kérdések a tárgyalási szakaszban kerülnek megbeszélésre Informális felülvizsgálatnál gyakran nincsen tárgyalási szakasz Moderátor foglalkozik a személyeket érintő kérdésekkel, az ő feladata, hogy a vita ne menjen át személyeskedésbe A felülvizsgálók a tárgyalási szakaszban távozhatnak, de maradhatnak is tanulási célból Moderátor feladata a tárgyalási szakasz ütemezése, elemeknek legyen eredménye vagy vegyék azokat fel a teendők közé 3.2 A felülvizsgálat folyamata Felülvizsgálati megbeszélés: Döntési szakasz: résztvevőknek döntést kell hozniuk a dokumentumról, néha a kilépési követelmények alapján a résztvevőknek Legfontosabb kilépési feltétel: egy oldalon talált kritikus vagy jelentékeny hibák átlagos száma (például 3 kritikus/jelentékeny hiba oldalanként) Ha a fenti számnál magasabb a hibák száma, a dokumentumot át kell dolgozni, majd újra felülvizsgálni Ha a dokumentum megfelel a kilépési feltételeknek, akkor a moderátor vagy néhány résztvevő még átvizsgálja, majd elhagyhatja a felülvizsgálati folyamatot 16

17 3.2 A felülvizsgálat folyamata Felülvizsgálati megbeszélés: Szoros határidő esetén, a moderátor arra kényszerülhet, hogy hibákat tartalmazó dokumentumot adjon ki Kilépési feltételek segítenek neki döntést hozni Létezik olyan kilépési feltétel, amely a felülvizsgálat alaposságát méri (például megfelelő ellenőrzési sebesség) 3.2 A felülvizsgálat folyamata Átdolgozás: A szerző a talált hibák alapján tökéletesíti a dokumentumot. Szerző kötelessége eldönteni, hogy egy adott hiba javításra kerül e, ugyanakkor ha egy hiba nem kerül javításra azt jelenteni kell Hibák módosítását úgy kell végezni, hogy a javított hibák könnyen beazonosíthatóak legyenek 17

18 3.2 A felülvizsgálat folyamata Ellenőrzés: Moderátor biztosítja, hogy megfelelő lépéseket tegyenek a hibák, folyamatfejlesztési javaslatok és változási kérelmek esetén Ugyanakkor nem feltétlenül a moderátor feladata minden hiba javításának ellenőrzése A javított dokumentum ellenőrzése az összes résztvevő segítségével történhet A moderátor többféle számadatot begyűjt a folyamat során (talált hibák száma, oldalanként talált hibák száma, idő, összes munka) Moderátor feladata, hogy az adatokat későbbi ellenőrzés során is fel lehessen használni 3.2 A felülvizsgálat folyamata Feladatok Felelősségi körök Résztvevőknek ismerniük kell a felülvizsgálati folyamatot Ideális esetben a résztvevők a munkájukban is előnyökhöz jutnak Inspekciónál vagy technikai felülvizsgálatnál megfelelő képzettség szükséges Résztvevők négy típusát különböztetjük meg: Moderátor, szerző, jegyzőkönyvvezető, felülvizsgáló Management is szerepet kap a felülvizsgálatok esetén 18

19 3.2 A felülvizsgálat folyamata A moderátor A moderátor vezeti a felülvizsgálati folyamatot Meghatározza a felülvizsgálat és megközelítés típusát Ellenőrzi a belépési feltételeket és az átdolgozást, ami hatással van a bementi és kimeneti minőségre Előjegyzi, ütemezi a megbeszéléseket Kiosztja a dokumentumokat Segíti a csapat többi tagját Vezeti a tárgyalásokat Felel az adatok tárolásáért 3.2 A felülvizsgálat folyamata A szerző Törekednie kell arra, hogy minél többet tanuljon Javítsa a dokumentum minőségét Fejlessze a képességeit (dokumentumírás) Zavaros részek tisztázása, talált hibák megértése 19

20 3.2 A felülvizsgálat folyamata A jegyzőkönyvvezető Naplózási megbeszélés alatt az említett hibák és folyamatfejlesztési javaslatok rögzítése Gyakorlatban ezt a szerző végzi Előnyökkel jár, ha nem a szerző a jegyzőkönyvvezető, szerzőnek több ideje van a dokumentumon gondolkodni 3.2 A felülvizsgálat folyamata A felülvizsgálók A felülvizsgálók (ellenőrzők, vizsgálók) feladata, hogy minden anyagot átvizsgáljanak Alaposság a felülvizsgálat típusától függ A domain ismeretek és a technikai szakértelem is a felülvizsgálattól függ Minél kevesebb kapcsolódó dokumentum létezik, annál nagyobb szakértelemre van szükség Fontos, hogy különböző nézőpontokat és szerepköröket képviseljenek Kiosztott dokumentációk lehetnek forrásdokumentumok, szabványok, ellenőrző listák is 20

21 3.2 A felülvizsgálat folyamata A menedzser Ő dönt a felülvizsgálatok végrehajtásáról Előkészíti az időbeosztásokat Megállapítja, hogy a célkitűzések teljesültek e Szükség esetén trainingről dönt Érintett lehet magában a felülvizsgálatban is a képzettségétől függően (felülvizsgáló) 3.2 A felülvizsgálat folyamata - Átvizsgálás Átvizsgálás Szerző határozza meg az átvizsgálás módját Ő vezeti át a résztvevőket a dokumentáción és saját gondolatmenetén azért hogy visszajelzést kapjon és egyetértés legyen a résztvevők között Hasznos, ha fejlesztésben nem jártas személyek is jelen vannak Előkészületeket főleg a szerző végzi Résztvevőknek nincs előírva, hogy olvassák át a dokumentumot A megbeszélésen több személy is részt vehet: több hallgatóság, több nézőpont, és oktatási célokat is szolgálhat Hallgatóság különböző ágazatokról biztosítja, hogy nem maradtak komolyabb hibák észrevétlenül 21

22 3.2 A felülvizsgálat folyamata - Átvizsgálás Átvizsgálás céljai: Dokumentum bemutatása a projektben résztvevőknek (nem informatikusoknak is) Dokumentum tartalmának elmagyarázása Általános összhang kialakítása Megoldási javaslatok Átvizsgálás jellemzői: Megbeszélést a szerző vezeti, gyakran külön jegyzőkönyvvezető Forgatókönyvek és fejben futtatások használata Opcionális: A felülvizsgálók felkészítése 3.2 A felülvizsgálat folyamata Technikai felülvizsgálat Dokumentum technikai tartalmával kapcsolatos konszenzus elérésére törekednek Hivatkozott dokumentumokra nem összpontosít Szakemberek a tartalomra összpontosítanak és így találnak hibákat Szakemberek: tervező, vezető műszaki tervező, kulcspozícióban lévő felhasználók Informálistól a nagyon formálisig terjedhet 22

23 3.2 A felülvizsgálat folyamata Inspekció Az inspekció a legformálisabb felülvizsgálati típus Dokumentációt a felülvizsgálat előtt alaposan ellenőrzik Az inspekció megbeszélésen naplózzák a talált hibákat, megvitatás a tárgyalási szakaszban Inspekciók végrehajtása Weinberg-féle koncepciója Weinberg az emberek önigazolási hajlamára hivatkozik Hajlamosak vagyunk arra, hogy a meggyőződésünknek ellentmondó információkat figyelmen kívül hagyjuk Emiatt vállalatoknál specializált tesztelési csoportok Az inspekciót többféle célt is szolgálhatnak, például a piacra kerülés gyorsasága a meghatározó, akkor a termelékenységen lesz a fő hangsúly 3.2 A felülvizsgálat folyamata A felülvizsgálat típusai Egy dokumentum több felülvizsgálat tárgya is lehet Többféle felülvizsgálati típus esetén az alkalmazási sorrend változhat: (Például először informális felülvizsgálat, majd technikai felülvizsgálat) Különböző típusok különböző célokat szolgálnak 23

24 3.2 A felülvizsgálat folyamata - Átvizsgálás Felülvizsgálat sikerességének tényezői: Hogyan kezdjünk neki egy sikeres felülvizsgálatnak? Találjunk egy profit! Olyan dolgokat válasszunk ki, amik tényleg számítanak! A felülvizsgálati tevékenységeket explicit módon tervezzük meg és kövessük nyomon! Képezzük a résztvevőket! Kezeljük a személyeket érintő kérdéseket! Kövessük a szabályokat, de törekedjünk az egyszerűségre! Folyamatosan tökéletesítsük a folyamatot és az eszközöket! Számoljunk be az eredményekről Álljunk neki! Felülvizsgálatok típusai 24

25 3.2.3 Felülvizsgálatok típusai Felülvizsgálatok típusai 25

26 3.3 Statikus elemzés eszközökkel A szoftverelemek (például követelmények vagy kód) elemzése azok futtatása nélkül. 3.2 A felülvizsgálat folyamata Statikus elemzés Eltérés a dinamikus elemzéstől: Követelményeken, műszaki terven, kódon hajtjuk végre a szoftver futtatása nélkül Formális felülvizsgálati típusok előtt hajtjuk végre Dinamikus tulajdonságokhoz nem kapcsolódik, például tesztlefedettséghez Célja: programhibák megtalálása (nem meghibásodások) Több eszköz is rendelkezésünkre áll, többsége a kódra összpontosít Statikus elemzési eszközöket leginkább fejlesztők használják Fordítóprogram is nevezhető statikus elemzési eszköznek, mivel szimbólumtáblát készít, rámutat a helytelen használatra 26

27 3.2 A felülvizsgálat folyamata Statikus elemzés Statikus elemzés használata a programozási nyelv jellemzőihez kapcsolódik Szabványosítási folyamat hiányosságai Minden programozási nyelvben vannak problémák Kódolási szabványok: Első teendő a kódolási szabvány meghatározása (osztályok elnevezése nagy C-vel kezdődjön, a behúzás 4 szóköz legyen) Sok munkát spórolhatunk vele Statikus kódelemzőt vásárolunk, felállítjuk az arra vonatkozó szabályokat Eszköz nélkül a kódolási szabvány betartása kudarcba fullad 3.2 A felülvizsgálat folyamata Statikus elemzés Kódmetrikák: Statikus elemzés során a kód jellemzőiből nyerünk információkat Ezeknek az adatoknak a kiszámítása hasznos a végrehajtott változások esetében is, hogy lássuk, hogy a kód, nem lesz e túl összetett Kiszűrhetjük a magas kockázatú területeket Ciklomatikus komplexitás: Bináris döntési utasításokat összeadjuk és ehhez hozzáadunk 1-et 27

28 3.2 A felülvizsgálat folyamata Statikus elemzés Ciklomatikus komplexitás formális számolása: 3.2 A felülvizsgálat folyamata Statikus elemzés 7 csomópont 8 élet látunk: 8-7+2=3 28

29 3.2 A felülvizsgálat folyamata Statikus elemzés Kódszerkezet: Érdemes több szempontot figyelembe venni: Vezérlési folyam szerkezetét (utasítások végrehajtási sorrendje, halott kódok azonosítása) Az adatfolyam szerkezetét (Adatelem útját követi nyomon) Az adatszerkezetet Tesztelés bemutatása 29

30 4.1 A teszt fejlesztési folyamata Nagyon informális módtól a nagyon formálisig terjedhet Formalitás jellegét befolyásolja (a tesztelés és a fejlesztési folyamat érettsége, az időbeli megkötések és a résztvevő személyek, költségek) Tesztelemzés: Tesztbázis dokumentáció (Test basis) elemzése Nyomonkövethetőség (tesztelési helyzetektől vissza a specifikációkig és követelményekig) A teszt műszaki tervezése során a tesztesetek és tesztadatok megalkotása és meghatározása történik. 4.1 A teszt fejlesztési folyamata Teszteset részei: - Bemeneti értékek halmaza - végrehajtási előfeltételek - elvárt eredmények és végrehajtás utáni feltételek IEEE (Institute of Electrical and Electronics Engeeners) 829 dokumantáció szabvány Teszteset specifikációjának - az elvárt eredményeket lehetőleg a teszt végrehajtása előtt meg kell határozni A teszt megvalósítása alatt a tesztesetek kifejlesztése, megvalósítása, priorizálása és teszteljárás specifikációba (Test Procedure Specification) rendezése történik (IEEE STD ) 30

31 4.1 A teszt fejlesztési folyamata 4.1 A teszt fejlesztési folyamata 31

32 4.1 A teszt fejlesztési folyamata 4.2 Műszaki teszttervezési technikák kategóriái Tesztelés előtt tudnunk kell, mit akarunk tesztelni Ismernünk kell a bemeneteket, a bemenetek alapján várható eredményeket 3 dolgot vizsgálunk: tesztelési feltételeket, teszteseteket, tesztelési eljárásokat külön dokumentumban (IEEE 829) Tesztelési feltételek a műszaki tesztterv specifikáció dokumentumban találhatóak A tesztesteket a teszteset-specifikáció tartalmazza Tesztelési eljárásokat a teszteljárás-specifikációban találhatjuk 32

33 4.2 Műszaki teszttervezési technikák kategóriái Tesztdokumentáció formalitása Tesztdokumentáció formalitása: Nagyon formális teszteléshez, ellenőrzött dokumentáció tartozik (konkrét inputokat és a tesztelés várható eredményeit tartalmazza) Nagyon informális teszteléshez nem tartozik dokumentáció (egyes tesztelőknek vannak jegyzeteik) elvárható, hogy a tesztelők fejben tudják, mit szeretnének tesztelni Formalitás mértéke a felhasználás körülményeitől függ (biztonságkritikus szoftverek) Formalitás mértékét az adott szervezet is befolyásolja (fejlesztési folyamat érettsége, fejlesztési folyamat érettsége) 4.2 Műszaki teszttervezési technikák kategóriái - Tesztelemzés Olyasmit keresünk, amiből információt nyerhetünk a tesztelésről (Tesztbázis) Tesztbázis vizsgálata segít megállapítani a tesztelési feltételeket Hetzel szerint jó megértést biztosít, ha a tesztesetek illeszkednek a követelményekhez Különböző elnevezések léteznek arra, amit tesztelni kell: Merick tesztelési feltétel; Hutcheson tesztelési célok; Craig tesztelési célok ISTQB tesztelési feltétel 33

34 4.2 Műszaki teszttervezési technikák kategóriái - Tesztelemzés Tesztelési lehetőség: lehető legtöbb tesztelési feltétel beazonosítása, majd kiválogatjuk, hogy melyekkel dolgozzunk részletesen Mivel a kimerítő tesztelés lehetetlen ezért ki kell választanunk a tesztjeinket Úgy válasszunk, hogy lehető legtöbb programhibát felfedezzük Szelektálást segítik a műszaki teszttervezési technikák Alapozhatjuk a szelektálást az alábbiakra: kockázat, rendszer modellje, valószínű meghibásodások, szakértői tanácsok, heurisztika 4.2 Műszaki teszttervezési technikák kategóriái - Tesztelemzés Nyomonkövethetőség: tesztelési feltételek visszavezethetőek a tesztbázis forrásaihoz Horizontális és vertikális Miért fontos: Funkcióhoz tartozó követelmény megváltozik, mely tesztekkel vizsgáljuk ezt? Problémák egy adott funkcióhoz kapcsolódóan. Mely funkciókat vizsgálják a tesztesetek? Minden követelményt leteszteltünk, ami a követelményspecifikációban van? 34

35 4.2 Műszaki teszttervezési technikák kategóriái - Tesztelemzés Ezután prioritási sorrend kialakítása, azaz azonosítjuk a legfontosabbakat Bizonyos tesztfeltételek kidobása Ne feledjük, hogy ez többletidő Tesztadatok, tesztbemenetek és tesztelési eredmények meghatározása fontos, hogy a legfontosabb adattípusokat reprezentálják Műszaki tesztterv specifikációban a tesztelési feltételek (IEEE 829) 4.2 Műszaki teszttervezési technikák kategóriái - Tesztelemzés 35

36 4.2 Műszaki teszttervezési technikák kategóriái Tesztesetek meghatározása Pontos bemenetekre van szükség, egy teszteset gyakran több tesztelési feltételt lefed Ugyanakkor tudtunk kell, hogy a rendszernek mit kell csinálnia a bemenetekkel Sikeres vagy megbukott a teszteset Teszteset dokumentáció Tapasztalt tesztelő vagy tapasztalatlan a rendszerrel kapcsolatban IEEE 829 szabvány tesztestekre Teszteset: Copelend szerint összehasonlítás mi van Mi kellene, hogy legyen Boris Biezer kontár tesztelés 4.2 Műszaki teszttervezési technikák kategóriái Tesztesetek meghatározása Teszt Orákulum Információ a rendszer működéséről, ahhoz, hogy tudjuk, mit kellene tennie a rendszernek Követelményspecifikációk Tehát, amint bemeneti értéket választunk, meg kell határoznunk kimeneti értéket, ezt dokumentálnunk kell Kimeneti értékre példa: Információ a képernyőn, állapotváltozás, egyéb következmény E nélkül nem vesszük észre a számítási hibákat, megfelelőnek tűnő eredményeket Várt eredmények megfogalmazása a teszt lefuttatása előtt Néha csak ésszerűségi vizsgálat - ha részleges orákulummal rendelkezünk 36

37 4.2 Műszaki teszttervezési technikák kategóriái Tesztesetek meghatározása 4.2 Műszaki teszttervezési technikák kategóriái Tesztesetek meghatározása Fontos tudunk a teszteset célját illetve a vizsgálandó tesztelési feltételeket Priorizálás után, a tesztelést a magas prioritással kezdjük Kapcsolódhat tesztelési feltételek priorizálásához Ugyanakkor prioritást befolyásolhatja például speciális bemeneti érték Fontos a pontosság 37

38 4.2 Műszaki teszttervezési technikák kategóriái A tesztelési eljárás Tesztesetek csoportosítása Teszt futtatásához szükséges lépések sorrendje A végrehajtandó lépéseket tesztelési eljárásnak vagy tesztszkriptnek, manuális scriptek nevezzük Teszteljárás átalakítása tesztvégrehajtási ütemtervvé Melyik lépést, mikor-kinek kell végrehajtania 4.2 Műszaki teszttervezési technikák kategóriái Hagyományos megkülönböztetése a feketedoboz és a fehérdoboz megnevezés Feketedoboz tesztelés: tesztbázis dokumentáció (Segítségével tesztelési feltételek, tesztesetek vagy tesztadatok nyerhetők.) Funkcionális vagy nemfunkctionális teszt A feketedoboz technika nem használ semmilyen, a tesztelendő komponens vagy rendszer belső felépítésére vonatkozó információt. 38

39 4.2 Műszaki teszttervezési technikák kategóriái A fehérdoboz technikák (nevezik őket még strukturális vagy struktúra alapú technikáknak) a komponens vagy rendszer struktúrájának elemzésén alapulnak. Alapulhatnak a tesztelők, illetve a felhasználók tapasztalatain 4.2 Műszaki teszttervezési technikák kategóriái A specifikáció alapú technikák közös jellemzői: Formális vagy informális modellek (minta) alkalmazása. Ezekből a modellekből módszeresen tesztesetek nyerhetők A struktúra alapú technikák közös jellemzői: A szoftver felépítésével kapcsolatos információk használatával történik a tesztesetek származtatása (kód és részletes műszaki tesztterv alapján) A szoftver lefedettségének mértékét a meglévő teszteseteken lehet mérni 39

40 4.2 Műszaki teszttervezési technikák kategóriái A tapasztalat alapú technikák közös jellemzői: Az emberek tudása és tapasztalata szolgál a tesztesetek létrehozásának alapjául A tesztelők, fejlesztők, felhasználók és más projektrésztvevők ismerete a szoftverről, annak használatáról és környezetéről is információként szolgál A valószínűsíthető hibákkal és azok eloszlásával kapcsolatos ismeretetek szintén információként szolgálnak 4.3 Specifikáció alapú, vagy feketedoboz technikák 5 feketedoboz technikát különböztetünk meg: Ekvivalencia partícionálás Határérték elemzés Döntési tábla teszt Állapotátmenet teszt Használati eset teszt 40

41 4.3.1 Ekvivalencia particionálás A szoftver, vagy a rendszer bemeneteit olyan csoportokra kell osztani, melyek valószínűleg hasonlóan fognak viselkedni, így bizonyára ugyanúgy kerülnek feldolgozásra. Ekvivalencia partíciók (vagy osztályok) léteznek az érvényes pl. elfogadandó - adatokra és az érvénytelen elutasítandó adatokra, defensive testing Idővel kapcsolatos értékekre is használható Tesztelés minden szintjén alkalmazható Hiba alapja: Ekvivalencia partíció rosszul van kezelve Ekvivalencia particionálás Tesztelési feltételek egy halmazát azonos csoportokra osztjuk Rendszer ezeket ekvivalensen kezeli Ekvivalenciapartíció ekvivalenciaosztály Minden osztályból elég egy elemet tesztelnünk ugyanakkor ha van időnk, több elemet is letesztelhetünk 41

42 4.3.1 Ekvivalencia particionálás Példa (Bemenet - Input partíció): Ha egy program az alábbi egész értékeket fogadja el és Érvényes pozitív partíció (0 < x < ) - Érvényes negatív partíció ( < x < 0) - (x=0) - Érvénytelen pozitív partíció (x > ) - Érvénytelen negatív partíció (x < ) - Nem egész számok (pl. 2,82) - Érvénytelen karakterek (pl. p ) Ekvivalencia particionálás Példa (Kimenet - Output partíció): Egy bank bankszámlája az alábbi kamatokat ajánlja: - 0,5 % kamat $ 1000-ig - 1% kamat $ 1000,01 - $ ,5% kamat az ezen felüli összegekre Az alábbi tesztesetek írhatóak a fent leírt feladatra: - Bemeneti adat $ 0,01 - $ 1000 Kimeneti adat : 0,5 % kamat - Bemeneti adat $ 1000,01 - $ 2000 Kimeneti adat : 1 % kamat - Bemeneti adat $ 2000,01 Kimeneti adat : 1,5 % kamat 42

43 4.3.1 Ekvivalencia particionálás Példa: Egy virágmagokat forgalmazó cég $ 3,5 postázási költséget számít fel $ 20 vagy annál alacsonyabb értékű rendelés esetén. A cég $ 40 vagy annál alacsonyabb összegű rendelés esetén $ 3,95 postázási költséget számít fel. $ 40 felett a cég nem számít fel postázási költségeket Ekvivalencia particionálás Példa: Egy virágmagokat forgalmazó cég $ 3,5 postázási költséget számít fel $ 20 vagy annál alacsonyabb értékű rendelés esetén. A cég $ 40 vagy annál nagyobb összegű rendelés esetén $ 3,95 postázási költséget számít fel. $ 40 felett a cég nem számít fel postázási költségeket. Megoldás: - Az érvényes partíciók a következőek: $ 0 - $ 20; $ 3,5 $ 20,01- $ 40; ---- $ 3,95 és >= $ 40, $ 0 - Az érvénytelen partíciók a következőek: negatív számok, alfabetikus és speciális karakterek 43

44 4.3.1 Ekvivalencia particionálás Ekvivalencia particionálás Példa: Egy kereskedelmi Weboldalon 2 radio button van Buy or Sell Ha van egy szabadszöveges mező is, az alábbi kombinációk léteznek: Buy - Sell érvényes inputok Trade érvénytelen inputok Buy, buy, BUY Követelményektől függ 44

45 4.3.1 Ekvivalencia particionálás Példa: Banki hitelek forgalmazó bank weboldalán az alábbi feltételeket látjuk: - Személyi kölcsön - Lakáshitel - Jelzálog Van bankszámlája a banknál? Van takarékossági számlája a banknál? Ekvivalencia particionálás 45

46 4.3.2 Ekvivalencia particionálás 1. partíció 2. partíció Ekvivalencia particionálás 3. partíció 46

47 4.3.2 Ekvivalencia particionálás Tesztesetek Határérték-elemzés Ezt a technikát sokszor az ekvivalencia partícionálás kiterjesztésének tekintik. Boundary value analysis (BVA) Egy partíció maximális és minimális értékei a határértékek Az érvényes partíciók határértéke érvényes határérték Az érvénytelen partíciók határa az érvénytelen határérték Hibatalálási képessége magas Minden szinten használható Osztályok közötti határok tesztelése 47

48 4.3.2 Határérték-elemzés Példa: Egy nyomtató 1-99 oldalt képes nyomtatni. Határértékek: 0,1, 2 98, 99, 100 Példa: Egy vizsga elégségesnek tekinthető, ha a hallgató eléri a 40%-ot, jónak tekinthető, ha eléri a 60%-ot és kiválónak tekinthető, ha eléri a 80%-ot Határértékek: Az alábbi határértékeket különböztetjük meg: 39, 40, 41 elégséges; 59, 60, 61- jó; 79, 80, 81 - kiváló Határérték-elemzés Példa: Egy pénzintézet az alábbi két információt kéri a weboldalán: - Kölcsön összege - Tulajdon értéke - A két mező dollárokat fogad el, 100-as értékekben - Minimum kölcsön: Maximum kölcsön: Tulajdon minimum értéke: Tulajdon maximum értéke:

49 4.3.2 Határérték-elemzés Határérték-elemzés 49

50 4.3.2 Határérték-elemzés Az ekvivalnciaosztályozás és határérték-elemzés kiterjesztése Például repülőjegyet rendelünk: Turista, prémium turista, business, első osztályú (ekvivalncia osztályok) Nincs értelme határokról beszélni Érvénytelen osztály (például személyzet) Alapkonfiguráció: rendszeradminisztrátori, menedzseri, ügyfélszintű 50

51 4.3.2 Az ekvivalnciaosztályozás és határérték-elemzés kiterjesztése Példa: Cég belső telefonhálózata 200 telefon 3 jegyű mellékek ig Számjegyek (0-9) érvénytelen osztályokkal Számjegyek száma 3 (2 és 4 érvénytelen határértékek) Telefonmellék kiterjesztése ( érvénytelen határértékek) Használt és használaton kívüli mellékek (két érvényes osztály, határok nélkül) Legtöbbet és legkevesebbet használt mellék, mint határérték Az ekvivalnciaosztályozás és határérték-elemzés kiterjesztése Egyetlen tesztesettel többet is letesztelhetünk Például 409 számjegyek, számjegyek száma, érvényes tartomány, számjegyek határértékei Hány teszteset szükséges? 2-4 számjegyű értékek 99,100, 699, 700 Használatok kívüli mellékek Legalacsonyabb és legmagasabb használatban lévő mellékek száma Összesen tehát teszteset 51

52 4.3.2 Az ekvivalnciaosztályozás és határérték-elemzés kiterjesztése Egyetlen tesztesettel többet is letesztelhetünk Például 409 számjegyek, számjegyek száma, érvényes tartomány, számjegyek határértékei Hány teszteset szükséges? 2-4 számjegyű értékek 99,100, 699, 700 Használatok kívüli mellékek Legalacsonyabb és legmagasabb használatban lévő mellékek száma Összesen tehát teszteset Az ekvivalnciaosztályozás és határérték-elemzés kiterjesztése Banki kamatláb Egy ügyfélnek több, mint egy számlája van, 1 % kamatprémium ha legalább $1000 az egyenlege Kimeneti értékek 7%-8% kamat 52

53 4.3.3 Az ekvivalnciaosztályozás és határérték-elemzés kiterjesztése Bemenetet egy felhasználó gépel Bemeneti adat más rendszerekből is jöhet Hasznos komponens tesztelésnél Határérték-elemzés egy karakterlánc egészéhez (név, cím) 1-30 között érvényes osztály 30 fölött érvénytelen karakterosztály érvénytelen karakterek: 0 és 31 Hibaüzenetek Néha rejtett határral dolgozunk Teszteljünk le mindent, aminek értelmét látunk Tesztesetek műszaki tervezése Tesztesetek műszaki tervezése következik a tesztfeltételek meghatározása után Egy tesztesetben minél több tesztelési feltételt tudunk lefedni annál kevesebb tesztelés Hiba miatt elbukott teszt újra kell tesztelnünk egészséges arány 53

54 4.3.3 Tesztesetek műszaki tervezése Példa: Bankszámla példa 1 új ügyfél $500 egyenleggel Lefedés: $100,01-$999,99 5%-os kamatlábérték Érvényes ügyfél Új ügyfél Egyetlen számlával rendelkező ügyfél Érvénytelen osztályok tesztelése tesztesettel 1 érvénytelen osztály lefedése segít abban például, hogy helyes hibaüzeneteket kapunk e Kivéve, ha több hibaüzenettel dolgozunk Tesztesetek műszaki tervezése Határok teszteseteinek lefedettsége: összes érvényes alsó határérték egy tesztesetbe összes érvényes felső határérték egy tesztesetbe Érvénytelen határok letesztelése együtt, ha validációt minden egyes mezőre végzünk (máskülönben külön tesztesetbe érvényes tenni) 54

55 4.3.3 Miért végezzünk ekvivalenciaosztályozást és határérték-elemzést is? Technikai értelemben határértékelemzéssel ekvivalenciaosztályokat is leteszteljük De ha egy érték megbukik, akkor a határérték vagy az ekvivalciaosztály bukott e meg? Nagyobb bizalom a felhasználó számára Határokat bonyolultabb felállítani Miért végezzünk ekvivalenciaosztályozást és határérték-elemzést is? Például (nyomtató) Két érvényes határérték tesztelése, de köztük semmit 1-et jól nyomtat, de 99-et nem, - tesztelés például 10-re Háromértékű határérték-elemzést is használhatunk ; 55

56 4.3.3 Miért végezzünk ekvivalenciaosztályozást és határérték-elemzést is? Mit tesztelünk a tesztelés célkitűzéseitől függ Ha a cél az alaposság: Érvényes osztályok letesztelése érvénytelen osztályok érvényes határok érvénytelen határok Határidő: Tipikus tranzakciók érvényes osztályok Lehető legtöbb hiba megtalálása: határérték tesztelés (érvényes és érvénytelen) Megfelelően kezeli a rossz bemeneteket: érvénytelen osztályok és határok Előző tapasztalataink segítenek Döntésitábla-teszt Miért használunk döntési táblát? Ekvivanciaosztályozás és határérték-elemzés meghatározott szituációk (bemenetek) esetén Bemenetek kombinációi különböző teehendőkhöz vezetnek Ekvivanciaosztályozás és határérték-elemzés inkább interfészre összpontosít Döntési tábla és állapotátmenet-teszt üzleti logikára alapul Alkalmas kombinációk kezelésére Gyakran ok-okozati táblának nevezzük Kapcsolódik hozzá egy diagramkészítési technika okokozati diagram 56

57 4.3.3 Döntésitábla-teszt Miért használunk döntési táblát? Elemzők és fejlesztők is hasznosnak találják Megkönnyíti munkát Kombinációk tesztelése kihívás, hiszen a kombinációk száma igen nagy Minden kombinációt letesztelni néha lehetetlen Mely kombinációkat teszteljük? Ha nincsen szisztematikus módszerünk tetszőleges részosztály kiválasztása de ez felesleges teszteléssel is járhat Döntési táblák segítenek a tesztesetek szisztematikus kiválasztását Jól együttműködik ekvivalenciaosztályozással feltételek lehetnek ekvivalencia osztályok Döntésitábla-teszt Logikai feltételeket tartalmazó rendszerkövetelmények tesztelésére használható Alkalmazhatók komplex üzleti szabályok rögzítésére Létrehozásakor elemzik a specifikációt, és meghatározzák a rendszer feltételeit és műveleteit Tartalmaz: Igaz vagy hamis értékek, ezek kombinációi, ezekhez tartozó értékek Tábla minden oszlopa egy üzleti szabályhoz tartozik (kombinációk) Legalább egy tesztnek kell lennie oszloponként Feltételek olyan kombinációit hozza létre, melyeket a tesztelés során esetleg nem érintenének 57

58 4.3.3 Döntésitábla-teszt Műszaki teszttervezés Függvény vagy alrendszer, amely a bemenetek vagy az események kombinációjára reagál Nagyszámú feltételt célszerű alcsoportokra osztani Feltételek meghatározása után táblázatot készítünk Igaz és hamis értékek összes lehetséges kombinációja Döntésitábla-teszt 58

59 4.3.3 Döntésitábla-teszt Műszaki teszttervezés Kölcsönökkel kapcsolatos alkalmazás, amelybe bevihetjük a havi törlesztő részleteket és a futamidőt Igaz és hamis értékek meghatározása Döntésitábla-teszt Műszaki teszttervezés Egyes kombinációkhoz tartozó helyes kimenetek Észrevesszük, hogy nincs arra lehetőség, hogy az ügyfél egyetlen mezőt sem tölt ki Feltételezzük, hogy ez hibaüzenetet eredményez (felfedezhetjük specifikáció hiányosságait) 59

60 4.3.3 Döntésitábla-teszt Műszaki teszttervezés Specifikáció (tesztbázis) is felülvizsgálható vele Döntésitábla-teszt Műszaki teszttervezés Technika utolsó lépése az, hogy teszteseteket írunk Bemeneti elemekkel kezdtünk Gyakorlatban néha eredményeink vannak 60

61 4.3.3 Döntésitábla-teszt Példa Egy biztosító cég az alábbi kedvezményeket adja házas vagy jól tanuló vezetőinek Döntésitábla-teszt Példa Műveletek 61

62 4.3.3 Döntésitábla-teszt Egy új ügyfék egy hűségkártyát szeretne használni: - Az új vásárlók 15% kedvezményt kapnak minden mai napi vásárláson - Már meglévő ügyfél hűségkártyával, 10% kedvezményt kap - Ha rendelkezik kuponnal, a mai napon 20% kedvezményt kap * Új vásárló kedvezmény nem vonható össze kupon kedvezménnyel Döntésitábla-teszt X ez a kombináció nem fordulhat elő Feltételezés a 3. szabálynál Kupon nagyobb kedvezményre jogosít Ilyen esetben konzultáció ügyféllel vagy BA-vel 5. szabálynál összeadtuk a kedvezményeket szabály csak egyféle kedvezménnyel dolgozunk 8. szabálynál kedvezmény 0% 62

63 4.3.3 Döntésitábla-teszt Döntésitábla-teszt 63

64 4.3.4 Döntésitábla-teszt Egyetemi honlap új diákok hozzáadására alkalmas, meglévő diákok adatainak módosítására, vagy meglévő diákok törlésére alkalmas Döntésitábla-teszt Új diák létrehozásához az alábbi információk szükségesek: név, cím, telefonszám, és Enter gomb megnyomása A rendszer ilyen esetben beviszi az új diák adatait a rendszerbe és megad egy Diák azonosítót. Diákok adatainak módosításához vagy törléséhez be kell vinni a Diák azonosítót, kiválasztani a Delete or Modify radio buttont és meg kell nyomni az Enter gombot 64

65 4.3.4 Döntésitábla-teszt Döntésitábla-teszt 65

66 4.3.4 Döntésitábla-teszt Ha sok kombinációnk van vagy szorít az időkeret nem tesztelünk le minden kombinációt Nem kell mindent letesztelni Prioritási sorrend alkotása, a legfontosabbakat teszteljük Állapotátmenet-teszt Rendszer állapota leírható egy véges állapotú gépezettel Egy rendszer véges számú különböző állapotban lehet Az egyik állapotból a másikba való átmenetet a gépezet szabályai határozzák meg Erre a modellre alapozzuk a teszteseteket A véges állapotú rendszert állapotdiagrammon ábrázoljuk 66

67 4.3.4 Állapotátmenet-teszt A rendszer az adott jellemzőitől vagy a megelőző eseményektől (az állapottól) függően különböző válaszokat adhat Állapotátmenet diagram Állapottábla A szoftver különböző állapotai, az állapotok közötti átmenetek, az állapotváltozások vizsgálhatóak Általánosságban a műszaki automatizálásban Meghatározott állapotokkal rendelkező üzleti objektumok modellezésére Állapotátmenet-teszt Repülőjegy foglaló rendszeren foglalást szeretnénk tenni. Megadjuk a szükséges információkat, ilyenkor a foglalás Made státuszba kerül. A jegyfoglaló rendszer egy időmérő rendszert indít, ha a keretidő lejár a foglalás törlésre kerül a rendszer által. Made Információ megadás / Időmérés 67

68 4.3.4 Állapotátmenet-teszt Miután a foglalás Made státuszba került, az ügyfél kifizeti a repülőjegyet Ár kifizetése Made Paid Információ megadás / Időmérés Állapotátmenet-teszt A Print gomb megnyomása után a jegy Ticketed státuszba kerül Ár kifizetése Print megnyomása Made Paid Ticketed Információ megadás / Időmérés 68

69 4.3.4 Állapotátmenet-teszt A jegy kiadása után a jegy Used státuszba kerül Ár kifizetése Print megnyomása Made Információ megadás / Időmérés Paid Ticketed Used Jegy kiadása Állapotátmenet-teszt Időszámláló lejár Ár kifizetése Made Információ megadás / Időmérés Paid Print megnyomása Ticketed Jegy kiadása Used Cancelled non Pay 69

70 4.3.4 Állapotátmenet-teszt Ügyfél Cancelled státuszba teszi Ár kifizetése Print megnyomása Made Információ megadás / Időmérés Paid Cancelled az ügyfél által Ticketed Used Jegy kiadása Cancelled non Pay Cancelled non Pay Állapotátmenet-teszt 70

71 4.3.4 Állapotátmenet-teszt Állapotátmenet-teszt Tesztesetek levezetése: Tipikus forgatókönyvből indulunk ki (leggyakoribb szituáció helyes PIN) Összes állapotot vagy átmenetet fedjük le Második teszteset azért, hogy minden állapoton átmenjünk helytelen PIN bevitel PIN első alkalommal, másodszorra hibás, harmadszorra helyes PIN harmadik próbálkozásra helyes 71

72 4.3.4 Állapotátmenet-teszt Állapotátmenet-technikák előnye: modell szükség szerint lehet részletezett vagy absztrakt Rendszer egyik része fontosabb nagyobb részletességgel modellezzük Rendszer kevésbé fontos részei egy állapottal modellezzük Állapotátmenet-teszt Érvénytelen átmenetek tesztelése: Állapotgráf (állapotgrafikon) érvényes étmenetek megfigyelése Érvénytelen átmenetek nem láthatóak Érdemes állapottáblát írni: Bal oldali oszlopba összes állapot Felső sorban események Tábla cellái állapotesemény-párt reprezentálnak Cellák tartalma mutatja, hogy mely állapotba megy át a rendszer Mutatja Negatív tesztelési feltételeket 72

73 4.3.4 Állapotátmenet-teszt Állapotátmenet-teszt 73

74 4.3.4 Állapotátmenet-teszt Állapotátmenet-teszt Példa: szövegszerkesztő Megnyitunk egy dokumentumot, akkor bezárható Ha nincsen nyitott dokumentum, akkor a bezárás funkció nem elérhető Ha a bezárást egyszer kiválasztottuk, még egyszer nem kiválasztható Dokumentumnak tehát két állapota van: megnyitott és bezárt 74

75 4.3.4 Állapotátmenet-teszt Az állapotátmenet-modellnek 4 része van: Állapotok-amelyeket a szoftver felvehet (megnyitottbezárt) Átmenetek az egyik állapotból a másikba (nem minden átmenet megengedett) Események, melyek átmenetet okoznak (a fájl bezárása) Tevékenységek, melyeket az átmenetek eredményeként hajtunk végre (hibaüzenet) Állapotátmenet-teszt 75

76 4.3.5 Használati eset teszt Egész rendszer átvizsgálásra tranzakcióról tranzakcióra Rendszer leírása egy adott szereplő szempontjából (használat) Rendszer és szereplő közötti kölcsönhatást írja le A szereplő lehet másik rendszer is Használati estet lépések sorozatát tartalmazza (szereplő és rendszer közötti kölcsönhatás) Azt írjuk le, hogy a szereplő mit tesz és lát (nem azt, hogy a rendszer milyen bemeneteket vár) Üzleti nyelven íródik Leginkább rendszer és átvételi tesztnél használjuk Integrációs problémák Használati eset teszt Alkalmas arra, hogy a rendszer valós problémáit felfedezzük Használati esethez tartozik egy főforgatókönyv Néha alternatív elágazások Használati esethez meg kell határozni előfeltételeket Minden használati esethez meg kell határozni utófeltételeket 76

77 4.3.5 Használati eset teszt A teszteket használati esetekből kiindulva határozhatják meg. Egy használati eset a szereplők ide tartoznak a felhasználók és a rendszer közötti kölcsönhatásokat írja le Használati eset rendelkezik előfeltételekkel, minden használati eset végrehajtás utáni feltételekkel ér véget Ügyfél/felhasználó részt vesz Forgatókönyvekként említik őket Hasznosak a rendszer valós használata folyamán fellépő hibák felderítésére Használati eset teszt 77

78 4.3.5 Használati eset teszt Használati eset teszt Egyetemi regisztráló rendszerben egy diák regisztrálni szeretne egy kurzusra 78

79 4.3.5 Használati eset teszt Használati eset teszt 1. Regisztrált felhasználó 2. Sikeres belépés 1.a Csak User name megadása 1.b Csak password megadása 1.c Nem regisztrált felhasználó 1.d. Mindkettő helytelenül megadva 79

80 4.4 Struktúra alapú, vagy fehérdoboz technikák A struktúra alapú fehérdoboz - teszt a szoftver vagy rendszer ismert struktúráján alapul Az alábbi szintekhez kapcsolódhat: - Komponens szint: a struktúra maga a kód, vagyis utasítások, döntések. - Integrációs szint: a struktúra lehet egy hívási fa (egy diagram, melyben modulok hívnak más modulokat). - Rendszerszint: a struktúra lehet egy menüstruktúra, egy üzleti folyamat vagy egy weboldal struktúra. 4.4 Struktúra alapú, vagy fehérdoboz technikák Struktúra alapú technikák kettős célt szolgálnak: Lefedettség mérése Tesztek műszaki tervezése Jól használható Segítségükkel kiterjedtebb lehet a tesztelés 80

81 4.4 Mi a lefedettség? Végrehajtott tesztelés mérése Alapvető lefedettségi mérőszám: Lefedettségi mérőszám használatának veszélyei: 100% lefedettség nem jelenti, hogy 100%-ban tesztelt Már megírt elemek lefedettségét méri, nem mond semmit a még meg nem írt kódrészről Specifikáció alapú technikák megmutatják, ha kimaradt valami, csakúgy, mint a tapasztalat alapú technikák A lefedettség típusai Minden szinten mérhető (komponensteszt, integrációs teszt, rendszerteszt, átvételi teszt) Rendszer és átvételi teszt szinten a lefedettségi elemek lehetnek követelmények, menüopciók, szűrők, tipikus üzleti tranzakciók További lefedettségi mérőszámok: adatbázis-struktúra elemei, fájlok Piaca rohamosan fejlődik 81

82 A lefedettség típusai ff A lefedettség típusai Lefedettség a specifikáció alapú technikáknál: EP: a vizsgált ekvivalenciaosztályok százalékos arány BVA: a vizsgált határok százalékos aránya Döntési tábla: letesztelt üzleti szabályok (döntésitáblaoszlopok) százalékos aránya Állapotátmenet-teszt: például bejárt állapotok százalékos aránya, vizsgált átmenetek százalékos aránya, érvénytelen átmenetek százalékos aránya Lefedettség: letesztelt követelmények %-os arányát értik lefedettségen Lefedettség: fejlesztők kódlefedettséget értik alatta 82

83 4.4 Struktúra alapú, vagy fehérdoboz technikák Utasítás: a programozási nyelvek egy entitása, ami tipikusan a futtatás legkisebb oszthatatlan egysége. Döntés: olyan program pont, ahol a vezérlési folyamnak két, vagy több alternatív útvonala van. 4.4 Struktúra alapú, vagy fehérdoboz technikák Döntési lefedettség magasabb rendű az utasításlefedettségnél: 100%-os döntési lefedettség esetén garantált a 100%-os utasítás-lefedettség, aminek fordítottja nem igaz. 83

84 4.5 Tapasztalat alapú technikák A tesztek a tesztelő szaktudásából és intuíciójából, valamint a hasonló alkalmazásokkal és technológiákkal kapcsolatos tapasztalataiból származnak. Szisztematikus technikák kiegészítéseként alkalmazzák őket Speciális tesztek (<Test>, Üresen hagyott input mező, Üres fájlok vagy hibás adatok bevitele) Típusai: Hibasejtés Felderítő technika 4.5 Tapasztalat alapú technikák - Hibasejtés A tesztelők általában a tapasztalat alapján előre sejtik a hibákat Támadás: Elkészítik a lehetséges hibák listáját, s megtervezik az ezen hibákat előidéző teszteket Példa: Már meglévő hibák alapján Meghibásodásokról rendelkezésre álló adatok alapján Szoftver helytelen működésével kapcsolatos ismeretekből 84

85 4.5 Tapasztalat alapú technikák - Hibasejtés 4.5 Tapasztalat alapú technikák Felderítő teszt Egy időben történő műszaki teszttervezést, tesztvégrehajtást, tesztnaplózást és tanulást jelent adott időkeretben végrehajtva Különösen hasznos, ha kevés, vagy hiányos specifikáció, idő áll rendelkezésre Más teszt kiegészítésére is alkalmas 85

86 4.5 Tapasztalat alapú technikák Felderítő teszt 4.5 Tapasztalat alapú technikák Felderítő teszt 86

87 4.5 Tapasztalat alapú technikák Felderítő teszt Javasolt tesztek: Mezők (Kötelező mezők, Speciális formátumok, Max. Min karakterszámok) Instrukciók, instrukciók tartalma, progress bar megjelenítése Ugyanannak a dokumentumnak a többszöri megnyitása, Kozmetikai problémák, Konzisztens rövidítések, Emlékeztető ablakok (mentésre emlékeztető ablakok, törlésre emlékeztető ablakok) Nyelvtani és helyesírási hibák, Scrollolási lehetőség, Hibaüzenetek, hibaüzenetek helyesírási hibái, Billentyűkombinációk tesztelése Invalid gombok a workflowtól függően, színek, ikonok, linkek, menük, gombok sorrendje Feladat 87

88 4.6 Tesztelési technikák kiválasztása Melyik a legjobb technika? Mindegyik technika alkalmas arra, hogy hibákat találjunk Belső és Külső tényezők befolyásolják a technika megválasztását: Belső tényezők -Használt fejlesztési modell, Tesztelők tudása és tapasztalata, Hasonló típusú hibák, Tesztelés célja, Dokumentáció Külső tényezők - Szoftver kockázata, Ügyfél és szerződési feltételek, Használt rendszer típusa, Jogi előírások, Projekt ideje és költségei 4.6 Tesztelési technikák kiválasztása Ekvivalencia partícionálás: 88

89 4.6 Tesztelési technikák kiválasztása Ekvivalencia partícionálás: 4.6 Tesztelési technikák kiválasztása Határérték elemzés: 89

90 4.6 Tesztelési technikák kiválasztása Pairwise technique (Total # of combination 1,257,600 ): 4.6 Tesztelési technikák kiválasztása 90

91 4.6 Tesztelési technikák kiválasztása 4.6 Tesztelési technikák kiválasztása Example of checklist: 91

92 4.6 Tesztelési technikák kiválasztása Example of checklist: 4.6 Tesztelési technikák kiválasztása Példa: Címkereső, Felhasználók címeket adhatnak, szerkeszthetnek, törölhetnek. 92

93 4.6 Tesztelési technikák kiválasztása 4.6 Tesztelési technikák kiválasztása 93

94 Feladat Követelmények: A felhasználó új kontakt személyeket tud létrehozni A felhasználó meg tud változtatni már létező kontakt személyeket A felhasználó keresni tud létező kontakt személyekre név alapján A felhasználó fotókat tud hozzáadni létező személyekhez A felhasználó törölni tud létező kontakt személyeket A felhasználó különböző típusú címeket tud hozzáadni létező kontaktokhoz A felhasználó különböző típusú címeket tud hozzáadni létező kontaktokhoz A felhasználó különböző típusú telefonszámokat tud hozzáadni létező kontaktokhoz (Web) Feladat 94