Vizsgálati módszerek szoftverek és hasonlítsa össze őket. Vizsgálati módszer a „fekete doboz” tesztelés és a módszer „fehér doboz”

Tesztelés szoftver (SW) és a hiányosságok feltárása, a hiányosságok és hibák a kódot kell foglalkozni. Úgy is meg lehet határozni, mint a folyamat funkcionalitás és becslés helyességét szoftver segítségével elemzést. Alapvető módszerek integrációját és tesztelését szoftveralkalmazások és a minőség biztosítása, hogy teszteljék a specifikáció, tervezés, kódolás, a megbízhatóság értékelési, érvényesítési és ellenőrzést.

mód

A fő cél a szoftver tesztelés - megerősítése a minőségi szoftver rendszer szisztematikus hibakeresés alkalmazások gondosan ellenőrzött körülmények között, hogy meghatározzák a teljesség és a pontosság, valamint az észlelési rejtett hibákat.

Az igazolási módszerek (teszt) programokat lehet osztani a statikus és dinamikus.

Az előbbiek közé informális, ellenőrzés és műszaki felülvizsgálat, ellenőrzés, lépésről lépésre elemzés, ellenőrzés, valamint a statikus adatfolyam elemzése és kezelése.

Dinamikus technikák:

1. Fehér doboz tesztelés. Ez egy részletes tanulmányt a belső logikája és szerkezete a programot. Szükséges ismeretek a forráskódot.
2. Fekete doboz tesztelés. Ez a technika nem igényel ismereteket a belső működését az alkalmazást. Úgy véljük, csak az alapvető szempontból a rendszer, nem kapcsolódik vagy társult néhány belső logikai szerkezetét.
3. Szürke doboz módszer. Ez két korábbi megközelítéseket. Hibakeresés korlátozott ismeretekkel a belső működésének a kérelem kombináljuk ismerete alapvető szempontból a rendszer.

átlátható vizsgálat

A fehér doboz módszer teszt scriptek ellenőrzési struktúrát az eljárási design. Ez a technika lehetővé teszi, hogy felfedje végrehajtás hibák, mint például a rossz vezetés kódrendszer elemzésével egy része a belső működését a szoftver. E vizsgálati módszerek alkalmazhatók az integráció, a modul és rendszer szinten. A teszter hozzáféréssel kell rendelkeznie a forráskódot, és használja azt, hogy megtudja, melyik egység viselkedik rosszul.

Tesztelés programok fehér doboz a következő előnyökkel jár:

• Ez lehetővé teszi, hogy hibát észlel, a rejtett kódot törölni a felesleges vonalak;
• a használata mellékhatások;
• maximális hatótávolság érhető el írásával teszt script.

hátrányai:

• magas költségű folyamat, amely képzett hibakereső;
• sok utat maradt kihasználatlanul, mert alapos ellenőrzést minden lehetséges rejtett hiba nagyon bonyolult;
• néhány kód lesz észrevétlen maradt.

Fehér doboz tesztelés is nevezik vizsgálatával átlátszó vagy nyitott doboz, szerkezeti, logikai vizsgálat alapján a forráskódot, és logikai architektúra.

A fő fajták:

1) teszteljük a flow control - strukturális stratégia segítségével a program ellenőrzési flow modellt és előnyben egyszerűbb módja, hogy kevesebb bonyolultabb;

2) Az ág vizsgálatára tervezték hibakeresés egyes lehetőségek (igaz vagy hamis) az egyes operátor, amely szintén tartalmaz egy egyesített oldatot;

3) tesztelése a fő út, amely lehetővé teszi, hogy a tesztelő létrehozni logikai összetettsége intézkedés eljárási projekt izolálására alapkészlet végrehajtási utakat;

4) ellenőrzi, hogy az adatfolyam - az áramlás ellenőrzési stratégia kutatás szerint a kommentárok száma információt ad, és használja a program változók

5) ciklusban tesztelés - a teljes mértékben odafigyelt helyes működését ciklikus folyamatokat.

viselkedési hibakeresés

Fekete doboz tesztelés kezeli a szoftver, mint egy „fekete doboz” - információkat a belső működését a program nem számítanak, és ellenőrizni csak az alapvető szempontból a rendszer. Ebben az esetben a tesztelő tudnia kell a rendszer felépítésének való hozzáférés nélkül a forráskódot.

Előnye ennek a megközelítésnek:

• hatékonyság a nagy kódszegmenshez;
• megkönnyítik az érzékelés teszter;
• felhasználó szempontjából világosan elkülönül a fejlesztő perspektívák (programozó és tesztelő függetlenek egymástól);
• gyorsabb létrehozását teszt.

Tesztprogramok fekete doboz módszer hátrányai a következők:

• Valóban végre egy kiválasztott számú teszt, ami a korlátozott fedezetet;
• hiányzik az egyértelmű leírás nehéz fejleszteni teszt scriptek;
• alacsony hatékonyságát.

Egyéb nevek ezt a technológiát - viselkedésbeli, nem átlátható, funkcionális tesztelés és hibakeresés eljárás zárt dobozban.

Ez a kategória magában a következő szoftverek tesztelési technikák:

1) egyenértékű partíció, ami csökkentheti a beállított vizsgálati adatok beviteli szoftver modul adatok bontani különálló részből;

2) határérték elemzés középpontjában az ellenőrzési határok vagy szélsőséges határértékeket - a minimális, maximális és jellemző értékek hiba;

3) fuzzing - végrehajtásához alkalmazott keresési megadásával hibák vagy hibás adatokat poluiskazhennyh automata vagy félautomata üzemmódban;

4) rendbeli okság - alapuló technikát létrehozására grafikonok és meghatározzuk a kapcsolat a cselekvés és annak okairól: identitás, tagadás, logikai VAGY és logikai ÉS - a négy fő karakter, viszonyt kifejező ok és okozat között;

5) ellenőrzése ortogonális tömb alkalmazott problémák viszonylag kis bemeneti területe meghaladja a lehetőséget kimerítő kutatás;

6) tesztelés összes pár - egy olyan technika, ahol egy sor vizsgálati értékek tartalmazza az összes lehetséges biner kombinációjával egyes pár bemeneti paraméterek;

7) hibakeresés állapot átmenet - a technika ellenőrzéséhez hasznos a készülék állapotát, valamint navigálhat a GUI felhasználó.

Fekete doboz tesztelés: Példák

black-box technika alapja a műszaki dokumentációt, és a leírások a szoftver interfész vagy a rendszer. Ezen felül, akkor modellek (formális vagy informális), ami az elvárt viselkedés a szoftver.

Jellemzően ezt a módszert alkalmazzák hibakeresés felhasználói felület és interakciót igényel az alkalmazás bevezetésével adatgyűjtés és az eredmények - a képernyőn, a jelentések és a nyomtatáshoz.

A teszter, ezért együttműködik a szoftver megadásával, azáltal, hogy a kapcsolók, gombok és egyéb interfészek. A választás a bemeneti adatok, a sorrendben a beadás vagy műveletsornak vezethet egy hatalmas kombinációk teljes száma, amint az a következő példa.

Hány tesztet kell tennie annak érdekében, hogy ellenőrizze az összes lehetséges értékei a 4 ablak zászló és egyszeri mezőben állítsa be az időt másodpercben? Első látásra számítás egyszerű: 4 mezők két lehetséges állapot - 24 = 16, amelyet meg kell szorozni a számos lehetséges helyzetében 00 és 99, azaz a 1600 lehetséges tesztek.

Azonban ez a számítás hibás: meg tudjuk határozni, hogy a két pont területén is tartalmazhatnak szóközt, azaz két alfanumerikus pozícióban vannak, és betűket, számokat, különleges karaktereket, szóközöket stb Így, ha .... rendszer egy 16-bites számítógépet, kapcsolja 216 = 65536 egyet minden egyes pozíciójához a kapott 4294967296 vizsgálati esetek, amelyek meg kell szorozni 16 kombinációi a zászlók, hogy ad egy összesen 68.719.476 736. Ha végeznek 1 vizsgálati másodpercenként, a teljes CONT olzhitelnost tesztelés 2 177,5 év. 32 vagy 64 bites rendszereket, az időtartam még.

Ezért van szükség, hogy csökkentsék ezt az időszakot, hogy egy elfogadható szintre. Így a technikákat kell alkalmazni, hogy csökkentse a számú teszt hatályának korlátozása nélkül a tesztelés.

ekvivalencia partíciók

Az egyenértékű partíció egy egyszerű módszer, amely alkalmazható minden változók, amelyek jelen vannak a szoftver, hogy bemeneti és kimeneti értékek, jelképes, numerikus, és mások. Ez azon az elven alapul, hogy az összes adatot egy ekvivalens partíció ugyanúgy kezeljék, és a ugyanezeket az utasításokat.

A tesztelés során kiválasztott egy-egy képviselője minden egyes ekvivalencia partíció. Ez lehetővé teszi, hogy rendszeresen számának csökkentése lehetséges vizsgálati esetek veszteség nélkül lefedettség parancsokat és funkciókat.

Egy másik következménye ennek particionálás, hogy csökkentse a kombinatorikus robbanás a különböző változók és a kapcsolódó csökkentési vizsgálati esetek.

Például, az (1 / x) ^1/2 alkalmazásával három adatsorozatokat, három ekvivalens partíció:

1. Minden pozitív számok fogják kezelni, ugyanúgy, és meg kell adni a helyes eredményt.

2. Minden negatív számokat kezelik ugyanúgy és ugyanazt az eredményt. Ez helytelen, mert a gyökér negatív szám képzetes.

3. Zero különválasztva kezeljük, és így a hiba „nullával”. Ez egy szakaszt egyetlen érték.

Így láthatjuk, három különálló részből állnak, amelyek közül az egyik csökkenti egyetlen érték. Van egy „helyes” szakasz, amely megbízható eredményt ad, és a két „rossz” helytelen eredményeket.

határérték elemzés

Feldolgozás a határok az egyenértékű particionálás is lehet másképpen, mint várták. Vizsgálata határértékeket - egy jól ismert módszer viselkedésének elemzésére a szoftver az ilyen területeken. Ez a technika lehetővé teszi, hogy azonosítsa az ilyen hibák:

• helytelen használata relációs operátorok (<,>, =, ≠, ≥, ≤);
• Egyetlen hiba;
• problémák ciklusok és az ismétléseket
• rossz típusú vagy méretű használt változók az információ tárolására;
• mesterséges korlátozásokat kapcsolódó adattípusok és változókat.

áttetsző tesztelés

szürke doboz eljárás növeli a teszt lefedettség, akkor elsősorban a nehezebb szinteken keresztül a rendszer kombinációja fekete-fehér technikát.

Ezzel a módszerrel a teszter a fejlesztési vizsgálati értékek ismernie kell a belső adatstruktúrák és algoritmusok. Példák szürke doboz tesztelés módszerek a következők:

• építészeti modell;
• Unified Modeling Language (UML);
• állami modell (véges állapotú gép).

Az eljárás során a szürke doboz, hogy dolgozzon teszt esetek tanult modulok fehér mérnöki kódok, és a tényleges vizsgálatot az interfészek a fekete technológiai programok.

Ezeket a vizsgálati módszereket az alábbi előnyei vannak:

• előnyeinek kombinációját technikus fehér és fekete négyzetek;
• Tester alapul felület és funkcionális specifikáció, és nem a forráskód;
• debugger lehet, hogy nagy teszt esetek;
• ellenőrzésre kerül a szempontból a felhasználó, nem a tervező, a program
• létrehozhat egyéni vizsgálat fejlődést;
• objektivitását.

hátrányai:

• teszt lefedettség korlátozott, mert nincs hozzáférése a forráskódot
• bonyolítja a hibák elosztott alkalmazások;
• Sok szempontból maradt kihasználatlanul;
• ha a szoftver fejlesztő elindította a vizsgálatot, akkor további vizsgálat lehet a túlzott.

Egy másik neve a szürke doboz módszerek - áttetsző hibakeresés.

Ebbe a kategóriába tartoznak például vizsgálati módszerek:

1) ortogonális tömb - a használata egy része az összes lehetséges kombinációt;

2) mátrix hibakeresés a állapotát a program adatok;

3) regresszív végzett vizsgálata az új módosításokat a program;

4) sablon teszt, amely elemzi a design és az építészet egy jó alkalmazás.

Összehasonlítása a szoftver tesztelési technikák

A dinamikus módszerek vezet kombinatorikus robbanás a vizsgálatok száma, amelyeket meg kell kidolgozni, végrehajtani és megvalósítani. Minden technikát kell alkalmazni pragmatikusan meghozatala korlátokat is figyelembe.

Az egyetlen igaz módszer nem létezik, csak azok, amelyek jobban illeszkednek az adott kontextusban. Magasépítés lehetővé teszi számunkra, hogy megtalálja a haszontalan vagy rosszindulatú kódot, de igen összetettek, és nem alkalmazható a nagy programok. Módszerek előírásai alapján - az egyetlen, amely képes azonosítani a hiányzó kódot, de nem tudják azonosítani egy kívülálló. Egyes technikák több alkalmas egy adott vizsgálati szinten hiba típusától vagy az összefüggésben, mint mások.

Az alábbiakban a legfontosabb különbség a három dinamikus tesztelési technikák - adott egy összehasonlító táblázatot a három formáját hibakeresés szoftver.

vonatkozás	A fekete doboz módszer	Szürke doboz módszer	Fehér-box eljárás
Jelenlét-információ a készítmény a program	Megvizsgálja csak az alapvető szempontjai	Részleges ismereteket a belső szerkezete a program	Teljes hozzáférés a forráskód
Fokú töredezettség a program	alacsony	központi	nagy
Ki termel hibakeresést?	Végfelhasználóknak, tesztelők és a fejlesztők	A végfelhasználók, a fejlesztők és a hibakereső	A fejlesztők és tesztelők
bázis	A tesztelés alapján a külső vészhelyzeti helyzetekben.	Rajzok adatbázis, adatáramlás diagramok, állam belső tudás az algoritmus és az építészet	A belső berendezés teljes mértékben tudatában van
A lefedettségi fokának	Kevésbé átfogó, és minimális idő	központi	Potenciálisan a legátfogóbb. Időigényes
Az adatok és a belső határok	Csak hibakeresés próbálgatással	Úgy lehet ellenőrizni az adatokat domének és a belső határok, ha azok ismertek	A legjobb vizsgálati adatok domainek és a belső határok
Alkalmassági vizsgálat algoritmus	nincs	nincs	igen

automatizálás

Automatikus módszerek szoftverpróbája sokkal egyszerűbbé a vizsgálati folyamat, függetlenül a technikai környezet és a keretében. Hozzá vannak szokva a két esetben:

1) automatizálni az unalmas, ismétlődő vagy szigorú alkalmazások, mint például a fájl képest több ezer sort annak érdekében, hogy kiadja idő koncentrációja a tesztelő fontosabb pontokat;

2) elvégzésére nyomkövető vagy feladatok, amelyeket nem lehet könnyen végrehajtható az emberek, mint a teljesítmény ellenőrzése, illetve elemzés válaszidő, hogy mérhető századmásodperc alatt.

Vizsgálati eszközök sorolható különböző módokon. A következő osztás alapja a feladatok segítik:

• teszt menedzsment, amely magában foglalja a projekt menedzsment támogatása, változatok, konfigurációk, kockázatelemzés, vizsgálat nyomon követése, a hibák, hiányosságok, és jelentési eszközök;
• követelmények kezelése, amely magában foglalja a tárolási követelmények és előírások, ellenőrizze azokat a teljesség és a kétértelműség, a prioritás, és a nyomon követhetőség minden vizsgálat;
• kritikai felülvizsgálat és statikus elemzés, beleértve a megfigyelésén, és a feladatok, felvételi és tárolási észrevételek, hiba észlelése és a tervezett korrekciók kezelése linkeket ellenőrző listák és szabályok, követés kommunikáció forrás dokumentumok és a kód statikus felderítéséhez hibák, biztosítva az előírások betartását az írás kódját, elemzését struktúrák és függőségek számítása metrikus paraméterei a kód és az építészet. Ezen kívül, használja fordítóprogramok, analizátorok, generátorok és kapcsolatok a kereszt-referenciák;
• modellezés, amely magában foglalja a modellezés üzleti magatartás és tesztelni a modell;
• tesztfejlesztés biztosítja a generációs adatok alapján várható feltételek és a felhasználói felület modellek és a kód, sikerül létrehozni vagy módosítani és adatbázisok, üzenetküldés, adatellenőrzés a szabályok alapján az irányítás, a statisztikai elemzés a feltételek és kockázatok;
• kritikusan adatok bevitelével egy grafikus felhasználói felület, API, a parancssor használatával összehasonlító, hogy segítsen azonosítani a sikeres és sikertelen tesztek;
• támogatás hibakeresési környezet, amely lehetővé teszi, hogy pótolja a hiányzó hardver vagy szoftver, a Vol. h. Szimulációs berendezés alapján meghatározott kiadási részhalmaza, terminál emulátorok, mobiltelefonok és hálózati eszközök, a környezet ellenőrzéséhez nyelvek, operációs rendszerek és hardver helyett a hiányzó alkatrészek driver, fiktív modulok, stb, valamint az eszközök beszerzésének és módosítja az operációs rendszer kéri a CPU szimuláció korlátozás, RAM, ROM, vagy hálózati .;
• .. összehasonlítása adatállományok, adatbázisok, ellenőrizze a várt eredményeket alatt és után a teszt befejeződött, beleértve a dinamikus és kötegelt összehasonlítás Automatikus „Oracles”;
• Rétegmérés a lokalizáció memóriavesztés és helytelen viselkedés az ellenőrzési rendszer becslése alapján szimulált terhelés generáló terhelés alkalmazások, adatbázisok, hálózatok vagy szerverek egy valós forgatókönyv növekedési mérési, elemzési és ellenőrzési rendszer erőforrások jelentés;
• biztonság;
• teljesítmény tesztelés, terhelés és dinamikus analízis;
• egyéb eszközök, a Vol. h., hogy ellenőrizze a helyesírást és a szintaxis, a hálózati biztonság, a rendelkezésre álló valamennyi weblapok és más.

távlati

A változó trendek a szoftver-ipar, a folyamat a hibakeresés is változhatnak. Vannak új módszerek szoftvertesztelés, mint például egy szolgáltatás-orientirovannae architektúra (SOA), vezeték nélküli technológiák, a mobil szolgáltatások, és így tovább. E., megnyitották új módszereket vizsgáló szoftver. Egyes módosítások, amelyek várhatóan az ipar az elkövetkező években az alábbiak:

• tesztelők biztosítja a könnyű súly, hogy a fejlesztők képesek lesznek, hogy ellenőrizze a kódot;
• fejlesztése a vizsgálati módszerek, beleértve a megtekintést és modellező programok korai szakaszban, akkor megszünteti sok ellentmondás;
• a többszörös lehallgatások teszt idejének csökkentését hiba detektálását
• Statikus analizátor és érzékelő eszköz lehet szélesebb körben használják;
• az ásványi mátrixok, mint például lefedettség a leírás, a hatálya a modell és kódlefedettséget fogja meghatározni a fejlesztési projektek;
• kombinatorikus eszközök lehetővé teszik a tesztelők, hogy meghatározza a kiemelt területeket hibakeresés;
• tesztelők ad egy intuitív és értékes szolgáltatásokat a szoftverfejlesztési folyamat
• debuggers létrehozhat eszközök és szoftverek vizsgálati módszerek írt és kölcsönhatásban áll a különböző programozási nyelvek;
• Hibakeresés szakértőket több szakmailag képzett.

Helyébe egy új üzlet-orientált szoftverek vizsgálati módszerek, hogy megváltoztassa a kölcsönhatás a rendszerek és az általuk nyújtott információk, miközben csökkenti a kockázatot és növeli az előnyöket az üzleti változások.