Speciális tesztelési feladatok
|
|
- Krisztián Barta
- 8 évvel ezelőtt
- Látták:
Átírás
1 Speciális tesztelési feladatok Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Tartalom Objektum-orientált rendszerek tesztelése Felhasználói felületek tesztelése Hibakezelés tesztelése hibainjektálással Robusztusság tesztelés
2 OO rendszerek tesztelése Problémák a hagyományos módszerek alkalmazása esetén: Információrejtés: Láthatóság, hozzáférhetőség problémás Öröklődés: Megváltozott környezet az öröklött metódusok esetén Inkrementális tesztelés szükséges Polimorfizmus: Eldönthetőség kérdéses Fedettségi mértékszámok használata Kódsor fedettség az öröklődés miatt nem alkalmas Jellegzetes probléma: Információrejtés Az objektumok állapota csak a publikus metódusokon keresztül hozzáférhető Megoldások: Teszt pontok: extra (lekérdező) metódusok hozzáadása Beavatkozó Leszármazott osztály: extra metódusok beillesztése itt Nem beavatkozó, de nem mindenhez férhet hozzá (ld. private C++ esetén) Nyelv-specifikus megoldások, wrapper osztályok friend (C++), child unit (Ada), inspector (Eiffel) ellenőrizetlen típuskonverzió publikussá tett osztályokba... Célszerű a specifikáció alapján tesztelni
3 Jellegzetes probléma: Információrejtés Az objektumok állapota csak a publikus metódusokon keresztül hozzáférhető Megoldások: Teszt pontok: extra (lekérdező) metódusok hozzáadása Beavatkozó ManagerMod Leszármazott osztály: extra metódusok beillesztése name : Stringitt Nem beavatkozó, de nem Manager mindenhez férhet hozzá name : String (ld. private C++ esetén) salary : Integer age : Integer Nyelv-specifikus megoldások, wrapper osztályok getage() : Integer setsalary(amount : Integer) friend (C++), child unit (Ada), inspector (Eiffel) ellenőrizetlen típuskonverzió publikussá tett osztályokba... ManagerTest Célszerű a specifikáció alapján tesztelni getsalary() Manager name : String salary : Integer age : Integer getage() : Integer setsalary(amount : Integer) salary : Integer age : Integer setsalary() getage() getsalary() Probléma: Nem példányosítható osztályok Absztrakt osztályok (nemdefiniált implementáció) Parametrikus osztályok (felparaméterezhető) Megoldás: Önmagukban nem tesztelhetők Funkcionális tesztelés leszármazottakon keresztül
4 Öröklés Intuíció: Öröklött metódusokat nem kell tesztelni (az ősben tesztelve volt) Általánosan nem alkalmazható megközelítés: Felüldefiniálás Más környezet, más hívott metódusok Öröklés típusai a viselkedés szempontjából: Szigorú: Megtartja a szülő viselkedését + kiegészítheti Az új metódusok megváltoztathatják az állapotot! Szintaktikai: Interfész marad, viselkedés átdefiniálható Átdefiniált metódusok újratesztelendők + a hívók is! Implementációs: Nem mindent örököl Hivatkozások a nem örököltekre megváltoznak Újratesztelés öröklés esetén Szülő osztály Leszármazott osztály Nem kell újratesztelni! Öröklött metódusok (azonos kód) Felüldefiniált metódusok (módosult kód) Új metódusok Eredeti viselkedés Módosult viselkedés Új viselkedés Módosult metódust hív Módosult metódustörzs Új metódustörzs
5 Többszörös öröklődés Az előbbi problémák fokozottan jelentkeznek Homográf műveletek: Azonos név és profil Fel kell oldani a kétértelműséget (fordító vagy explicit módon a programozó) Egyik homográf művelet a másikat felülírja, még a másik osztályból öröklött műveletekben is! Type1 select() Type2 select() get() Type12 Ha a Type1-beli select() az erősebb, akkor a Type2-ből örökölt get() is azt használja Type12-ben. Polimorfizmus Egy változó vagy referencia különböző osztályok példányait hordozhatja Öröklés által korlátozva (a leszármazott foglalhatja el a szülő helyét) Dinamikus kötés: Polimorf metódus esetén futás közben derül ki, milyen kódrészlet fog lefutni (pl. szülő, vagy a leszármazott átdefiniált metódusa?) Polimorf metódus tesztelése: Minimális funkcionalitás feltételezése, ami megmarad az átdefiniálás során is? Implicit elágazás (az előélet figyelembe vétele) TypeA add() TypeB add() Object1
6 OO teszt fedettségi mértékszámok Környezetfüggő mértékszámok szükségesek Forrás sorok fedettsége hamis eredményt adna Ha egy metódus a szülőben tesztelt, még a leszármazottban is tesztelni kell (pl. átdefiniált metódusokat használ) Környezetfüggő mértékszámok: Öröklésfüggő fedettség: környezet = osztály A metódus minden (örökölt) osztályban külön tesztelendő Állapotfüggő fedettség: környezet = objektum állapot A metódushívás minden állapotban külön tesztelendő Szálfüggő fedettség: környezet = szál A metódusok minden szálban külön tesztelendők Tartalom Objektum-orientált rendszerek tesztelése Felhasználói felületek tesztelése Hibakezelés tesztelése hibainjektálással Robusztusság tesztelés
7 GUI jellegzetességek Felhasználói utasítások fogadása, eredmény megjelenítése Kommunikáció grafikus elemeken keresztül A program funkcionalitásához nem ad hozzá Eseményvezérelt működésű Manipuláció főként egérrel Implementációk GUI toolkitek (Qt, GTK+, Swing, WinForms, ) Webes GUI Mit tesztelünk? Funkció engedélyezett/tiltott Láthatóság Fókusz Méretezés Elhelyezés Keretrendszer eseményei Adatvalidáció Frissesség Konzisztencia
8 Informális követelmények Tesztelési nehézségek Minták, ergonómiai ajánlások, konvenciók Nagyszámú bemenet, nagy állapottér Ugyanabban a kontextusban sokféle esemény Ugyanaz az esemény sokféle kontextusban Váratlan események Bonyolult GUI funkciók (toolkit mint fekete doboz ) Rejtett, nem dokumentált funkciók Nehéz teszt végrehajtás Egérkattintások reprodukálása Nehéz kiértékelés Grafikus felület változásai és háttér működés azonosítása Példa: Teszt környezet felhasználói felülethez Prototípus (specifikáció, PC) Implementáció (mikrokontroller) XML Report
9 Teszt típusok Ellenőrző lista Jól néz ki az ablak? Navigációs Ha ezt megnyomom, akkor eltűnik/megjelenik ez az ablak? Állapot alapú (belső állapotok) Ha ezt megnyomom, akkor elérhetővé válik / tiltott lesz a másik funkció? Integrációs (több modulra) Ha ezt megnyomom, megnyílik a link a böngészőben? Kommunikációs (modulok között) Ha ezt megnyomom, végrehajtódik a parancs? Szinkronizációs Ha ezt a nézetet megváltoztatom, megváltozik a másik is? Terheléses Kompatibilitást vizsgáló Más alkalmazásokat nem befolyásol? Más platformon is ilyen jól működik? Szisztematikus tesztelés előfeltételei GUI modell felvétele Előnyök: Teszt fedettség definiálható Automatikus tesztgenerálásra is lehetőséget ad Két tipikus GUI modell: Operátor alapú GUI modell Állapotgép alapú GUI modell Teszt módszer rögzítése Előnyök GUI modellhez való illeszkedés biztosítható Ad-hoc megoldásoknál jobban kézbentartható Két példa: Scenario alapú tesztelés: Leggyakoribb használat tesztelése Kombinatorikus tesztelés: Teljes fedésre ad lehetőséget
10 I. Operátor alapú GUI modell Program objektumok Háttérműködés elemeihez kötött (pl. szövegrészek, fájlok, ) Események Menü események (MM) Műveletek kibontása (pl. File/Save) Fókusz kiterjesztő események (FKTE) Munkaablakok (pl. eszköztárak) Fókusz kisajátító események (FKSE) Új ablak nyitása (pl. fájl megnyitási ablak) Rendszerkapcsolati események (RKE) Program objektumok megváltoztatása Operátorok Rendszerkapcsolati operátorok: (MM,FKTE,FKSE)*RKE Program objektumok befolyásolása (pl. Edit/Cut és hatása) Absztrakt operátorok: (MM,FKTE)*FKSE Új ablak nyitása egy művelet hatására (pl. File/Open esetén) 1. Teszt cél meghatározás Scenario alapú tesztelés Operátorok felmérése Objektumok felmérése Jellegzetes használat (kiindulási állapot, célállapot) meghatározása 2. Operátor szekvencia konstruálása Jellegzetes (legvalószínűbb) operátorsorozatok lefedése 3. Konkrét esemény szekvenciára való leképzés Tesztesetek generálása
11 Scenario generálás tervkészítő segítségével A tervkészítés (planner) probléma elemei a GUI teszt generáláshoz: Kezdőállapot: Kiindulási GUI és rendszerállapot (objektumok állapota) Célállapot: Elérendő GUI és rendszerállapot Operátorok (előfeltételek és hatások): GUI események alapján Szabad változókat tartalmazhatnak, hierarchikusak lehetnek Objektumok (lehetnek az operátorok változói): Rendszerállapot Megoldás: Terv (plan): Célállapot elérése a kezdőállapotból Operátor példányok halmaza Részleges rendezési reláció az operátorok között: sorrendi kötöttség Ok-okozati kapcsolatok az operátorok között: hatások és feltételek kötése Operátorok változóinak behelyettesítése: konkrét objektumok A terv teljes sorrendezéssel teszt szekvenciaként használható Linearizálás Kiindulás: Példa egy leképzésre Leképzés: Eredmény:
12 Példa egy másik leképzésre Leképzés: Eredmény: GUI mint automata Esemény folyam (elemi műveletek) II. Állapotgép alapú GUI modell
13 A normál működés tesztelése Tesztelés fedettségi kritériumok alapján: Átmenetek tesztelése Átmenet párok tesztelése Átmenet sorozatok tesztelése Részleges bejárás Teljes bejárás Valószínűségi tesztelés Legvalószínűbb bejárásokat előre kell venni Markov modell használható A nem megengedett működés tesztelése Az állapotgép kiterjesztése helytelen átmenetekkel: Sorrend megfordítása Plusz önhurkok felvétele Új sorrendi kapcsolatok felvétele (teljessé tétel) Helytelen átmenetek tesztelése 1. Normál átmenetekkel a tesztelendő helytelen átmenetig 2. Helytelen átmenet végrehajtásának kísérlete 3. Elvárt hibajelzés vagy nem lehetséges végrehajtás ellenőrzése
14 Állapotgép példa: Kávéautomata Felderíthető gyakorlati problémák: Milyen teszt típusok automatizálhatók? Ellenőrző lista (nehezen automatizálható) Jól néz ki az ablak? Navigációs (automatizálható) Ha ezt a gombot megnyomom, akkor eltűnik/megjelenik ez az ablak? Állapot alapú (automatizálható) Ha ezt megnyomom, akkor elérhetővé válik / tiltott lesz a másik funkció? Integrációs (az egyszerűbb esetekre automatizálható) Ha ezt a gombot megnyomom, megnyílik a link a böngészőben? Kommunikációs (az egyszerűbb esetekre automatizálható) Ha ezt a gombot megnyomom, végrehajtódik a parancs? Szinkronizációs (nehezen automatizálható) Ha ezt a nézetet megváltoztatom, megváltozik a másik is? Terheléses (automatizálható) Milyen gyakran kattinthatok rá? Kompatibilitást vizsgáló (az egyszerűbb esetekre automatizálható) Más alkalmazásokat nem befolyásol? Más platformon is ilyen jól működik?
15 Kézi és automatikus tesztelés Tesztek kézi összeállítása Kézi tesztelés Teszt tervezés Scriptek gépi rögzítése Scriptek integrálása Automatikus tesztelés Scriptek programozása Teszt specifikáció Teszt generálás Teszt végrehajtás Automatizálási lehetőségek Teszt generálás: Script felvétel ( record ) Felhasználói interakciók felvétele Felvett script módosítása, többszörözése Teszt végrehajtás: Script lejátszás ( playback ) Párhuzamosítható Regressziós teszteléshez alkalmazható Eredmény ellenőrzés: Szöveg összevetés : Csak karakteres felületekhez Képfeldolgozás : Grafikus felületekhez Widget alapú Bitmap alapú
16 Teszt automaták (példák) Eszköz Környezet Licensz Abbot Java CPL Squish Java + Web Commercial (Eval) SilkTest (Borland) Multi Commercial (Eval) IBM RFT Multi Commercial (Eval) BadBoy Web FFNP NUnit Forms.Net BSD QuickTest (HP) Java + Windows Commercial (Eval) Ranorex.Net+Web Mixed GUIDancer Java Commercial (Demo) GTT Java GPL Jemmy Java SPL JFCUnit Java LGPL Marathon Java LGPL UISpec4J Java CPL QF-Test Java Commercial (Eval) Selenium Web Apache 2.0 WET Web BSD Sahi Web Apache 2.0 Példa: Rational Robot IBM Rational Functional Tester környezet Automatizált feladatok GUI komponensekhez: Teszt szekvencia rögzítése ( record ) Teszt értékeléshez referencia (verifikációs pont) kijelölése Menü, ablak, régió, clipboard, fájl, szöveg szintű elemek Image mask megadható kép összehasonlításhoz Teszt script mentése (módosítható SQABasic scriptek) Kiindulási információ: (Grafikus) felhasználói felület felderítése, objektumok azonosítása Object mapping: Felhasználói objektumokhoz Adatkészlet (data pool) megadható teszt sorozatokhoz Felhasználás: Rögzített teszt szekvenciák lejátszása Módosított szekvenciák lejátszása Regressziós tesztelés
17 Példa: Selenium Selenium IDE: Böngészőn keresztül történő tesztelés webes felületű alkalmazásokhoz Rögzíti a felhasználói interakciókat Módosítás: Szerkesztés, töréspontok Mentés: Ruby, JavaScript, HTML Kód generálás (Java JUnit) Ezek teszteléshez újra lejátszhatók Teszt bemenet: URL megnyitás, kattintás, szövegbevitel, Teszt kimenet (assertion): Widget eltűnés, megjelenés, szöveg megjelenés,.. Selenium Remote Control: A tesztek több böngészőben futtathatók Szerver komponens: Böngészők indítása, HTTP proxy funkció Kliens könyvtár tesztek írásához: Java, PHP, Perl, Python, Ruby nyelvekhez Selenium Grid: A tesztek több szerveren futtathatók a párhuzamos tesztelés érdekében Selenium Hub: Több Remote Controlhoz Példa: GUITAR - GUI Testing FrAmewoRk
18 Tartalom Objektum-orientált rendszerek tesztelése Felhasználói felületek tesztelése Hibakezelés tesztelése hibainjektálással Robusztusság tesztelés Hibainjektálás: Célkitűzések Biztonságkritikus rendszerek Hibakezelés tesztelése is szükséges Fail stop rendszerek: Hibadetektálás Fail operational rendszerek: Hibatűrés Megvalósítási lehetőségek Valós hibák hatásának megfigyelése (naplózás): Véletlen hibák esetén nehézségek Hosszú idejű működtetés szükséges, vagy nagyszámú megfigyelés szükséges Hibainjektálás: Valóságban várható hibák bevitele Prototípuson vagy modellen elvégezhető Valós hibák gyorsított módon (stressz teszteléshez hasonló)
19 Hibainjektálás tervezése Hibamodell: Egy kép a rendszerben esetlegesen előforduló hibákról Hibamodell jósága Feltételezett és valós hibamodell viszonya Redundáns elemek: növelik a költséget Nem lefedett hibák: rontják a tesztelés minőségét Lefedett valós hibák Hibainjektálás: Módszerek Hardver hibák injektálása: Hardver úton: Precíz (valós hibaokhoz közeli), de drága Jelek közvetlen módosítása (tápfeszültség is) Besugárzás (nehéz-ion, neutron), hőmérsékleti hatások Szoftver úton: Olcsóbb, de kevésbé valósághű Hatások szoftver emulációja: CPU regiszterek, memória módosítása Szoftver hibák injektálása: Forráskód mutációja Modell alapú injektálás: Szimulációval vizsgálható Hardver: VHDL, Verilog modellek alapján Szoftver: UML, állapotgép modellek
20 Hibainjektáló eszközök Hardver hibák: Közvetlen hozzáférés jelekhez: RIFLE, GOOFI Besugárzás (nehéz-ion, neutron) Hatások szoftver emulációja: FIAT, FERRARI, FTAPE Szoftver hibák (fault/error): Alacsony szintű emuláció: DOCTOR, Xception Kód mutációs eszközök: FINE, DEFINE, G-SWFIT Protokoll rétegek hibái: ORCHESTRA, Neko, WS-FIT Modell alapú injektálás: VHDL, HDL szint: FOCUS, MEFISTO Komponens szint (CPU, diszk, memória): DEPEND A hibainjektálás valósághűsége Hibaszimuláció a forráskódban vagy modell szinten a fejlesztőeszközben Ár, valósághűség Regisztertartalom módosítása, memóriakép felülírása Síneken haladó vagy áramkörök lábán megjelenő jelek jelek módosítása Radioaktív sugárzás, ioninjektálás, tápfeszültség zavarása, hőmérséklet
21 Hibainjektálási lehetőségek (összefoglalás) Hardver hibainjektálás Hibaok injektálása közelíthető Besugárzás, elektromágneses zavarok, hőmérséklet Tápfeszültség tüske, jelvezetékek leragadása, összeragadása, Rugalmatlan, drága, de valósághűsége jobb Szoftver hibainjektálás Hibaállapot injektálása (hardver hibaok hatása) Processzor regisztertartalom, memóriatartalom, fájlok, üzenetek, Mutáció bevitele (vezérlés, adatkezelés) Rugalmas, olcsóbb, de valósághűsége kisebb Modell alapú hibainjektálás Tipikusan a komponens szintű hibajelenségek modellezése Funkciók, interakciók megváltozása Tervezési fázisban legkorábban végrehajtható, de a valósághűség itt is kérdéses (legmagasabb absztrakciós szintű) Példa: IBM Autonomous Computing Alkalmazás szerver tesztelése Hibaterhelés: Támadások, operátori hibák Leállások, újraindulások Hibainjektálási intervallumok meghatározása:
22 Nagy mennyiségű adat Feldolgozás: Eredmények kiértékelése OLAP: On-Line Analytical Processing Adatbányászat: Rejtett összefüggések felderítése x2 Linear estimation of dependency: Clusters are hidden Clustering by data miner : Clearly identifies clusters x1 Példa: DBMS hibainjektálás és helyreállítás Mi határozza meg a kiesés idejét? Hiba Konfiguráció Timing Type Target Faultload HW DBMS OS Infrastructure Input factors Measuring a Complex complex system built of COTS components TPMC Availability /TPMC Measures Output: measures
23 Példa: DBMS hibainjektálás és helyreállítás Osztályozás a kiesés ideje alapján, döntési fa mutatja a paramétereket Yes Fault load is one of abruptly shutting down the OS of the DBMS or killing the user session or removing file ORDR, HIST, ORDL or NORD? No Yes 160 Clients experience only a very low degradation of the availability Yeswhen abruptly shutting down the OS or the DBMS, killing the user session or removing individual files. Fault injection time < 750? Configuration is Conf-B? No Yes Yes Fault load is one of dropping table WARE or ORDR or NORD or ORDL or deleting the entire TPPC schema or removing all files from the disk? No Fault load is removing all files from the disk? No Yes Yes Fault load is one of removing file CUST or removing file set DIST or NORD? No Configuration is Conf-B? No 72 No Egy más célú technika: Hibabeültetés Hibák direkt bevitele, majd tesztelés indítása Becslés: Megtalált beültetett hibák sz. Összes beültetett hibák száma Megtalált valódi hibák sz. Összes valódi hiba száma Sok feltétel teljesülése esetén jó becslő csak! Beültetett hibák reprezentatívak, eloszlásuk megfelel a valódi hibákénak
24 Tartalom Objektum-orientált rendszerek tesztelése Felhasználói felületek tesztelése Hibakezelés tesztelése hibainjektálással Robusztusság tesztelés Definíciók Robusztusság (IEEE Std ): The degree to which a system operates correctly in the presence of exceptional inputs or stressful environmental conditions Annak jellemzője, mennyire helyesen működik a rendszer rendkívüli bemenetek vagy nagy igénybevételt jelentő környezeti feltételek mellett. Robusztusság hiba: Helytelen (nem elvárt) működés rendkívüli bemenetek és környezeti feltételek esetén Robusztusság tesztelés: A robusztusság hibák aktiválása a tesztelés során
25 Robusztusság tesztelés Funkcionális tesztelés Specifikációnak megfelelő működés vizsgálata Érvényes bemenet / elvárt kimenet Robusztusság tesztelés Specifikációtól eltérő működés(képtelenség) vizsgálata Extrém vagy hibás bemenet / elvárt kezelés, hibajelzés Bemenetek robusztusság teszteléshez Véletlen bemenetek Van esélye robusztusság hiba aktiválásának Egyszerű teszt adat generálás, de kis hatékonyság Típus-specifikus bemenetek Típustól függően előre kijelölt extrém értékek Komplex kombinációk lehetségesek Objektumok mint bemenetek NULL érték használható extrém értékként Létrehozáshoz extrém paraméterek megadása Scenario mutációval generált bemenetek Az extrém bemenetek állapottól függően adhatók ki Sorrendi, kihagyási, időzítési hibák is definiálhatók
26 Bemenetek generálása típus-specifikus szabályokkal Munkaterhelés (workload) a tesztelés során Valódi terhelés Pl. regisztrált scenariok visszajátszása Realisztikus terhelés Jellegzetes scenariok generálása Jobban hordozható, kézbentartható Szintetikus terhelés Jellemző használat: Tervezett, névleges terhelés Túlterhelés
27 Robusztusság teszt kimenetek értékelése Specifikációtól eltérő működés Sokszor nincs előírt érték Elvárt eredmények egyszerűsített kezelése szükséges Klasszikus kategóriák: CRASH Catastrophic: A teljes rendszer összeomlik / újraindul Restart: Az adott alkalmazás újraindulása Abort: Az adott alkalmazás leáll Silent: Hibajelzés nélküli érvénytelen művelet Hindering: Érvénytelen hibakód Nem robusztusság hiba: Érvényes hibakód visszaadása Jellegzetes eszközök Hardver hibainjektáló eszközök Környezet komponenseibe injektált hibák hatása Robusztusság tesztelő eszközök: Fuzz: Véletlen teszt adatok Konzolos alkalmazások tesztelése Ballista: Típus-specifikus teszt adatok POSIX API, CORBA tesztelés 15 Unix verzió összehasonlítása JCrasher: Teszt objektumok létrehozása Java alkalmazások vizsgálatához Keretrendszerek: DBench: szolgáltatásbiztonság benchmarkok
28 Példa: Ballista - Rendszerhívások tesztelése Példa: Ballista - Típus alapú tesztelés Hibaterhelés (faultload): Szélső és extrém értékek beállítása
29 Példa: Ballista - POSIX teszt eredmények Példa: JCrasher - Java programok tesztelése
30 Példa: JCrasher - Paraméter gráf Hogyan generáljunk automatikusan adott típusú (extrém) objektumot? A módszerek fejlődése uses Véletlen bemenetek Érvénytelen bemenetek Típus-specifikus tesztek Mutációs technikák OO tesztek Behatolás tesztelése idő
31 Mintapélda: HA köztesréteg tesztelése HA köztesréteg: Nagy rendelkezésreállás biztosítása Komponens hibadetektálás, helyreállítás, újraindítás, failover Szabványos operációs rendszerek felett Elosztott alkalmazások Service Availability Forum: HA köztesréteg specifikáció AIS: Redundancia menedzselési funkciók (AMF) Szabványos interfészek (C nyelvű) Miért kritikus a robusztusság hiba? Futtatott komponensek hibáira kell felkészülni Egy hibás komponens a köztesréteg robusztusság hibájának aktiválásával az egész rendszer működését befolyásolhatja Robusztusság tesztelés Közös interfész alapján összehasonlítható implementációk Nagyszámú hibaforrás és hibamód automatikus tesztelés Hibamodell: Elsődleges források
32 Hibamodell: Másodlagos források Az elkészült teszt eszközök TBTS-TG (típus spec.) MBST-TG (mutáció) Munkaterhelés HA Middleware OS hívás wrapper Operációs rendszer Hardver
33 Az elkészült teszt eszközök TBTS-TG (típus spec.) MBST-TG (mutáció) Cél: teljes interfész tesztelése, minél több HA Middleware robusztusság hiba megtalálása Tesztesetek a típusokhoz OS hívás wrapper definiálva Egyes függvényeknél Operációs rendszer Teszt sablon kitöltése Paraméterek hibás és érvényes értékeinek kombinációjával Hardver Kihívás: Állapotalapú hívások Az elkészült teszt eszközök TBTS-TG (típus spec.) MBST-TG (mutáció) Munkaterhelés Munkaterhelés Cél: Sok függvényt használó, HA Middleware komplex szekvenciák tesztelése Szekvenciák mutációja Funkcionális tesztek OS hívás wrapper felhasználása Teszt kód szintaktikai elemzése Mutáció tipikus programozói Operációs rendszer hibáknak megfelelően Kihagyás Felcserélés Tévesztés Hardver Típus-specifikus tesztelés adott szekvencia után
34 Az elkészült teszt eszközök TBTS-TG (típus spec.) MBST-TG (mutáció) Munkaterhelés HA Middleware OS hívás wrapper Cél: Környezeti Operációs hatások rendszer tesztelése Munkaterhelés biztosítása A köztesréteg adott rendszerhívásokat használjon Rendszerhívások eltérítése VárakoztatásHardver Visszatérési érték megváltoztatása Eredmények áttekintése SAFE4TRY robusztusabb Típus specifikus openais openais-trunk SAFE4TRY hibátlan lefutás segmentation fault timeout Mutáció Hibás / összes 30 / / 92 1 / 92 OS wrapper Nem volt hiba Alkalmazás hiba Köztes réteg hiba Rendszerhívások hibájára mindegyik érzékeny
Felhasználói felületek tesztelése
Szoftverellenőrzési technikák Felhasználói felületek tesztelé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/ Motiváció
Felhasználói felületek tesztelése
Szoftverellenőrzési technikák Felhasználói felületek tesztelé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/ Motiváció
Robusztusság tesztelés
Szoftverellenőrzési technikák (vimim148) Robusztusság tesztelés Majzik István és Micskei Zoltá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/
A hibakezelés tesztelése: Hibainjektálás
Szoftverellenőrzési technikák (vimim148) A hibakezelés tesztelése: Hibainjektálás Majzik István és Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek
Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Hibatűrés Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/ 1 Hibatűrés különféle hibák esetén Hardver tervezési hibák
A 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)
A 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)
Modell 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
OO 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
Automatikus 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
Szoftverminő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
Szoftverminő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
2011.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,
Modell 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
Haszná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
R3-COP. Resilient Reasoning Robotic Co-operating Systems. Autonóm rendszerek tesztelése egy EU-s projektben
ARTEMIS Joint Undertaking The public private partnership in embedded systems R3-COP Resilient Reasoning Robotic Co-operating Systems Autonóm rendszerek tesztelése egy EU-s projektben Micskei Zoltán Budapesti
Autó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
Miskolci 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,
Specifiká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
WebService tesztelés. SOAPui Pro, GreenPepper és Confluence használatával. Verhás & Verhás Szoftver Manufaktúra KNOW-HOW
WebService tesztelés SOAPui Pro, GreenPepper és Confluence használatával Verhás & Verhás Szoftver Manufaktúra KNOW-HOW 2008. 5. 15. Verhás & Verhás Szoftver Manufaktúra 1 Tartalom WebService tesztelés
Specifiká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
Komponens 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
Operációs rendszerek. Az X Window rendszer
Operációs rendszerek X Windows rendszer Az X Window rendszer Grafikus felhasználói felületet biztosító alkalmazás és a kapcsolódó protokoll 1983-84: a Massachusetts Institute of Technology-n (MIT, USA).
Szoftver ú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
Tesztelési szintek Tesztautomatizálás
Integrációs és ellenőrzési technikák (VIMIA04) Tesztelési szintek Tesztautomatizálás Majzik István, Micskei Zoltán Méréstechnika és Információs Rendszerek Tanszék Budapesti Műszaki és Gazdaságtudományi
Web-fejlesztés NGM_IN002_1
Web-fejlesztés NGM_IN002_1 Rich Internet Applications RIA Vékony-kliens generált (statikus) HTML megjelenítése szerver oldali feldolgozással szinkron oldal megjelenítéssel RIA desktop alkalmazások funkcionalitása
Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom
Szoftver újrafelhasználás (Software reuse) Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 18. Roger S. Pressman: Software Engineering, 5th e. chapter 27. 2 Szoftver újrafelhasználás Szoftver
Unit 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
OpenCL 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
Intervenciós röntgen berendezés teljesítményszabályozójának automatizált tesztelése
Intervenciós röntgen berendezés teljesítményszabályozójának automatizált tesztelése Somogyi Ferenc Attila 2016. December 07. Szoftver verifikáció és validáció kiselőadás Forrás Mathijs Schuts and Jozef
Modellező eszközök, kódgenerálás
Modellező eszközök, kódgenerálás Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek
Nagy 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ő
Grafikus keretrendszer komponensalapú webalkalmazások fejlesztéséhez
Grafikus keretrendszer komponensalapú webalkalmazások fejlesztéséhez Székely István Debreceni Egyetem, Informatikai Intézet A rendszer felépítése szerver a komponenseket szolgáltatja Java nyelvű implementáció
Szoftverminő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
Teszt terv Új funkció implementációja meglévı alkalmazásba
Teszt terv Új funkció implementációja meglévı alkalmazásba Passed Informatikai Kft. www.passed.hu Farkas Gábor 2007-P-123-45-T-1-1 IIR - Test Manager course 2 Szerepkör Név Aláírás Aláírás dátuma IT Projekt
Verifiká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
Image Processor BarCode Service. Felhasználói és üzemeltetői kézikönyv
Image Processor BarCode Service Áttekintés CIP-BarCode alkalmazás a Canon Image Processor programcsomag egyik tagja. A program feladata, hogy sokoldalú eszközt biztosítson képállományok dokumentumkezelési
Java Programozó képzés A&K AKADÉMIA 2019.
Java Programozó képzés A&K AKADÉMIA 2019. Kedves érdeklődő! Engedd meg, hogy a következő oldalakon részletesebben is bemutassam képzéseink modulrendszerét! Ha további kérdéseid vannak, ne habozz, tedd
Digitális technika (VIMIAA02) Laboratórium 1
BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRÉSTECHNIKA ÉS INFORMÁCIÓS RENDSZEREK TANSZÉK Digitális technika (VIMIAA02) Laboratórium 1 Fehér Béla Raikovich Tamás,
OOP és UML Áttekintés
OOP és UML Áttekintés Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) OOP és UML Áttekintés 2013 1 / 32 Tartalom jegyzék 1 OOP Osztály Öröklődés Interfész, Absztrakt Osztály Kivétel kezelés
OOP. Alapelvek Elek Tibor
OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós
8.3. AZ ASIC TESZTELÉSE
8.3. AZ ASIC ELÉSE Az eddigiekben a terv helyességének vizsgálatára szimulációkat javasoltunk. A VLSI eszközök (közöttük az ASIC) tesztelése egy sokrétűbb feladat. Az ASIC modellezése és a terv vizsgálata
Komplex terheléses tesztmegoldások a Mobil PS és CS gerinchálózaton
Komplex terheléses tesztmegoldások a Mobil PS és CS gerinchálózaton Olaszi Péter, Sey Gábor, Varga Pál AITIA International Zrt. HTE Infokom konferencia és kiállítás, 2012. október 10 12. Változások a gerinchálózatban
Digitális technika (VIMIAA02) Laboratórium 1
BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRÉSTECHNIKA ÉS INFORMÁCIÓS RENDSZEREK TANSZÉK Digitális technika (VIMIAA02) Laboratórium 1 Fehér Béla Raikovich Tamás,
Digitális technika VIMIAA01 9. hét Fehér Béla BME MIT
BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRÉSTECHNIKA ÉS INFORMÁCIÓS RENDSZEREK TANSZÉK Digitális technika VIMIAA01 9. hét Fehér Béla BME MIT Eddig Tetszőleges
Digitális technika VIMIAA01 9. hét
BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRÉSTECHNIKA ÉS INFORMÁCIÓS RENDSZEREK TANSZÉK Digitális technika VIMIAA01 9. hét Fehér Béla BME MIT Eddig Tetszőleges
Mintapélda: Rendszertesztelés a SAFEDMI projektben
Mintapélda: Rendszertesztelés a SAFEDMI projektben 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/ Tartalomjegyzék
Fogalomtá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...
Szoftver 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/
Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 9. ELŐADÁS - OOP TERVEZÉS 2014 Bánsághi Anna 1 of 31 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma
Ficsor 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
Automatikus infrastruktúra menedzsment és alkalmazástelepítés
Intelligens rendszerfelügyelet Automatikus infrastruktúra menedzsment és alkalmazástelepítés Szatmári Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
A 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
TSIMMIS egy lekérdezés centrikus megközelítés. TSIMMIS célok, technikák, megoldások TSIMMIS korlátai További lehetségek
TSIMMIS egy lekérdezés centrikus megközelítés TSIMMIS célok, technikák, megoldások TSIMMIS korlátai További lehetségek 1 Információk heterogén információs forrásokban érhetk el WWW Társalgás Jegyzet papírok
Java programozási nyelv 5. rész Osztályok III.
Java programozási nyelv 5. rész Osztályok III. 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/20 Tartalomjegyzék
Hálózati operációs rendszerek II.
Hálózati operációs rendszerek II. Novell Netware 5.1 Web-es felügyelet, DNS/DHCP szerver, mentési alrendszer 1 Web-es felügyelet Netware Web Manager HTTPS protokollon keresztül pl.: https://fs1.xy.hu:2200
Szoftver labor III. Tematika. Gyakorlatok. Dr. Csébfalvi Balázs
Szoftver labor III. Dr. Csébfalvi Balázs Irányítástechnika és Informatika Tanszék e-mail: cseb@iit.bme.hu http://www.iit.bme.hu/~cseb/ Tematika Bevezetés Java programozás alapjai Kivételkezelés Dinamikus
Az iskolai rendszerű képzésben az összefüggő szakmai gyakorlat időtartama. 10. évfolyam Adatbázis- és szoftverfejlesztés gyakorlat 50 óra
Az iskolai rendszerű képzésben az összefüggő szakmai gyakorlat időtartama 10. évfolyam: 105 óra 11. évfolyam: 140 óra 10. évfolyam Adatbázis- és szoftverfejlesztés gyakorlat 50 óra 36 óra OOP 14 óra Programozási
Szoftverminő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ő
A szerzõrõl... xi Bevezetés... xiii
TARTALOMJEGYZÉK A szerzõrõl...................................................... xi Bevezetés...................................................... xiii I. rész A Visual Basic 2005 környezet 1. óra Irány
Programtervezé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ű
Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Hibatűrés Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/ 1 Hibatűrés különféle hibák esetén Hardver tervezési hibák
Számítógép-rendszerek fontos jellemzői (Hardver és Szoftver):
B Motiváció B Motiváció Számítógép-rendszerek fontos jellemzői (Hardver és Szoftver): Helyesség Felhasználóbarátság Hatékonyság Modern számítógép-rendszerek: Egyértelmű hatékonyság (például hálózati hatékonyság)
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (11) Szoftverminőségbiztosítás Tesztautomatizálás A tesztelés kivitelezése Tesztelési feladatok Detektálatlan maradék hibák számának csökkentése hatásosan és hatékonyan megfelelő
MŰ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
Szoftver-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
Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18.
Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Két projekt Mindkettőben folyamatirányítás Eltérő követelmények Eltérő megoldások Dokumentum gyártási folyamat Üzemeltetés
Iman 3.0 szoftverdokumentáció
Melléklet: Az iman3 program előzetes leírása. Iman 3.0 szoftverdokumentáció Tartalomjegyzék 1. Az Iman rendszer...2 1.1. Modulok...2 1.2. Modulok részletes leírása...2 1.2.1. Iman.exe...2 1.2.2. Interpreter.dll...3
Má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
Adatbázis rendszerek. dr. Siki Zoltán
Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti
Folyamatmodellezé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):
Alapszintű formalizmusok
Alapszintű formalizmusok dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék 1 Mit szeretnénk elérni? Informális tervek Informális követelmények Formális modell Formalizált követelmények
Dr. Pál László, Sapientia EMTE, Csíkszereda WEB PROGRAMOZÁS 2.ELŐADÁS. Objektumorientált programozás 2015-2016
Dr. Pál László, Sapientia EMTE, Csíkszereda WEB PROGRAMOZÁS 2.ELŐADÁS 2015-2016 Objektumorientált programozás OOP PHP-ben 2 A PHP az 5.0-as verziójától megvalósítja az OO eszközrendszerét OO eszközök:
Integrá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?
A 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
Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft
Flash és PHP kommunikáció Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft A lehetőségek FlashVars External Interface Loadvars XML SOAP Socket AMF AMFphp PHPObject Flash Vars Flash verziótól függetlenül
Vizuális adatelemzés - Gyakorlat. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Vizuális adatelemzés - Gyakorlat Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Adatelemzés szerepe a rendszermodellezésben Lényeges paraméterek meghatározása
Kommunikációs rendszerek teljesítőképesség-vizsgálata
Kommunikációs rendszerek teljesítőképesség-vizsgálata (3. előadás) Dr. Lencse Gábor lencse@sze.hu https://www.tilb.sze.hu/cgi-bin/tilb.cgi?0=m&1=targyak&2=krtv 1 Miről lesz szó? Az OMNeT++ diszkrét idejű
A szoftver tesztelés alapjai
Szoftverellenőrzési technikák A szoftver tesztelés alapjai Micskei Zoltán, Majzik István http://www.inf.mit.bme.hu/ 1 Hol tartunk a félévi anyagban? Követelményspecifikáció ellenőrzése Ellenőrzések a tervezési
Részletes szoftver tervek ellenőrzése
Részletes szoftver tervek 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.mit.bme.hu/~majzik/ Tartalomjegyzék A részletes
Első lépések. File/New. A mentés helyét érdemes módosítani! Pl. Dokumentumok. Fájlnév: pl. Proba
Első lépések File/New A mentés helyét érdemes módosítani! Pl. Dokumentumok Fájlnév: pl. Proba (megj. ékezetes karaktereket nem használhatunk a fájlnévben) 1 Konvejor pálya elkészítése System/New Rendszer
Laborgyakorlat 3 A modul ellenőrzése szimulációval. Dr. Oniga István
Laborgyakorlat 3 A modul ellenőrzése szimulációval Dr. Oniga István Szimuláció és verifikáció Szimulációs lehetőségek Start Ellenőrzés után Viselkedési Funkcionális Fordítás után Leképezés után Időzítési
Adatbázisok elleni fenyegetések rendszerezése. Fleiner Rita BMF/NIK Robothadviselés 2009
Adatbázisok elleni fenyegetések rendszerezése Fleiner Rita BMF/NIK Robothadviselés 2009 Előadás tartalma Adatbázis biztonsággal kapcsolatos fogalmak értelmezése Rendszertani alapok Rendszerezési kategóriák
Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon
Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon Mi az IMDG? Nem memóriában futó relációs adatbázis NoSQL hagyományos relációs adatbázis Más fajta adat tárolás Az összes adat RAM-ban van, osztott
A 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)
S01-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
PROGRAMOZÁ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
Miért is transzformáljunk modelleket? Varró Dániel
Miért is transzformáljunk modelleket? Varró Dániel Mit látunk a képen? Tipikus kérdések (Hardvertervezés) Jól működik-e? 1+1 = 2? Hogyan készítsünk 8 bites összeadót 4 bites összeadóval? Hogyan készítsünk
Modellellenőrzés a vasút automatikai rendszerek fejlesztésében. XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő
Modellellenőrzés a vasút automatikai rendszerek fejlesztésében XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő 2018.04.25-27. Tartalom 1. Formális módszerek state of the art 2. Esettanulmány
Digitális eszközök típusai
Digitális eszközök típusai A digitális eszközök típusai Digitális rendszer fogalma Több minden lehet digitális rendszer Jelen esetben digitális integrált áramköröket értünk a digitális rendszerek alatt
III. Alapfogalmak és tervezési módszertan SystemC-ben
III. Alapfogalmak és tervezési módszertan SystemC-ben A SystemC egy lehetséges válasz és egyben egyfajta tökéletesített, tovább fejlesztett tervezési módszertan az elektronikai tervezés területén felmerülő
Interfészek. PPT 2007/2008 tavasz.
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 2 Már megismert fogalmak áttekintése Objektumorientált
Bokor Péter. DECOS Nemzeti Nap október 15. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Beépített diagnosztika Bokor Péter Tartalom 1. Elosztott diagnosztika: a feladat 2. A diagnosztika kihívása 3. A tagság mint diagnosztika 4. A DECOS diagnosztikai szolgáltatások 5. Kapcsolódó feladatok:
MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények
1. sz. melléklet MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS A) Műszaki követelmények A körkereső szoftvernek (a továbbiakban Szoftver) az alábbi követelményeknek kell megfelelnie
Né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,
Adatbázis-kezelő rendszerek. dr. Siki Zoltán
Adatbázis-kezelő rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati
ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu
ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu Számonkérés 2 Papíros (90 perces) zh az utolsó gyakorlaton. Segédanyag nem használható Tematika 1. félév 3 Óra Dátum Gyakorlat 1. 2010.09.28.
Informatikai technológiák szakirány Rendszertervezés ágazat
Méréstechnika és Információs Rendszerek Tanszék Informatikai technológiák szakirány Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A (BSc) Informatikai technológiák
Programfejleszté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ó
A Skype architektúrája. P2P hálózat Supernode ok, peer-ek, login server
Farkas Gábor A Skype architektúrája P2P hálózat Supernode ok, peer-ek, login server Szolgáltatásai IP telefon ingyenes Hátránya: érzékeny a csomagvesztésre, késleltetésingadozásra, sok további szolgáltatás