Test plan Okoshaz projekt

Hasonló dokumentumok
Unit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22

Test Management Strategy Document. Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán

Test Strategy. Tartalomjegyzék

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI

Okosház Test Plan. Tartalomjegyzék

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Web:

Test Strategy. Monotonitá s tűrése (0 5) Biztonsági tudás (0 5) Adatbázis ismeret (0 5)

Szoftverminőségbiztosítás

Verifikáció és validáció Általános bevezető

Szoftvertesztelés - Bevezető

Teszt terv Új funkció implementációja meglévı alkalmazásba

30 MB INFORMATIKAI PROJEKTELLENŐR

ESZKÖZTÁMOGATÁS A TESZTELÉSBEN

Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése

Szoftverminőségbiztosítás

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK

Okosház tesztterve. szeged.hu/~gertom/oktatas/tesztman.php oldalon találhatóak a következők:

Szoftverminőségbiztosítás

Járműkövető rendszer RÉSZLETES ISMERTETŐ

Rubin 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.

A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK

6. számú melléklet KÖLTSÉGVETÉSI SPECIFIKÁCIÓ. a Társadalmi Megújulás Operatív Program. Új tanulási formák és rendszerek Digitális Középiskola program

Rubin 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

Programozási technológia II 7. előadás. Verifikáció és validáció Giachetta Roberto

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)

Szoftvertesztelés Alapok

Intelligens biztonsági megoldások. Távfelügyelet

A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

MIÉRT KELL TESZTELNI?

Modell alapú tesztelés: célok és lehetőségek

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

A DevOps-kultúra eszközei

Agilis projektmenedzsment

hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba

Specifikáció alapú teszttervezési módszerek

Gyakorlati feladat - 1

Programtervezés. Dr. Iványi Péter

Specifikáció alapú teszttervezési módszerek

Ez a telepítési dokumentum segítséget nyújt abban, hogy szabályosan telepítse az Áfa átállító szoftvert Szerviz 7 programhoz.

INFORMATIKA EGYRE NAGYOBB SZEREPE A KÖNYVELÉSBEN

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

Hálózati szolgáltatások biztosításának felügyeleti elemei

Mobil Partner telepítési és használati útmutató

CRA - Cisco Remote Access

(Teszt)automatizálás. Bevezető

Image Processor BarCode Service. Felhasználói és üzemeltetői kézikönyv

Norway Grants. Az akkumulátor mikromenedzsment szabályozás - BMMR - fejlesztés technológiai és műszaki újdonságai. Kakuk Zoltán, Vision 95 Kft.

GalyaTető Grand Hotal nyilvántartási rendszer

Az Invitel adatközponti virtualizációja IBM alapokon

TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK

Átfogó megoldás a számlafolyamatok felgyorsításához ELO DocXtractor. Laczkó Kristóf ELO Digital Office Kft. Bálint András Prognax Kft.

Cloud Akkreditációs Szolgáltatás indítása CLAKK projekt. Kozlovszky Miklós, Németh Zsolt, Lovas Róbert 9. LPDS MTA SZTAKI Tudományos nap

NEMZETI MUNKAÜGYI HIVATAL Szak- és Felnőttképzési Igazgatóság

Intégro CLIA. A klímavezérlő számítógép általános ismertetése

NOLLEX Nemzetközi Kft. Magyarországi kizárólagos disztribútor.

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

ÓBUDAI EGYETEM Neumann János Informatikai Kar Informatikai Rendszerek Intézet Témavezető: Bringye Zsolt

Népszámlálás Taby Tamás. szenior projektvezető

ÁLTALÁNOS SZERZŐDÉSI FELTÉTELEK

BMD Rendszerkövetelmények

itsmf Magyarország Szeminárium november 6. ITIL, Wiki és Pareto találkozása a request fullfillment fejlesztése érdekében

V & V Feladatok. V & V Feladatok

Az azonosító számú, Internetes alkalmazásfejlesztő megnevezésű elágazás szakmai követelménymoduljainak

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

Projektterv. Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi

Webes alkalmazások fejlesztése 10. előadás. Webszolgáltatások tesztelése (ASP.NET Core) Cserép Máté

Statikus technikák: A szoftver átvizsgálása. Statikus technikák: A szoftver átvizsgálása

Biztonsági folyamatirányító. rendszerek szoftvere

5G technológiák és felhasználási esetek

TANÚSÍTVÁNY (I-ICZRT08T_TAN) MELLÉKLETE

JSF alkalmazások teljesítményhangolása JMeter és dynatrace segítségével

IP Thermo for Windows

Folyamatok rugalmas irányítása. FourCorm Kft.

BlackBerry Professional Server szoftver

Visual Studio 2012 és MSDN. Csomagok és licencelés

Médiatár. Rövid felhasználói kézikönyv

április 24. INFO Savaria április 24. INFO Savaria április 24. INFO Savaria

Minőségi téradat-szolgáltatások. fejlesztése és. és üzemeltetése

Követelmény alapú minőségbiztosítás az államigazgatásban

A szoftver tesztelés alapjai

TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS

Sigfox, LoRa, Narrow Band IoT hálózatok az okos-városok szolgálatában. Budapest, , Kiss Olivér, ELKO EP Hungary Kft.

ORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZÖK FEJLESZTÉSE - PEMS V&V

WebService tesztelés. SOAPui Pro, GreenPepper és Confluence használatával. Verhás & Verhás Szoftver Manufaktúra KNOW-HOW

TESZTMENEDZSMENT A TESZT ELŐREHALADÁSÁNAK FELÜGYELETE ÉS IRÁNYÍTÁSA KONFIGURÁCIÓ MENEDZSMENT KOCKÁZAT ÉS TESZTELÉS INCIDENSMENEDZSMENT

Orvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT

HaXSoN Nyílt forráskódú, zárt informatikai rendszer

SZÁMÍTÓGÉP AZ IRODÁBAN KÉPZÉSI PROGRAM

Automatikus szivárgáskeresés Zajszint-adatgyűjtő hálózat korrelátoros funkcióval

Szoftverminőségbiztosítás

NightHawk AccessControl

Gyors telepítési útmutató AC1200 Gigabit kétsávos WLAN hatótávnövelő

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

HÁLÓZATBIZTONSÁG III. rész

Programrendszerek tanúsítása szoftverminőség mérése

A L i n u x r u h á j a

Átírás:

Test plan Okoshaz projekt Csapattagok: Bak Henrik 2016 Ferenczi Viktor Harkai Tamás Maróy András

1. Teszt terv azonosító Okosház teszt terv 1.0 A teszt terv az IEEE 829 1998 as szabványt követi, noha ettől elemeiben eltérhet. További figyelembe vett szabványok: IEEE 1008, 1012, 1059 és 1074. 2. Bevezetés A fejlesztések lényeges eleme az elkészült rendszerek részletes tesztelése, vizsgálata. Az Okosház projekt sem kivétel: az elvárt minőséget csak akkor lehet biztosítani, ha a tesztelés megfelelő. A szoftvertesztelés a szoftverminőség biztosítás és így a szoftverfejlesztés részét képezi. A tesztelés egy rendszer vagy program kontrollált körülmények melletti futtatása, és az eredmények kiértékelése. A hagyományos megközelítés szerint a tesztelés célja az, hogy a fejlesztés során létrejövő hibákat minél korábban felfedezze, és ezzel csökkentse azok kijavításának költségeit. A tesztelés az előre elkészített teszt forgatókönyv alapján zajlik. A forgatókönyvben a rendszer megjelenésével és funkcióival kapcsolatos feladatok vannak felsorolva, amelyeket el kell végezni, és az eredményüket rögzíteni kell. A tesztforgatókönyv a fejlesztési leírás vagy rendszerterv alapján készül, így a rendszer funkcióira, illetve azok elvárt, helyes működésére vonatkozólag teljeskörű vizsgálatot nyújt. Jelen teszt terv célközönsége lefedi a projekt összes résztvevőjét, a fejlesztőktől a release managerekig bezárólag. Célja, hogy egy olyan átfogó leírást nyújtson a szoftver tesztelésének folyamatáról és követelményeiről, amely támpontot adhat minden résztvevő számára.

3. Célkitűzések a teszteléssel kapcsolatban A tesztelés célja a rendszer ellenőrzése abból a szempontból, hogy a működése a megrendelő által elvárt módon lett e megvalósítva, valamint az esetlegesen előforduló hibák kiszűrése. Abból az elvből kiindulva, hogy 100% osan kész, hibamentes rendszer nem létezik, a tesztelés végső célja a program olyan végrehajtása, amelyben a szándék a hibák megtalálása. További cél a szoftverminőség vizsgálata, és az ebből keletkező következmények levonása. 3. Általános tesztelési elvek A tesztek végzése során az alábbi alapelvekből indulunk ki. A teszteket előre meg kell tervezni. Egy teszteset terve tartalmazza a kiindulási állapot leírását, a végrehajtott lépéseket, és a várt eredmény állapotot. A teszt sikeres, ha a kapott eredmény megegyezik a várt eredménnyel. Ellenkező esetben a teszt sikertelen. Az eredményességet jegyzőkönyvben kell rögzíteni. A teszteknek reprodukálhatóaknak kell lenniük. Minden tesztelés eredményét rögzíteni kell. Az automatikus tesztek eredményei naplófájlba kerülnek. A kézzel végzett teszteknél jegyzőkönyvet kell írni. 4. Teszt típusok

Teszt fajta Unit tesztek (white box tesztek) Kód lefedettség mérés Funkcionális teszt (Black box) Integrációs teszt Teljesítmény teszt Kézi tesztek Célja Osztályok és függvények alapos tesztelése, speciálisan erre a célra írt kódokkal. A unit tesztekkel elért kód lefedettség mérése. A követelményspecifikációnak való megfelelés és a funkciók működőképességének vizsgálata. Az egyes rendszerkomponensek együttműködésének vizsgálata. A rendszer teljesítményének vizsgálata. A rendszer komplex tesztelése. 4.1 Unit (white box) tesztek Unit tesztek készülnek, melyek alacsony szinten, függvényenként, vagy néhány függvény együtteseiként teszteli a működést. A unit tesztek feladata a teszteset kiindulási állapotának felállítása, és a várt eredmény létrejöttének ellenőrzése is. A teszteseteknek tartalmaznia kell helyes adatokat, rossz adatokat, és szélsőérték adatokat is. A unit teszteket a JUnit teszt keretrendszer segítségével minden build re automatizáltan lefuttatjuk. 4.1.1 Mérhető cél Minden unit teszteset sikeresen lefut. 4.2 Kód lefedettség mérés

A code coverage (lefedettség mérés) egy olyan technika, mellyel az mérhető, hogy a kód mely részei futottak le. Folyamata: összehasonlítjuk a forráskódot, valamint azt, hogy egy konkrét teszt készlet (test suite) végrehajtása során ténylegesen a kód mely sorai futottak le. Emiatt a white box tesztelés egy formája. Ez a folyamat automatizált. A code coverage célja olyan kódrészletek megtalálása, melyekre a teszt során nem került a vezérlés, valamint pl. olyan feltételek kiválasztásra, melyeknek csak egyik ága futott le. 4.2.1 Mérhető cél Kódokon: >80% lefedettség. 4.3 Funkcionális (black box) tesztek A unit teszteknél összetettebb, a rendszer működési logikájának egy egy teljes ágát átfogó tesztek. A tesztesetek a követelmény specifikáció alapján készülnek, céljuk a rendszer technikai követelményeknek és a felhasználási eseteknek való megfelelését vizsgálata. 4.3.1 Mérhető cél Minden funkcionális teszt sikeresen lefut. 4.4 Integrációs tesztek A vizsgálat célja, hogy megállapítsa, hogy a rendszer alkotóelemei egymással képesek e együttműködni, valamint az önmagukban működőképes szolgáltatások képesek e a kommunikációra. 4.4.1 Mérhető cél Minden szolgáltatás képes a tőle függő rendszereket kiszolgálni, és a felette álló rendszereket megszólítani, illetve adatokkal ellátni.

4.5 Teljesítmény teszt A performancia tesztelés célja a rendszer válaszidejének, átviteli sebességének és határainak, megbízhatóságának és skálázhatóságának a tesztelése. 4.5.1 Mérhető cél Az előzetesen meghatározott teljesítményszámok teljesítése. 4.6 Manuális tesztek Az automatizált tesztek nem fedik fel a felhasználhatósági, vagy az összetettebb logikai problémákat. Alapvetően feltételezzük, hogy az automatizmusok nem helyettesítik az emberi intelligenciát, probléma felismerő képességet, és a teszteléshez szükséges kreativitást. Ezért legalább a felhasználási eseteket és a felhasználói felületről elérhető funkcionalitást manuálisan is tesztelni kell. 4.6.1 Mérhető cél Minden forgatókönyv sikeresen végigmegy. 5. Az Okosház projekt tesztelése, kritikus pontjai Az Okosház projekt tesztelése átfogó feladat, hiszen a projekt több különálló, mégis egységben kezelendő részből áll, amelyek a rendszer kritikus pontjainak tekinthetők: Kliens alkalmazás Egy olyan program telefonra és tabletre, amivel az házban lévő intelligens rendszerrel kapcsolatban lévő eszköz vezérelhető, időzíthető, programozható. Az összes funkció innen érhető el a felhasználók számára. Központi szerver

Itt található a központi adatbázis, ami a felhasználók által adott utasításokat tartalmazza. Az adatbázis mellett fut egy szerveroldali kód is, ami kommunikál az okos eszközökkel a felhasználó utasításai alapján. Okoseszközök Az összes olyan eszköz ide sorolható, ami kapcsolatban áll a központi rendszerrel, és felhasználó távolról tudja működtetni valamely eszközéről. Jelen teszt terv feltételezi, hogy a fejlesztői csapat végzi a 4.1 és 4.2 tesztmódszerekkel történő tesztelést, így a továbbiakban csak a fennmaradókra koncentrálunk. 6. Tesztelt funkciók A tesztelt funkciók kiválasztásánál elsőbbséget élveznek azok a funkciók, amelyek kritikusak a felhasználó szempontjából, például fűtés télen. Így elsődleges hangsúlyt élveznek tesztelés során az alábbi funkciók: Fűtés szabályozás Riasztó rendszer Ajtó nyitás zárás Világítás szabályozás Ezeknél mind közös pont, hogy a felhasználó mindennapi életét közvetlenül érintik, és nem csak kényelmi lehetőségekről van szó. 7. Elfogadási kritérium ok a funkciókra A projekt során az egyik legfontosabb alapelv az, hogy a rendszernek bármilyen körülmények között a funkcióját be kell töltenie. Azaz internet kiesés esetén is a fűtés nem állhat le, a zárnak kinyithatónak kell lennie, és

így tovább. Ezeknek az elvárásoknak meg kell jelenniük az elfogadási kritériumokban is. 7.1 Fűtés szabályozás A fűtés szabályozásnak működnie kell bármilyen a fűtés rendszert magát nem éríntő szolgáltatás kiesés esetén is. A rendszernek távolról frissíthetőnek kell lennie, még egy hibás frissítés után is. A felhasználó könnyen megadhasson idő hőmérséklet görbéket a hét minden napjára, minden szobára. Lehetőség különböző profilok megadására. 7.2 Riasztó rendszer A kamerák képe távolról megfigyelhető legyen. Riasztási feltételek megadása. Lehetőség a rendőrség vagy tűzoltóság automatikus értesítésére. 7.3 Ajtó nyitás zárás Hagyományos kulcsos bejutásnak minden esetben prioritása van. Áram vagy egyéb infrastruktúra kiesés esetén kulccsal való bejutásnak működnie kell. Lehetőség hozzáférés megosztására zárakhoz külön külön. Értesítés küldése a felhasználónak a zárak használata esetén. 7.4 Világítás szabályozás Az okos égők csoportosíthatóak legyenek szobánként. Választható tetszés szerinti szín és fényerő. Profilok létrehozásának lehetősége és váltás ezek között gombnyomásra illetve időzítve.

8. Fobb tesztesetek leírása általánosan 8.1 A fűtés tesztelése: A fűtés tesztelésére több használati esetet tesztelünk: Rendelkezünk mind az elektromos, mind az internet hálózattal. (általános eset) Rendelkezünk elektromos hálózattal, de nincs internet elérésünk. (probléma a routerrel, vagy az internet szolgáltatóval) Van internetes hozzáférésünk, de az elektromos hálózat nem érhető el. (elektromos áramszünet, router szünetmentes táppal) Nem rendelkezünk sem elektromos áram, sem hálózati kapcsolattal (legrosszabb eset) Minden esetben ellenőriznünk kell az összes helyiséget ahol a fűtésirányító szabályzók fel lettek szerelve. A megfelelő működés alatt azt értjük hogy a megadott hőfok van az adott helységben. Tesztelés pedig manuálisan, hőmérséklet egy a teszteléshez használt hőmérő szerkezettel való lemérésével történt. 8.2 Riasztó rendszer tesztelése: A riasztó rendszer tesztelésére több használati esetet tesztelünk: Nem ad életjelet a rendszer(elfogyott a pénz a gsm kártyáról, vagy meghibásodott a rendszer) Téves riasztás(érzékelők meghibásodása) Riasztáskor nem ad sziréna hangot(sziréna meghibásodása)

Kamerarendszert nem lehet távolról elérni(nincs internet kapcsolt, elektromos áramszünet, a szünetmentesek is lemerültek) Minden esetben ellenőriznünk kell az összes helyiséget ahol a kamerák és a riasztó szenzorai fel lettek szerelve. A megfelelő működés alatt azt értjük hogy a megadott szenzorok megfelelően kapcsolnak és a kamerák a megfelelő irányba vannak pozícionálva és rögzítenek a központban. Tesztelés pedig manuálisan a szenzorok és a központ letesztelésével történt. 8.3 Ajtó nyitás zárás tesztelése: Az ajtó nyitás zárás rendszer tesztelésére több használati esetet tesztelünk: Nem lehet bejutni(van áramforrás, de nem működik a beléptető rendszer) Nem lehet bejutni(nincs áramforrás) Nem lehet bejutni(nem fogadja el a kulcsot) Minden esetben ellenőriznünk kell az összes ajtót. A megfelelő működés alatt azt értjük hogy a megadott ajtók ki és becsukása megfelelően müködnek. Tesztelés pedig manuálisan az ajtók ki és bezárásával történik. 8.4 Világítás szabályzásának tesztelése:

A világítás szabályzás rendszer tesztelésére több használati esetet tesztelünk: Nem kapcsol be a rendszer(nincs áramforrás, elromlott a kapcsoló) Nem veszi le a fényerőséget a rendszer(elromlott a fényérzékelő szenzor) Nem jól veszi le a fényerőt a rendszer(a szenzort újra kell kalibrálni) Minden esetben ellenőriznünk kell az összes helyiséget ahol ez a fajta világítás fel lettek szerelve. A megfelelő működés alatt azt értjük, hogy a megadott helységekben a megadott szenzorok a megfelelő lámpákat szabályozza. Tesztelés pedig erre a célra gyártott és fejlesztett fényérzékelő és sötétitő szenzorokkal oldjuk meg a pontos % beálítások miatt. 9. Teszt kimenetek A tesztelés kimenete egy dokumentum, a teszt jegyzőkönyv, mely tartalmazza a szoftver tesztelés során használt teszteseteket. Rögzíti a tesztesetek részletes leírását lépésenként, pontokba szedve, valamint a teszteseteknél várt kimenet összehasonlítását a teszteset futtatása/tesztelése során létrejött outputtal. A szoftver akkor megy át sikeresen a tesztelésen, ha az összes tesztesetnél az elvárt outputot kapjuk.

10. Tesztelői csapat összeállítása és a szükségleteink 10.1 A tesztelői csapat A tesztelői csapatunk az alábbiként épül fel: Teszte lő Tapaszta lat (év) Elemző képess ég Szakm ai ismere t Adatbá zis ismeret Biztons ági ismeret Fejleszt ői képess ég Kreativit ás Monotonit ás tűrése Bak Henrik Ferenc zi Viktor Harkai Tamás Maróy András 6 4 4 2 2 5 2 1 3 3 3 5 1 4 4 2 2 5 3 3 1 4 4 3 3 4 4 2 5 4 3 5 10.2 Tesztelői környezet Minőségi teszteket csak megfelelő eszközökkel lehet elvégezni. Amennyiben nincsenek meg a feladathoz az infrastukturális feltételek, az a projekt sikerességét veszélyezteti. További szempont a munkatársak elégedettsége és motivációja: elavult, nem megfelelő eszközökön végzett munka negatívan befolyásolja a tesztelők motivációját, ezzel szintén negatív spirált hozva létre. Ezek miatt a minimális konfiguráció tesztelői számítógéphez az alábbi:

Intel Core i5 6400 2.7 GHz Processor (4 core) 128 GB SSD 500 GB HDD 8 GB RAM (projekttől függően ez 16 GB is lehet) Dual monitor, legalább 23 A számítógépek minimális szoftver követelményei: Dual OS (Windows 10 és Linux) Microsoft Office programcsomag IntelliJ Community Edition fejlesztői környezet (esetleges kisebb fejlesztői feladatok ellátására)