Nincs tökéletes program, csak még nem találtuk meg a hibát!

Slides:



Advertisements
Hasonló előadás
T ESZTELÉS. C ÉLJA Minél több hibát találjunk meg! Ahhoz, hogy az összes hibát fölfedezzük, kézenfekvőnek tűnik a programot az összes lehetséges bemenő.
Advertisements

H IBAKERESÉS, HIBAJAVÍTÁS. H IBAJELENSÉGEK Szintaktikai hiba:  Csak értelmezés esetén fordul elő, hiszen a fordítóprogramok korábban, még a fordítási.
Készítette: Kun Béla.  Operációs rendszernek nevezzük a számítástechnikában a számítógépeknek azt az alapprogramját, mely közvetlenül kezeli a hardvert,
Hatékonyságvizsgálat, dokumentálás
Kutatási terv bemutatása: diszkriminációtesztelés a gyakorlatban
Hardver alapok I. 10. osztály.
A szoftver minősége A szoftverfejlesztési folyamat azt igényli, hogy a fejlesztők és felhasználók ugyanazokat a minőségi jellemzőket használják a szoftver.
Rendszertervezés GIMP.
Clarity üzleti reggeli Budapest, Le Meridien február 19.
Rendszerfejlesztés gyakorlat - © Fülöp Lajos
MINŐSÉGBIZTOSÍTÁSI INFORMÁCIÓS RENDSZEREK III. FORRÁS: HOMONNAY GÁBOR SE, 2008 DÉRI ZOLTÁN GYTK, SE
Rendszerfejlesztés.
Az integrált áramkörök (IC-k) tervezése
Fontosabb fogalmak Képesség :
Az ötlettől a projekttervig
A webes tesztelés jövője
Validálás & verifikálás
Szervezeti formák.
OSI Modell.
Ez a dokumentum az Európai Unió pénzügyi támogatásával valósult meg. A dokumentum tartalmáért teljes mértékben Szegedi Tudományegyetem vállalja a felelősséget,
A Neumann-elvű számítógép jellemzői:
SZÁMÍTÓGÉP ARCHITEKTÚRÁK
Előnyök és alkalmazási területek
Programozó matematikus szak 2003/2004-es tanév II. félév
Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Informatikai Tanszék Dr. Kulcsár Gyula egyetemi docens.
Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Informatikai Tanszék Dr. Kulcsár Gyula egyetemi adjunktus.
Funkciópont elemzés: elmélet és gyakorlat
Megvalósíthatóság és költségelemzés Készítette: Horváth László Kádár Zsolt.
Gazdálkodási modul Gazdaságtudományi ismeretek III. Szervezés és logisztika KÖRNYEZETGAZDÁLKODÁSI MÉRNÖKI MSc TERMÉSZETVÉDELMI MÉRNÖKI MSc.
Regresszióanalízis 10. gyakorlat.
Szervezetfejlesztési Program
Szoftvertechnológia Ember-gép rendszerek. Mit értünk rendszer alatt? Kapcsolódó komponensek halmaza – egy közös cél érdekében működnek együtt A rendszer.
Szoftvertechnológia Rendszertervezés.
WEB MES (webes gyártásirányító rendszer) Kiss Miklós (G-5S8)
A számítógép jelentősége a hétköznapokban
Titokzatos vásárlók.
A LOGISZTIKAI RENDSZEREK MINŐSÉGBIZTOSÍTÁSA
Hálózati és Internet ismeretek
Adatfolyam modellezés az SSADM-ben
Operációs Rendszerek II.
Anyagadatbank c. tárgy gyakorlat Féléves tematika Adatbázis alapfogalmak, rendszerek Adatmodellek, adatbázis tervezés Adatbázis műveletek.
Budapesti Műszaki Főiskola Neumann János Informatikai Főiskolai Kar A Műszaki Tervezés Rendszerei 2000/2001 tanév, I. félév 9. előadás Műszaki tervezőrendszerek.
Környezetközpontú irányítása rendszerek MSZ14001.
HEFOP hét: az ISO 9001:2008-es szabványnak megfelelő minőségirányítási rendszer II. rész A diákhoz itt kellene beszúrni a tanári magyarázatokat.
Programtesztelés. Hibák keletkezésének okai nem egyértelmű vagy hiányos kommunikáció fejlesztés közben maga a szoftver bonyolultsága programozói (kódolási)
3.2. A program készítés folyamata Adatelemzés, adatszerkezetek felépítése Típus, változó, konstans fogalma, szerepe, deklarációja.
Controlling feladata A controlling időbeli dimenziói: 1. Stratégiai
Rendszertervezés Alapfogalmak; Az informatikai rendszer
Kulturális Projekt Ciklus Menedzsment A kultúra gazdaságtana
Termelő-fogysztó modell. A probléma absztrakt megfogalmazása: informális leírás. Adott egy N elemű közösen használt tároló, N  1. Adott a folyamatoknak.
Elektronikus tanulási forráskezelő keretrendszer, kompetencia-fejlesztő program adatbázis létrehozása Calderoni program.
Funkciós blokkok A funkciós blokkok áttekintése Az alkalmazás előnyei.
Programozás, programtervezés
Minőségbiztosítási ismeretek
Visegrád, Könyvvizsgálat, Minőség-ellenőrzés és
Megbízhatóság és biztonság tervezése
Munkakörelemés és –tervezés röviden
CMMI - VALIDÁCIÓ Suba Gergely.
Iskolai számítógépes hálózat bővítése Készítette Tóth László Ferenc.
2. Operációs rendszerek.
PIC mikrokontroller.
Continuous delivery: cél a működő szoftver. Forráskód és értéke A műszaki adósság és a csődhelyzet „Kódjátszma”: irány a kiváló minőség A kód újraírásának.
Continuous delivery: cél a működő szoftver
A ROM ÉS A BIOS. K ÉSZÍTETTE R ELL P ATRIK A ROM A ROM egy olyan elektrotechnikai eszköz, amely csak olvasható adatok tárolására alkalmas memória. Tartalma.
A programozás módszertana. Monolitikus programozás Egyszerű feladatok - egyszerű programok Egy program – egy programozó Nincs belső struktúra, lineáris.
A könyvtári integrált rendszerek statisztikai moduljának használata
Istvan Simon, CEO & Founder
Informatikai rendszerek lassulása - a tervszerű archiválás hiánya?
A PDCA elv alkalmazása az információvédelmi irányítási rendszerekben 3
Kutatási terv bemutatása: diszkriminációtesztelés a gyakorlatban
Előadás másolata:

Nincs tökéletes program, csak még nem találtuk meg a hibát! Szoftvertesztelés Nincs tökéletes program, csak még nem találtuk meg a hibát!

A tesztelés a programrendszer működési helyességének és hatékonyságának vizsgálati szempontjait, feladatait és a munkavégzés módját meghatározó tevékenységek összességgének szisztematikus végrehajtása. A szoftvertermékek működését két különböző vonatkozásban kell vizsgálni: verifikáció validáció

A verifikáció az a folyamat, amelyben igazolást nyer az a tény, hogy a szoftver egy fejlesztési fázisban teljesíti mindazokat a követel­ményeket, amelyeket az előző fázisban specifikáltak. A validáció a szoftvernek olyan irányú vizsgálata és kiértékelése, amiben eldől, hogy a termék minden szempontból teljesíti-e a felhasználói követelményeket.

funkcionálisan megfelelő működés megfelelő teljesítmény Egy biztonságkritikus rendszer esetében például a következőket kell bizonyítani: funkcionálisan megfelelő működés megfelelő teljesítmény a biztonsági követelmények kielégítése. A verifikáció és validáció együtt kezelendő, teljes összhangban. Ezt a tényt a széles körben elterjedt „V & V” eljárás elnevezés is kifejezi. A két fogalmat azonban néha összekeverik, annak ellenére, hogy lényegesen eltérő tevékenységeket jelölnek.

Tesztelési folyamat

A három csoport feladata: A forráskód-teszt a forrásprogramok verifikációs ellenőrzésére szolgál (modul­tesztnek is nevezik). Az integrációs teszt a modulok, illetve a magasabb szintű programegységek egységes működési képességét vizsgálja. A felhasználói tesztekkel a termék alkalmazói vizsgálják a rendszert

A forráskód-teszt folyamán a programozóknak az alábbi tesztelési feladatokat kell végrehajtaniuk: Az interfészteszt vagy blackbox teszt (feketedoboz-teszt) feladata annak vizsgálata, hogy a program egy adott bemenetre az elvárt kimenetet szolgál­tatja-e. A teszteléshez olyan inputadatokat kell választani, melyekkel nagy valószínűséggel kiszűrhetők a programhibák. A tesztelt elem akkor fogadható el, ha a tesztesetekben specifikált eredményt adja. A struktúrateszt vagy whitebox teszt (fehérdoboz teszt) a program-struktúra megvalósításának korrektségét vizsgálja. A tesztelés leellenőrzi az utasítások végrehajtását. Úgy kell összeállítani a teszteseteket, hogy minden utasítás legalább egyszer végrehajtódjon. Azt a mértéket, amely kifejezi, hogy minden utasítás végrehajtásra kerül-e, a teszt lefedettségi mértékének nevezik. Az útvonalteszt szorosan kapcsolódik a struktúrateszthez. Célja olyan teszt­esetek összeállítása és végrehajtása, amellyel a program összes útvonala bejárható, vagyis a párhuzamos műveletek, elágazások és a szinkronizáció teljes egységben ellenőrizhető. A határesetek tesztje a program viselkedésének vizsgálata szélsőséges körül­mények, szokatlan szituációk, szándékosan generált hibák környezetében. A teszt alkalmas a hibadiagnosztizálási és –javítási, valamint a kivétel-kezelési képességek felmérésére.

A tesztet két irányból célszerű elvégezni: Integrációs teszt A tesztet két irányból célszerű elvégezni: A top-down integrációs teszt a funkciók hierarchiájának legmagasabb szint­jéről (főprogram) indul ki, és végighalad az összes lehetséges ágon, kontrol­lálva annak működését, célja a rendszer vezérlési folyamatainak ellenőrzése. Ebben a szemléletben a a vezérlőmodul teszt-drájverként működik, és ellenőrzi az összes almodul működését, az egyes almodulok ellenőrzése a már ellenőrzöttek helyettesítésével történik, a tesztelés folyamata a már beintegrált modulok alapján zajlik, a teszt akkor fejeződik be pozitív eredménnyel, ha az összes útvonal minden modulja hibátlanul viselkedett.

A bottom-up integrációs teszt során a modulok együttműködésének vizsgálatát alulról felfelé, az elemi modulokból kiindulva végezzük, és a különböző hierarchia-útvonalakon keresztül eljutunk a legmagasabb szintre, a rendszer szintjére. Az ellenőrzést az alábbi lépések szerint célszerű végezni: az egymáshoz tartozó legalsó szintű modulokat önálló alfeladat vezérlésére képes egységekbe (cluster) kell integrálni, ellenőrizni kell a modulok I/O információit tesztprogram alkalmazásával, a tesztelő program eltávolítása után egy szinttel feljebb meg kell ismételni az ellenőrzést egészen a legmagasabb szintig.

Az integrációs teszt legmagasabb szintje a rendszerteszt, mely a fejlesztett alkal­mazás integritását teljes egészében vizsgálja. A legfontosabb feladatok az alábbiak: Funkcionális tesztelés Installációs teszt A rendszer telepítésének tesztelése különböző eshetőségek (külön­böző hardver-szoftver konfigurációk, feltételek) esetén. Általános funkcionális teszt A rendszer működésének vizsgálata normál működés esetén. A teszt során ellenőrizzük, hogy a rendszer funkciói az elvártnak megfelelően működnek, a teszt során a kívánt eredményeket kapjuk. Szélsőérték funkcionális teszt A rendszer működésének vizsgálata szélső bemeneti/kimeneti értékek esetén. A teszt során ellenőrizzük, hogy a rendszer funkciói az elvárt­nak megfelelően működnek, a teszt során az elvárt eredményeket kapjuk. Konfigurációs teszt A rendszer funkcionalitásának tesztelése eltérő hardver/szoftverfelté­telek mellett. Mennyiségi teszt A rendszer funkcionalitásának tesztelése nagy mennyiségű bemenő, kimenő, ill. adatbázis adat esetén. -Biztonsági teszt A szoftver jogosultsági rendszerének tesztelése ellenőrzi, hogy a rendszer adataihoz csak az elvárt felhasználók férnek-e hozzá

Teljesítménytesztelés Általános teljesítményteszt A rendszer működésének sebességét összevetjük az elvárt értékekkel. A teszt segítségével fényt deríthetünk a rendszernek a sebesség szempontjából kritikus pontjaira, szűk keresztmetszeteire. Referencia teljesítményteszt A rendszer működésének sebességét egy másik, a tesztelt rendszerhez hasonló funkcionalitású rendszer sebességével vetjük össze. Terheléses teljesítményteszt A rendszer sebességének vizsgálata különböző munkaterhelések esetén. A teszt során rögzítjük a terhelés mértékét (pl. felhasználók, tranzakciók száma), valamint a rendszer működési sebességét az adott terhelés alatt. Konkurencia teljesítményteszt A rendszer teljesítményének vizsgálata abban az esetben, ha a rend­szernek többszörösen kell ugyanahhoz az erőforráshoz (pl. ugyanahhoz az adatrekordhoz) hozzáférnie. Sokk teljesítményteszt A rendszer működésének vizsgálata extrém körülmények között. Ezek az extrém körülmények lehetnek a tervezettnél nagyobb terhelések, kevés memória/erőforrások, hardver problémák, áramszünet, stb.

Felhasználói tesztek A fejlesztés alapvető célja a felhasználói igények kielégítése, ezért fontos, hogy a felhasználót is bevonjuk a szoftver minősítésének folyamatába. Ha erre mód van, oda kell adni a rendszert rövid próbaüzemre a leendő üzemeltetőnek. Az éles próbaüzemben hamar kiderülhetnek a valós adatokkal tesztelt rendszer hibái, hiányosságai, és ezek még időben kijavíthatóak.

A felhasználó által végezhető tesztek lehetséges típusai: Az alfa-, bétatesztek félig, vagy majdnem kész szoftverek kipróbálását szolgálják. A felhasználók a szoftver kipróbálása közben/után jelzik a fejlesztőknek a próbaüzem közben előforduló problémáikat. Az alfateszt esetében az alkalmazás még nincs teljesen kidolgozva, a bétateszt során már egy korrigált alfaverzió újrapróbálásáról beszélhetünk. A kezelhetőségi/támogatási tesztekben a felhasználók élesben használják a fejlesztők által már tesztelt programrendszert, és meg tudják állapítani, hogy mennyiben könnyen kezelhető, mennyiben támogatja, és könnyíti meg munkájukat. Az elfogadási teszt célja annak megállapítása, hogy a szoftverrendszer a körülményeknek megfelelően működik-e. A rendszer működésének ellenőrzése nem szimulált tesztadatokkal történik, hanem valós környezetben tényleges adatokkal. Evvel a teszttel feltárhatóak azok a működésbeli problémák, amelyeket az informatikai szakemberek a megbízó szakterületének területén való jártatlanságuk hiánya miatt nem fedeztek fel.