Tesztterv¶
Dokumentumra vonatkozó adatok¶
Dokumentum száma: TT-001-EXMPL
A tervet készítette:
- Kiss Pista István, tesztelő
- Fekete Péter, tesztelő
- Metil Ibolya, tesztelő
Verziótörténet
| Verzió | Kiadás dátuma | Leírás |
|---|---|---|
| 1.0 | 2024.06.30 | A dokumentum kezdeti kiadása |
A tesztelési feladat kontextusa¶
Jelen dokumentum a XXXX/YYYY tanév tesztelés alapjai kurzus XX csapat által választott Unlucky projektjének teszttervét tartalmazza. Az Unlucky alkalmazás RNG-n (random number generator) alapuló, lépésváltásos harcrendszerrel rendelkező LibGDX Android RPG játék. Az RNG-t általában nem szeretik a játékokban, viszont ennek a játéknak az egész témája az RNG-re épül. A csatában a támadásoktól kezdve a varázslatos tárgyakon át a mozgásig minden RNG-n alapul.
A játékos különféle témájú térképeken harcol különböző szörnyekkel. Jelenleg három elérhető világ áll rendelkezésre, mindegyik 10+ szinttel. Ezeken a térképeken a játékosnak szörnyeket kell legyőznie, és meg kell találnia egy csillaglapkát a szint teljesítéséhez. A szörnyek tárgyakat dobhatnak, amelyek javíthatják a játékos erejét, vagy a játékos el is adhatja azokat.
A harcrendszer körökre osztott mechanikán alapul. A játékos négy véletlenszerűen generált lépést kap, amelyek minden színe más-más típusú lépésnek felel meg. A játékos hozzáférhet speciális mozdulatokhoz is, amelyeket a menüben választhat ki. A speciális mozdulatok bónusz hatást gyakorolnak a játékos támadásaira, vagy befolyásolják az ellenséget. A játékosnak lehetősége van arra is, hogy nagyon alacsony eséllyel elmenekülhessen a csatából.
A tesztelés célja a projekt minőségi fejlődésének elősegítése az előforduló hibák felkutatásával és a játékélmény megvizsgálásával. A kitűzött cél teljesítéséhez statikus és használhatósági teszteket alkalmazunk.
Az alkalmazás 2018.07.03-án kiadott 1.0 verziója kerül tesztelésre.
A statikus tesztek alapja az Unlucky core és desktop moduljainak forráskódja, ezeken az egységeken statikus forráskódelemzést hajtunk végre.
A használhatósági teszt bázisa a Desktop verzió felhasználói felülete, a végfelhasználói élmény kerül tesztelésre. Külön dokumentáció nem áll rendelkezésre, a projekt oldalán lévő README fájlokban található screenshootok adnak némi eligazítást.
Feltételezések és korlátozások¶
Azzal a feltételezéssel élünk, hogy az Unlucky projekt release oldalán közzétett csomagok telepíthetők, működnek. A fejlesztő a működő kód mellett annak forráskódját is közzétette, valamint a README fájlban olvashatók a fordításhoz szükséges feltételek. Itt azzal a további feltételezéssel élünk, hogy a szükséges verziók elérhetők, letölthetők, a gradle konfigurációk korrekt beállítást tartalmaznak.
A tesztelés során csak a desktop verziót teszteljük, az Androidos felület nem kerül tesztelésre.
Érdekelt felek¶
- Tesztelő csapat: a teszt tervezését és lebonyolítását végzik
- Tesztelésbe bevont önkéntesek: a játékélmény tesztelésében vesznek részt, véleményük kérdőívek segítségével kerül kiértékelésre
- Gyakorlatvezető: meghatározza a követelményeket és értékeli a teljesítéseket
- Fejlesztő: amennyiben visszajelzést kap a teszt eredményéről, lehetőséget kap a játékélmény fejlesztését szolgáló ötletek kidolgozására
Kommunikáció¶
A tesztelési projekt megvalósítása során a hivatalos kommunikációhoz az informatikai intézet által biztosított e-mail címeket használjuk, ezen keresztük kommunikálunk a gyakorlatvezetővel.
Hivatalos kommunikációs csatornának tekintjük ezenkívül a gyakorlathoz tartozó Coospace színtér fórumát, de ezen keresztül csak a publikus információk kerülnek megosztásra. Privát információk közléséhez kizárólag az intézet által biztosított e-mail címeket használjuk.
A projektkommunikáció történhet személyesen, vagy online meetingeken keresztül, amelyhez a Discord XXXX csatornát használjuk. A meetingekről minden esetben memo készül.
Kockázatmenedzsment¶
Kockázatcsökkentési lehetőségek:
- Projekt felénél és a végénél nem vagy csak nagyon kevés feladatot ütemeztünk be, hogy az esetleges problémákból okozott lemaradásokat bepótolhassuk
- Backup eszközt használunk meghibásodás esetére
- Gyakori mentéseket készítünk
- Gyakori meetingeket tartubj a félreértések elkerülése érdekében
- Lokális buffer gyakori ürítésére (push) figyelünk
Megjegyzés: A kockázatokat érintő események alacsony számossága miatt a projektkockázatok és a termékkockázatok ugyanazon kockázati mátrixban kerültek feltüntetésre.
Tesztmegközelítés¶
Tesztszintek¶
A statikus tesztelés esetén modulszinten, míg a használhatósági teszt esetében rendszerteszt szinten végezzük a tesztelést.
Teszttípusok¶
Kétféle tesztelést végzünk a statikus tesztelést (statikus kódelemzést), illetőleg a feketedoboz tesztelésnek megfelelő használhatósági tesztelést. Mindkét esetben nemfuncionális tesztelést végzünk.
Teszttechnikák¶
A statikus tesztelés végrehajtása érdekében a forráskód vizsgálatát végezzük alkalmas toolok segítségével, míg a használhatósági teszteléshez használati eset alapú teszteket használunk, amelyhez különböző szcenáriókat definiálunk egy-egy kérdőívvel. A tesztelés végeztével a szcenáriókon végigmegyünk különböző korú és érdeklődési körű önkéntesekkel, majd a kérdőívben megadott válaszaikat kiértékeljük.
Teszttermékek¶
- A tesztterv
- A használhatósági teszteléshez tartozó szcenáriók
- A kérdőívek és a rájuk érkezett válaszok
- Az összesített eredmények feldolgozása és a belőlük levont következtetések
- Statikus kódelemzés szkópjaként választott feature set
- Kiemelt, elemzett szabálysértésekről szóló riport
- Általános szabálysértésekről szóló riport
- Szabálysértések listája szerializált formában (pl. XML)
- A köztes és végső riportok
Belépési és kilépési feltételek¶
A statikus tesztelés belépési feltételei:
- A tesztterv jóváhagyása
- Java futtatókörnyezet és működő Gradle rendelkezésre állása
- Valamely text editor (pl. integrált GitLab editor, Visual Studio Code markdown pluginokkal stb.) rendelkezésre állása
- Ha a szoftver nem fordul out-of-the-box módon: egy olyan fork készítése a repositoryból, mely fordítható
- Eclipse vagy Jetbrains IDE felállítása, a SpotBugs (Eclipse) plugin beüzemelése
A statikus tesztelés kilépési feltételei:
- Legalább 10, de lehetőleg több kielemzett szabálysértés vizsgálata, majd ezekről a felsorolt riportok elkészítése.
A használhatósági tesztelés belépési feltételei:
- A tesztterv jóváhagyása
- A játékot sikeresen futtattuk
- A szcenáriók és a hozzájuk tartozó kérdőívek elkészültek
- A tesztelésben résztvevő önkéntes csoportok felállása
A használhatósági tesztelés kilépési feltételei:
- Minimum 5 szcenárió és a hozzájuk tartozó kérdőív kitöltése
- Minimum 20 felhasználó kitöltötte a kérdőíveket
- Az eredményeket feldolgoztuk, a leszállítandókat elkészítettük
Tesztkörnyezet¶
A használhatósági teszteléshez az alábbi eszközök rendelkezésre állását kell biztosítani:
- Átlagos desktop (Windows/MacOS/Linux), nincs specifikus hardver követelmény
- Java 8 környezet
- Gradle
- Google Forms
A statikus teszteléshez a következő eszközök rendelkezésre állása szükséges:
- Átlagos desktop (Windows/MacOS/Linux), nincs specifikus hardver követelmény
- Java 8
- Gradle
- Eclipse vagy Jetbrains IDE
- SpotBugs, esetleg IntelliJ IDEA beépített kódelemzője
- CheckStyle
Ütemterv¶
A projekt ütemezését az alábbi Gantt-diagram tartalmazza.
Felelősségek kiosztása¶
| Név | Felelősség |
|---|---|
| Kiss Pista István | XXXXXXX |
| Fekete Péter | YYYYYYY |
| Metil Ibolya | ZZZZZZZ |
Jóváhagyó¶
A dokumentumot a mai nappal jóváhagytam:
Dátum: 2024.06.30 Jóváhagyó: Dr. Gyakorlatvezető Henrik