Szoftvertermék tesztelése. Hogyan tesztelhető egy olyan függvény működőképessége, amely más függvényeket használ? Változással kapcsolatos tesztelés

Még ha annyira toleráns is, hogy fél órán belül egy összeomlás után 18-szor újraindíthatja a programot, és csak ezután dobhatja a monitort közvetlenül az ablakhoz, akkor is egyetért azzal, hogy kényelmesebb lenne ezzel a programmal dolgozni, ha nem "összeomolna" ” .

Hogyan biztosíthatja, hogy az Ön által fejlesztett program összeomlása, lefagyása vagy a szükséges műveletek végrehajtásának elmulasztása nagyon ritka legyen?

Erre a kérdésre nincs pontos válasz. Ám az évszázadok során a legbölcsebb tudósok évekig gondolkodtak ezen a témán, és sikerült olyan gyógymódot találniuk, amely, ha nem szünteti meg az összes programhibát, legalább azt az illúziót kelti, hogy a cselekvést megszüntesse.

És ezt a gyógymódot úgy hívják A szoftvertermék TESZTELÉSE.

A bölcsek szerint a tesztelés az egyik legmegbízhatóbb módja a fejlesztés minőségének biztosításának szoftverés egy hatékony eszközkészlet része modern rendszer a szoftvertermék minőségének biztosítása.

A szoftvertermék minőségét olyan tulajdonságok összessége jellemzi, amelyek meghatározzák, hogy a termék mennyire „jó” az érintettek, így a termék vásárlója, szponzora, végfelhasználója, termékfejlesztői és tesztelői, támogató mérnökei, marketingje szempontjából. , képzési és értékesítési személyzet. A résztvevők mindegyikének más és más elképzelése lehet a termékről, illetve arról, hogy az mennyire jó vagy rossz, vagyis milyen magas a termék minősége. Így a termékminőség biztosításának problémafelvetése az érintettek, azok minőségi kritériumainak azonosítását, majd az ezeknek a kritériumoknak megfelelő optimális megoldás megtalálását eredményezi.

Mikor és ki?

A tapasztalt fejlesztők szerint egy szoftvertermék tesztelését a létrehozásának legelején el kell végezni. Ugyanakkor maguk a tapasztalt fejlesztők nem vehetnek részt a tesztelésben, mivel ez nem királyi ügy. A szoftverterméket speciálisan képzett, tesztelőknek nevezett munkatársaknak kell tesztelniük, mert a legtapasztaltabb fejlesztő sem fogja látni a hibáját, még a legújabb optikai műszerek használatával sem.

Azonban minden fejlesztő egyetért abban, hogy egy szoftvertermék tesztelését a cél szerinti osztályozás szempontjából két osztályba kell osztani:

• Funkcionális tesztelés
• Nem funkcionális tesztelés

Funkcionális tesztelés

A funkcionális tesztelés annak ellenőrzését jelenti, hogy egy szoftvertermék megfelel-e a termék létrehozásához szükséges műszaki specifikációban meghatározott funkcionális követelményeknek. Leegyszerűsítve, a funkcionális tesztelés ellenőrzi, hogy a szoftvertermék teljesíti-e az összes szükséges funkciót.

Tehát végül úgy döntött, hogy funkcionális tesztelést végez. Belenézel a műszaki specifikációba, elolvasod a funkcionális követelményeket, és rájössz, hogy ezek legalább nem abban a sorrendben vannak, ahogy a tesztelést el lehet végezni. Meg fog lepődni, hogy nagyon régen mások már észrevették ezt az eltérést, és rájöttek, hogyan lehet ezt leküzdeni.

A funkcionális teszteléshez a műszaki ellenőrzési osztály munkatársai dokumentumprogramot és módszertant fejlesztenek az alkalmazás (API) funkcionalitásának tesztelésére. A PMI-dokumentum a szoftvertermék-tesztelési forgatókönyvek (tesztesetek) listáját tartalmazza Részletes leírás lépések. A tesztelési forgatókönyv minden lépését a felhasználó (tesztelő szakember) tevékenységei és a várt eredmények – a program válasza ezekre a műveletekre – jellemzik. A tesztprogramnak és módszertannak szimulálnia kell a szoftvertermék valós üzemmódban történő működését. Ez azt jelenti, hogy a tesztelési forgatókönyvet a rendszer jövőbeli felhasználói által elvégzendő műveletek elemzése alapján kell felépíteni, nem pedig egy mesterségesen összeállított, csak a fejlesztő számára érthető manipulációs sorozatot.

A funkcionális tesztelést általában két szinten hajtják végre:

• Alkatrész (egység) tesztelése. Egy szoftvertermék egyes összetevőinek tesztelése, különös tekintettel azok sajátosságaira, céljára és funkcionális jellemzőire.
• Integrációs tesztelés. Ez a típus A tesztelést az alkatrészek tesztelése után hajtják végre, és célja a különböző alrendszerek interakciójában fellépő hibák azonosítása a vezérlési áramlások és az adatcsere szintjén.

Nem funkcionális tesztelés

A nem funkcionális tesztelés értékeli a szoftvertermékek tulajdonságait, például az ergonómiát vagy a teljesítményt.

Úgy gondolom, hogy az ilyen típusú tesztelés fontossága egyértelmű, és nem igényel indoklást. Hiszen mindenki megérti, hogy ha például a rendszer teljesítménye nem elegendő, akkor a felhasználóknak fél napot kell várniuk a cselekvéseikre adott válaszra, ami tömeges hibernáláshoz vezethet.

Ahogy a neve is sugallja, a nem funkcionális tesztelés ellenőrzi, hogy egy szoftvertermék megfelel-e a nem funkcionális követelményeknek. feladatmeghatározás létrehozásához. És a funkcionális teszteléshez hasonlóan a nem funkcionális teszteléshez tesztprogramot és módszertant dolgoznak ki.

Beágyazott szoftvertesztelés és megfelelőség az agilis korszakban

Az ipari szabványoknak való megfelelést nem lehet elhanyagolni vagy később megtenni; a beágyazott szoftver (szoftver) fejlesztési folyamat szerves része. Egyes iparágak – például a repüléselektronika, az autóipar és az egészségügy – számára a minőségi szabványok szigorú betartása az összetett és problémamentes beágyazott rendszerek fejlesztése során létfontosságú a termék piacra kerüléséhez. Hagyományosan a tesztelés fontos szerepet játszott a szabványok által szabályozott iparágak beágyazott rendszereinek fejlesztésében. Az elmúlt években azonban jelentősen megváltoztak a kialakult tesztelési gyakorlatok és folyamatok, ezek helye és szerepe az ilyen projektekben. Ez egy játékmódosító volt, és amikor megváltoznak a játékszabályok, akkor változni kell velük a győzelemhez.

Az új, élvonalbeli technológiák folyamatos fejlesztésével a cégeknek gyorsan olyan termékeket kell piacra ajánlaniuk, amelyek megbízhatóak, biztonságosak, könnyen használhatóak és kompatibilisek más rendszerekkel – csak azért, hogy ne vesszenek el a gyorsan változó technológiai világban. Ilyen helyzetben a hagyományos vízesés modell, ahol a szoftverfejlesztési folyamat szigorúan szekvenciális, és a tesztelés a legvégén történik, a múlté válik. A DevOps és az Agile módszerek egyre népszerűbbek, mert lehetővé teszik a mérnökök számára, hogy egyidejűleg hajtsanak végre olyan feladatokat, amelyek korábban egymást követték.

Teljesítményfelmérés

A teljesítményteszt során az első lépés a terhelési tesztelés, melynek célja annak ellenőrzése, hogy a rendszer megfelelően reagál-e a külső hatásokra a valós működéshez közeli üzemmódban.

A terhelési tesztelés mellett a teszteket minimális hardver és maximális terhelés - stresszteszt -, valamint maximális feldolgozott információmennyiség - volumetrikus tesztelés - körülmények között végezzük.

A tesztelésnek van egy másik típusa is: a stabilitási és megbízhatósági tesztelés, amely nemcsak a szoftvertermék normál körülmények közötti hosszú távú tesztelését foglalja magában, hanem azt is, hogy rövid ideig tartó stresszes terhelések után képes-e visszatérni a normál működésre.

Dokumentáció a teszteléshez

Amint fentebb említettük, a tesztelést a GOST 34.603-92 szabvány szerint kidolgozott program és vizsgálati módszertan szerint végezzük.

Tesztelés céljából fejlesztünk próbaper, amelynek elegendő adatot kell tartalmaznia a szoftvertermék összes működési módjának ellenőrzéséhez. Jellemzően valós adatok alapján készítenek tesztesetet a megrendelő és a kivitelező közösen.

Minden típusú teljesítményteszt elvégzéséhez leggyakrabban úgynevezett adatgenerátort hoznak létre, amely lehetővé teszi automatikus üzemmód kellő mennyiségű adat létrehozása az objektív eredmény eléréséhez a teljesítmény értékelése során.

A tesztelés során vizsgálati jegyzőkönyv készül, amely a tesztelés valamennyi szakaszának, lépésének befejezéséről és a tesztelés során kapott észrevételekről tartalmaz információkat.

Ha a vizsgálat eredménye negatív, a hiányosságokat kijavítják és újra tesztelik.

Feltáró tesztelés

Feltáró tesztelés (az ad hoc tesztelés a funkcionális tesztelés egyik altípusa. Gyorsan növekvő, rugalmas fejlesztési módszerekkel rendelkező projektekben alkalmazzák, ahol nincsenek egyértelmű dokumentációk és követelmények. A feltáró tesztelés a legmagasabb műrepülés a szoftvertesztelésben. Kvalitatív tesztelés áll rendelkezésre a magasan kvalifikált szakemberek, és szinte teljes mértékben az előadón, tapasztalatán, tudásán (mind a témakörben, mind a tesztelési módszerekben) és a lényegre való gyors rátérési képességén múlik.

Stressz tesztelés

A terhelési tesztelés az a folyamat, amely a tesztelt rendszer terhelés alatti teljesítményét elemzi. A terhelési tesztelés célja az alkalmazás külső terhelésekkel szembeni ellenálló képességének meghatározása. A vizsgálatokat általában több szakaszban végzik el.

1. Teszt szkriptek generálása

A hatékony elemzés érdekében a forgatókönyveknek a lehető legközelebb kell állniuk a tényleges felhasználási esetekhez. Fontos megérteni, hogy kivételek mindig lehetségesek, és előfordulhat, hogy még a legrészletesebb vizsgálati terv sem fed le egyetlen esetet.

2. Tesztkonfiguráció kidolgozása

A tesztforgatókönyvek birtokában fontos a növekvő terhelés sorrendjének elosztása. A sikeres elemzéshez meg kell határozni a teljesítmény értékelési kritériumait (válasz sebessége, kérés feldolgozási ideje stb.).

3. Tesztvizsgálat elvégzése

A tesztek lefolytatása során fontos, hogy időben figyelemmel kísérjük a forgatókönyvek végrehajtását és a tesztelt rendszer reakcióit. A nagy terhelések emulálása komoly hardver- és szoftverinfrastruktúrát igényel. Egyes esetekben matematikai modellezési módszereket alkalmaznak a munka költségeinek csökkentése érdekében. Az alacsony terhelésnél kapott adatokat vesszük alapul és közelítjük. Minél magasabb a szimulált terhelés szintje, annál kisebb a becslés pontossága. Ez a módszer azonban jelentősen csökkenti a költségeket.

Tesztautomatizálás

Az automatizált tesztelés fő jellemzője a regressziós tesztek gyors elvégzésének képessége. Az automatizálás fő előnyei (a Worksoft jelentése szerint) a megnövekedett személyzeti hatékonyság, a hibák korai felismerése stb. jó minőségüzleti folyamatok. Ezeket az előnyöket egy jelentős hátrány ellensúlyozza: magas költség – a tesztautomatizálás megvalósításának és támogatásának magas költsége miatt a cégek mintegy 50%-a továbbra is elsősorban kézi tesztelést alkalmaz.

Használhatósági tesztelés

Bármely alkalmazás létrejön, hogy használható legyen. A könnyű használhatóság a program fontos minőségi mutatója. Az IT-ipar számos példát tud arra, hogy egy sikeres használhatósági javítást követően elindultak a projektek. Minél szélesebb a közönség, annál fontosabb a használhatósági tényező. A használhatóság tesztelése magában foglalja a felhasználói viselkedés részletes elemzését. Az ergonómia értékeléséhez fontos, hogy ne csak az üzleti feladat elvégzésének sebességéről rendelkezzünk adatokkal, hanem a felhasználó érzelmeiről, arckifejezéseiről és hangszínéről is.

Konfiguráció tesztelése

A konfiguráció tesztelése bizonyosságot ad arról, hogy az alkalmazás különböző platformokon fog működni, és ezáltal a felhasználók maximális száma számára. A WEB-alkalmazások esetében általában a böngészők közötti tesztelést választják. Windows alkalmazásokhoz - különféle tesztelés operációs rendszerés bitméretek (x86, x64). A konfiguráció tesztelésének fontos összetevője a teszt infrastruktúra: a tesztek elvégzéséhez folyamatosan karban kell tartani a tesztgépek flottáját. Számuk 5-től több tucatig változik.

Integrációs tesztelés

Ha a projekt egynél több összetevőt tartalmaz, akkor integrációs tesztelésre van szükség. Összetett alkalmazásarchitektúra esetén a minőségbiztosítás elengedhetetlen feltétele a programrészek interakciójának ellenőrzése. A tesztelést az „end-to-end” esetek kidolgozásával és lebonyolításával érik el. Az integrációs tesztelés az alkatrészek tesztelése után történik. Ezért nagyon fontos az alkatrésztesztelés tapasztalatainak figyelembe vétele, a tesztesetek üzleti orientációjának tiszteletben tartása mellett.

Stressz tesztelés

Minden rendszernek van határa normál működés. A határérték túllépése esetén a rendszer stresszállapotba kerül, és jelentősen megváltoztatja viselkedését. A stresszteszt egy alkalmazás működését teszteli a normál működési határokat meghaladó körülmények között. Ez különösen fontos a „kritikus” programok esetében: banki szoftverek, légiközlekedési ipari programok, orvostudomány. A stressztesztet nemcsak a szoftverfejlesztési szakaszban végzik, hanem a teljes működési ciklus során is, hogy hosszú időn keresztül megkapják és feldolgozzák a rendszer viselkedési adatait.

Tegyük fel, hogy van egy get-data függvény, amely egy térképet ad vissza az átadott felhasználói azonosítóról. Most ez a függvény 3 forrás-a, forrás-b és forrás-c függvényt használ három különböző típusú térkép előállításához. Most ezeket a térképeket egyetlen térképbe fogjuk egyesíteni, és visszatérünk az adatok lekéréséhez.

Amikor tesztelem a get-data-tellenőriznem kell a kulcsokhoz tartozó adatok elérhetőségét? Van értelme ennek a függvénynek meghiúsítani az egységteszteket, ha a forrás-a, forrás-b és forrás-c egyike meghiúsul? Ha ennek a funkciónak az a feladata, hogy adatokat egyesítsen, és ez megtörténik, annak elégnek kell lennie, nem?

1

2 válasz

Tegyük fel, hogy létezik egy get-data függvény, amely visszaadja az átadott felhasználói azonosító adatainak térképét.

Nagy. Akkor meg kéne nézni. Adott azonosítóhoz a megfelelő adatokat adja vissza?

most ez a függvény 3 forrás-a, forrás-b és forrás-c függvényt használ három különböző típusú térkép előállításához.

Melyik megvalósítási részletet érdemes figyelmen kívül hagyni a teszt során. Csak azt teszteli, hogy a munkaegysége (ez a módszer) azt csinálja, amit tennie kell (vesz egy azonosítót, és XYZ adatokat ad vissza ehhez az azonosítóhoz). Hogyan ez a módszer nem igazán számít – elvégre ennek az egységtesztnek az a fő előnye, hogy újra tudja alakítani a módszer megvalósítását, és a teszt ellenőrzi, hogy helyesen végezte-e el.

Valószínűleg azonban ki kell gúnyolnia az adatforrásokat, így egy bizonyos ponton a tesztnek valószínűleg tudnia kell, hogyan működik ez a kód. Itt három versengő célt kell egyensúlyba hoznia: a teszt izolálását (az adatok gúnyolásával), miközben a teszt a követelményekre és a pragmatizmusra összpontosít.

Végül is ez egy fontos kód. Vannak tesztek, amelyek támogatják a tényleges kódot, sok időt töltenek el, és a polírozás ellenőrzése nem olyan hasznos, mint a tesztek készítése .

Az egységtesztben csak egy osztály funkcionalitását szabad tesztelni, ha a forrás-a, forrás-b és forrás-c metódusok más osztályokat hívnak, akkor azokat ki kell gúnyolni (az osztályokban egységtesztelt kell tenni).

Az integrációs tesztelés során több, közöttük kölcsönhatásba lépő osztály viselkedését teszteli, ami azt jelenti, hogy a get-data függvénynek ellenőriznie kell, hogy a beolvasott adatok helyesek (forrás-a, forrás-b és forrás-c helyesek és az adatok megfelelően vannak csatlakoztatva).

Az egységtesztek egyszerűbbek és célzottabbak, és ezeket a fejlesztőknek kell megírniuk. Az integrációs tesztek általában viszonylag gyorsan elavulnak (ha vannak ilyenek). belső komponens megváltozott), megnehezítve azok végrehajtását. Minőségbiztosítási profillal kell létrehozni.

Még ha annyira toleráns is, hogy fél órán belül egy összeomlás után 18-szor újraindíthatja a programot, és csak ezután dobhatja a monitort közvetlenül az ablakhoz, akkor is egyetért azzal, hogy kényelmesebb lenne ezzel a programmal dolgozni, ha nem "összeomolna" ” .

Hogyan biztosíthatja, hogy az Ön által fejlesztett program összeomlása, lefagyása vagy a szükséges műveletek végrehajtásának elmulasztása nagyon ritka legyen?

Erre a kérdésre nincs pontos válasz. Ám az évszázadok során a legbölcsebb tudósok évekig gondolkodtak ezen a témán, és sikerült olyan gyógymódot találniuk, amely, ha nem szünteti meg az összes programhibát, legalább azt az illúziót kelti, hogy a cselekvést megszüntesse.

És ezt a gyógymódot úgy hívják A szoftvertermék TESZTELÉSE.

Az okos emberek szerint a tesztelés az egyik legelterjedtebb módja a szoftverfejlesztés minőségének biztosításának, és a modern szoftvertermékek minőségbiztosítási rendszerének hatékony eszköztárába tartozik.

A szoftvertermék minőségét olyan tulajdonságok összessége jellemzi, amelyek meghatározzák, hogy a termék mennyire „jó” az érintettek, így a termék vásárlója, szponzora, végfelhasználója, termékfejlesztői és tesztelői, támogató mérnökei, marketingje szempontjából. , képzési és értékesítési személyzet. A résztvevők mindegyikének más és más elképzelése lehet a termékről, illetve arról, hogy az mennyire jó vagy rossz, vagyis milyen magas a termék minősége. Így a termékminőség biztosításának problémafelvetése az érintettek, azok minőségi kritériumainak azonosítását, majd az ezeknek a kritériumoknak megfelelő optimális megoldás megtalálását eredményezi.

Mikor és ki?

A tapasztalt fejlesztők szerint egy szoftvertermék tesztelését a létrehozásának legelején el kell végezni. Ugyanakkor maguk a tapasztalt fejlesztők nem vehetnek részt a tesztelésben, mivel ez nem királyi ügy. A szoftverterméket speciálisan képzett, tesztelőknek nevezett munkatársaknak kell tesztelniük, mert a legtapasztaltabb fejlesztő sem fogja látni a hibáját, még a legújabb optikai műszerek használatával sem.

Azonban minden fejlesztő egyetért abban, hogy egy szoftvertermék tesztelését a cél szerinti osztályozás szempontjából két osztályba kell osztani:

• Funkcionális tesztelés
• Nem funkcionális tesztelés

Funkcionális tesztelés

A funkcionális tesztelés annak ellenőrzését jelenti, hogy egy szoftvertermék megfelel-e a termék létrehozásához szükséges műszaki specifikációban meghatározott funkcionális követelményeknek. Leegyszerűsítve, a funkcionális tesztelés ellenőrzi, hogy a szoftvertermék teljesíti-e az összes szükséges funkciót.

Tehát végül úgy döntött, hogy funkcionális tesztelést végez. Belenézel a műszaki specifikációba, elolvasod a funkcionális követelményeket, és rájössz, hogy ezek legalább nem abban a sorrendben vannak, ahogy a tesztelést el lehet végezni. Meg fog lepődni, hogy nagyon régen mások már észrevették ezt az eltérést, és rájöttek, hogyan lehet ezt leküzdeni.

A funkcionális teszteléshez a műszaki ellenőrzési osztály munkatársai dokumentumprogramot és módszertant fejlesztenek az alkalmazás (API) funkcionalitásának tesztelésére. A PMI-dokumentum tartalmazza a szoftvertermék-tesztelési forgatókönyvek (tesztesetek) listáját a lépések részletes leírásával. A tesztelési forgatókönyv minden lépését a felhasználó (tesztelő szakember) tevékenységei és a várt eredmények – a program válasza ezekre a műveletekre – jellemzik. A tesztprogramnak és módszertannak szimulálnia kell a szoftvertermék valós üzemmódban történő működését. Ez azt jelenti, hogy a tesztelési forgatókönyvet a rendszer jövőbeli felhasználói által elvégzendő műveletek elemzése alapján kell felépíteni, nem pedig egy mesterségesen összeállított, csak a fejlesztő számára érthető manipulációs sorozatot.

A funkcionális tesztelést általában két szinten hajtják végre:

• Alkatrész (egység) tesztelése. Egy szoftvertermék egyes összetevőinek tesztelése, különös tekintettel azok sajátosságaira, céljára és funkcionális jellemzőire.
• Integrációs tesztelés. Az ilyen típusú teszteléseket a komponensek tesztelése után hajtják végre, és célja a különféle alrendszerek interakciójában fellépő hibák azonosítása a vezérlési folyamatok és az adatcsere szintjén.

Nem funkcionális tesztelés

A nem funkcionális tesztelés értékeli a szoftvertermékek tulajdonságait, például az ergonómiát vagy a teljesítményt.

Úgy gondolom, hogy az ilyen típusú tesztelés fontossága egyértelmű, és nem igényel indoklást. Hiszen mindenki megérti, hogy ha például a rendszer teljesítménye nem elegendő, akkor a felhasználóknak fél napot kell várniuk a cselekvéseikre adott válaszra, ami tömeges hibernáláshoz vezethet.

Ahogy a neve is sugallja, a nem funkcionális tesztelés azt ellenőrzi, hogy egy szoftvertermék megfelel-e a nem funkcionális követelményeknek a létrehozásához szükséges műszaki leírásból. És a funkcionális teszteléshez hasonlóan a nem funkcionális teszteléshez tesztprogramot és módszertant dolgoznak ki.

Beágyazott szoftvertesztelés és megfelelőség az agilis korszakban

Az ipari szabványoknak való megfelelést nem lehet elhanyagolni vagy később megtenni; a beágyazott szoftver (szoftver) fejlesztési folyamat szerves része. Egyes iparágak – például a repüléselektronika, az autóipar és az egészségügy – számára a minőségi szabványok szigorú betartása az összetett és problémamentes beágyazott rendszerek fejlesztése során létfontosságú a termék piacra kerüléséhez. Hagyományosan a tesztelés fontos szerepet játszott a szabványok által szabályozott iparágak beágyazott rendszereinek fejlesztésében. Az elmúlt években azonban jelentősen megváltoztak a kialakult tesztelési gyakorlatok és folyamatok, ezek helye és szerepe az ilyen projektekben. Ez egy játékmódosító volt, és amikor megváltoznak a játékszabályok, akkor változni kell velük a győzelemhez.

Az új, élvonalbeli technológiák folyamatos fejlesztésével a cégeknek gyorsan olyan termékeket kell piacra ajánlaniuk, amelyek megbízhatóak, biztonságosak, könnyen használhatóak és kompatibilisek más rendszerekkel – csak azért, hogy ne vesszenek el a gyorsan változó technológiai világban. Ilyen helyzetben a hagyományos vízesés modell, ahol a szoftverfejlesztési folyamat szigorúan szekvenciális, és a tesztelés a legvégén történik, a múlté válik. A DevOps és az Agile módszerek egyre népszerűbbek, mert lehetővé teszik a mérnökök számára, hogy egyidejűleg hajtsanak végre olyan feladatokat, amelyek korábban egymást követték.

Teljesítményfelmérés

A teljesítményteszt során az első lépés a terhelési tesztelés, melynek célja annak ellenőrzése, hogy a rendszer megfelelően reagál-e a külső hatásokra a valós működéshez közeli üzemmódban.

A terhelési tesztelés mellett a teszteket minimális hardver és maximális terhelés - stresszteszt -, valamint maximális feldolgozott információmennyiség - volumetrikus tesztelés - körülmények között végezzük.

A tesztelésnek van egy másik típusa is: a stabilitási és megbízhatósági tesztelés, amely nemcsak a szoftvertermék normál körülmények közötti hosszú távú tesztelését foglalja magában, hanem azt is, hogy rövid ideig tartó stresszes terhelések után képes-e visszatérni a normál működésre.

Dokumentáció a teszteléshez

Amint fentebb említettük, a tesztelést a GOST 34.603-92 szabvány szerint kidolgozott program és vizsgálati módszertan szerint végezzük.

A teszteléshez egy tesztesetet dolgoznak ki, amelynek elegendő adatot kell tartalmaznia a szoftvertermék összes működési módjának teszteléséhez. Jellemzően valós adatok alapján készítenek tesztesetet a megrendelő és a kivitelező közösen.

Minden típusú teljesítményteszt elvégzéséhez leggyakrabban egy úgynevezett adatgenerátort hoznak létre, amely lehetővé teszi, hogy automatikusan elegendő mennyiségű adatot hozzon létre az objektív eredmény eléréséhez a teljesítmény értékelése során.

A tesztelés során vizsgálati jegyzőkönyv készül, amely a tesztelés valamennyi szakaszának, lépésének befejezéséről és a tesztelés során kapott észrevételekről tartalmaz információkat.

Ha a vizsgálat eredménye negatív, a hiányosságokat kijavítják és újra tesztelik.

Feltáró tesztelés

Feltáró tesztelés (az ad hoc tesztelés a funkcionális tesztelés egyik altípusa. Gyorsan növekvő, rugalmas fejlesztési módszerekkel rendelkező projektekben alkalmazzák, ahol nincsenek egyértelmű dokumentációk és követelmények. A feltáró tesztelés a legmagasabb műrepülés a szoftvertesztelésben. Kvalitatív tesztelés áll rendelkezésre a magasan kvalifikált szakemberek, és szinte teljes mértékben az előadón, tapasztalatán, tudásán (mind a témakörben, mind a tesztelési módszerekben) és a lényegre való gyors rátérési képességén múlik.

Stressz tesztelés

A terhelési tesztelés az a folyamat, amely a tesztelt rendszer terhelés alatti teljesítményét elemzi. A terhelési tesztelés célja az alkalmazás külső terhelésekkel szembeni ellenálló képességének meghatározása. A vizsgálatokat általában több szakaszban végzik el.

1. Teszt szkriptek generálása

A hatékony elemzés érdekében a forgatókönyveknek a lehető legközelebb kell állniuk a tényleges felhasználási esetekhez. Fontos megérteni, hogy kivételek mindig lehetségesek, és előfordulhat, hogy még a legrészletesebb vizsgálati terv sem fed le egyetlen esetet.

2. Tesztkonfiguráció kidolgozása

A tesztforgatókönyvek birtokában fontos a növekvő terhelés sorrendjének elosztása. A sikeres elemzéshez meg kell határozni a teljesítmény értékelési kritériumait (válasz sebessége, kérés feldolgozási ideje stb.).

3. Tesztvizsgálat elvégzése

A tesztek lefolytatása során fontos, hogy időben figyelemmel kísérjük a forgatókönyvek végrehajtását és a tesztelt rendszer reakcióit. A nagy terhelések emulálása komoly hardver- és szoftverinfrastruktúrát igényel. Egyes esetekben matematikai modellezési módszereket alkalmaznak a munka költségeinek csökkentése érdekében. Az alacsony terhelésnél kapott adatokat vesszük alapul és közelítjük. Minél magasabb a szimulált terhelés szintje, annál kisebb a becslés pontossága. Ez a módszer azonban jelentősen csökkenti a költségeket.

Tesztautomatizálás

Az automatizált tesztelés fő jellemzője a regressziós tesztek gyors elvégzésének képessége. Az automatizálás fő előnyei (a Worksoft jelentése szerint) a megnövekedett személyzeti hatékonyság, a hibák korábbi észlelése és az üzleti folyamatok jobb minősége. Ezeket az előnyöket egy jelentős hátrány ellensúlyozza: magas költség – a tesztautomatizálás megvalósításának és támogatásának magas költsége miatt a cégek mintegy 50%-a továbbra is elsősorban kézi tesztelést alkalmaz.

Használhatósági tesztelés

Bármely alkalmazás létrejön, hogy használható legyen. A könnyű használhatóság a program fontos minőségi mutatója. Az IT-ipar számos példát tud arra, hogy egy sikeres használhatósági javítást követően elindultak a projektek. Minél szélesebb a közönség, annál fontosabb a használhatósági tényező. A használhatóság tesztelése magában foglalja a felhasználói viselkedés részletes elemzését. Az ergonómia értékeléséhez fontos, hogy ne csak az üzleti feladat elvégzésének sebességéről rendelkezzünk adatokkal, hanem a felhasználó érzelmeiről, arckifejezéseiről és hangszínéről is.

Konfiguráció tesztelése

A konfiguráció tesztelése bizonyosságot ad arról, hogy az alkalmazás különböző platformokon fog működni, és ezáltal a felhasználók maximális száma számára. A WEB-alkalmazások esetében általában a böngészők közötti tesztelést választják. Windows alkalmazásokhoz - tesztelés különböző operációs rendszereken és bitsebességeken (x86, x64). A konfiguráció tesztelésének fontos összetevője a teszt infrastruktúra: a tesztek elvégzéséhez folyamatosan karban kell tartani a tesztgépek flottáját. Számuk 5-től több tucatig változik.

Integrációs tesztelés

Ha a projekt egynél több összetevőt tartalmaz, akkor integrációs tesztelésre van szükség. Összetett alkalmazásarchitektúra esetén a minőségbiztosítás elengedhetetlen feltétele a programrészek interakciójának ellenőrzése. A tesztelést az „end-to-end” esetek kidolgozásával és lebonyolításával érik el. Az integrációs tesztelés az alkatrészek tesztelése után történik. Ezért nagyon fontos az alkatrésztesztelés tapasztalatainak figyelembe vétele, a tesztesetek üzleti orientációjának tiszteletben tartása mellett.

Stressz tesztelés

Bármely rendszer normál működésének korlátai vannak. A határérték túllépése esetén a rendszer stresszállapotba kerül, és jelentősen megváltoztatja viselkedését. A stresszteszt egy alkalmazás működését teszteli a normál működési határokat meghaladó körülmények között. Ez különösen fontos a „kritikus” programok esetében: banki szoftverek, légiközlekedési ipari programok, orvostudomány. A stressztesztet nemcsak a szoftverfejlesztési szakaszban végzik, hanem a teljes működési ciklus során is, hogy hosszú időn keresztül megkapják és feldolgozzák a rendszer viselkedési adatait.

Az összes típus közül a funkcionális tesztelés jogosan foglal el vezető helyet, mivel a programnak mindenekelőtt megfelelően kell működnie, különben a könnyű használat, a biztonság és a megfelelő sebesség egyáltalán nem használ. A különféle tesztelési technikák elsajátítása mellett minden szakembernek meg kell értenie, hogyan kell megfelelően elvégezni a tesztet a leghatékonyabb eredmény elérése érdekében.

Funkcionális tesztelés: hová irányítsuk a fő erőfeszítéseket?

Egységek és rendszerek teszteléséhez;

A „fehér” vagy „fekete” négyzet bejelölése;

Kézi teszteléshez és automatizáláshoz;

Új funkciók teszteléséhez vagy;

„Negatív” vagy „pozitív” tesztekhez.

Mindezen tevékenységi területek között fontos megtalálni a helyes utat, amely a „közép” lesz, az erőfeszítések egyensúlyozása érdekében, az egyes területek előnyeit maximálisan kihasználva.

A szoftver ellenőrzése megtörténik különböző utak, amelyek közül az egyik fekete doboz vagy adatvezérelt tesztelés.

A programot ebben az esetben a „fekete doboz” szemszögéből mutatjuk be, és a tesztet annak megállapítására végezzük, hogy milyen körülmények között a program viselkedése nem felel meg a specifikációnak. Minden hiba azonosítása adatkezeléssel történik, amely teljes körű teszteléssel, azaz minden lehetséges felhasználásával történik

Ha egy program esetében egy parancs végrehajtása az azt megelőző eseményektől függ, akkor minden lehetséges szekvenciát ellenőrizni kell. Nyilvánvaló, hogy a legtöbb esetben egyszerűen lehetetlen kimerítő tesztelést végezni, ezért gyakrabban választanak egy elfogadható vagy ésszerű lehetőséget, amely a program futtatására korlátozódik az összes bemeneti adat egy kis részhalmazán. Ez az opció teljes mértékben garantálja a specifikációtól való eltérést.

A funkcionális tesztelés magában foglalja a megfelelő teszt kiválasztását. Ugyanakkor szokás megkülönböztetni a következő módszereket a készletek létrehozásához:

Határérték elemzés;

Egyenértékű partíció;

Hiba feltételezés;

Okok és hatások összefüggéseinek elemzése.

Mindegyiket külön-külön megvizsgálhatja.

Határérték elemzés. A határértékek általában az ekvivalenciaosztályok határain találhatók. Ilyen helyeken a legvalószínűbb, hogy hibát talál. Egy ilyen módszer alkalmazása bizonyos kreativitást igényel a szakembertől, valamint szakosodást erre a konkrét problémára.

Egyenértékű partíció. A bemeneti paraméterek összes lehetséges halmaza több ekvivalencia osztályra van osztva. Az adatok összevonása a hasonló hibák észlelésének elve alapján történik. Általánosan elfogadott, hogy ha egy osztály halmaza hibát mutat, akkor azt az egyenértékűek is jelezni fogják. Funkcionális tesztelés által ez a módszer két szakaszban hajtják végre: az elsőben az ekvivalencia osztályokat azonosítják, a másodikban pedig már speciális teszteket alakítanak ki.

Ok-okozati összefüggések elemzése. A rendszer az ilyen ellenőrzések elvégzésével nagy teljesítményű teszteket tud kiválasztani. Ebben az esetben egy külön bemeneti feltételt veszünk okként, és a kimeneti feltételt tekintjük hatásnak. A módszer azon az elgondoláson alapul, hogy minden típusú okot bizonyos következményeknek tulajdonítanak, vagyis ugyanazokat az ok-okozati összefüggéseket tisztázza. Egy szoftvertermék tesztelése több szakaszban történik, ami az okok és a következmények listáját eredményezi.

• a fejlesztők nem szándékos eltérései a munkanormáktól vagy a megvalósítási tervektől;
• a funkcionális és interfész követelmények specifikációi a fejlesztési szabványok betartása nélkül készülnek, ami a programok működésének megzavarásához vezet;
• a fejlesztési folyamat szervezése - a projektmenedzser erőforrásainak (humán, műszaki, szoftver, stb.) tökéletlen vagy nem megfelelő kezelése, valamint a projektelemek tesztelésének, integrációjának kérdései.

Nézzük meg a tesztelési folyamatot az ISO/IEC 12207 szabvány ajánlásai alapján, és adjuk meg az egyes életciklus-folyamatokban észlelt hibatípusokat.

Követelményfejlesztési folyamat. A rendszer kezdeti koncepciójának és a rendszer kezdeti követelményeinek meghatározásakor az elemzők specifikációs hibákat követnek el felső szint rendszerek és a témakör koncepcionális modelljének felépítése.

A folyamatban előforduló tipikus hibák a következők:

• a végfelhasználókra vonatkozó követelményspecifikáció elégtelensége - a szoftver működési környezettel vagy felhasználókkal való interakciójának helytelen meghatározása;
• az egyedi és általános szoftvertulajdonságokra vonatkozó vevői követelmények be nem tartása;
• a funkcionális jellemzők helytelen leírása;
• az ügyféligények megvalósításának minden aspektusához szükséges eszközök hiánya stb.

Tervezési folyamat.A komponensek tervezésében hibák fordulhatnak elő algoritmusok, vezérlési logika, adatstruktúrák, interfészek, adatfolyam-modellezési logika, bemeneti/kimeneti formátumok stb. leírásakor. Ezek a hibák az elemzői specifikációk hibáin és a tervezési hibákon alapulnak. Ide tartoznak a következőkhöz kapcsolódó hibák:

• a környezettel való felhasználói felület meghatározásával;
• a funkciók leírásával (az összetevők halmazának ellenőrzése során feltárt komponensek céljainak és célkitűzéseinek elégtelensége);
• az információfeldolgozási folyamat és a folyamatok közötti kölcsönhatás meghatározásával (komponensek és folyamatok kapcsolatainak helytelen meghatározásának eredménye);
• az adatok és struktúráik helytelen megadásával az egyes összetevők és a szoftver egészének leírásakor;
• a modulalgoritmusok helytelen leírásával;
• a programban előforduló esetleges hibák feltételeinek meghatározásával;
• megsérti a projekthez elfogadott szabványokat és technológiákat.

Kódolási szakasz.Ebben a szakaszban olyan hibák lépnek fel, amelyek tervezési hibákból, programozók és menedzserek hibáiból adódnak a rendszer fejlesztése és hibakeresése során. A hibák okai a következők:

• a bemeneti paraméterek, tömbindexek, hurokparaméterek, kimeneti eredmények, 0-val való osztás stb. értékeinek ellenőrzésének hiánya;
• szabálytalan helyzetek helytelen kezelése a hívott szubrutinokból, függvényekből stb. származó visszatérési kódok elemzésekor;
• a kódolási szabványok megsértése (rossz megjegyzések, irracionális modulok kiosztásaés alkatrész stb.);
• egy név használata különböző objektumok vagy egy objektum eltérő elnevezésére, rossz névmnemonika; - a program különböző fejlesztők általi következetlen módosításai stb.

Tesztelési folyamat.Ebben a folyamatban a programozók és tesztelők hibákat követnek el az összeszerelési és tesztelési technológia végrehajtása során, a tesztkészletek és tesztforgatókönyvek kiválasztásakor stb. szoftverhibák általában.

Karbantartási folyamat.A karbantartási folyamat során olyan hibákat fedeznek fel, amelyeket az üzemeltetési dokumentáció hiányosságai és hibái, a nem megfelelő módosíthatóság és olvashatóság mutatói, valamint a szoftver karbantartásáért és/vagy fejlesztéséért felelős személyek hozzá nem értése okoznak. A végrehajtott változtatások jellegétől függően ebben a szakaszban szinte bármilyen, az előző szakaszokban felsorolt ​​hibákhoz hasonló hiba előfordulhat.

A programokban előforduló összes hiba általában a következő osztályokba sorolható [7.12]:

• logikai és funkcionális hibák;
• számítási és futási hibák;
• beviteli/kimeneti és adatmanipulációs hibák;
• interfész hibák;
• adatmennyiségi hibák stb.

Logikai hibák az algoritmus logikájának megsértésének, a változók és operátorok belső inkonzisztenciájának, valamint a programozási szabályoknak az okai. A funkcionális hibák a nem megfelelően meghatározott funkciók, az alkalmazási sorrend megsértése vagy a megvalósítás hiányossága stb. következményei.

Számítási hibák a forrásadatok és a megvalósított képletek pontatlansága, módszerhibák, számítási műveletek vagy operandusok helytelen alkalmazása miatt keletkeznek. A futásidejű hibák a kérésfeldolgozási sebesség vagy a programhelyreállítási idő elmulasztásával járnak.

I/O hibákés az adatmanipuláció az adatok rossz minőségű programvégrehajtásra való előkészítésének, az adatbázisokba való bevitelük vagy onnan történő lehívásuk meghibásodásának a következménye.

Interfész hibák utalnak az egyes elemek egymáshoz való viszonyának hibáira, amelyek a köztük lévő adatátvitel során, valamint a működési környezettel való interakció során jelentkeznek.

Hangerő-hibák adatokra vonatkoznak, és annak következményei, hogy a megvalósított hozzáférési módok és adatbázisméretek nem elégítik ki a rendszerinformáció valós mennyiségét, illetve feldolgozásuk intenzitását.

Az adott fő hibaosztályok különböző típusú szoftverkomponensekre jellemzőek, és a programokban eltérő módon jelennek meg. Így egy adatbázissal való munka során hibák lépnek fel az adatmegjelenítésben és az adatkezelésben, logikai hibákat az alkalmazott adatfeldolgozási eljárások meghatározásában stb. A számítási programokban a számítási hibák, a vezérlő és feldolgozó programokban a logikai és funkcionális hibák dominálnak. A sok különböző programból álló szoftverek, amelyek különböző funkciókat valósítanak meg, hibákat tartalmazhatnak különböző típusok. Az interfészhibák és a hangerősértések minden rendszertípusra jellemzőek.

A programokban előforduló hibatípusok elemzése előfeltétele a szoftver helyességét biztosító teszttervek és vizsgálati módszerek elkészítésének.

A szoftverfejlesztést támogató eszközök (CASE-technológiák, objektumorientált módszerek és eszközök a modellek és programok tervezésére) fejlesztésének jelenlegi szakaszában olyan tervezést végeznek, amelyben a szoftver védve van a leggyakoribb hibáktól, és ezzel megakadályozza a szoftverhibák.

Hiba és kudarc kapcsolata.A programban fellépő hiba jelenléte általában a szoftver meghibásodásához vezet a működése során. A "hiba-hiba" ok-okozati összefüggéseinek elemzéséhez a következő műveleteket kell végrehajtani:

• a tervezési és programozási technológiák hibáinak azonosítása;
• a tervezési folyamat hibái és az emberi hibák közötti kapcsolat;
• a hibák, hibák és esetleges hibák, valamint hibák osztályozása a fejlesztés egyes szakaszaiban - az adott fejlesztési folyamat során elkövetett emberi hibák és az objektum hibáinak összehasonlítása a projektspecifikáció, programmodellek hibáiból eredően;
• ellenőrzés és hibavédelem az életciklus minden szakaszában, valamint a hibák feltárása a fejlesztés minden szakaszában;
• a szoftverhibák és meghibásodások összehasonlítása összekapcsolási rendszer és módszerek kifejlesztése a hibákkal és hibákkal kapcsolatos információk lokalizálására, összegyűjtésére és elemzésére;
• a szoftverek dokumentálási és tesztelési folyamatainak megközelítési módjainak fejlesztése.

A hiba-hiba ok-okozati összefüggés végső célja, hogy meghatározza az egyes osztályok hibáinak tesztelésére és észlelésére szolgáló módszereket és eszközöket, valamint kritériumokat a több adathalmaz tesztelésének befejezéséhez; a szoftverfejlesztési, -tesztelési és -karbantartási folyamatok megszervezésének javításának módjainak azonosításában.

Íme a hibatípusok következő osztályozása:

• hardver, amelyben a rendszerszintű szoftver nem működik;
• információs, amelyet a bemeneti adatok és a kommunikációs csatornákon keresztüli adatátvitel hibái, valamint a beviteli eszközök meghibásodása okoz (hardverhibák következménye);
• ergonómikus, amelyet a kezelő hibái okoznak a géppel való interakció során (ez a hiba másodlagos hiba, és információs vagy funkcionális hibákhoz vezethet);
• szoftver, ha hibák vannak a komponensekben stb.

Egyes hibák a követelmények meghatározása, a tervezés, a kimeneti kód generálás vagy a dokumentáció hiányosságaiból fakadhatnak. Másrészt egy program fejlesztése során, vagy az egyes programelemek interfészeinek fejlesztése során keletkeznek (paraméterek sorrendjének megsértése, kevesebb vagy több paraméter stb.).

Hibaforrások.Hibák a projekt, a komponensek, a kód és a dokumentáció fejlesztése során keletkezhetnek. Általában a szoftver végrehajtása vagy karbantartása során a legváratlanabb és legkülönbözőbb pontokon fedezik fel őket.

A program egyes hibái a követelmények meghatározása, a tervezés, a kódgenerálás vagy a dokumentáció hiányosságaiból származhatnak. Másrészt hibák keletkeznek egy program vagy elemeinek interfészeinek fejlesztése során (például amikor a kommunikációs paraméterek beállítási sorrendjét megsértik - kevesebb vagy több a szükségesnél stb.).

A hibák oka a vevői követelmények megértésének hiánya; a követelmények pontatlan meghatározása a projektdokumentumokban stb. Ez azt eredményezi, hogy egyes rendszerfunkciók nem az ügyfél által javasolt módon fognak működni. Ezzel kapcsolatban a megrendelő és a kidolgozó közös megbeszélést folytatnak a követelmények egyes részleteiről azok tisztázása érdekében.

A rendszerfejlesztő csapat módosíthatja a rendszerleírás szintaxisát és szemantikáját is. Előfordulhat azonban, hogy egyes hibák nem észlelhetők (például ezeknek az utasításoknak az indexei vagy változóértékei helytelenül vannak beállítva).