DÉRI ZOLTÁN GYTK, SE - 2011

1. DÉRI ZOLTÁN GYTK, SE - 2011 MinőségBIZTOSÍTÁSIinformációs rendszerek III. forrás: Homonnay Gábor SE, 2008

2. 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 Déri Zoltán: minőségbiztosítási információs rendszerek ii

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 Déri Zoltán: Minőségbiztosítási információs rendszerek III

4. Tesztelés – verifikálás - validálás 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 Verifikálás (kvalifikálás): program átnézése futtatás nélkül és futtatással Tesztelés: program ellenőrzése annak lefuttatásával (H. Olga szakdolgozatából, 2006) 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 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 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 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 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?) 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) 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 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) 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 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! 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 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 Déri Zoltán: Minőségbiztosítási információs rendszerek III

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

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