Okosház Test Plan. Tartalomjegyzék

Átírás

1 Okosház Test Plan Tartalomjegyzék Tartalomjegyzék 1. Bevezetés 2. Célkitűzések és feladatok 2.1 Célkitűzések 2.2 Feladatok 3. Tesztelendő funkciók 4. Nem tesztelendő funkciók 5. Teszt stratégia, tesztelési szintek 5.1 Egység tesztelés 5.2 Modul tesztelés 5.3 Rendszer és integrációs tesztelés 5.4 Automatizált regressziós tesztelés 5.5 Felhasználói jóváhagyás tesztelés 6. Hardver követelmények 7. Környezeti követelmények 8. Teszt ütemezés 9. Incidens menedzsment 10. Ütemterv 11. Kockázatok 12. Felhasznált eszközök

2 1. Bevezetés Ez a dokumentum az Okosház nevű projekt teszt tervezetét tartalmazza. A projekt egy épületet takar, melyben a különböző háztatársi gépek és eszközök egy olyan közös hálóztra csatlakoznak amin kereszt felügyelhetők és vezérelhetők. Az Okozház fő szempontjai között szerepel a biztonság, a kényelem és az energiatakarékosság, főbb funkciói pedig a következők: Fűtés szabályozás Légkondícionálás szabályozása Redőnyök működtetése Öntözés vezérlés Ajtó nyitás/zárás Világítás szabályoás Riasztó rendszer programozása Automatizált feladatok/napi rutinok 2. Célkitűzések és feladatok 2.1 Célkitűzések Ezen dokumentum célja az Okosház projekttel kapcsolatos szoftvertesztelés egyes fázisainak és az egyes fázisokon belül végrehajtandó specifikus tesztelési feladatoknak a leírása. A teszt tervezet továbbá kitér hardver és környezeti követelményekre, a teszt ütemezésre, az incidens menedzsmentre, a tesztelési ütemtervre és a kockázatok elemzésére. 2.2 Feladatok A projekt keretein belül megvalósítandók a következő teszteléssel kapcsolatos feladatok: Egység tesztelés

3 Modul tesztelés Rendszer és integrációs tesztelés Automatizált regressziós tesztelés Felhasználói jóváhagyás tesztelés 3. Tesztelendő funkciók A tesztelés menete az alább felsorolt, mobil alkalmazásokkal (Android, ios) és webes felületen keresztül elérhető illetve távvezérelhető funkciókra vonatkozik. Monitorozás Hőmérséklet Páratartalom Fényviszonyok Fűtés szabályozás Manuális fűtési szabolyozás Automatikus fűtés szabályozás a kinti hőmérsékletnek megfelelően Időzített fűtés szabályozás Légkondícionálás szabályozása Manuális légkondíconálás szabályozás Automatikus légkondícionálás szabályozás a kinti hőmérsékletnek megfelelően Redőnyök működtetése Manuális redőny működtetés Automatikus redőny működtetés a kinti fényviszonoknak megfelelően Öntözés vezérlés Manuális öntözés vezérlés Automatikus öntözés vezérlés Időzített öntözés vezérlés

4 Ajtó nyitás/zárás Manuális ajtó nyitás/zárás Automatikus ajtó nyitás/zárás Világítás szabályozás Manuális világítás szabályozás Automatikus világítás szabályozás a kinti fényviszonyoknak megfelelően Időzített világítás szabályozás Riasztó rendszer programozása 4. Nem tesztelendő funkciók A tesztelés nem terjed ki az alábbi funkciókra: Nem mobil alkalmazással vagy webes felületről történő távirányítású vezérlés, monitorozás Az egyes funkciók közvetlen (nem távirányítás alapú) vezérlése Az egyes funkciókkal kapcsolatos hardver komponensek helyes működése 5. Teszt stratégia, tesztelési szintek A tesztelési stratégia az alábbi tesztelési szinteket határozza meg: 1. Egység tesztelés 2. Modul tesztelés 3. Rendszer és integrációs tesztelés 4. Felhasználói jóváhagyás tesztelés A legalacsonyabb tesztelési szint az egység tesztelés célja biztosítani az egyes rendszer komponensekkel kapcsolatos főbb funkciók helyességét és működőképeségét. A modul tesztelés feladatköre az egymással szorosabban összefüggő rendszer funkciók tesztelése, mint pl. fűtés szabályozás, öntözés vezérlés.

5 A rendszer és integrációs tesztelés célja az egyes rendszer komponensek összehangolt (akár egyidejű) működésének a tesztelése. A felhasználói jóváhagyás tesztelés a telepített rendszerrel és a kész szoftverrel való felhasználó tesztelést jelent, aminek a során az ügyfél maga bizonyosodhat meg a rendszer helyes működéséről. A teszt stratégia továbbá magába foglalja az automatikus regresszisó tesztelést is annak érdekében, hogy a már működő és tesztelt rendszer komponensek ne romolhassanak el akaratlanul egy későbbi firssítés következtében. 5.1 Egység tesztelés Definíció: Az egység tesztelés feladata az egyes rendszer komponensek főbb funkcióinak a tesztelése és ellenőrzése úgy mint pl. világítás szabályozás manuális kontrollálása, vagy a légkondícionálás automatikus vezérlése. Résztvevők: Egység tesztelésre kijelölt programozók. Módszertan: Az egység tesztelés az alábbi két alapvető feladatból áll: 1. A tesztelendő funkciók meghatározása 2. Teszt esetek megírása a meghatározott funkciókhoz A tesztelendő funkciók meghatározásában és a teszt esetek implementálásában minden egység tesztelésre kijelölt fejlesztő részt vesz, így biztosítva a megfelelő kód lefedettséget és a más által írt tesztek helyességének az ellenőrzését. A kód lefedettség folyamatosan ellenőrizendő, az egyes teszt eseteknek pedig manuálisan illetve automatikus regressziós tesztelés által is futtathatónak kell lennie. Minden egyes fontosabb funkció implementálása után egy hozzá tartozó egység tesztet is implementálni kell, így bitosítva a megfelelő kód lefedettséget.

6 5.2 Modul tesztelés Definíció: A modul tesztelés feladata az egymáshoz szorosabban kapcsolódó rendszer funkciók egy egységként való tesztelése ezáltal biztosítva a kapcsolódó funkciók együttműködésének a helyességét. Az Okosház projekten belül modul alatt értendő pl. a világtás szabályozással kapcsolatos összes funkció, úgy mint a manuális és az automatikus világítás szabályozás. Külön modulnak tekintendő a mobilos alkalmazások és a webes felület által kínált ugyan azon funkciók együttese. Résztvevők: Modul tesztelésre kijelölt programozók. Módszertan: Az egység teszteléshez hasonlóan a modulokra vonatkozó teszt eseteknek is futtathatónak kell lenniük manuálisan és automatikus regressziós tesztek által is. A modulokra vonatkozó teszteseteknek a modulok főbb funkcióit kell takarniuk, különös tekintettel a külsőleg (esetlegesen más modulokból) is elérhető funkciókra. 5.3 Rendszer és integrációs tesztelés Definíció: A rendszer és integrációs tesztelés célja, a rendszer egyes moduljainak valamint a rendszer egészének az összehagolt tesztelése. Résztvevők: Rendszer és integrációs tesztelésre kijelölt tesztelők. Módszertan:

7 A rendszer és integrációs tesztelés esetében a rendszert alkotó hardver komponensek és az elkészült szoftver együtt tesztelendő. Az egyes rendszer modulok (beleértve a hardvert és szoftvert is) egymástól függetlenül és együttesen is tesztelendők. 5.4 Automatizált regressziós tesztelés Definíció: Az automatizált regressziós tesztelés célja a korábban elkészült egység és modul tesztek automatikus futtatása egy egy újabb funkció kifejlesztésekor. Ezáltal automatikus ellenőrizhető, hogy a korábban megírt funkciók továbbra is helyesen működnek. Résztvevők: Nincs résztvevő (automatikus) Módszertan : Az automatikus regressziós tesztek egy távoli szerveren, egy előre beállított környezeten automatikusan futnak a nap 24 órájában. A tesztelés akkor lép életbe, amint egy fejlesztő új egység vagy modul tesztet tölt fel projekttel kapcsolatos kód respository ba. A tesztek lefutása után, a rendszer automatikusan kíszített report ok formájában értesíti a fejlesztőket a tesztek sikerességéről. 5.5 Felhasználói jóváhagyás tesztelés Definíció: A felhasználói jóváhagyás tesztelés célja, hogy az ügyfél maga is megbizonyosodhasson a rendszer helyes működéséről valamint a szerződésben foglalt követelmények megvalósulásáról. A felhasználói jóváhagyás tesztelés a már telepített, beüzemelt és használatra kész rendszerrel vagy annak az egyes komponenseivel történik gyakorlati használatot szimulálva. A ügyfél esetleges visszajelzései által az egyes rendszer funkciók módosíthatók, vagy bővíthetők. Résztvevők:

8 Ügyfél Teszt menedzser Módszertan: A felhasználói jóváhagyás tesztelés akkor kezdődhet meg, ha legalább egy rendszer komponenshez (modulhoz) telepítve lettek a szükséges eszközök (hardver) és a vezérlésükhöz szükséges szoftver is tesztelésre készen áll. Az egyes rendszer komponensek külön külön és együttesen is tesztelendőek. A tesztelést minden esetben az ügfél végzi, hogy megbizonyosodhasson a rendszer helyes működéséről. A tesztelés kezdetén az ügyfelet informálni kell az egyes rendszer modulok működéséről, továbbá a vezérlésükkel kapcsolatos tudnivalókról. 6. Hardver követelmények Egyéni munkaállomások, az egység és a modul tesztek futtatásához Központi szerver az automatizált regressziós tesztek futtatásához Telepített és beüzemelt rendszer komponensek a rendszer és integrációs teszteléshez, valamint a felhasználó jóváhagyás teszteléshez A fennakadásmentes teszteléshez az alábbi hardverkövetelményeket támasztottuk munkaállomásaink irányában, mellyel minden, teszteléssel foglalkozó alkalmazottunk egyénileg rendelkezik: 16 Gb RAM 1 Tb HDD 256 Gb SSD Intel Core i5 negyedik generációs processzor Szélessávú internet hozzáférés Megfelelő input perifériák LCD Monitor 24

9 7. Környezeti követelmények Magasan képzett szakembereink a fentebb említett hardvereszközökkel rendelkeznek. Csapatunkon belül elvárjuk munkatársainktól, hogy elérhetőek legyenek különböző online felületeken. Minden alkalmazottunk egyedi, céges fiókkal rendelkezik, valamint különböző azonnali üzenetküldő alkalmazásokon érhető el, például Skype, Slack. Ezen termékek esetén lehetőség van különböző, beosztás vagy témakör szerinti csatornák létrehozására, így ha szükséges elérnünk valakit, mindig tudjuk hol keressük, mely nagyban növeli a produktivitást. A tesztelés lefolyásához szükséges különböző, platformfüggő eszközök (teszt automatizáló, elemző, fejlesztőprogramok) mindegyike rendelkezésünk rá, melyeket szakmai tapasztalataink segítségével gond nélkül tudunk üzemelni. Mivel az Okosház alkalmazáshoz hozzárendelt berendezések felhasználóink életének szerves részét képezik, rendkívül fontos, hogy megfelelően kezeljük a biztonsági kérdéseket. A teszt környezethez vagy a felhasználóink adataihoz való hozzáférést csak az arra jogosult személyek kaphatják meg, melynek során kötelezzük őket a hatályos személyi jogi adatkezelési törvények és az etikai kódexünk betartására. A fentiek alapján úgy gondoljuk, minden környezeti és személyes követelmény adott a tesztelés sikeres lefolytatásához, és nagy valószínűséggel nem lesz szükség a projekt során további beruházások lefolytatására. 8. Teszt ütemezés [...] 9. Incidens menedzsment Probléma jelentés Az incidensek jelentése a Redmine rendszer felületén történik. A projekt oldalán a Feladatok menüpont alatt kell felvenni a talált hibákat. A státusz alapvetően új, ezt

10 csak a jogosultsággal rendelkező emberek állíthatják át. A webes felületen minden mező értelemszerűen kitölteni, azonban fontos: a reprodukálás pontos lépéseit kötelező megadni, leírni. Legtöbb esetben érdemes log okat is mellékelni. Változtatási kérelem [...] 10. Ütemterv Főbb teljesítések [...] Leadandó anyagok, dokumentációk: Jelen dokumentum, azaz a Test Plan Tesztesetek Teszt riportok Incidens riportok Tesztelési tevékenység összegzése 11. Kockázatok A projekt során különböző kockázati tényezők jelenlétét is figyelembe kell vennünk. Természetesen professzionális fejlesztőgárdával rendelkezünk, így a legtöbb problémát már a megfelelő megelőzéssel el tudjuk hárítani. A fejlesztés során az alábbi kockázatos esetekkel számolunk: Szoros határidő, késés: ezt megfeleő kommunikációval és időszükséglet becsléssel próbálhatjuk megelőzni, valamint szükség esetén több műszakban, vagy további, emberi vagy fizikai erőforrással gyorsíthatjuk fel a tesztfolyamatot

11 Természeti károk: naprakész biztonsági mentésekkel rendelkezünk adatainkról a Föld különböző pontjain elhelyezett szervereink, és a velük való gyakori szinkronizáció segítségével Új, váratlan hibák felbukkanása miatti csúszás: ezek lehető leghamarabbi elhárításával biztosítjuk, hogy a tesztfolyamat stabilan folytatódik tovább 12. Felhasznált eszközök Az eszközeink az éppen aktuális platformtól függően eltérhetnek, a következőkben az általánosan használt programokat listázzuk: Selenium Soap UI Test Studio eggplant NUnit JUnit Buildbot Git Gerrit BugZilla Trac Redmine