Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Szoftvertesztelés 2013. május 7.. Szoftvertesztelés Bevezető • Jelen előadás anyaga az International Software Testing Qualifications Board (ISTQB) és.

Hasonló előadás


Az előadások a következő témára: "Szoftvertesztelés 2013. május 7.. Szoftvertesztelés Bevezető • Jelen előadás anyaga az International Software Testing Qualifications Board (ISTQB) és."— Előadás másolata:

1 Szoftvertesztelés május 7.

2 Szoftvertesztelés Bevezető • Jelen előadás anyaga az International Software Testing Qualifications Board (ISTQB) és a Hungarian Testing Board (HTB) által jóváhagyott és használt struktúrákat és fogalmakat tartalmazza • Az anyag segít megérteni a tesztelést, mint üzletágat és átfogó képet igyekszik alkotni arról, hogyan is teszteljünk éles helyzetekben

3 Szoftvertesztelés Agenda • A tesztelés alapjai • Mi a tesztelés, miért jó? • Alapelvek • Alapvető folyamatok • Tesztelés a szoftver életciklusán át • Szoftverfejlesztési modellek • Tesztszintek • Teszttípusok • Karbantartási teszt • Statikus technikák • Felülvizsgálat folyamata, statikus elemzés • Teszttervezési technikák • Black box technikák • White box technikák • Empirikus tesztelés • Eszköztámogatás

4 A tesztelés alapjai

5 Szoftvertesztelés Tesztelési alapelvek • Szoftverhibák okai: – Dokumentációs hiba – Kódolási hiba – Hardver feltételek megváltozása – Környezeti viszonyok • Sugárzás • Mágneses, elektromos mező • Szennyezés

6 Szoftvertesztelés Tesztelési alapelvek • Miért van szükség tesztelésre? – Használat során fellépő problémák kockázatának csökkentése – Minőségi szoftver – Megfelelés szerződésben foglalt szabályoknak, jogi előírásoknak – Megfelelés ipari szabványoknak

7 Szoftvertesztelés Tesztelés és a minőség • A teszteléssel mérjük a szoftver minőségét – Megbízhatóság – Használhatóság – Hatékonyság – Karbantarthatóság – Hordozhatóság

8 Szoftvertesztelés Mennyi tesztelés elegendő? • Ahhoz, hogy eldönthessük mennyi tesztelés elegendő, figyelembe kell vennünk: – A kockázati szintet – A technikai és vállalati termékek, projektek kockázatát – A projekt időre és költségvetésre vonatkozó megkötéseit

9 Szoftvertesztelés Mi a tesztelés? • Téves általános felfogás : a tesztelés csak tesztek futtatásából áll, vagyis a szoftver használatát, futtatását jelenti. Ez része a tesztelésnek, de a tesztelés nem csak ebből áll !!! • Tesztelési tevékenységek a tesztfuttatás előtt és után is léteznek: – Dokumentumok felülvizsgálata (beleértve a forráskódot is) – Teszttervezés- és irányítás, – Tesztelési feltételek meghatározása – Tesztesetek tervezése és futtatása, eredmények ellenőrzése – Kilépési feltételek kiértékelése – Tesztciklus lezárása, dokumentálás

10 Szoftvertesztelés Tesztelés helye az életciklusban Ötlet Definíció Tervezés Létrehozás Ellenőrzés Átadás Tesztelés

11 Szoftvertesztelés Tesztelési alapelvek • 1. alapelv – Hibajelenlét kimutatása – Bár a tesztelés kimutathatja a hibák jelenlétét, de azt nem képes igazolni, hogy nincsenek hibák. • 2. alapelv – Nem lehetséges kimerítő teszt • 3. alapelv – Korai tesztelés • 4. alapelv – Hibák csoportosulása – A kiadást megelőző tesztelés során a megtalált hibák többsége néhány modulban van, vagy legalábbis ezen modulok felelősek a működési hibák többségéért. • 5. alapelv – A féregirtó paradoxon – Ha mindig ugyanazokat a teszteket hajtjuk végre, akkor az azonos tesztkészlet egy idő után nem fog új hibákat találni. • 6. alapelv – A tesztelés függ a körülményektől (körülményfüggés) – Internetbank vs tanszéki portál • 7. alapelv – A hibátlan rendszer téveszméje – A hibák megtalálása és javítása hasztalan, ha a kifejlesztett rendszer használhatatlan, és nem felel meg a felhasználók igényeinek, elvárásainak.

12 Szoftvertesztelés A tesztelés folyamata Note: Ezek a folyamatok logikailag egymás után következnek, de a gyakorlatban legtöbbször átfedik egymást. Tervezés és irányítás Elemzés és műszaki tervezés Megvalósítás és végrehajtás Kilépési feltételek értékelése és jelentés Teszt lezárása

13 Tesztelés a szoftver életciklusán át

14 Szoftvertesztelés Tesztszintek • Komponensteszt - Unit Test • Integrációs teszt – Integration Test • Rendszerteszt – System Test • Átvételi teszt – User Acceptance Test (UAT)

15 Szoftvertesztelés A V-modell

16 Szoftvertesztelés Komponens teszt • Tesztbázis: – Komponens követelmények – Részletes műszaki tesztterv – Kód • A tesztelés jellemző tárgyai: – Komponensek – Programok – Adatkonvertáló / migrációs programok – Adatbázis modulok

17 Szoftvertesztelés Integrációs teszt • Tesztbázis: – A szoftver és a rendszer műszaki tesztterve – Architektúra – Munkafolyamatok – Használati esetek • A tesztelés jellemző tárgyai: – Alrendszerek adatbázis implementálása – Infrastruktúra – Interfészek

18 Szoftvertesztelés Rendszer teszt • Tesztbázis: – Rendszer– és szoftverkövetelmény specifikáció – Használati esetek – Funkcionális specifikáció – Kockázatelemzés jelentések • A tesztelés jellemző tárgyai: – Rendszer-, felhasználói-, és működési kézikönyv – Rendszer konfiguráció

19 Szoftvertesztelés Átvételi teszt • Tesztbázis: – Felhasználói követelmények – Rendszerkövetelmények – Használati esetek – Üzleti folyamatok – Kockázatelemzés jelentések • A tesztelés jellemző tárgyai: – Üzleti folyamatok teljesen integrált rendszeren – Működési és karbantartási folyamatok – Felhasználói eljárások – Sablonok – Jelentések

20 Szoftvertesztelés Teszttípusok • Funkcionális teszt – Functional testing • Nem funkcionális teszt – Non-Functional testing • Strukturális teszt – Structural testing • Változásokhoz kapcsolódó teszt, újratesztelés és regressziós tesztelés – Confirmation and regression testing • Karbantartási teszt – Maintenance testing

21 Szoftvertesztelés Funkcionális teszt • Black box testing • A funkcionalitások alatt azt értjük, amit „a rendszer tesz” • A szoftver külső viselkedésével foglalkozik – Megfelelőség – Együttműködő készség – Biztonság – Pontosság, „jóság” – Szabványnak való megfelelés

22 Szoftvertesztelés Nem funkcionális teszt • Azt teszteli, hogy a rendszer „hogyan” működik • Azokat a teszteket takarja, melyek a különböző mennyiségi mutatókkal leírható rendszer- és szoftverjellemzők méréséhez szükségesek – Teljesítmény teszt (Performance testing) • Terheléses teszt (Load testing) • Stressz teszt (Stress testing) – Használhatósági teszt (Usability testing) – Megbízhatósági teszt (Reliability testing) – Hordozhatósági teszt (Portability testing)

23 Szoftvertesztelés Strukturális teszt • White box testing • A strukturális technikák legjobban a specifikáció alapú technikák után használhatók annak érdekében, hogy egy adott típusú struktúra lefedettségének elemzésével támogassák a teszt lefedettségének mérését. • A lefedettség azt mutatja meg, hogy egy tesztkészlet milyen mértékben hívott meg egy struktúrát, és ezt az értéket a lefedett elemek százalékában fejezik ki. Ha a lefedettség nem 100%, további teszteket tervezhetnek, hogy a kimaradt elemeket is teszteljék, ezzel növelve a lefedettséget.

24 Szoftvertesztelés Újratesztelés és Regressziós teszt • Egy hiba felismerése és javítása után a szoftvert újra kell tesztelni, ezáltal meggyőződve arról, hogy a hiba eltűnt. Ezt hívják ellenőrző tesztnek. • A regressziós teszt egy már letesztelt program módosítása után történő ismételt tesztelése. Note: A regressziós tesztkészleteket sokszor futtatják le, és többnyire lassan fejlődnek ki, így a regressziós tesztnél fontos lehet az automatizálás.

25 Szoftvertesztelés Karbantartási teszt • A karbantartási tesztet létező, működő rendszeren hajtják végre, a tesztelésre a szoftver vagy rendszer módosítása, migrációja, vagy kivonása ad okot. • Hatáselemzés (Impact Analysis) alatt értjük annak meghatározását, hogy a változtatások milyen befolyással lesznek a már létező rendszerre; ez segít annak eldöntésében, hogy mennyi regressziós tesztet kell végezni. Note: A karbantartási tesztet jelentősen megnehezíti, ha a specifikációk elavultak, vagy egyáltalán nem állnak rendelkezésre.

26 Statikus technikák

27 Szoftvertesztelés Mi a statikus technika? • A kód vagy a projekt dokumentum manuális vizsgálata vagy automatikus elemzése • A követelményekben található hibák javítása sokkal olcsóbb mint a későbbi fázisokban • Felülvizsgálat (Review) előnyei – Hibák korai megtalálása és javítása – Fejlesztési termelékenység javítása – Fejlesztési időtartamok csökkentése – Tesztelési költség és idő csökkentése – Teljes élettartam költségeinek csökkentése – Kevesebb hiba, jobb kommunikáció

28 Szoftvertesztelés A hibákat minél korábban fedezzük fel! A hibajavítás relatív költsége … 100 RequirementsDesignCode Test Maintenance A hiba felfedezésének fázisa Cost to Fix $1 $5 $20 $50 $100+

29 Szoftvertesztelés Review típusok Informális felülvizsgálat ÁtvizsgálásTechnikai felülvizsgálat Inspekció Tervezésnincsvan Kick-offnincs opcionálisvan Egyéni felkészülés nincsopcionálisvan Review meeting van Újradolgozásvan Követésnincsopcionális van

30 Szoftvertesztelés Statikus elemzés eszközökkel • A statikus elemző eszközök a programkódot (pl. vezérlési folyam és adatfolyam) valamint a generált kimenetet (mint pl. HTML vagy XML) elemzik. • A statikus elemző eszközök által felismert tipikus hibák: – meghatározatlan értékű változóra való hivatkozás – összeférhetetlen interfész modulok és komponensek között – soha nem használt változók – nem elérhető (halott) kód – hiányzó vagy hibás logika (potenciális végtelen ciklusok) – túl komplikált struktúra – programozási szabványok megsértése – biztonsági rések – szintaxis megsértése a kódban

31 Teszttervezési technikák

32 Szoftvertesztelés Teszttervezés • A teszt műszaki tervezése során a tesztesetek és tesztadatok megalkotása és meghatározása történik. • Egy teszteset a következőkből áll: – bemeneti értékek halmaza – végrehajtási előfeltételek – elvárt eredmények – végrehajtás utáni feltételek • A „Szoftverteszt Dokumentáció Szabvány” (IEEE 829) tárgyalja a (tesztelési feltételeket is tartalmazó) műszaki tesztterv specifikációk és a teszteset specifikációk tartalmát.

33 Szoftvertesztelés Teszttervezési technikák kategóriái • Black box technikák – Ekvivalencia particionálás – Határérték elemzés – Döntési tábla – Állapotátmenet teszt – Use case teszt • White box technikák – Utasítás szintű teszt és lefedettség – Döntési teszt és lefedettség • Tapasztalat alapú technikák

34 Szoftvertesztelés Black box technikák • Black box technikák – Ekvivalencia particionálás – Határérték elemzés – Döntési tábla – Állapotátmenet teszt – Use case teszt

35 Szoftvertesztelés 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 léteznek az érvényes és az érvénytelen adatokra is. A partíciók alkalmazhatók továbbá – bemenetekre – kimenetekre – belső értékekre – idővel kapcsolatos értékekre (pl. egy esemény előtt vagy után) – valamint interfész paraméterekre (pl. tesztelendő integrált komponensekre az integrációs teszt során). • A partíciók lefedésére tesztek tervezhetők. • A tesztelés minden szintjén alkalmazható.

36 Szoftvertesztelés Példa bementi paraméterek tesztelésére Követelmény:Egy beviteli integer mező és között fogad el adatokat és megengedi a határértékeket is. Ekvivalencia partíciókÉrtékekTesztadatok szempontjából Érvényes pozitív értékek01000Érvénytelen ekvivalencia partíció Érvénytelen negatív értékekx<-1000Érvénytelen ekvivalencia partíció Valós számok5,34Érvénytelen ekvivalencia partíció Érvénytelen karakterekefesdfÉrvénytelen ekvivalencia partíció

37 Szoftvertesztelés Példa kimeneti paraméterek tesztelésére Követelmény:Egy banki rendszer különböző kamatot ajánl különböző feltételek teljesítése esetén. A bank elfogadja a centet is. – 5% az első 1000$ -os betétre – 10% a következő 1000$-ra – 15% a további betétekre BemenetKimenet % % %

38 Szoftvertesztelés Határérték elemzés • Az ekvivalencia partíciók határain kisebb az esély a helyes viselkedésre, mint a partíción belül, ezért ott a tesztek nagy eséllyel találnak hibákat. 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; míg az érvénytelen partíciók határa az érvénytelen határérték. • A tesztek tervezhetők úgy, hogy lefedjék az érvényes és az érvénytelen határértékeket is. A tesztesetek tervezésénél minden határértékhez választani kell egy tesztet. • A határérték elemzés minden tesztelési szinten alkalmazható. • Viszonylag egyszerű az alkalmazása, hibatalálási képessége magas. A részletes specifikációk hasznosak az érdekes határértékek megállapításakor. • Ezt a technikát sokszor az ekvivalencia particionálás kiterjesztésének tekintik.

39 Szoftvertesztelés Példa határérték elemzésre Az ekvivalencia partíciónk a következő: [-100;+100] TesztadatIntervallumMegjegyzés -101]-végtelen; -101]Maximum érvénytelen határérték -100[-100;+100]Minimum érvényes határérték +100[-100;+100]Maximum érvényes határérték +101[+101;+végtelen[Minimum érvénytelen határérték

40 Szoftvertesztelés Döntési tábla • A döntési táblák jól használhatók logikai feltételeket tartalmazó rendszerkövetelmények felvételére és a belső rendszerfelépítés dokumentálására. Alkalmazhatók a rendszer által megvalósított komplex üzleti szabályok rögzítésére. • A bemeneti feltételek és műveletek leggyakrabban úgy vannak megadva, hogy csak igaz vagy hamis értékek lehetnek (Boolean). • A döntési tábla tartalmaz kiváltó okokat, valamint a feltételek kombinációihoz tartozó eredményeket. • Előnye: a feltételek olyan kombinációit hozzák létre, melyeket a tesztelés során esetleg nem érintenének. • Minden olyan helyzetben alkalmazható, ahol a szoftver által végrehajtott művelet különböző logikai döntéseken alapul.

41 Szoftvertesztelés Példa döntési táblára Egy áruház hűségrendszert kínál minden vásárlójának. A hűségkártya tulajdonosok kedvezményeket kapnak minden vásárlásukhoz, vagy hűségpontokat kérnek kártyájukra amely voucher-re váltható. Akiknek nincs hűségkártyája, csak abban az esetben kap kedvezményt, ha 10000HUF felett vásárol, más esetben nem jár kedvezmény. Szabály 1Szabály 2Szabály 3Szabály 4 Feltételek: Nincs hűségkártyaTTFF Van hűségkártyaFFTT Kedvezményt választ--TF 10000Huf feletti vásárlás FT-- Akciók: Nincs kedvezményTFFF Van kedvezményFTTF HűségpontFFFT

42 Szoftvertesztelés Á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. Ebben az esetben a rendszer helyzetét állapotátmenet diagrammal lehet bemutatni. Ennek segítségével a tesztelő vizsgálhatja a szoftvert a különböző állapotaiban, az állapotok közötti átmeneteket, az állapotváltozásokat kiváltó bemeneteket és eseményeket valamint a műveleteket, melyek az átmenetek következményei. • A tesztelt rendszer vagy objektum állapotai elkülöníthetők, beazonosíthatók és véges számúak. • Az állapotátmenet-tesztet gyakran használják a beágyazott szoftvereknél és általánosságban a műszaki automatizálásban.

43 Szoftvertesztelés Példa állapot átmenet tesztre

44 Szoftvertesztelés Példa állapot átmenet tesztre Teszteset azonosító Kezdő állapotÁllapotátmenetVégső állapot 1EmptyBreakBroken 2EmptySquirt(n)Checking bottle 3 Not fullEmpty 4Checking bottleFull 5 CappedSealed 6FullBreakBroken

45 Szoftvertesztelés Use Case 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, melyek eredményeként egy a rendszer felhasználója számára értékes eredmény jön létre. • Minden használati eset rendelkezik előfeltételekkel, melyeknek teljesülniük kell a használati eset sikeres működéséhez. • Minden használati eset végrehajtás utáni feltételekkel ér véget, ezek a használati eset lezárása után megfigyelhető eredményeket és a rendszer végső állapotát tartalmazzák. • A használati esetnek általában van egy fő (vagyis legvalószínűbb) forgatókönyve, valamint esetenként alternatív mellékágai. • A használati esetek leírják az „eljárási folyamatot” a rendszer valószínűsíthető használata alapján, így a használati esetekből származtatott tesztesetek a leghasznosabbak a rendszer valós használata folyamán fellépő hibák felderítésére. • A használati esetek (gyakran forgatókönyvekként említik őket) nagyon hasznosak átvételi tesztek tervezésére, amelyekben az ügyfél/felhasználó részt vesz. Egyébként a gyakorlatban a legelterjettebb módszer.

46 Szoftvertesztelés White box technikák • White box technikák – Utasítás szintű teszt és lefedettség (statement coverage) – Döntési teszt és lefedettség (condition coverage)

47 Szoftvertesztelés Statement- és condition coverage • Utasítás szintű teszt és lefedettség – A komponenstesztnél az utasítás szintű lefedettség annak értékelése, hogy valamely teszteset készlet a futtatható utasítások hány százalékát érintette. – Az utasítás szintű tesztnél a származtatott tesztesetek meghatározott utasításokat hajtanak végre, általában az utasítás lefedettség növelése érdekében. • Döntési teszt és lefedettség – A döntési lefedettség – amely összefüggésben áll az elágazás teszttel – annak értékelése, hogy valamely teszteset készlet a döntési eredmények (pl. egy If utasítás Igaz vagy Hamis lehetőségei) hány százalékát hajtotta végre. – A döntési tesztnél a származtatott tesztesetek speciális döntési eredményeket hajtanak végre, általában a döntési lefedettség növelése érdekében. • A döntési lefedettséget a megtervezett, illetve végrehajtott döntési eredmények száma és a tesztelendő kódban található összes lehetséges döntési eredmény hányadosa határozza meg. • A döntési lefedettség magasabb rendű az utasítás-lefedettsé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.

48 Szoftvertesztelés Példa If ((temperature 100) { alert(„DANGER”); if ((speed < 100 ) and (load <= 50) { speed = 50; } } else { check = false; } A 100% os condition coverage-hez (és egyben a statement coveraghez is) 2 teszteset elegendő!

49 Szoftvertesztelés 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. • Ha a szisztematikus technikák kiegészítéseként alkalmazzák őket, akkor ezek a technikák hasznosak lehetnek olyan speciális tesztek meghatározásánál, melyeket formális technikákkal nehéz elérni • Hatékonysága nagy eltéréseket mutathat, mivel függ a tesztelők tapasztalatától. 1.Hibasejtés: A tesztelők általában a tapasztalat alapján előre sejtik a hibákat. 2.A felderítő teszt: Ez a megközelítés akkor különösen hasznos, ha kevés, vagy hiányos specifikáció áll rendelkezésre, kevés az idő, vagy ha más, formálisabb tesztet szándékoznak bővíteni, kiegészíteni.

50 Eszköztámogatás

51 Szoftvertesztelés Tesztmenedzsment • Tesztmenedzsment eszközök – Interfész a tesztek végrehajtásához, a hibák nyomon követéséhez és a követelmények menedzseléséhez. – Támogatják a tesztelés tárgyának mennyiségi analízisét és ezekről történő jelentéskészítést. – Támogatják a tesztelés tárgyának a követelmény specifikációval szemben történő nyomon követését. • Követelmény menedzsment eszközök – A követelmények, illetve a követelményekhez tartozó attribútumok tárolása. – Egyedi azonosítókat kínálnak és támogatják a követelmények nyomon követését az egyes tesztekben. • Incidens menedzsment eszközök (Hibakövető eszközök) – Tárolják és menedzselik az incidensjelentéseket, pl. hibák, meghibásodások és változáskezdeményezések, a talált problémák és rendellenességek kezelését. – Támogatják továbbá az incidensek életciklusának menedzselését • Konfiguráció menedzsment eszközök – Bár nem kifejezetten teszteszközök, de szükségesek a tesztterv és a kapcsolódó szoftverek tárolásához és verziókövetéséhez, különösen, ha a teszt egynél több hardver/szoftver környezetet (pl. operációs rendszert, fordítóprogramot, böngészőt, stb.) igényel.

52 Szoftvertesztelés Statikus teszt eszközei • Felülvizsgálati eszközök (review) – Támogatják a felülvizsgálati folyamatot, az ellenőrző listákat, a felülvizsgálati útmutatókat és gyakran használják a felülvizsgálati megjegyzések és jelentések, valamint a ráfordítási adatok tárolására és kommunikációjára. – Támogathatják az online felülvizsgálatokat a nagy, vagy földrajzilag szétosztott csapatok részére. • Statikus elemző eszközök – A statikus elemző eszközök támogatják a fejlesztőket, a tesztelőket, hogy a hibákat a dinamikus teszt előtt megtalálják azáltal, hogy támogatást nyújtanak a kódolási irányelvek betartásának • Modellező eszközök – A modellező eszközökkel validálhatók a szoftver modelljei (pl. fizikai adatmodell egy relációs adatbázishoz)

53 Szoftvertesztelés Teszt specifikáció eszközei • Műszaki teszttervező eszközök – Tesztbemeneteket, vagy futtatható teszteket alakíthatnak ki a követelményekből, egy grafikus felhasználói interfészből, illetve teszt modellekből, vagy a kódból. • Tesztadat előkészítő eszközök – A tesztadat előkészítő eszközök adatbázisokat, fájlokat vagy adatátviteleket kezelnek a tesztek végrehajtásánál használandó tesztadatok létrehozásához, hogy az adatok anonimitásán keresztül biztosítsák a rendszer biztonságát

54 Szoftvertesztelés Teszt végrehajtás és naplózás eszközei • Tesztvégrehajtási eszközök – A tesztek automatikus vagy félautomatikus végrehajtását teszik lehetővé eltárolt bemenetek és elvárt eredmények segítségével, egy szkriptnyelv használatával és általában minden tesztfutást naplóznak • Teszttámogató szoftverkörnyezet/egységteszt keretrendszer eszközök – Elősegítheti a komponensek vagy egy rendszer részeinek tesztelését úgy, hogy szimulálja a környezetet, melyben a tesztelés tárgya futni fog. Mindezt helyettesítő objektumokkal teszik. (virtuális gépek) • Teszt összehasonlító eszközök – Meghatározzák a fájlok, adatbázisok vagy teszteredmények közötti különbségeket. A teszt összehasonlító eszközök általában dinamikus összehasonlító eszközöket tartalmaznak, a végrehajtás utáni összehasonlítás elvégezhető külön összehasonlító eszközzel is. • Lefedettség mérő eszközök – Lehetnek beavatkozók, vagy nem beavatkozók. A kód lefedettség mérő eszközök egy tesztkészlet által adott típusú kódstruktúrák végrehajtását mérik százalékosan (pl. utasítások, elágazások vagy döntések, modul- vagy függvényhívások). • Biztonsági eszközök – A szoftver biztonsági karakterisztikájának kiértékelésére használják. Ez magában foglalja a szoftver adatbiztonságát, adat-integritását, hitelesítését, engedélyezését, rendelkezésre állását és válaszmegtagadásait.

55 Szoftvertesztelés Teljesítmény és felügyelet eszközei • Dinamikus elemző eszközök – Csak a szoftver futása alatt nyilvánvalóvá váló hibákat találják meg, olyanokat, mint: időbeli függőségi viszonyok, vagy memóriaszivárgások. Általában a komponens, vagy komponens integrációs tesztnél használják, valamint köztes rétegű teszteknél. • Teljesítménytesztelési/terheléses tesztelési/stressz teszt eszközök – Felügyelik, hogy egy rendszer hogyan viselkedik különböző szimulált használati körülmények között majd erről jelentést készítenek. A terhelés szimulálása virtuális felhasználók létrehozásával érhető el, akik különböző tranzakciókat hajtanak végre, különböző tesztgépeken elosztva. Ezeket általában terhelés generátornak nevezik. • Felügyeleti eszközök – A felügyeleti eszközök folyamatosan elemzik, ellenőrzik a speciális rendszer erőforrásokat, továbbá jelentéseket készítenek róluk, illetve a lehetséges szervízelési problémáknál figyelmeztetéseket adnak.

56 Köszönöm a figyelmet! Varga Gábor Senior Software Test Engineer


Letölteni ppt "Szoftvertesztelés 2013. május 7.. Szoftvertesztelés Bevezető • Jelen előadás anyaga az International Software Testing Qualifications Board (ISTQB) és."

Hasonló előadás


Google Hirdetések