Dátum | Verzió | Leírás | Szerzők |
2017. december 10. | 0.1 | Béta verzió | Csuzda Péter Kiss Máté Reisz Ákos Szabó Dávid Tóth Péter |
2017. december 15. | 1.0 | Tördelés, kiadásra kész verzió | Szabó Dávid Tóth Péter |
Tesztelés
Tartalomjegyzék
1. Bevezetés
Ebben a dokumentumban az általános használt tesztelési eljárások közül azokat mutatjuk be amelyeket mi is használunk, továbbá ezeknek a használati módjára térünk ki.
Manuális tesztek
2. Manuális tesztek
Ezen teszteket úgy hajtjuk végre, hogy a lenti leírásokat pontosan követi egy tesztelő, majd ellenőrzi a végeredményt.
2.1 Felhasználó lámpa kapcsolás útvonal
Alkalmazás megnyitása
Username és Password együttes beírása
Login gomb
Lighting gomb
Kívánt eszköz le vagy felkapcsolása
Várt eredmény: A kívánt eszköz fel/le kapcsol.
2.2 Fűtés állítása a webes felületen
Alkalmazás megnyitása
Username és Password együttes beírása
Login gomb
Climate gomb
Kívánt hőfok beírása számmal
Várt eredmény: A rendszer beállítja a fűtés vezérlést
3. Automatizált tesztek
3.1 Terhelésteszt
Nagy mennyiségben szimulálunk rendszerbe való belépést azonos időben, valamint ezzel párhuzamosan számos háztartásból érkező lámpa kapcsolást. Ezzel tesztelve, hogy a válaszidő a megengedett tartományban legyen (A specifikációban foglaltak szerint maximum 1 mp).
3.2 SQL injection
SQL injection tesztelés esetén ugyan úgy kell eljárni mint a hibás felhasználónév vagy jelszó megadásánál, annyi különbséggel, hogy ez esetben speciális beérkező értéket adunk meg, amely SQL parancsként le kéne, hogy fusson. Például: user mező: “or 1=1;-- “
3.3 Slowloris
Ennél a tesztelésnél, a rendszerhez a lekérést nagyon lassú sebességgel küldjük, ez a üzenet küldési idő több, mint a rendszer specifikációban megadott időtúllépési keret (30 mp), majd időtúllépési hiba üzenetet ad és megszakítja a feldolgozási folyamatot.
4. Komponens teszt
Az összetevő tesztelés (ismeretes mint egység, modul és program tesztelésként is) a hibákat keresi és ellenőrzi a szoftver modulokat, programokat, objektumokat, osztályokat, stb, amelyek külön-külön tesztelhetőek. Elvégezhető a rendszertől elszigetelt környezetben is, ez a fejlesztési élet ciklus és a rendszer kontextusától függ. Helyettesítő függvények (amelyek a tesztelés szempontjából úgy viselkednek mint a valódi függvények, angolul stubs), illesztőprogramok és szimulátorok használhatóak.
Az összetevő tesztelés magába foglalhatja a közvetlen funkciók és a nem közvetlen funkciók tesztelését, mint az erőforrás viselkedését (pl: memória szivárgás keresése) vagy robosztusság tesztelés, mint a strukturális tesztelés (pl: döntési lefedettség). A teszt váza a terméktől függ, mint például a komponensek specifikációja, a szoftver modellje, vagy az adatmodelje.
Jellemzően az összetevő tesztelés során a kódot teszteljük, majd a tervező környezet segítségével, a teszt keretrendszerrel és a hibakereső eszközzel javítjuk. Gyakorlatban viszont, a kódot készítő programozó bevonásával zajlik. A hibákat leggyakrabban a megtalálásukkor javítjuk.
4.1 Bejelentkezés során hibás felhasználó név beírása
Hibás userName beírás
ReturnStatus:a boolean értéke false lesz, a Message-ben kiírja, hogy hibás felhasználónevet vagy jelszót adott meg.
4.2 Bejelentkezés során hibás jelszó megadása
Hibás password megadása
ReturnStatus:a boolean értéke false lesz, a Message-ban kiírja, hogy hibás felhasználónevet vagy jelszót adott meg.
5. Integrációs teszt
Integrációs teszt során teszteljük az interfészeket a komponensek között, az interakciókat a rendszer különböző részei között, mint az operációs rendszer, fájlrendszer, hardver.
Lehetséges többszintű integrációs teszt futtatása, és
Minél nagyobb az integráció kiterjedtsége, annál nehezebbé válik az adott komponens vagy rendszer elszigetelése. Ez fokozott kockázathoz vezethet és több időbe telhet a hibaelhárítás.
A nem funkcionális követelményeket (pl: teljesítmény) is tesztelhetjük az integrációs teszt során, valamint a funkcionális teszt során is.
Az integráció minden szakaszában a tesztelők kizárólag az integrációra koncentrálnak. Például ha integrálják az A modult a B modullal, akkor a két modul közötti kommunikációra kíváncsiak, nem pedig az adott modul funkciójára. Azt a komponens teszt során tesztelik. Mind funkcionális és strukturális megközelítés használható.
Ideális esetben a tesztereknek érteniük kellene az architektúrát és az integrációs tervezés hatását. Ha az integrációs tesztet a komponens vagy rendszer elkészítése előtt tervezik meg, akkor ezeket a komponenseket úgy készítik el, hogy a leghatékonyabban szerepeljenek a teszten.
6. Rendszertesztelés
Rendszertesztelés a rendszer, termék teljességének a viselkedését vizsgálja. A tesztelés kiterjedésének minden szinten világosnak kéne lennie.
A rendszertesztelésben a tesztelési környezetnek meg kéne felelnie a valós világban állított követelményeknek, annyira hogy csökkentse a környezetspecifikus hibákat amiket a tesztelés során nem lehetett felfedezni.
Rendszertesztelésnek ki kell terjednie a kockázatokon és/vagy követelményeken alapuló tesztekre, use case-ekre vagy a magasabb szintű szöveges leírásokra, az operációs rendszerrel való interakciókra és a rendszer erőforrásaira.
7. Tesztelés kiterjedése
A rendszer tesztelésnek vizsgálnia kell funkcionális és nem funkcionális követelményeit a rendszernek. A tesztelőknek számolniuk kell a félkész, valamint az ismeretlen követelményekkel is. A funkcionális követelmények tesztelését a black-box tesztelési eljárással kell kezdeni. A black-box-nál, a kódot nem ellenőrizzük, a kimeneti értékeket vizsgáljuk a bemeneti értékek függvényében. White-box eljárás a black-box ellentéte, tesztelésnél, a forrás kódot ellenőrizzük.
8. Tesztelési eljárás a HomeWare-nél
Gyakran független csoportok is végezhetik a rendszer tesztelést.
A mi rendszerünk tesztelése során az alacsonyabb szintű teszteléseket a fejlesztők és/vagy annak környezetében levők végzik, a fontosabb, nagyobb lélegzetű (teljes rendszertesztelés, biztonság, stb) teszteléséhez pedig külső tesztelőket is bevonunk.