MINŐSÉGBIZTOSÍTÁSI INFORMÁCIÓS RENDSZEREK III. FORRÁS: HOMONNAY GÁBOR SE, 2008 DÉRI ZOLTÁN GYTK, SE

Tematika •Alapfogalmak –Információs rendszer fogalma –Vállalati alkalmazási rendszerek –Biztonsági követelmények, IT Biztonság, Felhasználó jog. –Minőségmenedzsment információs rendszerek •A mai környezet –Alkalmazások fejlesztése, bevezetése, használata –Alkalmazási rendszerek ellenőrzése –Elektronikus rekord, elektronikus aláírás •A felhasználó kritikus feladatai –Felhasználói igények megfogalmazása –Felhasználók tesztelési feladatai 2011 február 25. Déri Zoltán: minőségbiztosítási információs rendszerek ii#2#2

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 3 Ellenőrzések és a tesztelés •Az alkalmazások ellenőrzésének sok fajtája van: –Használatbavétel előtt: •Terv ellenőrzése (inspekció) •Tesztelés •Verifikálás •Validálás –Használatbavételkor: Átvételi tesztek –Használatbavételt követően •Az alkalmazás megfelelőségének ellenőrzése – a felhasználói követelmények teljesülésének utólagos ellenőrzése – utólagos tesztek •Az alkalmazás használata megfelelőségének ellenőrzése – felhasználók munkavégzésének ellenőrzése, adatbázis és naplók elemzése •Adat megbízhatósági ellenőrzések •Biztonsági ellenőrzések •Vészhelyzeti tervek ellenőrzései

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 4 Tesztelés – verifikálás - validálás Tesztelés: program ellenőrzése annak lefuttatásával Verifikálás (kvalifikálás): program átnézése futtatás nélkül és futtatással Validálás: az alkalmazás tervének és környezetének való megfelelőség, beleértve a programok futtatásával és egyéb vizsgálatokkal való ellenőrzését is (H. Olga szakdolgozatából, 2006)

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 5 Tesztelések a fejlesztésben •Már a projekt megtervezésénél: –A tesztelés „feladat” lesz, idő, munka és pénz ráfordítással •Felhasználói követelmények megfogalmazásából már következik a tesztelési konkrét munka •Tervezéskor, specifikáláskor már el kell készíteni a tesztelési tervet

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 6 Tesztelési terv •Tesztelés csak tesztelési terv alapján legyen! –Terv a felhasználói követelmények alapján –Terv a tesztelési stratégia szerint •Alkalmazás kockázatai •Arányosság •A terv általában két lépcsős –A tesztelési stratégia (általános) •A tesztelési feladat megközelítése •Résztvevők, felelősségek •Tesztadatok, teszt környezet –A tesztelés végrehajtását segítő terv (részletes) •Teszt tervek, teszt protokollok •Tesztelési tervet a felhasználó készíti

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 7 Tesztelési (részletes) terv •A tervben: –Az elvégzendő feladat –A tesztelést végrehajtó(k) neve –A tesztelés előfeltételei –Az elfogadás feltétele(i) – kimenő adatok –A feladat(ok) végrehajtásának ütemezése –A tesztadatok fajtája (valós vagy kitalált, konkrét adatok) – bemenő adatok

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 8 Tesztelések a fejlesztésben •A kivitelezési (programtervezési, programozási) szakaszban az informatikus tesztel –Saját munkáját ellenőrzi •Kész alkalmazást (vagy elkülönített alkalmazás-részt) a felhasználó teszteli –A saját követelmény megfogalmazási munkáját ellenőrzi és az informatikus fejlesztési munkáját ellenőrzi

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 9 Tesztelési fajták •Egyedi teszt (Unit teszt) – informatikus a programot vagy program részletet minden ágán leteszteli, mielőtt kezéből kiadja. Eredménye: elvileg a követelményeknek megfelelő program (DE: ne számítsanak tökéletes egyedi tesztekre!) •Folyamat-teszt – felhasználó által végrehajtott teszt, a funkció minden ágát megmozgatja a lehetséges különféle jó és hibás adatokkal (DE: Önök készítenek ilyent?)

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 10 Tesztelési fajták •Rendszerteszt – felhasználók által folyamatában végrehajtott teszt az alkalmazás kezdetétől annak végéig, a rendszer minden ágát megmozgatja, ám általában csak a jó adatokkal (Kérdés: Önök készítenek ilyent?) •Tömeg-teszt (terhelési teszt) – a szokásos terhelés legalább háromszorosával kipróbálni az alkalmazást (igen ritkán használják)

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 11 Más szempontból tesztelési fajták •Alkalmazásba vétel előtt – folyamat tesztek (használati tesztek) –Kapcsolati tesztek (interfészek tesztjei) –Átvételi tesztek –Hozzáférési tesztek –Teljesítőképességi tesztek •Működő alkalmazásban –Változások tesztjei –Ismétlő tesztek (megbizonyosodni a használhatóságról) •Végrehajtó szerinti különös esetek –Auditor teszjei –Független vizsgáló tesztjei

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 12 Kis elmélet •Fekete dobozos tesztelés –Nem ismerjük a vizsgált dolog belsejét, ezért csak a különféle bemenetek esetén elért kimeneteket, eredményeket tudjuk vizsgálni –A felhasználói tesztek szinte mindig ilyenek •Fehér dobozos tesztelés –Pontosan ismerjük a dolog összes belső elemét, itt a program minden ágát és utasítását –Az elvileg létező összes lehetséges variációban vizsgáljuk a dolgot, itt a program összes ágát bejárjuk, az elképzelhető különféle adatokkal –Ez informatikusi feladat –(Speciális teszt csoportok végzik)

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 13 Tesztadatok •Tesztadatok –Normál esetek –Határok –Kivételek –Speciális értékek (mínusz, nulla, üres érték stb.) –Kezdőérték adás stb. •Logikai ellenőrzések –Hiányzó logikai útvonalak –Rossz útvonalválasztás –Rossz tevékenység

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 14 A felhasználó szemlélete •Szabályos esetekben működjön minden –Nagyon sok szabályos eset létezhet az adatok és algoritmusok sokféleségéből adódóan –Elvileg minden lehetséges előforduló esetet ki kellene próbálni •Hibás eseteknél –Ezeket megfelelően kezelje az alkalmazás –Bármi lehet nem megfelelő vagy hibás •Hibás adat vagy adathiány •Hibás kezelői működtetés •Hibás szoftver –Minden előforduló szabálytalanságot le kellene kezelni az alkalmazásban •Ezért mindet ki kellene próbálni •De a gyakorlatban előforduló eseteket mindenképp!

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 15 Tesztelés •A tesztelési művelet tehát próbálgatás •A teszt terv vagy teszt protokoll szerint dokumentálandó –Dokumentálás lényege: •Megerősítés a tesztelőnek – összegzés alapja •Másnak hihető legyen, hogy végrehajtották •Azt más utólag képes legyen megismételni

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 16 Tesztelési környezet •A tesztelést nem szokás, nem szabad az éles környezetben végezni. Ezért három környezet az ideális: –Éles környezet, ebben dolgoznak a felhasználók –Minőségbiztosítási környezet, ebben tesztelnek a felhasználók –Fejlesztő környezet, ebben fejleszt az informatikus és ebben tesztel

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 17 Tesztelési környezet Fejlesztő környezetTesztelő környezetÉles környezet Ebben tesztel informatikus Ebben tesztel felhasználó Ebben esetleg auditor tesztel Átvitel kipróbálása Csak kipróbált fejlesztés kerülhet éles környezetbe! Megjegyzés: 1.Számítógépes környezetből pontosan lehetséges három külön környezet kialakítása 2.A valós környezetből nehéz már a második környezet kialakítása is

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 18 Kockázatelemzés •Bonyolult alkalmazásokat lehetetlen teljes körűen tesztelni –Több százezer, millió esetről lehet szó •A tesztelés méretét csökkenteni kockázatelemzéssel lehet –Kritikus elemekre koncentrálni •Teljes körű tesztelést csak exrtém esetben szoktak –Űrhajózás, repülőgép irányítás –Mobiltelefonok –Gyártó eszközök folyamatirányítása

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 19 Kockázat szerinti tesztelés •Mivel a tesztelés általában részleges, ezért a teszt eseteket kockázat szerint kell választani –Kritikus műveleteket mindenképp tesztelni –Kihagyhatók a lekérdezés jellegű programok –Lehetőleg be kell választani a folyamatba épített ellenőrzések által nem érintett folyamatokat –Kihagyhatók a minőségi állapotot nem befolyásoló funkciók (hasonlóan pl. számviteli rendszernél a nem könyvelési funkciók) –Kevesebb esetszámmal vizsgálhatók a jó programtervvel rendelkező funkciók •A kockázat szerinti választást az informatikussal együtt kell eldönteni, mert sok az informatikai szakmai meggondolás

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 20 Kockázatot csökkenteni •Mindenféle kockázatelemzés ellenére a mai alkalmazásoknál a legfontosabb: –Megfelelő és teljes körű követelményekből induljon ki a fejlesztés –Részletes és szakszerű tervezés legyen a kivitelezés előtt •A megfelelő minőséget elsősorban „beépíteni” kell, nem utólag – tesztelés hatására – kijavítani –A megfelelő tervezés mellett sem maradhat el a kockázatokkal arányos tesztelés

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 21 Gyakorlati megfontolások •Egy folyamatot ésszerű számosságú teszttel kell kipróbálni –Új, induló alkalmazásnál viszonylag sok változattal –Pl. verzió emelés esetén elegendő lehet a kevesebb változat is •Az alkalmazás tesztelési időtartama ne legyen túl nagy, tehát elvégezhető mennyiségű tesztet kell kijelölni –Számolva a normál munka melletti elvégezhetőséggel –A tesztelési periódus kisebb alkalmazásnál néhány hét, integrált alkalmazásnál (verzióváltásnál) 3-5 hónap

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 22 Változtatások esetén •Változtatások esetén különös gonddal kell tesztelni –Ilyenkor általában nem történik teljes újratervezés •Ezért az alkalmazás változásában maradhat programozási hiba, még gondos tervezés mellett is –A változási helyen kívül, attól időben és folyamatban nagyon távol is lehetnek nem kívánt mellékhatások •Például következmény az időszak végi záráskor •Hibák utólagos felmerülése beszámolókban, lekérdezésekben –Külön figyelmet érdemel a kódok változása, ez nem okoz-e problémát? •Más (most nem változó) folyamatokban, algoritmusokban •Beszámolókban, lekérdezésekben

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 23 Tesztelés automatizálása •A tesztelés bizonyos fokig automatizálható –Tesztelési környezet (pl. felhasználók jogosultságokkal) –Tesztelési forgatókönyvek –Tesztelési esetek –Lehetséges bemenő adatok (esetleg generálva) –Elvárt végeredmények –Továbblépési feltételek

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 24 Tesztelés oktatása •Tesztelés előtt oktatás –A tesztelendő funkció szabályos működése –Esetlegesen előforduló hibák –A tesztadatok kiválasztásának elve és gyakorlata –A teszt végrehajtása –A teszt dokumentálása

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 25 Integrált rendszer tesztelése, verifikálása •Az integrált rendszerek nagyon sok elemből állnak (több ezer program, több ezer táblás adattár stb.) •A lehetséges teszt esetek számossága több százezer esetnél kezdődik, szinte végtelen •Egy több lépéses folyamat egyszeri tesztelése néhány tízperctől néhány óráig tart •Az integrált rendszerek tesztelése szinte végtelen ideig tartana több embernek is •Ezért az integrált rendszereket olyan módszerekkel kell megtervezni és készíteni, hogy gyakorlatilag hibátlan szerkezet készüljön. •Ezután elégséges a szokásos adatokkal a használt funkciók „kóstolás-szerű” tesztelése

2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 26 Átvételi tesztek •Átvétel a fejlesztőtől éles üzemeltetésre •Átadás kiszervezett szolgáltatásra •Szerződéses felelősség átadás •Érdemes komolyan venni (de kevesen szokták) és ugyanúgy végezni és dokumentálni, mint pl. a validálást

Köszönöm a figyelmet! 2011 február 25. Déri Zoltán: Minőségbiztosítási információs rendszerek III 27