Átvételi teszt meghatározása. Dokumentáció fejlesztése, prototípusok gyártása, tesztelése. Szabványkészlet automatizált rendszerekre

Általában ezt a tesztelést egy másik csapat végzi, amely sok mindent megismétel az automatikus átvételi tesztelés során, manuálisan vagy más eszközzel. Ez azért lehetséges, mert az elfogadási tesztek nem futtathatók könnyen különböző környezetekben, vagy a fejlesztőcsapat nem tudja könnyen megérteni, mit csinálnak a tesztek, és a felhasznált adatok el vannak rejtve a kódban, ami megnehezíti a keresést vagy módosítást. A teszt szándékának elrejtése a kódban megnehezíti annak megértését, hogy a teszt mit akar csinálni.

Ez azt is jelenti, hogy a nem műszaki csapat tagjai nem tudnak könnyen hozzájárulni a teszteléshez, és a műszaki emberek több időt töltenek az automatizált tesztkóddal. Amikor a teszteket át kell alakítani, ami elkerülhetetlen, hogy elválassza a szándékot a megvalósítás eszközeitől, akkor a teszt végrehajtásának újrafaktorizálására összpontosíthat, nem pedig arra, amit a tesztnek el kell végeznie.

A szándék, a megvalósítás és az adatok szétválasztása

Az alábbiakban látható egy diagram, amely szemlélteti a szándék, a megvalósítás és az adatok szétválasztásának gondolatát. A környezet is ide tartozik, hiszen fontos megérteni, hogy a tesztek milyen környezetben fognak futni, és ha szükséges, módosítani kell az adatokat, és le kell futtatni a tesztet. Szándék létrehozását a nem műszaki csapattagok a megvalósítástól független nyelven is megtehetik. Ez azért fontos, mert ez azt jelenti, hogy az implementációt újra lehet alakítani anélkül, hogy módosítani kellene a teszt szándékát. Ennek a fordítottja is igaz; lehetőség van a teszt szándékának megváltoztatására a megvalósítás befolyásolása nélkül, feltéve, hogy van olyan megvalósítás, amely kielégíti az intent bekezdésben szereplő összes szót.

Ha a legrosszabb esetben úgy dönt, hogy kidobja a teljes implementációt, és újrakezdi, továbbra is megtarthatja a tesztelési szándékot, és így nem veszíti el az automatizált tesztek legfontosabb részét, amit a tesztek megpróbálnak elvégezni. Szándékokra és megvalósításokra is szét kell választani az adatokat, ezzel absztrakcióval megadhatók a tesztben az adatok, majd az implementáció eltávolításra kerül. Például egy teszt azt jelezheti, hogy az „Arany ügyfél”, mivel az ügyfél azonosításra került, nem része a tesztnek, hanem az adatréteg része.

Az adatréteg létrehozása és az adatok absztrakciója nem új technikák; jellemzően alkalmazáskódhoz használják őket, és az automatizált teszteknél is alkalmazni kell őket, mivel az előnyök továbbra is érvényesek. Tesztesetben az adatréteg meghívásra kerül, hogy a megfelelő ügyféltípushoz adatokat kérjen le az adatforrásból.

A teszteset ezután a lista összes bejegyzésén ismétlődik, és minden ügyfélbejegyzésen tesztet hajt végre. A rendszertesztek a szoftvertesztelés egyik szintjének felelnek meg különféle tesztekkel kombinálva, mint például helyreállítás, biztonság, rugalmasság, teljesítmény, csatlakoztathatóság, hangerő, feszültség, adatok elérhetősége, egyszerű használat, működés, Környezet, tárolás, konfiguráció, telepítés és dokumentáció. Mindegyiknek más a célja, és van egy közös célja, amely bemutatja a projekt szisztematikus elképzelését. Az elfogadási tesztelés egy másik olyan szint, amelyet szoftverteszt-szintek egészítenek ki, ezek a tesztek nagyon alapvetőek, mivel ezek segítségével olyan terméket kaphatunk, amely megfelel a követelményeknek, és egyben kielégíti a felhasználók igényeit a szabványnak megfelelően. követelményeket, amelyeket a kezdetektől fogva felvetettek. Ez arra kényszeríti a rendszert, hogy tesztelje a létfontosságú tesztelési folyamatot, mivel a termék, a hibák száma és a hibák súlyossága szempontjából ez az a fejlesztési lépés, amely általában hajlamos a legtöbb hibára. 1. ábra: Iteratív rendszerek ellenőrzése A rendszertesztek nem a rendszer működésének ellenőrzésére szolgáló folyamatok, ill teljes program, mivel ez a funkcionális tesztelési folyamat során felesleges lenne. A rendszerteszteknek meghatározott célja van: összehasonlítani egy rendszert vagy programot az eredeti céljaival. Ebből a célból két értéket mutatunk be. A rendszertesztelés nem korlátozódik a rendszerekre. Ha a termék egy program, akkor a rendszertesztelés egy kísérlet annak bemutatására, hogy a program hogyan nem teljesíti teljes mértékben céljait vagy követelményeit. A rendszertesztek értelemszerűen csak akkor lehetségesek, ha a termékre mérhető írásos követelmények vonatkoznak. A rendszertesztelés a kutatás azon fázisa, amelyben biztosítja, hogy az egyes komponensek vagy modulok a szándék szerint kölcsönhatásba lépjenek más összetevőkkel vagy modulokkal. A rendszertesztek célja a rendszer mélyreható implementációja, egy információs rendszer integráltságának ellenőrzése világszerte, az azt alkotó különböző alrendszerek és más információs rendszerekkel kommunikáló interfészek megfelelő működésének ellenőrzése. A klasszikus rendszerteszt probléma az "ujjmutatás". Ez akkor fordul elő, ha hibát fedeznek fel, és az egyes rendszerelemek fejlesztője másokat hibáztat. Ahelyett, hogy ebbe az abszurdumba esne, a szoftvermérnöknek előre kell számolnia lehetséges problémákat interfésszel:  tervezési hibakezelési útvonal, amely a rendszer más elemeitől érkező összes információt ellenőrzi. Rendszertesztelés és tesztelés 6  Alkalmazzon tesztsorozatot, amely rossz adatokat vagy másokat szimulál lehetséges hibákat a szoftveres felületen.  A vizsgálati eredményeket bűnösség esetén bizonyítékként rögzíteni.  Részvétel a rendszertesztelés tervezésében és fejlesztésében, hogy megbizonyosodjon a szoftver megfelelő teszteléséről. Valójában a rendszerteszt egy sor különböző tesztet takar, amelyek fő célja a rendszer mélyreható kiszámítása számítástechnika közben. Bár minden tesztnek más a célja, mindannyian azon dolgoznak, hogy a rendszer minden eleme megfelelően integrálva legyen, és a megfelelő funkciókat látja el. 2 A teszt rendszer áttekintése. A tesztelés során rendszert kell fenntartani, vagyis a szoftverfejlesztés integrált megközelítését. Ha ezeket a fogalmakat alkalmazza egy szoftvertesztre, akkor a teszt alapjául szolgáló alapelveket eredményezi: meg kell győződnie arról, hogy pontosan ismeri a tesztelt szoftver céljait, valamint a sikerességi arányokat. Ezek az elemek megtalálhatók a követelménygyűjtési fázis során megszerzett dokumentumokban, valamint a szoftverspecifikációkban. Ezekre az információkra lesz szükség a tesztterv elkészítéséhez, és ezek képezik majd a teszteset kidolgozásának megkezdésének alapját. Meg kell határozni a jóváhagyott rendszer be- és kimeneteit. Ez a szempont szükséges a tesztesetek elkészítésében, valamint a teszteljárások, különösen a célok teljesülését mutató orientált tesztesetek megalkotásában. Vegye figyelembe a fő rendszert, amelyen a tesztelt szoftver fut. Ez általában egy szervezeti környezet, amely hardverből, szoftverből és emberekből áll. Mindezek az elemek nagy befolyást gyakorolnak a rendszerre, és különösen segítik a nem megfelelő adatokkal, adathiánnyal járó nemkívánatos helyzetek teszteseteinek elkészítését. szükséges elemeketés a kivételek előfordulása. 3 A rendszertesztelés áttekintése A rendszertesztelési folyamat két szakaszból áll, amelyek idővel nagyon elkülönülhetnek: a teszt előkészítéséből és a tesztalkalmazásból. Az előbbi szorosan összefügg a követelményekkel, így a projekt korai szakaszában történik, az utóbbihoz pedig a teljes rendszerre vagy legalább egy integrációra van szükség, mivel a résztermékről azt mondják, hogy még kiadatlan, hogy képes legyen teszteket alkalmazni, így ez a projekt előrehaladott szakaszaiban történik meg. projektet. Ezekkel az alkatrészekkel a pontos helyzet a választott modelltől függ. életciklus. A második és harmadik tevékenység elvégzéséhez követelménydokumentum szükséges. A tesztelés első fázisa visszajelzést ad a követelmények elemzéséhez, a hiányosságok, kétértelműségek és egyéb problémák azonosításához. Emellett értékes tanácsokat ad a rendszertervezéshez és -bevezetéshez, ha éppen fejleszt egyet. A tesztalkalmazási fázishoz teszttervre és végrehajtható rendszerverzióra van szükség. Ebben az esetben az elkészített teszteseteket alkalmazzák, az eredményeket elemzik, és azonosítják az esetleges hibákat. Ez a második lépés visszajelzést ad a megvalósításhoz és a tervezéshez, bemutatva a lehetséges hibákat, amelyeket javítani kell. Olyan információkat is tartalmaz, amelyek hasznosak lesznek egy rendszer kiadásához, átvételéhez, megbízhatóságának értékeléséhez és karbantartásához. Az 1. ábra a rendszertesztelési folyamatot és más folyamatokkal való kapcsolatát mutatja be. A második pont azért fontos, mert néha a rendszertesztet összekeverik az interfészteszttel. Az első az összes rész interakcióját ellenőrzi, a második pedig az interfész elemeit, esetleg a kapcsolódó események feldolgozását elemzi. A felület tesztelését segítő eszközök azonban használhatók rendszertesztek futtatására. Több kérdés is felmerül: hány eset lesz elég? Hogyan lehet a lehető legkevesebbet generálni? Milyen értékek a megfelelőek? Rendszertesztelés és tesztelés 9 1 Tesztterv A tesztterv nagyon fontos dokumentum szoftverteszt során. Elmagyarázza a tesztelés céljait és megközelítéseit, a munkatervet, a működési eljárásokat, szükséges eszközöketés felelősségeket. Rendszertesztelés és tesztelés 10 A követelménydokumentumnak tartalmaznia kell a szoftver által végrehajtandó funkciók listáját, leírva és rangsorolva azokat; nem funkcionális követelményeket is tartalmaznia kell, amelyek szervezeti, működési és egyéb szempontokat is tartalmazhatnak. Egy jól előkészített követelménydokumentumnak módot kell adnia az egyes követelmények teljesítésének ellenőrzésére. Jellemzők esetében ez egy leírás lenne, nem funkcionális követelmények esetén pedig nagyon precíz specifikációk, például válaszidő. Egyelőre a funkcionális követelményekre koncentrálunk, a többit egy későbbi szakaszra hagyjuk. A rendszertesztek a következő tényezők miatt fontosak:  A rendszert mint egészet tesztelik a rendszerfejlesztési életcikluson belül.  Ellenőrzik, hogy a rendszer megfelel-e a funkcionális és technikai követelmények .  A rendszert olyan környezetben tesztelik, amely a lehető legközelebb áll az éles környezethez.  A rendszertesztek lehetővé teszik az üzleti követelmények és az alkalmazás architektúra tesztelését, érvényesítését és érvényesítését. 6Rendszertesztek típusa Funkcionális tesztek  Integrációs teszt. - Amelyben a tesztberendezés hozzáfér a rendszer forráskódjához. Ha hibát talál, az integrációs csapat megpróbálja megtalálni a probléma forrását, és meghatározza a hibakeresésre szoruló összetevőket. Az integrációs tesztelés főként a rendszer hibáinak feltárására irányul.  Szállítási igazolás. Itt van a rendszer verziója, amely a felhasználóhoz szállítható. Itt a tesztcsapat feladata annak ellenőrzése, hogy a rendszer megfelel-e a követelményeknek, és garantálja a rendszer megbízhatóságát. A kézbesítési tesztek általában fekete dobozos tesztek, amelyek során a vizsgálóberendezés egyszerűen azzal foglalkozik, hogy a rendszer megfelelően működik-e. Az integrálható komponensek lehetnek kereskedelmi komponensek, egy adott rendszerre szabott újrafelhasználható komponensek vagy új fejlesztésű komponensek. Sok nagy rendszer esetében valószínűleg mindhárom típusú alkatrészt használni fogják. Az integrációs teszt ellenőrzi, hogy ezek a komponensek valóban együtt működnek-e, helyesen hívják-e meg őket, és a megfelelő adatokat a pontos időben továbbítja-e az interfészeiken. A rendszerintegráció magában foglalja az összetevők csoportjainak azonosítását, amelyek bizonyos rendszerfunkciókat biztosítanak, és ezek integrálását kódok hozzáadásával az együttműködéshez. Néha először az egész rendszer vázát fejlesztik ki, és hozzáadják az összetevőket. Ezt nevezik posztintegrációnak. Ez a felfelé irányuló integráció. A gyakorlatban sok rendszer esetében az integrációs stratégia a kettő kombinációja, további infrastrukturális összetevők és funkcionális összetevők hozzáadásával. Mindkét integrációs megközelítéshez további kód szükséges a többi összetevő modellezéséhez és a rendszer működéséhez. Az integrációs tesztek során felmerülő fő nehézség a hibák helye. A rendszer összetevői között összetett kölcsönhatások lépnek fel, és ha rendellenes kimenetet észlel, nehéz lehet meghatározni, hol történt a hiba. A hibák elkülönítésének megkönnyítése érdekében mindig növekményes megközelítést kell alkalmaznia a rendszerintegráció és a tesztelés során. Ennek a folyamatnak a fő célja, hogy növelje a beszállító bizalmát abban, hogy a rendszer megfelel a követelményeknek. Ha igen, akkor termékként szállítható vagy szállítható a vásárlóhoz. Annak bizonyításához, hogy egy rendszer megfelel a követelményeknek, igazolni kell, hogy biztosítja a meghatározott funkcionalitást, teljesítményt és megbízhatóságot, és hogy normál használat mellett nem hibásodik meg. A kézbesítési tesztek általában egy fekete doboz tesztelési folyamat, amelyben a tesztek a rendszer specifikációjából származnak. A rendszert fekete doboznak tekintik, amelynek viselkedését csak a megfelelő bemenetek és kimenetek vizsgálatával kell meghatározni. Ennek egy másik elnevezése a funkcionális tesztelés, mivel a tesztelőt csak a funkcionalitás érdekli, a szoftver megvalósítása nem. A következő ábrán láthatjuk annak a rendszermodellnek az illusztrációját, amely lehetővé teszi a fekete dobozban történő érvényesítést. A tesztelő bemeneteket mutat be egy komponensnek vagy rendszernek, és figyelembe veszi a bemeneteket. Bizonyos esetekben a rendszernek hibatűrőnek kell lennie; vagyis a feldolgozási hibák nem vezethetnek a rendszer egészének meghibásodásához. Tesztrendszerek és átvételi tesztek 14 A rendszerhibákat meghatározott időn belül ki kell javítani, különben az súlyos gazdasági károkkal jár. A helyreállítási teszt egy olyan rendszerteszt, amely több szempontból is meghiúsítja a szoftvert, és ellenőrzi, hogy a helyreállítás megfelelően történik-e. Ha a helyreállítás automatikusan megtörténik, ellenőriznie kell, hogy az újrainicializálás, a rendszer biztonsági mentési mechanizmusai, az adatok helyreállítása és az újraindítás megfelelő-e. Ha a gyógyulás emberi beavatkozást igényel, meg kell határozni az átlagos felépülési időt annak megállapítására, hogy az elfogadható határokon belül van-e. A cél olyan végpontok kialakítása, ahol a rendszer a megadott követelmények alatt kezd el működni. Ezt nem szabad összetéveszteni a hangerőteszttel; A nagyfeszültség a maximális adatmennyiség vagy tevékenység per egy kis idő. A hasonlat a gépíró értékelése lenne. Térfogatvizsgálatot határoznak meg, ha a gépíró egy nagy jelentéstervezettel szembesül; a stresszteszt meghatározza, hogy a gépíró tud-e gépelni percenként 50 szót. A jogsértés a tevékenységek széles körét foglalja magában:  Hacker, aki játékonként próbál bejelentkezni. A biztonsági teszt igazolja, hogy a rendszerbe épített biztonsági mechanizmusok valóban megvédik azt a nem megfelelő behatolásoktól. "A rendszereket tesztelni kell a rendszerbiztonság szempontjából, hogy immunisak legyenek a frontális támadásokkal szemben, de az oldalról vagy hátulról érkezőkkel szemben is." A biztonsági teszt során bárki, aki alkalmazza, a bejelentkezni akaró szerepét tölti be. Mindez megéri! Meg kell próbálnia megszerezni a jelszavakat külső eszközök; megtámadhatja a rendszert a védett architektúrák megkerülésére tervezett speciális szoftverekkel; telítheti a rendszert, megtagadva ezzel mások szolgálatát; szándékos hibákhoz vezethet a rendszerben, hogy megpróbáljon hozzáférni a helyreállítás során: védelem nélkül tekintheti meg az adatokat, azzal a gondolattal, hogy meg kell keresnie a rendszer jelszavát. Ha elegendő időt és erőforrást adunk, a rendszer végül megteszi jó teszt a biztonság érdekében. A rendszertervező szerepe abban áll, hogy a megszakítás költsége nagyobb, mint a kapott információ költsége. Az emberi tényezők elemzése azonban továbbra is erősen szubjektív probléma. A tesztesetek célja annak bizonyítása, hogy ezek a tárolási célok nem találhatók. A lehetséges konfigurációk száma gyakran túl nagy ahhoz, hogy mindegyiket teszteljük, de ha lehetséges, érdemes a programot minden hardvereszközzel, a minimális és maximális konfigurációval tesztelni. Ha maga a program beállítható úgy, hogy kihagyja az összetevőket, vagy ha több számítógépen is futhat, minden konfigurációt tesztelni kell. A telepítési eljárások tesztelése a rendszertesztelési folyamat fontos része. Ez különösen igaz a rendszerre automatikus telepítés tartalmazza a szoftvercsomag. A nem megfelelően futtatott telepítő megakadályozhatja, hogy a felhasználó sikeresen éljen a rendszerrel. A felhasználó első élménye az alkalmazás telepítése. Ennek egyik módja az, hogy a dokumentáció segítségével meghatározzuk a korábbi rendszerteszt-esetek nézetét. Azaz, ha túlterheléses esetet szeretne kifejleszteni, a dokumentációt útmutatóként kell használnia a tényleges teszteset megírásához. Ezenkívül a felhasználói dokumentációt a pontosság és az egyértelműség érdekében ellenőrizni kell. A dokumentációban látható példák bármelyikét tesztelni kell, és fel kell venni a teendők listájára, és bele kell foglalni a programba. Rendszertesztelés és tesztelés 17 működési szempontból, a rendszer tényleges környezetben történő átvétele után és a meghatározott nem funkcionális követelményeknek való megfelelés alapján. Az ellenállástesztet a programok szokatlan helyzetekben történő leküzdésére tervezték. Lényegében az ellenállástesztet végző személy kérdez. Meddig jutsz el a kudarc előtt? Az ellenállásteszt úgy végzi el a rendszert, hogy az abnormális mennyiségű, gyakoriságú vagy mennyiségű erőforrást igényel. Például:  speciális teszteket fejlesztettek ki, amelyek másodpercenként 10 megszakítást generálnak, ha az átlagos csésze egy vagy kettő.  Az adatbevitel gyakoriságát olyan mértékben növeljük, amely lehetővé teszi a beviteli funkciókra adott válaszokat.  Futtasson teszteseteket, amelyek maximális memóriát vagy egyéb erőforrásokat igényelnek.  A tesztesetek a memóriakezelési problémák elhárítására szolgálnak. Tesztesetek jönnek létre, amelyek túlzott lemezkeresést okoznak. Az ábra egy ellenállásteszt példája. A teljesítménytesztet a tesztelési folyamat minden szakaszában alkalmazzák. Még egység szinten is. A tesztelés során értékelni kell az egyes modulok teljesítményét. A valódi rendszerteljesítmény azonban csak a rendszer minden elemének teljes integrálása után érhető el. A teljesítménytesztek gyakran tartalmaznak ellenállástesztet, és gyakran szoftver- és hardverutasításokat igényelnek. Vagyis gyakran szükséges pontosan mérni az erőforrás-felhasználást. Külső eszközök használatával rendszeresen figyelemmel kísérheti a futási időközöket, a naplózott eseményeket és a hardverminták állapotát. Ezeket a teszteket azért hajtják végre, hogy az ügyfél megerősítse, hogy a rendszer érvényes számára. Ezeknek a teszteknek a részletes tervezését már a fejlesztési szakaszban el kell végezni azzal a céllal, hogy az eredményeket érvényességük jelzésére használjuk: ha a dokumentált teszteket a vevők megelégedésére hajtják végre, a termék megfelelőnek minősül, és ezért megfelelő behelyezésre. Termelés. 6 Az átvételi tesztek2 alapvetően funkcionális tesztek a teljes rendszeren, és célja annak ellenőrzése, hogy a megállapított követelményeket . Végrehajtása a kliens számára opcionális, és ha nincsenek kifejezetten megadva, akkor a rendszertesztekben szerepelnek. Vagyis az elfogadási tesztek gyakran a felhasználó vagy az ügyfél felelőssége, bár bárki, aki részt vesz az üzletben, elvégezheti azokat. Az elfogadási teszteléshez olyan tesztkörnyezetre van szükség, amely az éles környezetet képviseli. Ez a fázis vagy szint mint kiindulási pont határozza meg a termékelfogadásnak a tanúsítási környezetben már kialakított alapvonalát. Rendszer tesztelése és elfogadása 19 ábra - Elfogadás ellenőrzése. 1 A jelenlegi helyzet vizsgálata átvételi tesztekben. A tesztek keretében ellenőriznünk kell a szoftvert, az egyik legfontosabb az átvételi tesztelés. Ezek azok a tesztek, amelyeket maga a fejlesztőcsapat fejleszt ki az elemzési fázisban meghatározott funkcionális követelmények alapján, hogy lefedje a teljes spektrumot és a végfelhasználó végezze el őket, de néhány felhasználó kivételével nem mindegyik rendelkezik olyan jelentős eredménnyel, érvényessége és megfelelősége a részükre leszállított terméknek az eredeti megállapodás alapján. A tesztelés alatt álló rendszer összetettségétől függően, függetlenül attól, hogy modulokra van osztva stb. ezeknek a teszteknek a végrehajtása eltérően történik. Ha az alkalmazást modulokra osztanák, akkor ezek alrendszernek minősülnének, és elég összetettek lennének ahhoz, hogy másként kezeljék őket, különböző átvételi teszteket kellene lefolytatni. 2 Az átvételi tesztelés célja Az átvételi tesztelés célja, hogy a végső vásárló elfogadja a terméket a gyártás megkezdése előtt. Amikor egy szervezet elvégezte a rendszerteszteket és kijavította a legtöbb hibáját, a rendszert jóváhagyásra átadják a felhasználónak vagy az ügyfélnek. Az átvételi tesztelés célja annak ellenőrzése, hogy a rendszer megfelel-e az elvárt teljesítménynek, és lehetővé teszi a rendszer felhasználója számára, hogy meghatározza az elfogadottságát a funkcionalitás és a teljesítmény tekintetében. Az átvételi teszteket a rendszer felhasználója határozza meg, és a fejlesztő csapat készíti elő, bár a végső végrehajtás és jóváhagyás a felhasználón múlik. A rendszerellenőrzés fekete doboz-tesztek futtatásával történik, amelyek igazolják a megfelelőséget, és szerepelnek egy teszttervben, amely meghatározza az elvégzendő ellenőrzéseket és a hozzájuk tartozó teszteseteket. Jelen terv célja, hogy a felhasználó által meghatározott összes funkcionális követelmény teljesüljön, valamint a teljesítménnyel, a rendszerelérés, az adatok és folyamatok, valamint a különféle rendszererőforrások biztonságával kapcsolatos nem funkcionális követelmények, 3 Átvételi tesztelés generálása. A rendszert a felhasználónak el kell fogadnia. Emiatt a rendszer strukturált specifikációi alapján az elemző olyan teszteseteket hoz létre, amelyeknek kielégítően kell megfelelniük. Mivel az elfogadási tesztek a tervezési és gyakorlati tevékenységekkel párhuzamosan is kidolgozhatók, normális, hogy ezeket a tevékenységeket az elemző kezdeményezi, amint a strukturált elemzési tevékenység befejeződött. 4 Elfogadási tesztelési stratégiák Ha a rendszert tömegpiacra tervezték, akkor nem lenne célszerű egyéni felhasználók vagy ügyfelek számára tesztelni, esetenként nem lenne lehetséges. Ezekben az esetekben visszajelzésre van szükség a termék eladása előtt. Az ilyen rendszerekben gyakran az átvételi tesztelés két szakasza van. Alfa- és béta tesztelés Amikor egyedi szoftvert készítenek egy klienshez, egy sor elfogadási tesztet hajtanak végre, hogy az ügyfél minden követelményt tesztelhessen. Az ügyfél a fejlesztési helyszínen végzi. A szoftvert természetesen a fejlesztő, mint a felhasználó figyelője használja, a regisztrációs hibákkal és a használati problémákkal együtt. Az alfa-teszteket ellenőrzött környezetben végzik. Ön ellenőrzött környezetben dolgozik, és az ügyfélnek mindig van egy szakértője, aki segít a rendszer használatában. A fejlesztő nyomon követi a talált hibákat és a használati problémákat. A Β-béta teszteket az α-alfa teszt után hajtják végre, és ügyfélkörnyezetben fejlesztik. Ebben az esetben a kliens egyedül marad a termékkel, és megpróbál olyan hibákat találni, amelyek tájékoztatják a fejlesztőt. Ezeket a szoftver végfelhasználói végzik az ügyfél munkaállomásain. Az alfateszttől eltérően a fejlesztő általában nincs jelen. Így a béta teszt a szoftver élő alkalmazása olyan környezetben, amelyet a fejlesztő nem vezérelhet. Az ügyfél naplózza a béta tesztelés során felmerülő összes problémát, és rendszeres időközönként jelentést küld a fejlesztőknek. 5 Az átvételi teszt bemenetei, kimenetei, feladatai és szerepei. A belépési követelmények meghatározása. Feladatok Készítse elő a tesztkörnyezetet. Javasoljuk, hogy az ilyen típusú teszteléshez legyen egy speciális tesztkörnyezet. Telepítés tesztkörnyezetben. Rendszertesztelés és tesztelés 22 Határozza meg az elvégzendő teszteket. A tesztek között fennálló lehetséges függőségek megállapításra kerülnek, és a tesztek végrehajtásának sorrendje vagy sorrendje ezeken a függőségeken alapul. Eredmények fogadása és rögzítése. Javítva a hibák és a hibák. Addig ismételje a feladatot, amíg az összes teszten át nem ment. Átvételi vizsgálati jegyzőkönyv készítése. Áttekintés az összes benyújtott teszt helyes végrehajtásáról és eredményeiről. Gyártóbázis létrehozása. A tevékenységek hivatalos lezárása. Vizsgálati eredmények. Elfogadott termék átvételi jegyzőkönyv. Projekt menedzser. Az elfogadási tesztelés középpontba állítása azzal a kísérlettel kapcsolatos, hogy megerősítsék azt a véleményt, hogy az ebbe a szakaszba integrált felhasználó korai szakaszban segítene javítani ezt a folyamatot a tesztelés tervezési és tervezési szakaszában, számos mennyiségi és kívánatos szempont későbbi javításával. , mint például: Az integrált szoftverbiztonság minőségének javítása. Költségminimalizálás. Megnövelt megbízhatóság a projekteredményekben. Ha kevesebb hibával rendelkező szoftvert használunk, nő az ügyfelek elégedettsége. Ez javítja a fejlesztési folyamat hatékonyságát. 7 Az átvételi vizsgálat kritériumai. A szoftverek elfogadását egy sor teszttel érik el, amelyek bizonyítják, hogy megfelelnek a követelményeknek. A tesztterv leírja az alkalmazandó teszt típusát, a vizsgálati eljárás pedig meghatározza a konkrét teszteseteket, mind a terv, mind az eljárás úgy van kialakítva, hogy minden funkcionális követelménynek megfeleljenek, minden viselkedési jellemző megvalósuljon, minden teljesítménykövetelmény teljesüljön, dokumentáció helyes és betartja a könnyű használat és egyéb követelményeket meghatározott követelményeket. 8 Átvételi tesztek eszközei. Ez lehetővé teszi az ügyfeleknek, a tesztelőknek és a programozóknak, hogy tudják, mit kell tenniük a szoftverüknek, és automatikusan összehasonlíthatják azt, amit valójában csinál. Lehetővé teszi, hogy olyan teszteket írjon, amelyek könnyen olvashatóak és könnyen karbantarthatók. Ezt a tevékenységet végső tesztnek vagy elfogadási tesztnek nevezik. Ehhez az átvételi teszt adatok bevitele és a tevékenység során létrehozott integrált rendszer szükséges. A tesztet a felhasználó valamely tagja vagy osztálya, vagy akár egy független minőségellenőrzési osztály végzi. Fontos megjegyezni, hogy minden korábbi elemzési, tervezési és megvalósítási tevékenységnél fontos minőség-ellenőrzési tevékenységeket végezni annak érdekében, hogy azok a megfelelő minőségi szinten megtörténjenek. Ez biztosítja, hogy az elemző minőségi specifikációkat, a tervező minőségi terveket, a programozó pedig minőségi kódolási programokat készítsen. A számítástechnikában az implementáció egy műszaki specifikáció vagy algoritmus, például program, szoftverkomponens vagy más számítógépes rendszer. Sok megvalósítást specifikáció vagy szabvány szerint biztosítanak. Összefoglaljuk a szerzők korábbi munkáját, hogy olyan tesztcélokat kapjunk, amelyek az automatizált tesztek kidolgozásának kiindulópontját jelentik. A használati esetekből történő rendszerteszttel összefüggésben a tesztelés célja használati esetként fejezhető ki. Ez a forgatókönyv egy lehetséges alternatíva nélküli lépéssorozatból és egy tesztérték-készletből áll, és előfeltételekés az ehhez a forgatókönyvhöz kapcsolódó utókonferenciák. A tesztforgatókönyvek generálásához először egy tevékenységdiagramot építenek fel a fő sorozatból, valamint a használati eset hiba- és alternatív sorozataiból. A tevékenységdiagramban a rendszer által végrehajtott cselekvések és a résztvevők által végrehajtott cselekvések sztereotipizáltak. Ezután az útvonalelemzés végrehajtásra kerül, és minden tevékenységdiagram útvonal egy használati eset forgatókönyve lesz, és ezért potenciális tesztcélpont lesz. 2 Rendszertesztek végrehajtása. Rendszertesztelési architektúra. A rendszertesztek végrehajtásának és automatikus érvényesítésének architektúrája a 7. ábrán látható. Ez az architektúra hasonló a más típusú tesztek, például az egységtesztek automatizálásához szükséges architektúrához. A fő különbség az, hogy az egységtesztben maga a teszt hívja meg a végrehajtható kódot, míg a tesztrendszer funkcionális tesztje és teszt elfogadása 27 olyan közvetítőt igényel, aki tudja, hogyan kell kezelni a külső interfészét. Tesztesetek megvalósítása. A teszt-teszt a tesztelés céljának megvalósítása. A teszteset általános viselkedését az Általános teszteset-viselkedés táblázat tartalmazza. Minden használati eset hozzá lesz rendelve egy tesztkészlethez. Ez a csomag teszteket tartalmaz az említett használati eset összes forgatókönyvéhez. Amint a teszt céljaiból kiderül, minden lépést meg kell határozni, hogy azt egy szereplő vagy a vizsgált rendszer hajtja végre. Ez az információ nagyon fontos a csomagtesztelési módszerek kódolásakor. A szereplő által végrehajtott összes művelet a tesztkód kódját a teszteset és a rendszer közötti interakcióvá alakítja át. Rendszertesztelés és átvételi tesztelés 29 A szükséges tesztértékek meghatározásához működési és kategóriaváltozós módszert kell alkalmazni. Hármat azonosítottak különféle típusok működési változók. A tesztesetekben minden típus másként kerül megvalósításra. Az első típus azokból a működési változókból áll, amelyek egy külső entitás által a rendszerbe történő információtovábbítást jelzik. Minden ilyen típusú változóhoz egy új osztály kerül meghatározásra, amelynek objektumai különböző tesztértékeket tartalmaznak ehhez a változóhoz. Az esettanulmányban látható egy példa erre a típusú munkaváltozóra. A második típus azokból a műveleti változókból áll, amelyek a külső szereplő számára elérhető több lehetőség közötti választást jelzik. Ehelyett egy ilyen választás közvetlenül a szereplő és a rendszer közötti interakciót megvalósító kód részeként valósul meg. A harmadik típusba azok a működési változók tartoznak, amelyek a rendszer állapotát jelzik. A teszteset beállítási módszerének megvalósításához írja be a szükséges kódot a rendszerállapotokat leíró műveleti változók értékének helyes beállításához, vagy annak ellenőrzéséhez, hogy az értékek egyeznek. Hasonlóképpen, a törés módszernek vissza kell állítania ezeket az értékeket eredeti állapotukba. Ezenkívül a nyomkövetési módszernek szükség esetén ki kell zárnia a teszteset által a teszteset végrehajtása során a rendszerbe bevitt információkat. Az esettanulmányban számos példa látható az ilyen típusú műveleti változókra. Ebben az esetben az első dolga, hogy alkalmazza a látottakat, hogy megkapja a tesztcélok halmazát a használati esetből. Ezután meg kell határozni a használt tesztheveder jellemzőit. Végül alkalmazzuk a benne látottakat korábbi szakaszok a teszteset megvalósításához a tesztcélból. A tesztelt rendszer műtermékeit azonosították angol nyelv, Amennyiben spanyol a használt eszközök nem támogatják. A 2. táblázat használati esete egy új hivatkozás bevezetését írja le a rendszerben. Kiegészítésként megjelenik az egyes hivatkozások által kezelt információkat leíró információk tárolásának követelménye is. A használati esetből és automatikusan generált egy sor forgatókönyvet, amely az említett használati eset tesztelésének célpontja lesz. Tekintettel arra, hogy a használati eset korlátlan számú ciklust tartalmaz végtelen számú potenciális ismétléssel, az utak megszerzéséhez választott lefedettségi kritérium a 01-es kritérium, amely ellenőrzi és teszteli a 30-as rendszer tesztjeit, és minden lehetséges útvonalat meg kell szerezni az egyetlen vagy egyszeri ismétlődéshez. az egyes hurkok. A táblázatban felsoroljuk az ezzel a feltétellel kapott és spanyolra fordított összes szkriptet. Ehhez az esettanulmányhoz a 09. forgatókönyvet választottuk, amelynek végrehajtását az 5. táblázat részletezi. Tesztelés és tesztelés a tesztelés során 31 Táblázat Információk Hivatkozási követelmény. Használhatja a kategóriafelosztás módszerét is. Az egyes változókhoz tartozó szakaszokat a táblázat tartalmazza. Rendszertesztelés és tesztelés 32 A használati esethez definiált táblázatváltozók. Tesztelés és tesztelés a tesztelésben 33 Az azonosított változók kategóriáinak táblázata. A 7. ábrán leírtak szerint a kábelköteg-tesztet úgy tervezték, hogy szimulálja a felhasználói viselkedést, és utasításokat kínáljon az eredmény értékeléséhez. Ez a fordítás jelenleg manuálisan történik, és a táblázatban látható. Az adó-vevő tesztelése és tesztelése 35 ábra A teszteset megvalósítása. A fő forgatókönyvben a felhasználó által végrehajtott lépések lefordítása végrehajtható kódra. Vagyis megbizonyosodni arról, hogy a kategóriák léteznek, és nem okoznak hibát a kategóriák visszaállítása vagy új hivatkozás beillesztése során. A break módszer megvalósítása a rendszerben tárolt eredeti hivatkozáskészlet visszaállítása volt. 2 Átvételi tesztek végrehajtása. Az átvételi tesztek csak az ügyfélszolgálattal működnek, vagy legalábbis egy proxyval, hogy az ügyfél meghatározza a feltételeket. Az illesztőprogram elfogadási kritériumai nélkül nehéz lesz ellenőrizni, hogy a megfelelő szoftvert készíti-e. Az ügyfélnek és a fejlesztőcsapat összes tagjának össze kell jönnie, hogy meghatározza a rendszert egy sor "szkriptben", amelyek leírják, hogy a rendszernek mit és hogyan kell csinálnia. Az egyértelmű követelményekkel és jóváhagyási feltételekkel rendelkező tesztek létrehozásával a szoftver nagyobb valószínűséggel felel meg a vásárlók elvárásainak. Ez azonban azt jelenti, hogy valaki manuálisan ellenőrzi, hogy a követelmények teljesülnek-e, és az alkalmazás az elvárásoknak megfelelően működik-e. Itt jönnek be az automatizált elfogadási tesztek a régi dokumentum követelményei helyett, a követelmények példaként és forgatókönyvként vannak meghatározva, a forrásvezérlésben telepítési melléktermékekkel védettek, és bármikor lefuttathatók annak ellenőrzésére, hogy megfelelnek-e a követelményeknek és megfelelően működnek-e. Ugyanezt a megközelítést használhatja tesztek írásakor is, de ahelyett, hogy tesztesetkezelő szoftverbe vagy táblázatba gépelné be őket, írja be közvetlenül a kódba. Rendszertesztelés és tesztelés 37 1 Automatikus átvételi tesztelés. Ezért minden új funkció bevezetésének első lépése, hogy egy teszttel leírja az elvárásait. Mások nem, és az idő múlásával a folyamatirányítással küszködnek, különösen akkor, amikor a bizonyítékok gyarapodnak, és a tesztelési rugalmasság kezd romlani. A tesztvezérelt megközelítés azon alapul, hogy mely teszteknek kell irányítaniuk egy szoftvertermék fejlesztését. Az ipari szoftvertermékekben, amikor követelménymérnöki módszereket alkalmaznak, többnyire természetes nyelvet támogatnak, ami a kétértelműség jól ismert kellemetlenségével jár. Az érvényesítés szükségessége azonban meghaladhatja azokat az előnyöket, amelyeket egy formálisabb és szigorúbb követelményspecifikáció kínálhat. Az ügyfélnek el kell tudnia olvasni és meg kell értenie a követelményeket, hogy el tudja fogadni azokat. A követelmények meghatározásának legnépszerűbb módszerei a Használati esetek és felhasználói történetek részben találhatók. A követelmények meghatározása az ügyfél vonzásának kulcsa. Követelmények - az elérési cél, vagyis az, amit az ügyfél elvár a szoftverterméktől. Rendszertesztelés és tesztelés 38 szerepkör a követelmények specifikációjával, valamint az érvényesítési és átvételi teszteléssel kapcsolatos. A követelmények fogalma az elfogadási tesztek konténerévé válik, és ezek azok, amelyek az egyes követelmények specifikációjaként a központi szerepet töltik be. Vegye figyelembe a „Pénz felvétele” követelményt az ATM-ekkel kapcsolatban. Egy tipikus leíró specifikáció a következő lehet: Az ügyfélnek képesnek kell lennie arra, hogy meghatározott összegben készpénzt vegyen fel a pénztárosból. Mindig kapjon nyugtát, ha a pénztárosnak nincs papírja. Ha a kiemelt ügyfélről van szó, akkor visszavonhatja több pénz mint amennyi a fiókjában van, de figyelmeztetni kell, hogy százalékos terhelést kell fizetnie. Az ügyfélnek az elállás megerősítése előtt bármikor lemondhatja az elállást. Az összegeket a pénztáros számláival kell kezelni, más összegeket nem szabad elfogadni. Ábra – Specifikációs alternatívák A 10. ábra néhány specifikációs alternatívát mutat erre a követelményre. Az ikonok az egyes specifikációk kényelmét tükrözik. Érdekes lehet egy szekvenciadiagram kidolgozása, amely meghatározza az egyes forgatókönyveket egy követelmény teljesítéséhez, azonban ez általában nem megfelelő, mert egy nagy szám generált diagramok. Érdekesebb a forgatókönyvek azonosítása, mint mindegyiket diagramon ábrázolni. A narratív leírás nem egyszeri, legalábbis a számára rövid meghatározás követelményeknek, amely az érintett fogalmak meghatározására összpontosít. A használati modell azonban nem alkalmas egy szoftvertermék részletes követelménystruktúrájának szemléltetésére hosszú távú karbantartási környezetben, mert egy átlagos szoftverterméknek több ezer követelménye lehet. Megfelelőbb mechanizmusokra van szükség számos követelmény megjelenítéséhez és kezeléséhez. A sablonok az egyik leggyakrabban használt alternatíva a használati esetekhez. A sablonok elegánsak és rendet biztosítanak a specifikációnak. Ezek azonban általában kontraproduktívak, mivel általában egyetlen szintű részletfeldolgozást biztosítanak minden követelményhez. Ezekben a nagyon egyszerű esetekben olyan dolgokat is tartalmaznak, amelyek nyilvánvalóak vagy lényegtelenek, csak hogy lefedjék a sablon összes részét. Ha egy követelmény több szkriptet is tartalmaz, a sablon összes parancsfájljának szintetizálása általában zavaros specifikációkat eredményez. Ily módon a követelmények konténerként működnek az ország számára. A követelményektől függően a specifikáció egyéb további formái is hasznosak lehetnek. Például egy tevékenységdiagram, ha a követelményhez társított viselkedés algoritmikus szimbólummal rendelkezik, vagy egy állapotdiagram, ha a viselkedés magában foglalja a műveletek engedélyezését vagy letiltását a rendszerállítások és a rendszerelfogadási tesztek szerint. Alapvető feltétel a specifikáció pragmatizmusa, amely nem zárja ki a specifikáció alternatíváinak megosztását, de az elsődleges kritérium a nyereségesség és a specifikáció fenntartásához való hozzájárulás. Másrészt az arra irányuló erőfeszítések tekintetében karbantartás, különösen a következetesség szempontjából fontos, hogy ne használjuk túlzottan a specifikációk sokszorosítását vagy megkettőzését különböző eszközökkel reprezentáció. Az irányított gráf megfelelő reprezentáció a szintfinomításhoz. Ez a grafikon lehetővé teszi a követelmények közötti bontási kapcsolatok és függőségek megjelenítését. Így minden csomópont funkcionális vagy nem funkcionális követelmény. A csomópontok közötti ívek kapcsolatokat hoznak létre a szülők és a gyerekek között, vagy "csomópontokat befolyásoló csomópontok" függőségi kapcsolatokat. Így a fenti példában a „Pénzfelvétel” követelmény a követelménystruktúra csomópontja lehet. Visszaküldés a vásárló által megadott mennyiséggel. Nincs jegy. Nincs átvehető papír. Túllépték a központi rendszerrel való kommunikációs időt. Értesítés a pénztáros belső működéséről. Időtúllépés történt a művelet kezdeményezéséhez. Ez kapcsolódhat funkcionális vagy nem funkcionális követelményhez. Nem kötelező, és a tesztlépések alkalmazása előtti előfeltételek beállítására szolgál. Ezek a cselekvő és a rendszer interakciós tevékenységei. Ha több műveletet hajtanak végre, akkor egy számozott listára kerülhetnek. Ez a színészi interakciók hatása. Minden egyes művelet egy vagy több eredményt okozhat. Fontos, hogy amikor a felhasználónak küldött üzenetekről van szó, a szöveg a várt eredmény részeként szerepeljen, így a programozó ezt az információt már ellenőrizte a klienssel. Ez, amint az alábbiakban rámutatunk, megteremti a követelmények közötti függőséget. Feltétel Normál ügyfélnek kell lennie. Lépések  Próbáljon meg visszatéríteni egy normál ügyfélnek, és kérjen egyenleget meghaladó összeget.  Várható eredmény. Rendszer tesztelés és elfogadás 42  Megjelenik a "A kért mennyiség meghaladja az aktuális egyenlegét, adja meg újra a mennyiséget" üzenet, és visszatér a mennyiség megadására szolgáló ablakba. Az elfogadási tesztelés segít megbizonyosodni arról, hogy az ügyfél által kívánt alkalmazást készíti-e, míg ezeknek a szkripteknek az automatizálása lehetővé teszi az alkalmazás folyamatos tesztelését a fejlesztési folyamat során, és a regressziós tesztelési csomag részeként történő felhasználását annak biztosítására, hogy a jövőbeni változtatások ne szakítsák meg a jelenlegit. követelmények. Azonban, ha egy klienst a bizonyítékok összeállításához, különösen az automatizált teszteléshez társítanak, számos lehetséges problémát vet fel. Az ügyfelek általában nem műszakiak, és hajlamosak elhatárolódni magától a szoftverfejlesztéstől. Az ügyfél szolgáltathat adatokat és példákat, míg a tesztelők vagy a fejlesztők gyorsan kódolhatnak szkripteket és végrehajtható specifikációkat. Felhasználói felület elfogadási tesztek A példákban az elfogadási tesztek az üzleti logikára és a tartományobjektumokra összpontosítottak, hogy megnézzék, a logika sikeresen működik-e. De mi a helyzet azzal, hogy a felhasználó hogyan lép kapcsolatba az alkalmazással? Ezeknek az elfogadási teszteknek a logika helyességének tesztelésére kell szolgálniuk a felhasználó szemszögéből, a felhasználó szemszögéből pedig a felhasználói felület. Ha az alkalmazás jó szétválasztással rendelkezik, és a logikát jól választja el a felhasználói felület kódjától, ez megkönnyíti a tesztek végrehajtását. Ha ezen a szinten tesztel, a tesztek nem változnak a felhasználói felületen. Bár a tesztelésnek kizárólag a logikára kell összpontosítania, ez nem jelenti azt, hogy ne menjen át az elfogadási teszteken a teljes felhasználói felületen. Szeretek füstteszteket végezni, amelyek egy alapvető felhasználói felületre irányulnak." boldog út". Az alkalmazás azon részeire összpontosítanak, amelyeket a felhasználók a legnagyobb valószínűséggel használnak annak érdekében, hogy a legtöbbet hozzák ki az élményből. legkisebb mennyiségben tesztelés. Ha megpróbál mindent lefedni lehetséges módjaiés a felhasználói felület használata, és ha a felhasználói felület megváltozik, akkor az összes tesztet módosítania kell. Például, ha egy e-kereskedelmi webhely felhasználói felületét teszteli, az út örömmel kiválaszt egy terméket, hozzáadja a kosárhoz, megnézi, és megjelenik a vásárlás visszaigazolása. Ha ez a forgatókönyv kudarcot vall, érdemes minél hamarabb kideríteni. Bizonyos alkalmazások esetében – a bonyolultságtól és az élettartamtól függően – érdemes több elfogadási tesztet végezni a felhasználói felületen, hogy megbizonyosodjon arról, hogy jobban bízik a felhasználói felület rétegében. A sikeres felhasználói felület tesztelése azonban igen nehéz kérdésés nincs helyem letakarni. Rendszerek tesztelése és elfogadása 43 3Intelligens tesztek. Miután világos és érthető formában elmondta a történetet és a forgatókönyveket, a következő lépés a történet és a forgatókönyvek automatizálása. Ez lehetővé teszi számukra, hogy a fejlesztés során futhassanak a fejlődés nyomon követésére és a regressziós hibák észlelésére. Következtetések és ajánlások. Másrészt vannak olyan rendszertesztjeink, amelyek a teljes folyamat során a működés kiértékeléséért felelősek, az ehhez esetlegesen előforduló hibák felderítéséhez szükséges egy tesztekkel ellátott stratégia kidolgozása és a kódfejlesztés elkülönítése az interfészfejlesztéstől, így az a legjobb a rendszertesztek végrehajtása. E két szoftverteszt megvalósítását szigorú, meghatározott szabványoknak megfelelő tesztekkel, a rendszer fejlesztésében érintett szereplők koordinálásával kell végrehajtani. Rendszertesztelés és elfogadás 44 Bibliográfia 1. Isabelle Ramos Roman, José Javier Dolado Cosin. Kvantitatív menedzsment módszerek a szoftverfejlesztésben. Alonso Amo, Loic Martinez Normand. Bevezetés a szoftverfejlesztésbe. Rendszertesztelés és átvételi tesztelés 45 8. Számítógépes nyelvek és rendszerek tanszéke. Szerkezeti rendszer elemzése. Baktériumok azonosításának módszerei a mikrobiológiai laboratóriumban.