Szoftverellenőrzési technikák - Házi feladat

Házi feladat (2014. ősz)

A félév során 2-3 fős csapatokban kell egy házi feladatot megoldani, melyben a tanult szoftverellenőrzési technikákat (követelményellenőrzés, forráskód vizsgálata, tesztelés, stb.) kell egy kiadott szoftveren alkalmazni. A házi feladat kiadása és elkészítése 4 részfeladat formájában zajlik, minden egyes részfeladat esetén az alkalmazás különböző részei kerülnek kiadásra, melyen a feladatokat meg kell oldani.

Háttér infrastruktúra

A csapatok a vizsgálandó alkalmazás dokumentációját, binárisait, forrását egy központi verziókezelőből tölthetik majd le:

Ezen kívül minden egyes csapatnak rendelkezésére áll egy saját tárhely, ide kell majd feltölteni az összes elkészített anyagot (dokumentációk, tesztek, teszt környezet, stb.):

  • https://szet.inf.mit.bme.hu/svn/szet_X_2014/ ahol X helyére a csapat számát (1-8) kell beírni

A házi feladat során azonosított problémákat, hibákat egy saját Trac hibabejelentő rendszerbe kell minden csapatnak felvinni, a házi feladat bemutatását pedig a Trac wiki oldalain kell elkészíteni:

Értékelés

  • Mindenki minden részfeladat elkészítésében dolgozzon.
  • Az értékeléseknél fontos szempont a megoldások minősége, erre is figyeljünk oda (pl. az elkészítendő dokumentáció érthető és konzisztens legyen, a teszt kód is jól formázott és érthető kód legyen, stb.).
  • Értékelés (csapatonként):
    • 1-5 pont minden részfeladatra (legalább 2-t el kell érni),
    • a 4 részfeladat pontszámának átlagát vesszük,
    • az eredmény 0,3-as súllyal számít a végleges jegybe,
    • a csapaton belül a csapattagok csak akkor kapnak különböző pontot, ha az ilyen problémát a csapat előre jelzi.

Előkészületek

Cél: az infrastruktúra megismerése, kipróbálása

Határidő: 2014. 09. 29.

Feladatok:

  • 2-3 fős csapatok alakítása, ezek alapján a hozzáféréseket beállítjuk.
  • saját SVN tárhely birtokba vétele, alap struktúra kialakítása
  • saját Trac birtokba vétele
    • kezdőoldal kitöltése
    • hibajegy felvitel kipróbálása, saját milestone-ok és komponsek definiálása

HF1 - Követelménykezelés

Cél: a házi feladat során vizsgált alkalmazás követelményspecifikációjának ellenőrzése, részletes követelménylista előállítása.

Határidő: 2014. 10. 15. (szerda), 20:00 óra (a határidő leteltéig az SVN-be felkerült anyagokat értékeljük)

Kerettörténet: A BookStore rendszer fejlesztése elkezdődött, jelenleg az ügyféllel folytatott beszélgetések alapján a projekt vezetője és a vezető fejlesztő elkészítették a szoftverkövetelmény-specifikáció (SRS) első változatát egy Word dokumentum formájában. Azonban mielőtt nekiállnának a fejlesztésnek, a korábbi tapasztalatokból tanulva, előbb a specifikációt ellenőriztetik. Ezt a feladatot egy külső szakértői csapatra, ránk, bízzák. Hogy minél objektívebben tudjunk majd nyilatkozni az SRS minőségéről, mi csak a dokumentumot kapjuk meg. Válaszként többek között egy hivatalos igazoló jelentést várnak az átvizsgálásról. A feladathoz kiindulásként az EA02 előadás anyaga nyújt segítséget.

Bemenet: Az SRS elérhető az SVN tárhely BookStore/trunk/doc könyvtárában.

Feladatok:

  1.  Végezzük el az SRS átvizsgálását, és készítsük el az ezt dokumentáló szoftverkövetelmény-igazolójelentést. A jelentés legalább a következőket tartalmazza:
    1. Definiáljuk, hogy milyen szempontok szerint és milyen módszerrel fogjuk elvégezni a követelményspecifikáció ellenőrzését, valamint, hogy a csapattagoknak mi lesz a szerepük az átvizsgálás során. [A házi feladat része ezeknek az szempontoknak az összegyűjtése.]
    2.  Emeljük ki az SRS-sel kapcsolatos főbb problémákat, majd tételesen fogalmazzuk meg, hogy milyen hibákat találtunk a követelményspecifikációban.
  2. A szöveges követelmények alapján készítsünk egy követelménylistát, amely később a tesztek tervezésének és megvalósításának alapjául fog szolgálni. Figyeljünk arra, hogy minden követelmény kerüljön bele, tehát pl. hibakezelés, nem-funkcionális követelmények is.
    1. A listát táblázatos formában adjuk meg, melyben szerepelnek az egyes követelmények fontos adatai (pl. azonosító, név, forrás, stb.). A követelmény forrását olyan pontosan adjuk meg, hogy később biztosítható legyen a követhetőség az eredeti specifikációk, a követelmények, és az ezekből származtatott tesztesetek között.
    2. A követelménylista formai része nincs megszabva (kerülhet a Trac wikire, Excel fájlként az SVN-be vagy akár Google Docs-ba).

HF2 - Forráskód ellenőrzése

Cél: Forráskód ellenőrzése statikus technikák segítségével.

Határidő: 2014. 10. 29. (szerda), 20:00 óra (a határidő leteltéig az SVN-be felkerült anyagokat értékeljük)

Kerettörténet: A BookStore alkalmazás interfészeit rögzítette a fejlesztőcsapat, és elkezdtek párhuzamosan dolgozni a modulok implementációján. Az adminisztrátoroknak szánt OSGi parancssori felület kódja elkészült, a cég fejlesztési folyamatának megfelelően ilyenkor ezt a fejlesztők közül egy másik csapatnak felül kell vizsgálni, és, ha szükséges, javításokat kell javasolnia. Ezt a feladatot most mi kaptuk meg. Az alkalmazás többi része még nincs kész, ezért nem tudjuk futtatni a kódot, úgyhogy koncentráljunk manuális átolvasásra és statikus analízis eszközökre. Mivel most a fejlesztői csapaton belüli felülvizsgálásról van szó, ezért nem szükséges formális dokumentációt készíteni.

Bemenet: A console modul forrása elérhető a központi SVN tárhelyen. A többi modul interfészeinek definíciója elérhető a commons nevű projektben, ennek a felhasználásával a console modul már lefordul (ám végrehajtani még nem lehet). A fejlesztőcsapat sajnos nem készített részletes modultervet, pusztán egy szöveges fájlban foglalták össze az OSGi megvalósítással kapcsolatos legfontosabb tudnivalókat (lásd doc/osgi_console_notes.md).

Feladatok:

  1. A projektek jelenlegi állapotát minden csapat töltse fel a saját SVN tárhelyén egy megfelelő könyvtárba.
  2. Tanulmányozzuk a projekt állományait és értsük meg, hogy melyik résznek mi a szerepe, hogyan épül fel nagy vonalakban a console modul.
    1. Végezzük el a BookStoreUserConsole.java fájl ellenőrzését átolvasással.
    2. Ehhez előbb a csapat wikijén definiáljuk, hogy milyen szempontokra fogunk figyelni a forráskód átolvasása során.
    3. Az eredményeket a csapat wikijén valami könnyen áttekinthető formában (felsorolás, táblázat stb.) adjuk meg.
  3. Végezzük el a FindBugs és a PMD eszközök segítségével a forráskód ellenőrzését.
    1. A FindBugs esetén vegyük fel a 'Minimal rank to report' beállítását 20-ra és 'Minimal confidence to report' értéket Low-ra. A FindBugs eszközt a teljes projektre futtassuk.
    2. PMD-t csak a BookStoreUserConsole.java fájlra kell lefuttatni. Először az egy csökkentett szabálykészletet használjunk, csak a Basic, Controversial és Design kategóriákba tartozó szabályok legyenek aktívak. Később kapcsoljuk be az összes szabályt.
  4. Minden, az eszközök által megtalált hibára reagálni kell, mely a következők egyike lehet:
    1. A forráskód javítása a hibajelzés alapján, ilyenkor a javítást fel kell tölteni a saját SVN tárhelyre.
    2. Az adott szabály erre az előfordulásra nem releváns, ilyenkor ezt az adott eszközben jelölni kell a megfelelő indoklással együtt (pl. a PMD-ben Marks as reviewed).
    3. Egy adott szabály egyáltalán nem érvényes az adott projektre, így azt teljesen kikapcsoljuk. Ilyenkor ennek a tényét és az indoklást a saját wikire készülő jelentésben meg kell adni.
  5. Ehhez a házi feladathoz nem szükséges formális ellenőrző dokumentumot készíteni, elég az, ha egy táblázatban készül egy lista, hogy az egyes hibajelzésekre mit reagáltunk.
    1. Forráskód javítása esetén hivatkozzunk a megfelelő módosításra (SVN commit) a verziókezelő rendszerben (ld. a WikiFormatting#TracLinks oldalt a Trac wikin a részletekért). Fontos: Ez csak akkor működik, ha egy-egy módosítás nem túl nagy méretű. Lehetséges több, összetartozó javítást egy módosítással feltölteni (pl. több azonos típusú hiba javítása), de semmiképpen se egy módosításként kerüljön fel az összes javítás a rendszerbe.

HF3 - Fejlesztői tesztelés

Cél: Egységtesztek készítése TDD módszerrel.

Határidő: 2014. 11. 12. (szerda), 20:00 óra (a határidő leteltéig az SVN-be felkerült anyagokat értékeljük)

Kerettörténet: A BookStore projekt folyik tovább, most be kell szállnunk a discount modul fejlesztésébe. Itt a kedvezményszámítást végző calculateDiscountedTotalPrice függvényt kell implementálnunk. Ez a függvény paraméterül kapja egy vásárlás kedvezmények nélküli végösszegét és a vásárlást végző felhasználót, majd visszatérési értékként megadja a vásárló által ténylegesen fizetendő, kedvezményeket is tartalmazó árat.

Annak érdekében, hogy jó minőségű kód készüljön, a fejlesztés során a Test-Driven Development elvét kell követni, azaz előbb egységtesztet kell írni, majd utána elkészíteni az ahhoz szükséges funkcionalitást.

Bemenet: Az SVN src könyvtára tartalmazza a discount modul forrását és egy minta tesztprojektet.

Feladatok:

  • Irányelvek:
    • A discount modul forrásai közt megtalálható a DiscountManagerImpl.java fájl, ezt kell majd tovább bővíteni. A megvalósítandó calculateDiscountedTotalPrice metódus már szerepel benne, azonban a törzse még üres.
    • A metódus megvalósításáért mi vagyunk felelősek, a belső működése ránk van bízva. Azonban a metódus szignatúráját (bemenő paramétereit és visszatérési értékét) nem szabad módosítani. Új, privát metódusok létrehozása megengedett.
    • Az SRS átvizsgálása rámutatott, hogy a kedvezményszámítás nem volt elégségesen specifikálva. Ezért az SRS javított változatában ez a rész bővítésre került. A kedvezményszámítás javított specifikációja megtalálható az SVN-ben BookStore_SRS_discount.docx néven.
    • A hu.optxware.junitcourse.bookstore.discount.unittest projektbe kerüljenek az egységtesztek. Ez egy sima Java projekt, aminek be vannak állítva a megfelelő függőségek, és tartalmaz egy egyszerű teszt mintát. Ennek a projektnek mi vagyunk a gazdái, tehát létrehozhatunk benne később újabb teszt vagy kisegítő osztályokat.
    • Egységteszteket kell készíteni, így a DiscountManager függőségeit helyettesíteni kell. Ehhez a Mockito keretrendszert használhatjuk.
  • A házi feladat során a calculateDiscountedTotalPrice metódushoz kell teszteket készíteni és azok alapján megvalósítani a metódust.
    • A tesztek végiggondolását és megvalósítási sorrendjüket dokumentáljuk a csapat wiki oldalán (ennek nem kell formális dokumentációnak lennie, csak követhető legyen belőle az elvégzett munka).
    • Érdemes először a metódushoz szükséges teszteseteket végiggondolni (ehhez az előadásokon szó volt különböző teszttervezési módszerekről).
    • Vezessünk ezek után egy listát, hogy milyen sorrendben valósítottuk meg a teszteseteket.
    • Az egyes tesztesetek és az azok helyes lefutásához megírt kód legyen a commit egysége [ez csak a HF javítását könnyíti meg, egyébként nem feltétlen kéne ilyen kicsi granularitást választani].
    • Az implementáció során figyeljünk arra, hogy hiba esetén a lehető legspecifikusabb kivételt dobjuk. Ehhez használjuk a commons projekt exceptions csomagjában található kivételeket.
    • (A tesztek által elért kód lefedettséget nem kell ebben a szakaszban még mérni.)

HF4 - Teszttervezés és integrációs tesztelés

Cél: Korábbi tesztkészlet bővítése kódlefedettség mérése alapján, majd integrációs tesztek készítése.

Határidő: 2014. 11. 26. (szerda), 20:00 óra (a határidő leteltéig az SVN-be felkerült anyagokat értékeljük)

Kerettörténet: Az utolsó fázisban elsőként a korábban elkészített egységtesztek által elért lefedettséget kell vizsgálni, és esetlegesen kiegészíteni a tesztkészletet. Ezután egy másik modult, a kedvezményszámítást megvalósító discount modult kell vizsgálni, de most már integrációs tesztek segítségével.

Feladatok:

  1. Kód lefedettség: Mérjük meg, hogy az elkészített metódusokon milyen kódfedést érnek el a HF3-ban implementált tesztesetek! Ehhez használjuk az EclEmma 2.x verzióját (​http://www.eclemma.org/). (Ez a változat egy általa branch coverage-nek nevezett lefedettséget számol, de a gyakorlatban ez a decision és condition coverage bizonyos ötvözete.)
    1. A kód lefedettség alapján bővítsük a korábbi tesztkészletet, ha szükséges. A cél a 100%-os utasítás és döntés (decision) lefedettség. Ha ez valahol nem célszerű, tehát adott utasítás vagy döntési ág lefedése a jelenlegi tesztkörnyezetben nagyon körülményes lenne, ott ezt külön indokoljuk meg.
  2. Integrációs tesztek készítése:
    1. A feladat során a hu.optxware.junitcourse.bookstore.discount modul DiscountManager szolgáltatásának metódusaihoz (kivéve a calculateDiscountedTotalPrice() metódust) kell teszteket tervezni, majd azokat implementálni. A modul és a metódus definícióját és rövid leírását megtaláljuk a commons projektben. (A calculateDiscountedTotalPrice() metódus egyébként nincs is implementálva, hiszen a külső fejlesztői csapat által készített implementáció még értékelés alatt van.)
    2. Most csak pozitív teszteket szükséges implementálni, a hibás bemeneteket ebben a fázisban nem vizsgáljuk.
    3. Figyeljünk arra, hogy a feladat integrációs tesztek készítése. Feltételezhetjük, hogy a metódusokat már a fejlesztők egységtesztek segítségével vizsgálták (ekkor a BookStore függőség mockolva volt). Koncentráljunk azon elemek vizsgálatára, amelyek helyességét egy egységteszt nem tudta vizsgálni. A teszttervezés során írjuk le, hogy a kód milyen aspektusai azok, amik feltételezhetően nem voltak az egységtesztekkel kellőképp ellenőrizve.
    4. A dokumentáció inkább a minőségre és érthetőségre fókuszáljon, ne a mennyiségre. A fontos az, hogy a koncepcióitok, döntéseitek érthető legyen a leírás alapján, illetve hogy egyértelmű legyen, milyen teszteket miért végeztetek el.
    5. Az alkalmazás beüzemelésével kapcsolatos segítséget a doc/development_notes.md fájlban találunk. Az újabb modulokat nem forrás szintjén kapjuk meg, hanem csak lefordított csomagokat kapunk belőlük. A korábban kiadott források közül egyiket sem kell ehhez a feladathoz használni, csak a dist és test mappák tartalmára van szükség.
    6. Tesztfuttató keretrendszerként használhatjuk a JUnitot és az előre elkészített teszt projektet (hu.optxware.junitcourse.bookstore.discount.test). (Figyelem, bár a JUnit keretrendszert használjuk, ezek most ne egységtesztek legyenek, ne izoláljuk a tesztelt modult, hanem vizsgáljuk a függőségeivel együtt.) A JUnitnál vannak specifikusabb keretrendszerek OSGi integrációs tesztelésnél (pl. Pax Exam), lehet ezeket is használni, csak ezeknek a kezdeti konfigurációja időt igényel.
    7. A tesztelés során azonosított incidenseket vigyük fel a csapat Trac incidenskezelő rendszerébe. Figyeljünk oda, hogy az incidensek leírása minél pontosabb és részletesebb legyen.

Nyelvek

  • English
  • Magyar

Belépés

Navigáció