Tesztelési terv

Funkcionális tesztelés

A rendszer funkcionalitásainak a tesztelése. A tesztesetek a fejlesztés során bővülhetnek még.

Teszteset	Leírás	Elvárt kimenet
Felhasználó regisztrációja a rendszerbe.	A felhasználó megadja a regisztrációs adatait a rendszernek.	Felhasználóduplikáció és a helyes adatok ellenőrzése után a rendszer beregisztrálja a felhasználót és ezután logolás is történik.
Felhasználó bejelentkezése a rendszerbe helytelen adatokkal	Egy felhasználó helytelen felhasználói adatok megadásával bejelentkezik a rendszerbe.	A felhasználó létezése az adatok helyességének ellenőrzése után a rendszer (logolás után) helytelen adatok miatt nem ad vissza tokent. (tehát semmit nem ad vissza)
Felhasználó bejelentkezése a rendszerbe helyes adatokkal	Egy felhasználó helyes felhasználói adatok megadásával bejelentkezik a rendszerbe.	A felhasználó létezése az adatok helyességének ellenőrzése után a rendszer logol majd visszaad egy tokent a felhasználónak.
Felhasználó hitelesítése	Felhasználó által beadott token ellenőrzése.	Token helyességétől függetlenül visszaad egy státuszt. Helyes token esetén engedélyezett a belépés, helytelen token esetén a belépést elutasítja a rendszer. Logolás történik mindeközben.
Helyes kép feltöltése a felhasználó által. (miután bejelentkezett)	Egy felhasználó feltölt egy helyes képet a rendszerbe.	Hitelesítés és a beküldött adat(kép) ellenőrzése után a hitelesítés és az adat is megfelel a követelményeknek, ezért a rendszer feltölti a képet és visszaad egy kép ID-t. Az eseményeket logolja.
Helytelen kép feltöltése a felhasználó által. (miután bejelentkezett)	Egy felhasználó feltölt egy helytelen "képet" a rendszerbe.	Hitelesítés és a beküldött adat ellenőrzése után a rendszer az adat ellenőrzése során nem találta a feltöltött adatot(képet) helyesnek, ezért hibaüzenettel válaszol. A hiba logolása megtörténik.
Létező kép letöltése a felhasználó által.	A felhasználó bejelentkezés után letölt egy, a rendszerben létező képet.	A felhasználó bejelentkezik. Ha helytelen a bejelenkezés akkor a rendszer nem enged képet letölteni. Felhasználó a hitelesítési tokennel és az imageId-val képet tölt le. Ha a token valid és az imageId létezik, a válasz tartalmazza a képet raw adat formában. A letöltés logolásra kerül.
Nem létező kép letöltése a felhasználó által.	A felhasználó bejelentkezés után le szeretne tölteni egy nem létező ID-val rendelkező képet.	A felhasználó bejelentkezik. Ha helytelen a bejelenkezés akkor a rendszer nem enged képet letölteni. Felhasználó a hitelesítési tokennel és az imageId-val képet szeretne letölteni, azonban a rendszer nem talál ilyen ID-val rendelkező képet, így hibaüzenettel visszatér. A hibáról log készül.
Megjegyzés írása.	A felhasználó bejelentkezés után megjegyzést ír egy adott képhez.	A felhasználó bejelentkezik. Ha helytelen a bejelenkezés akkor a rendszer nem enged megjegyzést írni. Felhasználó a megjegyzéssel és az imageId-val megjegyzést szeretne írni az adott ID-val rendelkező képhez. Ha létezik kép ilyen ID-val akkor feltölti a megjegyzést a képhez és válasszal visszatér. Az eseményekről log készül.

Statikus tesztelés és Coding Standard

A statikus tesztelési feladatokat a SonarQube segítségével végezzük el. Ez nem csak a coding standar betartását segíti, de a beépített security check segítségével sok olyan sérülékenységet is előre kijavíthatunk (bele se implementálunk), melyek később komoly biztonsági kockázatokat hordoznak magukban. Ilyen pl. SQL Injection sérülékenység, broken authentication vagy insecure logging. A dependencyk vizsgálatával, pedig kiszűrhetjük az olyan modulok használatát, melyek ismert sérülékenységeket tartalmaznak. Ebben az esetben frissebb verziójú vagy más modult használunk. Az implementáció során a statikus elemző által kimutatott összes biztonsági sérülékenységet, bugot javítunk, nem kerülhet ki éles környezetbe olyan kód, mely ilyen típusú, ismert hibákat tartalmaz. A "code smell" típusú hibák manuális elemzés után, megfelelő indok esetén benne maradhatnak, amennyiben a rendszer biztonságát nem veszélyeztetik.

Sonarqube eredménye

A Sonarqube-t egyszerűen futtattuk docker segítségével majd pedig a projektben apró konfigurálások után (build.gradle) lehetett is használni. Az eredmény a következő lett: Látszódik, hogy 27 bugot talált a sonar illetve egy vulnerability-t, ami számunkra különösen fontos. Ezen kívül 114 Code Smells-t talált. Mindezt 1800 kódsoron belül.

Az összes bug egy "figyelmetlenséghez" köthető: Egy változó értéke nem lett ellenőrizve, hogy null-e, mielőtt hivatkoztak annak a változó értékére: Ezt valóban érdemes megtenni, hiszen null érték esetén komoly gondokat okozhat. Többfajta bug-ot nem talált a sonar.

Egy vulnerability volt, mégpedig egy hardcoded secret: A sonar erre egy bővebb leírást is ad, miért tartja sebezhetőnek a programot emiatt:

A megoldás erre a problémára az lenne, hogy egy külön fájlban tároljuk a titkot (jelszót). Aki pedig szeretne ehhez a jelszóhoz hozzáférni, hozzáférést kell biztosítani a fájlhoz.

Végezetül 114db Code Smells-t talált a sonar. Ezeknek a megítélése elég szubjektív, viszont van egy két javaslat amit érdemes megfogadni, viszont hiba általában nem származik belőle. Például jelezte a sonar, hogy feleslegesen hívtunk .toString() metódust egy változón, ugyanis a Formatter ezt elvégzi helyettünk:

Összességében nagy hibát szerencsére nem talált a sonar, de mindenképpen hasznos volt lefuttatni és ellenőrizni.

Natív CAFF Parser dinamikus tesztelése

A natív komponens dinamikus analíziséhez a Valgrind elemző szoftvert használtuk. Segítségével különböző memória menedzsment hibákat tudunk felfedezni, melyek adott esetben a program összeomlásához vezetnek, vagy lehetővé tehetik rosszindulatú kódok futtatását. (pl. Nem felszabadított területre injektált kód futtatása) A fejlesztés során a dinamikus tesztelés által nem sikerült hibát találni a rendszerben. Mivel modern c++ban nincs szükség new hívásra, így ez az eredmény várható volt. Sajnos a Valgrind a hibák hiányát kimenet hiányával jutalmazza így csak a következő képet tudjuk mutatni a tesztelésről:

illetve sikerült találni egy xml kimenetet is a futásról:

Ahogy itt is látszik, nincs egyetlen error sem a kimenetben.

Elképzelhető, hogy valami rosszul volt configolva a kimenethez - azonban egy new int[234]; hívás rögtön kimenetet generált futáskor így feltételezem hogy a valgrind ux hibája hogy nem ad visszajelzést a hibamentes kódról.

Integrációs tesztelés

Az integrációs tesztelést a Postman segítségével végeztük. A következő táblázatban az egyes endpointok láthatók, a típusával, a hozzájuk tartozó paraméterekkel és az visszaadott válasszal együtt. Mindegyik endpointhoz szükséges autorizáció, ezt bearer token segítségével oldjuk meg.

Endpoint URL	Paraméterek	Válasz
POST localhost:8443/api/users/register	username, password	Username, roles (lista)
POST localhost:8443/api/users/login	username, password	Access token, Refresh token
GET localhost:8443/api/users/	-	Felhasználók listája, a következő adatokkal: username, roles(lista), links(url, amelyen elérhető a user)
GET localhost:8443/api/users/admin	-	Adatok az adminról: username, roles(lista), links(lista)
DELETE localhost:8443/api/users/{username}	-	- (204 No Content)
POST localhost:8443/api/caffPictures	title, description, caff file, ownerUserName, price	title, description, owner(username, roles), price, caffData (preview, fixelenkénti leírás)
POST localhost:8443/api/caffPictures/{id}/buy	-	- (200 OK)
POST localhost:8443/api/caffPictures/{id}/comments	comment_value	- (200 OK)
PUT localhost:8443/api/caffPictures/{id}/	updatelni kívánt érték. pl. price	title, description, commentList (commment value, username), owner(username, roles), price, caffData (preview, fixelenkénti leírás)
DELETE localhost:8443/api/caffPictures/{id}/	-	- (204 No Content)
GET localhost:8443/api/caffPictures/{id}/	-	full caff data