FORRÁSKÓD KÖVETŐ RENDSZEREK. Rajacsics Tamás BME AAIT

Átírás

1 FORRÁSKÓD KÖVETŐ RENDSZEREK Rajacsics Tamás BME AAIT

2 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

3 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

4 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

5 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

6 Példa forrásfa szerkezet d:\sources \foo \binary_release \x86 \specs \src \feature1 \feature2 \testsrc \bvt \feature1 \feature2 \tools

7 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

8 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

9 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!

10 TESZTELÉS Rajacsics Tamás BME AAIT

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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.

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 Példa konvergencia ZBB

31 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

32 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!

33 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