Szofttech 101-137

Jellemezze az egység (unit) tesztet!

Az egységtesztelés az egyes komponensek elszigetelt tesztelésének folyamata.

Ez egy hibatesztelési folyamat.

Az egységek lehetnek:

• Egy objektumon belüli egyes funkciók vagy módszerek

• Több attribútummal és metódussal rendelkező objektumosztályok

• Összetett komponensek meghatározott interfészekkel, amelyeket a funkcionalitásuk eléréséhez használnak.

Mit jelent az automatizált tesztelés?

Ahol csak lehetséges, az egységtesztelést (unit test) automatizálni kell, hogy a tesztek kézi beavatkozás nélkül fussanak és ellenőrizhetők legyenek.

Az automatizált egységtesztelés során a programtesztek megírásához és futtatásához egy tesztautomatizálási keretrendszert (például a JUnit-et) használ.

A keretrendszerek általános tesztosztályokat biztosítanak, amelyeket kiterjesztve egyedi tesztesetek hozhatók létre. Ezután képesek lefuttatni az összes implementált tesztet, és - gyakran valamilyen grafikus felületen keresztül - jelentést készíteni a tesztek sikerességéről.

Milyen tesztelési stratégiákat ismer?

• Partíciós tesztelés, ahol a bemenetek olyan csoportjait azonosítja, amelyek közös jellemzőkkel rendelkeznek, és amelyeket azonos módon kell feldolgozni.
  ○       Mindegyik csoportból érdemes teszteket választani.

• Irányelv-alapú tesztelés, ahol a tesztelési irányelvek alapján választja ki a teszteseteket.
  ○       Ezek az iránymutatások a korábbi tapasztalatokat tükrözik, hogy a programozók ilyen hibákat követnek el gyakran a komponensek fejlesztése során.

Mit jelent a partíciós tesztelés? Hogyan határozzák meg a partíciókat?

●       Partíciós tesztelés, ahol a bemenetek olyan csoportjait azonosítja, amelyek közös jellemzőkkel rendelkeznek, és amelyeket azonos módon kell feldolgozni.

○       Mindegyik csoportból érdemes teszteket választani.

Mit jelent az irányelv alapú tesztelés? Írjon le 2 irányelvet.

• Irányelv-alapú tesztelés, ahol a tesztelési irányelvek alapján választja ki a teszteseteket.    

• Ezek az iránymutatások a korábbi tapasztalatokat tükrözik, hogy a programozók milyen hibákat követnek el gyakran a komponensek fejlesztése során.

Jellemezze a komponens tesztelést!

• A szoftverkomponensek gyakran összetett komponensek, amelyek több, egymással kölcsönhatásban álló objektumból állnak.
  ○ Például az időjárás-állomás rendszerben az újrakonfigurációs komponens olyan objektumokat tartalmaz, amelyek az újrakonfiguráció minden egyes aspektusával foglalkoznak.

• Ezeknek az objektumoknak a funkcionalitását a meghatározott komponensinterfészen keresztül lehet elérni.

• Az összetett komponensek tesztelésének ezért arra kell összpontosítania, hogy megmutassa, hogy a komponens interfésze a specifikációjának megfelelően viselkedik.
  ○Feltételezhető, hogy a komponens egyes objektumainak egységtesztjei elkészültek.

Mit jelent az interfészek tesztelése? Milyen interfész típusokat ismer?

A cél az interfészhibákból vagy az interfészekre vonatkozó érvénytelen feltételezésekből eredő hibák felderítése.

Interfész típusok:

• Paraméter-interfészek: Az egyik metódusból vagy eljárásból a másikba átadott adatok.

• Megosztott memória interfészek: A memóriablokkot megosztják az eljárások vagy függvények között.

• Eljárási interfészek: Az alrendszer más alrendszerek által hívható eljárások halmazát foglalja magába.

• Üzenetátviteli interfészek: Az alrendszerek szolgáltatásokat kérnek más alrendszerektől.

Milyen interfész hibák lehetségesek?

• Az interfész helytelen használata

• Interfész félreértése

• Időzítési hibák

Jellemezze a rendszertesztelést!

A rendszer tesztelése során a külön fejlesztett, újrafelhasználható komponensek és a megvásárolható rendszerek integrálhatók az újonnan kifejlesztett komponensekkel. Ezt követően a teljes rendszert tesztelik.

Ismertessen néhány alapelvet rendszertesztelésre vonatkozóan!

A fejlesztés során a rendszer tesztelése magában foglalja az összetevők integrálását a rendszer egy verziójának létrehozásához, majd az integrált rendszer tesztelését.

A rendszertesztelés során a komponensek közötti kölcsönhatások tesztelése áll a középpontban.

A rendszer tesztelése azt ellenőrzi, hogy az összetevők kompatibilisek-e, megfelelően működnek-e együtt, és a megfelelő adatokat a megfelelő időben továbbítják-e a kapcsolódási pontjaikon keresztül.

A rendszertesztelés a teljes rendszer viselkedését vizsgálja.

Mit jelent és mi az alapja a tesztvezérelt fejlesztésnek?

A tesztvezérelt fejlesztés (TDD - Test-driven development) a programfejlesztés olyan megközelítése, amelyben a tesztelést és a kódfejlesztést összekapcsoljuk.

A teszteket a kód előtt írják, és a tesztek “sikeressége" a fejlesztés kritikus mozgatórugója.

A kódot inkrementálisan fejleszti, az adott inkrementumhoz tartozó tesztekkel együtt. Addig nem lépnek tovább a következő lépcsőfokra, amíg a kifejlesztett kód át nem megy a tesztelésen.

A TDD-t az olyan agilis módszerek részeként vezették be, mint az Extrém Programozás. Azonban tervvezérelt fejlesztési folyamatokban is alkalmazható.

Mi a TDD?

A tesztvezérelt fejlesztés (TDD - Test-driven development) a programfejlesztés olyan megközelítése, amelyben a tesztelést és a kódfejlesztést összekapcsoljuk.

Mutassa be a tesztvezérelt fejlesztés folyamatának lépéseit!

• Kezdje a szükséges funkcionalitás meghatározásával. Ennek általában kicsinek és néhány sornyi kóddal megvalósíthatónak kell lennie.

• Írjon tesztet erre a funkcióra, és valósítsa meg automatizált tesztként.

• Futtassa a tesztet az összes többi végrehajtott teszttel együtt. Kezdetben nem implementálta a funkciót, így az új teszt sikertelen lesz.

• Implementálja a funkciót, és futtassa le újra a tesztet.

• Ha minden teszt sikeresen lefutott, továbbléphet a következő funkcionalitás megvalósításához.

Mi a regressziós tesztelés?

A regressziós tesztelés a rendszer tesztelése annak ellenőrzésére, hogy a változtatások nem “rontották-e el" a korábban működő kódot.

A manuális tesztelési folyamat esetén a regressziós tesztelés költséges, de az automatizált teszteléssel egyszerű és egyértelmű. Minden tesztet újra lefuttatunk minden alkalommal, amikor a programban változás történik.

A teszteknek "sikeresen" kell lefutniuk, mielőtt a változtatás rögzítésre kerül.

Jellemezze a release tesztet!

A release tesztelés a rendszer egy adott kiadásának tesztelése, amelyet a fejlesztőcsapaton kívüli használatra szánnak.

A release tesztelési folyamat elsődleges célja, hogy meggyőzze a rendszer szállítóját arról, hogy a rendszer elég jó a használathoz.
A release tesztelésnek tehát azt kell bizonyítania, hogy a rendszer biztosítja a meghatározott funkcionalitást, teljesítményt és megbízhatóságot, és hogy normál használat során nem hibásodik meg.

A release tesztelés általában egy fekete dobozos tesztelési folyamat, ahol a tesztek csak a rendszerspecifikációból származnak.

Mi a teljesítménytesztelés? Melyik rendszertesztelési folyamatnak lehet a része?

A release tesztelés része lehet a rendszer olyan megjelenő tulajdonságainak tesztelése, mint például a teljesítmény és a megbízhatóság.

A teszteknek tükrözniük kell a rendszer használati profilját.

A teljesítménytesztek általában egy olyan tesztsorozat megtervezését foglalják magukban, amelyben a terhelést folyamatosan növelik, amíg a rendszer teljesítménye elfogadhatatlanná nem válik.

A stressztesztelés a teljesítménytesztelés egy formája, amikor a rendszert szándékosan túlterhelik, hogy teszteljék a hibás viselkedését.

Jellemezze a felhasználói tesztelést!

A felhasználói vagy ügyféltesztelés a tesztelési folyamat egy olyan szakasza, amelyben a felhasználók vagy az ügyfelek tanácsot adnak a rendszer teszteléséhez.

A felhasználói tesztelés elengedhetetlen, még akkor is, ha már elvégezték az átfogó rendszer- és átadási tesztelést.

Ennek oka, hogy a felhasználó munkakörnyezetéből származó hatások nagyban befolyásolják a rendszer megbízhatóságát, teljesítményét, használhatóságát és robusztusságát. Ezek nem reprodukálhatók tesztelési környezetben.

Mutassa be a felhasználói tesztelés 3 típusát!

• Alfa tesztelés: A szoftver felhasználói a fejlesztőcsapattal együttműködve tesztelik a szoftvert a fejlesztő telephelyén.

• Béta tesztelés: A szoftver egy kiadását a felhasználók rendelkezésére bocsátják, hogy kísérletezhessenek, és az általuk felfedezett problémákat felvethessék a rendszer fejlesztőinek.

• Átvételi tesztelés: Az ügyfelek tesztelik a rendszert, hogy eldöntsék, készen áll-e arra, hogy a rendszerfejlesztőktől átvegyék és az ügyfélkörnyezetben telepítsék. Elsősorban egyedi rendszerek esetében.

Milyen események vezethetnek a meglévő szoftverek megváltoztatásához? Soroljon fel 4-et.

A szoftverek változása elkerülhetetlen:

• A szoftver használatakor új követelmények merülnek fel;

• Az üzleti környezet változik;

• A hibákat ki kell javítani;

• A rendszer új számítógépekkel és berendezésekkel egészül ki;

• Előfordulhat, hogy a rendszer teljesítményét vagy megbízhatóságát javítani kell.

Mi az evolúció?

Egy szoftverrendszer életciklusának az a szakasza, amikor a rendszer üzemszerű használatban van, és fejlődik, mivel új követelményeket javasolnak és implementálnak a rendszerbe.

Mi a karbantartás?

Ebben a szakaszban a szoftver továbbra is használható marad, de csak a működés fenntartásához szükséges változtatásokat hajtják végre, azaz a hibajavításokat és a szoftver környezetében bekövetkezett változásokat tükröző változtatásokat. Új funkciókat nem adnak hozzá.

Ismertesse a szoftverfejlődési (evolúciós) folyamat lépéseit!

A szoftverfejlődési folyamatok a következőktől függenek

• A karbantartott szoftver típusa;

• Az alkalmazott fejlesztési folyamatok;

• Az érintettek képességei és tapasztalata.

A változtatási javaslatok a rendszer fejlődésének mozgatórugói.

• Össze kell kapcsolni a változás által érintett összetevőkkel, lehetővé téve ezáltal a változás költségének és hatásának becslését.

A változások azonosítása és fejlesztése a rendszer teljes élettartama alatt folytatódik.

Lépések:
-Igényfelmérés és tervezés
-Rendszertervezés
-Implementáció és fejlesztés
-Tesztelés és validáció
-Üzemeltetés
-Karbantartás

Miket nevezünk ős (legacy) rendszereknek?

Az ős rendszerek olyan régebbi rendszerek, amelyek olyan nyelvekre és technológiákra támaszkodnak, amelyeket már nem használnak az új rendszerek fejlesztéséhez.

Az ős szoftverek régebbi hardvertől, például nagyszámítógépektől függhetnek, és ehhez kapcsolódóan régebbi folyamatok és eljárások is létezhetnek.

Az ős rendszerek nem csupán szoftverrendszerek, hanem szélesebb körű társadalmi-technikai rendszerek, amelyek magukban foglalják a hardvert, a szoftvereket, a könyvtárakat és más támogató szoftvereket és üzleti folyamatokat.

Sorolja fel a legacy rendszer 6 elemét!

- Hardware – gyakran elavult mainframe hardver
- Support software – gyakran a szolgáltatók már nem léteznek
- Application software – Gyakran elavult programnyelveken íródtak
- Application data – Gyakran hiányos és inkonzisztens
- Business processes – A szoftver struktúrája és funkcionalitása korlátozhatja
- Business policies and rules – A szoftverbe implicit módon beépülhet

Miért költséges az ős rendszerek változtatása? Írjon 4 lehetőséget.

-Komplexitás és nehezen karbantartható struktúra

-Kompatibilitási problémák

-Adatmigráció és adatintegritás

-Részleges vagy teljes átállás költségei

Írja le a szoftver karbantartás 3 típusát!

• Adaptív karbantartás

• Preventív karbantartás

• Hibajavítás

Mivel foglalkozik a szoftverprojekt-menedzsment?

A szoftver időben és pontosan történő leszállítása:

• Az ütemtervnek megfelelően

• A fejlesztő szervezetek követelményeinek megfelelően

• A szoftvert beszerző szervezetek követelményeinek megfelelően.

Mikor nevezhető egy szoftverprojekt sikeresnek?

• A szoftver átadása az ügyfélnek a megbeszélt időpontban.

• Összköltségek a költségvetési kereteken belül.

• Az ügyfél elvárásainak megfelelő szoftver szállítása.

• Koherens és jól működő fejlesztői csapat fenntartása.

Miért különbözik egy szoftverprojekt más projektektől?

• A termék megfoghatatlan.

• Sok szoftverprojekt "egyszeri" projekt.

• A szoftverfolyamatok változóak és szervezetspecifikusak.

Milyen feladati vannak egy szoftverprojekt menedzsernek? Soroljon fel legalább 4-et!

• Projekttervezés

• Kockázatkezelés

• Emberek menedzselése

• Jelentés

• Javaslatleírás

Mi a kockázatkezelés, miért fontos és mi a szerepe a projektmenedzsernek a kockázatok kezelésében?

A kockázatkezelés a kockázatok azonosításával és a projektre gyakorolt hatásuk minimalizálására irányuló tervek kidolgozásával foglalkozik.

A szoftverkockázatkezelés a szoftverfejlesztésben rejlő bizonytalanságok miatt fontos.

A projektmenedzsernek előre kell látnia a kockázatokat, meg kell értenie, hogy ezek a kockázatok milyen hatással vannak a projektre, a termékre és az üzletre, és lépéseket kell tennie a kockázatok elkerülése érdekében.

Írja le a kockázatkezelési folyamat 4 lépését!

• Kockázat azonosítása

• Kockázatelemzés

• Kockázattervezés

• Kockázatfigyelés

Mi a kockázatelemzés? Milyen jellemzői vannak egy kockázatnak?

Az egyes kockázatok valószínűségének és súlyosságának elemzése.

A valószínűség lehet nagyon alacsony, alacsony, közepes, magas vagy nagyon magas.

A kockázati következmények lehetnek katasztrofálisak, súlyosak, elviselhetőek vagy jelentéktelenek.

Mit jelent a kockázat azonosítása? Nevezzen meg 2 db kockázattípust!

Az egyes kockázatok valószínűségének és súlyosságának elemzése.

Példa:

• A hibajavítási arányt alábecsülik.

• A szoftver méretét alábecsülik.

Milyen kockázatkezelési stratégiák kerülnek kidolgozásra a kockázattervezés során? Mutassa be őket!

• Szervezet pénzügyi problémái: A vezetőség számára egy jelentés írása arról, hogy a projekt milyen fontos az üzleti célok sikeres végrehajtása érdekében.

• Munkaerő toborzási gondok: A megrendelő értesítése a potenciális nehézségekről és késés lehetőségéről.

• Komponens-vásárlás lehetőségének felmérése.

• Munkaerő megbetegedése: A csoportok átszervezése oly módon, hogy nagyobb átfedés legyen a csoportok elvégzendő munkájában. Így könnyebb más munkájának megértése.

• Hibás komponensek: A valószínűleg hibás komponensek kiváltása vásárolt, ismert minőségű komponensekkel.

Miért fontos a projekten dolgozó emberek motiválása?

• A menedzser fontos szerepe, hogy motiválja a projektben dolgozó embereket.

• A motiváció a munka és a munkakörnyezet olyan megszervezését jelenti, amely az embereket hatékony munkavégzésre ösztönzi.

• Ha az emberek nem motiváltak, nem fogják érdekelni őket a munka, amit végeznek. Lassan fognak dolgozni, nagyobb valószínűséggel fognak hibázni, és nem fognak hozzájárulni a csapat vagy a szervezet tágabb céljaihoz.

Milyen elemeken múlik egy projektcsapat hatékonysága?

• Megfelelő ütemterv

• A munka megfelelő felosztása

• Helyes kockázatelemzés

• Megfelelő hardver-, szoftver- és eszközigények

• Műszaki és vezetői kommunikáció