Test plan Okoshaz projekt

                     

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

2016 

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 

Célja 

Unit tesztek (white box tesztek)  Osztályok és függvények alapos  tesztelése, speciálisan erre a  célra írt kódokkal.  Kód lefedettség mérés 

A unit tesztekkel elért kód  lefedettség mérése. 

Funkcionális teszt (Black box) 

A követelményspecifikációnak  való megfelelés és a funkciók  működőképességének  vizsgálata. 

Integrációs teszt 

Az egyes rendszerkomponensek  együttműködésének vizsgálata. 

Teljesítmény teszt 

A rendszer teljesítményének  vizsgálata. 

„Kézi” tesztek 

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  (1­5) 

Szakm ai  ismere t  (1­5) 

Adatbá zis  ismeret  (1­5) 

Biztons ági  ismeret  (1­5) 

Fejleszt ői  képess ég  (1­5) 

Kreativit ás  (1­5) 

Monotonit ás tűrése  (1­5) 

Bak  Henrik 

6 

4 

4 

2 

2 

5 

2 

1 

Ferenc zi  Viktor 

3 

3 

3 

5 

1 

4 

4 

2 

Harkai  Tamás 

2 

5 

3 

3 

1 

4 

4 

3 

Maróy  András 

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)