Tudd Intuíció, előadás, integrációs tesztelés
Abstract: Az előadás második három szint figyelembe véve az ellenőrzési folyamatot. A téma az előadás - a folyamat integrációs tesztelés, a célokat és feladatokat. Úgy véljük, a szervezeti szempontból integrációs tesztelés - a strukturális és ideiglenes besorolás integrációs tesztelési módszereket tervez integrációs tesztelés. E előadás az, hogy egy ötlet a folyamat integrációs tesztelés, műszaki és szervezési alkatrészek
20.1. Célok és integrációs tesztelés
Az eredmény tesztelése és hitelesítése az egyes modulok teszik ki a szoftver rendszert kell megállapítani, hogy ezek a modulok összhangban vannak és megfelelnek a követelményeknek. Ugyanakkor az egyes modulok ritkán működnek a saját, tehát a következő feladat a tesztelés után az egyes modulok - teszteli a helyességét a kölcsönhatás több modul együttes egy egységet alkot. Egy ilyen teszt neve integráció. Az ő célja -, hogy biztosítsák a helyességét a közös rendszer működését alkatrészeket.
Integrációs tesztelés is nevezik a vizsgálati rendszer architektúra. Egyrészt, ez a név annak a ténynek köszönhető, hogy az integrációs tesztek is vizsgálják az összes lehetséges közötti kölcsönhatás szoftver modulokat és elemeket, amelyek a rendszerben meghatározott építészeti - így integrációs tesztek teljességének igazolására a kölcsönhatások a vizsgálati rendszer végrehajtását. Másrészt, az eredmények az integrációs tesztek - az egyik fő információforrások folyamat javítások és finomítások a rendszer architektúra, modulok közötti interfészek és összeköttetéseket. Ie Ebből a szempontból, integrációs tesztek helyességének ellenőrzését a kölcsönhatás a rendszerelemeket.
Egy példa a validációs kölcsönhatás sem szolgálhat két modult, amelyek közül az egyik tárolja az üzeneteket a protokoll által elfogadott fájlokat, és a második megjeleníti a protokoll a képernyőn. A funkcionális követelmények a rendszer azt mondja, hogy az üzenetek jelenjenek meg fordított időrendi sorrendben. Ugyanakkor az üzenet tároló egység tárolja őket közvetlen módon, és kimeneti modul használ egy köteg megjelenítendő fordított sorrendben. Unit tesztek érintő minden modul külön-külön, nem ad semmilyen hatása van - teljesen valós fordított a helyzet, amelyben az üzeneteket tárolja a fordított sorrendben, és megjeleníti a sorban. Felismerni a potenciális problémát csak akkor lehet ellenőrizni segítségével kölcsönhatás modulok integrációs tesztek. A lényeg itt az, hogy fordított időrendi sorrendben jeleníti meg az üzenetet a rendszer egészének, azaz a ellenőrzése kimeneti modul, és megállapította, hogy üzeneteket jelenít hogy a közvetlen, nem tudjuk garantálni, hogy az általunk felfedezett hiba.
Ennek eredményeként az integráció tesztelés és megszünteti az összes azonosított hibák kiderül koherens és integrált szoftver rendszer felépítése, azaz a feltételezhetjük, hogy az integrációs tesztelés - a tesztelési architektúra és az alacsony szintű funkcionális követelményeknek.
Integrációs tesztelés. általában egy iteratív folyamat, amelynek során egy ellenőrző funkció egyre növekvő méretű aggregátum modulokat.
20.2. Szervezése integrációs tesztelés
20.2.1. Szerkezeti osztályozás az integráció vizsgálati módszerek
Jellemzően integrációs tesztelés került sor végén egy egység teszt minden integrált modulokat. Azonban ez nem mindig van így. Számos módszer létezik az integráció vizsgálata:
- Könyv tesztelése;
- monolit tesztelése;
- Csökkenő tesztelés.
Mindezen technikák ismerete alapján a rendszer felépítése, amelyet gyakran ábrázolják, folyamatábrák és diagramok funkció hívásokat. [10] Minden csomópont Ezen az ábrán egy olyan szoftver modul, és a nyilak között képviseli a függőség hívások modulok között. A fő különbség a módszerek integrációs tesztelés célja, hogy a mozgás irányát ezen ábrák és széltében egy iteráció.
Könyv vizsgálatok. Ha ezt a módszer feltételezi, hogy az első teszt a szoftver modulok teszik ki a rendszert, és csak ezután azok együttes integrációs tesztelés. Ezzel a megközelítéssel jelentősen leegyszerűsíti a lokalizáció hiba: ha a modulok egyenként vizsgáljuk, a hiba a közös munka a probléma a felület. Ezzel a megközelítéssel a keresési problémák a teszter keskeny, és ezért sokkal valószínűbb, hogy azonosítsa a hiba helyesen.
Ábra. 20.1. Fejlesztés a járművezetők és csonkok a korszerű integrációs tesztelés
Azonban a növekvő vizsgálati módszer jelentős hátránya - annak szükségességét, hogy a járművezetők és csonkok egység tesztelése előtt integrációs tesztelése és annak szükségességét, hogy a járművezetők és csonkok az integrációs tesztelés a modulok a rendszer (20.1 ábra)
Egyrészt a járművezetők és a csonkokat - egy erőteljes tesztelő eszköz, a másik - a fejlődésük jelentős erőforrásokat igényel, különösen akkor, ha összetételének megváltoztatásával integrált modulok, más szóval, akkor szükség lehet egy meghajtó készlet egység tesztelése minden modul, külön driver és dugó, hogy teszteljék az integráció két modul egy sor külön -, hogy teszteljék az integráció a három modul, stb Ez elsősorban annak a ténynek köszönhető, hogy az integráció a modulok nem kell valamilyen dugók, és meg akarja változtatni a driver, amely támogatja az új kísérletekre több modulból áll.
Előregyártott beton vizsgálata arra utal, hogy az egyes komponenseket a súlyos próba a rendszer nem felelt meg. A fő előnye ennek a módszernek - nincs szükség, hogy dolgozzon ki egy teszt környezet, a járművezetők és csonkokat. Miután a fejlesztés az összes modul fut integrációját, akkor az egész rendszer tesztelt egészére. Ez a megközelítés nem keverendő össze a rendszer tesztelése, amelyre a következő előadás. Annak ellenére, hogy a monolit teszt Ellenőrizze a működését az egész rendszer, a fő cél a teszt - azonosítani a problémákat, az interakció az egyes modulok a rendszer. A tárgy a rendszer teszt célja a minőségi és mennyiségi értékeléséhez rendszer jellemzőinek szempontjából elfogadhatósága a végfelhasználó.
A szilárd vizsgált számos súlyos hiányosságot.
- Nagyon nehéz meghatározni a hiba forrását (téves azonosítást kódrészletet). A legtöbb modul kell vállalnia a létezését hibákat. A probléma csapódik le, hogy a meghatározása, hogy milyen hibát összes modult érintett vezetett eredményre. Lehetőség van overlay hiba hatásokat. Ezen túlmenően, egy hiba egy modulban elzárhatják másik teszt.
- Nehéz megszervezni a hibák kijavítását. A tesztelés tesztelő talált a probléma megoldódott. A hiba a rendszerben, hogy a problémát okozó, a fejlesztő fogja rögzíteni. Mivel, mint általában, a vizsgálati modulok által írt különböző emberek, van egy probléma - egyikük felelős megszüntetésére törekszik a hiba? Egy ilyen „kollektív felelőtlenség” eliminációs ráta a hibák zuhannak.
- A tesztelési folyamat automatizált rossz. Az előny (semmilyen további szoftver, amely végigkíséri a tesztelési folyamat) alakul hátrány. A változások megkövetelik minden ismétlése minden tesztben.
Lefelé vizsgálat azt sugallja, hogy az integrációs tesztelési folyamat mozgatja, hogy kövesse a fejlődést. Első teszt csak a legfelső szintű rendszer, nem az alacsonyabb szintű modulokat. Ezután fokozatosan egy magasabb szintű modul integrálva alacsony szinten. Ennek eredményeként ez az eljárás szükségtelenné teszi a vezető (a vezető végzi a szerepét a magas szintű rendszer modul), de még mindig szükség dugók (ábra 20.2).
nagyobb kép
Ábra. 20.2. A fokozatos integrációját a modulok egy vizsgálati módszerek megállapításáról
A szakirodalom gyakran említi a módszer integrációs tesztelés az objektum-orientált szoftver rendszer, amelynek alapja a kiválasztott osztályok klaszterek amelynek van egy zárt együtt, és teljes funkcionalitást [10]. Lényegét tekintve ez a megközelítés nem új típusú integrációs tesztelés, csak a változó a minimális elem eredő integráció. Amikor integráló modulok procedurális nyelvek lehet építeni bármilyen modulok száma alá a fejlesztés a dugók. Ha integrált osztályok klaszterek van elég puha határt teljességének cluster funkciót. Azonban még abban az esetben az objektum-orientált rendszerek integrálása bármely osztályok száma a class csonk.
Függetlenül attól, hogy az alkalmazott módszer, integrációs teszt, azt kell figyelembe venni a lefedettség integrációs teszt rendszer funkcióit. [17] javasolt módszer értékelésére lefedettségi fokának alapján a hívás közötti ellenőrzési funkciók és adatfolyamok. Ebben az értékelési kód az összes modul a blokk diagram a rendszert kell elvégezni (a hatálya alá tartozó összes csomópont), az összes hívás kell végezni legalább egyszer (fedeznie kell az összes kommunikációt a strukturális diagram csomópontok), az összes hívás szekvenciák is végre lehet hajtani egy alkalommal (egészen a strukturális diagramja kell fedezni). [10]