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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

3.2 A felülvizsgálat folyamata

1

Informális felülvizsgálat

2

Átvizsgálás

3

Technikai felülvizsgálat

4

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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 10-20 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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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!

3.2.3 Felülvizsgálatok típusai

24

2014.04.14.



25

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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 829-1998)

30

2014.04.14.

4.1 A teszt fejlesztési folyamata


31

2014.04.14.


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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

4.3.1 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

2014.04.14.

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 -10 000 és + 10 000 - Érvényes pozitív partíció (0 < x < 10 000) - Érvényes negatív partíció (- 10 000 < x < 0) - (x=0) - Érvénytelen pozitív partíció (x > 10 000) - Érvénytelen negatív partíció (x < - 10 000) - Nem egész számok (pl. 2,82) - Érvénytelen karakterek (pl. „p”)

4.3.1 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 - $ 2000 - 1,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

2014.04.14.

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.

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 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,01 ------ $ 0 - Az érvénytelen partíciók a következőek: negatív számok, alfabetikus és speciális karakterek

43

2014.04.14.


4.3.1 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

2014.04.14.

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?


45

2014.04.14.

4.3.2 Ekvivalencia particionálás Ø 1. partíció

Ø 2. partíció

4.3.2 Ekvivalencia particionálás Ø 3. partíció

46

2014.04.14.

4.3.2 Ekvivalencia particionálás Ø Tesztesetek

4.3.2 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

2014.04.14.

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ó

4.3.2 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: 5000 Maximum kölcsön: 1 000 000 Tulajdon minimum értéke: 25 000 Tulajdon maximum értéke: 5 000 000

48

2014.04.14.



49

2014.04.14.


4.3.2 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

2014.04.14.

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 100-699-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 100-699 (099-700 é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

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 10-11 teszteset Ø Ø Ø Ø Ø

51

2014.04.14.

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 10-11 teszteset Ø Ø Ø Ø Ø

4.3.3 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

2014.04.14.

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

Ø Ø Ø Ø

4.3.3 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

2014.04.14.

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

4.3.3 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

2014.04.14.

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

4.3.3 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 1-298-99;

55

2014.04.14.

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

4.3.3 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

2014.04.14.

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

4.3.3 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

2014.04.14.

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


58

2014.04.14.


Ø 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


Ø 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

2014.04.14.


Ø Specifikáció (tesztbázis) is felülvizsgálható vele


Ø Technika utolsó lépése az, hogy teszteseteket írunk Ø Bemeneti elemekkel kezdtünk Ø Gyakorlatban néha eredményeink vannak

60

2014.04.14.

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.

4.3.3 Döntésitábla-teszt Ø Példa Műveletek

61

2014.04.14.

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

4.3.3 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 Ø 4. 5. 6. szabály csak egyféle kedvezménnyel dolgozunk Ø 8. szabálynál kedvezmény 0%

62

2014.04.14.



63

2014.04.14.

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.

4.3.4 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

2014.04.14.



65

2014.04.14.


Ø 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

4.3.4 Á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

2014.04.14.

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

4.3.4 Á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

2014.04.14.

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


4.3.4 Állapotátmenet-teszt Ø A Print gomb megnyomása után a jegy Ticketed státuszba kerül Print megnyomása Ár kifizetése Made

Paid

Ticketed


68

2014.04.14.

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

Paid Ticketed Jegy kiadása


Used

4.3.4 Állapotátmenet-teszt Ø Időszámláló lejár Ár kifizetése

Made

Print megnyomása Paid Ticketed


Jegy kiadása Used

Cancelled – non Pay

69

2014.04.14.

4.3.4 Állapotátmenet-teszt Ø Ügyfél Cancelled státuszba teszi Ár kifizetése Print megnyomása

Made

Paid Ticketed


Cancelled az ügyfél által

Jegy kiadása Used



4.3.4 Állapotátmenet-teszt

70

2014.04.14.


4.3.4 Á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

2014.04.14.

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

4.3.4 Á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

2014.04.14.



73

2014.04.14.



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

2014.04.14.

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)


75

2014.04.14.

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

4.3.5 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

2014.04.14.

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.

4.3.5 Használati eset teszt

77

2014.04.14.


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

78

2014.04.14.


4.3.5 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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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 (, Ü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

2014.04.14.

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

2014.04.14.

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

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

86

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.

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

2014.04.14.


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

91

2014.04.14.

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

2014.04.14.



93

2014.04.14.

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ú email 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

2014.04.14.

4.6 Tesztelési technikák kiválasztása Követelmények: Ø A Business Impact Activity (BIA) első oldalán BIA rekordokat hozhatunk létre Ø A létrehozó oldalról a Contract oldal nyílik meg, ahol lehetőségünk van kitölteni és elmenteni az oldalat. Ø A Contract tab mentése után az Evaluation oldal jelenik meg, amely rögtön az Interdependency oldalra ugrik. Ø A Plan oldal Plan-eket adhatunk a BIA-hoz. Add Component gomb megnyomása után a Create plan oldal jelenik meg.

Feladat

95

2014.04.14.

Feladat

Feladat 2.

96

2014.04.14.

Feladat

Feladat

97

2014.04.14.

Feladat

Feladat

98

2014.04.14.

Feladat 4.

4.6 Tesztelési technikák kiválasztása Követelmények: Ø A beszerzési szoftveren a beszerzési munkatárs az alábbi lépéseket tudja tenni egy kérésen Ø Elutasítja a kérést Ø Árajánlatot kér Ø Megrendelést készít a kérésből * Ha a kérés értéke meghaladja az $500 a kérést a department managernek is jóvá kell hagynia * Ha a kérés értéke meghaladja az $1000 a kérést a az alelnöknek is jóvá kell hagynia * Ha a kérés meghaladja a $ 5000 a kérést a pénzügyi igazgatónak is jóvá kell hagynia

99

2014.04.14.


4.6 Tesztelési technikák kiválasztása Követelmények: Ø Biztosító társaság szoftvere az alábbi feltételekkel fogad el autósokat biztosításra: Ø Balesetek száma Ø Autó típusa Ø Autó kora Ø A társaság visszautasíthatja a biztosítást Ø Elfogadhatja a biztosítást, standard áron Ø Elfogadhatja a biztosítást speciális áron

100

2014.04.14.


4.6 Tesztelési technikák kiválasztása Követelmények: Ø Technikai support cég printer problémákat szeretne megérteni az ügyfeleik visszajelzései alapján: Ø Printer nem nyomtat Ø Piros lámpa felgyullad Ø Nem ismeri fel a rendszer a nyomtatót Melyek a lehetséges megoldások?

101

2014.04.14.


4.6 Tesztelési technikák kiválasztása Követelmények: Ø Három feltétel befolyásol egy árleszállítást: Ø Diák (25% kedvezmény) Ø Fiatalabb, mint 24 év (25% kedvezmény) Ø Új tag (15% kedvezmény)

102

2014.04.14.



103

2014.04.14.

4.6 Tesztelési technikák kiválasztása Követelmények: Ø Egy rendeléshez tudunk új sort hozzáadni. A rendeléshez több sor adható Ø Minden sor egy speciális periódushoz kapcsolódik Előfeltételek: Ø A rendelésnek már léteznie kell a rendszerben „in progress” státuszban Ø A felhasználó be van lépve a rendszerbe Ø A rendelés nem tartalmazhat 25-nél több sort. Ø Rendelésszámnak egyedinek kell lennie

4.6 Tesztelési technikák kiválasztása Utófeltételek: Ø A rendelésnek a módosítások után is elérhetőnek kell lennie Ø A rendszernek a megfelelő állapotban kell lennie Ø A termékszám nem lehet duplikátum Ø Hibák esetén hibaüzenetek jelennek meg Ø A tesztesetek lefuttatása után a rendelés újra szerkeszthető

104

2014.04.14.



105

2014.04.14.

4.6 Tesztelési technikák kiválasztása Hány teszteset szükséges az alábbi kódrész döntés leteszteléséhez? If (p==q) s=s+1 if (s<5) { t=10 } else if (p>q) { t=5 } …… …... ……

4.6 Tesztelési technikák kiválasztása A Test Managered arra kért, hogy egy ellenőrző lista alapján nézd át a hibákat egy software követelmény dokumentumban. Az alábbi checklist alapján nézd át a dokumentációt: Ø Ø Ø Ø Ø

Specifikus Tesztelhető Egyértelmű Nyomonkövethető Konzisztens

106

2014.04.14.

4.6 Tesztelési technikák kiválasztása Use case testing

4.6 Tesztelési technikák kiválasztása Test case information

107

2014.04.14.

4.6 Tesztelési technikák kiválasztása Use case testing

4.6 Tesztelési technikák kiválasztása A felhasználó létrehozhat, módosíthat, törölhet feladatokat A felhasználó elkezdhet és megállíthat feladatokat A felhasználó e-maileket küldhet és beállíthatja azok küldését egy adott időpontra A felhasználó riportokat készíthet és beállíthatja azok küldését egy adott időpontra

108

2014.04.14.



109

2014.04.14.



110

2014.04.14.



111

2014.04.14.



112

2014.04.14.


4.6 Tesztelési technikák kiválasztása Dolgozatokat feltöltő oldal

113

2014.04.14.



114

2014.04.14.



115

2014.04.14.

4.6 Tesztelési technikák kiválasztása Agreement under work Agreement sent to direct report Agreement accepted by direct report Terminated Agreement sent to Direct Report 2

Agreement accepted by Direct Report 2

Evaluation sent to Direct Report

Evaluation sent to Direct Report 2


116

2014.04.14.


Kérdések?

117

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

Recommend Documents