Teszttervezés. Majzik István, Micskei Zoltán. Integrációs és ellenőrzési technikák (VIMIA04) Méréstechnika és Információs Rendszerek Tanszék

Átírás

1 Integrációs és ellenőrzési technikák (VIMIA04) Teszttervezés Majzik István, Micskei Zoltán Méréstechnika és Információs Rendszerek Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék 1

2 Áttekintés Funkció Felülvizsgáló Verziókezelő rendszer Fejlesztő Éles környezet Kódolási szabályok Statikus analízis Egységteszt Folytonos integráció kiszolgáló Felügyelet Rendszerteszt 2 E2E teszt Ikonok: icons8.com

3 Miért fontos a teszttervezés? More than the act of testing, the act of designing tests is one of the best bug preventers known. Boris Beizer 3

4 Tesztelési alapfogalmak (ismétlés) Specification, requirements Test cases Test execution Verdicts SUT: system under test Teszteset (test case) o bemeneti értékek, végrehajtási feltételek és elvárt eredmények halmaza, amelyeket egy konkrét célért fejlesztettek Tesztkészlet (test suite) Teszt-orákulum (test oracle) o Olyan elv vagy módszer, ami segít eldönteni a tesztelőnek, hogy sikeres volt-e a teszt Eredmény (verdict): pass / fail /error / inconclusive 4

5 Megoldandó feladatok Tesztkiválasztás (test selection) o Milyen bemeneti értékeket és adatok használjunk? Orákulum problémája o Honnan lesz megbízható orákulum? Kilépési feltétel (exit criteria) o Meddig folytassuk a tesztelést? 5

6 Teszttervezési technikák Cél: tesztesetek kiválasztása tesztcél alapján Specifikáció alapú SUT: black box Csak a specifikáció ismert Előirt funkcionalitás vizsgálata Struktúra alapú SUT: white box Belső felépítés ismert Felépítés és működés alapján bejárás 6

7 Lefedettségi metrikák Tesztelhető elemek mekkora %-a volt tesztelve Tesztelhető elemek o Specifikáció: követelmény, funkció o Struktúra: utasítás, döntés Lefedettségi feltétel (coverage criterion) o X % az Y metrikánál Ez nem hibafedés! 7

8 Mire jók a lefedettségi metrikák? Kiértékelés (mérés) Kiválasztás (cél) Meglévő tesztek kiértékelése Hiányzó tesztek azonosítása Teszt tervezése metrika mentén Cél adott % elérése 8

9 SPECIFIKÁCIÓ ALAPÚ TESZTELÉS 9

10 Teszttervezési technikák Cél: tesztesetek kiválasztása tesztcél alapján Specifikáció alapú SUT: black box Csak a specifikáció ismert Előirt funkcionalitás vizsgálata Struktúra alapú SUT: white box Belső felépítés ismert Felépítés és működés alapján bejárás 10

11 Specifikáció alapú technikák Ekvivalencia partícionálás Határértékanalízis Use case / user story Kombinatorikus módszerek Döntési táblák 11

12 Ekvivalencia partícionálás Bemenet és kimenet ekvivalencia osztályai: o Olyan adatok, amelyek várhatóan ugyanazt a hibát fedik le (ugyanazt a programrészt járják be) o Cél: Egy-egy ekvivalencia osztályból egy-egy teszt adat kiválasztása (többire elvileg hasonló) Nagyon környezetfüggő (context-dependent) o Ismerni kell a környezetet és a SUT-ot! o Tesztelő tudásán múlik a módszer hatékonysága 12

13 Ekvivalencia osztályok meghatározása Meghatározás heurisztikus folyamat: o Kezdés: érvényes és érvénytelen bemeneti adatok o Partíciók tovább finomítása Tipikus heurisztikák: o Tartomány (pl ) < min, min-max, >max o Halmaz (pl. RED, GREEN, BLUE) érvényes elem, érvénytelen o Specifikus az elején) feltétel teljesül, feltétel nem teljesül o Egyéni (pl. február hónap) 13

14 Tesztesetek származtatása ekv. osztályból Több bemenet ekv. osztályainak összekapcsolása Érvényes (normál) ekv. osztályok esetén: o egy teszt minél több osztályt fedjen le Érvénytelen ekv. osztályok esetén: o először minden érvénytelen osztályhoz külön teszt legyen o egymás hatását ne oltsák ki o majd több osztály kombinációja is 14

15 FELADAT Ekvivalencia partícionálás Követelmény: A hitelfelvételt meg kell tagadni, ha a kért összeg 1M Ft-nál nagyobb és az igénylő 25 évnél fiatalabb, kivéve ha az összeg 3M Ft-nál kisebb és az igénylőnek már volt korábban visszafizetett hitele. Bemeneti paraméterek? Ekvivalencia osztályok? Van kérdésünk a követelménnyel kapcsolatban? 16

16 Specifikáció alapú technikák Ekvivalencia partícionálás Határértékanalízis Use case / user story Kombinatorikus módszerek Döntési táblák 17

17 Határérték-analízis Adattartományok határait vizsgálja o Egy-egy ekvivalencia osztály határaira koncentrál o Bemeneti és kimeneti tartományokra is Tipikus megtalált hibák: o relációs operátorok o ciklusok be- és kilépési feltételei o adatstruktúrák mérete o 18

18 Tipikus teszt adatok határértékeknél Egy határérték 3 tesztet jelent: határérték Egy tartomány 5-7 tesztet jelent: határérték 1 határérték 2 19

19 FELADAT Határérték-analízis Követelmény: Legalább három könyvet kell rendelni a kedvezményes ár eléréséhez, és tíz könyv rendelése esetén további kedvezmény jár. Milyen értékeket használjunk a tesztelésre? Van kérdésünk a követelménnyel kapcsolatban? 21

20 Specifikáció alapú technikák Ekvivalencia partícionálás Határértékanalízis Use case / user story Kombinatorikus módszerek Döntési táblák 22

21 Tesztek származtatása használati esetekből Tipikus tesztesetek: o 1 teszt: fő ág ( happy path, mainstream ) Ellenőrzés: utófeltételek vizsgálata o Alternatív lefutások: mindegyikhez külön teszteset o Előfeltételek (nem)teljesülése Jobbára magasabb szintek (rendszer, elfogadási ) 23

22 FELADAT Használati esetek (use case) 24

23 STRUKTÚRA ALAPÚ TESZTELÉS 25

24 Teszttervezési technikák Cél: tesztesetek kiválasztása tesztcél alapján Specifikáció alapú SUT: black box Csak a specifikáció ismert Előirt funkcionalitás vizsgálata Struktúra alapú SUT: white box Belső felépítés ismert Felépítés és működés alapján bejárás 26

25 Mi a belső felépítés? Kód esetén: forráskód struktúrája Forráskód: int a = 1; while(a < 16) { if(a < 10) { a += 2; } else { a++; } } a = a * 2; Control-flow graph (CFG): control flow Megjegyzés: CFG pontos definíciójával most nem foglalkozunk! 27

26 Alapfogalmak int t = 1; Speed s = SLOW; Utasítás Blokk if (! started){ } start(); if (t > 10 && s == FAST){ brake(); } else { accelerate(); } 28 Feltétel Döntés Döntési ág

27 Utasítás (statement) Blokk (block) Alapfogalmak o Utasítások egybefüggő sorozata, amik között nincs elágazás vagy függvényhívás Feltétel (condition) o Egyszerű vizsgálat, amiben nincs logikai (Boole) operátor Döntés (decision) o Nulla vagy több logikai operátorral összekötött feltételből álló kifejezés Döntési ág (branch) o Egy döntés lehetséges kimenetele Út (path) o Utasítások sorozata, tipikusan a modul be és kilépési pontja között 29

28 1. Utasítás lefedettség Tesztelés során végrehajtott utasítások száma Összes utasítás szám A1 A2 A4 A3 A5 Utasítás lefedettség: 4/5 = 80% 30

29 Utasítás lefedettség értékelése Minden utasítást legalább egyszer végrehajtunk k=0 [a>0] k=1 [a<=0] m=1/k Utasítás lefedettség: 100% DE: hiányzik a [a<=0] ág Üres ágak lefedését nem garantálja 31

30 2. Döntési lefedettség Tesztelés során előfordult döntési eredmények száma Döntési eredmények lehetséges száma A2 Döntési lefedettség: 50% A4 A3 Hány eredménye lehet egy döntésnek? 32

31 Döntési lefedettség értékelése Minden utasítást legalább egyszer végrehajtunk Minden ágat lefedünk (üres ágakat is) # safe(c) safe(b) [safe(c) safe(b)] A2 [else] 1 T F 2 F F A4 A3 100% döntési lefedettség DE: safe(b) = true eset hiányzik! Feltételek kombinációjára nem figyel 33

32 További lefedettségi metrikák (lásd MSc) Condition Coverage Condition/Decision Coverage (C/DC) Modified Condition/Decision Coverage (MC/DC) Multiple Condition Coverage (MCC) Loop Coverage All-Defs Coverage All-Uses Coverage 34

33 FELADAT Struktúra alapú tesztelés 1 Product getproduct(string name, Category cat){ 2 if (name == null! cat.isvalid) 3 throw new IllegalArgumentException(); 4 5 Product p = ProductCache.getItem(name); 6 7 if (p == null){ 8 p = DAL.getProduct(name, cat); 9 } return p; 12 } Tervezz teszteket: 100% utasítás lefedettség 100% döntési lefedettség 36

34 Kód lefedettség számolása a gyakorlatban Mindegyik eszköznél más definíciók Megvalósítás o Forrás/bináris kód instrumentálása o Lefedettséget számoló utasítások hozzáadása if (a > 10){ CoveredBranch(1, true); b = 3; } else { CoveredBranch(1, false); b = 5; } send(b); Lásd például: Is bytecode instrumentation as good as source code instrumentation,

35 Kód lefedettség használata Mire használható: o Egyáltalán nem tesztelt kódrészlet azonosítása o Tesztkészlet teljességének értékelése o Kilépési feltételekben Mire nem használható: o Hiányzó/hiányos követelmények azonosítása o Kód/teszt minőségével csak indirekt kapcsolat 38

36 Kód lefedettség használata a gyakorlatban Microsoft tapasztalata: o Test suite with high code coverage and high assertion density is a good indicator for code quality. o Code coverage alone is generally not enough to ensure a good quality of unit tests and should be used with care. o The lack of code coverage to the contrary clearly indicates a risk, as many behaviors are untested. (Forrás: Parameterized Unit Testing with Microsoft Pex ) Kapcsolódó cikkek: o Coverage Is Not Strongly Correlated with Test Suite Effectiveness, DOI: / o The Risks of Coverage-Directed Test Case Generation, DOI: /TSE

37 Teszttervezési technikák összefoglalása Specifikáció és struktúra alapú technikák o Több, egymást kiegészítő módszer o Mindegyik módszert gyakorolni kell Technikák kombinációja hasznos Példa (Microsoft): specifikáció alapú: 83% kód lefedettség + felderítő tesztelés: 86% kód lefedettség + struktúra alapú: 91% kód lefedettség 40 40

38 Összefoglalás 41