20. Ellenőrzés és minősítés szoftver
Az ellenőrzés és érvényesítés azokra az ellenőrzési és felülvizsgálati folyamatokra vonatkozik, amelyek ellenőrzik, hogy a szoftver megfelel-e a specifikációinak és az ügyfél követelményeinek. Az ellenőrzés és minősítés a teljességre kiterjed életciklus Szoftver - a követelmények elemzésének szakaszában kezdődnek, és a programkód ellenőrzésével zárulnak a kész szoftverrendszer tesztelésének szakaszában.
Az igazolás és a tanúsítás nem ugyanaz, bár könnyen összetéveszthető. Röviden, a köztük lévő különbséget a következőképpen határozhatjuk meg:
Az ellenőrzés választ ad arra a kérdésre, hogy a rendszer megfelelően van-e kialakítva;
A tanúsítás választ ad arra a kérdésre, hogy a rendszer megfelelően működik-e.
E meghatározások szerint az ellenőrzés azt ellenőrzi, hogy a szoftver megfelel-e a rendszerspecifikációnak, különösen a funkcionális és nem funkcionális követelményeknek. Minősítés – több általános folyamat. Az érvényesítés során meg kell győződnie arról, hogy a szoftvertermék megfelel az ügyfél elvárásainak. A hitelesítés az ellenőrzést követően történik annak megállapítására, hogy a rendszer nem csak a specifikációnak, hanem a vevő elvárásainak is megfelel.
Mint korábban említettük, a rendszerkövetelmények érvényesítése nagyon fontos a szoftverfejlesztés korai szakaszában. A követelményekben gyakran előfordulnak hibák és hiányosságok; ilyen esetekben a végtermék valószínűleg nem fog megfelelni a vevő elvárásainak. De természetesen a követelmények érvényesítése nem fedheti fel a követelményspecifikáció összes problémáját. Néha a követelmények hiányosságait és hibáit csak a rendszer megvalósítása után fedezik fel.
Az ellenőrzési és érvényesítési folyamatok két fő technikát használnak a rendszerek ellenőrzésére és elemzésére.
1. Szoftver ellenőrzés. A rendszer különféle reprezentációinak elemzése és ellenőrzése, mint például a követelményspecifikációs dokumentáció, az építészeti diagramok vagy a program forráskódja. Az ellenőrzés a szoftverrendszer fejlesztési folyamatának minden szakaszában megtörténik. Az ellenőrzéssel párhuzamosan elvégezhető a programok és a kapcsolódó dokumentumok forráskódjának automatikus elemzése. Az ellenőrzés és az automatizált elemzés statikus ellenőrzési és érvényesítési módszerek, mivel nem igényelnek végrehajtható rendszert.
2. Szoftver tesztelés. Futtatható kód futtatása tesztadatokkal, valamint a kimenet és a teljesítmény vizsgálata szoftver termék hogy ellenőrizze a rendszer megfelelő működését. A tesztelés dinamikus ellenőrzési és érvényesítési módszer, mivel a futó rendszerre alkalmazzák.
ábrán. A 20.1. ábra mutatja az ellenőrzés és tesztelés helyét a szoftverfejlesztési folyamatban. A nyilak jelzik a fejlesztési folyamat azon szakaszait, ahol ezek a módszerek alkalmazhatók. E séma szerint az ellenőrzés a rendszerfejlesztési folyamat minden szakaszában elvégezhető, a tesztelés pedig - prototípus vagy végrehajtható program elkészítésekor.
Az ellenőrzési módszerek a következők: programellenőrzés, automatikus forráskód-elemzés és formális ellenőrzés. A statikus módszerek azonban csak a programok specifikációnak való megfelelőségét tudják ellenőrizni, a rendszer megfelelő működését nem. Ezenkívül az olyan nem funkcionális jellemzők, mint a teljesítmény és a megbízhatóság, nem tesztelhetők statikus módszerekkel. Ezért a nem funkcionális jellemzők értékelésére rendszertesztet végeznek.
Rizs. 20.1. Statikus és dinamikus ellenőrzés és tanúsítás
A szoftverellenőrzés széles körben elterjedt alkalmazása ellenére a tesztelés még mindig az uralkodó igazolási és tanúsítási módszer. A tesztelés a programok működésének ellenőrzése a valóshoz hasonló adatokkal, amelyek a rendszer működése során kerülnek feldolgozásra. A programban a hibák és a követelményekkel való inkonzisztenciák jelenléte a kimeneti adatok vizsgálatával és az anomáliák azonosításával észlelhető. A tesztelés a rendszer bevezetési szakaszában (annak ellenőrzésére, hogy a rendszer megfelel-e a fejlesztők elvárásainak) és a megvalósítás befejezése után történik.
A szoftverfejlesztési folyamat különböző szakaszaiban különböző típusú teszteléseket alkalmaznak.
1. Hibavizsgálat a program és annak specifikációi közötti, a programok hibáiból vagy hibáiból eredő inkonzisztenciák észlelésére szolgál. Az ilyen tesztek célja a rendszer hibáinak észlelése, nem pedig a működés szimulálása.
2. Statisztikai tesztelésértékeli a programok teljesítményét, megbízhatóságát, valamint a rendszer működését különböző üzemmódokban. A teszteket úgy tervezték, hogy valós bemeneti adatokkal utánozzák a rendszer tényleges működését. A rendszer megbízhatóságát a programok munkájában észlelt hibák száma határozza meg. A teljesítmény értékelése a teljes működési idő és a rendszer válaszidejének mérésével történik a tesztadatok feldolgozásakor.
Az ellenőrzés és minősítés fő célja annak biztosítása, hogy a rendszer „megfelel a célnak”. Egy szoftverrendszer rendeltetésszerű alkalmassága nem jelenti azt, hogy teljesen hibamentesnek kell lennie. Inkább a rendszernek ésszerűen jól illeszkednie kell azokhoz a célokhoz, amelyekre szánták. Kívánt megfelelőség érvényessége függ a rendszer céljától, a felhasználói elvárásoktól és a szoftvertermékekre vonatkozó piaci feltételektől.
1. A szoftver célja. A megfelelőségi megbízhatóság szintje attól függ, hogy bizonyos kritériumok szerint mennyire kritikus a kifejlesztett szoftver. Például a biztonság szempontjából kritikus rendszerek megbízhatósági szintjének lényegesen magasabbnak kell lennie, mint a prototípusok azonos megbízhatósági szintjének. szoftverrendszerek fejlesztés alatt áll néhány új ötlet bemutatására.
2. Felhasználói elvárások. Szomorúan kell megjegyezni, hogy jelenleg a legtöbb felhasználó alacsony követelményeket támaszt a szoftverekkel szemben. A felhasználók annyira hozzászoktak a programok futása közben fellépő hibákhoz, hogy ezen nem lepődnek meg. Hajlandóak elviselni a rendszerhibákat, ha a használat előnyei meghaladják a hátrányokat. Az 1990-es évek eleje óta azonban a felhasználók toleranciája a szoftverrendszerek hibáival szemben fokozatosan csökken. Az utóbbi időben szinte elfogadhatatlanná vált a megbízhatatlan rendszerek létrehozása, ezért a szoftverfejlesztő cégeknek egyre nagyobb figyelmet kell fordítaniuk a szoftverek ellenőrzésére és validálására.
3. Szoftverpiaci feltételek. A szoftverrendszer értékelésekor az eladónak ismernie kell a versengő rendszereket, azt az árat, amelyet a vevő hajlandó fizetni a rendszerért, és a rendszer várható piaci bevezetési idejét. Ha a fejlesztő cégnek több versenytársa van, akkor a teljes tesztelés és hibakeresés befejezése előtt meg kell határozni a rendszer piacra lépésének időpontját, ellenkező esetben a versenytársak léphetnek be elsőként a piacra. Ha az ügyfelek nem hajlandók magas áron szoftvert vásárolni, akkor hajlandóak lehetnek több rendszerhibát is elviselni. Az igazolási és minősítési folyamat költségeinek meghatározásakor mindezeket a tényezőket figyelembe kell venni.
Általános szabály, hogy az ellenőrzés és a tanúsítás során hibákat találnak a rendszerben. A hibák kijavítása érdekében változtatásokat hajtanak végre a rendszeren. Ez hibakeresési folyamat rendszerint más ellenőrzési és tanúsítási folyamatokkal integrálva. A tesztelés (vagy általánosabban az ellenőrzés és érvényesítés) és a hibakeresés azonban különböző folyamatok, amelyeknek más a célja.
1. Az ellenőrzés és érvényesítés a szoftverrendszer hibáinak észlelésének folyamata.
2. Hibakeresés - a hibák (hibák) lokalizálásának és kijavításának folyamata (20.2. ábra).
Rizs. 20.2. Hibakeresési folyamat
Nincsenek egyszerű módszerek a programok hibakeresésére. A tapasztalt hibakeresők úgy találják meg a hibákat, hogy összehasonlítják a tesztkimeneti mintákat a tesztelt rendszerek kimenetével. A hiba megtalálásához ismerni kell a hibatípusokat, a kimeneti mintákat, a programozási nyelvet és a programozási folyamatot. Nagyon fontos a szoftverfejlesztési folyamat ismerete. A hibakeresők tisztában vannak a leggyakoribb programozási hibákkal (például a számláló növelésével). Figyelembe veszi azokat a hibákat is, amelyek bizonyos programozási nyelvekre jellemzőek, például azokat, amelyek a C nyelvben a mutatók használatával kapcsolatosak.
A programkódban lévő hibák felkutatása nem mindig egyszerű folyamat, mivel a hiba nem feltétlenül található a programkód azon pontjának közelében, ahol az összeomlás bekövetkezett. A hibák elkülönítése érdekében a hibakereső további szoftverteszteket fejleszt ki, amelyek segítenek azonosítani a programhiba forrását. Lehet, hogy manuálisan kell nyomon követnie a program végrehajtását.
Az interaktív hibakereső eszközök a kódfordító rendszerbe integrált nyelvtámogatási eszközök készletének részét képezik. Speciális programvégrehajtási környezetet biztosítanak, amelyen keresztül elérheti az azonosítók táblázatát, és onnan a változók értékeit. A felhasználók gyakran lépésről lépésre irányítják a program végrehajtását, utasításról utasításra egymás után lépve. Az egyes utasítások végrehajtása után a változók értékeit ellenőrizzük, és azonosítjuk az esetleges hibákat.
A programban talált hiba kijavításra kerül, ezt követően ismételten ellenőrizni kell a programot. Ehhez újra ellenőrizheti a programot, vagy megismételheti az előző tesztet. Az újratesztelés arra szolgál, hogy a programon végrehajtott változtatások ne vezessenek be új hibákat a rendszerbe, mert a gyakorlatban a „hibajavítások” nagy százaléka vagy nem fejeződik be teljesen, vagy új hibákat vezet be a programba.
Elvileg minden javítás után újra le kell futtatni az összes tesztet, de a gyakorlatban ez a megközelítés túl drága. Ezért a tesztelési folyamat megtervezésekor meghatározzák a rendszer részei közötti függőséget, és minden részhez hozzárendelnek teszteket. Ezután lehetőség nyílik a programelemek nyomon követésére az ezekhez az elemekhez kiválasztott speciális tesztesetek (vezérlő adatok) segítségével. Ha a nyomkövetési eredményeket dokumentálják, akkor a teljes vizsgálati adathalmaznak csak egy részhalmaza használható a megváltozott programelem és a függő összetevők tesztelésére.
A kurzus célja, hogy átfogó képet adjon a szoftverellenőrzési folyamatról. A megbeszélés tárgya az verifikáció és különösen a szoftverteszt területén alkalmazott különféle megközelítések és módszerek. Feltételezhető, hogy a fejlesztés alatt álló szoftver egy nagyobb része közös rendszer. Egy ilyen rendszer hardver, információs és szervezeti (emberi felhasználó, emberi kezelő, stb.) komponenseket tartalmaz, amelyeket esetleg különböző csapatok fejlesztettek ki. Ezért olyan fejlesztési dokumentumokra van szükség, amelyek meghatározzák a rendszer különböző összetevőivel szemben támasztott követelményeket és azok interakciójának szabályait. Ezenkívül feltételezzük, hogy a rendszerhibák ilyen vagy olyan súlyos következményekkel járhatnak, ezért a szoftverfejlesztés során a rejtett hibák azonosítására fordított erőfeszítések szükségesek és indokoltak. Mindenekelőtt a szoftverellenőrzés eszközeire és eljárásaira vonatkozik. A kurzus egy sor gyakorlati gyakorlatot tartalmaz, amelyek a szoftverellenőrzés technikáit és módszereit mutatják be a Microsoft Visual Studio 2005 Team Edition for Software Testers környezetben egy egyszerű rendszer példaként. Ez a kiadvány a Curriculum Library része, amelyet az MSDN Academic Alliance (MSDN AA) Akadémiai Együttműködési Program fejleszt.
Az alábbi szöveget a rendszer automatikusan kivonja az eredeti PDF-dokumentumból, és csak előnézeti célokat szolgál.
A képek (képek, képletek, grafikonok) hiányoznak.
Rizs. 7 Tesztelés, ellenőrzés és érvényesítés A szoftverellenőrzés általánosabb fogalom, mint a tesztelés. A hitelesítés célja annak biztosítása, hogy az ellenőrzött objektum (követelmények vagy programkód) megfelel a követelményeknek, nem kívánt funkciók nélkül valósul meg, és megfelel a tervezési előírásoknak és szabványoknak. Az ellenőrzési folyamat magában foglalja az ellenőrzéseket, a kód tesztelését, a teszteredmények elemzését, a problémajelentések generálását és elemzését. Így általánosan elfogadott, hogy a tesztelési folyamat az szerves része ellenőrzési folyamat, ugyanez a feltételezés szerepel ebben az oktatóanyagban. A szoftverrendszer validálása egy olyan folyamat, amelynek célja annak bizonyítása, hogy a rendszer fejlesztése eredményeként elértük azokat a célokat, amelyeket a használattal elérni terveztünk. Más szóval a validáció annak ellenőrzése, hogy a rendszer megfelel-e az ügyfél elvárásainak. Az érvényesítéssel kapcsolatos kérdések kívül esnek ennek hatókörén képzésés külön érdekes tanulmányi témát jelentenek. Ha ezt a három folyamatot az általuk megválaszolt kérdés szempontjából nézzük, akkor a tesztelés a „Hogyan történik?” kérdésre válaszol. vagy „A kifejlesztett program viselkedése megfelel a követelményeknek?” Ellenőrzés - „Mi történt?” vagy „A kifejlesztett rendszer megfelel a követelményeknek?”, az érvényesítés pedig „Megtette, amit kell?” vagy „A kifejlesztett rendszer megfelel-e az ügyfél elvárásainak?”. 1.7. Az életciklus különböző szakaszaiban készített dokumentáció A fejlesztés minden szakaszának szinkronizálása az egyes szakaszokban keletkező dokumentumok segítségével történik. Ugyanakkor a dokumentáció mind az életciklus közvetlen szegmensében - egy szoftverrendszer fejlesztése során, mind pedig fordítva - annak ellenőrzése során készül. Próbáljuk meg egy V alakú életciklus példáján nyomon követni, hogy az egyes szegmenseken milyen típusú dokumentumok jönnek létre, és milyen kapcsolatok vannak közöttük (8. ábra). A rendszerkövetelmények fejlesztési szakaszának eredménye a rendszerre vonatkozó megfogalmazott követelmények - egy dokumentum, amely leírja a rendszer működésének általános elveit, interakcióját a rendszerrel. környezet» - a rendszer felhasználói, valamint a működését biztosító szoftverek és hardverek. Általában a rendszer követelményeivel párhuzamosan hitelesítési tervet készítenek, és meghatározzák a hitelesítési stratégiát. Ezek a dokumentumok általános megközelítést határoznak meg a tesztelés végrehajtására, milyen módszertanok alkalmazására, és a jövőbeli rendszer mely szempontjait kell szigorú tesztelésnek alávetni. A verifikációs stratégia meghatározásával megoldható másik feladat a különböző verifikációs folyamatok helyének és fejlesztési folyamatokkal való kapcsolatának meghatározása. 20 A rendszerkövetelményekkel működő ellenőrzési folyamat a követelmények érvényesítésének folyamata, összehasonlítva azokat a vevő valós elvárásaival. A jövőre nézve mondjuk el, hogy az érvényesítési folyamat eltér a kész rendszer ügyfélhez történő átadásakor végzett átvételi tesztektől, bár az ilyen tesztek részének tekinthető. A validáció nemcsak a rendszer megvalósításának a megrendelő szempontjából való helyességét, hanem a fejlesztés alapjául szolgáló elvek helyességét is bizonyítja. Rizs. 8 Szoftverrendszer-fejlesztési folyamatok és dokumentumok A rendszerkövetelmények képezik a funkcionális követelmények fejlesztési folyamatának és a projektarchitektúrának az alapját. Ennek során általános követelményeket dolgoznak ki a rendszer szoftverére, azokra a funkciókra, amelyeket el kell látnia. A funkcionális követelmények gyakran magukban foglalják a rendszer viselkedési mintáinak meghatározását a normál és vészhelyzetek , adatfeldolgozási szabályok és felhasználói felület definíciók. A követelmény szövege általában tartalmazza a „kell, kell” szavakat, és a következő alakú: „Ha az ABC érzékelő hőmérsékleti értéke eléri a 30 Celsius-fokot vagy többet, a rendszernek le kell állítania a hangjelzést. ” A funkcionális követelmények képezik a rendszerarchitektúra fejlesztésének alapját - felépítésének leírása az alrendszerek és a nyelv szerkezeti egységei szerint, amelyen a megvalósítás történik - területek, osztályok, modulok, funkciók stb. A funkcionális követelmények alapján tesztkövetelményeket írnak le - olyan dokumentumokat, amelyek a legfontosabb pontok meghatározását tartalmazzák, amelyeket ellenőrizni kell, hogy megbizonyosodjunk a funkcionális követelmények megfelelő végrehajtásáról. A tesztkövetelmények gyakran az „Ellenőrizze mit” szavakkal kezdődnek, és hivatkozásokat tartalmaznak a megfelelő funkcionális követelményekre. A fenti funkcionális követelményre vonatkozó tesztkövetelmények például a következők: „Győződjön meg arról, hogy ha az ABC érzékelő hőmérséklete 30 Celsius-fok alá csökken, a rendszer figyelmeztető hangot ad ki” és „Győződjön meg arról, hogy ha az ABC érzékelő hőmérséklete meghaladja a 30 Celsius fokot, a a rendszer nem sípol." 21 A tesztkövetelmények írásakor felmerülő problémák egyike egyes követelmények alapvető tesztelhetetlensége, például a „A felhasználói felületnek intuitívnak kell lennie” követelményt nem lehet tesztelni anélkül, hogy egyértelműen meghatároznánk, mi az intuitív interfész. Az ilyen nem specifikus funkcionális követelményeket általában utólag módosítják. A rendszer architekturális jellemzői forrásul is szolgálhatnak a rendszer szoftveres megvalósításának jellemzőit figyelembe vevő tesztkövetelmények elkészítéséhez. Ilyen követelmény például: "Ellenőrizze, hogy az ABC érzékelő hőmérsékleti értéke nem haladja meg a 255-öt". A funkcionális követelmények és az architektúra alapján megírják a rendszer programkódját, ennek ellenőrzésére a tesztkövetelmények alapján tesztterv készül - a rendszer megfelelőségét ellenőrző tesztesetek sorrendjének leírása. követelményeknek megfelelő rendszer bevezetése. Minden teszteset tartalmaz egy konkrét leírást a rendszernek bemenetként megadott értékekről, a kimenetként várt értékekről, valamint a teszt végrehajtási forgatókönyv leírását. A tesztelés tárgyától függően tesztterv készíthető akár programozási nyelvű programként, akár egy eszközkészlet bemeneti adatfájljaként, amely végrehajtja a tesztelt rendszert, és átadja neki a teszttervben megadott értékeket, vagy utasításként a felhasználó számára.rendszer, amely leírja a rendszer különféle funkcióinak teszteléséhez szükséges lépéseket. Az összes teszteset végrehajtása eredményeként statisztika gyűlik a teszt sikerességéről - azon tesztesetek százalékos arányáról, amelyeknél a valós kimeneti értékek egybeestek a várt értékekkel, az úgynevezett sikeres tesztek. A sikertelen tesztek a kezdeti adatok a hibák okainak elemzéséhez és azok későbbi kijavításához. Az integráció szakaszában az egyes rendszermodulokat egyetlen egésszé állítják össze, és teszteseteket hajtanak végre, amelyek a rendszer teljes funkcionalitását ellenőrzik. Az utolsó szakaszban a kész rendszert a vevőhöz szállítják. Megvalósítás előtt a megrendelő szakemberei a fejlesztőkkel közösen átvételi teszteket végeznek - egy előzetesen jóváhagyott tesztprogram szerint ellenőrzik a felhasználó számára kritikus funkciókat. A tesztek sikeres elvégzése után a rendszer átkerül az ügyfélhez, ellenkező esetben pedig felülvizsgálatra kerül. 1.8. A tesztelési és ellenőrzési folyamatok típusai és helyük a különböző életciklus-modellekben 1.8.1. Egységteszt A kis egységeket (eljárások, osztályok stb.) egységtesztnek vetik alá. Egy viszonylag kis, 100-1000 soros modul tesztelésekor ellenőrizhető, ha nem az összes, de legalább sok logikai ág a megvalósításban, az adatfüggőségi gráf különböző útvonalai, a paraméterek határértékei. Ennek megfelelően a teszt lefedettségi kritériumok felépítésre kerülnek (minden operátor, minden logikai ág, minden határpont, stb. lefedve). . Az egységtesztet általában minden függetlennél elvégzik szoftver modulés talán a legelterjedtebb tesztelési típus, különösen kis és közepes méretű rendszerek esetében. 1.8.2. Integrációs tesztelés Az összes modul helyességének ellenőrzése sajnos nem garantálja a modulrendszer megfelelő működését. A szakirodalom néha tárgyalja a modulrendszer tesztelésének helytelen megszervezésének „klasszikus” modelljét, amelyet gyakran „nagy ugrás” módszernek neveznek. A módszer lényege, hogy először minden modult külön-külön tesztelünk, majd rendszerré egyesítjük és a teljes rendszert teszteljük. Nagy rendszerek esetében ez irreális. Ezzel a megközelítéssel sok időt kell fordítani a hibahelyreállításra, és a tesztelés minősége alacsony marad. A "nagy ugrás" alternatívája az integrációs tesztelés, amikor a rendszer szakaszosan épül fel, a modulok csoportjai fokozatosan kerülnek hozzáadásra. 1.8.3. Rendszertesztelés A teljesen megvalósított szoftverterméket rendszertesztelésnek vetik alá. Ebben a szakaszban a tesztelőt nem az egyes eljárások és módszerek megvalósításának helyessége érdekli, hanem a teljes program egésze, ahogyan a végfelhasználó látja. A tesztek alapja az Általános követelmények a programhoz, beleértve nemcsak a funkciók megvalósításának helyességét, hanem a teljesítményt, a válaszidőt, a meghibásodásokkal, támadásokkal, felhasználói hibákkal szembeni ellenállást stb. A rendszer és komponens teszteléséhez meghatározott típusú tesztlefedettségi kritériumokat használnak (például minden tipikus munkaforgatókönyvet lefednek, minden rendellenes helyzetet tartalmazó forgatókönyvet, páros forgatókönyv-összetételt stb.). 1.8.4. Terhelési tesztelés A terheléses tesztelés nemcsak előrejelző adatokat szolgáltat a rendszer terhelés alatti teljesítményéről, ami az építészeti döntések meghozatalára irányul, hanem operatív információkat is nyújt a műszaki támogató csoportoknak, valamint a projekt- és konfigurációs menedzsereknek, akik a legproduktívabb megoldás létrehozásáért felelősek. hardver és szoftver konfigurációk. . A terhelési tesztelés lehetővé teszi a fejlesztőcsapat számára, hogy megalapozottabb döntéseket hozzon az optimális építészeti kompozíciók kidolgozása érdekében. Az ügyfél a maga részéről lehetőséget kap az átvételi tesztek lefolytatására a valósághoz közeli körülmények között. 1.8.5. Formális ellenőrzések A formális ellenőrzés a szoftverfejlesztési folyamat során létrehozott dokumentumok és programkódok ellenőrzésének egyik módja. A formai ellenőrzés során egy szakembercsoport önállóan ellenőrzi az ellenőrzött dokumentumok eredeti okmányoknak való megfelelőségét. Az ellenőrzés függetlenségét biztosítja, hogy azt olyan ellenőrök végzik, akik nem vettek részt a vizsgált dokumentum kidolgozásában. 1.9. A tanúsított szoftver ellenőrzése Adjunk néhány definíciót, amelyek meghatározzák átfogó szerkezet szoftvertanúsítási folyamat: A szoftvertanúsítás az a folyamat, amelynek során megállapítják és hivatalosan elismerik, hogy a szoftverfejlesztés bizonyos követelményeknek megfelelően történt. A tanúsítási folyamat során létrejön a Kérelmező, a Tanúsító Hatóság és a Felügyeleti Hatóság interakciója A Kérelmező olyan szervezet, amely kérelmet nyújt be a megfelelő tanúsító hatósághoz valamely tanúsítvány (megfelelősége, minősége, alkalmassága stb.) megszerzésére. termék. Tanúsító Szervezet – olyan szervezet, amely elbírálja a Kérelmező szoftvertanúsítási kérelmét, és akár önállóan, akár külön bizottság felállításával eljárásokat készít a Kérelmező szoftvertanúsítási folyamatának lebonyolítására. 23 Felügyeleti szerv - szakértőkből álló bizottság, amely felügyeli az Igénylő által tanúsított fejlesztési folyamatokat. tájékoztatási rendszerés véleményezése az eljárás bizonyos követelményeknek való megfeleléséről, amelyet megfontolásra a Tanúsító Szerv elé terjeszt. A tanúsítás irányulhat megfelelőségi tanúsítvány vagy minőségi tanúsítvány megszerzésére. Az első esetben a tanúsítás eredménye a fejlesztési folyamatok bizonyos kritériumoknak való megfelelésének, illetve a rendszer funkcionalitásának bizonyos követelményeknek való megfelelésének elismerése. Az útmutató dokumentumok példaként szolgálhatnak az ilyen követelményekre. Szövetségi Szolgálat a szoftverrendszerek biztonsága területén a műszaki és exportellenőrzésről. A második esetben az eredmény a fejlesztési folyamatok bizonyos kritériumoknak való megfelelőségének elismerése, ami garantálja a legyártott termék megfelelő minőségi szintjét és bizonyos feltételek melletti használatra való alkalmasságát. Ilyen szabványok például az ISO 9000:2000 (GOST R ISO 9000-2001) nemzetközi minőségi szabványok vagy a DO-178B, AS9100, AS9006 légiközlekedési szabványok. A tanúsítandó szoftver tesztelésének két, egymást kiegészítő célja van: Az első cél annak bemutatása, hogy a szoftver megfelel a vele szemben támasztott követelményeknek. A második cél az, hogy nagy biztonsággal igazolják, hogy a tesztelési folyamat során azonosítják azokat a hibákat, amelyek elfogadhatatlan meghibásodási helyzetekhez vezethetnek, amint azt a rendszerbiztonsági értékelési folyamat meghatározza. Például a DO-178B szabvány követelményei szerint a szoftvertesztelés céljainak teljesítése érdekében a következőkre van szükség: A teszteknek először a szoftverkövetelményeken kell alapulniuk; A teszteket úgy kell megtervezni, hogy ellenőrizzék a helyes működést, és megteremtsék a feltételeket a lehetséges hibák azonosításához. A szoftverkövetelményeken alapuló tesztek teljességének felülvizsgálata során meg kell határozni, hogy mely követelmények nincsenek tesztelve. A tesztek teljességének a programkód struktúrája alapján történő elemzése határozza meg, hogy mely struktúrák nem kerültek végrehajtásra a tesztelés során. Ez a szabvány követelmény alapú tesztelésről is beszél. Ezt a stratégiát találták a leghatékonyabbnak a hibák észlelésében. A tesztesetek követelmények alapján történő kiválasztására vonatkozó irányelvek a következők: A szoftvertesztelés céljainak elérése érdekében a tesztek két kategóriáját kell elvégezni: normál helyzetekre és abnormális (nem kötelező, robusztus) helyzetekre vonatkozó teszteket. A szoftverfejlesztési folyamatban rejlő szoftverkövetelményekhez és hibaforrásokhoz speciális teszteseteket kell kidolgozni. A normál helyzetekre vonatkozó tesztek célja annak bemutatása, hogy a szoftver képes-e a normál bemenetekre és feltételekre a követelményeknek megfelelően reagálni. 24 Az abnormális helyzetekre vonatkozó tesztek célja annak bemutatása, hogy a szoftver képes-e megfelelően reagálni a rendellenes bemenetekre és feltételekre, vagyis nem okozhatja a rendszer meghibásodását. A rendszer meghibásodási helyzeteinek kategóriái a légijármű és az abban tartózkodók meghibásodási veszélyének meghatározásával kerülnek megállapításra. A szoftver bármely hibája olyan hibát okozhat, amely hozzájárul a hibahelyzet kialakulásához. Így a biztonságos működéshez szükséges szoftverintegritás szintje összefügg a rendszer meghibásodási helyzeteivel. A meghibásodásoknak 5 szintje van a kisebbtől a kritikusig. Ezen szintek szerint kerül bevezetésre a szoftverkritikussági szint fogalma. A kritikusság szintje határozza meg a tanúsító hatósághoz benyújtott dokumentáció összetételét, és ezáltal a rendszer fejlesztési és ellenőrzési folyamatainak mélységét. Például a DO-178B legalacsonyabb kritikussági szint tanúsításához szükséges dokumentumtípusok száma és a rendszerfejlesztési munka mennyisége egy-két nagyságrenddel eltérhet a legtöbb esetben a tanúsításhoz szükséges számtól és mennyiségtől. magas szint. A konkrét követelményeket az a szabvány határozza meg, amely szerint a tanúsítást tervezik. 25 2. TÉMAKÖR. Programkód tesztelés (2-5. előadások) 2.1. A programkód tesztelésének feladatai és céljai A programkód tesztelés a programkód végrehajtásának folyamata, amelynek célja a benne lévő meglévő hibák azonosítása. Hiba alatt itt a programkód olyan szakaszát értjük, amelynek végrehajtása bizonyos feltételek mellett váratlan rendszerviselkedéshez vezet (azaz olyan viselkedéshez, amely nem felel meg a követelményeknek). A rendszer váratlan viselkedése működési meghibásodásokhoz és meghibásodásokhoz vezethet, ebben az esetben a programkód jelentős hibáiról beszélnek. Egyes hibák kisebb problémákat okoznak, amelyek nem zavarják a rendszer működését, de valamelyest megnehezítik a vele való munkát. Ebben az esetben közepes vagy kisebb hibákról beszélünk. Az ezzel a megközelítéssel végzett tesztelés feladata a rendszerhibák megjelenési feltételeinek meghatározása és ezek rögzítése. A tesztelési feladatok általában nem tartalmazzák a programkód bizonyos hibás szakaszainak azonosítását, és soha nem tartalmazzák a hibák kijavítását – ez egy hibakeresési feladat, amelyet a rendszertesztelés eredményei alapján hajtanak végre. A programkód tesztelési eljárás alkalmazásának célja a végtermékben előforduló hibák, különösen jelentős hibák számának minimalizálása. A tesztelés önmagában nem garantálja a rendszerkód hibák teljes hiányát. Azonban a következetlenségek és hiányosságok kiküszöbölését célzó ellenőrzési és érvényesítési folyamatokkal kombinálva projektdokumentáció(különösen a rendszerrel szemben támasztott követelmények), a jól szervezett tesztelés biztosítja, hogy a rendszer minden elképzelhető helyzetben megfeleljen a követelményeknek és azoknak megfelelően viselkedjen. A fokozott megbízhatóságú rendszerek, például a légi közlekedés fejlesztése során a megbízhatósági garanciákat a tesztelési folyamat egyértelmű megszervezésével, más életciklus-folyamatokkal való kapcsolatának meghatározásával, olyan mennyiségi jellemzők bevezetésével érik el, amelyek lehetővé teszik a tesztelés sikerességének értékelését. Ugyanakkor minél magasabb követelményeket támasztanak a rendszer megbízhatóságával (kritikussági szintjével) szemben, annál szigorúbbak a követelmények. Így mindenekelőtt nem egy adott rendszer tesztelésének konkrét eredményeit vesszük figyelembe, hanem általános szervezés tesztelési folyamat, a "jól szervezett folyamat minőségi eredményt ad" megközelítést alkalmazva. Ez a megközelítés számos nemzetközi és iparági minőségi szabványban közös, amelyekről a kurzus végén részletesebben is lesz szó. A kifejlesztett rendszer minősége ezzel a megközelítéssel egy szervezett fejlesztési és tesztelési folyamat eredménye, nem pedig független, nem menedzselt eredmény. Mivel a modern szoftverrendszerek nagyon nagyok, a programkódjuk tesztelésekor a funkcionális dekompozíciós módszert alkalmazzák. A rendszer különálló modulokra (osztályok, névterek stb.) van felosztva, amelyek a követelmények által meghatározott funkcionalitással és interfészekkel rendelkeznek. Ezt követően minden modult külön-külön tesztelnek - egységtesztet hajtanak végre. Ezután az egyes modulokat nagyobb konfigurációkká állítják össze - integrációs tesztelést végeznek, végül a rendszer egészét tesztelik - rendszertesztet hajtanak végre. A programkód szempontjából az egység, az integráció és a rendszertesztelés nagyon sok közös vonást mutatnak, ezért ebben a témában az egységtesztelésre fókuszálunk, az integráció és a rendszerteszt sajátosságairól a későbbiekben lesz szó. 26 Az egységteszt során minden modult tesztelnek mind a követelményeknek való megfelelés, mind a programkód olyan problémás szakaszainak hiánya szempontjából, amelyek meghibásodást és meghibásodást okozhatnak a rendszerben. A modulok általában nem működnek a rendszeren kívül - adatokat fogadnak más moduloktól, feldolgozzák és továbbítják. Egyrészt annak érdekében, hogy a modult el lehessen szigetelni a rendszertől és kiküszöböljük az esetleges rendszerhibák hatását, másrészt, hogy a modult minden szükséges adattal ellássuk, tesztkörnyezetet használunk. A tesztkörnyezet feladata, hogy futási környezetet hozzon létre a modul számára, emulálja az összes külső interfészt, amelyhez a modul hozzáfér. A tesztkörnyezet megszervezésének jellemzőiről ebben a témában lesz szó. Egy tipikus tesztelési eljárás a tesztesetek előkészítése és végrehajtása (más néven tesztek). Minden teszteset egy "helyzetet" ellenőriz a modul viselkedésében, és a modul bemenetére átadott értékek listájából, az adatfeldolgozás elindításának és végrehajtásának leírásából - egy tesztforgatókönyvből, valamint a értékeket, amelyek a modul kimenetén várhatóak annak megfelelő viselkedése esetén. A tesztforgatókönyvek úgy vannak összeállítva, hogy kizárják a modul belső adataihoz való hozzáférést, minden interakció csak a modul külső interfészein keresztül történjen. A teszteset végrehajtását egy tesztkörnyezet támogatja, amely tartalmazza a tesztszkript programozott megvalósítását. A végrehajtás a bemenet modulnak való átadásával és a szkript futtatásával kezdődik. A szkript végrehajtása eredményeként a modultól kapott tényleges kimenet eltárolásra kerül és összehasonlításra kerül a várt kimenetekkel. Ha megegyeznek, a teszt sikeresnek minősül, ellenkező esetben nem. Minden sikertelen teszt vagy a tesztelt egység, vagy a tesztkörnyezet vagy a tesztleírás hibáját jelzi. A tesztesetek leírásának halmaza egy tesztterv - a fő dokumentum, amely meghatározza a programmodul tesztelésének eljárását. A tesztterv nemcsak magukat a teszteseteket határozza meg, hanem azok követésének sorrendjét is, ami szintén fontos lehet. A teszttervek felépítéséről és jellemzőiről ebben a témában, a tesztesetek sorrendjével kapcsolatos problémákról lesz szó – a „Megismételhetőség tesztelése” témakörben. A tesztelésnél gyakran nem csak a rendszerrel szemben támasztott követelményeket kell figyelembe venni, hanem a vizsgált modul programkódjának felépítését is. Ebben az esetben a teszteket úgy tervezték meg, hogy észleljék tipikus hibák a követelmények félreértelmezése okozta programozók. Határállapot-ellenőrzések, egyenértékűségi osztályellenőrzések kerülnek alkalmazásra. A követelmények által nem meghatározott képességek hiánya a rendszerben garantálja a programkód lefedettségének különböző becsléseit a tesztekkel, pl. becslések arra vonatkozóan, hogy bizonyos nyelvi konstrukciók hány százalékát hajtják végre az összes teszteset végrehajtása eredményeként. Mindezekről a téma végén lesz szó. 2.2. Vizsgálati módszerek 2.2.1. Fekete doboz A rendszer fekete dobozként való tesztelésének fő gondolata az, hogy a tesztelő rendelkezésére álló összes anyag a rendszer viselkedését és magát a rendszert leíró követelmény, amellyel csak külső hatások alkalmazásával tud dolgozni. bemeneteire és a kimenetek megfigyelésére valamilyen eredményt. A rendszer megvalósításának minden belső tulajdonsága el van rejtve a tesztelő elől, így a rendszer egy „fekete doboz”, amelynek a követelményekhez viszonyított helyes viselkedését ellenőrizni kell. 27 A programkód szempontjából a fekete doboz lehet osztályok (vagy modulok) halmaza, ismert külső interfészekkel, de hozzáférhetetlen forrásszövegekkel. A tesztelő fő feladata ennél a tesztelési módszernél, hogy következetesen ellenőrizze, hogy a rendszer viselkedése megfelel-e a követelményeknek. Ezenkívül a tesztelőnek tesztelnie kell a rendszert kritikus helyzetekben - mi történik, ha helytelen bemeneti értékeket adnak meg. Ideális helyzetben a kritikus helyzetek minden változatát le kell írni a rendszer követelményeiben, és a tesztelő csak konkrét ellenőrzésekkel állhat elő ezekre a követelményekre. A valóságban azonban a tesztelés eredményeként általában kétféle rendszerprobléma derül ki: 1. A rendszer viselkedésének inkonzisztenciája a követelményekkel 2. A rendszer nem megfelelő viselkedése olyan helyzetekben, amelyeket a követelmények nem írnak elő. Mindkét típusú probléma jelentését dokumentálják, és megosztják a fejlesztőkkel. Ugyanakkor az első típusú problémák általában a programkód változását okozzák, sokkal ritkábban - a követelmények változását. A követelmények megváltoztatására ebben az esetben szükség lehet azok következetlensége (több különböző követelmény írja le a rendszer viselkedésének különböző modelljeit ugyanabban a helyzetben) vagy helytelenségük (a követelmények nem felelnek meg a valóságnak) miatt. A második típusú problémák hiányosságuk miatt egyértelműen a követelmények módosítását teszik szükségessé - a követelmények egyértelműen kihagyják azt a helyzetet, amely a rendszer nem megfelelő viselkedéséhez vezet. Ugyanakkor a nem megfelelő viselkedés felfogható a rendszer teljes összeomlásaként, vagy általánosságban minden olyan viselkedésként, amelyet a követelmények nem írnak le. A fekete doboz tesztelését követelményvizsgálatnak is nevezik. ez az egyetlen információforrás a tesztterv elkészítéséhez. 2.2.2. Üveg (fehér) doboz Az üvegdobozhoz hasonló rendszer tesztelésekor a tesztelő nem csak a rendszer követelményeihez, annak bemeneteihez és kimeneteihez fér hozzá, hanem a belső felépítéséhez is - látja a programkódját. A programkód elérhetősége kibővíti a tesztelő képességeit azáltal, hogy láthatja a követelmények megfelelését a programkód szakaszainak, és ezáltal láthatja, hogy vannak-e követelmények a teljes programkódra vonatkozóan. A programkódot, amelyhez nincsenek követelmények, követelmények nélküli kódnak nevezzük. Az ilyen kód a rendszer nem megfelelő viselkedésének lehetséges forrása. Ráadásul a rendszer átláthatósága lehetővé teszi a problémákat okozó területek elemzésének elmélyítését – gyakran az egyik probléma semlegesíti a másikat, és soha nem jelentkeznek egyszerre. 2.2.3. Modelltesztelés A modelltesztelés némileg távol áll a klasszikus szoftverellenőrzési módszerektől. Ez mindenekelőtt abból adódik, hogy a tesztelés tárgya nem maga a rendszer, hanem annak formális eszközökkel megtervezett modellje. Ha figyelmen kívül hagyjuk magának a modellnek a helyességének és alkalmazhatóságának ellenőrzésének kérdéseit (úgy véljük, hogy helyessége és az eredeti rendszernek való megfelelése formális eszközökkel is igazolható), akkor a tesztelő rendelkezésére áll egy meglehetősen hatékony elemzési eszköz. a rendszer általános integritását. A modellel dolgozva olyan helyzeteket hozhat létre, amelyeket egy valós rendszer tesztlaborjában nem lehet létrehozni. A rendszer programkódjának modelljével dolgozva elemezni lehet annak tulajdonságait és olyan rendszerparamétereket, mint az algoritmusok optimalitása vagy stabilitása. 28 A modelltesztelés azonban éppen a rendszer viselkedésének formális leírásának kialakítása során felmerült nehézségek miatt nem terjedt el széles körben. A kevés kivételek egyike a kommunikációs rendszerek, amelyek algoritmikus és matematikai apparátusa meglehetősen fejlett. 2.2.4. Programkód elemzés (ellenőrzés) Sok esetben lehetetlen a rendszer egészének viselkedését tesztelni - előfordulhat, hogy a programkód egyes részei soha nem kerülnek végrehajtásra, miközben lefedik a követelmények. A kivételkezelők példák a kód ilyen szakaszaira. Ha például két modul numerikus értékeket küld egymásnak, és mindkét modulban működnek az értékellenőrzési funkciók, akkor a vevőmodul ellenőrző funkciója soha nem aktiválódik, mert minden hibás érték le lesz vágva a távadóban. Ebben az esetben a programkód kézi elemzése történik a helyesség szempontjából, amit kódellenőrzésnek vagy ellenőrzésnek is neveznek. Ha az ellenőrzés eredményeként problémás területeket azonosítanak, akkor az erről szóló információkat a rendszeres tesztek eredményeivel együtt átadják a fejlesztőknek javításra. 2.3. Tesztkörnyezet Szinte minden összetett rendszer tesztelésének nagy része általában ebben történik automatikus üzemmód. Ezenkívül a tesztelés alatt álló rendszert általában külön modulokra osztják, amelyek mindegyikét először a többitől külön, majd egy egészben tesztelik. Ez azt jelenti, hogy a teszteléshez létre kell hozni egy olyan környezetet, amely biztosítja a tesztelt modul elindítását és végrehajtását, átadja a bemeneti adatokat, összegyűjti a rendszer adott bemeneti adatokon történő futtatásának eredményeként kapott valós kimeneti adatokat. . Ezt követően a környezetnek össze kell hasonlítania a tényleges kimeneti adatokat a várt adatokkal, és ennek alapján következtetést kell levonnia a modul viselkedésének a megadottnak való megfelelőségéről (9. ábra). Teszt illesztőprogram várt kimeneti adatok tesztelés alatt Bemeneti adatok Eredmény Modul valós kimeneti adat csonkok 9 A tesztkörnyezet általánosított sémája A tesztkörnyezet az egyes rendszermodulok elidegenítésére is használható a teljes rendszertől. A rendszermodulok szétválasztása a tesztelés korai szakaszában lehetővé teszi a programkódjukban felmerülő problémák pontosabb lokalizálását. Egy modul rendszertől elkülönített működésének támogatásához a tesztkörnyezetnek modelleznie kell minden olyan modul viselkedését, amelyek funkcióihoz vagy adataihoz a tesztelt modul hozzáfér. 29
Küldje el a jó munkát a tudásbázis egyszerű. Használja az alábbi űrlapot
Diákok, végzős hallgatók, fiatal tudósok, akik a tudásbázist tanulmányaikban és munkájukban használják, nagyon hálásak lesznek Önnek.
Házigazda: http://www.allbest.ru/
absztrakt
Szoftver ellenőrzési és tesztelési módszerek
Bevezetés
Az emberek hajlamosak hibázni. Hibák mindig voltak és lesznek is. Van egy vicc az informatikai környezetben, hogy ha a program először elindul és azonnal működik, akkor hibát kell keresni.
A fejlesztéssel együtt Számítástechnika, az élet minden területére való behatolásával a programok hibáinak száma is nő. Ráadásul a hibák számának növekedése nem áll arányban a programok számának növekedésével. A programozók sora minden évben feltöltődik bydlocoderekkel (és a nevük légió), akik exponenciálisan fejlesztik a hibaterületet.
A hibák nem minden területen láthatók. Például senkit sem érdekelnek az olyan böngészők hibái és sebezhetőségei, mint az "amigo". Igen, és az ilyen hibákból származó veszteségek jelentéktelenek: a maximum, amit egy hétköznapi felhasználó veszíthet, a közösségi hálózatokon lévő fiókok, másfél ezer átlagos nyaralási fotó és egy pornógyűjtemény.
De vannak olyan területek, ahol a programozási hibák a legsajnálatosabb következményekkel járhatnak. Az egyik első eset, amit sikerült megtalálnom, a Mariner 1 űrhajó, amely 1962. július 22-én, 293 másodperccel az indítás után megsemmisült a fedélzeti számítógépes program hibája miatt. Még jó, hogy akkor nem volt haláleset.
És mi lesz, ha a Boeing-747 fedélzeti számítógépe, négyszáz utassal a fedélzetén kivételt dob?
Az ilyen „komolynak” nevezhető területekre találták ki az ellenőrzési és tesztelési módszereket.
Egyes külföldi szakirodalomban az verifikáció, tesztelés folyamatait azonosítják, helyenként a tesztelést tekintik a verifikáció egyik módszerének. Ezt a munkát legjobb tudásom szerint fogom elvégezni, külön figyelembe véve az ellenőrzési és tesztelési folyamatokat. Az igazságosság kedvéért kitérek a szoftverérvényesítés témára is.
1. Definíciók
Életciklus(LC) szoftver. Ez a kifejezés arra az időintervallumra vonatkozik, amely a bizonyos problémák megoldásához szükséges funkciókkal rendelkező szoftver létrehozásának ötletétől a használat teljes leállításáig kezdődik. legújabb verzió ez a program.
Műtárgyak szoftver életciklusa (SW). Ez magában foglalja a szoftverek létrehozásával kapcsolatos különféle információs anyagokat. Ezek a megbízási feltételek, az architektúra leírása, a forráskód, a felhasználói dokumentáció és egyéb dokumentumok. A fejlesztés során felhasznált, de hozzáférhető formában nem rögzített anyagok (például megjegyzések a kódban és a fejlesztők visszaélése a chatben) nem minősülnek műterméknek.
2. Igazolás
A hitelesítés ellenőrzi, hogy egyes szoftverfejlesztés és -karbantartás során keletkezett műtermékek megfelelnek-e más, korábban létrehozott vagy kiindulási adatként használt műtermékeknek, valamint ezen műtermékek és fejlesztési folyamataik megfelelnek-e a szabályoknak és szabványoknak. Az verifikáció különösen a szabványok normái, a szoftverre, a tervezési megoldásokra, a forráskódra, a felhasználói dokumentációra és maga a szoftver működésére vonatkozó követelmények leírása (meghatározás) közötti megfelelést ellenőrzi. Ezen túlmenően, ellenőrizni kell, hogy a követelmények tervezési megoldások, a dokumentáció és a kód az adott országban, iparágban és szervezetben a szoftverek fejlesztése során elfogadott normáknak és szabványoknak megfelelően készül, valamint az is, hogy megalkotásukkor a szabványokban meghatározott összes műveletet a szükséges sorrendben elvégezték. Az ellenőrzés során észlelt hibák és hiányosságok eltérések vagy ellentmondások több felsorolt dokumentum között, a dokumentumok és a program tényleges működése, a szabványok normái és a szoftverfejlesztés és karbantartás tényleges folyamatai között. Ugyanakkor annak eldöntése, hogy melyik dokumentumot (talán mindkettőt) kell javítani, külön feladat.
A fenti a hitelesítés hivatalos meghatározása. Valójában minden sokkal egyszerűbb: az ellenőrzés határozza meg jól csináljuk a programot?.
Így az ellenőrzés fő módszerei a vizsgálat és az ellenőrzés.
programszakértelem ellenőrzése
3. Érvényesítés
Az érvényesítési folyamat ellenőrzi, hogy a szoftver fejlesztése és karbantartása során létrehozott vagy használt műtermékek megfelelnek-e a szoftver felhasználói és vásárlói igényeinek és követelményeinek, figyelembe véve a törvényeket. tárgykörbenés a szoftver felhasználási környezetének korlátai.
És ismét a sok szó mögött ott van egy nagyon egyszerű feladat: az érvényesítési folyamat során ellenőrzik, hogy ezeknek a felhasználóknak/ügyfeleknek szüksége van-e a program egy bizonyos funkciójára. Megfelel-e a szoftvertermék az ügyfelek és a végfelhasználók kívánságainak?
4. Tesztelés
A tesztelés a szoftverhibák észlelésének folyamata egy szoftverrendszer kódjának tesztelési adatokon történő végrehajtásával, teljesítményjellemzők összegyűjtése a végrehajtás dinamikájában egy adott működési környezetben, azonosítva a különféle hibákat, hibákat, hibákat és hibákat, amelyeket szabálytalan és abnormális helyzetek okoznak. vagy a szoftver rendellenes leállása.
Történelmileg a tesztelés első típusa a hibakeresés volt.
A hibakeresés egy programobjektum leírásának ellenőrzése egy programozási nyelven annak érdekében, hogy felismerje a benne lévő hibákat, majd kiküszöbölje azokat. A hibákat a fordító a szintaktikai vezérlés során észleli. A hibakeresést követően ellenőrzésre kerül sor a kód helyességének és érvényesítésének ellenőrzésére, hogy a termék megfelel-e a megadott követelményeknek.
1. Statikus vizsgálati módszerek
Statikus módszereket alkalmaznak az ellenőrzések és a komponensek specifikációinak felülvizsgálata során azok végrehajtása nélkül. A statikus elemzés technikája a programok szerkezetének módszeres áttekintéséből, elemzéséből, valamint helyességének bizonyításából áll. A statikus elemzés az életciklus minden szakaszában kifejlesztett dokumentumok elemzésére irányul, és a forráskód ellenőrzéséből és a program végpontok közötti vezérléséből áll.
A szoftverellenőrzés a program adott specifikációinak való megfelelésének statikus ellenőrzése, amelyet az életciklus-folyamatok tervezési eredményeinek (dokumentáció, követelmények, specifikációk, diagramok vagy programforráskód) különféle reprezentációinak elemzésével hajtanak végre. A tervezési eredmények és a vevői követelményeknek való megfelelés felülvizsgálata és ellenőrzése többet nyújt jó minőség szoftverrendszereket hozott létre.
2. Dinamikus tesztelési módszerek
Fekete doboz módszer. Ennek a módszernek a használatakor a megoldandó problémára vonatkozó információkat használjuk, de a program felépítéséről semmit sem tudunk. Az ezen elv szerinti tesztelés célja, hogy egy teszttel a lehetséges bemeneti adatok egy kis részhalmazának felhasználásával azonosítsuk a hibák maximális számát.
Ezen elv szerinti vizsgálati módszerekkel teszteljük a programban megvalósított funkciókat a függvények tényleges viselkedése és az elvárt viselkedés közötti eltérés ellenőrzésével, figyelembe véve a követelményspecifikációkat. A tesztelésre való felkészülés során állapottáblázatok, ok-okozati diagramok 1 és bontási területek épülnek fel. Emellett tesztcsomagok készülnek, amelyek figyelembe veszik a függvények viselkedését befolyásoló paramétereket és környezeti feltételeket.
Fehér doboz módszer.
Ez a módszer lehetővé teszi a program belső szerkezetének feltárását, és a program összes hibájának észlelése a vezérlő áramlási útvonalak kimerítő tesztelésének kritériuma, amelyek között szerepel:
Üzemeltetői lefedettségi kritérium – az összesített tesztsorozatnak biztosítania kell, hogy minden operátor legalább egyszer sikeres legyen;
Ágak tesztelési kritériuma (más néven döntési lefedettség vagy átmeneti lefedettség) - az összesített tesztkészletnek biztosítania kell, hogy minden elágazás vagy kilépés legalább egyszer sikeres legyen.
3. Funkcionális tesztelés
A funkcionális tesztelés célja a megvalósított funkciók tényleges viselkedése és a specifikáció és a kezdeti követelmények szerinti elvárt viselkedés közötti ellentmondások kimutatása. A funkcionális teszteknek ki kell terjedniük az összes megvalósított funkcióra, figyelembe véve a legvalószínűbb hibatípusokat. Az egyedi teszteket kombináló tesztforgatókönyvek a funkcionális problémák megoldásának minőségének ellenőrzésére összpontosítanak.
A funkcionális tesztek a funkciók, a tervezési információk és a programnyelvi szövegek specifikációi szerint jönnek létre, és a funkcionális feladatok végrehajtásának teljességét és a kezdeti követelményeknek való megfelelését határozzák meg.
A funkcionális tesztelési feladatok közé tartozik:
Funkcionális követelményrendszer meghatározása;
Külső funkciók azonosítása és funkciósorozatok felépítése a szoftverrendszerben való használatuknak megfelelően;
Az egyes funkciók bemeneti adatkészletének azonosítása és változási területeinek meghatározása;
Tesztkészletek és forgatókönyvek készítése tesztelési funkciókhoz;
Az összes funkcionális követelmény azonosítása és bemutatása tesztesetek és tesztelési hibák segítségével a programban és a környezettel való interakció során.
A tervezési információkból készített tesztek adatstruktúrákhoz, algoritmusokhoz, egyes komponensek közötti interfészekhez kapcsolódnak, és komponensek és interfészeik tesztelésére szolgálnak. A fő cél a megvalósított funkciók és a köztük lévő interfészek teljességének, következetességének biztosítása.
5. ANSI/IEEE hibatípusok-7 29 -8 3
Error (hiba) - a program állapota, amelyben hibás eredmények születnek, amelyek oka a program vagy a program utasításainak hibái (hiba) technológiai folyamat fejlődését, ami félreértelmezéshez vezet háttér-információ, ami rossz megoldáshoz vezet.
A program hibája (hiba) - a fejlesztő hibáinak következménye a fejlesztés bármely szakaszában, amelyet az eredeti vagy a tervezési specifikáció, a programkódok szövege, az üzemeltetési dokumentáció stb. tartalmazhat. A program végrehajtása során hiba vagy meghibásodás észlelhető.
A meghibásodás (hiba) a program működésétől való eltérése, vagy a program nem képes a követelmények és korlátozások által meghatározott funkciók ellátására, amely olyan eseménynek minősül, amely hozzájárul a program működésképtelen állapotba kerüléséhez hibák miatt. , benne lappangó hibák vagy a működő környezet meghibásodásai. A kudarc a következő okokból állhat:
Hibás specifikáció vagy kihagyott követelmény, ami azt jelenti, hogy a specifikáció nem tükrözi pontosan a felhasználó szándékát;
A specifikáció tartalmazhat olyan követelményt, amely az adott hardveren és szoftveren nem teljesíthető;
A programterv tartalmazhat hibákat (például az adatbázist úgy tervezték meg, hogy nincs védelem a jogosulatlan felhasználói hozzáférés ellen, de védelem szükséges);
Lehet, hogy a program hibás, pl. szokatlan algoritmust hajt végre, vagy nincs teljesen implementálva.
Következtetés
A szoftverellenőrzéssel és teszteléssel kapcsolatos orosz GOST-ok olyan „burzsoá” szabványok fordításai, mint az ISO 12207, ANSI/IEEE-729-83 és mások (sok ilyen van). A probléma az, hogy ezek a nemzetközi szabványok eltérően kezelik a tesztelési és ellenőrzési kérdéseket. Nem azt mondom, hogy teljesen ellentmondanak egymásnak, de zavart okozhatnak.
Mindezeket a szabványokat a múlt század 80-as éveiben fogalmazták meg az amerikai űripar számára. A következő években kijavították és újra kiadták, de a dokumentumokban nézeteltérések és ellentmondások megmaradtak.
Következtetés: az verifikációs, validációs és tesztelési módszerek felépítését feltételesnek kell tekinteni.
Bibliográfia
1. Ingyenes enciklopédia wikipedia.org
2. Kulyamin V.V. Szoftverellenőrzési módszerek M.: Rendszerprogramozási Intézet, 2008
3. Lavrishcheva E., Petrukhin V. Előadás "Módszerek a programok és rendszerek ellenőrzésére és tesztelésére": NOU "INTUIT" http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130
Az Allbest.ru oldalon található
...Hasonló dokumentumok
A szoftver életciklusa egy folyamatos folyamat, amely a szoftver létrehozásának szükségességéről szóló döntéssel kezdődik és a teljes működésből való kivonással végződik. Riley, Lehman és Boehm megközelítése a szoftver életciklus meghatározásához.
absztrakt, hozzáadva: 2009.11.01
A programfejlesztési technológia fogalma. A szoftvertervezés alapja. A szoftvertervezés elméletének fejlődése során történetileg kialakult életciklus-modellek. Spirális (spirál), kaszkád és iteratív modellek.
bemutató, hozzáadva 2015.11.05
A fejlesztés története és a szoftvertesztelés típusai. Telepítés, regresszió, konfiguráció, integráció, lokalizáció, egységteszt. A kifejlesztett alkalmazás egységtesztelési bonyolultságának csökkentésére szolgáló módszerek.
szakdolgozat, hozzáadva 2015.12.16
A szoftvertesztelési probléma eldönthetetlensége. A tesztelés típusai és szintjei. Upstream és downstream tesztelési stratégiák. A „fehér” és „fekete” doboz módszerei. Automatizált és kézi tesztelés. Fejlesztés teszteléssel.
szakdolgozat, hozzáadva 2015.03.22
Szoftvertervezési technológia (SW) követelményei. A szoftver teljes életciklusának szakaszainak összeállítása és leírása. Szoftver életciklus modellek osztályozása, jellemzőik. Szoftverfejlesztési módszertanok, extrém programozási technikák.
bemutató, hozzáadva 2016.09.19
A szoftvertesztelés története, megvalósításának főbb céljai és jellemzői. A tesztelés típusai, típusai, automatizálásának szintjei. Használat és kutatás szükséges technológiákat. Teljes ciklus a teljes felügyeleti rendszer működtetése.
szakdolgozat, hozzáadva: 2018.05.03
Főbb nemzetközi szabványok a területen információs technológiák. nemzetközi szabvány ISO/IEC 9126 Minőség és életciklus. A minőség belső és külső jellemzőinek jellemzése. A szoftver működésének elemzése.
jelentés, hozzáadva: 2017.06.13
A szoftverfejlesztés céljai és célkitűzései. A szoftver fogalma. Hat alapelv hatékony felhasználása szoftver. Szoftvertípusok: rendszerszintű, hálózati és alkalmazott. A szoftverkészítés alapelvei.
szakdolgozat, hozzáadva 2010.06.29
A fő életciklus modellek általános jellemzői: kaszkád, inkrementális, spirál. A szoftverfejlesztési folyamat részeként meghatározott szakasz, amely meghatározott időkeretre korlátozódik és egy adott termék kiadásával ér véget.
bemutató, hozzáadva 2013.12.27
Oroszország informatizálása. Piac szoftver eszközök. A szabványosítás, tanúsítás és engedélyezés fő feladatai az informatizálás területén. Mérnöki módszerek és eszközök összessége szoftverkészítéshez. A szoftver életciklusa.
Az ellenőrzés és érvényesítés azokra az ellenőrzési és felülvizsgálati folyamatokra vonatkozik, amelyek ellenőrzik, hogy a szoftver megfelel-e a specifikációinak és az ügyfél követelményeinek. Az ellenőrzés és érvényesítés a szoftver teljes életciklusára kiterjed – a követelményelemzés szakaszában kezdődik, és a programkód ellenőrzésével a kész szoftverrendszer tesztelésének szakaszában ér véget.
Az igazolás és a tanúsítás nem ugyanaz, bár könnyen összetéveszthető. Röviden, a köztük lévő különbséget a következőképpen határozhatjuk meg:
Az ellenőrzés választ ad arra a kérdésre, hogy a rendszer megfelelően van-e kialakítva;
A tanúsítás választ ad arra a kérdésre, hogy a rendszer megfelelően működik-e.
E meghatározások szerint az ellenőrzés azt ellenőrzi, hogy a szoftver megfelel-e a rendszerspecifikációnak, különösen a funkcionális és nem funkcionális követelményeknek. A tanúsítás egy általánosabb folyamat. Az érvényesítés során meg kell győződnie arról, hogy a szoftvertermék megfelel az ügyfél elvárásainak. A hitelesítés az ellenőrzést követően történik annak megállapítására, hogy a rendszer nem csak a specifikációnak, hanem a vevő elvárásainak is megfelel.
Mint korábban említettük, a rendszerkövetelmények érvényesítése nagyon fontos a szoftverfejlesztés korai szakaszában. A követelményekben gyakran előfordulnak hibák és hiányosságok; ilyen esetekben a végtermék valószínűleg nem fog megfelelni a vevő elvárásainak. De természetesen a követelmények érvényesítése nem fedheti fel a követelményspecifikáció összes problémáját. Néha a követelmények hiányosságait és hibáit csak a rendszer megvalósítása után fedezik fel.
Az ellenőrzési és érvényesítési folyamatok két fő technikát használnak a rendszerek ellenőrzésére és elemzésére.
1. Szoftver ellenőrzés. A rendszer különféle reprezentációinak elemzése és ellenőrzése, mint például a követelményspecifikációs dokumentáció, az építészeti diagramok vagy a program forráskódja. Az ellenőrzés a szoftverrendszer fejlesztési folyamatának minden szakaszában megtörténik. Az ellenőrzéssel párhuzamosan elvégezhető a programok és a kapcsolódó dokumentumok forráskódjának automatikus elemzése. Az ellenőrzés és az automatizált elemzés statikus ellenőrzési és érvényesítési módszerek, mivel nem igényelnek végrehajtható rendszert.
2. Szoftver tesztelés. Futtatható kód futtatása tesztadatokkal, valamint a szoftvertermék kimenetének és teljesítményének vizsgálata annak ellenőrzése érdekében, hogy a rendszer megfelelően működik-e. A tesztelés dinamikus ellenőrzési és érvényesítési módszer, mivel a futó rendszerre alkalmazzák.
ábrán. A 20.1. ábra mutatja az ellenőrzés és tesztelés helyét a szoftverfejlesztési folyamatban. A nyilak jelzik a fejlesztési folyamat azon szakaszait, ahol ezek a módszerek alkalmazhatók. E séma szerint az ellenőrzés a rendszerfejlesztési folyamat minden szakaszában elvégezhető, a tesztelés pedig - prototípus vagy végrehajtható program elkészítésekor.
Az ellenőrzési módszerek a következők: programellenőrzés, automatikus forráskód-elemzés és formális ellenőrzés. A statikus módszerek azonban csak a programok specifikációnak való megfelelőségét tudják ellenőrizni, a rendszer megfelelő működését nem. Ezenkívül az olyan nem funkcionális jellemzők, mint a teljesítmény és a megbízhatóság, nem tesztelhetők statikus módszerekkel. Ezért a nem funkcionális jellemzők értékelésére rendszertesztet végeznek.
Rizs. 20.1. Statikus és dinamikus ellenőrzés és tanúsítás
A szoftverellenőrzés széles körben elterjedt alkalmazása ellenére a tesztelés még mindig az uralkodó igazolási és tanúsítási módszer. A tesztelés a programok működésének ellenőrzése a valóshoz hasonló adatokkal, amelyek a rendszer működése során kerülnek feldolgozásra. A programban a hibák és a követelményekkel való inkonzisztenciák jelenléte a kimeneti adatok vizsgálatával és az anomáliák azonosításával észlelhető. A tesztelés a rendszer bevezetési szakaszában (annak ellenőrzésére, hogy a rendszer megfelel-e a fejlesztők elvárásainak) és a megvalósítás befejezése után történik.
A szoftverfejlesztési folyamat különböző szakaszaiban különböző típusú teszteléseket alkalmaznak.
1. Hibavizsgálat a program és annak specifikációi közötti, a programok hibáiból vagy hibáiból eredő inkonzisztenciák észlelésére szolgál. Az ilyen tesztek célja a rendszer hibáinak észlelése, nem pedig a működés szimulálása.
2. Statisztikai tesztelésértékeli a programok teljesítményét, megbízhatóságát, valamint a rendszer működését különböző üzemmódokban. A teszteket úgy tervezték, hogy valós bemeneti adatokkal utánozzák a rendszer tényleges működését. A rendszer megbízhatóságát a programok munkájában észlelt hibák száma határozza meg. A teljesítmény értékelése a teljes működési idő és a rendszer válaszidejének mérésével történik a tesztadatok feldolgozásakor.
a fő cél Ellenőrzés és minősítés – annak biztosítása érdekében, hogy a rendszer „megfeleljen a célnak”. Egy szoftverrendszer rendeltetésszerű alkalmassága nem jelenti azt, hogy teljesen hibamentesnek kell lennie. Inkább a rendszernek ésszerűen jól illeszkednie kell azokhoz a célokhoz, amelyekre szánták. Kívánt megfelelőség érvényessége függ a rendszer céljától, a felhasználói elvárásoktól és a szoftvertermékekre vonatkozó piaci feltételektől.
1. A szoftver célja. A megfelelőségi megbízhatóság szintje attól függ, hogy bizonyos kritériumok szerint mennyire kritikus a kifejlesztett szoftver. Például a biztonság szempontjából kritikus rendszerek megbízhatósági szintjének lényegesen magasabbnak kell lennie, mint az új ötlet demonstrálására fejlesztendő prototípus szoftverrendszereknél.
2. Felhasználói elvárások. Szomorúan kell megjegyezni, hogy jelenleg a legtöbb felhasználó alacsony követelményeket támaszt a szoftverekkel szemben. A felhasználók annyira hozzászoktak a programok futása közben fellépő hibákhoz, hogy ezen nem lepődnek meg. Hajlandóak elviselni a rendszerhibákat, ha a használat előnyei meghaladják a hátrányokat. Az 1990-es évek eleje óta azonban a felhasználók toleranciája a szoftverrendszerek hibáival szemben fokozatosan csökken. Az utóbbi időben szinte elfogadhatatlanná vált a megbízhatatlan rendszerek létrehozása, ezért a szoftverfejlesztő cégeknek egyre nagyobb figyelmet kell fordítaniuk a szoftverek ellenőrzésére és validálására.
3. Szoftverpiaci feltételek. A szoftverrendszer értékelésekor az eladónak ismernie kell a versengő rendszereket, azt az árat, amelyet a vevő hajlandó fizetni a rendszerért, és a rendszer várható piaci bevezetési idejét. Ha a fejlesztő cégnek több versenytársa van, akkor a teljes tesztelés és hibakeresés befejezése előtt meg kell határozni a rendszer piacra lépésének időpontját, ellenkező esetben a versenytársak léphetnek be elsőként a piacra. Ha az ügyfelek nem hajlandók magas áron szoftvert vásárolni, akkor hajlandóak lehetnek több rendszerhibát is elviselni. Az igazolási és minősítési folyamat költségeinek meghatározásakor mindezeket a tényezőket figyelembe kell venni.
Általános szabály, hogy az ellenőrzés és a tanúsítás során hibákat találnak a rendszerben. A hibák kijavítása érdekében változtatásokat hajtanak végre a rendszeren. Ez hibakeresési folyamat rendszerint más ellenőrzési és tanúsítási folyamatokkal integrálva. A tesztelés (vagy általánosabban az ellenőrzés és érvényesítés) és a hibakeresés azonban különböző folyamatok, amelyeknek más a célja.
1. Az ellenőrzés és érvényesítés a szoftverrendszer hibáinak észlelésének folyamata.
2. Hibakeresés - a hibák (hibák) lokalizálásának és kijavításának folyamata (20.2. ábra).
Rizs. 20.2. Hibakeresési folyamat
Nincsenek egyszerű módszerek a programok hibakeresésére. A tapasztalt hibakeresők úgy találják meg a hibákat, hogy összehasonlítják a tesztkimeneti mintákat a tesztelt rendszerek kimenetével. A hiba megtalálásához ismerni kell a hibatípusokat, a kimeneti mintákat, a programozási nyelvet és a programozási folyamatot. Nagyon fontos a szoftverfejlesztési folyamat ismerete. A hibakeresők tisztában vannak a leggyakoribb programozási hibákkal (például a számláló növelésével). Figyelembe veszi azokat a hibákat is, amelyek bizonyos programozási nyelvekre jellemzőek, például azokat, amelyek a C nyelvben a mutatók használatával kapcsolatosak.
A programkódban lévő hibák felkutatása nem mindig egyszerű folyamat, mivel a hiba nem feltétlenül található a programkód azon pontjának közelében, ahol az összeomlás bekövetkezett. A hibák elkülönítése érdekében a hibakereső további szoftverteszteket fejleszt ki, amelyek segítenek azonosítani a programhiba forrását. Lehet, hogy manuálisan kell nyomon követnie a program végrehajtását.
Az interaktív hibakereső eszközök a kódfordító rendszerbe integrált nyelvtámogatási eszközök készletének részét képezik. Speciális programvégrehajtási környezetet biztosítanak, amelyen keresztül elérheti az azonosítók táblázatát, és onnan a változók értékeit. A felhasználók gyakran lépésről lépésre irányítják a program végrehajtását, utasításról utasításra egymás után lépve. Az egyes utasítások végrehajtása után a változók értékeit ellenőrizzük, és azonosítjuk az esetleges hibákat.
A programban talált hiba kijavításra kerül, ezt követően ismételten ellenőrizni kell a programot. Ehhez újra ellenőrizheti a programot, vagy megismételheti az előző tesztet. Az újratesztelés arra szolgál, hogy a programon végrehajtott változtatások ne vezessenek be új hibákat a rendszerbe, mert a gyakorlatban a „hibajavítások” nagy százaléka vagy nem fejeződik be teljesen, vagy új hibákat vezet be a programba.
Elvileg minden javítás után újra le kell futtatni az összes tesztet, de a gyakorlatban ez a megközelítés túl drága. Ezért a tesztelési folyamat megtervezésekor meghatározzák a rendszer részei közötti függőséget, és minden részhez hozzárendelnek teszteket. Ezután lehetőség nyílik a programelemek nyomon követésére az ezekhez az elemekhez kiválasztott speciális tesztesetek (vezérlő adatok) segítségével. Ha a nyomkövetési eredményeket dokumentálják, akkor a teljes vizsgálati adathalmaznak csak egy részhalmaza használható a megváltozott programelem és a függő összetevők tesztelésére.
Ellenőrzés és tanúsítás tervezése
Az ellenőrzés és érvényesítés költséges folyamat. A nagy rendszerek, például a valós idejű rendszerek, amelyek összetett, nem funkcionális korlátai vannak, a rendszerfejlesztési költségvetés felét az ellenőrzési és érvényesítési folyamatra fordítják. Ezért nyilvánvaló ennek a folyamatnak a gondos tervezésének szükségessége.
A szoftverrendszerek fejlesztésének részeként a hitelesítés és érvényesítés tervezését a lehető legkorábban el kell kezdeni. ábrán. A 20.3. ábra egy szoftverfejlesztési modellt mutat be, amely figyelembe veszi a teszttervezési folyamatot. Itt kezdődik a tervezés már a specifikáció és a rendszertervezés fázisában. Ezt a modellt néha V-modellnek is nevezik (a V megtekintéséhez forgassa el a 20.3. ábrát 90°-kal). Ezen a diagramon az ellenőrzési és tanúsítási folyamat több szakaszra bontása is látható, minden szakaszban a megfelelő tesztekkel.
Rizs. 20.3. Teszttervezés a fejlesztés és tesztelés során
A hitelesítés és tanúsítás tervezése során meg kell határozni a statikus és dinamikus rendszerellenőrzési módszerek közötti kapcsolatot, meg kell határozni a szoftverellenőrzési és -tesztelési szabványokat és eljárásokat, jóvá kell hagyni technológiai térkép szoftver áttekintését (lásd a 19.2. szakaszt), és készítsen szoftverteszt tervet. Az, hogy az ellenőrzés vagy a tesztelés a fontosabb, a fejlesztés alatt álló rendszer típusától és a szervezet tapasztalatától függ. Minél kritikusabb a rendszer, annál nagyobb figyelmet kell fordítani a statikus ellenőrzési módszerekre.
Az ellenőrzési és érvényesítési terv a tesztfolyamatok szabványaira összpontosít, nem pedig konkrét tesztek leírására. Ez a terv nem csak útmutatás, hanem elsősorban rendszerfejlesztő és tesztelő szakemberek számára készült. A terv lehetővé teszi a műszaki személyzet számára, hogy teljes képet kapjanak a rendszertesztekről, és ezzel összefüggésben tervezzék meg munkájukat. Ezenkívül a terv tájékoztatást nyújt a vezetőknek, akik felelősek azért, hogy a tesztelő csapat rendelkezzen az összes szükséges hardverrel és szoftverrel.
A tesztterv nem rögzített dokumentum. Rendszeresen felül kell vizsgálni, mivel a tesztelés a rendszer megvalósítási folyamatától függ. Például, ha a rendszer egy részének megvalósítása nem fejeződött be, akkor a rendszer összeállításának tesztelése lehetetlen. Ezért a tervet időszakonként felül kell vizsgálni, hogy a tesztelő személyzetet más munkakörökben lehessen használni.
Az érvényesítés és az ellenőrzés két fogalmát gyakran összekeverik. Ezenkívül a rendszerkövetelmények érvényesítését gyakran összekeverik a rendszerellenőrzéssel. Javaslom ennek a kérdésnek a megvizsgálását.
A cikkben az objektummodellezés két megközelítését vizsgáltam: egészként és struktúraként. A mostani cikkben erre a felosztásra lesz szükségünk.
Tegyük fel, hogy van egy tervezett funkcionális objektumunk. Tekintsük ezt az objektumot egy másik funkcionális objektum felépítésének részének. Legyen az Objektum felépítésének leírása úgy, hogy az tartalmazza az objektum leírását. Egy ilyen leírásban az objektumnak van egy leírása, mint egész, vagyis az objektum felépítésének keretein belül le vannak írva más objektumokkal való interakciós felületei. Legyen adott az objektum mint szerkezet leírása. Legyen egy információs objektum, amely követelményeket tartalmaz az objektum mint szerkezet leírásának kialakításához. Legyen egy olyan ismeretanyag, amely következtetési szabályokat tartalmaz, amelyek alapján az objektum mint struktúra leírása a tárgy egészének leírásából származik. A tudásanyag az, amit az intézetekben tanítanak a tervezőknek - sok-sok tudás. Lehetővé teszik a tárgyra vonatkozó ismeretek alapján a szerkezetének megtervezését.
Szóval, kezdheted. Kijelenthetjük, hogy ha az objektum egésze helyesen van leírva, ha az ismeretanyag helyes, és ha a következtetés szabályait betartjuk, akkor az objektum felépítésének eredő leírása helyes lesz. Vagyis e leírás alapján egy funkcionális objektum, amely megfelel valós körülmények művelet. Milyen kockázatok merülhetnek fel:
1. Helytelen ismeretek használata az objektumról. Lehet, hogy az emberek fejében a Tárgy modellje nem felel meg a valóságnak. Nem ismerték például a földrengések valós veszélyét. Ennek megfelelően előfordulhat, hogy az objektummal szemben támasztott követelmények helytelenül vannak megfogalmazva.
2. Az objektummal kapcsolatos ismeretek hiányos nyilvántartása - valami kimarad, hibákat követnek el. Például tudtak a szelekről, de elfelejtették megemlíteni. Ez az objektumra vonatkozó követelmények nem kellően teljes leírásához vezethet.
3. Rossz tudásanyag. Megtanították nekünk a tömeg elsőbbségét más paraméterekkel szemben, de kiderült, hogy növelni kell a sebességet.
4. A következtetési szabályok helytelen alkalmazása az objektum leírására. Logikai hibák, valami hiányzik az objektum tervezési követelményeiből, a követelmények nyomkövetése megszakadt.
5. A rendszer tervezésére vonatkozó következtetések hiányos nyilvántartása. Mindent figyelembe vettek, mindent kiszámoltak, de elfelejtettek írni.
6. A létrehozott rendszer nem egyezik a leírással.
Nyilvánvaló, hogy a projekt összes műterméke általában csak a projekt végére jelenik meg befejezett formájában, és még akkor sem mindig. De ha feltételezzük, hogy a fejlesztés vízesés, akkor a kockázatok olyanok, mint ahogy leírtam. Az egyes kockázatok ellenőrzése egy konkrét művelet, amely nevet adhat. Ha valakit érdekel, megpróbálhatja kitalálni és hangoztatni ezeket a feltételeket.
Mi az ellenőrzés? Oroszul az ellenőrzés a szabályok betartásának ellenőrzése. A szabályok dokumentum formájúak. Vagyis legyen egy dokumentum a dokumentációs követelményekkel. Ha a dokumentáció megfelel a dokumentum követelményeinek, akkor átment az ellenőrzésen.
Mi az érvényesítés? Oroszul a validálás a következtetések helyességének ellenőrzése. Vagyis legyen egy olyan ismeretanyag, amely leírja, hogyan kaphatunk leírást egy tervről az objektum adatok alapján. E következtetések alkalmazásának helyességének ellenőrzése validálás. Az érvényesítés többek között a leírás egységességének, teljességének és érthetőségének ellenőrzését jelenti.
A követelmények érvényesítését gyakran összekeverik az ezekre a követelményekre épülő termékek érvényesítésével. Nem érdemes ilyet csinálni.
