CVS (Concurrent Versions System)

CVS egy kliens-szerver architektúrára épülő, ingyenes verzió követő rendszer, melynek alapjait Dick Grune fektette le 1986 júliusában pár shell script formájában. Segítségével egyszerre több emberek dolgozhat ugyanazon a projekten (akár ugyanazokon a file-okon!), anélkül, hogy a különböző fejlesztők változatai összekeverednének. A CVS az RCS (Revision Control System) változatkezelő rendszeren alapul, kiterjesztve azt olyan módon, hogy a fájlok csoportjaira menedzsment eszközöket biztosít (az RCS egyes file-ok menedzselését valósította meg).

2, Működése
A projekthez szükséges file-okat egy központi „repository”-ban tárolja a CVS. A file-okat verzió-követve tárolja, vagyis minden „commit”-olás után új verzió keletkezik (de a régiek sem vesznek el!).
Ebből a „repository”-ból (a megfelelő jogosultságok birtokában) egy adott fejlesztő bármikor készíthet egy lokális másolatot a saját filerendszerébe a „check out” paranccsal. Később, amennyiben újabb verzió érhető el valamelyik file-ból, az „update” paranccsal frissítheti azt. A „check out”-olt file-okat szabadon lehet módosítani. Ha ezalatt valamilyen módosítás kerül be a „repository”-ba, akkor az „update” össze-„merge”-öli az új részeket a lokálisan tárolt változatban a felhasználó változtatásaival. Amennyiben ezt nem tudja megtenni, „conflict” keletkezik, ami emberi beavatkozást igényel (ez akkor szokott előfordulni, ha a lokális és a központi változások azonos részeket érintenek, de még ilyenkor sem minden esetben). Ha a fejlesztő elkészült a változtatásaival, feltöltheti azokat a „repository”-ba a „commit” paranccsal. Ezzel minden érintett file verzió száma („revision”) megnő eggyel. Mivel CVS az egyes file-ok minden verzióját tárolja, így egy korábbi állapot bármikor visszaállítható.

3, Alapfogalmak
„repository” – a cvs-ben tárolt adatok központi „raktára”
„module” – a CVS egy logikai egysége, általában egy module-t használunk projektenként
„revision” – egy filecsoport adott verziója
„revision number” – numerikus szimbólum egy filecsoport adott verziójának jelölésére a következő módon: ’.’-al elválasztott számpárok sorozata és általában 1.1-ről indul (elágaztatás, vagyis branch készítése esetén ez a számsor kibővülhet újabbakkal)
„head-revision” – az elérhető legfrissebb verzió
„check out” – az adott projekthez tarozó file-ok letöltése a „repository”-ból, lokális másolat készítése
„update” – az előző „update” (ha még nem volt akkor a „check out”) óta a „repository”-ba bekerült változtatások letöltése a felhasználó filerendszerében tárolt másolatba
„commit” – a lokális másolat változásainak feltöltése a „repository”-ba
„add” – új file hozzáadása a „head-revision”-höz (innentől a projekt része)
„remove” – már a „repository”-ban lévő file-t lehet eltávolítani a „head-revision”-ből (korábbi verziói ettől függetlenül elérhetőek)
„history” – adott file „családfáját”, azaz előzményeit (korábbi verzióit) lehet lekérdezni vele
„merge” – két különböző verzió összefésülése
„conflict” – olyan eltérés két változat között, amit a CVS maga képtelen feloldani (főként „update” vagy „commit” esetén fordulhat elő)
„status” – egy CVS felügyelet alatt álló file állapota, ami a lokális másolatra vonatkozik

1. up-to-date: azonos a repositoryban lévő változattal
2. locally modified: a file-t lokálisan módosították, ezért „commit” szükséges
3. needing update: valaki más módosított és „commit”-ált egy újabb változatot a „repository”-ba, de a lokális másolat még nem módosult
4. needing merge: valaki más módosított és „commit”-ált egy újabb változatot a „repository”-ba, és a lokális másolat is módosult

4, Branch
A CVS segítségével szét lehet választani a fejlesztést különböző ágakra, ezeket hívjuk „branch”-eknek. Amikor egy file-t megváltoztatunk a „branch”-ben, a módosítások nem jelennek meg a fejlesztés fő ágában („trunk”, azaz törzs). Később természetesen egybe lehet őket olvasztani a megfelelő változtatások átvitelével egyikből a másikba („merge”-ölés).
Példáult egy fejlesztő szeretne kipróbálni valamit, de nem biztos abban, hogy az működni fog. Ilyenkor indíthat egy saját „branch’-et (ágat), ami elágazik a „trunk”-ből. Megtehetné azt is, hogy a saját renszerén kísérletezik ezzel, de így nem használná ki a CVS nyújtotta előnyöket.
Okot adhat egy új branch létrehozására az is, ha például új „release”-t szeretnénk kiadni a szoftverből.

5, Tag (symbolic names)
A CVS tag-eket használ a projekt egyes verzióinak megkülönböztetésére. Egy adott tag-hez a aktuális branch vagy trunk legfrissebb file-jainak verziószámát menti el a rendszer (mintha egy pillanatkép lenne az aktuális állapotról).
Hasznos lehet például „merge”-ölés előtt és után „tag”-elni a „branch”-ünket, így később könnyen visszaállítható ez az állapot („check out as”-el ki lehet menteni egy adott tag-hez tarzozó file-okat). Egyébként nyugodtan használható szinte bármikor, amikor úgy gondoljuk, hogy szükség lehet rá (ártani nem árt, de sokszor nagyon hasznos lehet).
Természetesen fontos, hogy az elnevezésre itt is ügyeljünk, tartsuk be az adott „repository”-t használó csoportunk által alkalmazott konvenciókat.

6,Források, linkek és további információ
http://en.wikipedia.org/wiki/Concurrent_Versions_System
http://cvshome.org/eng/
http://ipv6.niif.hu/tipster6/papers/cvs_overview/

Téma: Tesztelés

Témavezetők: Pali, Krisztián
Leírás:

A Brainstorming témája a szoftvertesztelés volt. A szoftvertesztelés a szoftverfejlesztés egyik kiemelt szakasza, fontosságát az is jelzi, hogy a tesztelési erőfeszítések közel felét ennek a szakasznak a sikerre vitele jelenti. Nyilvánvaló, hogy a megírt szoftver hibátlanságáról és használhatóságáról meg kell győződni, mielőtt azt a megrendelő használatba venné.

A tesztelés általában két szinten zajlik, modul és rendszer szinten, a modulszintű tesztelés esetén a modulokat a teljes rendszerből kiemelve, szeparáltan tesztelik le, míg a rendszerszintű tesztelésnél a teljes rendszert vizsgálják összefüggéseiben.

A tesztelés két fő  típusát különböztetjük meg, ezek a validációs ill. a verifikációs tesztelések. A verifikációs teszt a programozás helyességét, a programírás és tervezés mérnöki folyamatának hibátlanságát vizsgálja, míg a validációs tesztelés a specifikációnak, a felhasználó igényeinek való megfelelést vizsgálja. A kétféle teszt végrehajtása biztosítja, hogy jó minőségű és funkcionálisan megfelelő szoftver készült.

A tesztek elvégzésére általában két utat különböztetünk meg. A fejlesztők általában úgynevezett white box tesztelést folytatnak, míg a tesztelők főleg black vagy iron box tesztelést. A white box tesztelés lényege, hogy a tesztelő belelát a kódba, míg a black box tesztelésnél a tesztelő csak azt tudja, milyen kimenet várható el egy bizonyos bemenet esetén, de a belső funkciók működését nem ismeri.

Ez a két megközelítés egyben a tesztesetek tervezésénél is meghatározó, a white box tesztek tervezésénél strukturális teszteket terveznek, míg a black box tesztelésnél rengeteg technika ismert, például tapasztalaton alapuló, ekvivalencia - partícionálás, határérték-analízis, ok-hatás analízis.

A tesztelési visszacsatolás általában manuális követést jelent, a tesztelés szempontjából ez rendkívül fontos, hiszen ez alapján lehet kiértékelni a tesztelés eredményességét, illetve követni a tesztelési folyamat állapotát.

A manuális tesztelésen kívül léteznek automatizált tesztelési módszerek is. Az automatizált tesztelés eléggé megosztja a tesztelőket, általánosságban elmondható, hogy az automatizált tesztek létrehozása már magában is egy mini fejlesztési folyamat, a tesztelési idő nem csökken az automatizált tesztek esetében, csak a ráfordítás csökkenhet, de ez sem minden esetben.