FORRÁSKÓD KÖVETŐ RENDSZEREK Rajacsics Tamás raja@aut.bme.hu BME AAIT
Forráskód követő rendszerek Cél Verzionálás Központi tárolás, előhívás Hozzáférés kezelés / csatorna titkosítás Biztonság / mentés Sebesség / adatmennyiség Integráció a fejlesztőeszközzel
Forráskód követő rendszerek Extrák Összefésülés támogatás Polc Biztonsági mentés Dinamikusan allokált munkahely Checkout szerint Kizárólagos Megosztott Nincs checkout
A forrásfa A forráskód a rendszer komponenseinek megfelelő irányított gráf A levélelemek tartalmazzák az egyes komponensek forráskódját
Hogyan építsük fel a forrásfát? Legyen benne minden, ami a termék elkészítéséhez kell Forráskód + eszközök = termék (ez a build környezet) A dokumentumoknak is a forráskód követő rendszerben a helyük Ne szennyezzük a fordítás során előálló fájlokkal Minden egyes ágnak legyen gazdája Az eszközöket célszerű külön elhelyezni
Példa forrásfa szerkezet d:\sources \foo \binary_release \x86 \specs \src \feature1 \feature2 \testsrc \bvt \feature1 \feature2 \tools
Külső függőségek Amikor egy másik csapat vagy projekt eredményeit kell felhasználnunk Microsoft komponensek ActiveX kontrollok A forrásfa meghatározott részére kerül a másik projekt bináris-fájának egy része Követelmények az átadott binárisokkal szemben: Binárisok és teljes debug info (PDB) az összes támogatott platformra
Forrásfa házirend Meghatározza, hogy milyen szabályok szerint lehet kódot elhelyezni a forrásfában Milyen időközönként Milyen jóváhagyást igényel Milyen minőségi feltételeknek kell eleget tegyen Beadási szabályok (Checkin policy) Adminisztratív eszközökkel betartandó A fejlesztőket oktatni kell Ha nem lehet betartani, elágaztatásra van szükség
Esettanulmány Kis/közepes csapat (5-7 fejlesztő) Nincs leágaztatás Fejlesztők többnyire átlátják a folyamatot De beleírnak mindenbe Vajon kell-e ilyen egyszerű esetben is SCC? Már két embernél is sokat segít Egyetlen fejlesztőnél is van előny!
TESZTELÉS Rajacsics Tamás raja@aut.bme.hu BME AAIT
Tesztelés Minőséget nem lehet beletesztelni a szoftverbe A teszt célja: ellenőriz és visszajelez, hogy a szoftver megfelele a kitűzött követelményeknek specifikált működés elvárt teljesítmény üzembiztonság egyéb általános elvárások
Tesztek a napi ciklusban Fejlesztői regresszióteszt a fejlesztő végzi, még beadás előtt kibírja-e a termék a változást? white box, automatizált Telepítési teszt telepíthető-e? Build Verification Test megvannak-e az alapvető működések ki lehet-e adni a build-et további tesztelésre? automatizált
Tesztek a napi ciklusban Unit Test az egyes modulok, funkciócsoportok részletes tesztje Regression Test visszajöttek-e egyszer már kijavított hibák? bugs tend to cluster a baj nem jár egyedül változások átvezetése a forrásfa egyes ágai között
Tesztek a napi ciklusban Stress test Megpróbáljuk szétverni a szoftvert Érvénytelen input, óriási adatkészlet, erőforrások mesterséges korlátozása Általában éjszaka fut, reggel debugoljuk a döglött példányokat. Komoly tervezést és infrastruktúrát igényel! Terhelési teszt ha van teljesítmény-kritérium gondos tervezést igényel
Tesztek a napi ciklusban Ad-hoc teszt játszunk a szoftverrel, és figyeljük, mit csinál (szimuláljuk az egyszerű felhasználót) nem determinisztikus nagyon kell figyelni, hogy reprodukálható legyen legtöbbször kiinduló pont az automatizált tesztekhez
A megtalált hibák kezelése Minden hiba, ami valamilyen szempontból nem felel meg a követelményeknek az elvárásoknak Jelentjük. Az összeset. Adatbázisban rögzítjük statisztikák hibák életciklusának követése
Egy hiba adatai Rögzítendő azonosító (automatikusan generált egyedi kulcs) tárgy (rövid leírás) szoftver verziószáma konfiguráció oprendszer, hardver, egyéb szoftverkörnyezet a hiba részletes leírása reprodukciós lépések a szükséges csatolt állományok fontossági / súlyossági besorolás (severity/priority) terület / alterület
Fontosság Fontosság (priority): milyen fontos megjavítani Pri 4: majd Pri 3: amikor időnk engedi még a termék kiadása előtt Pri 2: még ebben a szakaszban Pri 1: most Pri 0: azonnal Pri 0 HOT: már kész kéne, hogy legyen áll a vezér gépe
Súlyosság Mekkora galibát okoz? Sev 4: nem szép Sev 3: kicsit zavar a működésben, elkerülhető Sev 2: komolyabb hiba, hiányosság Sev 1: adatvesztés, összeomlás, súlyos hiba valamilyen szempontból használhatatlanná teszi a terméket
Kategóriák Súlyosság fontosság de nem automatikusan Pri 1, Sev 4: Micorosoft Office XP Pri 4, Sev 1: a teszter otthoni XT-jén letörli a FAT-táblát, ha a program indításával egyidejűen dugja be a mentéshez használt VHS-videomagnót.
A hiba életciklusa Aktív A hiba gazdája aki az adott hibával foglalkozik az életciklus minden stádiumában létezik egyéni vagy csoport
A hiba életciklusa Aktív megoldás Megoldott A megoldás visszaküldi a hibát ahhoz, aki megnyitotta Feladat: ellenőrizni a megoldást
Megoldási módok Megoldás Ki teheti További teendő Javítva Fejlesztő ellenőrizni Elhalasztva (kockázatkezelés) Nem javítjuk (alapvető probléma, erőforráshiány) Így terveztük It s not a bug, it s a feature Már létező hiba (duplikált) Nem reprodukálható Program-menedzser Program-menedzser Program-menedzser Fejlesztő Tesztelő ált. fejlesztő dokumentálni későbbi követelmény dokumentálni végfelhasználói dokumentáció, ha szükséges megadni az eredeti hiba azonosítóját
A hiba életciklusa Aktív Lezárás ha a hiba gazdája elégedett a javítással Megoldott Lezárt lezárás
A hiba életciklusa Aktív reaktiválás Megoldott Lezárás ha a hiba gazdája elégedett a javítással Reaktiválás ha elégedetlen Lezárt
A hiba életciklusa Lezárás Aktív ha a hiba gazdája elégedett a javítással Reaktiválás reaktiválás Megoldott ha elégedetlen Lezárt hiba is reaktiválható regressziós teszt Lezárt további ellenőrzés során
Mire használjuk az adatbázist? Aktív hibák: megoldjuk Megoldott hibák: megnyitóik ellenőrzik Lezárt hibák: elhalasztott, nem javítandó: dokumentáljuk javított: bevesszük a tesztekbe regressziós teszt unit teszt Összességében: statisztikák
Statisztikák Új hibák beérkezési sebessége Hibamegoldási sebesség javítási sebesség: tervezhető, kb. 2/fejlesztő/nap Konvergencia amikor többet oldunk meg, mint ahányat találunk a stabilizáció kezdete
Statisztikák Mikor lesz kész a szoftver? aktív hibák számának csökkenő trendje adja meg Kiadási stádiumok konvergencia Nulla aktív hiba ZBB: zero bug bounce RC Gold Kiadás
Példa konvergencia ZBB
Tesztek típusai Coverage testing (ideális célok) A termék összes funkcióját teszteli A termék minden kódsorát teszteli Elsősorban a fejlesztési fázisban használatos Usage testing Tipikus feladatok végrehajtása Tesztelés az éles környezetben Elsősorban a stabilizációs fázisban Átadás átvételi teszt A rendszer megfelel-e a specifikációnak Felhasználó résztvételével
Automatizálás Többrétegű alkalmazás esetén érdemes rétegenként, komponensenként teszteket készíteni Minimálisan Megbízható Mag A teszt tesztje... Teszt adatbázis tesztadatok!
Teszt keretrendszerek NUnit (junit-ból), cstest, harnessit, x-unity szerelvény alapú attribútummal jelölt metódusokat futtatnak több szál VS.NET integrációs ACT: application center test webes alkalmazások sebességtesztje