Szoftver tesztelés és minőségbiztosítás 2002
|
|
- Ede Papp
- 8 évvel ezelőtt
- Látták:
Átírás
1 Szoftver tesztelés és minőségbiztosítás 2002 Molnár D. László A szoftver tesztelése során vallott missziónk A misszió minden lépést befolyásol, és segítséget nyújt számos területen, hogy Gyorsan felfedezzük a fontos programhibákat Általános kulcsunk legyen a termék minőségének megállapításához Igazoljuk, hogy a termék megfelel bizonyos standardoknak A felhasználók is hozzájáruljanak a termék minőségének és tesztelhetőségének javításához A tesztelési folyamat feleljen meg bizonyos "számonkérhetőségi" standardoknak Fejlessze a felhasználókat is a tesztelésben és a tesztelőkkel való együttműködésben Bizonyos előre meghatározott módszerek és szabályok érvényesüljenek a tesztelés során Elősegítse a terméktámogatás költségének megállapítását és ellenőrzését Segítse a felhasználókat munkafolyamataik javításában A munka a lehető legkisebb indokolt költséggel, a lehető legrövidebb idő alatt, "mellékhatások" nélkül készüljön el Együttműködés alakuljon ki a programozókkal Szinte mindent megkérdőjelezzenek, de ne kürtöljenek ki mindent azonnal a külvilágba A sikertelen dolgokra koncentráljanak annak érdekében, hogy a felhasználó a sikert érzékelje Mindent megtegyenek annak érdekében, hogy felhasználók elégedettek legyenek A teszteléssel nem biztosítjuk a minőséget Viszonylag könnyű arra gondolni, hogy a tesztelők a minőség őrei Azonban a minőség a termék készítőitől származik Missziónk nagy része arra irányul, hogy a készítők foglalkozzanak a minőséggel és hatékonyabban, mint egyébként tennék Amennyiben mi végezzük a tesztelést, csoportunk "minőségbiztosítási" csoportnak is nevezhető Teszt eredményeink és hibalistáink valóban elősegítik a termék minőségének javítását, azonban ez a javulás nem csak a tesztelők érdeme, hanem az egész munkacsoport munkájának az eredménye A tesztelők nem kapuőrök Egyes tesztelők azt gondolják, hogy joguk van megakadályozni a termék forgalomba hozatalát, szinte vétójoguk van A probléma az, hogy amennyiben a tesztelők szabják meg a forgalomba hozatal időpontját, nekik kell viselniük a termék minőségéért a felelősséget is Végső soron azok az emberek vezetik a programfejlesztést, akik a felelősséget is vállalják a termék forgalomba hozataláért
2 Mindazonáltal a legsikeresebb termékfejlesztési munkáknál általában ki szokott alakulni valamilyen konszenzus ebben a tekintetben Amennyiben valaki megszabhatja, hogy mikor lehet a terméket publikálni, célszerű, hogy az illető a munkacsoport összes egyéb jogosítványával is rendelkezzen A "nem a mi problémánk" kérdése a tesztelés során A tesztelés komplex folyamat és tevékenység, amely szorosan kapcsolódik más tevékenységekhez. Ennek ellenére egyesek szívesen leszűkítenék a tesztelés folyamatát a terméknek a tervtől való eltéréseire Érdemes ennél sokkal szélesebb értelemben felfogni a tesztelést A tesztelés valójában foglalkozik a következőkkel használhatóság mi szükséges a programhoz, futtatásához adatok minősége program támogathatósága melyek mind ugyancsak a "mi problémánk" Missziónk a tesztelés során a csoport tájékoztatása, legjobb tudásunk szerint, bármely olyan problémáról, amelyek kedvezőtlen hatással lehetnek a termék minőségére a jó tesztelő csoportok különböző típusú, feladatkörű embereket vonnak be a munkába, akik együttesen megértik, átlátják a termék készítésének lényegét, folyamatát? Hogyan készül a terve, mi módon készítik, hogyan dobják piacra, milyen feltételekkel árusítják, hogyan fogják használni, karbantartani és frissíteni Váljunk folyamatjavító csoporttá Úgy gondolhatjuk, hogy könnyebb a hibák keletkezését megelőzni, mint kijavítani Továbbá úgy gondolhatjuk, hogy kevesebb hiba lenne, ha a programozó körültekintőbben járna el munkája során Ezeknek az elgondolásoknak van értelme, már amennyiben megvalósíthatók Sikeresen részt vehetünk a folyamatjavítási munkában, és sikeresek lehetünk, amennyiben a javítás az egész csoport munkájának a része Jelentésre és kijavításra érdemes programhibák A programhibák megzavarják a felhasználókat és csökkentik a szoftver iránti bizalmukat A gyakori programhibák a következők: Helyesírási hibák Képernyő formázási hibák Egérnyom (kis foltok, nyomok jelennek meg az egér mögött mozgatása során) Számítási hibák Az ábrák, grafikonok nem megfelelő méretűek
3 Hibák a képernyőre hívható segítségben Menüpontok, amelyek nem szürkülnek el, amikor kellene, illetve elszürkülnek, amikor nem kellene Nem működő billentyűkombinációk Helytelen hibaüzenetek Szélső értékek (túl nagy vagy túl kicsi számok) helytelen kezelése Időbeállítások, időkorlátozások helytelen működése Egyéb hibák Gondolkodjunk tesztelőként A jó tesztelők technikai szempontból, kreatívan, kritikusan és gyakorlatiasan gondolkodnak Valamennyi gondolkodási típusnak jelentősége van a tesztelés során A gondolkodás négy fő típusa Technikai gondolkodás A technikai gondolkodás annak a képessége, hogy magunkban modellezzük a technológiát és megértsük az okokat és következményeket. Ez magában foglalja a fontos technikai tények ismeretét, az eszközök használatát és a rendszer várható működésének ismeretét, előre látását. Kreatív gondolkodás A kreatív gondolkodás révén képesek vagyunk új ötletekre, és a lehetőségek felmérésére. Rendszerint csupán olyan módon tesztelünk, ahogy elképzeljük a tesztelés folyamatát. Csupán olyan problémák után kutatunk, amelyek létezését elképzeljük. Kritikai gondolkodás A kreatív gondolkodás segít abban, hogy az elképzeléseket értékeljük és következtessünk. Ez magában foglalja a gondolkodásunkban jelentkező hibák észlelését és elhárítását, megfigyeléseinknek a minőség szempontokkal való összevetését, és adott elgondolás vagy esemény elbírálását. Gyakorlatias gondolkodás A gyakorlatias gondolkodás az a képesség, hogy az elméletet a gyakorlatba ültessük. Ez magában foglalja a tesztelő eszközök alkalmazásának vagy kifejlesztésének képességét, amelyek a program sikeres teljesítését segítik. Implicit és explicit specifikációk Specifikáció alatt a program működésének és peremfeltételeinek meghatározását értjük Az explicit, kimondott, leírt specifikáció igen hasznos, mert a készítők vagy a felhasználók által elfogadott követelményeket, kritériumokat önt formába egyértelműen Az implicit specifikáció viszont nincs egyértelműen elfogadva vagy leírva a készítők vagy a felhasználók által Az implicit specifikáció gyakran nem annak alapján keletkezik, hogy a program legjobb legyen a felhasználók szempontjából, hanem sokszor a meggyőző ereje vagy a hihetősége
4 határozza meg. Nemegyszer az implicit specifikációknak alig van közük a kifejlesztendő termékhez. Az implicit specifikációknak számos formája létezik: Hasonlítás versengő termékekhez Hasonlítás kapcsolódó termékekhez Hasonlítás ugyanazon termék korábbi verzióihoz A fejlesztés során váltott ek tartalma A fogyasztók által tett észrevételek, megjegyzések Újságcikkek, folyóiratcikkek (például a korábbi verzióval kapcsolatban) Tankönyvek mondatai a témával kapcsolatban (A program tartalmához hasonló témájú könyv mit ír, melyet összehasonlítanak a program tartalmával) A grafikus felhasználói felületre (GUI) vonatkozó stílus-ajánlások Operációs rendszerrel kapcsolatos kompatibilitási követelmények Saját jól megalapozott tapasztalataink Heurisztikák alkalmazása a tesztelés során A heurisztika lényegében ökölszabály, hüvelykujjszabály Célja, hogy képzett emberek által jóváhagyott módon cselekedjünk új helyzetben Jóllehet a heurisztika nem biztosítja a helyes cselekvést kritikus helyzetekben, mindazonáltal időnként jó szolgálatot tehet Példák heurisztikák alkalmazására Szélső értékek tesztelése A szélső értékek valószínűleg nem egyértelműek a specifikációban Valamennyi hibajelzés tesztelése A hibakezelés általában gyengébben van megírva, mint a főprogram Beállítások tesztelése A különböző programozók beállításai általában eltérőek. Emiatt abban a hamis hitben élnek, hogy a program más beállítás mellett is működni fog Futtatási teszt Ez eléggé gondot szokott okozni. Emiatt a könnyen elvégezhető futtatási tesztek elvégzésének a valószínűsége nagyobb, mint a nehezebben tesztelhető funkcióké Ötszörös tesztelő rendszer Tesztelők Ki végzi a tesztelést Tesztelendő Mit kell tesztelni Potenciális problémák Miért tesztelünk (és mi ellen tesztelünk: például a szélső értékek kezelését stb.) Tevékenységek
5 Hogyan tesztelünk. Például exploratív, feltáró célzatú tesztelést hajtunk végre Értékelés Hogyan tolmácsoljuk, hogy a teszten a program "átjutott" vagy nem A tesztelés egyéb szempontjai Működés tesztelése Kimerítően teszteljük a program valamennyi funkcióját Szélső értékek tesztelése Teszteljük a program miként kezeli a hibákat, amikor szélső értéket adunk valamelyik változónak (például nagy számot írunk be valamelyik mezőbe) Béta-tesztelés Valamilyen külső fogyasztónk, régi vevőnk, vagy velünk kapcsolatban álló szakember teszteli a szoftvert Emberekre alapozott tesztelési technikák Ezek elsősorban arra irányulnak, hogy ki végzi a tesztelést Felhasználói tesztelés Tesztelés olyan emberek által, akik jellemző módon, tipikusan a mi szoftverünket használják Alfa-tesztelés Házon belüli tesztelés, amelyet a fejlesztő munkacsoport, vagy más éházon belüli érdeklődők végeznek el Béta-tesztelés A tesztelést olyanok végzik, akik nem tagjai a fejlesztő munkacsoportnak, sőt a szervezetnek sem, viszont a termékünk célpiacának tagjai Ilyenkor a termék fejlesztése rendszerint már közel van a befejezéshez A béta-tesztelés típusai Tervezési béta teszt Megkérjük a felhasználókat vagy a témában szakértőket, hogy értékeljék a program külalakját (design) Lehetőleg korán meg kell kezdeni, hogy maradjon idő a változtatások elvégzéséhez Marketing béta-teszt Célja a nagy fogyasztók megnyerése, hogy megvásárolják a termékünket, amint piacra kerül és nagy hálózataikon is helyezzék el A fejlesztés meglehetősen késői fázisában kerül sorra, amikor a termék már eléggé kiforrott
6 Kompatibilitási béta-teszt A felhasználó olyan hardveren és szoftver platformon teszteli termékünket, amely számunkra nem áll könnyedén rendelkezésre Erre nem túl későn kell sort keríteni, hogy még időben fel lehessen fedezni és megoldani a kompatibilitási problémákat Gyors tesztelés Házon belüli tesztelés, amelyet a titkárnők, programozók, termékmenedzserek és minden más elérhető ember végez. A tipikus gyors tesztelés fél napig tart és akkor végezzük, amikor a szoftver már majdnem kész Adott területre vonatkozó szakértői tesztelés A szoftvert szakértőnek adjuk bizonyos körülírt kérdésekkel, problémákkal kapcsolatban és visszajelzést kérünk, nevezetesen a hibák feltárását, kritikai észrevételeket, javaslatokat, esetleg helyeslést A szakértő nem feltétlenül a programunk későbbi felhasználója, hanem sokkal inkább a szakértelmére építünk Páros tesztelés Két tesztelő együtt dolgozik a hibák megtalálása érdekében Általában egy gépen dolgoznak és megosztják egymással ötleteiket, tapasztalataikat Együk meg, amit főztünk A saját szervezetünk is használja piacra dobás előtt a szoftvert Rendszerint érdemes várni addig, amíg a szoftver elég megbízhatóan működik, mielőtt éles használatba és eladásra kerülne A tesztelés tárgyára irányuló technikák A tesztelés tárgyára irányuló technikák a termékre koncentrálnak Számos technika áll rendelkezése, amelyek különbözőképpen csoportosíthatók attól függően, hogy mire kívánjuk használni ezeket Például a az egyes program tulajdonságok integráltságának tesztelése termék orientált, amennyiben azt vizsgáljuk, hogy minden funkció megfelelően működik-e a többi funkcióval együtt (kombinációban) Ugyanez probléma orientált, amennyiben van valamilyen elképzelésünk arról, hogy miért van valamilyen hiba, és ennek keletkezését nyomon szeretnénk követni. Lehet például, hogy az egyik függvénynek vagy szubrutinnak nem vagy nem jól adjuk át az értékeket Működés tesztelése
7 Minden egyes működési elem, függvény, szubrutin tesztelése egyenként Az elemek, függvények, szubrutinok lehetőleg teljes körű tesztelése annak megállapítása érdekében, hogy azok valóban jól működnek Fehér doboz függvény tesztelés Ezt rendszerint egység tesztelésnek is nevezik, és rendszerint az egyes, forráskódban megjelenő önálló függvények vagy szubrutinok tesztelését jelenti Fekete doboz függvény tesztelés Ennek során a parancsokra és olyan dolgokra, tulajdonságokra figyelünk elsősorban, amelyeket a felhasználó ki tud választani, vagy amellyel elő tud idézni valamilyen működést Ajánlott a függvény tesztelés elvégzése mielőtt bonyolultabb tesztek során több függvény együttes tesztelését végeznénk el Összetett tesztelés során az első hibás függvény leállítja a program futását, és esetleg nem állapítható meg egykönnyen, hogy melyik függvény volt a hibás Tulajdonságok és függvények integráltságának tesztelése Ennek során elemezzük, hogy a tulajdonságok, függvények megfelelően kapcsolódnak-e egymáshoz, integrált-e a rendszer Menü vizsgálat Végig kell menni valamennyi menüponton a grafikus felhasználói felületen és minden választási lehetőséget kipróbálni Domain tesztelés A domain olyan (matematikai) halmaz, amely magában foglalja egy változó, illetve függvény valamennyi lehetséges értékét A domain tesztelés során azonosítjuk a változókat és függvényeket A változók bemeneti és kimeneti változók egyaránt lehetnek Minden egyes változóhoz a lehetséges változókat ekvivalencia osztályokba soroljuk és kiválasztjuk belőlük kis részhalmazukat, rendszerint a szélső értékek környékén a teszteléshez Ekvivalencia osztály tesztelés Az ekvivalencia osztály a változó azon értékei, amelyeket ekvivalensnek tekintünk A teszt-esetek ekvivalensek, ha úgy gondoljuk, hogy Valamennyien ugyanazt tesztelik Ha az egyikkel kapcsolatban programhiba van, akkor valószínűleg a másikkal kapcsolatban is Ha az egyikkel kapcsolatban nincs programhiba, akkor valószínűleg a másikkal kapcsolatban sincs Határoló érték tesztelés Az ekvivalencia osztály értékek halmazából áll Ha le tudjuk képezni ezeket az értékeket a számegyenesre, akkor a határoló értékek az osztály legkisebb és legnagyobb értékei
8 A határoló érték tesztelésnél ezeket az értékeket teszteljük, továbbá a közelükben fekvő további értékeket is A legjobb képviselő tesztelése Az ekvivalencia osztály legjobb képviselője a változónak olyan értéke, amely ugyanolyan valószínűséggel okoz programhibát, mint bármely más érték A legjobb képviselő tesztelése során általában a szélső értékeket és a közelükben fekvő értékeket szokták tesztelni elsősorban Beviteli mező tesztelése és az eredmény elhelyezése táblázatban Minden egyes beviteli mező teszteléséhez célszerű kidolgozni standard tesztelési eljárást és ezeket a módszereket kell alkalmazni minden hasonló mező tesztelése során Minden lehetséges módon teszteljük a mező tartalmának módosíthatóságát Adott mező tartalmát rendszerint többféle módon megváltoztathatjuk Például importálhatjuk kívülről, bevihetjük közvetlenül billentyűzetről, a programmal kiszámoltathatjuk és feltölthetjük a mezőt valamilyen számított értékkel, és így tovább. A mező tartalma általában csak bizonyos értékeket vehet fel. Logikai kapcsolatok tesztelése A programban az egyes változók között logikai kapcsolatok lehetnek. Például a programba beépítettek olyan döntést, hogy ha az életkor nagyobb, mint 50, és a dohányzás "igen" értéket kapott, akkor a "felajánlunk-e biztosítást" mező automatikusan "nem"-re állítódik Az ilyen típusú döntési szabályok logikai kapcsolatokat tartalmaznak A logikai kapcsolatok tesztelése során megkísérlik valamennyi lehetséges logikai kapcsolatot egyenként tesztelni Állapot tesztelés A program működése közben egyik állapotából másik állapotába mehet át Adott állapotban bizonyos bemenő értékek elfogadhatóak, míg másik állapotban nem. Például bizonyos mezők akár el is szürkülhetnek, vagy nem lehet oda adatot bevinni, míg máskor igen A helyes érték bevitelekor a program tesz valamit, és nem tesz olyat, amit nem tehet meg Az állapot tesztelés során a tesztelő végigmegy a programon és az ilyen típusú működéseket teszteli körültekintően Út tesztelés Az út tesztelés magában foglalja mindazokat a lépéseket, amelyeken a program végigment, amíg a megadott állapothoz érkezett Az út tesztelés rendszerint számos más útvonal tesztelését magában foglalja Azonban bizonyos bonyolult programok esetében elképzelhető, hogy nem lehet valamennyi utat bejárni Programsorok és elágazások tesztelése Száz százalékos programsor tesztelést lehet végrehajtani abban az esetben, ha a program minden sorát egyenként teszteljük Száz százalékos elágazás tesztelést lehet végrehajtani abban az esetben, ha a program minden elágazását egyenként teszteljük Konfiguráció lefedettség tesztelése
9 Abban az esetben, ha 100 printeren kell végrehajtanunk a tesztelést, és csak tízen tettük meg, úgy is fogalmazhatunk, hogy 10 százalékos "lefedettséggel" teszteltük a konfigurációs kompatibilitást Specifikáció alapú tesztelés Ebben az esetben a tesztelés azoknak a kívánalmaknak a tesztelésére vonatkozik, amelyeket a programmal szemben támasztottak Ezeknek a kívánalmaknak a tesztelése általában igen/nem típusú válasszal fejeződik be Ezek a kívánalmak rendszerint megjelennek a program dokumentációban, kézikönyvben, a piacra kerülést kísérő egyéb dokumentumokban, hirdetésekben, valamint a technikai támogatásra vonatkozó leírásokban, amelyeket a felhasználókhoz eljuttatnak Követelmény alapú tesztelés A követelmény alapú tesztelés során kitérnek mindazon szempontok ellenőrzésére, amelyek szerepelnek a dokumentumokban Kombináció tesztelés Ez a tesztelés két vagy több változó együttes tesztelésére vonatkozik Probléma alapú tesztelés Ennek a középpontjában az áll, hogy mi a tesztelés célja, illetve milyen veszély elhárítására irányul a tesztelés Kockázat alapú tesztelés Itt a tesztelés irányát a programhiba bekövetkezésének valószínűsége, illetve a hibából származható kár nagysága határozza meg. Minél nagyobb a hiba bekövetkezésének valószínűsége, illetve a hibából származható kár nagysága, annál inkább és annál korábban szükséges a tesztelés végrehajtása Input korlátozások Input korlátozás alatt az értendő, hogy a program bizonyos határok között tud kezelni dolgokat Például ha a program legfeljebb 32-jegyű számokat tud kezelni, a programozónak olyan védő rutinokat kell írnia, amelyek megakadályozzák, hogy 32 bitesnél nagyobb számokat vigyenek be a rendszerbe Amennyiben nincs ilyen védelem, a program általa feldolgozhatatlan adatokat kísérel meg feldolgozni, amely hibához vezet Output korlátozások Előfordulhat, hogy az input adatok megfelelőek voltak, de mégis a feldolgozás során olyan adatok keletkeztek, amelyeket a program nem tud kezelni A program leállhat vagy hibát jelezhet, amikor ezeket az értékeket megpróbálja megjeleníteni a képernyőn, kinyomtatni, vagy lementeni Számítási megszorítások Abban az esetben, ha a bemeneti és kimeneti adatok megfelelőek, a számítások során keletkezhetnek olyan értékek, amelyek programhibához vezetnek Például két nagy szám szorzata túl nagy számot eredményezhet, amelyet a program nem tud kezelni Tárolási kapacitás megszorítások Abban az esetben, ha a bemeneti és kimeneti adatok, és a számítások is megfelelőek, a program számára esetleg időközben elfogyhat a memória vagy a háttértár
10 Az időfaktor tesztelése Az időfaktor tesztelése magában foglalja a különböző egymás utáni események idejének, illetve az egymásutániságok helyes sorrendjének a vizsgálatát Tevékenységre alapozott tesztelési technikák Ezeknek a technikáknak az alkalmazása során elsősorban a tesztelés módjára figyelnek Regresszió tesztelés A regresszió tesztelés magában foglalja ugyanannak a tesztnek többszöri alkalmazását, különösen a különböző változásokat követően A regressziós tesztelés típusai Régi hibák újratesztelése Akkor kerül sor rá, amikor úgy gondoljuk, hogy a régi hibákat eltávolították A teszt célja annak bizonyítása, hogy a hiba megszüntetése nem tökéletes A régi hibák regressziós tesztelésének célja annak kimutatása, hogy a régi programhiba kiküszöbölése ellenére az újra előkerül Mellékhatás regressziós tesztelés (stabilitás regressziós teszt) Ez magában foglalja a termék lényeges részeinek újratesztelését Célja annak igazolása, hogy ami korábban működött, a program javítása következtében most nem működik Tesztelés forgatókönyv szerint Kézi tesztelés rendszerint kezdő tesztelő által, amelyet tapasztalt tesztelő által megírt lépésről lépésre megírt forgatókönyv szerint végeznek el Smoke tesztelés Ez a mellékhatás regressziós tesztelés azzal a céllal készül, hogy bizonyítsa, hogy a termék valamelyik új modulja még nem elég érett a további tesztelésre sem A smoke tesztelés gyakran automatizált és standardizált, és egyik modulról a másikra haladnak alkalmazása során Azt tesztelik, hogy a modul az elvárások szerint működik-e, és ha nem, feltételezik, hogy esetleg nem a megfelelő fájllal építették össze vagy valami más alapvető probléma van a modullal Exploratív tesztelés Elvárjuk a tesztelőtől, hogy a munka során tanulja meg a terméket, a potenciális piacát, a kockázatait, és emlékezzen arra, hogy a korábbi tesztek során milyen problémák voltak Folyamatosan keletkeznek új tesztek és ezeket alkalmazzák is Az újabb tesztek hatékonyabbak, mert a tesztelő növekvő tapasztalatain alapulnak Gerilla tesztelés Gyors és ártalmas támadás a program ellen Az exploratív tesztelés egyik formája, mely rövid időszakra korlátozódik, és rendszerint tapasztalt tesztelő végzi A tesztelő a leghatékonyabb módszereket veti be a program ellen Amennyiben jelentős problémákat talál, ennek a területnek a költségvetését is újra alakítják, és az egész tesztelési folyamat is módosulhat Amennyiben nem találnak jelentős problémákat, ettől kezdve az adott területet kevésbé intenzíven tesztelik Forgatókönyv tesztelés
11 A forgatókönyv tesztelés négy tulajdonsággal jellemezhető (1) A teszt legyen valóságszerű. Tükrözze, amit a felhasználó valóban tenne a programmal (2) A teszt legyen összetett, komplex, foglaljon magában számos tulajdonságot, szempontot, amelynek a programnak meg kell felelnie (3) A teszt legyen könnyen és gyorsan végrehajtható, amelyből megállapítható, hogy a program átment-e a vizsgán vagy sem (4) A tulajdonosok, érintett felek bizonyára erőteljesen amellett érvelnek majd, hogy javítsák ki a programhibákat, ha ilyeneket találnak Telepítés tesztelés A tesztelés során a program különböző, megengedett körülmények között és eltérő, megengedett rendszereken telepítésre kerül Ellenőrzésre kerül, hogy a lemezen mely fájlok adódnak hozzá a meglévőkhöz, illetve melyek módosulnak a telepítés során Működik-e a telepített program Mi történik a telepítés megszüntetése (uninstall) után? Betöltődés tesztelés A program vagy rendszer futásának ellenőrzése úgy történik meg, hogy közben több progrtamot is betöltenek, illetve a rendszer erőforrásait erősen igénybe veszik Igen nagy terhelés mellett a rendszer valószínűleg nem működik, azonban ennek a folyamatnak az elemzése rávilágíthat a rendszer sebezhető pontjaira, és ezeket a tapasztalatokat a fejlesztés során hasznosítani lehet Hosszú ideig tartó tesztelés (ellenállóság, megbízhatóság tesztelése) A tesztelést egész éjszaka vagy napokig, hetekig folytatják. Ennek a célja olyan hibák felderítése, amelyek rövid idejű tesztelésnél nem kerülnek napvilágra. Ilyenek például a pointerekkel, memória-kezeléssel, memória szivárgással, túlcsordulással és alulcsordulással, és ezek valamilyen kombinációjával, kölcsönhatásával kapcsolatos vizsgálatok Teljesítmény tesztelés Ezek a tesztek rendszerint arra irányulnak, hogy milyen gyors a program annak megállapításához, hogy szükséges-e valamilyen optimalizálás. Ezek a tesztek azonban végül számos más programhibát is előidézhetnek, kimutathatnak. A programban a fejlesztés különböző szakaszai között tapasztalt jelentős teljesítményváltozás valamilyen programozási hibára hívhatja fel a figyelmet Kiértékelésre alapozott technikák Ezek arra irányulnak, hogy milyen módon közöljék a program helyes vagy hibás működését A kiértékelésre alapozott technikák között leírják azokat a módszereket, amelyek alkalmasak a program helyes vagy hibás működésére vonatkozó megállapítások, következtetések megtételéhez Ugyanakkor nem mondják meg, hogy hogyan kell magát a tesztelést végrehajtani, hogyan kell adatokat gyűjteni a rendszerről Arról tájékoztatnak, hogy amennyiben tudunk adatokat gyűjteni, hogyan vonjuk le ezek alapján a következtéseket Önellenőrző adatok A tesztelés során az általunk használt adatfájlok alkalmasak lehetnek a kimenő adatok helyességének megállapítására
12 Tesztelés a lementett eredményekkel való összehasonlítás révén A rendszerint, de nem mindig, automatizált regresszió tesztelés során összehasonlításra kerülnek a jelenlegi eredmények a korábbi, akár múlt heti eredményekkel Amennyiben a múlt héten az eredmények jók voltak, viszont most más eredmények jöttek ki, ez új problémára hívhatja fel a figyelmünket Előre megadott specifikációval vagy egyéb mértékadó dokumentummal való összehasonlítás Amennyiben a program működése nem felel meg a specifikációkkal, ez valószínűleg hibára utal Heurisztikus egyezés Az egyezés (konzisztencia) fontos szempont a program kiértékelése során. A meg nem felelés (inkonzisztencia) elegendő indok lehet programhiba jelentésére, de lehet szándékos tervezési variáció eredménye is. Hét fő inkonzisztenciáról, illetve konzisztenciáról szoktak beszélni 1. Konzisztens a régi eseményekkel A jelenlegi működés hasonló, mint korábban volt 2. Konzisztens az általunk alkotott képpel A program működése egyezésben van azzal a képpel, amelyet a szervezet akar önmagáról közölni 3. Konzisztens a hasonló termékekkel A program működése a hasonló termékek működésével nagyjából megegyezik 4. Konzisztens az igényekkel A program működése megfelel az igényeknek, amelyet az emberek feltehetőleg kívánnak 5. Konzisztens a felhasználók várakozásaival A program működése megfelel annak, amit szerintünk a felhasználók akarnak 6. Konzisztencia a terméken belül A program működése belül konzisztens, tehát a működési minták, a grafikus felület és így tovább értelemszerűen megegyezik egymással a lehetőségek határain belül 7. Konzisztens a céllal A program működése megfelel annak a célnak, amelyre nyilvánvalóan kifejlesztették.
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
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é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észletesebbenMiskolci 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é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é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é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észletesebbenTESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS
TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,
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é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észletesebben1.1. HOGYAN HASZNÁLJUK AZ ÖNÉRTÉKELÉSI ESZKÖZT. Az eszköz három fő folyamatot ölel fel három szakaszban:
1.1. HOGYAN HASZNÁLJUK AZ ÖNÉRTÉKELÉSI ESZKÖZT 1. melléklet Az eszköz három fő folyamatot ölel fel három szakaszban: a pályázók kiválasztása (a táblázat 1. munkalapja); a projekt kedvezményezettek általi
RészletesebbenAlkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
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észletesebbenAlgoritmizálás és adatmodellezés tanítása beadandó feladat: Algtan1 tanári beadandó /99 1
Algoritmizálás és adatmodellezés tanítása beadandó feladat: Algtan1 tanári beadandó /99 1 Készítette: Gipsz Jakab Neptun-azonosító: ABC123 E-mail: gipszjakab@seholse.hu Kurzuskód: IT-13AAT1EG 1 A fenti
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észletesebbenAngolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata jelentése: gyors, fürge 1990-es évek vége Változás igénye Módszertan-család
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é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é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észletesebbenSzoftverminő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ő
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észletesebbenSZERZŐ: Kiss Róbert. Oldal1
A LEGO MindStorms NXT/EV3 robot grafikus képernyőjét és programozási eszközeit használva különböző dinamikus (időben változó) ábrákat tudunk rajzolni. A képek létrehozásához koordináta rendszerben adott
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észletesebbenRubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József
Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0 Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax:
RészletesebbenAlgoritmizálás és adatmodellezés tanítása beadandó feladat: Algtan1 tanári beadandó /99 1
Algoritmizálás és adatmodellezés tanítása beadandó feladat: Algtan1 tanári beadandó /99 1 Készítette: Gipsz Jakab Neptun-azonosító: ABC123 E-mail: gipszjakab@seholse.hu Kurzuskód: IT-13AAT1EG Gyakorlatvezető
RészletesebbenFeladat. Bemenő adatok. Bemenő adatfájlok elvárt formája. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. Például (bemenet/pelda.
Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. BEDTACI.ELTE Programozás 3ice@3ice.hu 11. csoport Feladat Madarak életének kutatásával foglalkozó szakemberek különböző településen különböző madárfaj
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é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észletesebbenLaborinformációs menedzsment rendszerek. validálása. Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH)
Laborinformációs menedzsment rendszerek validálása Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH) Tartalom Túl a címen 17025:2017(8) elvárásai Gondolatok a NAH-tól LIMS validálás Számoló táblák/eszközök
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észletesebbenDigitális aláíró program telepítése az ERA rendszeren
Digitális aláíró program telepítése az ERA rendszeren Az ERA felületen a digitális aláírásokat a Ponte webes digitális aláíró program (Ponte WDAP) segítségével lehet létrehozni, amely egy ActiveX alapú,
RészletesebbenUtolsó módosítás:
Utolsó módosítás: 2011. 09. 08. 1 A tantárggyal kapcsolatos adminisztratív kérdésekkel Micskei Zoltánt keressétek. 2 3 4 5 6 7 8 9 10 11 12 13 14 Erősen buzzword-fertőzött terület, manapság mindent szeretnek
RészletesebbenVári Péter-Rábainé Szabó Annamária-Szepesi Ildikó-Szabó Vilmos-Takács Szabolcs KOMPETENCIAMÉRÉS 2004
Vári Péter-Rábainé Szabó Annamária-Szepesi Ildikó-Szabó Vilmos-Takács Szabolcs KOMPETENCIAMÉRÉS 2004 2005 Budapest Értékelési Központ SuliNova Kht. 2 Országos Kompetenciamérés 2004 Tartalom 1. Bevezetés...4
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észletesebbenMentális modell, metaforák és analógiák. A desktop metafora. Xerox Star GUI
Mentális modell, metaforák és analógiák A desktop metafora Xerox Palo Alto Research Center Xerox Star GUI 1973/79. Xerox Alto A piacon megjelenő első számítógép bittérképes képernyővel egérrel grafikus
RészletesebbenProgramozási alapismeretek beadandó feladat: ProgAlap beadandó feladatok téma 99. feladat 1
Programozási alapismeretek beadandó feladat: ProgAlap beadandó feladatok téma 99. feladat 1 Készítette: Gipsz Jakab Neptun-azonosító: A1B2C3 E-mail: gipszjakab@vilaghalo.hu Kurzuskód: IP-08PAED Gyakorlatvezető
RészletesebbenA minőség és a kockázat alapú gondolkodás kapcsolata
Mottó: A legnagyobb kockázat nem vállalni kockázatot A minőség és a kockázat alapú gondolkodás kapcsolata DEMIIN XVI. Katonai Zsolt 1 Ez a gép teljesen biztonságos míg meg nem nyomod ezt a gombot 2 A kockázatelemzés
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észletesebbenA GeoEasy telepítése. Tartalomjegyzék. Hardver, szoftver igények. GeoEasy telepítése. GeoEasy V2.05 Geodéziai Feldolgozó Program
A GeoEasy telepítése GeoEasy V2.05 Geodéziai Feldolgozó Program (c)digikom Kft. 1997-2008 Tartalomjegyzék Hardver, szoftver igények GeoEasy telepítése A hardverkulcs Hálózatos hardverkulcs A GeoEasy indítása
RészletesebbenAz interakció stílusai
Az interakció stílusai Starkné dr. Werner Ágnes Interakció Az interakció folyamán, a képernyőn megjelenő információ, és a kezelő inputjainak, valamint ezek alapján a programfunkciók szervezési stílusának
RészletesebbenFMEA tréning OKTATÁSI SEGÉDLET
FMEA tréning OKTATÁSI SEGÉDLET 1. Hibamód és hatás elemzés : FMEA (Failure Mode and Effects Analysis) A fejlett nyugati piacokon csak azok a vállalatok képesek hosszabbtávon megmaradni, melyek gazdaságosan
RészletesebbenAutóipari beágyazott rendszerek. Kockázatelemzés
Autóipari beágyazott rendszerek Kockázatelemzés 1 Biztonságkritikus rendszer Beágyazott rendszer Aminek hibája Anyagi vagyont, vagy Emberéletet veszélyeztet Tipikus példák ABS, ESP, elektronikus szervokormány
RészletesebbenSzoftvertesztelés - Bevezető
Szoftvertesztelés - Bevezető Csirmaz Péter Livesoft Kft. 2010.03.13. Bevezetés A szoftvertesztelés egy rendszer vagy program kontrollált körülmények melletti futtatása, és az eredmények kiértékelése. A
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észletesebbenSzoftver-ergonómiára vonatkozó szabvány, avagy ISO 9241
Szoftver-ergonómiára vonatkozó szabvány, avagy ISO 9241 Ez a szabvány támpontokat ad a fejlesztőknek ahhoz, hogy ergonómikus rendszert tudjanak létrehozni. Az ISO 9241-es szabvány célja a képernyős munka
RészletesebbenA Szekszárdi I. Béla Gimnázium Helyi Tanterve
A Szekszárdi I. Béla Gimnázium Helyi Tanterve Négy évfolyamos gimnázium Informatika Készítette: a gimnázium reál munkaközössége 2015. Tartalomjegyzék Alapvetés...3 Egyéb kötelező direktívák:...6 Informatika
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é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észletesebbenHidak építése a minőségügy és az egészségügy között
DEBRECENI EGÉSZSÉGÜGYI MINŐSÉGÜGYI NAPOK () 2016. május 26-28. Hidak építése a minőségügy és az egészségügy között A TOVÁBBKÉPZŐ TANFOLYAM KIADVÁNYA Debreceni Akadémiai Bizottság Székháza (Debrecen, Thomas
RészletesebbenEmber-gép rendszerek megbízhatóságának pszichológiai vizsgálata. A Rasmussen modell.
Ember-gép rendszerek megbízhatóságának pszichológiai vizsgálata. A Rasmussen modell. A bonyolult rendszerek működtetésének biztonsága egyre pontosabb, naprakész gondolati, beavatkozási sémákat igényel
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észletesebbenIntegráci. ciós s tesztek. ciós s tesztek (folyt.) Integration Level Testing (ILT) Ficsor Lajos. Miskolci Egyetem Általános Informatikai Tanszék
ciós s tesztek ciós s tesztek Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 11. 27. IntegraciosTeszt / 1 ós tesztek IntegraciosTeszt / 2 ciós s tesztek (folyt.) Feltételezzük,
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észletesebbencím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től
Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Alapfogalmak: 1. hiba: egy már meglévő, funkcionalitásban hibás működést eredményező programrész hibás működésének leírása konkrét
RészletesebbenA DigiKresz internetes gyakorló program hatékony segítség az elméleti oktatást követő vizsga eredményességének növelésében.
DIGIKRESZ internetes gyakorló program Kedves Felhasználó! A DigiKresz internetes gyakorló program hatékony segítség az elméleti oktatást követő vizsga eredményességének növelésében. A program előnyei a
RészletesebbenAntreter Ferenc. Termelési-logisztikai rendszerek tervezése és teljesítményének mérése
Antreter Ferenc Termelési-logisztikai rendszerek tervezése és teljesítményének mérése Doktori értekezés Témavezetők: Dr. Várlaki Péter egyetemi tanár Széchenyi István Egyetem, Műszaki Tudományi Kar, Logisztikai
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észletesebbenV & V Feladatok. V & V Feladatok
V & V Feladatok 2008.01.08 2. Feladat tartozik! A relációjel fordított. Hibás bemenetekre nem teszteltünk. Figyelmen kívül hagytuk az objektum konstruálás időigényét. A pointer értéke null. A program lefut,
RészletesebbenWebprogramozás szakkör
Webprogramozás szakkör Előadás 5 (2012.04.09) Programozás alapok Eddig amit láttunk: Programozás lépései o Feladat leírása (specifikáció) o Algoritmizálás, tervezés (folyamatábra, pszeudokód) o Programozás
RészletesebbenI. A DIGITÁLIS ÁRAMKÖRÖK ELMÉLETI ALAPJAI
I. A DIGITÁLIS ÁRAMKÖRÖK ELMÉLETI ALAPJAI 1 A digitális áramkörökre is érvényesek a villamosságtanból ismert Ohm törvény és a Kirchhoff törvények, de az elemzés és a tervezés rendszerint nem ezekre épül.
RészletesebbenAz adatok értékelése és jelentéskészítés: Az (átfogó) vizsgálati összefoglalás benyújtása
Az adatok értékelése és jelentéskészítés: Az (átfogó) vizsgálati összefoglalás benyújtása Webszeminárium az információs követelményekről 2009. november 30. Valamennyi rendelkezésre álló információ értékelése
RészletesebbenStatikus technikák és Műszaki teszttervezési technikák
Statikus technikák és Műszaki teszttervezési technikák Bevezetés a tananyagba Tesztelési Technikák 3 Statikus technikák 4 Műszaki teszttervezési technikák (Dinamikus tesztelés) 1 Tesztelési technikák Tesztelési
RészletesebbenA CA-42 adatkommunikációs kábel gyors telepítési útmutatója
A CA-42 adatkommunikációs kábel gyors telepítési útmutatója 9234594 2. kiadás A Nokia, a Nokia Connecting People és a Pop-Port a Nokia Corporation bejegyzett védjegyei. Copyright 2005 Nokia. Minden jog
RészletesebbenHORVÁTH ZSÓFIA 1. Beadandó feladat (HOZSAAI.ELTE) ápr 7. 8-as csoport
10-es Keressünk egy egész számokat tartalmazó négyzetes mátrixban olyan oszlopot, ahol a főátló alatti elemek mind nullák! Megolda si terv: Specifika cio : A = (mat: Z n m,ind: N, l: L) Ef =(mat = mat`)
RészletesebbenHogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni?
Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni? Kritikus pontok Ethernet interfész soros eszközbe ágyazásakor Az ipari Ethernet technológia az alacsony költségeinek és jelentős hálózati
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észletesebbenA PiFast program használata. Nagy Lajos
A PiFast program használata Nagy Lajos Tartalomjegyzék 1. Bevezetés 3 2. Bináris kimenet létrehozása. 3 2.1. Beépített konstans esete.............................. 3 2.2. Felhasználói konstans esete............................
RészletesebbenFTP Az FTP jelentése: File Transfer Protocol. Ennek a segítségével lehet távoli szerverek és a saját gépünk között nagyobb állományokat mozgatni. Ugyanez a módszer alkalmas arra, hogy a kari web-szerveren
RészletesebbenAláírást-ellenőrző alkalmazás. funkcionális modellje és követelményrendszere. CWA 14171:2004 alapján
Aláírást-ellenőrző alkalmazás funkcionális modellje és követelményrendszere a CWA 14171:2004 alapján V1.1 Készítette: 2005. 15/2 1 Az aláírás-ellenőrző rendszerek funkcionális modellje... 3 1.1 Az aláírások
Részletesebben11.2. A FESZÜLTSÉGLOGIKA
11.2. A FESZÜLTSÉGLOGIKA Ma a feszültséglogika számít az uralkodó megoldásnak. Itt a logikai változó két lehetséges állapotát két feszültségérték képviseli. Elvileg a két érték minél távolabb kell, hogy
RészletesebbenTeszt 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
RészletesebbenESZKÖZTÁMOGATÁS A TESZTELÉSBEN
ESZKÖZTÁMOGATÁS A TESZTELÉSBEN MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA, TURISZTIKA ÉS VENDÉGLÁTÁS TERÜLETEN
RészletesebbenProgramozás I. házi feladat
Programozás I. házi feladat 2013. 6. hét, 1. rész A feladatsor 4 feladatot tartalmaz, amelyeket egy közös forráskódban kell megvalósítani. Annak érdekében, hogy a tesztelő egymástól függetlenül tudja tesztelni
RészletesebbenA foglalkozás céljának eléréséhez a következő tevékenységeket végezzük el:
A FOGLAKOZÁS ADATAI: SZERZŐ Kiss Róbert A FOGLALKOZÁS CÍME Dinamikus rajzolás robotképernyőn A FOGLALKOZÁS RÖVID LEÍRÁSA A LEGO MindStorms NXT/EV3 robot grafikus képernyőjét és programozási eszközeit használva
RészletesebbenSzilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt
Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt segédlet A Szilipet programok az adatok tárolásához Firebird adatbázis szervert használnak. Hálózatos
RészletesebbenBevezetés a programozásba
Bevezetés a programozásba 1. Előadás Bevezetés, kifejezések http://digitus.itk.ppke.hu/~flugi/ Egyre precízebb A programozás természete Hozzál krumplit! Hozzál egy kiló krumplit! Hozzál egy kiló krumplit
RészletesebbenKözfoglalkoztatás támogatás megállapítását segítő segédtábla használati útmutatója
Közfoglalkoztatás támogatás megállapítását segítő segédtábla használati útmutatója 1.) Általános tudnivalók: A segédtábla két méretben készül, 10, és 50 sort lehet kitölteni. A tábla megnevezéséből amit
RészletesebbenINFORMATIKAI ALAPISMERETEK
Informatikai alapismeretek középszint 0621 ÉRETTSÉGI VIZSGA 2007. május 25. INFORMATIKAI ALAPISMERETEK KÖZÉPSZINTŰ ÍRÁSBELI ÉRETTSÉGI VIZSGA JAVÍTÁSI-ÉRTÉKELÉSI ÚTMUTATÓ OKTATÁSI ÉS KULTURÁLIS MINISZTÉRIUM
RészletesebbenA TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK
A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR,
RészletesebbenImage 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
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észletesebben(Közlemények) AZ EURÓPAI UNIÓ INTÉZMÉNYEITŐL ÉS SZERVEITŐL SZÁRMAZÓ KÖZLEMÉNYEK BIZOTTSÁG
2009.5.9. Az Európai Unió Hivatalos Lapja C 107/1 II (Közlemények) AZ EURÓPAI UNIÓ INTÉZMÉNYEITŐL ÉS SZERVEITŐL SZÁRMAZÓ KÖZLEMÉNYEK BIZOTTSÁG A Bizottság Közleménye Italok csomagolása, betétdíjas rendszerek
RészletesebbenÜGYFÉL OLDALI BEÁLLÍTÁSOK KÉZIKÖNYVE
ÜGYFÉL OLDALI BEÁLLÍTÁSOK KÉZIKÖNYVE Felhasználói leírás E-HATÁROZAT 2012 - verzió 1.2 Érvényes: 2012. május 24-től. Azonosító: ehatarozat_ugyfél_ beallitasok_kezikonyv_felh_v1.2_20120524_tol 1/15 1 Tartalom
RészletesebbenRubin SPIRIT TEST. Domino net provisioning tesztelése esettanulmány 1.0. Készítette: Dobó Arnold Jóváhagyta: Varga József. Rubin Informatikai Zrt.
Domino net provisioning tesztelése esettanulmány 1.0 Készítette: Dobó Arnold Jóváhagyta: Varga József Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax: +361 469 4029
RészletesebbenFelhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása
Szabó Zsolt adatbiztonság tároláskor Felhasználók hitelesítése adatbiztonság szállításkor Felhasználóknak szeparálása jogi és szabályozási kérdések incidens kezelés öntitkosító meghajtókat Hardveres Softveres
RészletesebbenFunkciópont elemzés: elmélet és gyakorlat
Funkciópont elemzés: elmélet és gyakorlat Funkciópont elemzés Szoftver metrikák Funkciópont, mint metrika A funkciópont metrika alapelveinek áttekintése Bonyolultsággal korrigált funkciópont A funkciópont
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 telepítési útmutató tartalma
1 A telepítési útmutató tartalma 3 Kompatibilitás és rendszerkövetelmények A telepítési folyamat röviden 4 A telepítés indítása 5 Adatbáziskezelő beállítása / telepítése 8 Telepítési módozatok 11 Az ENSO
RészletesebbenProgramozási alapismeretek 4.
Programozási alapismeretek 4. Obejktum-Orientált Programozás Kis Balázs Bevezetés I. Az OO programozási szemlélet, egy merőben más szemlélet, az összes előző szemlélettel (strukturális, moduláris, stb.)
RészletesebbenTelepítési útmutató a Solid Edge ST7-es verziójához Solid Edge
Telepítési útmutató a Solid Edge ST7-es verziójához Solid Edge Tartalomjegyzék Bevezetés 2 Szükséges hardver és szoftver konfiguráció 3 Testreszabások lementése előző Solid Edge verzióból 4 Előző Solid
Részletesebben8.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
RészletesebbenSystemDiagnostics. Magyar
SystemDiagnostics Magyar Szeretne hozzánk fordulni... műszaki jellegű kérdéseivel vagy problémájával? Az alábbiakkal veheti fel a kapcsolatot: Forróvonalunk/ügyfélszolgálatunk (lásd a mellékelt forróvonal-listát,
RészletesebbenA GeoEasy telepítése. Tartalomjegyzék. Hardver, szoftver igények. GeoEasy telepítése. GeoEasy V2.05+ Geodéziai Feldolgozó Program
A GeoEasy telepítése GeoEasy V2.05+ Geodéziai Feldolgozó Program (c)digikom Kft. 1997-2010 Tartalomjegyzék Hardver, szoftver igények GeoEasy telepítése A hardverkulcs Hálózatos hardverkulcs A GeoEasy indítása
RészletesebbenKinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések. 1. Mi a programozás?
Bevezetés Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések Forráskód Hibajegyzék p2p.wrox.com xiii xiii xiv xiv xvi xvii xviii
RészletesebbenOCSP Stapling. Az SSL kapcsolatok sebességének növelése Apache, IIS és NginX szerverek esetén 1(10)
OCSP Stapling Az SSL kapcsolatok sebességének növelése Apache, IIS és NginX szerverek esetén 1(10) 1. Tartalomjegyzék 1. Tartalomjegyzék... 2 2. Bevezető... 3 3. OCSP Stapling támogatással rendelkező webszerverek...
RészletesebbenA 9001:2015 a kockázatközpontú megközelítést követi
A 9001:2015 a kockázatközpontú megközelítést követi Tartalom n Kockázat vs. megelőzés n A kockázat fogalma n Hol található a kockázat az új szabványban? n Kritikus megjegyzések n Körlevél n Megvalósítás
RészletesebbenEgyetemi adatbázis nyilvántartása és weben
Egyetemi adatbázis nyilvántartása és weben keresztül történő elérése Bara Levente Dező László Farkas Kinga Gere Árpád Keresztes Anna March 6, 2009 1 Contents 1 Egyetemi adatbázis nyilvántartása és weben
RészletesebbenInformatika-érettségi_emelt 11.-12. évfolyam Informatika
11. évfolyam A tanév célja a középszintű érettségire való felkészítés, az emelt szintű érettségire való felkészülésnek a megalapozása. A középszintű érettségi elősegíti az eligazodást és a munkába állást
RészletesebbenINFORMATIKAI ALAPISMERETEK
ÉRETTSÉGI VIZSGA 2005. május 20. INFORMATIKAI ALAPISMERETEK KÖZÉPSZINTŰ ÉRETTSÉGI VIZSGA Az írásbeli vizsga időtartama: 180 perc JAVÍTÁSI-ÉRTÉKELÉSI ÚTMUTATÓ OKTATÁSI MINISZTÉRIUM Megoldási útmutató I.
Részletesebben