Kihagyás

Minőségbiztosítás

A szoftver rendszerek minősége számos szempontból vizsgálható. Ez a gyakorlatban azt jelenti, hogy ahhoz hogy egy termék hasznot tudjon hozni a gyártónak nem elég, hogy a program lefordul és fut. Sőt a helyes működés, vagyis, hogy el lehet vele végezni a követelményekben megadott célt, is csak az első lépés. A gyakorlat célja, hogy ezeket az aspektusokat megismerjük és a gyakorlatban is alkalmazni tudjuk.

Az alábbi ábra informálisan mutatja a minőség főbb aspektusait. Az említett "működik", azaz funkcionálisan helyes, csak az első elem a listában.

quality

Választhatok több alfeladatot is?

Az alábbi feladatok közül a hallgató a projekt jellegét figyelembe véve és a gyakorlatvezető jóváhagyásával választ egy vagy több alfeladatot.

Jóváhagyás szükséges!

A kiválasztott alfeladatot jelezni kell a Coospace-en. A választás csak akkor számít elfogadottnak, ha azt a gyakorlatvezető megerősíti. A gyakorlatvezető jóváhagyása nélküli feladat végrehajtását és eredményét nem fogadjuk el.

A minőségbiztosítás témakörét két részre fogjuk bontani a gyakorlat során.

Tesztelés

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 gyakorlat során bevezetést adunk a tesztelés világába, melyet háromféle teszteléssel mutatunk be. A hallgatók, akik ennél mélyebben szeretnének elmerül a tesztelés világában javasoljuk a Szoftvertesztelés Alapjai tárgy felvételét és az ISTQB vizsga anyagok áttekintését.

Letesztelted vagy kipróbáltad?

A fejlesztés közben sokszor próbálgatjuk (pl. debug-golás során) a funkciót amit fejlesztünk. Példakódot írunk, main metódusokat hozzunk létre, hogy közvetlenül hívhassuk a fejlesztés alatt lévő részeket. Ezek a lépések fontosak, de nem számítanak tesztelésnek. A tesztelés szinte minden fajtájára elmondhatóak a következő irányelvek.

  • A tesztek futtatása megismételhető és konzisztens eredményt ad, amennyiben nem történt módosítás a kódbázisban.
  • A teszt pontosan leírja hogy milyen lépéseket kell végrehajtani az eredmény (elbukott vagy átment) érdekében.
  • A tesztek összekapcsolhatóak a rendszer valamely követelményeivel (nem feltétlenül funkcionális).

A kipróbálásokat nem fogadjuk el tesztként a gyakorlat során.

A próbálgatások hasznos alapot jelentenek a tesztek megírása során. A megvalósítás alatt lévő metódust meghívó példa main helyett (vagy alapján) készítsünk egy új egység vagy integrációs tesztet megvalósító metódust. A kipróbálások során követett felhasználási lépések alapján új végfelhasználói teszteset forgatókönyv készíthető.

test-story

Unit tesztek

A unit tesztek célja, hogy a rendszer legkisebb építőelemeit (melyek általában a metódusok) helyes működését igazolja megismételhető módon. Az egységteszteket mindig a fejlesztők írják, hiszen ők rendelkeznek megfelelő ismeretekkel a forráskódról ehhez.

Honnan tudom, hogy helyesen működnek-e a metódusaim?

Megfelelően megírt tesztekkel tudjuk igazolni, hogy tesztelt részek az elvárásoknak megfelelően működnek. Ha minden teszt csak egy adott metódus egy adott (fajta) bemenetre teszteli akkor az a hiba keresést és javítást is gyorsítja. Hiszen a hibás metódus az amelyiknek a tesztje elbukott és a tesztelt bemenet egyben példa adatokkal is szolgál.

Módosítottam valamit. Honnan tudom hogy a metódusok még mindig megfelelően működnek?

Az egységteszteknek egymástól és külvilágtól is függetlennek kell lennie. Ez azt jelenti, hogy bármikor újrafuttatva konzisztens eredményt kell kapjunk. Tehát ha módosítás után valamelyik egységteszt elbukik, akkor a módosítás során hibát okoztunk a rendszerben.

Hogyan is kell használni ezt a metódust?

A unittest-ek számtalan példát tartalmaznak a metódusok használatára. Ezekből nem csak a helyes paraméterezést tanulhatjuk meg, de képet kaphatunk az eredeti fejlesztő szándékáról is, hiszen a tesztek egyértelműen jelzik, hogy mi volt az elvárt viselkedés.

A unittest-ek megvalósítása forráskódban történik, általában valamilyen keretrendszer segítségével. A gyakorlat során a JUnit rendszert fogjuk használni. Az egységteszteket ugyanabban a verziókövető rendszerben szokták nyilván tartani, mint a kódbázis többi részét.

Hányas verziót használjunk?

A korábban már elkezdett projektet szinte minden esetben már tartalmazni fog valamilyen egységtesztelési keretrendszert, ezért nem szükséges azt nekünk hozzá adni. Vagyis azt a verziót használjuk amelyet a projekt is előír. Jelenleg ez a definíció a CodeMetropolis esetében a Maven leírófájlokban található.

Attól nem lesz unittest mert JUnit-tal készült!

Az egységteszt keretrendszereket több más, automatizált tesztkészlet megvalósítására is használják a gyakorlatban. Ezeket nem tekintjük egységteszteknek, mivel nem tartják az egységtesztek irányelveit.

Mit nem javasolt tesztelni?

  • Ne teszteljünk triviális kódot, például egysoros getter és setter.
  • A konstruktor szakszerű tesztelése általában technikai akadályokba ütközik.

Értékelés

A Unittest-ek részre a hallgató 3 pontot szerezhet. Feladat a projekthez unittest-ek implementálása és futtatása. A feladat során a unittest-ek forráskódját (*.java fájlok) a hallgatói GitLab szerveren kell elhelyezni. A tesztelésre kiválasztott metódusok során vegyük figyelembe a következőket.

  • A saját változtatás megvalósításának tesztelése kötelező, vagyis azokat a metódusokat amiket mi írtunk, vagy módosítottunk.
  • Másodsorban a saját változás megvalósításához közvetlenül kapcsolódó részeket teszteljük, vagyis amik ugyan abban az osztályban vagy névtérben vannak (package).

Integrációs tesztek

De hát külön-külön jól működött!

door windows sensor

Az integrációs tesztek célja, hogy megismételhető módon igazolják, hogy a rendszer komponensei (metódusok, osztályok, csomagok, programok, ...) megfelelőképpen működnek együtt.

Házak pivot pontja

Tegyük fel, hogy a Placing és a Rendering CodeMetropolis program is koordináta és méret alapján helyezi el az épületeket. Pró Bea a Rendering-en dolgozik és az (x,y,z) koordináták alapján meghatározza az épület bal, alsó, első pontját. Ez egy szakmailag megalapozott döntés volt, hiszen így számtalan koordinátageometriai művelet egyszerűsödik a blokkok elhelyezése során. Teszt Elek issue-ja a Placing eszközhöz kapcsolódik. Az (x,y,z) koordináta nála az épület alapjának közepét jelenti. Ezzel sokkal egyszerűbben tudta középreigazítani az egymásra kerülő szinteket.

Mindketten megfelelő mennyiségű és minőségű egységteszteket készítettek, melyek sikeresen le is futottak. A két módosítás egyesítése után a generált városban mégis egymásba csúsztak az épületek. Az integrációs tesztek ilyen problémák kiszűrésére képesek.

A gyakorlaton az integrációs teszteket az egységtesztekkel megegyező keretrendszerrel valósítjuk meg. Ez egy elfogadott szakmai gyakorlat, azonban léteznek más módszerek is.

Értékelés

Az integrációs tesztek részfeladatra a hallgató 3 pontot szerezhet. Feladat a projekthez integrációs tesztek implementálása és futtatása. A feladat során az integrációs tesztek forráskódját (*.java fájlok) a hallgatói GitLab szerveren kell elhelyezni. A tesztelésre kiválasztott komponensek során vegyük figyelembe a következőket.

  • A saját változtatás megvalósításának tesztelése kötelező, vagyis azokat a metódusokat amiket mi írtunk, vagy módosítottunk teszteljük le hogy továbbra is képes megfelelően együtt működni a közvetlen környezetével (osztály, csomag).
  • Másodsorban a saját változás megvalósításához közvetlenül kapcsolódó részeket teszteljük, vagyis amik ugyan abban az osztályban vagy névtérben vannak (package).
  • Végül teszteljük le, hogy az egyes programok továbbra is képesek az elvárt módon együttműködni.

Végfelhasználói tesztek

A végfelhasználói tesztek feladata a teljes folyamat vagy funkcionalitás helyességének igazolása a felhasználó szemszögéből.

De a rendszer ugyanúgy működik mindegy ki használja, nem?

A felhasználó szemszöge alatt azt értjük, hogy a tesztelést végzőnek nincsen információja a rendszer belső működéséről. Ezt a fajta megkülönböztetést fekete- és fehér-doboz tesztelésnek hívjuk. Az egység tesztek tipikusan fehér-doboz tesztek, hiszen a fejlesztő tudja, hogy hogyan működik az adott metódus és ez alapján konstruálja meg a szükséges teszteseteket.

A végfelhasználói tesztek fekete-doboz tesztek, mivel a felhasználó nem ismeri és nem is fér hozzá a program belső logikájához. Az információ elsődleges forrása számára nem a belső működés, hanem a dokumentáció. white-black

Világ generálása

A CodeMetropolis Rendering programja az IXML fájlban megadott épületeket Minecraft világbeli blokkokká konvertálja. A folyamat általában percekig is eltart, a vizualizált program méretétől függően akár órákat is igénybe vehet. A CodeMetropolis egyik korábbi verziójában nem volt visszajelzés a folyamat közben. A tesztelés során a végfelhasználói teszt mutatott rá erre a hiányosságra.

A javítás első lépésben egy folyamatos jelzést jelentett, hogy a konverzió folyamatban van. További végfelhasználói tesztek jelezték, hogy a hosszú konverziók során a felhasználónak nincs tudomása róla hogy meddig tart a folyamat. Ez nagyban csökkentette a CodeMetropolis használhatóságát.

Ezt követte a funkció jelenlegi állapota, mely elfogadható pontossággal becsüli meg e fázis hosszát.

A végfelhasználói tesztet nem feltétlenül szükséges hogy szoftverfejlesztésben jártas szakember végezze, bár a közös előismeret segítheti a kommunikációt a fejlesztő csapattal. Ezeket a teszteket többször manuálisan végzik el, azonban előfordulhat hogy a kézi végrehajtást rögzítik és később ezzel szimulálják a valódi felhasználó cselekedeteit.

Felhasználó szimulálása

Bár a gyakorlaton ezzel a témával csak említés szintjén foglalkozunk, az érdeklődő hallgató további részleteket olvashat erről a Selenium és ehhez hasonló eszközök kapcsán.

Jóváhagyás szükséges

Az tesztelésre kiválasztott issue-t jelezni kell a Coospace-n. A leadott anyagot csak akkor fogadjuk el, ha a gyakorlatvezető jóváhagyta a választást.

Választhatok olyan issue-t ami még nincs kész?

Igen. A tesztelésre kiválasztott issue-nak nem szükséges készen lennie. A tesztek hamarabb is elkészülhetnek mint a funkció vagy a követelmény maga. Ez az elv nagyon hasonló a Tesztvezérelt fejlesztés alapjaihoz.

Természetesen ilyen esetben a tesztek el fognak bukni mindaddig amíg a követelmények nem készültek el. Ez nem azt jelenti, hogy a tesztet nem kell szakmailag megalapozott módon elkészíteni. Ha bizonytalan vagy minnél előbb fordulj a gyakorlatvezetődhöz.

Értékelés

A hallgatók a Végfelhasználói tesztek részre összesen 3 pontot kaphat. A hallgató feladata tetszőleges CodeMetropolis program végfelhasználói tesztjeinek elkészítése. A tesztelés során koncentráljunk egy tetszőleges issue-ban megadott követelményekre. A végfelhasználói teszteket a hallgatói GitLab issue-k formájában kell megadni, felhasználva a sablont. A tesztelésre kiválasztott issue-t minden esetben hivatkozni kell. A gyakorlat során (az egyszerűség kedvéért és a hallgatói feladatok mérséklése érdekében) csak kézzel végrehajtott végfelhasználó teszteseteket fogadunk el. A feladatban igazolni kell a tesztek végrehajtását (pl. képernyőképekkel).

Szoftverelemzés

A szoftverelemzés célja a szoftverrendszer objektív megismerése. Az elemzés általában tudományos módszereket használ és méréseken alapszik. A megismételhető és lehetőleg személyfüggetlen mérés alapján következtetéseket vonhatunk le a rendszerről és a hozzá kapcsolódó folyamatokról.

Miért kell mérni és elemezni?

Képzeld el, hogy vezető fejlesztőként meg kell becsülnöd, hogy mennyi fejlesztő tud majd elvégezni egy új projektet határidőre. Első ötleted, hogy korábbi hasonló projektek erőforrása alapján adsz becslést. A korábbi projektek fejlesztéséhez szükséges fejlesztők száma és futamideje mind a folyamatokat jellemző mérés.

Bármelyik projekt megfelel a becslés alapjaként? Nyilván nem, csak a hasonlóak. Egy program hasonló, ha ugyanazokat a technológiákat használja? Hasonló ha ugyan annyi kódsort tartalmaz? Ezek mind a terméket jellemző metri

Tegyük fel hogy 5 fejlesztőre lesz szükség a becslés szerint. Mindegy hogy milyen a junior és a senior fejlesztők aránya? Minden senior fejlesztő ugyanakkora sebessége dolgozik? Minden junior fejlesztő ugyanolyan minőségű terméket állít elő? Ezek a tulajdonságok mind a fejlesztési folyamat szereplőit jellemzik és mérések segítségével határozhatóak meg. measure

A becslés folyamata tulajdonképpen egy elemzés ami tudományosan megalapozott módszerek alapján von le következtetést (mennyi fejlesztőre van szükség) a korábbi mérésekből (hasonló projektek erőforrásigénye).

Minőségriport kódelemzés alapján

A kódelemzés során a forráskódból gyűjtünk információt a rendszerről. Statikus elemzés során nem futtatjuk a kódot, míg dinamikus esetben (akár több) futás során gyűjtött adatokat használunk fel. A feladat célja hogy képet kapjunk a projekt minőségéről és ennek változásáról a módosítások elvégzése előtt, közben és után. A minőség bármelyik korábban bemutatott aspektusát vizsgálhatjuk ezzel a módszerrel.

Használhatok más eszközöket is?

A riportot a gyakorlatokon bemutatott eszközök segítségével ajánlott elkészíteni, de használható más eszköz is saját felelősségre. Ha bizonytalan vagy kérj tanácsot a gyakorlatvezetőtől! A nem megfelelő eszközökkel készült méréseket és az azok alapján levont hibás következtetések nem fogadjuk el.

Használhatok dinamikus elemzést is?

A gyakorlaton időhiány miatt a dinamikus elemzést csak említés szintjén vesszük, ezért nem javasolt. De a hallgató saját felelősségére használhatja ezt a mérési módszert is.

Új blokkok bevezetése

Képzeljük el a következő hipotetikus esetet. Jelenség: A CodeMetropolis komplexitása (pl. az osztályok teljes McCabe komplexitása) több mint 30%-al nőtt az elmúlt fél év során. A többi statikus forráskód metrika nem változott jelentősen. Vagyis a kódbázis mérete is megközelítőleg azonos maradt. Ezek azok az adatok melyet statikus módszerek segítségével le tudunk mérni.

Elemzés: Az elemzés során elsősorban az okokat és a lehetséges következményeket keressük. Az adatokban látszik, hogy a legnagyobb komplexitás változás a Mapping és a Rendering eszközben figyelhető meg. A többi részek nagyságrendekkel kisebb mértékben változtak. A kapcsolódó események és a verziókövető rendszer adatai alapján megállapíthattuk, hogy az egyik legfontosabb függőség a Minecraft játék egyik nagyobb verziója ennek az időszaknak az elején jelent meg. A többi függőségben nem történt változás és új felhasználói követelményekről sem érkezett hír a rendszer issue-kezelő felületén.

Okok: A további vizsgálatok alapján feltételezzük, hogy mivel a kérdéses verzió számtalan új blokkot vezetett be, ezért a lelkes hallgatókból álló fejlesztőcsapat elkezdte ezek kihasználását új épület stílusok és változatok bevezetésével. A megvalósított issue-k is ezt támasztják alá.

Következmények: A komplexitás növekedése miatt a jövőben nehezebb lesz megérteni és a sok egyedi logika miatt módosítani a kapcsolódó Rendering és Mapping eszközök részeit. Vagyis az ezekhez kapcsolódó issue-k megoldása több erőforrást igényel.

Az issue-khoz tartozó branch-et jelezni kell

Amennyiben a hallgató nem időben vagy nem egyértelműen (pl. GitLab link) jelzi az issue-hoz tartozó branch-et úgy a mérésekről saját maga kell hogy gondoskodjon.

Kifejező metrika választása

wtf

Értékelés

A hallgató a Minőségreport kódelemzés alapján részfeladatra 4 pontot kaphat. A hallgató feladata, hogy méréseket végezzen a fejlesztés során. Ehhez a hallgatói GitLab projektek esetében automatikus folyamatok kerülnek beállításra a választott issue-ban jelzett branch-ekre. A mérések alapján, a hallgató fejlesztések végén a projektről minőségriport készít a projekt állapotai alapján. A riportot a hallgatói GitLab projekt Wiki rendszerébe kell feltölteni.

Az elemzésben a következő szempontokat vegyük figyelembe és kérdésekre keressük a választ.

  • Milyen volt a projekt forráskódjának metrikák és egyéb mért jellemzőkkel alátámasztott kezdeti és fejlesztés utáni minősége?
  • Hogyan változott a minőség a fejlesztés során? Milyen viszony alakult ki a kezdeti és a végső állapot között?
  • Milyen furcsa vagy meglepő jelenségeket tudunk megfigyelni a megvalósítás (forráskód) metrikákból levonható és konkrét példákkal alátámasztott jellegzetességeiből?
    • kiemelkedő értékeinek magyarázata és jogossága
    • értékeinek egymással való kapcsolata és ezek pozitív, negatív vagy semleges hatása a fejlesztett projektre
    • időbeli változásának értékelése és magyarázata
  • Milyen szabálysértéseket találhatóak a forráskódban? Mi lehet ezek keletkezésének létezésének okai a verziókövető rendszer alapján?
    • Mely szabálysértések jeleznek valódi hibát? Miért?
    • Melyek leggyakoribb és legritkább jelzések?
    • Hogyan változtak a szabálysértések száma vagy aránya a fejlesztés során?

Tesztlefedettség vizsgálata

A tesztelést mint minden szoftverfejlesztéshez kapcsolódó tevékenységet lehet jól és rosszul végezni. A nem megfelelő minőségű tesztelés ritkán éri el a célját (a követelmények ellenőrzése), azonban legalább annyi erőforrást emészt fel mint szakmailag megalapozott változata. A tesztlefedettség viszgálata egy lehetséges módszer a tesztelés minőségének ellenőrzésére.

A lefedettség képes a tesztek minőségét minden korábbi aspektus szerint vizsgálni?

Nem. A lefedettséget általában a teszt csomag méretének és teljességének vizsgálatára szokták használni. Számos kutatás számára szolgál alapvető adatként egyéb minőségbeli jellemzők becslése során.

Mit mér a lefedettség?

A lefedettség kifejezi, hogy az egyes tesztek végrehajtása (automatizált esetben futtatása) során mely kódrészletek kerültek futtatásra. Ezek számából meghatározható, hogy a tesztek mekkora mértékben érintették a forráskódot, vagyis hogy mekkora és melyek azok a részek, amelyek biztosan nem kerültek tesztelésre.

A lefedettség mérésének kulcsa, hogy valamilyen módszerrel feljegyezzük, hogy mely kódrészletek hajtódtak végre. Az ilyen naplózás aktiválása után a teszteket egyszerűen végrehajtjuk vagy automatizált esetben futtatjuk.

Parancssori argumentumok ellenőrzése

A példa kedvéért tegyük fel, hogy a CodeMetropolis Converter eszköz parancssori felületének megalkotás egy funkció csoport keretében történt (viszonylag egyidőben). A fejlesztő automatizált tesztek segítségével szeretne meggyőződni a funkcionális követelmények teljesítéséről. A tesztelés során csak két tesztesetet fogalmaz és valósít meg. Egyet-egyet -t (type) argumentum két értékére: sourcemeter és sonarqube. Hiszen fontos hogy a konvertálás jelenleg csak ezt a két formátumból lehetséges, így ezek tesztelése fontos.

A gondolatmente bár helyes, de hiányos. A lefedettségmérés egyértelműen kimutatja, hogy bár vannak olyan kódrészletek amelyeket érintenek a tesztek és a többi argumentumhoz kapcsolódnak, de ezek csak az alapértelmezett értékek kezelésével foglalkoznak. Vagyis a parancssori argumentumokat tesztelő csomag túl kicsi és nem teljes.

A lefedettség elemzése egy másik hiányosságra is rámutat ebben az esetben. A tesztelt -t argumentum kezelése során a hibás értékeket ellenőrző és jelző kódrészletek nem kerültek futtatásra. Vagyis ezen tesztek alapján nem tudunk meggyőződni ezek helyes működéséről.

Milyen eszközt használhatok a lefedettségi adatok begyűjtésére?

Java nyelven írt projektek esetén javasoljuk az Eclipse fejlesztőkörnyezetbe alapértelmezett módon integrált EclEmma eszköz használatát.

Használhatok más eszközt vagy módszert a lefedettség mérés során?

A hallgató saját felelősségére és a gyakorlatvezető jóváhagyásával használhat más lefedettségmérő eszközt. Ha bizonytalan vagy kérd ki a gyakorlatvezető tanácsát! Nem megfelelően használt eszközökkel végzet mérést és ennek elemzését nem fogadjuk el.

Ahogy a fenti példából is látszik a nyers lefedettségi adatok közlése nem segíti a projekt fejlesztését. A lefedettség mérése a vizsgálat során csak az első lépés, melyet a többi minőség-ellenőrzéshez hasonlóan elemzési fázis követ. Ebben a fázisban a mért adatok okait (magyarázatát) és következményeit kutatjuk.

A generált riport nem elég!

Az indoklás és magyarázat nélküli lefedettségi adatokat nem fogadjuk el. A legtöbb lefedettségmérő eszköz képes emberek számára könnyen olvasható riportot generálni. Ezek azonban csak a nyers adatokat tartalmazzák, vagyis nincs bennük a lehetséges okok és következmények vizsgálata. Ezek célja hogy felgyorsítsák a méréssel szerzett adatok bemutatását és az elemzés előkészítését. A generált riportokat felhasználhatjuk, mint első verzió a végleges jelentés elkészítése során.

Értékelés

A Tesztlefedettség vizsgálata alfeladatra a hallgató 4 pontot kaphat. Feladat a kiválasztott issue-ban leírt követelményekhez kapcsolódó módosításokhoz kapcsolódó tesztek lefedettségének mérése és a kapott adatok elemzése. A lefedettségi vizsgálatot a hallgatói GitLab szerver Wiki rendszerébe kell feltölteni.

A leadott anyagnak magyaráznia kell a tesztelés és a hozzá kapcsolódó mérés során kapott értékeket. A tesztelés során vegyük figyelembe és a leadott anyagban foglaljuk bele a következőket.

  • tesztelés során felhasznált eszközök és technikák ismertetése
  • a vizsgált teszt csomag bemutatása
  • végrehajtott tesztek sikerességének ismertetése
  • tesztek végrehajtása során a lefedettség szisztematikus (akár automatikus) mérése
    • felhasznált technikák és eszközök
    • lefedettségi érték indoklása
    • erősen és kevésbé lefedett kódelemek bemutatása
    • könnyen és nehezebben tesztelhető funkciók és változtatások

Értékelés összefoglalása

részfeladat maximális pontszám
Tesztelés Unittesztek 8
Integrációs tesztek 8
Végfelhasználói tesztek 8
Szoftverelemzés Minőségriport kódelemzés alapján 9
Tesztlefedettség vizsgálata 9

Utolsó frissítés: 2022-05-02 09:16:09