Gyors szoftverfejlesztés A fejezet célja Megértetni, hogyan vezethet egy iteratív, inkrementális szoftverfejlesztési megközelítés a

használhatóbb szoftverek gyorsabb átadásához Az agilis fejlesztési módszerek és a dokumentált specifikációkon, terveken alapuló szoftverfejlesztési

módszerek közti különbségek megbeszélése Megismertetni az extrém programozás alapelveit, gyakorlati alkalmazásait és néhány korlátját A prototipizálás szerepének megértése a szoftverfolyamatban A fejezet témái Agilis módszerek Extrém programozás Gyors alkalmazásfejlesztés Szoftverprototípus készítése Gyors szoftverfejlesztés A gyorsan változó gazdasági környezet miatt a vállalatoknak gyors válasszal kell reagálniuk a

versenykihívásokra, kihasználva az új lehetőségek adta előnyöket. A szoftverrendszereknél így ma az egyik legkritikusabb követelmény a gyors fejlesztés és üzembe

helyezés. Sok vállalat hajlandó engedni a minőségből és kompromisszumokat köt a szoftver gyors üzembe

helyezése érdekében. Követelmények A folyamatosan változó környezet miatt, sokszor gyakorlatilag lehetetlen, hogy a szoftverrel

kapcsolatban stabil elvárásokat fogalmazzanak meg. Ezért a hagyományos vízesés modell nem felel meg a fejlesztéshez, hanem iteratív folyamat

alkalmazása a célravezető, ahol a specifikáció, a tervezés, a fejlesztés és a tesztelés átfedi egymást. A RAD folyamatok néhány közös jellemzője A specifikáció, a tervezés és az implementálás folyamata konkurens módon zajlik. Nincs részletes

rendszer-specifikáció, a tervezési dokumentáció minimális. A felhasználói elvárások leírása csak a rendszer legfontosabb jellemzőit határozza meg.

A rendszert lépésről lépésre fejlesztik. A végfelhasználók is részt vesznek minden lépés specifikálásában és kiértékelésében. Új követelményeket és változtatásokat fogalmazhatnak meg, melyeket egy későbbi fejlesztési lépésben kellene megvalósítani.

A rendszer felhasználói felülete gyakran egy beépített fejlesztői környezet használatával készül el. Egy iteratív fejlesztési folyamat

Az inkrementális fejlesztés előnyei Az ügyfélszolgáltatások gyorsított átadása. A rendszer korai inkremensei tartalmazhatják a

leglényegesebb funkcionalitásokat, így az ügyfél a rendszerből már a fejlesztés korai szakaszában is hasznot tud húzni. A gyakorlati megvalósítást látva megfogalmazhatnak változtatásokat.

Felhasználói elkötelezettség a rendszerrel mellett. Visszajelzéseket adnak az előző lépés után elkészült rendszerről. Részvételük nem csak azt jelenti, hogy a rendszer sokkal inkább meg fog felelni a követelményeknek, hanem azt is, hogy a végfelhasználók elkötelezték magukat a szoftver használata mellett és szeretnék működő állapotba hozni azt.

Az inkrementális fejlesztés problémái Kezelési problémák

Nehéz megítélni az előrehaladottság állapotát és nehezebb megtalálni a problémákat, mert nem áll rendelkezésre klasszikus struktúrájú rendszerdokumentáció.

Szerződésbeli problémák Egy hagyományos szerződés a rendszerspecifikáción alapszik; ennek hiányában más alapon kell

a szerződést megkötni. Validációs problémák

Ha nincs meg a specifikáció, hogyan teszteljük a rendszert? Karbantartási problémák

A folyamatos változtatás hibás szoftverstruktúrához vezethet, amely még drágábbá teheti a változtatást és az újabb igényeknek való megfelelést.

Prototípus-készítés Nagyobb rendszerek esetében az inkrementális fejlesztés és átadás nem a legjobb megközelítés;

különösen igaz, ha több, más-más helyen levő csoport fejleszti a rendszert. A prototípus-készítés olyan kísérleti rendszerek kifejlesztésének iteratív folyamata, amely segít

megérteni a szoftverfejlesztőnek és az ügyfélnek, hogy valójában mit is kell implementálni. A prototípus a folyamat végén eldobásra kerül, nem kerül az ügyfélhez kihelyezésre.

Inkrementális fejlesztés vs. eldobható prototípus-készítés Követelmények körvonalazása Inkrementális fejlesztésÁtadott rendszer Eldobható prototípus-készítés Futtatható prototípus + rendszerspecifikáció Különböző célkitűzések Az inkrementális fejlesztés célja, hogy egy működő rendszert szolgáltasson a végfelhasználóknak. A

fejlesztés a leginkább megértett és legmagasabb prioritású felhasználói követelményekkel indul. Az eldobható prototípus-készítés célja, hogy validálja vagy származtassa a rendszerkövetelményeket.

Ekkor a legkevésbé érthető követelményekkel célszerű kezdeni. Agilis módszerek Az időigényes tervezési módszerekkel való elégedetlenség miatt a 90-es években létrejöttek az agilis

módszerek: Inkább a szoftverre való fokuszálás a terv és a dokumentáció helyett; A specifikáció, a fejlesztés és az átadás iteratív megközelítésére alapoznak; Célja, hogy a működő szoftvert minél hamarabb átadhassák az ügyfélnek, aki ezt követően új és

változtatott követelményeket javasolhat. Az agilis módszerek a kis- és középvállalkozások rendszereinek, illetve a személyi számítógépes

termékek fejlesztésére a legalkalmasabbak.

Az agilis módszerek alapelvei Az ügyfél bevonása

Az ügyfeleket minél jobban be kell vonni a fejlesztési folyamatba. A szerepük az, hogy a rendszerkövetelményekről gondoskodjanak, azokat priorizálják és kiértékeljék a rendszer minden egyes iterációját.

Inkrementális átadás A szoftver lépésenként fejlődik, az ügyfél adja meg a követelményeket, amelyeket majd az egyes

lépésekben implementálni kell. Az emberek nem folyamatok

A fejlesztőcsapat képességeit ismerni kell és ki is kell használni. Hagyjuk, hogy a csapattagok a feladatokat a saját módszerükkel végezzék el, nem pedig előírt folyamatok szerint.

Változtatási lehetőség Számítani kell a rendszerkövetelmények változására és úgy kell tervezni a rendszert, hogy azzal

összeegyeztethetők legyenek ezek a változások. Kezelési egyszerűség

Az egyszerűségre kell koncentrálni mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Dolgozni kell a rendszer komplexitásának csökkentésén.

Problémák az agilis módszerekkel Gyakran nehéz megtartani a bevont ügyfél érdeklődését a fejlesztési folyamatban. Esetleg az egyes csapattagok nem rendelkeznek megfelelő személyi adottságokkal az intenzív

részvételhez, ami viszont jellemző az agilis módszerek esetében. A változtatások fontossági sorrend szerint való elrendezése nehéz olyan rendszereknél, ahol sok

érintett van. Az egyszerűség fenntartása külön munkát igényel. Az inkrementális specifikáció miatt a szerződések megkötése nehezebb lehet. Extrém programozás Talán a legismertebb és legszélesebb körben használt agilis módszer. Az extrém programozás (XP) az iteratív fejlesztés „extrém” megközelítését használja.

Naponta többször megjelenhet a szoftver egy új verziója; Az inkremensek nagyjából kéthetente kerülnek az ügyfélhez; Minden teszten végig kell futtatnia a következő verziót és az csak akkor fogadható el, ha minden

teszt sikeresen lefutott. Az extrém programozás kiadási ciklusa A kiadáshoz tartozó felhasználói történet kiválasztása A történet feladatokra bontása A kiadás tervezése A szoftver fejlesztése / integrálása / tesztelése A szoftver kiadása A rendszer értékelése Az XP magában foglalja az agilis módszerek alapelveit Az inkrementális fejlesztés a rendszer kisméretű, gyakori kiadásán keresztül valósul meg, valamint a

követelmények felhasználói történetekkel való megadásával. A forgatókönyvek a folyamattervezés alapját képezik.

Az ügyfél részvételének biztosítása elérhető a fejlesztőcsapatba történő teljes munkaidős bevonásával. Részt vesz a fejlesztésben és a rendszer elfogadási tesztjeinek meghatározásáért felelős.

A párban való programozás, a rendszerkód feletti együttes tulajdonjog, illetve egy olyan fejlesztési folyamat, amely nem von maga után felesleges munkaórákat, az embereket támogatja, nem a folyamatokat.

A változtatásokat a rendszeres rendszerverziók, az előrehozott tesztelést alkalmazó fejlesztés és a folyamatos integráció támogatja.

Az egyszerűség fenntartásához szükséges a kód minőségének folyamatos tökéletesítéssel történő növelése.

Követelmények és forgatókönyv Az XP-folyamatban minden követelményt forgatókönyvként állítanak össze (felhasználói történet). Közösen kifejlesztenek egy történetkártyát, ami magában foglalja az ügyfél kéréseit. A fejlesztőcsapat

ezt feladatokra bontja és megbecsüli az implementáláshoz szükséges időt és erőforrásokat. Az ügyfél ezután rangsorolja az implementálandó történeteket a prioritásuk és a megvalósításukhoz

szükséges idő alapján. Dokumentumletöltés történetkártyája

Egy cikk letöltése és kinyomtatása

Először válasszuk ki egy megjelenített listából a kívánt cikket. Aztán adjuk meg a rendszernek a fizetési módot – ez történhet előfizetéssel, vállalati számláról vagy hitelkártyával. Ezután kapunk egy kitöltendő szerzői jogi űrlapot. Ha ezt elküldtük, a cikk letöltődik a számítógépünkre. Ezután választunk egy nyomtatót és kinyomtatjuk a cikk egy másolatát. Közöljük a rendszerrel a sikeres nyomtatás tényét. Ha a cikk csak nyomtatható, akkor nem őrizhetjük meg a PDF-verziót, így az automatikusan törlődik a számítógépünkről.

XP és a változtatások A hagyományos szoftvertervezés egyik alapelve, hogy a változtatásokra kell tervezni. Érdemes időt és

energiát szentelni az előretekintésre, hogy milyen változtatások várhatóak a jövőben, mivel ez költségcsökkenést okoz a teljes életciklusban.

Az XP figyelmen kívül hagyja ezeket az alapelveket mondván, hogy gyakran nem az előre megjósolt változtatások valósulnak meg.

Inkább a szoftver folyamatos kódátszervezését javasolja, tehát a programozócsapat tökéletesítési lehetőségeket keres a szoftverben.

A dokumentumletöltés feladatkártyái 1. feladat: A fő munkafolyamat implementálása 2. feladat: A cikk-katalógus és –kiválasztás implementálása 3. feladat: A fizetési lehetőségek implementálása 4. … A dokumentumletöltés feladatkártyái (ez egy példa lehet?)

3.feladat: A fizetési lehetőségek implementálása

A fizetés három különböző úton történhet. A felhasználó kiválasztja, hogy milyen módon szeretne fizetni. Ha a felhasználónak van könyvtári olvasójegye, akkor beírhatja ide annak az azonosítóját, amit a rendszernek ellenőriznie kell. Másik lehetőség, hogy megad egy szervezeti számlaszámot. Ha az érvényes, akkor a cikknek megfelelő költséggel megterhelik a számlát. Végül beírható a 16 számjegyből álló hitelkártyaszám és a lejárati dátum. Ellenőrizni kell ennek az érvényességét és amennyiben érvényes, akkor terhelést kell küldeni a hitelkártyaszámlára.

Tesztelés az XP-ben

l Előrehozott teszteléssel történő fejlesztés l Inkrementális tesztfejlesztés a forgatókönyvek alapján l Felhasználók bevonása a tesztek fejlesztésébe és validálásába l Automatizált tesztelőeszközök használata

Tesztesetleírások

Hitelkártya érvényességének ellenőrzése

Bemenet: A hitelkártyaszámot egy karaktersorozat, míg a kártya lejárati hónapját és évét két egész szám reprezentálja. Tesztek: Ellenőrizni kell, hogy a karaktersorozat minden bájtja számjegy-e. Ellenőrizni kell, hogy a hónap 1 és 12 között van-e és az év nagyobb vagy egyenlő-e az aktuális évvel. A hitelkártya számának első négy számjegye alapján ellenőrizni kell a kibocsátó érvényességét a kártyakibocsátók táblázata alapján. A hitelkártya érvényességét ellenőrizzük úgy, hogy elküldjük a kártyaszámot és a lejárati dátumot a kártya kibocsátójához. Kimenet: Ok vagy hibaüzenet, ami a kártya érvénytelenségét jelzi.

Előrehozott teszteléssel történő fejlesztés A teszt előzetes elkészítése a kód megírása előtt feltételezi a követelmények és a specifikáció pontos

ismeretét, amelyeket majd implementálni kell. A tesztet, mint futatható komponenst előbb írjuk meg, mint ahogy a feladatot implementálnánk. Az

implementáció után a teszt rögtön futtatható az automatizált tesztkörnyezet segítségével. A összes korábbi és új teszt automatikusan futtatásra kerül, amikor egy új funkcionalitás hozzáadásra

kerül a rendszerhez. Így ellenőrizhető, hogy az új funkcionalitás nem okozott hibát a már meglévő alkalmazásrészekben.

Páros programozás Az XP folyamatban a programozók párban dolgoznak a szoftverfejlesztés alatt, gyakorlatilag együtt

ülnek ugyanahhoz a munkaállomáshoz a szoftver fejlesztésére. Támogatja a rendszerre vonatkozó közös tulajdon és felelősségtudat érzését. Úgy működik, mint valamilyen informális átvizsgálási folyamat, mert minden egyes kódsort legalább két

ember átnéz. Segít a kódátszervezésben, ami a szoftver tökéletesítésének egy folyamata. A fejlesztői eredményesség a párban való programozás esetében vetekedik a két külön dolgozó egyén

termelékenységével. Gyors alkalmazásfejlesztés Bár az agilis módszerek nagy figyelmet kaptak az elmúlt néhány évben, a vállalati rendszereket már sok

éve fejlesztik iteratívan, gyors alkalmazásfejlesztési technikákat használva. Adatintenzív üzleti alkalmazások fejlesztésére használták. Olyan eszközkészletekbe vannak szervezve,

melyek adatokkal kapcsolatos programozási feladatokat valósítanak meg. A RAD-környezetben található eszközök Adatbázis-programozási nyelv Interfész-generátor Kapcsolat irodai szoftverekkel Jelentésgenerátor Egy RAD környezet

Verifikáció és validáció A fejezet célja A verifikáció és validáció bemutatása, a köztük lévő különbség tisztázása A programátvizsgálás, mint a programban előforduló hibák felderítésének módszerének megismerése Az automatizált statikus elemzés és a verifikációba és validációban betöltött szerepének elemzése A statikus elemzés megismerése a Cleanroom fejlesztési folyamatban A fejezet témái Verifikáció- és validációtervezés Szoftverek átvizsgálása Automatizált statikus elemzés Verifikáció és formális módszerek Verifikáció és validáció Verifikáció:

„A terméket jól készítjük el?” A szoftver megfelel specifikációjának. Validáció:

„ A megfelelő terméket készítjük el?” A szoftver megfelel-e a megrendelő elvárásainak? A V & V folyamat A teljes szoftverfejlesztési folyamatot átöleli, minden szintjén megjelenik Két fő célja

A rendszer hibáinak felfedezése Annak a vizsgálata, hogy egy rendszer hasznos és használható-e működés közben

V& V céljai A verifikációs és validációs folyamat célja megbizonyosodni arról, hogy a szoftverrendszer a „célnak

megfelel”. Ez nem jelenti azt, hogy teljesen mentes a hibáktól. Inkább azt jelenti, hogy „elég jónak” kell lenni arra a célra, amire használni akarják. Az elfogadási szint több tényezőtől függ. V & V elfogadási szint Függ a rendszer céljától, a rendszer felhasználóinak elvárásaitól és a piaci környezettől

Szoftver funkció Mennyire kritikus a szervezet számára a szoftver

Felhasználói elvárások Bizonyos szoftverekkel szemben lehetnek alacsonyabbak a felhasználói elvárások

Piaci környezet Hamarabb kijönni a piacra, fontosabb lehet, mint a hibák megtalálása

Statikus és dinamikus ellenőrzés Szoftverátvizsgálások. A rendszer reprezentációját elemzik és ellenőrzik (követelmény dokumentumot,

tervábrákat, forráskódot) (statikus elemzés) Kiegészíthető automatikus terv és kódelemzéssel

Szoftvertesztelés. Az implementáció működés közbeni vizsgálata, tesztadatokkal (dinamikus elemzés) A rendszert tesztadatokkal futtatják és működését figyelik

Statikus és dinamikus V&V

Program tesztelése Csak az előbúvó hibát lehet megtalálni Az egyetlen technika a nemfunkcionális követelmények tesztelésére a program végrehajtása A statikus elemzéssel együtt ad teljes eredményt Tesztelési típusok Hiányosságtesztelés

A rendszer hiányosságainak feltárására szolgáló teszt Validációs teszt

Megmutatja, hogy a szoftver megfelel a követelményeknek A sikeres teszt megmutatja, hogy a szoftver megfelel a követelményeknek, vagyis ez az, amit a

vásárló/megrendelő szeretne Tesztelés és belövés A tesztelés és a belövés két külön folyamat. A tesztelés a hibák felfedésére szolgál A belövés a hibák helyének meghatározása és ezek kijavítása A belövés folyamata

V & V tervezése Körültekintő tervezés szükséges a megfelelő tesztelési és felügyeleti folyamatok kidolgozásához A tervezési szakasz korai fázisában kell elkezdődnie Egyensúlyt kell kialakítania a verifikáció és a validáció statikus és dinamikus technikái között A teszttervezés nemcsak a terméktesztek leírására szolgál, hanem szabványok megalkotására is a

tesztelési folyamat számára

Teszttervek, mint fejlesztés és tesztelés közötti kapcsolatok (V-model)

A tesztelési terv fő komponensei A tesztelési folyamat A követelmények nyomonkövethetősége Tesztelt elemek A tesztelés ütemezése Tesztdokumentáló eljárások Hardver- és szoftverkövetelmények Megszorítások Szoftverek átvizsgálása Áttekinthetjük a szoftverrendszert hibák, kimaradt részek és anomáliák után kutatva Az átvizsgálás statikus folyamat, nem kíván programvégrehajtást, így a valós működés előtt

alkalmazható A szoftver bármilyen olvasható reprezentációja (követelmények, terv) átvizsgálható Hatékony technika a program hibáinak felfedésére Átvizsgálás előnyei Sok különböző hiba felderíthető egy átvizsgálási folyamatban. A tesztelésnél egy hiba más hibákat

elfedhet, ezért több futtatás szükséges. A szakterületi és programozási ismeretek újrafelhasználhatók, az átvizsgálást végzők valószínűleg

találkozhattak hasonló típushibával Átvizsgálás és tesztelés Az átvizsgálás és tesztelés egymást kiegészítő és nem egymást helyettesítő folyamatok Mindkettő a verifikációs és validációs folyamat része Az átvizsgálás a specifikációnak való megfeIelést vizsgálja, nem pedig a megrendelő igényeinek való

megfelelést Az átvizsgálással nem lehet nemfunkcionális jellemzőket vizsgálni, mint pl. teljesítmény,

használhatóság, stb. Program átvizsgálás Formálizált folyamat az átvizsgálás dokumentálására A hiányosságok, hibák megtalálására szolgál elsődlegesen (nem javításra) Lehetnek logikai hibák, a kódban található anomáliák (pl. hibás feltételt rejtenek) vagy meg nem felelés

a szervezeti és projektszabványoknak Átvizsgálás előfeltétele Precíz specifikáció kell A csapattagoknak jól kell ismerniük a szervezeti szabványokat Szintaktikusan helyes kód vagy más rendszer-reprezentáció szükséges Hibalistát kell készíteni A vezetésnek el kell fogadni a magasabb költségeket a szoftverfejlesztés kezdeti szakaszában Nem célszerű, hogy a menedzsment a fejlesztőcsapatot vizsgálja vele (pl.: ki csinálja a hibákat)

Az átvizsgálási folyamat

Átvizsgálási folyamat Áttekintést biztosítanak az átvizsgálócsapatnak a rendszerről A kódot és egyéb dokumentációkat előzetesen megkap az átvizsgálócsapat Elvégzik az átvizsgálást és a talált hibákat feljegyzik Változtatásokat tesznek a felfedezett hibák kijavítására Újraátvizsgálás vagy szükséges vagy nem Átvizsgálási szerepkörök Author or owner The programmer or designer responsible

for producing the program or document.

Responsible for fixing defects discovered

during the inspection process.

Inspector Finds errors, omissions and

inconsistencies in programs and

documents. May also identify broader

issues that are outside the scope of the

inspection team.

Reader Presents the code or document at an

inspection meeting.

Scribe Records the results of the inspection

meeting.

Chairman or

moderator

Manages the process and facilitates the

inspection. Reports process results to the

Chief moderator.

Chief moderator Responsible for inspection process

improvements, checklist updating,

standards development etc.

Átvizsgálási ellenőrzőlista A szokványos, általános hibák leellenőrzésére egy ellenőrzőlista kell, amely alapján az átvizsgálás zajlik Az ellenőrzőlista programozási nyelv függő és a valószínűsíthető, programnyelvre jellemző hibákat

tartalmazza Általában ha gyengébb a típusellenőrzés, hosszabb az ellenőrzőlista Például: Kezdőérték megadása, konstansok elnevezése, ciklusból való kilépés, tömb túlindexelés Átvizsgálási mutatók 500 utasítás/óra első átfutáskor 125 utasítás/óra egyéni előkészület során 90-125 utasítás/óra vizsgálható át a felülvizsgálati találkozó során Az átvizsgálás emiatt egy költséges folyamat 500 sor átvizsgálása kb. 40 emberóra

Automatizált statikus elemzés A statikus analizátorok szoftvereszközök a forráskód feldolgozására Elemzik a forráskódot és megpróbálják felfedezni a potenciális hibákat Nagyon hatékony segítség az átvizsgálás folyamatában Nem helyettesítik az emberi átvizsgálást Statikus elemzési lista

Fault class Static analysis check

Data faults Variables used before initialisation

Variables declared but never used

Variables assigned twice but never used

between assignments

Possible array bound violations

Undeclared variables

Control faults Unreachable code

Unconditional branches into loops

Input/output faults Variables output twice with no

intervening assignment

Interface faults Parameter type mismatches

Parameter number mismatches

Non-usage of the results of functions

Uncalled functions and procedures

Storage

management faults

Unassigned pointers

Pointer arithmetic

A statikus elemzés szakaszai A vezérlés folyamatának ellenőrzése. Ciklusok ellenőrzése több belépési és kilépési ponttal, soha le

nem futó kód megtalálása, stb. Az adathasználat elemzése. Inicializálatlan változók, többször outputra kerülő változók értékük

megváltozása nélkül, deklarált, de soha el nem használt változók, stb. Interfészelemzés. Elemzi a rutinok és eljárások deklarációjának konzisztenciáját és azok használatát Az információáramlás elemzése. A bemenő és kimenő változók közötti függőségeket ismeri fel. Hogyan

számolódik ki egy érték, milyen feltételek befolyásolják Útvonalelemzés. A szemantikus elemzés e szakasza azonosítja a program összes lehetséges végrehajtási

útvonalát. Mindegyik szakasz sok információt szolgáltat. Körültekintéssel kell értelmezni őket. A statikus elemzés használata Különösen hasznos egy gyengén típusos nyelv esetén és ezért a fordító sok hibát nem észlel. Kevéssé költséghatékony olyan nyelveknél, mint pl. a Java, melyek erősen típusosak, ezért a fordítás

során több hiba kiderül. Verifikáció és formális módszerek A formális módszerek akkor használhatók, ha a rendszer matemaikai specifikációja létrehozásra kerül. Alapvető ellenőrzési technika. Mély matematikai analízist kívánnak a specifikáció alapján. Programhelyesség bizonyítása.

Érvek a formális módszerek mellett A matematikai specifikáció a követelmények részletes analízisét kívánja, amely valószínű, hogy hibákat

fed fel. Implementációs hibákat detektálnak a tesztelés előtt,amikor a program a specifikáció alapján

analizálásra kerül. Érvek a formális módszerekkel szemben Speciális jelölésrendszere van, amelyet a program szakterületének ismerői nem értenek. Nagyon költséges a specifikációt kidolgozni és még költségesebb megmutatni, hogy a program megfelel

specifikációjának. Általában más V & V technikák használatával olcsóbban el lehet érni a hasonló helyességi szintet. Cleanroom szoftverfejlesztés A név a félvezetőgyártásból ismert 'Cleanroom‘ fogalomból származik. A filozófia a hiba elkerülése, szemben a hiba kijavításával

A szoftverfolyamat a következőkön nyugszik: Inkrementális fejlesztés; Formális specifikáció; Statikus verifikáció; Statisztikus tesztelés a program megbízhatóságának meghatározására.

The Cleanroom process

Cleanroom folyamat jellemzői Formális specifikáció állapotátmenet modell használatával. Inkrementális fejlesztés a megrendelő prioritásai alapján. Strukturált programozás – limitált vezérlési és absztrakciós szerkezetek felhasználása a programban. Statikus ellenőrzés szigorú átvizsgálással. A rendszer statisztikus tesztelése. (később lesz róla szó) A formális specifikáció és az átvizsgálás Az állapot alapú modell egy rendszer specifikáció, az átvizsgálási folyamat a programot ellenőrzi a

modellel szemben. A programozási megközelítés úgy definiált, hogy a modell és a rendszer közti kapcsolat tiszta. Matematikai érvek (nem bizonyítás) kerülnek felhasználásra a helyesség bizonyosságának növelésére

az átvizsgálási folyamatban. Cleanroom folyamat teamjei Specifikációs csapat. A rendszerspecifikáció kifejlesztéséért és karbantartásáért felelős. Fejlesztő csapat. A szoftver fejlesztéséért és ellenőrzéséért felelős. A szoftver nem kerül végrehajtásra

vagy akár még fordításra ezalatt a folyamat alatt. Átvizsgáló csapat. A statisztikus tesztek kifejlesztéséért felelős, melyekkel a fejlesztés után a szoftvert

átvizsgálják. Megbízhatóságot növelő modelleket használnak az elfogadható megbízhatósági szint meghatározásához.

Cleanroom folyamat értékelése A Cleanroom folyamat használatának eredményei szembetűnőek az elkészített rendszerekben utólag

felfedezett kevés hiba miatt. Egymástól független feladatok mutatják, hogy a folyamat nem drágább, mint más megközelítés. Kevesebb hiba, mint a „tradicionális” fejlesztési folyamatokkal. Mégis a módszer nem széles körben használt. Nem tiszta, hogy hogyan vihető át a megközelítés olyan

környezetbe, ahol kevésbé képzett és motivált szoftvertervezők vannak.

Szoftvertesztelés A fejezet célja A validációs és a hiányosságtesztelés közti különbség megismertetése A rendszertesztelés és komponenstesztelés alapelveinek áttekintése A tesztesetek létrehozásának stratégiái A tesztautomatizáláshoz használt eszközök alapvető jellemzőinek bemutatása A fejezet témái Rendszertesztelés Komponenstesztelés Tesztesetek tervezése Tesztautomatizálás A tesztelési folyamat Komponenstesztelés

Különálló programalkotórészek tesztelése Általában a komponens fejlesztőjének felelőssége A tesztek a fejlesztő gyakorlatából következnek

Rendszertesztelés Rendszerré vagy alrendszerré integrált komponensek csoportjainak tesztelése Általában független tesztelőcsoport végzi A tesztek a rendszerspecifikációból következnek

Tesztelési fázisok

Hiányosságtesztelés A hiányosságtesztelés célja a program hiányosságainak felfedése A sikeres hiányosságteszt a programot egy rendellenes módon való működésre készteti A teszt a hiba jelenlétét mutatja, nem a hiba hiányát Tesztelési folyamat céljai Validációs tesztelés

Cél, hogy megmutassa a fejlesztőnek és a megrendelőnek, hogy a szoftver megfelel a követelményeknek

A sikeres teszt megmutatja, hogy a rendszer úgy működik, ahogy „elképzelték” Hiányosságtesztelés

Cél a hibák vagy hiányosságok felfedezése a szoftverben, ahol a viselkedése helytelen vagy nem felel meg a specifikációjának

A sikeres teszt a rendszert hibás működésre készteti, így rávilágít a rendszer hiányosságaira

A szoftvertesztelési folyamat

Tesztelési irányelvek Csak a kimerítő, teljes tesztelés mutathatja meg, hogy a program hiányosságoktól, hibáktól mentes A kimerítő, teljes tesztelés lehetetlen A tesztelési irányelvek meghatározzák a megfelelő rendszertesztek kiválasztását:

Az összes, menükön keresztül elérésre kerülő funkció tesztelendő Ugyanabból a menüből elérhető funkciók kombinációja tesztelésre szorul Ahol felhasználói adatbevitel történik, ott az összes függvényt tesztelni kell helyes és helytelen

bemenetre Rendszertesztelés Vele jár a komponensek rendszerré vagy alrendszerré való összeillesztése Növekedési lépésenként való tesztelést tesz lehetővé az átadáshoz. Két fázis:

Integrációs tesztelés - a tesztelőcsoport hozzáfér a rendszer forráskódjához. A rendszert a komponensek hozzáadásával párhuzamosan, fokozatosan tesztelik

Kiadástesztelés - a tesztelőcsoport a teljes rendszer teszteli és feketedobozként kezeli Integrációs tesztelés Magában foglalja a rendszer komponenseiből történő felépítését és tesztelését a komponensek

együttműködéséből adódó problémák felderítésére Fentről lefelé történő integráció (Top-down)

A rendszer váza kerül kifejlesztésre, majd ehhez adódnak hozzá a komponensek. Lentről felfelé történő integráció (Bottom-up)

Az infrastrukturális komponensek (pl.: hálózati, adatbázis-elérés) készülnek el, majd a funkcionális komponensek kerülnek hozzáadásra.

A hiba lokalizálásának megkönnyítéséhez a rendszer integrálása és tesztelése során mindig inkrementális megközelítést kell alkalmazni

Inkrementális integrációs tesztelés

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence 1 Test sequence 2 Test sequence 3

Integráció típusainak néhány előnye Architektúra validálása

A fentről-lefelé történő integrációs tesztelés jobb, ha a rendszerarchitektúra hibáit akarjuk feltárni

Rendszer bemutatása A fentről-lefelé történő integrációs tesztelés lehetővé teszi a rendszer korlátozott bemutatását a

fejlesztés korai fázisában Teszt implementálása

Gyakran könnyebb a lentről-felfelé történő integrációs tesztelés esetében Teszt megfigyelése, kiértékelése

Mindkét megközelítésnél probléma, hogy további kódot kell kifejleszteni ahhoz, hogy lehetővé tegyük a rendszer futtatását

Kiadástesztek A kiadástesztelés az a folyamat, amelynek során a rendszervásárlóknak leszállítandó kiadás tesztelése

történik A folyamat elsődleges célja, hogy növelje a bizalmat abban, hogy a rendszer megfelel

követelményeinek A kiadástesztelés általában egy fekete doboz folyamat (funkcionális tesztelés)

A teszteket a rendszer specifikációjából származtatják A tesztelőnek nem kell foglakoznia a szoftver implementációjával

A fekete doboz teszt

Tesztelési irányelvek Tesztelési irányelvek, melyek növelik a sikeres hiányosságtesztelés valószínűségét

Válasszunk olyan bemeneteket, amelyek rákényszerítik a rendszert arra, hogy az összes hibaüzenetet legenerálja

Alkalmazzunk olyan inputokat, amelyek a bemeneti pufferek túlcsordulását eredményezik Ugyanazon inputot vagy inputsorozatot több alkalommal is ismételjük meg Kényszerítsük ki az érvénytelen outputok generálását Kényszerítsük ki azt, hogy a számítási eredmények túl kicsik vagy túl nagyok legyenek

Forgatókönyv-alapú tesztelés Egy Skóciában amerikai történelmet hallgató diák azt a feladatot kapja, hogy írjon dolgozatot „A határvidék, mint nemzetalakító tényező az amerikai Nyugaton, 1840 és 1880 között” címmel. Ehhez sok könyvtárból szüksége lesz különböző forrásokra. Belép a LYBSYS-rendszerbe, és a keresési funkció segítségével megtudja, hogy hozzáférhet-e korabeli dokumentumokhoz. Különböző amerikai egyetemi könyvtárakban megtalálja őket, közülük néhányat letölt. Egy dokumentumhoz csak akkor juthat hozzá, ha egyeteme megerősíti, hogy ő valóban diák, és nem üzleti célokra szeretné a dokumentumot használni. A LIBSYS ilyen engedélyek igénylését kezelő modulja rögzíti kérését, majd ha megkapja az engedélyt, a dokumentum letöltésre kerül a regisztrált könyvtár szerverére, majd kinyomtatják számára. A hallgató üzenetet kap a LYBSYS-től, amelyben arról tájékoztatják, hogy majd e-mailben értesítik, hogy mikor mehet a kinyomtatott dokumentumért. A rendszer tesztje

1. Helyes és helytelen bejelentkezési információkkal tesztelni kell a

bejelentkezési mechanizmust, hogy meggyőződjünk arról, hogy a rendszer

beengedi a hitelesített felhasználókat, míg a többieket nem.

2. Tesztelni kell a keresési funkciót is, hogy ellenőrizni tudjuk, hogy az ismert

adatforrásokra kiadott lekérdezések valójában találnak eredményként

dokumentumokat.

3. A megjelenítő rész tesztelésére is szükség van, ezzel azt ellenőrizzük, hogy a

dokumentumok információi megfelelően jelennek-e meg.

4. Tesztelni kell a letöltési jogosultság kérelmezési mechanizmusát.

5. A letöltött és kinyomtatott dokumentum hozzáférhetőségéről szóló e-mail

üzenetküldést is tesztelni kell.

Használati esetek A használati esetek a rendszer tesztelésének alapját képezhetik. Segítenek meghatározni a tesztelésre

szoruló műveleteket és megtervezni a kívánt teszteseteket A kapcsolódó szekvenciadiagramokkal a tesztesetekhez szükséges bemenetek és kimenetek is

meghatározhatók Időjárási adatok begyűjtésének szekvenciadiagramja

Teljesítménytesztelés Miután a rendszer integráltuk, lehetséges a rendszer eredendő tulajdonságainak a tesztelése, mint

például a teljesítmény és a megbízhatóság A teljesítményteszt általában tesztek olyan sorozatát foglalja magában, ahol a terhelés mindaddig

állandóan nő, amíg a rendszer terhelése elfogadhatatlanná nem válik Stressztesztelés Működteti a rendszert a tervezési határain túlmutató terheléssel. Olyan hiányosságok is előjöhetnek,

melyekre a normális működés közben nem derülne fény Teszteli a rendszer viselkedését szélsőséges körülmények között. A rendszer nem omolhat össze

katasztrofálisan. Nem lehet adatvesztés vagy a felhasználói szolgáltatások váratlan eltűnése Komponenstesztelés A komponenstesztelés (egységtesztelés) a rendszer önálló komponenseinek elszigetelt tesztelése A tesztelendő komponensek lehetnek:

Önálló függvények vagy objektumok esetén metódusok Több attribútumot és metódust tartalmazó objektumosztályok Különböző objektumokból és/vagy függvényekből készült összetett komponensek, amelyek

funkcionalitását interfészeken keresztül érjük el Objektumosztályok tesztelése A teljes tesztnek tartalmaznia kell

Az objektumhoz kapcsolódó összes művelet különálló tesztelését Az objektumhoz kapcsolódó összes attribútum beállítását és vizsgálatát Az objektum összes lehetséges állapotának a vizsgálatát

Az öröklés még nehezebbé teszi az objektumosztályokra vonatkozó tesztek megtervezését Meteorológiai állomás interfésze

Meteorológiai állomás tesztelése Meg kell határozni a teszteseteket a következő metódusokhoz: reportWeather, calibrate, test, startup

és shutdown Állapotmodellt használva azonosítható a tesztelendő állapotátmenetek sorozata és meghatározhatók

az ezen átmenetek eléréséhez szükséges eseménysorozatok Például:

Leállítás -> Várakozás -> Leállítás Várakozás -> Kalibrálás -> Tesztelés -> Továbbítás -> Várakozás Várakozás -> Gyűjtés -> Várakozás ->Összesítés -> Továbbítás -> Várakozás

Interfésztesztelés Célja az interfész hibáinak a kiderítése Különösen fontos az objektumorientált és komponensalapú fejlesztésben, mivel a komponensek

funkcionalitását az interfészükön keresztül érhetjük el

identifier

repor tWeather ()calibrate (instruments)test ()star tup (instruments)shutdown (instruments)

WeatherStation

Interfésztesztelés

Interfész típusok Paraméter-interfészek

Adatok továbbítódnak az egyik komponenstől a másikhoz Osztott memóriájú interfészek

Egy memóriablokk van megosztva az alrendszerek között. Az adatokat az egyik alrendszer a memóriába írja, ahonnan a másik alrendszer kiolvassa

Procedurális interfészek Az egyik alrendszer a más alrendszerek által hívható eljárások egy halmazát bezárja

Üzenettovábbító interfészek Egy alrendszer szolgáltatást kér egy másik alrendszertől úgy, hogy üzenetet továbbít hozzá. A

szolgáltatás lefuttatásával kapott eredményeket egy válaszüzenet tartalmazza Interfész hibák Interfész téves alkalmazása

Egy hívó komponens meghív egy másik komponenst és hibát követ el az interfésze használatában. Gyakori a paraméter-interfészeknél. Pl.: paraméterek rossz típusúak, rossz sorrendűek vagy nem megfelelő számú paraméter lett átadva

Interfész félreértelmezése A hívó komponens félreértelmezi a hívott komponens interfész-specifikációját, így von le

következtetéseket a hívott komponens viselkedésmódjáról. Pl.: bináris keresést végző rutin meghívása rendezetlen tömbbel

Időzítési hibák A hívott és a hívó komponens különböző sebességgel működik és nem időszerű információ kerül

át Interfésztesztelési irányelvek A tesztek egy részét úgy kell összeállítani, hogy a külső komponensek paramétereinek az értékei a

tartományuk legtávolabbi végére essenek Mindig teszteljünk null értékű paraméterekkel Olyan tesztek kellenek, melyek esetleg a komponens hibázását okozzák Stressztesztelés kell üzenettovábbító rendszereknél (időzítési problémák kiderítése) Osztott memóriát használó rendszerekben teszteljük a komponensek aktiválódási sorrendjét

Tesztesettervezés A rendszer tesztelésére szolgáló tesztesetek (bemenetek és előre jelzett kimenetek) tervezése A folyamat célja a program hiányosságainak felderítésére alkalmas tesztesetek kialakítása Tesztelési típusok a tervezés szempontjából:

Követelményalapú tesztelés Partíciós tesztelés Strukturális tesztelés

Követelményalapú tesztelés A követelménytervezés egyik fő alapelve, hogy a követelményeknek tesztelhetőeknek kell lenniük A követelményalapú tesztelés olyan szisztematikus tesztesettervezést jelent, amikor az egyes

követelményekből tesztsorozatokat származtat Partíciós tesztelés A bemeneti adatok általában különböző osztályokba esnek, ahol az osztály tagjai valamilyen közös

jellegzetességgel bírnak Ezeket az osztályokat az azonos viselkedés miatt ekvivalenciaosztályoknak nevezik Minden osztályból kell tesztesetet kiválasztani Ekvivalenciaosztályozás

Keresőrutin - input partíciók Bemenetek, amelyek megfelelnek az előfeltételnek Bemenetek, amelyek nem felelnek meg az előfeltételnek Bemenetek, ahol a kulcselem a sorozat tagja Bemenetek, ahol a kulcselem nem tagja a sorozatnak Tesztelési irányelvek (sorozatok) Tesztelés egyelemű sorozattal Használjunk különböző méretű sorozatokat a különböző tesztek során Készítsünk olyan teszteket is, amelyeknél a sorozat első, középső és utolsó elemét kell kiválasztani Tesztelés nulla hosszúságú sorozattal Struktúrateszt Fehér doboz tesztelésnek is hívják A tesztesetek a program szerkezetének ismeretében kerülnek létrehozásra A cél az összes programutasítás végrehajtása (nem az összes kombináció)

Struktúrateszt

Útvonaltesztelés Az útvonaltesztelés célja, hogy minden független végrehajtási útvonal kipróbálásra kerüljön legalább

egyszer. Az útvonaltesztelés kezdő pontja egy programfolyamat-gráf. Csomópontokból áll, melyek döntéseket

reprezentálnak, az élek mutatják a vezérlés irányát. A feltételes utasítások ágai különálló útként jelennek meg a gráfban, a ciklusokat a ciklusfeltételt

reprezentáló csomópontba visszamutató nyíl jelöli. Példa: Bináris keresés ekvivalenciaosztályának specifikációja:

l Előfeltétel teljesül, a kulcselem a tömbben l Előfeltétel teljesül, a kulcselem nincs a tömbben l Előfeltétel nem teljesül, a kulcselem a tömbben l Előfeltétel nem teljesül, a kulcselem nincs a tömbben l A tömb egy értékből áll l A tömb páros elemű • A tömb páratlan elemű

Ez alapján a bináris keresés folyamatgráfja:

Független utak 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, … 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, … A teszteseteket úgy kell létrehozni, hogy mindegyik út végrehajtásra kerüljön Dinamikus programelemző használható a program futási profiljának felderítésére Tesztautomatizálás A tesztelés a szoftverfolyamat drága és fáradságos szakasza. A tesztelőszoftverek számos eszközt

nyújtanak a tesztelési folyamat költségének és idejének csökkentésére. Tesztelési keretrendszerek (pl.: JUnit, osztályok halmaza), melyet a felhasználó kibővíthet annak

érdekében, hogy létrehozzon egy automatizált tesztkörnyezetet. Sok tesztkörnyezet nyílt rendszer, mert a tesztelési igények szervezet függőek. Nagy rendszereknél éri meg. Tesztelési eszközrendszer

Tesztelési eszközök adaptálása A felhasználói interfész szimulálásához szükség lehet szkriptek írására és mintákat lehet definiálni

tesztadat-generátorok számára. A várt teszteredmények egy csoportját nekünk kell előkészíteni, ha nincs korábbi programverzió, amely

előrejelzőként működne. Lehet, hogy speciális rendeltetésű állomány-összehasonlítókat kell írnunk.