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 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 moderator Chief moderator

or Manages the process and facilitates the inspection. Reports process results to the 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 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

with

no

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 A T1

A T1

T2

A

T2 T2

B T3

B T3

B

C

T3

T4 C

T4 D

Testsequence 1

T1

Testsequence 2

Testsequence 3

T5

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

WeatherStation identifier repor tWeather () calibrate (instruments) test () star tup (instruments) shutdown (instruments) 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

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.