Szoftverarchitektúra - implementáció tervezése -
|
|
- Zsombor Hajdu
- 7 évvel ezelőtt
- Látták:
Átírás
1 Szoftverarchitektúra - implementáció tervezése - Architektúra Architektúra: strukturálisan fontos elemek és ezek kapcsolata. 1
2 Architektúra központú A rendszer architektúrája (egy adott pillanatban) a rendszer alapvető komponenseinek szerveződése, melyek egymással meghatározott felületeken keresztül kommunikálnak, és hierarchikus szervezésű, egyre finomabb, egymással szintén megfelelő, alacsonyabb szintű felületeken keresztül kommunikáló komponensekből épülnek fel. Architektúra - nézet Egy architektúrát több nézet szerint lehet leírni. A különböző módszertanok különböző nézeteket javasolnak: Statikus nézet: rendszert alkotó elemek, kapcsolatok. Dinamikus nézet: a rendszer időbelisége. Funkcionális nézet: a rendszer funkcionalitása, a rendszer milyen adatokat milyen algoritmusok alapján generál. 2
3 Architektúra az alkalmazás jellege alapján Az objektumok csoportosítása az MVC koordináta rendszer alapján Model-View-Control Smalltalk vezette be Sztereotípus Minden jól tervezett objektum valamelyik koordináta fele húz. MVC koordináta rendszer Koordináták: Határ, Entitás, Control objektumok. Ez a gondolatmenet általánosítható alkalmazásokra, egy-egy alkalmazás olyan mint egy nagy objektum. 3
4 MVC koordináta rendszer Határ: Felület dominenciájú alkalmazások: Jellegzetes desktop alkalmazások, szövegszerkesztők, vizuális felhasználói környezetek stb. Entitás: Klasszikus információrendszerek Fő feladatuk az adatkezelés Control Algoritmus dominenciájú alkalmazások Tudományos, műszaki számításokat végző alkalmazások Az architektúrát az algoritmusok befolyásolják Ritka a gyakorlatban. Mi a szoftverarchitektúra? A rendszert felépítő alrendszerek (szoftver komponensek) kerete alrendszerek meghatározása alrendszerek tulajdonságai Vezérlési, valamint kommunikációs kapcsolataik 4
5 Mi még a szoftverarchitektúra? Magasszintű terv A rendszer átfogó struktúrája több nézet -> több struktúra Komponensek és összekötők összesége Architektúra központú Architektúrális komponensek: A rendszer alapvető működését meghatározó szoftver részek, rendszerszervezési megoldások. A fejlesztés fázisaiban központi szerepet kap a robosztus architektúra: Robosztus = rugalmas, jól tűri a változásokat Az architektúra megalapozása az elsődleges feladat, hiszen ha itt hibázunk, az nagyon sokba kerül. 5
6 A SW architektúra szerepe Az érdekelt szereplők kommunikációjának lehetővé tétele. A korai fejlesztási fázisok döntéseinek támogatása a követelmények tükrében. Nagyléptékű újrafelhasználhatóság elősegítése. A SW architektúra célja Az architektúra célja: átláthatóvá teszi a fejlesztést, könnyebben felismerhetők az újrafelhasználható elemek, átlátható projekt menedzsment, kockázatok csökkentése, lehetővé válik a párhuzamos fejlesztés. 6
7 A SW architektúrák forrása Üzleti és technológiai döntések eredménye Meghatározó a környezet szerepe A fejlesztők céljai és stratégiája által befolyásolt követelmények vezetnek különféle szoftver architektúrákhoz Az architektúra ciklus Az architektúra meghatározó a fejlesztő szervezet szerkezetére Az architektúra befolyásolja a fejlesztő szervezet céljait Az architektúra hatással van a követelményekre A fejlesztés során a fejlesztők tapasztalatokat szereznek architektúráról Bizonyos rendszerek hatással vannak a fejlesztési kultúrára 7
8 Az architektúra ciklus Fejlesztõ szervezet Követelmények Architektúra A rendszer szereplõi Technológiai követelmények A tervezõ tapasztalata Tervezõ/fejlesztõ Rendszer Mitől jó egy architektúra? Kis számú vezető tervező Jól definiált funkcionális követelmények és minőségi jellemzők Jól dokumentált az architektúra Az architektúra értékelésében az összes érintett szereplő részt vesz Kvantitatív minőségi mértékek Inkrementális architektúra implementáció Kevés erőforrás versenyhelyzet a fejlesztés során 8
9 Architektúra elemek Architektúrális minta típus elemek és kapcsolatok, kényszerek pl. kliens-szerver minta Referencia modell standard funkcionális felosztás és adatfolyam megoldások pl. adatbázis kezelő rendszer Referencia architektúra referencia modell leképezése szoftver elemekre pl. ISO OSI architektúra Az architektúra rétegei A rendszer különböző szinten elhelyezkedő elemei rétegekbe sorolhatók. 9
10 Rétegzett architektúra Általánosan használt modell Mit jelent a rétegzettség: Fizikai rétegek (tier): az egyes rétegek különböző futtatható állományokban vannak, ezek a futtatható állományok különböző gépeken helyezkednek el, az egyes futtatható elemek hálózati protokollon keresztül beszélgetnek Logikai rétegek (layer): a forráskód belső tagozódása. Egyirányú a logikai függés: a fizikai rétegzettség feltételezi a logikait, de fordítva nem! Javasolt rétegek Rendszerszoftver réteg. Közép réteg (elosztott komponensek: EJB, CORBA, DCOM). Általános alkalmazási réteg. Felhasználó specifikus alkalmazási réteg (user interfészek). RUP által javasolt. 10
11 Szokásos logikai rétegek Kezelői felület Alkalmazás logika Adatbázis logika Frameworks, middleware, rendszer szoftver Minden, ami kiszolgál. Szokásos logikai rétegek Kezelői felület Csak a megjelenés. Alkalmazás logika Az alkalmazásra jellemző elemek. 11
12 Szokásos logikai rétegek Adatbázis logika Egész szervezetre, egész adatbázisra jellemző, nem alkalmazás függő. Általában egy adatbázison több, különböző célú alkalmazás is dolgozhat (Számlázó-, Megrendelés kezelő-, Raktárkészlet kezelő alkalmazás), amik részben vagy egészében ugyan azokat az adatokat használják és az adatok között vannak olyan összefüggések, amik függetlenek a feldolgozás céljától. Frameworks, middleware, rendszer szoftver Minden, ami kiszolgál. Együttműködés Kliens-szerver architektúra. 12
13 Néhány elterjedt architektúrális modell Osztott adatokra épített architektúra CASE eszközök Kliens-szerver architektúra hálózati, kommunikációs szoftverek Réteg szerkezet architektúra protokoll referencia modellek Funkcionális csőrendszerek Eseményvezérelt rendszerek Osztott adatok Az alrendszerek adatokat cserélnek központi adatbázis saját adatbázisok, explicit adatcsere Közös adatigényű alkalmazások 13
14 Osztott adatok Előnyök nagy mennyiség" adat hatékonymegosztása központi adat kezelés lehetősége Hátrányok minden részrendszerben azonos adatszervezés elosztottság nehézkes Osztott adatok Integrált CASE eszköz 14
15 Réteg szerkezet modell Speciális alrendszer elrendezés Rétegekbe szervezett modulok, szolgáltatások Jól definiált interfészek Inkrementálisan, egymástól elkülönülten fejleszthető rétegek Mesterségesen kialakított rétegek Az OSI modell 7 rétege fizikai réteg adatkapcsolati réteg hálózati réteg szállítási réteg viszony réteg megjelenítési réteg alkalmazási rétegek 15
16 A hoszt Alkalmazási Alkalmazási protokoll B hoszt Alkalmazási Megjelenítési Megjelenítési protokoll Megjelenítési Viszony Viszony protokoll Viszony Szállítási Szállítási protokoll Szállítási Hálózati Hálózati protokoll Hálózati Adatkapcsolati Adatkapcsolati protokoll Adatkapcsolati Fizikai Fizikai protokoll Fizikai Eseményvezérelt rendszerek A rendszer vezérlésén kívülről érkező események határozzák meg a viselkedést Pl. Ha a vállalat eseményvezérelten működik, a felhasználói rendelések közvetlenül meghatározzák a legyártandó termékek számát (a rendelés beérkezése "kiváltja" a gyártás indítását). Eseményvezérelt modell broadcast modell 16
17 Broadcast modell Elosztott alrendszerek integrálása Az alrendszerek előfizetnek azőket érdeklő eseményekre az eseménykezelőnél Események időbeli bekövetkezte ismeretlen A programtervezés jelentősége a végzendő feladatok mennyisége karbantartás tesztelés karban- tartás tesztelés kódolás tervezés programtervezés kódolás Megvalósítás tervezés nélkül Megvalósítás tervezéssel 17
18 A programtervezési módszerek sajátosságai cél az információs domének tervezési reprezentációvá alakítása megoldás szimbólumkészlettel, amely a komponensek, azok viszonyának és az algoritmusnak a leírására szolgál ajánlás az eljárások finomításának és komponensre bontásának végrehajtására szempontokat ad a szoftverminőség biztosításához A Warnier-féle strukturált programtervezési lépések adatszerkezetek tervezése a programszerkezet kialakítása funkcionális leírás tevékenységek programstruktúrákhoz rendelése 18
19 A Lorensen-féle OO programtervezés lépései az alrendszerek adatigényét kielégítő osztályabsztrakciók meghatározása az absztrakciós osztályok jellemzőinek specifikálása az osztályok műveleteinek meghatározása objektumok közötti kommunikáció módjának (üzenetek) specifikációja felhasználói igények leírása scenárióval öröklődés vizsgálata A programtervezés feladatai A programtervezés a korábbi fázisokban kialakított modellek (adat- illetve objektum-modell, funkcionális modell és a rendszer viselkedését leíró dinamikus modell) alapján történik. A programspecifikációt lépései: adat-tervezés: az adatstruktúrák és ábrázolási módok specifikálása architektúra tervezés: a programrendszer egyes komponenseinek, azok egymáshoz való viszonyának meghatározása folyamatok (procedures) tervezése a szerkezeti komponensek működési folyamatokhoz illesztésének specifikációja 19
20 Dinamikus Adat/objektum modell modell adatok tervezése Funkcionális modell Egyéb elvárások, körülmények Programtervezés Az implementációs fázis szakaszai procedurális tervezés Kódolás architektúra-terv Programmodulok Tesztelés tesztelt szoftver-rendszer (integrációs és validitási ellenõrzés) Tervezési alapelvek absztrakció lépésenkénti finomítás modularitás, komponens szemlélet szoftver-architektúra vezérlési hierarchia adatstruktúra és adatfolyam szoftverfolyamatok komponens architektúra információelrejtés 20
21 Modularitás modul, komponens értelmezése beépülési, aktivitási jellemző, vezérlési mód típusok: compile time~, corutin~, conrutin~ definíció: a modul, a komponens a programrendszer legkisebb, önállóan is működőképes, cserélhető, újrafelhasználható egysége, amely interfészeken keresztül csatlakozik a környezetéhez funkcionális függetlenség kohézió (binding), csatolás (link, coupling) A Architektúra adatfolyamdiagram Cél: az architektúra-komponensek B 0. szint közötti adat- és vezérlési információk áramlásának, az üzenettovábbítási folyamatoknak a szemléltetése 1. szint 21
22 Objektumorientált fejlesztőkörnyezet - komponensdiagram Alkalmazások, kliens oldal user interface (felhasználói felület komponens) TCP/IPv6 protokoll Rendszer szerver object database (objektum adatbázis) Fejlesztõ rendszer CASEeszközök, alkalmazásgenerátorok Projectmanagement repository domain (fejlesztési adatbázis) rendszerszolgáltatások A programtervezés feladatai adat- és objektumtervezés architektúra tervezés bemeneti, kimeneti információk, működési, vezérlési funkciók, tesztelési feladatok folyamat-terv készítése működési algoritmus fejlesztőkörnyezet kiválasztása kódolás 22
23 A program-architektúra tervezés feladatai a rendszer bemeneti információinak meghatározása felhasználói interfészek tervezése a rendszer működését vezérlő funkciók terve: menüszerkezet architektúra kontextus diagram: információ forrása,típusa, kommunikációs útvonal szolgáltatások, outputok specifikációja karbantartási, diagnosztikai és tesztelési tervek A működési algoritmus tervezése folyamatábra Warnier-Orr diagram Jackson ábra avagy struktúra diagram Nassi-Shneidermann avagy Chapin-Chart ábra komponensdiagram vezérlési struktúradiagram lásd szemléletesen: 23
24 Folyamatábra szimbólumok start/stop kapcsolódási pont manuális mûvelet funkció, mûvelet általános adat szimbólum forrás-dokumentumvagy nyomtatott output on-line input Folyamatábrakészítés START Input a,b c= 2a+ 5b d= 7ab-4b/a Folyamatábra minta szalag állomány elõkészítõ funkció lemez állomány rutinmûvelet, könyvtárprogram logikai döntés, elágaztatás on-line output mûveletek sorrendje adatkommunikáció c= d? igen x= 5b-3d nem x= 4a+ 7c x= d+ a? igen kiír a,b,x nem END Műveleti struktúrák folyamatábrával Mûveletek szekvenciája Aszelekció logikai struktúrája Iteratív mûveletek ciklikus szerkezetei hátultesztelõ elõltesztelõ utasítás IF... nem feltétel igen ciklusutasítások ciklusutasítások utasítás ELSEág THEN ág DOUNTIL felltétel igen nem DOWHILE felltétel igen nem DOUNTIL DOWHILE 24
25 JACKPR o a= 1? a«0? o o a= 9999? * end: k= 50 o o a= 1000? különben vege k= k+ 1 k= 25 k= k*2 a= a*k+ 1 Jackson-féle struktúradiagram Chapin-Chart szerkezetek Szekvencia IF THEN... ELSE... szelekció Iteráció szemléltetése CASEszelekció 1. feladat 2. feladat 3. feladat feltétel hamis igaz ELSE THEN ág ág ciklus feltétel DOWHILE ciklusmag REPEAT UNTIL ciklusmag ciklus feltétel CASEfeltételek érték érték... utas. utas
26 Vezérlési struktúradiagram sorrendiség S; S; S; döntés (if... then... else...) S; if Cthen else S; S; S; S; S; end if case S; S; S; case Dis when C1= > S; S; end case when C2 = > S; S; while ciklus S; while C; S; S; S; end C; S; Komponens architektúra "A" modul "A1" modul "A2" modul "A3" modul "A31" modul "A32" modul 26
27 Kódolás A számítógépes program készítése a végrehajtandó utasítások meghatározott sorrendben írását jelenti a rendelkezésre álló nyelven. Az a mód azonban, ahogyan a programozó a nyelvi lehetőségeket használja a program intelligenciájának mértéke Kernighan, Tesztelés 27
28 A tesztelés szükségessége, jelentősége Tesztelés kiértékelése Elfogadási, rendszer - és terhelési teszt Modul- és integrációs teszt Bevezetés, üzemeltetés, karbantartás, minőségbiztosítás M egvalósítás Célkitűzés, problémadefiniálás Elemzés, követelményspecifikáció Inkrementális tervezés Tesztelés célja Helytelen szemlélet: a szoftver hibamentességének bizonyítása, ill. a specifikált tulajdonságok megvalósításának bizonyítása. Helyes felfogás: a szoftvertesztelés a fejlesztett szoftver végrehajtása azzal a céllal, hogy a benne levő hibákat, ill. a specifikációtól eltérő viselkedését felderítsük. 28
29 Szoftverrendszerek tesztelése A szoftver fejlesztés célja: a specifikációban leírt követelményeket kielégítő szoftver készítése. Fejlesztés során különböző ellenőrző, elemző lépéseket kell végrehajtanunk a cél elérése érdekében. A vizsgálat során két egymástól eltérő célunk lehet: Vizsgálhatjuk azt, hogy a megfelelő terméket készítjük-e. Ebben az esetben validációt végzünk. Vizsgálhatjuk azt, hogy a terméket jól készítjük-e. Ebben az esetben verifikációt végzünk. V & V: verifikáció és validáció A verifikáció: azt vizsgáljuk, hogy a fejlesztés során egymás után végrehajtott fejlesztési lépések során előállított szoftver (ill. annak terve) megfelel-e a specifikációban rögzített elvárásoknak, tulajdonságoknak. A verifikáció során a vizsgálat alapja mindig valamilyen fejlesztés során előállított információ (termék). 29
30 V & V: verifikáció és validáció A validáció: általánosabb folyamat, Azt vizsgáljuk, hogy az elkészített termék megfelel-e a megrendelő elvárásainak. A validáció tehát magában foglalja a specifikáció ellenőrzését is. V & V: verifikáció és validáció A verifikáció, és a validáció végrehajtására használható technikák: Szoftver átvizsgálás. Szoftvertesztelés. 30
31 V & V: verifikáció és validáció Szoftver átvizsgálás: A fejlesztés során előállított termékek (modellek, kód, stb.) statikus elemzése, ami lehet manuális vagy automatizált. Manuális vizsgálatra példa a kód-review különböző formái, automatizált vizsgálatra példa a UNIX rendszerekben használt lint (splint) eszköz, mely C programokat elemez és felhívja a fejlesztő figyelmét a potenciálisan hibás, vagy hibát eredményező kódrészletekre. V & V: verifikáció és validáció Szoftvertesztelés: Az implementált szoftver futtatása tesztadatokkal, annak kimeneteinek, viselkedésének, ill. teljesítményének megfigyelése, összevetése a követelményekkel, azzal a céllal, hogy a benne levő hibákat felderítsük. Ezt nevezzük dinamikus elemzésnek, ill. dinamikus verifikációnak. 31
32 Statikus és dinamikus verifikáció alkalmazása szoftverfejlesztés során Követelmények 1. Analízis & Tervezés Rendszer terv (pl. UML diagrammok) statikus verifikáció (review) 2. Terv verifikációja Verifikált rendszer terv (pl. UML diagrammok) 3. Implementáció Implementált rendszer (pl. C++ code) dinamikus verifikáció (szoftvertesztelés) 4. Tesztelés Tesztelt rendszer Szoftvertesztelés alapsémája A tesztelés lényege összehasonlítás: A tesztelt szoftver (software under test, SUT) kimeneteit, működését, viselkedését összehasonlítjuk valamilyen referenciával. Az összehasonlítás alapjául szolgáló referencia leírása sok forrásból származhat, attól függően, hogy a szoftverfejlesztés mely stádiumában hajtjuk végre a tesztelést. Származhat az információ a specifikációból nyert adatokból, prototípus szoftver leírásából/megfigyeléséből, vagy a fejlesztés során előállított, rendszer viselkedését leíró modellből. 32
33 Szoftvertesztelés alapsémája Referencia (követelmény specifikáció, prototípus, rendszermodell stb.) referencia kimenet bemeneti sorozat viselkedés, állapot megfigyelése Értékelés (viselkedés, kimenetek összehasonlítása) eredmény Tesztelt szoftver software under test, SUT SUT kimenet Szoftvertesztelés típusai Két típus az alapján, hogy mi a tesztelés célja: Hiányosság és hiba tesztelés: A tesztelés célja a fejlesztés során bekerült specifikációtól eltérő, vagy nem megvalósított működés kiszűrése. Statisztikai tesztelés: A program teljesítményének, megbízhatóságának vizsgálata általában valós bemenetek felhasználásával. 33
34 Tesztelés folyamata A szoftver tesztelése különböző lépésekre bontható. A szoftverfejlesztés korai szakasza, teszt tervezése: definiáljuk, milyen módszerekkel és milyen lépésekben végezzük a szoftver tesztelését. A tesztelés következő lépése a tesztesetek definiálása. Tesztesetnek nevezzük egy adott hiba felderítésére szolgáló tesztet. A teszteset definíciója tartalmazza: a tesztelés során használandó bemeneteket, a tesztelt szoftver teszteset végrehajtásához szükséges állapotának leírását (esetlegesen az állapot beállítás módját), a helyes működés során keletkező referencia kimeneteket, ill. a teszteset hibamentes végrehajtása során történő viselkedésének (pl. bejárt állapotok) leírását. Tesztelés folyamata Ha egy teszteset alkalmas arra, hogy annak végrehajtásával egy adott hiba meglétét, ill. hiányát felderítsük, akkor azt mondjuk, hogy az adott teszteset (ill. az adott teszt) a kérdéses hibát lefedi. Ennek megfelelően beszélünk tesztesetek (tesztek), ill. teszteset halmazok (teszthalmazok) hibafedéséről. Tesztgenerálásnak azt a folyamatot nevezzük, mely során a teszteseteket előállítjuk, definiáljuk. A tesztgenerálás célja a minél nagyobb hibafedésű teszthalmaz előállítása. 34
35 Tesztelés folyamata A tesztesetek definiálása és szoftver implementálása után történik: a tesztesetek végrehajtása, az eredmények értékelése, elemzése, mely a tesztelés utolsó fázisa. A szoftverben feltételezhetően előfordulható hibák leírását nevezzük hibamodellnek. SW hibamodell Hibák: specifikációs hibák, tervezési hibák, kódolási hibák... Általános probléma: Nem lehet olyan leírását adni a hibáknak, ami általánosan használható. Nehéz a tesztelés hatékonyságát mérni. 35
36 Tesztelési megközelítések A tesztelés során a tesztelt rendszert különböző módon lehet kezelni, mely alapvetően más, és más módszereket fog eredményezni a tesztesetek előállítására. Két alapvető megközelítés létezik: Funkcionális tesztelés Strukturális tesztelés Funkcionális tesztelés A tesztelő nem veszi figyelembe a tesztelt szoftver belső felépítését. Kizárólag a rendszer specifikációja alapján végzi a tesztelést. Az ilyen szemléletben történő tesztelést szokták még specifikáció alapján történő tesztelésnek is hívni. Mivel a tesztek tervezése, ill. végrehajtása során a tesztelés alatt álló szoftver belsejébe nem látunk bele, szokásos az ilyen technikákat fekete doboz (black box) tesztelésnek is nevezni. 36
37 Strukturális tesztelés A funkcionális tesztelés ellentéte. A tesztelés a szoftver a specifikációban megadott funkciót megvalósító program szerkezete alapján történik. Mivel a tesztelő belelát a szoftver belső működésébe szokásos az ilyen technikákat fehér doboz (white box) tesztelésnek is nevezni. Strukturális tesztelés esetén a program vezérélési szerkezetét modellezzük és a tesztelő a vezérlési szerkezet minden ágát, a program különböző bemenetek esetén végrehajtódó részét végrehajtva vizsgálja annak működését. Funkcionális tesztelési módszerek Az ekvivalencia partícionálás egy természetes tesztelési megközelítés formalizálása. Abból indul ki, hogy minden hibához lehetőleg csak egy tesztesetet definiáljunk. Ennek érdekében a szoftver bemeneti adatainak minden kombinációját tartalmazó képzeletbeli halmazt olyan részekre (partíciókra) bontja, melyek mindegyike más és más hiba felderítésére alkalmas. A bemenetek partícionálása után, a tesztesetek definiálásakor a tesztelő az egyes partíciókból egyet-egyet választ. 37
38 Funkcionális tesztelési módszerek A határérték analízis: az ekvivalencia partícionálás finomítása. Míg az ekvivalencia partícionálás során minden ekvivalencia osztályból csak egy, az osztályt reprezentáló bemenetet választottunk, addig a határérték analízis definiálja, hogy melyik bemenetet (vagy bemeneteket) válasszuk az ekvivalencia osztályból. Azt mondja, hogy ha két partíció határos, vagyis a bemenetek természetes sorrendjében egymás után következő bemeneteket tartalmaz, akkor ezeket a partíció határán levő értékeket célszerű a tesztesetekben használt bemenetnek választani. Egy partícióból, ha több más partícióval határos, akár több bemenetet is használhatunk. Strukturális tesztelés A tesztelő nem állít fel explicit hibamodellt a felderítendő hibákról, kizárólag a hibamentes program működését, vezérlési szerkezetét modellezi a folyamat vezérlési gráf (Control Flow Graph - CFG) segítségével. A strukturális tesztelés alapfeltételezése szerint a programban létrejövő hibák valamilyen módon befolyásolják a program vezérlési szerkezetét, mely a működést leíró folyamat vezérlési gráf gráfpontjainak, ill. éleinek hibás (nem megengedett) bejárását jelenti. A használt hibamodell tehát egy folyamat vezérlési gráf alapján felállított implicit hibamodell. 38
39 Tesztelés menete ST esetén Tesztgenerálás: Teszt bemenetek generálása valamilyen mértékszám alapján. Teszt végrehajtás: Program egy vezérlési ágának végrehajtása. Eredmények összehasonlítása a specifikációban rögzítettel. Strukturális tesztelés előnyei Hibák keresése anélkül, hogy tudnám, milyen hibákat is keresek konkrétan. Matematikai modell: tesztelés hatékonyságának számszerű mérése. ST felhasználási területei: Vezérlés intenzív alkalmazások. Tervezési hibák felderítése. Elérhetetlen (dead) kódrészek felderítése. 39
40 Strukturális tesztelés módszerei Vezérlési szerkezet modellezése Programok vezérlési bonyolultsága Egyszerű strukturális tesztgenerálás Vezérlési szerkezet modellezése Folyamat vezérlési gráf (FVG) Control Flow Graph (CFG) Gráf pontok: utasítások + végpont. Egymás után végrehajtott utasításokat gráf él köti össze. Utasítások típusa: Szekvenciális utasítás. Elágazás utasítás (predicate statement). 40
41 CFG A CFG egy gráf modell. A gráf pontok az utasításoknak feleltethetők meg. Az utasításokat reprezentáló gráf pontokon kívül a program kezdetét, belépési pontját és végét, kilépési pontját is egy-egy gráf pont reprezentálja. A gráf származtatása igen egyszerű, az egymás után végrehajtható utasításokat egy-egy irányított gráf él köti össze. CFG A gráf-pontok két típusa: Egyszerű (szekvenciális) gráf pont, amelyből egyetlen gráf él indul ki, és egy szekvenciális utasítást reprezentál. Elágazás gráf pont, amelyből egynél több gráf él indul ki, és egy elágazás utasítás (predicate statement) feleltethető meg neki. A CFG esetén az egyszerűbb kezelhetőség miatt általában a kimenő élek számát kettőben szokták limitálni. Az elágazás utasításban mindig szerepel egy feltétel, mely meghatározza, hogy az utasítás végrehajtásakor melyik következő utasítás hajtódik végre. 41
42 CFG START END Programok vezérlési bonyolultsága A programok vezérlési szerkezetének bonyolultsága igen eltérő lehet. A programok vezérlési szerkezetének bonyolultságát jellemző mérőszám, az ún. ciklomatikus komplexitás (CK, Cyclometric complexity). 42
43 Programok vezérlési bonyolultsága Ciklonometrikus komplexitás (CK) (Cyclonometric complexity) Független út: Olyan gráf út, amelyben létezik olyan pont v. él, amely más útnak nem eleme. Ciklonometrikus komplexitás definíciója: A FVG-ben található független gráf utak maximális száma. CK számítása Jelölés: G: gráf; V(G): CK ; E: élek száma; N: pontok száma; P: elágazás utasítások száma. V(G)= E-N+2 V(G)=P+1 (bináris elágazások esetén) 43
44 CK számítási példa E=11 N=9 V(G)=E-N+2=11-9+2=4 begin 1 2 P=3 V(G)=P+1=3+1= end Egyszerű strukturális tesztgenerálási algoritmus CFG generálása a kód alapján. CK számítása az CFG alapján. Független utak maximális (CK darab utat tartalmazó) halmazának generálása. Bemenetek generálása a független utak bejárásához. 44
45 Problémák tesztgenerálás során AZ CFG: ciklikus, vagyis kört tartalmaz, így elvben a végtelen sok út generálható az adott CFG-hoz. Nem generálható olyan bemeneti kombináció, amely egy adott út bejárását eredményezné az CFGben. Teszt hatékonyságának mérése A strukturális tesztelés alaposságának jellemzésére mértékszámokat lehet használni. A mértékszám egy arányszám: megmutatja, hogy a kiválasztott szempont szerint a tesztelhető elemek (egységek, tételek) mekkora részét teszteltük le, a korábban bevezetett terminológiát használva a feltételezett hibák mekkora részét fedtük le. 45
46 Mértékszámok Utasítás lefedettség: Az utasítások mekkora hányadát hajtottuk végre teszteléskor. Ág lefedettség (döntés lefedettség): A CFG ágainak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor. Út lefedettség: A CFG-ban található utaknak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor. SW tesztelés végrehajtása SW tesztelését több fázisban hajtják végre. Első fázis a modul tesztelés (unit testing). Integrációs tesztelés. Rendszerteszt. Míg az első két fázis tipikusan verifikáció, addig a rendszertesztet általában validálására használják. 46
47 Modul tesztelés Unit testing. A fázisban csak az egyes modulok specifikációját veszik alapul. Különösen munkaigényes és emiatt költséges fejlesztési fázis. Modul tesztelés A szoftvermodulok: önálló specifikációval rendelkező, más moduloktól függetlenül fordítható szoftver egységek. Strukturált program esetén ezek lehetnek eljárások, függvények, ill. azok csoportja, objektumorientált környezetben objektumok, ill. azok halmaza (clustere). 47
48 Modul tesztelés A modulok a kész rendszerben használják egymás szolgáltatásait, pl. az egyik modul meghívja a másik modul adott függvényét. Ekkor azt mondjuk, hogy az egyik modul függ a másik modultól. Modulok függősége grafikusan is ábrázolható. Modulok függősége A modul például függ a B a C és D moduloktól. A B C D E F G H I J 48
49 Modulok függősége A tesztelő elkészíti azon modulok biztosan hibamentesen (a specifikációban leírt módon) viselkedő egyszerűsített változatát, melyektől a tesztelt modul (SUT) függ. A szoftver modulok ilyen egyszerűsített megvalósítását nevezik stub-nak (csonknak). Teszt driver A modulok tesztelése csak úgy történhet, ha azokat működtetjük, azok szolgáltatásait meghívjuk. Ehhez létre kell hozni a megfelelő szoftver környezetet. Teszt driver-nek nevezzük azt a szoftver elemet, mely a tesztelés során a tesztelt szoftvert működteti. 49
50 Teszt driver Feladata: a tesztelt szoftver működtetése, annak bemeneti adatok biztosítása. A szoftver driver általában megvalósítja a kimenetek eltárolását, ill. más, szoftver viselkedését jellemző információ összegyűjtését. Teszt driver A stub-ok, ill. teszt drive-ek készítése: legmunkaigényesebb, így legköltségesebb része a tesztelésnek. Ha egy szoftver minden modulját önállóan szeretném tesztelni, akkor minden elemnek el kell készítenem a stub változatát, ill. minden elemhez készítenem kell egy teszt driver-t. Az ilyen típusú tesztelés az izolációs tesztelés. 50
51 Izolációs tesztelés teszt driver B C D tesztelt modul E stub F stub G stub H I J Tesztelési költségek csökkentése A teszt driver-ek, ill. stub-ok készítése költséges. Ezek készítését részben elkerülhetjük: ha az amúgy is megvalósítandó szoftver moduljaimat használom driver-ként, ill. stub-ként. Feltétlenül be kell tartanom a tesztelés azon szabályát, hogy tesztelés során a szoftvernek csak olyan komponensét használhatom (driver-ként vagy stub-ként), melynek helyes működése biztos, vagyis már átesett a tesztelésen. Két alap technika létezik, a többi lényegében ezek finomítása: top down tesztelés és bottom up tesztelés. 51
52 Top-down tesztelés A teszt driver-ek készítése kerülhető el. Teszt driver-ként mindig azokat a modulokat használom, melyek az adott tesztelés alatt álló modulomtól függenek. Először mindig a hierarchia legmagasabb szintjén álló modulomat kell tesztelni, majd sorban az alatta levő modulokat. Top-down tesztelés A driver (tesztelve) B (tesztelve) C (tesztelve) D tesztelt modul E stub F stub G stub H I J 52
53 Bottom-up tesztelés A teszt stub-ok készítése kerülhető el. Stub-ként mindig azokat a modulokat használom, melyektől az adott tesztelés alatt álló modulom függ. A tesztelést a függőségi hierarchia legalsó szintjén kell elkezdeni azokkal a modulokkal, melyek nem függenek más moduloktól. Ezeket letesztelve léphetünk tovább a hierarchia következő szintjére. Bottom-up tesztelés teszt driver B C D tesztelt modul E (tesztelve) F (tesztelve) G (tesztelve) H (tesztelve) I (tesztelve) J (tesztelve) 53
54 Tesztesetek definiálása Teszteset azonosító: a fejlesztési folyamat teljes menete során ezzel hivatkozhatunk a tesztesetre. Fontos, hogy tényleg ne változzon. Hibajelentések készítésekor, ill. teszt riportok összeállításakor látjuk hasznát. Regressziós tesztelésnél különösen hasznos. A tesztelt szoftver elem azonosítása, ill. a tesztelt funkció, viselkedés azonosítása, leírása. A tesztelt szoftver (SUT) teszteset végrehajtása előtt beállítandó állapotának leírása, szükség szerint a beállítás módja. Tesztesetek definiálása Teszteset végrehajtásához szükséges bemeneti adatok. Elvárt eredmény: hibamentes esetben várt kimenet, állapot, esetleg teljesítmény. Teszteset végrehajtásának előfeltételei: mely tesztesetet kell hibamentesen végrehajtani, ill. mely teszteset által tesztelt funkcióra épül az aktuális teszteset. A tesztelésnél alkalmazott szabványok előírhatnak további jellemzők megadását, pl. a teszteset definiálásakor alkalmazott tesztelési módszert. 54
55 Integrációs tesztelés A rendszer moduljait együtt tesztelik nagy hangsúlyt fektetve a modulok együttműködésére, interfészek vizsgálatára. Rendszerteszt A teljes rendszert valós adatokkal valós környezetben tesztelik. 55
56 Tesztadatok összeállításának szempontjai adatok körének meghatározása: napi adatok szélsőséges adatok tesztelési szintekhez eltérő adatok tesztállományok összeállítása elvárt eredmények meghatározása Tesztelés alapjai (terminológia) teszt driver: tesztelő rutin teszt csonk (stub): Tesztelt egység által használt más egység működését szimuláló rutin. teszt eset: egy adott hiba felderítésére szolgáló teszt 56
57 A programspecifikáció tartalma a programrendszer célja rendszercélok HW, SW környezet specifikációuser interface tervek menü- és struktúra tervek adatbázis (külsőleg definiált) tervezési feltételek 2. Hivatkozott dokumentumok szoftver dokumentáció rendszerleírás HW/SW szállítói információk technikai referenciák A programspecifikáció tartalma Tervezési specifikáció adatleírás (típus, struktúra) származtatott programstruktúra struktúrán belüli interfészek 4. Modulonkénti részletes specifikáció feldolgozási eljárások működési algoritmus leírása interfészspecifikáció (input, output) tervezési technológia felhasználandó modulok, hívás módja adatok köre és szervezési módja 57
58 A programspecifikáció tartalma File-szerkezetek, globális modell specifikáció külső file-szerkezet: file-ok, rekordok, szervezési és elérési mód globális adatok jegyzéke file/adat kapcsolatok 6. Folyamatok-modulok kapcsolatrendszere 7. Tesztelési előírások, dokumentáció tesztadatok, tesztelési utasítás tesztelési stratégia, integrációs teszt különleges előírások 8. Programegységek létrehozása (package) speciális átlapolás átalakítási feltételek Átállás Kísérleti futtatás Fokozatos átállás Párhuzamos feldolgozás Azonnali átállás 58
59 Átadás Az átadás programja, forgatókönyv Átadási információk Az átadás programja Különleges rendelkezések Átadási információk Az átadás tárgya Az átadás időpontja Az átadás helye Résztvevők Az átadási anyagok HW, SW dokumentáció, kézikönyvek Elfogadási feltételek, átvételi kritériumok 59
60 Az átadás programja Bevezető tájékoztató A rendszer bemutatása, elfogadási teszt (projektvezető és a megbízó) Az elfogadási teszt kiértékelése (megbízó) Döntés az elfogadásról Jegyzőkönyv készítése 60
Miskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenA tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (8) Szoftverminőségbiztosítás Szoftvertesztelési folyamat (folyt.) Szoftvertesztelési ráfordítások (Perry 1995) Tesztelésre fordítódik a projekt költségvetés 24%-a a projekt menedzsment
RészletesebbenMiskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,
RészletesebbenA szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver
RészletesebbenVerifikáció és validáció Általános bevezető
Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának
RészletesebbenS01-7 Komponens alapú szoftverfejlesztés 1
S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (13) Szoftverminőségbiztosítás Szoftverminőség és formális módszerek Formális módszerek Formális módszer formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben
RészletesebbenUnit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22
Unit Teszt Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 1 / 22 Tartalomjegyzék 1 Bevezetés 2 Unit Teszt 3 Példa Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 2 / 22 Szoftvertesztelés
RészletesebbenProgramrendszerek tanúsítása szoftverminőség mérése
SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát
RészletesebbenInformációtartalom vázlata
1. Az Ön cégétől árajánlatot kértek egy üzleti portál fejlesztésére, amelynek célja egy online áruház kialakítása. Az árajánlatkérés megválaszolásához munkaértekezletet tartanak, ahol Önnek egy vázlatos
RészletesebbenProgramfejlesztési Modellek
Programfejlesztési Modellek Programfejlesztési fázisok: Követelmények leírása (megvalósíthatósági tanulmány, funkcionális specifikáció) Specifikáció elkészítése Tervezés (vázlatos és finom) Implementáció
RészletesebbenSzoftverarchitektúrák 3. előadás (második fele) Fornai Viktor
Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor A szotverarchitektúra fogalma A szoftverarchitektúra nagyon fiatal diszciplína. A fogalma még nem teljesen kiforrott. Néhány definíció: A szoftverarchitektúra
RészletesebbenMegoldások a mintavizsga kérdések a VIMIAC04 tárgy ellenőrzési technikák részéhez kapcsolódóan (2017. május)
Megoldások a mintavizsga kérdések a VIMIAC04 tárgy ellenőrzési technikák részéhez kapcsolódóan (2017. május) Teszt kérdések 1. Melyik állítás igaz a folytonos integrációval (CI) kapcsolatban? a. Folytonos
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2017-18/2 (9) Szoftverminőségbiztosítás Specifikáció alapú (black-box) technikák A szoftver mint leképezés Szoftverhiba Hibát okozó bement Hibás kimenet Input Szoftver Output Funkcionális
RészletesebbenProjectvezetők képességei
Projectvezetők képességei MOI modell Motivation ösztönzés Organisation szervezés Ideas or Innovation ötletek vagy újítás Más felosztás Probléma megoldás Vezetői öntudat Teljesítmény Befolyás, team képzés
RészletesebbenSoftware Engineering
Software Engineering Software Engineering Software Engineering értelmezése Az a folyamat, mely eredményekénk létrehozunk egy adott feladatot megvalósító szoftver rendszert. Tevékenységek, technológia,
RészletesebbenSzoftver-mérés. Szoftver metrikák. Szoftver mérés
Szoftver-mérés Szoftver metrikák Szoftver mérés Szoftver jellemz! megadása numerikus értékkel Technikák, termékek, folyamatok objektív összehasonlítása Mér! szoftverek, programok CASE eszközök Kevés szabványos
RészletesebbenMŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
RészletesebbenSzoftver architektúra, Architektúrális tervezés
Szoftver architektúra, Architektúrális tervezés Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 11. Roger S. Pressman: Software Engineering, 5th e. chapter 14. Bass, Clements, Kazman: Software
RészletesebbenModell alapú tesztelés mobil környezetben
Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed
RészletesebbenOO rendszerek jellemzői
OO rendszerek jellemzői Problémák forrása lehet teszteléskor: Problémák feldarabolása. Adatrejtés. Az OO rendszerek nagyszámú, egymással aktívan kapcsolatban levő, együttműködő komponensekből állnak. A
RészletesebbenJava programozási nyelv
Java programozási nyelv 2. rész Vezérlő szerkezetek Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/23 Tartalomjegyzék
RészletesebbenOpenCL alapú eszközök verifikációja és validációja a gyakorlatban
OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és
RészletesebbenSZOFTVER-MINŐSÉGBIZTOSÍTÁS SZOFTVER-TESZTELÉSI MÓDSZEREK. Széchenyi István Egyetem. Alapfogalmak
Alapfogalmak Bemeneti adat: Olyan számítógépes adat, amely egy tetszőleges szoftver működtetését vonja maga után, felhasználói szinten. Kimeneti adat: Olyan számítógépes adat, amely egy tetszőleges szoftver
RészletesebbenSzoftvertechnológia ellenőrző kérdések 2005
Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?
RészletesebbenA modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel Majzik István Micskei Zoltán BME Méréstechnika és Információs Rendszerek Tanszék 1 Modell alapú fejlesztési folyamat (részlet)
RészletesebbenA fejlesztési szabványok szerepe a szoftverellenőrzésben
A fejlesztési szabványok szerepe a szoftverellenőrzésben Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Tartalomjegyzék Biztonságkritikus rendszerek A biztonságintegritási szint Az ellenőrzés
RészletesebbenA modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel Majzik István Micskei Zoltán BME Méréstechnika és Információs Rendszerek Tanszék 1 Modell alapú fejlesztési folyamat (részlet)
RészletesebbenSpecifikáció alapú teszttervezési módszerek
Szoftverellenőrzési technikák Specifikáció alapú teszttervezési módszerek Majzik István, Micskei Zoltán http://www.inf.mit.bme.hu/ 1 Klasszikus tesztelési feladat A tesztelendő program beolvas 3 egész
RészletesebbenSpecifikáció alapú teszttervezési módszerek
Szoftverellenőrzési technikák Specifikáció alapú teszttervezési módszerek Majzik István, Micskei Zoltán http://www.inf.mit.bme.hu/ 1 Klasszikus tesztelési feladat A tesztelendő program beolvas 3 egész
RészletesebbenAutóipari beágyazott rendszerek. Komponens és rendszer integráció
Autóipari beágyazott rendszerek és rendszer integráció 1 Magas szintű fejlesztési folyamat SW architektúra modellezés Modell (VFB) Magas szintű modellezés komponensek portok interfészek adattípusok meghatározása
RészletesebbenAutomatikus tesztgenerálás modell ellenőrző segítségével
Méréstechnika és Információs Rendszerek Tanszék Automatikus tesztgenerálás modell ellenőrző segítségével Micskei Zoltán műszaki informatika, V. Konzulens: Dr. Majzik István Tesztelés Célja: a rendszerben
RészletesebbenHatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve
Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok
Részletesebben30 MB INFORMATIKAI PROJEKTELLENŐR
INFORMATIKAI PROJEKTELLENŐR 30 MB DOMBORA SÁNDOR BEVEZETÉS (INFORMATIKA, INFORMATIAKI FÜGGŐSÉG, INFORMATIKAI PROJEKTEK, MÉRNÖKI ÉS INFORMATIKAI FELADATOK TALÁKOZÁSA, TECHNOLÓGIÁK) 2016. 09. 17. MMK- Informatikai
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (10) Szoftverminőségbiztosítás Struktúra alapú (white-box) technikák A struktúrális tesztelés Implementációs részletek figyelembevétele Tesztelési célok -> lefedettség Implicit
RészletesebbenV. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A
RészletesebbenObjektum orientált software fejlesztés (Bevezetés)
Objektum orientált software fejlesztés (Bevezetés) Lajos Miskolci Egyetem Általános Informatikai Tanszék Út az objektum orientált szemléletig 1. Klasszikus módszerek: program = adatszerkezetek + algoritmusok
RészletesebbenKövetelmény alapú minőségbiztosítás az államigazgatásban
Követelmény alapú minőségbiztosítás az államigazgatásban László István 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Témák Követelmény
RészletesebbenKompetens szoftvertesztelés a gyakorlatban II. zárthelyi dolgozat
Név:...................................... Neptunkód:................... Kompetens szoftvertesztelés a gyakorlatban II. zárthelyi dolgozat 2015. április 22. (szerda) Kitöltési útmutató A dolgozat kitöltéséhez
Részletesebben01. gyakorlat - Projektalapítás
2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:
RészletesebbenMŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
RészletesebbenModell alapú tesztelés: célok és lehetőségek
Szoftvertesztelés 2016 Konferencia Modell alapú tesztelés: célok és lehetőségek Dr. Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika
RészletesebbenObjektumorientált paradigma és programfejlesztés Bevezető
Objektumorientált paradigma és programfejlesztés Bevezető Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján
RészletesebbenA szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-technológia aspektusai
RészletesebbenSzoftver karbantartási lépések ellenőrzése
Szoftverellenőrzési technikák (vimim148) Szoftver karbantartási lépések ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.inf.mit.bme.hu/
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (7) Szoftverminőségbiztosítás Szoftvertesztelési folyamat Szoftverek és környezet Nem egyforma a szoftverek használatához kapcsolódó kockázat Különböző kockázati szintek -> eltérő
RészletesebbenNagy bonyolultságú rendszerek fejlesztőeszközei
Nagy bonyolultságú rendszerek fejlesztőeszközei Balogh András balogh@optxware.com A cég A BME spin-off-ja A Hibatűrő Rendszerek Kutatócsoport tagjai alapították Tisztán magánkézben Szakmai háttér Hibatűrő
RészletesebbenInformációs rendszerek Információsrendszer-fejlesztés
Információs rendszerek Információsrendszer-fejlesztés A rendszerfejlesztés életciklusa problémadefiniálás helyzetfeltárás megvalósítási tanulmány döntés a fejlesztésrıl ELEMZÉS IMPLEMENTÁCIÓ programtervezés
RészletesebbenRendszer szekvencia diagram
Rendszer szekvencia diagram Célkitűzések A rendszer események azonosítása. Rendszer szekvencia diagram készítése az eseményekre. 2 1.Iteráció Az első igazi fejlesztési iteráció. A projekt kezdeti szakaszában
RészletesebbenA Java EE 5 plattform
A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11. 13. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési
RészletesebbenSOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni.
Service-Oriented Architecture, SOA Az elosztott rendszerek fejlesztésének módja. Célja:az IT eszközök komplexitásának a kezelésének egyszerűsítése könnyebben újrafelhasználhatóság, egymással integrálhatóság
RészletesebbenMéréselmélet MI BSc 1
Mérés és s modellezés 2008.02.15. 1 Méréselmélet - bevezetés a mérnöki problémamegoldás menete 1. A probléma kitűzése 2. A hipotézis felállítása 3. Kísérlettervezés 4. Megfigyelések elvégzése 5. Adatok
RészletesebbenProgramtervezés. Dr. Iványi Péter
Programtervezés Dr. Iványi Péter 1 A programozás lépései 2 Feladat meghatározás Feladat kiírás Mik az input adatok A megoldáshoz szükséges idő és költség Gyorsan, jót, olcsón 3 Feladat megfogalmazása Egyértelmű
RészletesebbenORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZÖK FEJLESZTÉSE - PEMS V&V
ORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZÖK FEJLESZTÉSE - PEMS V&V Nagy Katinka Budapest, 29 November 2018 Bemutatkozás Nagy Katinka Villamosmérnök BSc (2012) Villamosmérnök MSc
RészletesebbenHasználati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban
Használati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban Nagy Attila Mátyás 2016.12.07. Áttekintés Bevezetés Megközelítés Pilot tanulmányok
RészletesebbenFogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.
Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...
RészletesebbenMIÉRT KELL TESZTELNI?
Unrestricted MIÉRT KELL TESZTELNI? MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak... MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver MIÉRT
RészletesebbenS01-8 Komponens alapú szoftverfejlesztés 2
S01-8 Komponens alapú szoftverfejlesztés 2 Tartalom 1. Komponens megvalósítása: kölcsönhatás modell, viselkedési vagy algoritmikus modell és strukturális modell. 2. Komponens megtestesítés: finomítás és
RészletesebbenTeszttervezé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
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
RészletesebbenSzoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.
Architektúrák dokumentálása UML-lel Irodalom L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addison-Wesley, 2003 H. Störrle: UML 2, Panem, 2007 2 Szoftver architektúra (emlékeztet!)
RészletesebbenProgramozási technológia
Programozási technológia Dinamikus modell Tevékenységdiagram, Együttműködési diagram, Felhasználói esetek diagramja Dr. Szendrei Rudolf ELTE Informatikai Kar 2018. Tevékenység diagram A tevékenység (vagy
RészletesebbenMár megismert fogalmak áttekintése
Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak
Részletesebben2011.11.29. JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése
Tartalom Integrált fejlesztés Java platformon JUnit JUnit használata Tesztelési technikák Demo 2 A specifikáció alapján teszteljük a program egyes részeit, klasszikus V-modell szerint Minden olyan metódust,
RészletesebbenA dokumentáció felépítése
A dokumentáció felépítése Készítette: Keszthelyi Zsolt, 2010. szeptember A szoftver dokumentációját az itt megadott szakaszok szerint kell elkészíteni. A szoftvert az Egységesített Eljárás (Unified Process)
RészletesebbenIntegrációs mellékhatások és gyógymódok a felhőben. Géczy Viktor Üzletfejlesztési igazgató
Integrációs mellékhatások és gyógymódok a felhőben Géczy Viktor Üzletfejlesztési igazgató Middleware projektek sikertelenségeihez vezethet Integrációs (interfész) tesztek HIÁNYA Tesztadatok? Emulátorok?
RészletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):
RészletesebbenStatikus technikák: A szoftver átvizsgálása. Statikus technikák: A szoftver átvizsgálása 2011.04.25.
Dr. Mileff Péter A V & V tervezési folyamatoknak egyensúlyt kell kialakítani a verifikáció és a validációstatikus és dinamikus technikái között. 1 2 Statikus technikák: A szoftver átvizsgálása A szisztematikus
RészletesebbenFicsor Lajos Általános Informatikai Tanszék Miskolci Egyetem
A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2008. 04. 17. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési
RészletesebbenAZ ELőADÁS CÉLJA. a funkciók dokumentálásának bemutatása. az SSADM szerkezetben elfoglalt helyének bemutatása
AZ ELőADÁS CÉLJA a funkciók fogalmának bevezetése a funkciók azonosításának bemutatása a funkciók dokumentálásának bemutatása az SSADM szerkezetben elfoglalt helyének bemutatása Információrendszer fejlesztés
RészletesebbenII. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László
A kockázat alapú felülvizsgálati és karbantartási stratégia alkalmazása a MOL Rt.-nél megvalósuló Statikus Készülékek Állapot-felügyeleti Rendszerének kialakításában II. rész: a rendszer felülvizsgálati
RészletesebbenAlgoritmizálás, adatmodellezés tanítása 6. előadás
Algoritmizálás, adatmodellezés tanítása 6. előadás Tesztelési módszerek statikus tesztelés kódellenőrzés szintaktikus ellenőrzés szemantikus ellenőrzés dinamikus tesztelés fekete doboz módszerek fehér
RészletesebbenPROGRAMOZÁS tantárgy. Gregorics Tibor egyetemi docens ELTE Informatikai Kar
PROGRAMOZÁS tantárgy Gregorics Tibor egyetemi docens ELTE Informatikai Kar Követelmények A,C,E szakirány B szakirány Előfeltétel Prog. alapismeret Prog. alapismeret Diszkrét matematika I. Óraszám 2 ea
RészletesebbenA szoftverfejlesztés eszközei
A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Történet (hw) Lyukkártya válogató
RészletesebbenTOGAF elemei a gyakorlatban
TOGAF elemei a gyakorlatban Vinczellér Gábor 2009.06.0406 04 8 éves szakmai tapasztalat Bemutatkozás IT Support, Programozó, jelenleg Projektvezető, Termékfejlesztési Üzletág Vezető Tanácsadási és Szoftverfejlesztési
RészletesebbenSzoftver újrafelhasználás
Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
RészletesebbenInteraktív, grafikus környezet. Magasszintû alkalmazási nyelv (KAL) Integrált grafikus interface könyvtár. Intelligens kapcsolat más szoftverekkel
Készítette: Szabó Gábor, 1996 Az Az IntelliCorp IntelliCorp stratégiája: stratégiája: Kifinomult, Kifinomult, objektum-orientált objektum-orientált környezetet környezetet biztosít biztosít tervezéséhez,
RészletesebbenTeszttervezé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
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
RészletesebbenObjektumorientált paradigma és a programfejlesztés
Objektumorientált paradigma és a programfejlesztés Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján Objektumorientált
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2017-18/2 (2) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer A szoftver-minőségbiztosítási rendszer összetevői Minőségbiztosítási rendszer Minőség menedzsment Minőségbiztosítás
RészletesebbenKomponens alapú fejlesztés
Komponens alapú fejlesztés Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
RészletesebbenKomponens alapú szoftverfejlesztés. 1. Előadás Bevezetés
Komponens alapú szoftverfejlesztés 1. Előadás Bevezetés 1. Bevezetés Hagyományos, nem komponensalapú fejlesztés: általában top-down, felülrőllefelé haladó módszer Komponensalapú fejlesztési módszer: bottom-up,
RészletesebbenFormális módszerek GM_IN003_1 Bevezetés
Formális módszerek GM_IN003_1 Formális módszerek Formális módszer! formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben nincs olyan formális eljárás, ami egy komplex rendszer minden
RészletesebbenA programozás alapjai előadás. Amiről szólesz: A tárgy címe: A programozás alapjai
A programozás alapjai 1 1. előadás Híradástechnikai Tanszék Amiről szólesz: A tárgy címe: A programozás alapjai A számítógép részegységei, alacsony- és magasszintű programnyelvek, az imperatív programozási
RészletesebbenNév: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (3) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer (folyt.) Eljárások, munkautasítások Eljárás: egy adott módja valami elvégzésének részletezett tevékenységek,
RészletesebbenBiztonsági folyamatirányító. rendszerek szoftvere
Biztonsági folyamatirányító rendszerek szoftvere 1 Biztonsági folyamatirányító rendszerek szoftvere Tartalom Szoftverek szerepe a folyamatirányító rendszerekben Szoftverek megbízhatósága Szoftver életciklus
RészletesebbenIsmeretanyag Záróvizsgára való felkészüléshez
Ismeretanyag Záróvizsgára való felkészüléshez 1. Információmenedzsment az információmenedzsment értelmezése, feladatok különböző megközelítésekben informatikai szerepek, informatikai szervezet, kapcsolat
RészletesebbenInformatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs
Bevezetés Projektellenőr szerepe és feladatai Informatika Informatikai függőség Informatikai projektek Mérnöki és informatikai feladatok találkozása technológiák 1 Tartalom Informatikai projektellenőr
RészletesebbenOrvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT
Orvostechnikai eszköz tesztelése DSS Unit test Taliga Miklós BME-IIT Szabványok és direktívák Orvostechnikai eszközök feladatai Objektív eredmények képzése Embernek érzékelhetetlen paraméterek mérése Sokféle
RészletesebbenRendszer-modellezés, modellezési technikák
Rendszer-modellezés, modellezési technikák System engineering and modelling Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 8. Roger S. Pressman: Software Engineering, 5th e. chapter 10,
RészletesebbenTesztelés az XP-ben Tesztelés az XP-ben. A tesztelés kulcsjellemzői:
Dr. Mileff Péter 1 2 Az XP nagyobb hangsúlyt fektet a tesztelés folyamatára, mint a többi agilis módszer Oka: a teszteléssel és a rendszer validálásával kapcsolatos problémák elkerülése. A rendszertesztelés
RészletesebbenBánsághi Anna Bánsághi Anna 1 of 62
SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 10. ELŐADÁS - TESZTELÉS Bánsághi Anna 1 of 62 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV.
Részletesebben10-es Kurzus. OMT modellek és diagramok OMT metodológia. OMT (Object Modelling Technique)
10-es Kurzus OMT modellek és diagramok OMT metodológia OMT (Object Modelling Technique) 1 3 Modell és 6 Diagram Statikus modell : OMT Modellek és diagramok: Statikus leírása az összes objektumnak (Név,
RészletesebbenMérés és modellezés Méréstechnika VM, GM, MM 1
Mérés és modellezés 2008.02.04. 1 Mérés és modellezés A mérnöki tevékenység alapeleme a mérés. A mérés célja valamely jelenség megismerése, vizsgálata. A mérés tervszerűen végzett tevékenység: azaz rögzíteni
RészletesebbenModellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK
Modellinformációk szabványos cseréje Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK Tartalom MOF, UML, XMI Az UML és az XML séma MDA - Model Driven Architecture Networkshop 2004 2 Az OMG metamodell
RészletesebbenOrvostechnikai eszközök gyártmányfejlesztése Aktív orvosi eszközök fejlesztése PEMS V&V. Nagy Katinka
Orvostechnikai eszközök gyártmányfejlesztése Aktív orvosi eszközök fejlesztése PEMS V&V Nagy Katinka 2016-11-24 Bemutatkozás Nagy Katinka Villamosmérnök BSc (2012) Villamosmérnök MSc (2014) Rendszer tesztmérnök,
RészletesebbenELTE, Informatikai Kar december 12.
1. Mi az objektum? Egy olyan változó, vagy konstans, amely a program tetszőleges pontján felhasználható. Egy olyan típus, amelyet a programozó valósít meg korábbi objektumokra alapozva. Egy olyan változó,
RészletesebbenVállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):
Követelményrendszer 1. Tantárgynév, kód, kredit, választhatóság: Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K 2. Felelős tanszék: Informatika Szakcsoport 3. Szak, szakirány, tagozat: Műszaki
Részletesebben23. Szoftver-tesztelés
23. Szoftver-tesztelés Kérdések Mi a különbség a validációs tesztelés és a hibatesztelés között? Mik a rendszer- és komponenstesztelés alapelvei? Milyen stratégiákat alkalmazhatunk tesztgenerálás céljára?
Részletesebben