Ez a legidőigényesebb szakasz. Célja a program szintaktikai és logikai helyességének ellenőrzése, valamint annak megállapítása, hogy a program az érvényes adatok teljes skáláján működik-e.
A program hibakeresése során a következő szakaszokat különböztetjük meg:
1. a program forrásszövegének fordítása;
2. program elrendezése;
3. programvégrehajtás a logikai hibák azonosítására;
4. program tesztelése.
Adás
A fordítás lefordítja az ember által olvasható programot számítógép által olvasható nyelvre. Ha a fordítás célja a teljes forrásszöveg átkonvertálása a számítógép belső nyelvére (azaz valamilyen új kód beszerzése), és semmi több, akkor az ilyen fordítást fordításnak is nevezik. A forrásszöveget forrásprogramnak vagy forrásmodulnak is nevezik, a fordítás eredményét pedig objektumkódnak vagy objektummodulnak. Ha a forrásszövegek egyes operátorai fordításon esnek át, és a kapott kódok azonnal végrehajtásra kerülnek, az ilyen fordítást interpretációnak nevezzük. Mivel a fordítást speciális szoftver végzi, az utóbbiakat fordítónak vagy tolmácsnak nevezzük.
A fordítási folyamat során a következőket hajtják végre egymás után: lexikális, szintaktikai, szemantikai elemzés, közbenső kódgenerálás, közbenső kódoptimalizálás, belső reprezentáció generálása.
Lexikai elemzés
A programszöveg egyes összetevőit, úgynevezett lexémákat azonosítjuk, és meghatározzuk a típusukat. A tokenek operátorneveket tartalmaznak, például olvasás vagy írás; nevek (változók vagy állandók), például NABOR vagy CHISLO, különféle elválasztók, például zárójelek, írásjelek stb. Ugyanakkor a megadott lexémák típusai operátornevek, változónevek, elválasztók stb. Ha a programozó hibázik és bemeneti operátort adunk meg, például rread, akkor azt névként ismeri fel a fordító. Ebben a szakaszban olyan szimbólumok használatát is észleli, amelyeket a programozási nyelv nem engedélyez, például a @ szimbólumot. A lexikális elemzés eredményeként a forrásprogram kódolása megtörténik: minden lexéma helyére a típusának megfelelő kód kerül, ami csökkenti a programszöveg mennyiségét. Ezenkívül a programszövegből eltávolítják a szóközöket.
1. példa: Egy Turbo Pascal programrészlet lexikai elemzése, amely csak egy helyesen megírt bemeneti utasítást tartalmaz:
olvas(NABOR,CHISLO);
láncot ad
ahol 1 az operátornév kódja;
2 – zárójeles kód;
3 – névkód;
4 – írásjelek.
2. példa: Egy Turbo Pascal programrészlet lexikai elemzése, amely csak egy hibásan írt bemeneti utasítást tartalmaz:
újraolvasás (NABOR,CHISLO); ,
láncot ad
Elemzés
Meghatározzuk a lexikális elemzés eredményeként kódolt lexémalánc szintaktikai helyességét. Meghatározzák például a zárójelek párosítását, a szükséges írásjel meglétét a megfelelő helyen, és a forrásszöveg megfelelését egy adott programnyelv szerkezeti szabályainak, amelyben a programot lefordították. A probléma megoldására az eredeti (kódolt) láncban azonosítjuk az operátor egyes töredékeinek megfelelő részstruktúrákat. Például a Turbo Pascal bemeneti operátora számára meghatározhatja az 1. ábrán látható struktúrát, amely megfelel az algoritmus strukturális leírásának szakasz 1. példájában szereplő szabályoknak:
1. kép
Ugyanakkor a "helyes" bemeneti utasítás szerkezetét a séma határozza meg:
2. ábra
Mivel a bemutatott struktúrák azonosak, az utasítás így szólt (NABOR,CHISLO); elemzéskor megállapítja, hogy helyes-e.
Ebben a lépésben azonosítják az operátornevek helyesírási hibáit: ezek a teljes operátor hibás szerkezetéhez vezetnek. Tehát egy példa egy „hibás” beviteli operátorral megfelel az ábrán látható szerkezetnek:
3. ábra
Mivel az ábra szerkezete nem egyezik az 1. ábra szerkezetével, az rread utasítás (NABOR,CHISLO); szintaktikailag hibásnak minősül: a fordító az elemzett töredékben nem találja meg a szükséges műveletet, amelyet az operátor neve határoz meg, és erről tájékoztatja a programozót.
Szemantikai elemzés
Ennél a lépésnél a programozó által a programozási szabályokat megsértő hibákat azonosítják, például a következő típusúak: minden változót és állandót le kell írni, mielőtt nyelvi utasításokban használnák őket; minden nevet (változó vagy állandó) csak egyszer kell leírni; össze kell hangolni a változók típusait az azokat használó függvényekkel stb. Tehát, ha a teljes program csak az utasításból áll
olvas(NABOR,CHISLO); ,
szemantikailag hibásnak lesz definiálva, mert hiányzik a bemeneti változók leírása.
3. példa Program
var NABOR, CHISLO: egész szám;
olvas(NABOR, CHISLO);
4. példa Program
var CHISLO: egész szám;
CHISLO:=CHISLO + 1;
a szemantikai elemző szemantikailag helyesnek tekinti.
Köztes kód generálása
A lexémák kódolt lánca valamilyen, egy adott számítógépen elfogadott köztes reprezentációvá alakul, például assembly nyelvű programmá (az egyszerűség kedvéért valamilyen feltételes assemblert használunk).
5. példa: A 4. példa programja a feltételes összeállítóban köztes kóddá alakul:
$1DD? ; A DD utasítások változókat írnak le: mindegyiket
$2DD?; 2 bájt memóriát foglal le a változó számára;
$3DD?; a $1 - $3 változókat a kódgenerátor a következőképpen adja meg
CHISLO DD?; segédváltozók;
MOVE 1, $1; a MOVE utasításokban konstansok vagy tartalmak
MOVE CHISLO, $2; a vesszőtől balra lévő változók a változókba és
MOVE $1, AX; processzor regiszterek (AX és CX), jobbra jelölve;
ADD AXE, CX; az AX és CX regiszterek tartalma hozzáadásra kerül,
; az eredmény az AX regiszterben marad
MOVE AXE, 3 dollár; -ban található értékeket
MOVE $3,CHISLO; regiszter és változó, megfelelő változókká
Az így kapott kód redundáns: valójában az 1-es konstans és a CHISLO változó értékének értelmetlen átvitele, először a további $1 és $2 változókba, majd az összeadás során használt AX és CX regiszterekbe. Hasonló értelmetlen műveleteket hajtanak végre az összeadás eredményével. A kód méretének csökkentésére azonban a következő lépésben kerül sor.
A köztes kód optimalizálása
Az előző lépésben kapott programból kikerülnek az „extra” operátorok, változók és konstansok, amelyek használata nem befolyásolja a végrehajtott műveletek helyességét.
6. példa: A program közbenső kódjának optimalizálása az 5. példából a következő formába hozza:
Ez az eredmény annak köszönhető, hogy számos operátor végzett szükségtelen adatmozgatást egyik tárolóhelyről a másikra. Ezen utasítások eltávolítása a segédváltozók eltávolításával járt.
Objektumkód generálása
Az optimalizálás eredményeként kapott programot gépi kóddá alakítják (ún. objektummodul), amely a fő memória relatív, nem pedig abszolút címeit használja. Az objektummodul megszerzéséhez általában feltételes memóriát használnak, amelynek kezdőcíme 1. Minden programutasítás gépi utasítássá alakul, és a kezdőcímtől kezdve abba a sorrendbe kerül, ahogyan a programban megjelenik. Ez figyelembe veszi az egyes kezelők méretét. A 6. példa programparancsai feleljenek meg a gépi parancsoknak:
kód hangerő művelet
tevékenységek
124 1 b Adja hozzá az AX és CX regiszterek tartalmát, az eredmény az AX regiszterben van,
125 3 b helyezze el az AX regiszter tartalmát a címen
126 2 b helyezze a konstanst az AX regiszterbe,
127 3 b helyezze el a cím tartalmát a CX regiszterben.
Cél és eljárás
A munka célja a hibakereső programok eszközeinek és képességeinek tanulmányozása a Microsoft Visual C++ 2008 (Visual Studio 2008) integrált környezetben.
Munkarend:
Olvassa el a laboratóriumi munka leírását;
Kapjon megbízást a tanártól, választása szerint;
Írjon programot, és végezzen hibakeresést a számítógépen;
Hozzon létre egy jelentést.
Rövid elmélet
A Microsoft Visual C++ 2008 integrált interaktív programfejlesztő környezet (IDE) számos olyan eszközt tartalmaz, amelyek megkönnyítik a programok megfelelő működését akadályozó hibák megtalálását.
Hibakeresési koncepció
A hibakeresés a program megfelelő működését akadályozó hibák megtalálásának és kijavításának folyamata.
A program hibakeresése a fejlesztés egyik legfontosabb és legidőigényesebb szakasza. A hibakeresés összetettsége és hatékonysága közvetlenül függ a hibakeresési módszertől és a programozási nyelvi eszközöktől.
Számos egyszerű dolog megkönnyítheti a program hibakeresését. A legtöbb esetben igaz, hogy nem szabad egynél több utasítást elhelyezni egy program ugyanabban a sorában. Mivel a program végrehajtása soronként történik a hibakeresés során, ez a követelmény biztosítja, hogy egyszerre legfeljebb egy utasítás kerüljön végrehajtásra.
Ugyanakkor olyan esetek is megengedettek, amikor több operátor is elhelyezhető egy vonalon. Ha van egy lista azokról az utasításokról, amelyeket végre kell hajtani, de amelyek valójában nem relevánsak a hibakeresés szempontjából, akkor véletlenszerűen elhelyezheti őket egy vagy két sorban, hogy gyorsabban léphessen át rajtuk.
Végül is a legjobb hibakeresés a megelőző hibakeresés. Egy jól megtervezett, világosan megírt program nemcsak kevés hibát tartalmazhat, hanem megkönnyíti a hibák helyének nyomon követését és rögzítését. Számos alapvető szempontot kell szem előtt tartani a program létrehozásakor:
Program fokozatosan. Amikor csak lehetséges, kis szakaszokban kódolja és hibajavítsa a programot. Dolgozzon végig minden szakaszon a befejezésig, mielőtt továbblépne a következőre;
Bontsa fel a programot részekre: modulok, eljárások, függvények. Kerülje a 25-30 sornál nagyobb függvények építését, ellenkező esetben bontsa fel őket több kisebb függvényre;
Próbáljon információt csak paramétereken keresztül átadni, ahelyett, hogy globális változókat használna az eljárásokon és függvényeken belül. Ez segít elkerülni a mellékhatásokat és megkönnyíti a program hibakeresését, mivel könnyedén nyomon követheti az adott eljárásba vagy funkcióba be- és kilépő összes információt;
Bevezetés
Szoftvertesztelési és hibakeresési fogalmak
1 A szoftvertesztelés és hibakeresés elvei
2 A szoftvertesztelés szakaszai
3 A szoftvertesztelés céljai és célkitűzései
4 Átfogó szoftvertesztelés
5 Felfelé és lefelé irányuló tesztelés
Szoftvertesztelés és hibakeresési stratégia
1 Szendvics módszer
2 Fehér doboz módszer
3 Fekete doboz módszer
4 Szoftver hibakeresési módszer
Következtetés
Szójegyzék
A felhasznált források listája
Rövidítések listája
Bevezetés
A szoftvertesztelés története magának a szoftverfejlesztésnek az evolúcióját tükrözi. A szoftverfejlesztés hosszú ideig a nagyszabású tudományos programokra és a Védelmi Minisztérium programjaira összpontosított, amelyek vállalati adatbázisrendszerekhez kapcsolódnak, amelyeket nagyszámítógépen vagy miniszámítógépen terveztek. A tesztforgatókönyveket papíron rögzítették. Segítségükkel a célvezérlési folyamatokat, összetett algoritmusok számításait és az adatmanipulációt tesztelték. A teszteljárások végső sorozata hatékonyan tesztelheti a teljes rendszert. A tesztelést általában csak a projekt ütemtervének befejezése után kezdték meg, és ugyanaz a személyzet végezte.
A személyi számítógépek megjelenése elősegítette az iparág szabványosítását, mivel az alkalmazásokat elkezdték építeni, hogy egy közös operációs rendszeren fussanak. A személyi számítógépek bevezetése új korszakot nyitott, és a kereskedelmi fejlesztések gyors és robbanásszerű növekedéséhez vezetett. A kereskedelmi alkalmazások keményen versengtek az elsőbbségért és a túlélésért. A számítógép-felhasználók defacto szabványként fogadták el a fennmaradt szoftvert. A kötegelt feldolgozást valós idejű rendszerek váltották fel.
A valós idejű rendszerek tesztelése más megközelítést igényelt a teszttervezés során, mivel a munkaszálak bármilyen sorrendben hívhatók. Ez a funkció hatalmas számú tesztelési eljárás megjelenéséhez vezetett, amelyek képesek végtelen számú permutációt és kombinációt támogatni.
Sok fejlesztői szerencsétlenség oka a szoftverhibák, amelyek miatt régóta esedékes projektek és álmatlan éjszakák hullanak a hosszútűrő fejükre. A hibák nagyon megkeseríthetik a fejlesztő életét, mert csak néhány hiba kell bekerülni a programjaikba, az ügyfelek felhagynak a programok használatával, és ők maguk is elveszíthetik munkájukat.
Sokáig a hibákat pusztán kellemetlenségnek tekintették. Semmi sem állhat távolabb az igazságtól. Minden programozó ismer olyan cégeket, amelyek csak azért zártak be, mert olyan szoftvereket adtak ki, amelyek a rengeteg hiba miatt teljesen használhatatlanok voltak. Mivel a számítógépesítés egyre inkább olyan kritikus területekre terjed ki, mint az életfenntartó rendszerek, az orvosi eszközök és az ultradrága számítógépes hardver, a hibákat már nem lehet egyszerűen kinevezni, vagy úgy kezelni, mint ami csak a fejlesztés során számít.
Átlagosan a fejlesztési ciklus körülbelül 50%-át hibakeresésre fordítják. Ha a hibakeresést időben elkezdjük, annak időtartama radikálisan lecsökkenthető, ami azt jelenti, hogy az ügyfél sokkal gyorsabban kapja meg a programot. Nem spórolhat időt a követelmények áttekintésével és tervezésével, de a hibakeresést sokkal hatékonyabbá teheti. A hibakeresést a követelmények fejlesztési szakaszában kell elkezdeni, és a termék végső verziójáig kell folytatni.
1. A szoftvertesztelés és hibakeresés fogalmai
.1 A szoftvertesztelés és hibakeresés elvei
A szoftvertesztelés a szoftver elemzésének vagy működtetésének folyamata a hibák azonosítása érdekében.
A meghatározás egyszerűsége ellenére további pontosítást igénylő pontokat tartalmaz. A folyamat szó annak hangsúlyozására szolgál, hogy a tesztelés tervezett, rendezett tevékenység. Ez a pont nagyon fontos, ha a gyors fejlesztésben vagyunk érdekeltek, mert az átgondolt, szisztematikus megközelítés a szoftverhibák gyorsabb felfedezéséhez vezet, mint a rosszul megtervezett, szintén kapkodó tesztelés.
E meghatározás szerint a tesztelés egy szoftvertermék „elemzését” vagy „működtetését” foglalja magában. A szoftverfejlesztési eredmények elemzéséhez kapcsolódó tesztelési tevékenységeket statikus tesztelésnek nevezzük. A statikus tesztelés magában foglalja a programkódok ellenőrzését, a végpontok közötti vezérlést és a program ellenőrzését anélkül, hogy a gépen futna, pl. asztali ellenőrzések. Ezzel szemben a szoftvertermék működésével járó tesztelési tevékenységeket dinamikus tesztelésnek nevezzük. A statikus és dinamikus tesztelés kiegészíti egymást, és az ilyen típusú tesztelések mindegyike saját megközelítést valósít meg a hibák azonosítására.
A definíció utolsó, további magyarázatot igénylő pontja a hiba (bug) fogalma. Egyszerűen fogalmazva, a szoftverhiba nem más, mint egy szoftvertermék fejlesztésének hibája, amely eltérést okoz a szoftvertermék végrehajtásának várt és a ténylegesen elért eredmények között. A hiba előfordulhat a kódolási szakaszban, a követelmények szakaszában vagy a tervezési szakaszban, vagy oka lehet a hibás konfiguráció vagy adatok. Hiba lehet más is, ami nem felel meg a vevő elvárásainak, és ami a szoftvertermék specifikációjában meghatározott vagy nem. A hibaterminológia részletesebb leírása az oldalsávban található.
A hibakeresés a hibaforrások azonosításának folyamata, pl. hibákat, és a program megfelelő javításait.
1.2 Szoftvertesztelési szakaszok
A teszttervezés első lépése egy magas szintű tesztstratégia kidolgozása. Általánosságban elmondható, hogy a vizsgálati stratégiának meg kell határoznia a vizsgálati munka hatókörét, a hibák felderítésére használt vizsgálati technikák típusait, a hibák bejelentésének és kiküszöbölésének eljárásait, valamint a különböző típusú teszteléseket szabályozó teszt be- és kilépési kritériumait. A fejlesztési ütemterv optimalizálása érdekében a fejlesztés és a tesztelés szoros integrációjának elvét megvalósítva a tesztelési stratégiának le kell térképeznie a különböző típusú tesztelési tevékenységeket a fejlesztési életciklusba. Az átfogó stratégia kialakításakor mind a statikus, mind a dinamikus tesztelést figyelembe kell venni.
Ha az automatizálást különféle tesztelési tevékenységek támogatására használják, az automatizálási stratégiát az átfogó tesztelési stratégia részének kell tekinteni. Az automatizálás független, párhuzamos tevékenységeket igényel, amelyeket gondosan meg kell tervezni, és csak akkor kell végrehajtani, ha ez nem eredményez hatékonyságvesztést.
A következő megközelítések léteznek a tesztelési stratégia kialakítására:
Határozza meg a tesztmunka hatókörét a szoftvertermékkövetelményeket (műszaki specifikációkat) tartalmazó dokumentumok elemzésével, hogy meghatározza, mit kell tesztelni. Fontolja meg azokat a tesztelési típusokat, amelyek nem következnek közvetlenül a követelménydokumentumokból, mint például a szoftvertermék telepíthetőségének és bővíthetőségének, a termék használhatóságának és egyszerű karbantartásának, valamint az ügyfél környezetében lévő más típusú hardverekkel való interakció képességének tesztelése. .
Határozza meg a tesztelési megközelítést az egyes fejlesztési szakaszokhoz tartozó statikus és dinamikus tesztek kiválasztásával. Itt meg kell adnia az összes olyan munkatermék leírását, amelyet a tesztcsoportnak elő kell készítenie.
Határozza meg a be- és kilépési kritériumokat a tesztelés minden szakaszához, valamint minden minőség-ellenőrzési pontot, amelyhez tesztelési szakemberek részvétele szükséges.
Határozza meg az automatizálási stratégiát, ha bármilyen típusú tesztelési tevékenység automatizálását tervezi. Az automatizálás független, párhuzamos tevékenységeket igényel, amelyeket gondosan meg kell tervezni, és csak akkor kell végrehajtani, ha ez nem eredményez hatékonyságcsökkenést.
A próbamunka körének meghatározása
Mivel lehetetlen mindent tesztelni, kétségtelen a tesztelni kívánt elem kiválasztásának fontossága. Ha engedélyezi a „nyers erőt” a tesztelés során, azaz ha a teszt lefedettsége redundáns, akkor a szoftvertermék hibakeresése jelentős időt vesz igénybe, ami veszélyezteti a projekt határidejét. Ha a tesztelés elégtelennek bizonyul (pontosabban a tesztlefedettség nem lesz elegendő), akkor megnő az egyik vagy másik hiba hiányának kockázata, aminek elhárítása különösen a szoftvertermék üzembe helyezése után igen költséges lesz. A tapasztalat és a tesztelés sikerének mérésére szolgáló módszer segít megtalálni a megfelelő egyensúlyt e két véglet között.
Íme néhány tesztstratégia-javaslat, amelyek segítenek megtalálni az optimális tesztlefedettséget:
Először tesztelje a legmagasabb prioritású követelményeket.
Tesztelje az új funkciókat és a módosított kódokat a régi funkciók javítása vagy javítása érdekében
Használjon egyenértékű osztályfelosztást és határérték-elemzést a tesztelési erőfeszítések csökkentése érdekében
Tesztelje azokat a területeket, ahol a legvalószínűbb a problémák előfordulása
Összpontosítson azokra a funkciókra és konfigurációkra, amelyekkel a végfelhasználó a leggyakrabban kommunikál.
Tesztelési megközelítés meghatározása
A tesztelési stratégia megfogalmazásának második szakasza a tesztelés megközelítésének meghatározására vonatkozik. A tesztelési megközelítés felépítése a fejlesztési életciklus egyes szakaszainak vizsgálatával kezdődik, hogy kiválasszuk a megfelelő szakaszban használható statikus és dinamikus tesztelési teszteket. Nem mindegy, hogy melyik fejlesztési életciklus-modellt használjuk: kaszkádot, spirált vagy iteratív verziójú modellt - a hatékony tesztek kiválasztásához a felsorolt modellek bármelyikének szakaszait megvizsgálhatja. Vegyük példaként a vízesés modellt, és nézzük meg, milyen típusú tesztelések használhatók hozzá:
Követelmények megfogalmazásának szakasza
A rendszer tervezési szakasza
Programprojektek tesztelésének szakaszai, programkódok, egységteszt és komplex tesztelés
Rendszertesztek
Átvételi tesztek
Regressziós teszt
A tesztelési megközelítésnek tükröződnie kell a tesztterv dokumentumokban.
Vizsgálati kritériumok és minőségellenőrzési pontok meghatározása
A rendszertesztelés megkezdése előtt ötféle kritérium határozható meg:
Belépési feltételek. Leírja, hogy mit kell tenni a tesztelés megkezdése előtt.
Kilépési kritérium. Leírja, hogy mit tart szükségesnek a teszt kitöltéséhez.
Felfüggesztés/újraindítás kritériuma. Leírja, mi történik, ha hibák miatt nem lehet folytatni a tesztelést.
A vizsga teljesítésének/megbukásának kritériumai. Minden teszt futtatásának ismert eredményeket kell eredményeznie.
Eljárás vagy szabvány által meghatározott egyéb kritériumok. Ha egy szoftverterméknek meg kell felelnie egy bizonyos szabványnak, vagy a vállalat bizonyos követelményeket támaszt a végrehajtott folyamattal szemben, akkor számos további kritériumot kell figyelembe venni.
Automatizálási stratégia meghatározása.
Reális tervek és ésszerű feltételezések mellett az automatizált eszközök és az automatizált tesztesetek használata kiváló módja a szoftvertermékek tesztelésére fordított idő csökkentésének. Minden olyan feladat, amelyet ismételten végrehajtanak, alkalmas az automatizálásra. Egy feladat automatizálása azonban általában sokkal tovább tart, mint annak befejezése, ezért minden automatizálható feladat esetében célszerű alaposan elemezni az automatizálás lehetséges előnyeit. A lehetséges előnyök elemzésekor emlékezni kell arra, hogy magának az automatizálásnak megvan a maga autonóm életciklusa.
A hatékony automatizáláshoz speciális képzésre, fejlesztésre, hibakeresésre és ellenőrzésre van szükség, akárcsak bármely más szoftverfejlesztési projekt. A nem tervezett és rosszul végrehajtott automatizálás nemcsak az erőforrásokat pazarolja, hanem akár ütemezési zavarokhoz is vezethet, ha az időt az automatizálás hibakeresésével töltik a tesztelés helyett.
1.3 A szoftvertesztelés céljai és célkitűzései
A tesztelés céljai:
Növelje annak valószínűségét, hogy a tesztelésre szánt alkalmazás minden körülmények között megfelelően fog működni.
Növelje annak valószínűségét, hogy a tesztelt alkalmazás megfelel az összes leírt követelménynek.
A tesztelés céljai:
Ellenőrizze, hogy a rendszer a megadott ügyfél- és szerverválaszidőn belül működik-e.
Győződjön meg arról, hogy a végfelhasználói rendszer legkritikusabb műveletsorozatait megfelelően hajtják-e végre.
Ellenőrizze a felhasználói felületek működését
Győződjön meg arról, hogy az adatbázisok módosításai nem érintik hátrányosan a meglévő szoftvermodulokat.
A tesztek tervezésekor minimalizálja a tesztek átdolgozását az esetleges alkalmazásmódosítások esetén.
Adott esetben használjon automatizált tesztelőeszközöket.
A vizsgálatokat úgy végezze el, hogy ne csak észlelje, hanem megelőzze a hibákat.
Az automatizált tesztek tervezésekor használjon fejlesztési szabványokat az újrafelhasználható és karbantartható szkriptek létrehozásához.
1.4 Átfogó szoftverteszt
Az átfogó tesztelés célja annak ellenőrzése, hogy egy szoftvertermék minden modulja megfelelően illeszkedik-e a termék többi moduljához. Az átfogó tesztelés során felülről lefelé és alulról felfelé irányuló feldolgozási technológiát alkalmazhatunk, amelyben minden egyes modul, amely egy levél a rendszerfában, alacsonyabb vagy magasabb szinten integrálódik a következő modullal, amíg létre nem jön egy szoftvertermékfa. Ez a tesztelési technika nem csak a két komponens között átadott paraméterek tesztelését célozza, hanem a globális paramétereket is, és objektum-orientált alkalmazás esetén az összes legfelső szintű osztályt is.
Minden végponttól végpontig terjedő tesztelési eljárás felső szintű tesztszkriptekből áll, amelyek egy adott feladatot végrehajtó felhasználót szimulálnak, alsó szintű egységteszteket használva a szükséges paraméterekkel az interfész teszteléséhez. Az összes egységtesztelési hibajelentéssel kapcsolatos döntések meghozatala után a modulokat fokozatosan kombinálják és együtt tesztelik a vezérlési logika alapján. Mivel a modulok más modulokból is összeállíthatók, a végpontok közötti tesztelési munka egy része az egységtesztelés során is elvégezhető. Ha az egységtesztelési parancsfájlokat automatizált tesztelőeszközökkel hozták létre, akkor ezek kombinálhatók, és új szkriptek adhatók hozzá a modulok közötti kapcsolatok teszteléséhez.
Átfogó tesztelési eljárásokat követnek és megfelelően finomítanak, a hibajelentéseket pedig dokumentálják és nyomon követik. A problémajelentéseket általában súlyosságuk alapján osztályozzák, 1-től 4-ig (1 a legkritikusabb és 4 a legkevésbé kritikus). A jelentések feldolgozása után a tesztelő regressziós tesztelést végez, hogy megbizonyosodjon arról, hogy a problémák teljesen megoldódnak.
1.5 Alulról felfelé és felülről lefelé irányuló tesztelés
Az alulról felfelé irányuló tesztelés nagyszerű módja a hibák elkülönítésének. Ha egyetlen modul tesztelése során hibát fedeznek fel, akkor nyilvánvaló, hogy az benne van - a forrás megtalálásához nem kell elemeznie a teljes rendszer kódját. És ha hiba jelenik meg, amikor két korábban tesztelt modul együtt működik, akkor a probléma az interfészükben van. Az alulról felfelé irányuló tesztelés másik előnye, hogy az azt végrehajtó programozó nagyon szűk területre koncentrál (egy modul, adatátvitel két modul között stb.). Ez alaposabbá teszi a tesztelést, és nagyobb valószínűséggel azonosítja a hibákat.
Az alulról felfelé irányuló tesztelés fő hátránya, hogy speciális wrapper kódot kell írni, amely meghívja a tesztelt modult. Ha viszont egy másik modult hív meg, akkor egy „csonkot” kell írni hozzá. A csonk a hívott függvény utánzata, ugyanazokat az adatokat adja vissza, de nem tesz mást.
Nyilvánvaló, hogy a csomagolóanyagok és csonkok írása lelassítja a munkát, és a végtermék szempontjából teljesen használhatatlanok. De miután megírta, egyetlen elem sem használható fel minden alkalommal, amikor a program változik. Egy jó csomagoló- és csonkkészlet nagyon hatékony tesztelési eszköz.
Az alulról felfelé irányuló teszteléssel ellentétben a holisztikus tesztelési stratégia azt feltételezi, hogy a rendszer egyes moduljait nem tesztelik különösebben alaposan, amíg a rendszer teljesen integrálva van.
Ennek a stratégiának az az előnye, hogy nincs szükség további kód írására. Ezért sok menedzser választja ezt a módszert időmegtakarítási okokból – úgy gondolják, hogy jobb egyetlen kiterjedt tesztkészletet kidolgozni, és ezzel egyszerre ellenőrizni a teljes rendszert. De ez az elképzelés teljesen téves, és itt van, miért.
Nagyon nehéz azonosítani a hiba forrását. Ez a fő probléma. Mivel egyik modult sem tesztelték megfelelően, a legtöbben vannak hibák. Kiderül, hogy nem annyira az a kérdés, hogy melyik modulban fordult elő az észlelt hiba, hanem az, hogy a folyamatban részt vevő összes modul hibái közül melyik vezetett a kapott eredményhez. És ha több modulból származó hibák átfedik egymást, a helyzetet sokkal nehezebb elkülöníteni és megismételni.
Ezenkívül az egyik modul hibája blokkolhatja egy másik modul tesztelését. Hogyan lehet tesztelni egy függvényt, ha az azt hívó modul nem működik? Ha nem írunk wrapper programot ehhez a funkcióhoz, akkor meg kell várni a modul hibakeresését, ami sokáig tarthat.
Nehéz megszervezni a hibajavításokat. Ha egy programot több programozó ír (és nagy rendszerekben pontosan ez történik), és nem tudni, melyik modul tartalmazza a hibát, akkor ki keresi meg és javítja ki? Az egyik programozó rámutat a másikra, aki miután megtudta, hogy a kódjának semmi köze hozzá, ismét az elsőhöz fordul, és ennek eredményeként a fejlesztés sebessége nagymértékben szenved.
A tesztelési folyamat rosszul automatizált. Ami első pillantásra a holisztikus tesztelés előnyének tűnik – a burkolólapok és csonkok írásának hiánya – valójában a hátránya. A fejlesztési folyamat során egy program naponta változik, és újra és újra tesztelni kell. A héjak és csonkok pedig segítenek automatizálni ezt a monoton munkát.
A tesztelés megszervezésének van egy másik alapelve is, amelyben a programot, csakúgy, mint az alulról felfelé irányuló módszerrel, nem egészben, hanem részenként tesztelik. Csak a mozgás iránya változik - először a modulhierarchia legfelső szintjét teszteljük, majd onnan fokozatosan lefelé halad a tesztelő. Ezt a technológiát felülről lefelé irányulónak nevezik. Mindkét technológiát – felülről lefelé és alulról felfelé – inkrementálisnak is nevezik.
A felülről lefelé irányuló teszteléssel nem kell shelleket írni, de a csonkok megmaradnak. A tesztelés előrehaladtával a csonkokat egyenként valódi modulokra cserélik.
A szakértők nagy különbségeket mutatnak abban, hogy a két növekményes tesztelési stratégia közül melyik a hatékonyabb. A gyakorlatban a tesztelési stratégia megválasztásának kérdését általában egyszerűen megoldják: minden modult lehetőség szerint azonnal a megírása után tesztelnek, ennek eredményeként a program egyes részeinek tesztelési sorrendje emelkedőnek bizonyulhat, ill. mások - csökkenő.
2. Szoftvertesztelés és hibakeresési stratégia
.1 Szendvics módszer
A szendvicstesztelés kompromisszumot jelent az alulról felfelé és a felülről lefelé irányuló megközelítések között. Itt arra teszünk kísérletet, hogy kihasználjuk mindkét módszer előnyeit, miközben elkerüljük a hátrányait. Ennek a módszernek a használatakor az alulról felfelé és a felülről lefelé irányuló tesztelés egyszerre indul, alulról és felülről is összeállítva a programot, és végül valahol középen találkozik. A találkozási pont a tesztelt programtól függ, és előre meg kell határozni annak szerkezetét tanulmányozva. Például, ha egy fejlesztő a rendszerét alkalmazásmodul-szintnek, majd lekérdezés-feldolgozó modulszintnek, majd primitív funkciószintnek tekintheti, akkor dönthet úgy, hogy felülről lefelé irányuló megközelítést alkalmaz az alkalmazásmodul szintjén (ehelyett programozási csonkok). lekérdezésfeldolgozó modulok) és alulról felfelé irányuló módszert alkalmaz. A szendvics módszer egy intelligens megközelítés nagy programok, például operációs rendszer vagy alkalmazáscsomag integrálásához.
A szendvicsmódszer megtartja a felülről lefelé és alulról felfelé irányuló megközelítések előnyeit a rendszerintegráció nagyon korai szakaszában történő megkezdésében. Mivel a program teteje korán működésbe lép, a felülről lefelé irányuló módszerhez hasonlóan már korai szakaszban megkapjuk a program működő vázát. Mivel a program alsó szintjei alulról felfelé irányuló módszerrel jönnek létre, a felülről lefelé irányuló módszer azon problémái, amelyek azzal jártak, hogy bizonyos feltételeket nem tudtak tesztelni a program mélyén, megszűnnek.
Módosított szendvicsmódszer.
A szendvics tesztelés ugyanazzal a problémával néz szembe, mint a felülről lefelé irányuló megközelítés, bár itt kevésbé súlyos. A probléma az, hogy az egyes modulokat nem lehet alaposan tesztelni. Az alulról felfelé irányuló szendvicstesztelés megoldja ezt a problémát az alacsonyabb szintű modulok esetében, de továbbra is nyitva állhat a program felső felének alsó felére. A módosított szendvics módszernél az alsó szinteket is szigorúan alulról felfelé vizsgálják. A felső szintű modulokat pedig először elkülönítve tesztelik, majd felülről lefelé irányuló módszerrel szerelik össze. Így a módosított szendvicsmódszer kompromisszumot is jelent az alulról felfelé és a felülről lefelé irányuló megközelítések között.
2.2 Fehér doboz módszer
A fehér doboz kifejezés azt jelenti, hogy a tesztelők a belső struktúrával vagy kóddal kapcsolatos minden rendelkezésre álló tudást felhasználják a tesztesetek kidolgozásakor. A fehérdobozos tesztelés során használt technológiákat általában statikus tesztelési technológiáknak nevezik.
Ennek a módszernek nem célja a szintaktikai hibák észlelése, mivel az ilyen jellegű hibákat általában a fordító észleli. A fehér doboz módszerek célja a nehezebben azonosítható, megtalálható és kijavítható hibák lokalizálása. Segítségükkel felismerheti a logikai hibákat és ellenőrizheti a teszt lefedettségének mértékét.
A fehér doboz stratégiához kapcsolódó tesztelési eljárások az eljárások vezérlési logikáját használják. Számos szolgáltatást nyújtanak, többek között:
Garantálja, hogy a modulban lévő összes független elérési út legalább egyszer ellenőrzésre kerül.
Minden logikai megoldást ellenőriznek, hogy igazak-e vagy hamisak.
Minden ciklus végrehajtása működési határokon belül és határértékek használatával.
Megvizsgálják a belső adatok szerkezetét, hogy igazolják azok megbízhatóságát.
A fehér dobozos tesztelés jellemzően egy egységtesztelési stratégiát foglal magában, amelyben a tesztelés egység vagy funkcionális szinten történik, és a tesztelési erőfeszítések a modul belső működésének vizsgálatára irányulnak. Ezt a fajta tesztelést egységtesztelésnek, átlátszó doboztesztnek vagy áttetsző tesztelésnek is nevezik, mivel a tesztelést végző személyek hozzáférnek a programkódhoz, és belülről láthatják, hogyan működik a program. Ezt a tesztelési megközelítést strukturált megközelítésnek is nevezik.
A tesztelési tesztek ezen szintje vezérli a moduláris szinten megjelenő logikát. A teszt-illesztőprogramok segítségével biztosítják, hogy egy adott modulban lévő összes útvonalat legalább egyszer teszteljék, minden logikai megoldást minden lehetséges körülmény között megvizsgáljanak, a ciklusokat felső és alsó határok segítségével hajtsák végre, és a belső adatstruktúrákat vezéreljék.
Fehér doboz stratégián alapuló vizsgálati módszerek:
Helytelen értékek beírása. Ha helytelen értékeket ad meg, a teszter kényszeríti a visszatérési kódokat, hogy hibákat mutassanak, és megnézi a kód válaszát. Ez egy jó módszer bizonyos események szimulálására, mint például a lemez megtelt, a memória kevés stb. Egy népszerű módszer az alloc() lecserélése egy olyan függvényre, amely az esetek 10%-ában NULL-t ad vissza, hogy megtudja, hány összeomlást fog okozni. Ezt a megközelítést hibás bemeneti adatok tesztelésének is nevezik. Az ilyen típusú tesztelés az érvényes és érvénytelen bemeneti adatok feldolgozását egyaránt ellenőrzi. A tesztelők kiválaszthatnak olyan értékeket, amelyek tesztelik a bemeneti/kimeneti paraméterek tartományát, valamint olyan értékeket, amelyek kívül esnek a tartományon.
Egységteszt. A szoftvertermék minden egyes moduljához tartozó kód létrehozásakor egységtesztet hajtanak végre annak ellenőrzésére, hogy a kód megfelelően működik-e, és megfelelően implementálja-e az architektúrát. Az egységtesztelés az új kódot egy részletes felépítési leírás alapján teszteli; Megvizsgálják a kódban található útvonalakat, hogy megbizonyosodjanak arról, hogy a képernyők, a legördülő menük és az üzenetek megfelelően vannak formázva; a bemeneti adatok tartományát és típusát ellenőrzik, és minden kódblokk kivételeket dob, és szükség esetén hibákat ad vissza. A szoftvertermékek minden egyes moduljának tesztelése megtörténik az algoritmusok és a logika helyességének, valamint a szoftvermodulnak a követelményeknek való megfelelés és a szükséges funkcionalitás ellenőrzése érdekében. Az egységtesztek eredményei alapján rögzítik a programlogikai, túlterhelési és hatótávolságon kívüli hibákat, üzemidőt és memóriaszivárgást.
Hibakezelés tesztelése. Ez a módszer felismeri, hogy nem célszerű minden lehetséges hibaállapotot tesztelni. Emiatt egy hibakezelő program mérsékelheti a váratlan hibák bekövetkezésének következményeit. A tesztelő felelőssége annak biztosítása, hogy az alkalmazás megfelelően jelentse a hibaüzenetet. Így a köztesszoftver okozta rendszerhibát jelző alkalmazás csekély értékű sem a végfelhasználó, sem a tesztelő számára.
Memóriaszivárgás. A memóriaszivárgás-teszt megvizsgálja az alkalmazást, hogy észlelje azokat a helyzeteket, amikor az alkalmazás nem szabadítja fel a lefoglalt memóriát, ami gyenge teljesítményt vagy patthelyzetet eredményez. Ezt a technológiát egy alkalmazás verziójának tesztelésére és egy kész szoftvertermék tesztelésére is használják. Lehetőség van tesztelő eszközök használatára. Figyelemmel kísérhetik egy alkalmazás memóriahasználatát órákon vagy akár napokon keresztül, hogy megnézzék, a memóriahasználat tovább növekszik-e. Segítségükkel azonosíthatja azokat a programutasításokat is, amelyek nem szabadítanak fel lefoglalt memóriát.
Átfogó tesztelés. Az átfogó tesztelés célja annak ellenőrzése, hogy egy szoftvertermék minden modulja megfelelően illeszkedik-e a termék többi moduljához. Az átfogó tesztelés során felülről lefelé és alulról felfelé irányuló feldolgozási technológiát alkalmazhatunk, amelyben minden egyes modul, amely egy levél a rendszerfában, alacsonyabb vagy magasabb szinten integrálódik a következő modullal, amíg létre nem jön egy szoftvertermékfa. Ez a tesztelési technika nem csak a két komponens között átadott paraméterek tesztelését célozza, hanem a globális paramétereket is, és objektum-orientált alkalmazás esetén az összes legfelső szintű osztályt is.
Láncvizsgálat. A lánctesztelés egy szoftvertermék funkcióját alkotó modulok csoportjának tesztelését jelenti. Ezeket a tevékenységeket egységtesztelésnek is nevezik, és biztosítják a rendszerelemek megfelelő tesztelését. Ez a tesztelés meghatározza, hogy a modulok elég megbízhatóan működnek-e ahhoz, hogy egyetlen modult alkossanak, és hogy a szoftvertermék modulja pontos és következetes eredményeket ad-e.
Lefedettségkutatás. A bevonatvizsgáló eszköz kiválasztásakor fontos, hogy a tesztelő csapat elemezze az alkalmazáshoz szükséges bevonat típusát. A bevonatok kutatása különféle technológiák alkalmazásával végezhető. Az operátori lefedettség módszerét gyakran C1-nek nevezik, ami egyben csomóponti lefedettséget is jelent. Ezek a mérések jelzik, hogy minden végrehajtható utasítás ellenőrizve van-e. Ez a tesztelési módszer általában teljesítményprofilozó programot használ.
A megoldások lefedettsége. A döntési lefedettség módszerének célja, hogy meghatározza (százalékban) azon döntések összes lehetséges kimenetelét, amelyeket tesztelési eljárásokkal ellenőriztek. A megoldás-fedő módszert néha ágfedésnek is nevezik, és C2-nek nevezik. Megköveteli, hogy egy program minden be- és kilépési pontját legalább egyszer el lehessen érni, a programban lévő megoldások összes lehetséges feltételét legalább egyszer teszteljék, és a programban lévő minden megoldást legalább egyszer teszteljenek az összes lehetséges eredmény felhasználásával.
Lefedettség feltételei. A feltételek lefedettsége hasonló a döntési lefedettséghez. Célja, hogy ellenőrizze az egyes logikai kifejezések igaz vagy hamis eredményeinek pontosságát. Ez a módszer olyan teszteket tartalmaz, amelyek egymástól függetlenül tesztelik a kifejezéseket. E tesztek eredményei hasonlóak a döntési lefedettség módszerével kapottakhoz, azzal a különbséggel, hogy a döntési lefedettség módszere érzékenyebb a program vezérlési logikájára.
2.3 Fekete doboz módszer
A fekete doboz stratégián alapuló tesztelés csak akkor lehetséges, ha nyílt felületek, például felhasználói felület vagy alkalmazásprogramozási felület (API) telepítve vannak. Míg a fehérdobozos tesztelés egy program belső működését vizsgálja, addig a feketedobozos tesztelés egy alkalmazás viselkedését hasonlítja össze a követelményekkel. Ezenkívül ezek a módszerek általában három fő hibatípus azonosítására irányulnak: a szoftvertermék által támogatott funkcionalitás; elvégzett számítások; a szoftvertermék által feldolgozható adatértékek elfogadható tartománya vagy köre. Ezen a szinten a tesztelők nem a szoftvertermék-összetevők belső működését, hanem implicit módon tesztelik. A tesztelő csoport egy szoftvertermék bemeneti és kimeneti adatait vizsgálja. Ebből a szempontból a fekete doboz tesztelése a rendszerszintű tesztelés szinonimája, bár a fekete doboz technikák az egység- vagy alkatrészteszt során is használhatók.
A feketedobozos tesztelés során a felhasználói adatok fontosak, mert ők tudják a legjobban, mit várhatnak el az üzleti funkcióktól. A rendszertesztelés sikeres befejezésének kulcsa az adatok helyessége. Ezért a tesztelési adatgenerálási szakaszban kritikus fontosságú, hogy a végfelhasználók a lehető legtöbb inputot adják meg.
A fekete doboz tesztelés célja olyan bemeneti adatkészletek beszerzése, amelyek a legteljesebben tesztelik a rendszer összes funkcionális követelményét. Ez nem alternatíva a fehér dobozos teszteléshez. Az ilyen típusú tesztelés célja, hogy megtalálja azokat a hibákat, amelyek számos kategóriába sorolhatók, beleértve:
Hibás vagy hiányzó funkció
Interfész hibák
Használhatósági problémák
Tesztelési módszerek alapú automatizált eszközök
Hibák az adatstruktúrákban vagy hibák a külső adatbázisokhoz való hozzáférés során
Teljesítményproblémák és egyéb teljesítménybeli hibák
Letöltési hibák
Többfelhasználós hibák
Inicializálási és befejezési hibák
Problémák a biztonsági másolatok karbantartásával és a munka visszaállításának lehetőségével
Biztonsági kérdések
Fekete doboz stratégián alapuló vizsgálati módszerek
Egyenértékű partíció. A bemeneti adatok teljes körű tesztelése általában nem kivitelezhető. Ezért a tesztelést a bemeneti adatok egy részhalmazával kell elvégezni.
A tartományon kívüli hibák tesztelésekor az egyenértékű osztályok három fő típusa létezik: tartományon belüli, tartományon kívüli és kötött. Jó gyakorlat olyan teszteljárások létrehozása, amelyek a plusz/mínusz egy él eseteket tesztelik, hogy elkerüljék az egy feletti vagy egy alatti hibák hiányát. A magasan strukturált ekvivalenciaosztályokat használó vizsgálati eljárások kidolgozása mellett a tesztelő csoportnak feltáró tesztelést is kell végeznie. A várt eredményeket produkáló vizsgálati eljárásokat érvényes teszteknek nevezzük. A vizsgálati eljárásokat, amelyek végrehajtása hibához kell vezetnie, helytelen teszteknek nevezzük.
Ok-okozati diagramok. Az ok-okozati diagram egy olyan technika, amely világos megértést biztosít a logikai feltételekről és a megfelelő cselekvésekről. A módszer négy szakaszból áll. Első lépésként össze kell állítani egy listát az okokról (bemeneti feltételek) és a következményekről (műveletek) a modulra vonatkozóan, és minden modulhoz hozzá kell rendelni egy azonosítót. A második szakaszban egy ok-okozati diagramot dolgoznak ki. A harmadik lépésben a diagram döntési táblázattá alakul. A negyedik lépés az ok és okozat megállapítása a jellemző specifikációjának elolvasásával. Minden ok és okozat saját azonosítóval rendelkezik. Az okok a papírlap bal oldalán található oszlopban, a következmények pedig a jobb oldalon találhatók. Ezután az okokat és a következményeket vonalakkal kötik össze, így a köztük lévő megfelelés tükröződik. A diagram logikai kifejezéseket tartalmaz, amelyek két vagy több okot kombinálnak egy hatáshoz. Ezután a döntési táblázat szabályait teszteljárásokká alakítjuk.
Rendszertesztelés. A "rendszertesztelés" kifejezést gyakran a "fekete doboz tesztelés" szinonimájaként használják, mivel a rendszertesztelés során a tesztelő csapat elsősorban az alkalmazás "külső viselkedését" vizsgálja. A rendszertesztelés számos altípust tartalmaz, beleértve a funkcionális, regressziós, biztonsági, torlódási, teljesítmény-, használhatósági, véletlenszerű, adatintegritási, adatkonverziós, biztonsági mentési megőrzési és helyreállíthatósági, működési készenléti, elfogadási teszteket és alfa/béta tesztelést.
Funkcionális tesztelés. A funkcionális tesztelés megvizsgálja a rendszeralkalmazást a funkcionális követelményekhez képest, hogy észlelje a végfelhasználói követelményeknek való meg nem felelést. A legtöbb szoftvertermék-tesztelő program esetében ez a tesztelési módszer a fő. Fő feladata annak értékelése, hogy az alkalmazás a követelményeknek megfelelően működik-e.
Regressziós teszt. A tesztelés lényege a hibák felderítése, dokumentálása és nyomon követése a javításig. A tesztelőnek biztosnak kell lennie abban, hogy a talált hibák kiküszöbölésére tett intézkedések nem hoznak létre új hibákat a rendszer más területein. A regressziós tesztelés lehetővé teszi annak kiderítését, hogy a már felfedezett hibák kiküszöbölése következtében nem jelentek-e fel hibák. A regressziós tesztelésnél az automatizált tesztelőeszközök használata adja a legnagyobb megtérülést. Az összes korábban létrehozott szkript újra felhasználható annak ellenőrzésére, hogy a hibajavítás érdekében végrehajtott változtatások következtében nem keletkeztek-e új hibák. Ez a cél könnyen elérhető, mert a szkriptek manuális beavatkozás nélkül is végrehajthatók, és annyiszor használhatók, ahányszor szükséges a hibák észlelésére.
Biztonsági tesztelés. A biztonsági tesztelés magában foglalja a rendszer és az adatelérési mechanizmusok működésének ellenőrzését. Ehhez olyan teszteljárásokat dolgoznak ki, amelyek megpróbálják leküzdeni a rendszer védelmét. A tesztelő ellenőrzi a biztonsági és hozzáférési korlátozásokat, hogy biztosítsa a megállapított biztonsági követelményeknek és az összes vonatkozó rendszerbiztonsági előírásnak való megfelelést.
Túlterhelési tesztelés. A túlterhelési tesztelés az építészeti korlátok figyelembevétele nélkül teszteli a rendszert, hogy azonosítsa a rendszer műszaki korlátait. Ezeket a teszteket a tranzakciófeldolgozás csúcspontján hajtják végre, és amikor nagy mennyiségű adatot töltenek be folyamatosan. A túlterhelési tesztelés méri a rendszer teljesítményét és rugalmasságát minden hardverplatformon. Ez a módszer azt jelenti, hogy sok felhasználó egyszerre ér el bizonyos rendszerfunkciókat, és néhányan a normál tartományon kívüli értékeket adnak meg. A rendszernek hatalmas mennyiségű adatot kell feldolgoznia, vagy nagyszámú funkcionális kérést kell végrehajtania rövid időn belül.
Teljesítményfelmérés. A teljesítménytesztek ellenőrzik, hogy egy rendszeralkalmazás megfelel-e a teljesítménykövetelményeknek. A teljesítményteszt segítségével mérheti és jelentést készíthet azokról a mérőszámokról, mint például a bemeneti és kimeneti adatátviteli sebesség, a bemeneti és kimeneti műveletek teljes száma, az adatbázis által a lekérdezések megválaszolásához szükséges átlagos idő és a CPU-használat. Általában a teljesítménytesztben használt automatizált teljesítményteszt ugyanazokat az eszközöket használja, mint a túlterhelési tesztelés.
Használhatósági tesztelés. A használhatósági tesztek célja annak biztosítása, hogy a rendszer könnyen használható legyen, és a felhasználói felület vonzó megjelenésű legyen. Az ilyen tesztek figyelembe veszik a rendszer működésében az emberi tényezőt. A tesztelőnek a végfelhasználó szemszögéből kell értékelnie az alkalmazást.
2.4 Szoftver hibakeresési módszerek
szoftvertesztelés hibakeresés
A program hibakeresése valamilyen módon figyelembe veszi és logikusan dönti el a rendelkezésre álló hibainformációkat. A legtöbb hiba közvetetten felismerhető a programszövegek és a teszteredmények alapos elemzésével, további információ nélkül. Tehát használjon különböző módszereket:
Kézi tesztelés;
Hanyatlás;
Visszakövetés.
Kézi tesztelési módszer.
Ez a csoport legegyszerűbb és legtermészetesebb módszere. Hibafelismerésnél a tesztelt programot manuálisan, telefonos teszttel kell végrehajtani, azzal a munkával, amellyel a hibát észlelték. A módszer nagyon hatékony, de nem alkalmazható nagy műsorszámoknál, nehéz számítású műsoroknál, illetve amikor a hiba a televíziós produkciós cég tévhitével párosul egyes műveletek végrehajtásáról. Ezt a módszert gyakran használják más hibaelhárítási módszerek összetevőjeként.
Prológus módszer.
A módszer a Hiba tüneteinek gondos elemzésén alapul, amely hibás számítási eredményként vagy hibaüzenetként jelenhet meg. Ha a számítógép egyszerűen lefagy, a kijelző Hibák egy töredéke kiszámításra kerül, az utolsó kapott eredmények eredete és a felhasználói mozgások. Az így megszerzett információ rendszerezi és gondosan tanulja meg a program megfelelő részletét. E hipotézisek eredményeként a hibákkal kapcsolatos mozgások javulnak, és mindegyiket teszteljük. Ha a hipotézis igaz, részletezze a hibákkal kapcsolatos információkat, ellenkező esetben frissítse a másik hipotézist.
A legfontosabb lépés a hibatünetek szövegének megfogalmazása. Az Errors rendszerezés során minden arra van lehetőség, hogy rögzítsük a megjelenítéseiről ismert adatokat, és rögzítsük mind a helyeket, ahol a hibás töredék jellemzően végrehajtódik, és azokat a helyeket, ahol a hiba megjelenik. Ha ennek tanulmányozása eredményeként nem merülnek fel hipotézisek, további információkra van szükség a hibákról. További információk nyerhetők például hasonló tesztek elvégzéséből. A bizonyítási kísérlet során egyértelmű, hogy egy adott hipotézis minden hibakijelzést magyaráz-e, ha nem az összeset, vagy a hipotézis nem igaz, vagy hibák vannak.
Redukciós módszer.
A redukciós módszerről az elején található azon okok formája, amelyek ezt a hibát okozhatják. Ekkor szakad meg az okok elemzése, amely ellentmond a rendelkezésre álló adatoknak. Ha minden okot megszüntetünk, a vizsgált fragmentum további vizsgálatát kell végezni. Ellenkező esetben a legvalószínűbb próbálkozás a hipotézis bizonyítása. Ha a hipotézis megmagyarázza a kapott hibajeleket, akkor a hiba megtalálható, ellenkező esetben a következő ok kerül ellenőrzésre.
Visszakövetési módszer.
Kisebb programok esetén a visszakövetési módszer a hatékony. Kezdje onnan, ahol rossz eredményt ad ki. Ezen a ponton egy hipotézis dolgozik azon fő változók értékeivel kapcsolatban, amelyek elérhető eredményhez vezethetnek. Ezután, ennek a hipotézisnek az eredete, tegyen javaslatokat az előző pontban szereplő változók értékére. A folyamat folytatódik, továbbra sem derül ki a hiba okáról.
Következtetés
Nincsenek programok hiba nélkül. A szerkesztőben a parancsok helytelen bevitelével, az azonosítók helytelen rögzítésével kapcsolatos hibák szinte mindig lehetségesek, ez a kezdeti szöveg egyszerű tanulmányozásával kideríthető, és a platform fordítója javítja ki, amelyre a program íródott. Általában a hagyományoknak megfelelően a televíziós produkciós társaságok egy próbálkozási módszert alkalmaznak – megpróbálják megnézni, hogy a program működni fog-e ezen vagy azon a változtatáson, amit általában hibaelhárításnak neveznek.
Egyes eszközöket a horgok programozásában, tesztelésében és hibaelhárításában vettek részt, olcsóbban. Ezért foglalkozni kell a televíziós produkciós társaságok különféle előnyeivel, lehetővé téve a szoftver teljesítményének javítását és a hibák mielőbbi megnyitását, és a professzionális TV-gyártó cégek követik el a legtöbb hibát, mind a projekt szakaszában. és a programkódban. Elég gyakran egy hiba következmények lavinához vezet, megnehezítve a televíziós műsorgyártó cég munkáját, ami az összes kód felülvizsgálatához vezet a kezdeti szakaszban. Erre a célra a televíziós produkciós cég maga készít egy programot, amely teszteli a szoftvert, vagy már használja a rendelkezésre álló tesztelő szoftvercsomagokat.
A tesztelésben azonban a főszerep a televíziós produkciós cégé, amely a műsorkód teljesítményét és a töréspontok előfordulását figyeli. A televíziós műsorgyártó cégnek ettől függetlenül rögzítenie kell a hibákat, csak az szükséges, hogy a hibakereső program elinduljon. A fejlesztői környezet csak ezután tudja nyomon követni a program teljesítményét és a különböző változók értékeinek változásait. Korábban a nagy számítógépek a rendkívül merev RAM-igények és a gyenge számítási erőforrások miatt csak a protokollok prológján alapuló hibaelhárítási technikát alkalmaztak.
Ennek eredetét a tévégyártó cég be tudja azonosítani a hibát, hogy gyorsan kiderítse, ez a hibát okozó rutin ismeretében nem lehetséges. A régebbi programozási nyelvek páros számú speciális üzemeltető céggel rendelkeztek a legitim információk kiadására. Azonban a kezdeti szöveg egyszerű beolvasása a leghatékonyabb a hibák megtalálásában. Bizonyos esetekben a szoftverfejlesztők rajtakapják a nyers programok, az úgynevezett teszteletlen programok kiadását. Az ilyen programokat fogadó fogyasztó vagy eszköz saját felelősségére használja azokat. Súlyos hibaüzenetek, amelyekben a fordító által generált objektumkód természetesen hibás és további felhasználása lehetetlen.
Minden televíziós produkciós cég tudja, mennyi az idő, és lapokat tologat a programok hibaelhárítása és tesztelése során. Ebben a szakaszban a teljes programozási költség körülbelül 50%-ára van szükség. Nem minden szoftverfejlesztő tudja igazán meghatározni a tesztelés célját. Elég gyakran lehet hallani, hogy a tesztelés a program teljesítményének folyamata, azzal a céllal, hogy hibákat rakjanak ki benne. De ez a cél elérhetetlen: a legalaposabb tesztelés nem garantálja, hogy a program nem tartalmaz hibákat.
Az egyes tesztek eredményeinek vizsgálatakor ellenőrizni kell, hogy a program azt csinálja-e, amit nem szabad. Nem a tesztelés lehet az elszállásolás tervezett eredete, amely a program hibáiban (különösen a teszteléshez megfelelő idő- és tulajdonság kiválasztása szükséges) nem kerül felismerésre. El kell kerülni, hogy egy műsort szerzője teszteljen, mivel a televíziós műsorgyártó cégeknél a tesztelés már jelzett objektív nehézsége mellett ott van az is, hogy a cselekvés hiánya szövegének megfogalmazása ellentétben az emberi pszichológiával (a program hibakeresését azonban a program szerzője végzi a leghatékonyabban). Mindig emlékezni kell arra, hogy teszteléskor - a kreatív folyamat, ahelyett, hogy megérintené ezt a szabványos elhelyezés tekintetében.
Szójegyzék
Sz. Fogalom Definíció 1 A szoftvertesztelés a szoftver elemzésének vagy működtetésének folyamata a hibák azonosítása érdekében 2 A hibakeresés a hibaforrások azonosításának folyamata, pl. hibák, és megfelelő korrekciók bevezetése a programba 3 Alulról felfelé irányuló tesztelés A tesztelés alulról felfelé történik 4 Felülről lefelé tesztelés A tesztelés felülről lefelé történik 5 A fehér dobozos tesztelés olyan tesztesetek fejlesztése, amelyek bármilyen rendelkezésre álló információt felhasználnak a belső struktúráról vagy kódról 6 A fekete doboz tesztelés tesztesetek kidolgozása kialakult nyílt interfészek jelenlétében 7 A szendvics módszer nagy programok, például operációs rendszer vagy alkalmazáscsomag integrálásának megközelítése 8 Az egységtesztelés a a program forráskódjának egyes moduljainak tesztelésének folyamata a helyesség szempontjából 9 A biztonsági tesztelés a rendszer és az adatelérési mechanizmusok működésének tesztelése 10 A teljesítményteszt azt vizsgálja, hogy egy rendszeralkalmazás megfelel-e a teljesítménykövetelményeknek A felhasznált források listája
1.Beizer B. Fekete doboz tesztelése. Technológiák szoftverek és rendszerek funkcionális teszteléséhez [szöveg] / B. Beizer; - Péter, 2004, 320 p. ISBN 5-94723-698-2. 2.Braude E.D. Szoftverfejlesztési technológia [szöveg] / E.D. Braude; - Péter, 2004, 656 p. ISBN 5-94723-663-X. .Vinnichenko I.V. Tesztelési folyamatok automatizálása [szöveg] / I. V. Vinnichenko; - Péter, 2005, 208 p. ISBN 5-469-00798-7. .Kaner S. Szoftvertesztelés. Az üzleti alkalmazások kezelésének alapfogalmai [szöveg] / S. Kaner; - DiaSoft, 2001, 544 o., ISBN 966-7393-87-9. .Culbertson R. Gyorstesztelés [szöveg] / R. Culbertson, K. Brown, G. Cobb; - Williams, 2002, 384. o. ISBN 5-8459-0336-X. .Kolikova T.V. A szoftvertesztelés alapjai. Tankönyv [szöveg] / T.V. Kolikova, V.P. Kotljarov; - Intuit, 2006, - 285 p. ISBN 5-85582-186-2. .Kaspersky K. Technika programok hibakereséséhez forrásszöveg nélkül [szöveg] / K. Kaspersky; - BHV-Petersburg, 2005, 832 p. ISBN 5-94157-229-8. .McGregor D. Objektumorientált szoftver tesztelése. Gyakorlati útmutató [szöveg] / D. McGregor, D. Sykes; - TID „DS”, 2004, 432. o. ISBN 966-7992-12-8. .Plaksin M. Programok tesztelése és hibakeresése - jövőbeli és jelenlegi szakemberek számára [szöveg] / M. Plaskin; - Binom. Tudáslaboratórium, 2007, - 168 p. ISBN 978-5-94774-458-3. .Robert M. Gyors programfejlesztés: alapelvek, példák, gyakorlat [szöveg] / M. Robert, D. Newkirk; - Williams, 2004, 752. o. ISBN 5-8459-0558-3. .Folk D. Szoftvertesztelés [szöveg] / D. Folk, E. K. Nguyen, S. Kaner; - Diasoft, 2003, 400 p. ISBN 966-7393-87-9. .Elfrid D. Automatizált szoftverteszt. Megvalósítás, irányítás és üzemeltetés [szöveg] / Elfrid D., Jeff R., John P. - Laurie, 2003, ISBN 5-85582-186-2. Rövidítések listája tesztelés - szoftvertesztelés - folyamattesztelés - statikus tesztelés ellenőrzése - táblaellenőrző tesztelés - dinamikus tesztelés - hibaleállás - felülről lefelé - alkalmazásprogramozási felület eggrog returns - error returnbox - átlátszó doboz - átlátszó tesztelés
OKTATÁSI ÉS TUDOMÁNYOS MINISZTÉRIUM
OROSZ FÖDERÁCIÓ
SZÖVETSÉGI OKTATÁSI ÜGYNÖKSÉG
ÁLLAMI OKTATÁSI INTÉZMÉNY
SZAKMAI FELSŐOKTATÁS
TYUMEN ÁLLAMI EGYETEM
Matematikai és Számítástechnikai Intézet
Matematika és Informatika Tanszék
Tanfolyami munka
Szakág: „A programozás alapjai”
A programfejlesztés szakaszai. Tesztelés és hibakeresés. Dokumentáló programok
Bevezetés
1. fejezet A programfejlesztés szakaszai
1.1 Problémafelvetés
1.1.1 A fizikai probléma megfogalmazása és elemzése
1.1.2. Matematikai modell készítése
1.2 Program készítése
1.3 A program dokumentálása
1.3.1 A program felhasználói dokumentációja
1.3.2 A program támogatásának dokumentációja
1.4 A kész program indítása és a kapott eredmények elemzése
Az elektronikus számítógépek és a modern információfeldolgozási és -továbbítási eszközök bevezetése egy új folyamat kezdetét jelentette, amelyet a társadalom informatizálódásának neveznek. A tudományos és technológiai fejlődés széles körben elterjedt. Jelenleg a tudományos és technológiai haladás egyik iránya az emberi tevékenység szinte minden területének számítógépesítése.
Manapság a számítógép az emberek munkájának szerves része. A számítógépeket iskolákban és egyetemeken használják. Segítik a kapott adatok rendszerezését, munkavégzési és oktatási célból egyaránt. De egyetlen számítógép sem nélkülözheti programok és szoftverek.
Ennek a kurzusnak az a célja, hogy megvizsgáljon egy olyan témát, amely nem lényegtelen a kezdő programozók számára – „A program létrehozásának szakaszai”. Az elméleti készségek gyakorlati alkalmazását egy szoftveralkalmazás - a "Hangman" - játék megírása során tesztelték. Ami ennek a tanfolyamnak a célja is lett.
A programfejlesztés nem csak programírásból áll. A program megírása az egyik szakasz. Kezdetben felsoroljuk a programfejlesztés összes szakaszát, majd részletesen beszélünk róluk.
A program kidolgozásának szakaszai:
1. A probléma megfogalmazása
1. A fizikai probléma megfogalmazása és elemzése
2. Matematikai modell készítése
3. Algoritmus készítése a feladatra
2. Program készítése
1. A program szövegének összeállítása
2. Programszöveg bevitele a számítógépbe
3. A program szintaktikai hibakeresése
4. Tesztelés és szemantikai hibakeresés
5. A program dokumentálása
3. Az elkészült program indítása és a kapott eredmények elemzése
Nézzük meg részletesen az egyes szakaszokat.
1.1 Problémafelvetés
Az első szakasz a probléma részekre bontása a programírás egyszerűsítése érdekében. Matematikai szakasznak is nevezik.
1.1.1 A fizikai probléma megfogalmazása és elemzése
Probléma megfogalmazása– éppen ez a bejelentése, a produkciója.
De csak a megfogalmazás nem segít a programozóknak. Ezért van egy második részszakasz – a feladatelemzés.
Feladatelemzés a feladat részletes áttekintése a bemeneti és kimeneti információk meghatározásával és azonosításával. ( Adja meg a feladathoz szükséges információkat- ez az az adat, amely beírja a probléma bemenetét és annak megoldására szolgál. Kimeneti információ- ez az eredmény.)
A feladat elemzése után a programozó többé-kevésbé megérti, milyen problémákkal kell szembenéznie.
1.1.2 Matematikai modell készítése
Kezdjük újra a meghatározással. A világosabb megértés érdekében nézzük meg a matematikai modell különböző (matematikai, fizikai, gazdasági stb.) forrásokban deklarált definícióit, és próbáljuk meg megalkotni saját, programozásra alkalmas definíciónkat.
« Matematikai modell- egy objektum adott jelenségének vagy viselkedésének leírására és előrejelzésére szolgáló egyenlet- és fogalomrendszer. A matematikai modelleknek gyakorlati és elméleti alkalmazásuk is van (néha egyidejűleg). A matematikai modellek gyakorlati problémái közé tartozik az új anyagok létrehozása, az időjárás előrejelzése, a hidak, repülőgépek és hasonlók szilárdságának tesztelése” – ezt a meghatározást használják a fizikában, a kémiában és a matematikai biológiában.
« Matematikai modell a valóság leegyszerűsített leírása matematikai fogalmak segítségével. A matematikai modellekkel kapcsolatos problémáknak két fő osztálya van: direkt és inverz. Az első esetben a modell összes paraméterét ismertnek tekintjük, és csak a viselkedését tudjuk tanulmányozni. A másodikban pedig a modell néhány paramétere ismeretlen, és ezeket úgy kell megtalálni, hogy összehasonlítjuk a valós rendszer viselkedését a modelljével.” - ezt a meghatározást főleg a közgazdaságtanban használják.
« Matematikai modell„a valóság matematikai ábrázolása” – ez a matematikusok által alkotott meghatározás.
Következtetéseket vonunk le: matematikai modell a programozásban matematikai összefüggésrendszer, amely megközelítőleg tükrözi a megfogalmazott problémát. És lehetővé teszi az optimális megoldások előzetes kiválasztását bizonyos kritériumok szerint.
Egy matematikai modell elkészítése nem fog sok időt igénybe venni, mert részletesen kellett elemeznünk a problémát az előző bekezdés szerint.
1.1.3 Algoritmus készítése a problémára
Kezdetben az algoritmus megjelenése a matematika megjelenéséhez kapcsolódik. Az algoritmus egy cselekvéssorozat (terv) leírása, amelynek szigorú végrehajtása egy adott probléma véges számú lépésben történő megoldásához vezet.
Az algoritmusnak 2 kötelező feltétele van:
· Az algoritmust a kidolgozó számára érthető formában kell bemutatni.
· Az algoritmust az algoritmusban leírt műveleteket végrehajtó objektum (beleértve a személyt is) számára érthető formában kell bemutatni.
Az algoritmusok a következő tulajdonságokkal is rendelkeznek:
1. Diszkrétség, azaz az algoritmusnak meghatározott sorrendben következő konkrét cselekvésekből kell állnia.
2. A determinizmust, azaz minden cselekvést minden esetben szigorúan és egyértelműen meg kell határozni.
3. Végesség, azaz minden műveletnek és az algoritmus egészének teljesíthetőnek kell lennie.
4. Masszív, azaz ugyanaz az algoritmus használható különböző forrásadatokkal.
5. Hatékonyság, azaz a hibák hiánya, az algoritmusnak minden érvényes bemeneti értéknél a helyes eredményre kell vezetnie.
A világon többféle algoritmus létezik:
· Lineáris algoritmus (egy adott sorrendben egyszer végrehajtott műveletek leírása);
· Ciklikus algoritmus (a műveletek leírása, amelyeket meghatározott számú alkalommal vagy egy feltétel teljesüléséig meg kell ismételni);
· Elágazó algoritmus (olyan algoritmus, amelyben a feltételtől függően egy vagy másik műveletsort hajtanak végre);
1.2 Program készítése
A programkészítés, vagy inkább a szoftverfejlesztés folyamata a programkészítés második szakasza.
1.2.1 Programszöveg összeállítása
Talán ez a legnehezebb a szakaszok közül, és a legtöbb odafigyelést igényli. Lényegében a programszöveg összeállítása egy feladat-algoritmus rögzítését jelenti valamelyik programozási nyelv használatával. Annak érdekében, hogy a szöveg érthető legyen a felhasználó és a fordító számára, megjegyzéseket használunk.
1.2.2 A program szintaktikai hibakeresése
A program hibakeresése- ez a programfejlesztés egy speciális szakasza, amely a már megállapított szoftverhibák azonosításából és kiküszöböléséből áll.
Szintaxis hibakeresés– szintaktikai hibák keresése a programszövegben. A hiba észlelése után a fordító egy üzenetet jelenít meg, amely jelzi a hiba helyét és természetét a programban. Miután megkapta az ilyen üzenetet, a programozónak ki kell javítania a hibát, és meg kell ismételnie az adást. Ez addig folytatódik, amíg az összes szintaktikai hibát ki nem javítják.
Ha szintaktikai hibával találkozik, gyakran megoldhatja a problémát a súgórendszer használatával, ahol további információkhoz juthat a hibáról, és javíthatja a hibát, ha fokozott figyelmet fordít a függvények, objektumok, metódusok, ill. használt tulajdonságok.
1.2.3 Tesztelés és szemantikai hibakeresés
A tesztelés egy program dinamikus vezérlése, pl. a program helyességének ellenőrzése, amikor a számítógépen fut.