Szoftvertermék tesztelése. Hogyan ellenőrizhető egy olyan funkció működőképessége, amely más funkciókat is használ? Változással kapcsolatos tesztelés

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

Hogyan lehet elérni, hogy az elesés, lefagyás, az Ön által kifejlesztett program szükséges műveleteinek elmulasztása nagyon ritka legyen?

Erre a kérdésre nincs pontos válasz. Ám a legbölcsebb tudósok évszázadok óta gondolkodnak ezen, és ennek ellenére sikerült olyan gyógymódot találniuk, amely ha nem is szünteti meg az összes programhibát, de legalább azt az illúziót kelti, hogy a tevékenység kiküszöböli.

És ezt az eszközt úgy hívják 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észletben szerepel modern rendszer szoftvertermékek minőségbiztosí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 érdeklődők, például a termék vásárlója, szponzora, végfelhasználója, termékfejlesztői és tesztelői, támogatása szempontjából. mérnökök, marketing, képzés és értékesítők. A résztvevők mindegyikének más és más elképzelése lehet a termékről, és arról, hogy az mennyire jó vagy rossz, vagyis milyen magas a termék minősége. Így a termék minőségbiztosítási problémájának megfogalmazása azt a feladatot eredményezi, hogy azonosítsák az érintetteket, azok minőségi kritériumait, majd megtalálják az ezeknek a kritériumoknak megfelelő optimális megoldást.

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 sem vehetnek részt a tesztelésben, mivel ez nem királyi üzlet. A speciálisan képzett munkatársaknak, úgynevezett tesztelőknek érdemes tesztelniük a szoftverterméket, mert a legtapasztaltabb fejlesztő sem fogja látni a hibáját, még a legújabb optikai műszerek használatával sem.

Mindazonáltal minden fejlesztő egyetért abban, hogy egy szoftvertermék tesztelését a célok 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

Funkcionális tesztelés alatt azt értjük, hogy egy szoftvertermék megfelel-e a termék létrehozására vonatkozó feladatmeghatározásban meghatározott funkcionális követelményeknek. Egyszerűen fogalmazva, a funkcionális tesztelés ellenőrzi, hogy a szoftvertermék teljesíti-e az összes szükséges funkciót.

Tehát úgy döntött, hogy funkcionális tesztelést végez. Megnézi a feladatmeghatározást, elolvassa a funkcionális követelményeket, és megérti, hogy ezek legalább nincsenek abban a sorrendben, ahogyan tesztelni tudja. Meg fog lepődni, hogy 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 az alkalmazás funkcionalitásának (API) tesztelésének módszerét dolgozzák ki. 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 tesztforgató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 programnak és a tesztelési 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 tesztszkriptet 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. Szoftvertermék egyes összetevőinek tesztelése sajátosságukra, céljukra és funkcionális jellemzőikre összpontosítva.
• 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 a szoftvertermékek olyan tulajdonságait értékeli, mint például az ergonómia vagy a teljesítmény.

Úgy gondolom, hogy az ilyen típusú tesztelés fontossága egyértelmű, és nem igényel indoklást. Végtére is 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 hatalmas hibernáláshoz vezethet.

Ahogy a neve is sugallja, a nem funkcionális tesztelés ellenőrzi, hogy a 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 is kidolgoznak egy programot és tesztelési módszertant.

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

Az ipari szabványoknak való megfelelést nem lehet elhanyagolni vagy később megtenni; a beágyazott szoftver (SW) fejlesztési folyamatának 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 a termék piacra kerülésének elengedhetetlen feltételévé válik. Hagyományosan a tesztelés fontos szerepet játszott a szabványvezérelt iparágak beágyazott rendszereinek fejlesztésében. Az elmúlt években azonban jelentősen megváltoztak a kialakult gyakorlatok és tesztelési folyamatok, ezek helye és szerepe az ilyen projektekben. Drámaian megváltoztatta az összes játékszabályt, és amikor a játékszabályok megváltoznak, akkor változnia kell velük ahhoz, hogy nyerjen.

A folyamatosan fejlődő új, korszerű technológiáknak köszönhetően a vállalatoknak gyorsan piacra kell vinniük megbízható, biztonságos, könnyen használható és interoperábilis termékeket – csak hogy ne vesszenek el a rohanó világban. technológiai világ. Ilyen helyzetben a hagyományos waterfall 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, mivel lehetővé teszik a mérnökök számára, hogy olyan feladatokat hajtsanak végre, amelyek korábban egymást követték.

Teljesítményfelmérés

A teljesítményteszt során mindenekelőtt terhelési tesztet végeznek, melynek célja annak ellenőrzése, hogy a valós üzemmódhoz közeli üzemmódban a rendszer megfelelően reagál-e a külső hatásokra.

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 - térfogatteszt - feltételek mellett végezzük.

A tesztelésnek van egy másik fajtája is: a stabilitási és megbízhatósági tesztelés, amely nemcsak egy szoftvertermék hosszú távú tesztelését foglalja magában normál körülmények között, hanem azt is, hogy rövid ideig tartó 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 szerint kidolgozott vizsgálati programnak és módszertannak megfelelően végzik.

Tesztelésre kifejlesztve próbaper, amelynek elegendő adatot kell tartalmaznia a szoftvertermék összes működési módjának ellenőrzéséhez. Általában valós adatok alapján készítenek próbaesetet 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 elegendő 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, amelybe a tesztelés minden szakaszának, lépésének lefutásáról és a vizsgálatok során beérkezett észrevételekről információ kerül.

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 alfaja. Gyorsan növekvő, rugalmas fejlesztési módszerekkel rendelkező projektekben alkalmazzák, ahol nincs egyértelmű dokumentáció és követelmény. A feltáró tesztelés a szoftvertesztelés csúcsa. Kiváló minőségű tesztelés érhető el magasan képzett szakembereknek, és szinte teljes mértékben függ az előadótól, tapasztalatától, tudásától (mind a témakörben, mind a tesztelési módszerekben), a lényegbe való gyors behatolás képességétől.

Stressz tesztelés

A terhelési tesztelés az a folyamat, amely a vizsgált rendszer teljesítményét terhelés hatására elemzi. A terhelésteszt célja annak meghatározása, hogy egy alkalmazás képes-e ellenállni a külső terhelésnek. 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 valós 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 szükséges kiemelni a teljesítmény értékelésének szempontjait (válasz sebesség, kérés feldolgozási idő stb.).

3. Tesztvizsgálat lefolytatása

A tesztek végrehajtásakor fontos a szkriptek végrehajtásának és a tesztelt rendszer válaszának időben történő figyelemmel kísérése. A nagy terhelések emulálásához komoly hardver és szoftver infrastruktúra szükséges. 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.

Teszt automatizá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és szerint) a megnövekedett személyzeti hatékonyság, a hibák korábbi észlelé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 karbantartásának magas költsége miatt a cégek mintegy 50%-a még mindig többnyire kézi tesztelést alkalmaz.

Használhatóság tesztelése

Minden alkalmazás használatra készült. 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ági tesztelés a felhasználói viselkedés részletes elemzését foglalja magában. Az ergonómia felméréséhez fontos, hogy ne csak az üzleti feladat elvégzésének sebességére, hanem a felhasználó érzelmeire, arckifejezéseire és hangszínére is rendelkezzenek adatok.

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, ami azt jelenti, hogy a felhasználók maximális száma. Webes alkalmazások esetén általában a böngészők közötti kompatibilitás tesztelését választják. Windows alkalmazásokhoz - különféle tesztelés operációs rendszerés bitesség (x86, x64). A konfiguráció tesztelésének fontos összetevője a tesztinfrastruktúra: a teszteléshez 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. Egy összetett alkalmazásarchitektúra esetén a minőségbiztosítás szükséges feltétele a program részei közötti interakció ellenőrzése. A tesztelést "átmenő" 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, hogy figyelembe vegyük az alkatrésztesztelés tapasztalatait, miközben tiszteletben tartjuk a tesztesetek üzleti orientációját.

stresszteszt

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 az alkalmazás teljesítményét a normál működés határait meghaladó körülmények között ellenőrzi. Ez különösen fontos a "kritikus" programok esetében: banki szoftverek, repülési ipar programjai és az orvostudomány. A stressztesztet nemcsak a szoftverfejlesztés szakaszában, hanem a teljes működési ciklusban is végezzük, hogy a rendszer viselkedésére vonatkozóan hosszú időn keresztül adatokat kapjunk és dolgozzanak fel.

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 a 3 forrás-a , forrás-b és forrás-c függvényt használja három különböző típusú térkép lekéréséhez. 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-t, ellenőrizzem, hogy vannak-e adatok a kulcsokhoz? Van értelme ennek a függvénynek, hogy sikertelen legyen az egységteszteken, ha a forrás-a, forrás-b és forrás-c egyike meghiúsul? Ha ennek a funkciónak az a feladata, hogy összekapcsolja az adatokat, és ez megtörténik, akkor ennek elégnek kell lennie, nem?

1

2 válasz

Tegyük fel, hogy létezik egy get-data függvény, amely a megadott felhasználói azonosítóval kapcsolatos információk térképét adja vissza.

Nagy. Akkor meg kéne nézni. A megadott 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, hogy 3 különböző típusú térképet kapjon.

Milyen megvalósítási részleteket kell figyelmen kívül hagynia 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 adja vissza az XYZ-adatokat 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 faktorálhatja a módszer megvalósítását, és a teszt ellenőrizni fogja, hogy jól csinálta-e.

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 tesztet izolálni kell (az adatok gúnyolásával), a tesztet a követelményekre és a pragmatizmusra összpontosítani.

Végül is ez egy fontos kód. Vannak tesztek a tényleges kód biztonsági mentésére, a sok idő elköltése és a polírozás ellenőrzése nem olyan hasznos, mint a tesztek készítése .

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

Az integrációs tesztelés során a közöttük kölcsönhatásba lépő több 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 összekapcsolva).

Az egységtesztek egyszerűbbek és célzottabbak, és ezeket a fejlesztőknek kell elkészíteniük. Az integrációs tesztek általában viszonylag gyorsan elavulnak (ha vannak ilyenek). belső komponens módosult), így nehezebb végrehajtani. Minőségbiztosítási profillal kell létrehozni.

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

Hogyan lehet elérni, hogy az elesés, lefagyás, az Ön által kifejlesztett program szükséges műveleteinek elmulasztása nagyon ritka legyen?

Erre a kérdésre nincs pontos válasz. Ám a legbölcsebb tudósok évszázadok óta gondolkodnak ezen, és ennek ellenére sikerült olyan gyógymódot találniuk, amely ha nem is szünteti meg az összes programhibát, de legalább azt az illúziót kelti, hogy a tevékenység kiküszöböli.

És ezt az eszközt úgy hívják 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 egy modern szoftverminőség-biztosítási rendszer 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 érdeklődők, például a termék vásárlója, szponzora, végfelhasználója, termékfejlesztői és tesztelői, támogatása szempontjából. mérnökök, marketing, képzés és értékesítők. A résztvevők mindegyikének más és más elképzelése lehet a termékről, és arról, hogy az mennyire jó vagy rossz, vagyis milyen magas a termék minősége. Így a termék minőségbiztosítási problémájának megfogalmazása azt a feladatot eredményezi, hogy azonosítsák az érintetteket, azok minőségi kritériumait, majd megtalálják az ezeknek a kritériumoknak megfelelő optimális megoldást.

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 sem vehetnek részt a tesztelésben, mivel ez nem királyi üzlet. A speciálisan képzett munkatársaknak, úgynevezett tesztelőknek érdemes tesztelniük a szoftverterméket, mert a legtapasztaltabb fejlesztő sem fogja látni a hibáját, még a legújabb optikai műszerek használatával sem.

Mindazonáltal minden fejlesztő egyetért abban, hogy egy szoftvertermék tesztelését a célok 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

Funkcionális tesztelés alatt azt értjük, hogy egy szoftvertermék megfelel-e a termék létrehozására vonatkozó feladatmeghatározásban meghatározott funkcionális követelményeknek. Egyszerűen fogalmazva, a funkcionális tesztelés ellenőrzi, hogy a szoftvertermék teljesíti-e az összes szükséges funkciót.

Tehát úgy döntött, hogy funkcionális tesztelést végez. Megnézi a feladatmeghatározást, elolvassa a funkcionális követelményeket, és megérti, hogy ezek legalább nincsenek abban a sorrendben, ahogyan tesztelni tudja. Meg fog lepődni, hogy 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 az alkalmazás funkcionalitásának (API) tesztelésének módszerét dolgozzák ki. 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 tesztforgató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 programnak és a tesztelési 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 tesztszkriptet 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. Szoftvertermék egyes összetevőinek tesztelése sajátosságukra, céljukra és funkcionális jellemzőikre összpontosítva.
• 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 a szoftvertermékek olyan tulajdonságait értékeli, mint például az ergonómia vagy a teljesítmény.

Úgy gondolom, hogy az ilyen típusú tesztelés fontossága egyértelmű, és nem igényel indoklást. Végtére is 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 hatalmas 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ára vonatkozó feladatmeghatározásból. És a funkcionális teszteléshez hasonlóan a nem funkcionális teszteléshez is kidolgoznak egy programot és tesztelési módszertant.

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

Az ipari szabványoknak való megfelelést nem lehet elhanyagolni vagy később megtenni; a beágyazott szoftver (SW) fejlesztési folyamatának 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 a termék piacra kerülésének elengedhetetlen feltételévé válik. Hagyományosan a tesztelés fontos szerepet játszott a szabványvezérelt iparágak beágyazott rendszereinek fejlesztésében. Az elmúlt években azonban jelentősen megváltoztak a kialakult gyakorlatok és tesztelési folyamatok, ezek helye és szerepe az ilyen projektekben. Drámaian megváltoztatta az összes játékszabályt, és amikor a játékszabályok megváltoznak, akkor változnia kell velük ahhoz, hogy nyerjen.

A folyamatosan fejlődő új, korszerű technológiáknak köszönhetően a vállalatoknak gyorsan piacra kell vinniük megbízható, biztonságos, könnyen használható és interoperábilis termékeket – csak hogy ne vesszenek el a rohanó világban. technológiai világ. Ilyen helyzetben a hagyományos waterfall 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, mivel lehetővé teszik a mérnökök számára, hogy olyan feladatokat hajtsanak végre, amelyek korábban egymást követték.

Teljesítményfelmérés

A teljesítményteszt során mindenekelőtt terhelési tesztet végeznek, melynek célja annak ellenőrzése, hogy a valós üzemmódhoz közeli üzemmódban a rendszer megfelelően reagál-e a külső hatásokra.

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 - térfogatteszt - feltételek mellett végezzük.

A tesztelésnek van egy másik fajtája is: a stabilitási és megbízhatósági tesztelés, amely nemcsak egy szoftvertermék hosszú távú tesztelését foglalja magában normál körülmények között, hanem azt is, hogy rövid ideig tartó 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 szerint kidolgozott vizsgálati programnak és módszertannak megfelelően végzik.

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. Általában valós adatok alapján készítenek próbaesetet 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, amelybe a tesztelés minden szakaszának, lépésének lefutásáról és a vizsgálatok során beérkezett észrevételekről információ kerül.

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 alfaja. Gyorsan növekvő, rugalmas fejlesztési módszerekkel rendelkező projektekben alkalmazzák, ahol nincs egyértelmű dokumentáció és követelmény. A feltáró tesztelés a szoftvertesztelés csúcsa. Kiváló minőségű tesztelés érhető el magasan képzett szakembereknek, és szinte teljes mértékben függ az előadótól, tapasztalatától, tudásától (mind a témakörben, mind a tesztelési módszerekben), a lényegbe való gyors behatolás képességétől.

Stressz tesztelés

A terhelési tesztelés az a folyamat, amely a vizsgált rendszer teljesítményét terhelés hatására elemzi. A terhelésteszt célja annak meghatározása, hogy egy alkalmazás képes-e ellenállni a külső terhelésnek. 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 valós 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 szükséges kiemelni a teljesítmény értékelésének szempontjait (válasz sebesség, kérés feldolgozási idő stb.).

3. Tesztvizsgálat lefolytatása

A tesztek végrehajtásakor fontos a szkriptek végrehajtásának és a tesztelt rendszer válaszának időben történő figyelemmel kísérése. A nagy terhelések emulálásához komoly hardver és szoftver infrastruktúra szükséges. 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.

Teszt automatizá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 cégjelenté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 karbantartásának magas költsége miatt a cégek mintegy 50%-a még mindig többnyire kézi tesztelést alkalmaz.

Használhatóság tesztelése

Minden alkalmazás használatra készült. 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ági tesztelés a felhasználói viselkedés részletes elemzését foglalja magában. Az ergonómia felméréséhez fontos, hogy ne csak az üzleti feladat elvégzésének sebességére, hanem a felhasználó érzelmeire, arckifejezéseire és hangszínére is rendelkezzenek adatok.

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, ami azt jelenti, hogy a felhasználók maximális száma. Webes alkalmazások esetén általában a böngészők közötti kompatibilitás tesztelését választják. Windows alkalmazásokhoz - tesztelés különböző operációs rendszereken és bitességen (x86, x64). A konfiguráció tesztelésének fontos összetevője a tesztinfrastruktúra: a teszteléshez 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. Egy összetett alkalmazásarchitektúra esetén a minőségbiztosítás szükséges feltétele a program részei közötti interakció ellenőrzése. A tesztelést "átmenő" 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, hogy figyelembe vegyük az alkatrésztesztelés tapasztalatait, miközben tiszteletben tartjuk a tesztesetek üzleti orientációját.

stresszteszt

Bármely rendszernek van határa a normál működésnek. 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 az alkalmazás teljesítményét a normál működés határait meghaladó körülmények között ellenőrzi. Ez különösen fontos a "kritikus" programok esetében: banki szoftverek, repülési ipar programjai és az orvostudomány. A stressztesztet nemcsak a szoftverfejlesztés szakaszában, hanem a teljes működési ciklusban is végezzük, hogy a rendszer viselkedésére vonatkozóan hosszú időn keresztül adatokat kapjunk és dolgozzanak fel.

A funkcionális tesztelés minden típusa között jogosan foglal el vezető pozíciót, mivel a programnak elsősorban megfelelően kell működnie, különben semmi értelme a könnyű használatnak, a biztonságnak és a megfelelő sebességnek. A különféle tesztelési technikák elsajátítása mellett minden szakembernek meg kell értenie, hogyan kell megfelelően tesztelni 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 ;

A "negatív" vagy "pozitív" teszteken.

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 a feketedobozos vagy adatvezérelt tesztelés.

A programot ebben az esetben a „fekete doboz” szemszögéből mutatjuk be, és a tesztet annak kiderítésére végezzük, hogy milyen körülmények között a program viselkedése nem felel meg a specifikációnak. Minden hibát az adatkezelés határozza meg, amely kimerítő teszteléssel, azaz minden lehetséges

Ha egy program esetében egy parancs végrehajtása az azt megelőző eseményektől függ, akkor az összes lehetséges szekvenciát ellenőrizni kell. Nyilvánvaló, hogy a legtöbb esetben egyszerűen lehetetlen teljes körű 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óktól való eltérések hiányát.

A funkcionális tesztelés magában foglalja a teszt helyes megválasztását. Ugyanakkor szokás megkülönböztetni a készletek kialakításának ilyen módszereit:

Határérték-elemzés;

Egyenértékű partíció;

Hiba tipp;

Az okok és következmények összefüggéseinek elemzése.

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

A határértékek elemzése. 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 az adott problémára való specializációt.

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 szerint történik. Általánosan elfogadott, hogy ha egy osztály halmaza hibát észlel, akkor az egyenértékű osztályok is jelezni fogják. Funkcionális tesztelés által ez a módszer két szakaszban történik: az elsőben az ekvivalencia osztályokat választják ki, 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éseknek köszönhetően nagy teljesítményű teszteket tud kiválasztani. Ebben az esetben egy külön bemeneti feltételt veszünk figyelembe okként, és egy kimeneti feltételt tekintünk következménynek. 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 következmények listáját eredményezi.

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

Tekintsük a tesztelési folyamatot az ISO/IEC 12207 szabvány ajánlásai alapján, és soroljuk fel az egyes életciklus-folyamatoknál található hibák típusait.

Követelmények kialakításának folyamata. A rendszer kezdeti koncepciójának és a rendszer kezdeti követelményeinek meghatározásakor elemzői hibák lépnek fel a specifikáció során felső szint rendszerek és a témakör koncepcionális modelljének felépítése.

Ennek a folyamatnak a tipikus hibái 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 a felhasználókkal való interakciójának helytelen meghatározása;
• eltérések az egyedi és általános szoftvertulajdonságokra vonatkozó ügyfélkövetelmények között;
• 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 logikák, adatstruktúrák, interfészek, adatfolyamok modellezési logikái, bemeneti-kimeneti formátumok stb. leírásakor. Ezek a hibák az elemzők specifikációiban és a tervezők hibáin 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 komplexumának ellenőrzésekor észlelt komponensek céljainak és célkitűzéseinek nem megfelelősége);
• az információfeldolgozási folyamat és a folyamatok közötti kölcsönhatás meghatározásával (a komponensek és folyamatok közötti kapcsolatok helytelen meghatározásának eredménye);
• az adatok és struktúráik helytelen hozzárendelésével az egyes komponensek és a PS egészének leírásában;
• 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, a programozók és a 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ömb indexek, 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.);
• ugyanazon név használata különböző objektumok vagy ugyanazon 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 tesztcsomagok és a tesztforgatókönyvek kiválasztásakor stb. általában véve.

Karbantartási folyamat.A karbantartási folyamat során olyan hibákat találnak, amelyeket az üzemeltetési dokumentáció hiányosságai és hibái, a módosíthatóság és olvashatóság nem megfelelő 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;
• I/O é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 működési hibák a nem megfelelően meghatározott funkciók, az alkalmazási sorrend megsértésének vagy a megvalósítás hiányosságának stb.

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 szükséges lekérdezés-feldolgozási sebesség vagy a program-helyreállítási idő elmulasztásával kapcsolatosak.

I/O hibákés az adatok manipulálása az adatok rossz minőségű programvégrehajtási előkészítésének, az adatbázisba való bevitelük vagy az onnan történő lehívásuk meghibásodásának az eredménye.

Interfész hibák az egyes elemek egymással való összekapcsolásának hibáira vonatkoznak, amelyek a köztük lévő adatátvitel során, valamint a működő 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. Tehát egy adatbázissal való munka során hibák vannak az adatok megjelenítésében és manipulálásában, logikai hibákat az alkalmazott adatfeldolgozási eljárások, stb. feladatkörében. A számítási jellegű 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ó szoftver, amely különböző funkciókat valósít meg, hibákat tartalmazhat. különböző típusok. Az interfészhibák és a hatókör-sértések minden rendszertípusnál gyakoriak.

A programok hibatípusainak 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, objektum-orientált módszerek és modellek és programok tervezési eszközei) fejlesztésének jelenlegi szakaszában olyan tervezést végeznek, amelyben a szoftver védve van a leggyakoribb hibáktól, és ezáltal megakadályozza a szoftverhibák megjelenése.

Hiba összekapcsolása hibával.A programban fellépő hiba jelenléte általában a szoftver meghibásodásához vezet működése során. Az ok-okozati összefüggések „hiba-hiba” 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 meghibásodások, 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, valamint 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;
• szoftverdokumentációs és tesztelési folyamatok megközelítéseinek fejlesztése.

A hiba-hiba ok-okozati összefüggés végső célja, hogy módszereket és eszközöket határozzon meg bizonyos osztályok hibáinak tesztelésére és észlelésére, valamint kritériumokat adjon meg egy adathalmazon a tesztelés befejezését; a szoftverfejlesztési, -tesztelési és -karbantartási folyamat megszervezésének javításának módjainak meghatározásában.

A hibatípusok következő osztályozását adjuk:

• hardver, amelyen 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 okoznak, valamint a beviteli eszközök meghibásodása (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, amely információs vagy funkcionális hibákhoz vezethet);
• szoftver, ha hibák vannak az összetevőkben 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ó hibáiból adódhatnak. Másrészt a program fejlesztése során, vagy a program egyes elemeinek 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önfélébb pontjain fedezik fel őket.

A program egyes hibái a követelmények meghatározásában, a tervezésben, a kódgenerálásban vagy a dokumentációban fellépő hibákból származhatnak. Másrészt hibák keletkeznek a program vagy elemeinek interfészeinek fejlesztése során (például, ha a kommunikációs paraméterek beállítási sorrendje megsérül - a szükségesnél kevesebb vagy több stb.).

A hibák megjelenésének oka az ügyfél követelményeinek félreértése; pontatlan követelmények specifikációja a projektdokumentumokban stb. Ez oda vezet, hogy bizonyos rendszerfunkciók megvalósítása nem az ügyfél által javasolt módon fog működni. Ezzel kapcsolatban a megrendelő és a fejlesztő közös megbeszélést folytat a pontosítási követelmények egyes részleteiről.

A rendszertervező 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 ezen operátorok indexei vagy változóértékei rosszul vannak beállítva).