DÉRI ZOLTÁN GYTK, SE - 2011

MINŐSÉGBIZTOSÍTÁSIINFORMÁCIÓS RENDSZEREK III. FORRÁS: HOMONNAY GÁBOR SE,

2008

DÉRI ZOLTÁNGYTK, SE - 2011

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

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


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)


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


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


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


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


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?)


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)


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


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)


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


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!


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


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


Tesztelési környezet

Fejlesztő környezet Tesztelő 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


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


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


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


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


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


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


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


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


Á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!


Documents

DÉRI ZOLTÁN GYTK, SE - 2011