Ebben a részben a szoftvertesztelés különböző típusait fogjuk megérteni, amelyek a szoftverfejlesztési életciklus idején használhatók.
Mint tudjuk, szoftver tesztelés egy olyan folyamat, amely egy alkalmazás funkcionalitását elemzi az ügyfél előfeltételei szerint.
Ha biztosítani akarjuk, hogy szoftverünk hibamentes vagy stabil legyen, akkor különféle szoftverteszteket kell végrehajtanunk, mert a tesztelés az egyetlen módszer, amely hibamentessé teszi alkalmazásunkat.
A szoftvertesztelés különböző típusai
A szoftvertesztelés kategorizálása a változatos tesztelési tevékenységek része, mint pl tesztstratégia, teszteredmények, meghatározott tesztcél stb . A szoftverteszt pedig a szoftver végrehajtása a hibák feltárására.
A tesztelési típus célja, hogy megerősítse a AUT (Alkalmazás tesztelés alatt).
A tesztelés megkezdéséhez rendelkeznünk kell a igény, pályázatkész, szükséges források rendelkezésre állnak . Az elszámoltathatóság fenntartásához hozzá kell rendelnünk egy megfelelő modult a különböző tesztelő mérnökökhöz.
A szoftvertesztelés alapvetően két részre oszlik, amelyek a következők:
Mi az a kézi tesztelés?
Bármilyen szoftver vagy alkalmazás tesztelése az ügyfél igényei szerint automatizálási eszköz használata nélkül kézi tesztelés .
Más szóval azt mondhatjuk, hogy ez egy eljárás ellenőrzés és érvényesítés . A kézi tesztelést arra használják, hogy ellenőrizzék egy alkalmazás vagy szoftver viselkedését a követelmények specifikációival ellentétben.
A kézi tesztesetek végrehajtásához nincs szükségünk semmilyen tesztelőeszköz pontos ismeretére. Könnyedén elkészíthetjük a tesztdokumentumot, miközben bármilyen alkalmazáson manuális tesztelést végzünk.
A kézi teszteléssel kapcsolatos részletes információkért kattintson a következő hivatkozásra: https://www.javatpoint.com/manual-testing.
A kézi tesztelés osztályozása
A szoftvertesztben a kézi tesztelés tovább osztályozható három különböző típusú vizsgálat , amelyek a következők:
A jobb megértés érdekében lássuk őket egyenként:
Fehér doboz tesztelése
A fehér dobozos tesztelés során a fejlesztő minden kódsort megvizsgál, mielőtt átadná a tesztelőcsoportnak vagy az érintett tesztmérnököknek.
Ezt követően a kód észrevehető a fejlesztők számára a tesztelés során; ezért nevezik ezt a folyamatot WBT (White Box Testing) .
Más szóval azt mondhatjuk, hogy a fejlesztő végrehajtja az adott szoftver teljes fehérdobozos tesztelését, és elküldi az adott alkalmazást a tesztelő csapatnak.
A fehérdobozos tesztelés megvalósításának célja, hogy hangsúlyozzák a bemenetek és kimenetek áramlását a szoftver felett, és fokozzák az alkalmazás biztonságát.
A fehér doboz tesztelése más néven nyitott doboz tesztelése, üvegdoboz tesztelése, szerkezeti tesztelése, átlátszó doboz tesztelése és átlátszó doboz tesztelése .
A fehér doboz tesztelésével kapcsolatos alapos ismeretek megszerzéséhez használja az alábbi linket: https://www.javatpoint.com/white-box-testing.
Fekete doboz tesztelése
A kézi tesztelés másik fajtája az fekete doboz tesztelése . Ebben a tesztelésben a tesztmérnök elemzi a szoftvert a követelményeknek megfelelően, azonosítja a hibákat vagy hibákat, és visszaküldi a fejlesztőcsapatnak.
Ezután a fejlesztők kijavítják ezeket a hibákat, elvégzik a White box tesztelését, és elküldik a tesztelő csapatnak.
Itt a hibák kijavítása azt jelenti, hogy a hiba megszűnt, és az adott szolgáltatás az adott követelménynek megfelelően működik.
A fekete doboz tesztelés megvalósításának fő célja az üzleti igények vagy az ügyfél igényeinek meghatározása.
Más szavakkal, azt mondhatjuk, hogy a fekete doboz tesztelése egy olyan folyamat, amely egy alkalmazás funkcionalitását ellenőrzi az ügyfél igényei szerint. A forráskód nem látható ebben a tesztelésben; ezért ismerik fekete doboz tesztelése .
A fekete doboz tesztelésével kapcsolatos további információkért tekintse meg az alábbi linket: https://www.javatpoint.com/black-box-testing.
A fekete doboz tesztelésének típusai
A fekete doboz tesztelése további két részre oszlik, amelyeket az alábbiakban tárgyalunk:
Funkcionális tesztelés
A tesztelő mérnök szisztematikusan ellenőrzi az összes alkatrészt a követelményeknek megfelelően funkcionális tesztelés . A funkcionális tesztelést más néven Alkatrész tesztelés .
A funkcionális tesztelés során az összes komponenst az érték megadásával, a kimenet meghatározásával és a tényleges kimenet várható értékkel való érvényesítésével tesztelik.
A funkcionális tesztelés a black-box tesztelés része, mivel az alkalmazási követelményekre helyezi a hangsúlyt, nem pedig a tényleges kódra. A tesztmérnöknek csak a programot kell tesztelnie a rendszer helyett.
A funkcionális teszteléssel kapcsolatos részletes információkért tekintse meg az alábbi linket: https://www.javatpoint.com/functional-testing .
A funkcionális tesztelés típusai
Csakúgy, mint egy másik típusú tesztelés több részre oszlik, a funkcionális tesztelés is különböző kategóriákba sorolható.
A változatos A funkcionális tesztelés típusai a következőket tartalmazza:
Most pedig értsük meg őket egyenként:
1. Egységteszt
Az egységteszt a funkcionális tesztelés első szintje bármely szoftver tesztelésére. Ebben a tesztmérnök önállóan teszteli egy alkalmazás modulját, vagy teszteli a modul összes funkcióját egységtesztelés .
Az egységteszt végrehajtásának elsődleges célja az egységkomponensek teljesítményének megerősítése. Itt az egység egy szoftver vagy alkalmazás egyetlen tesztelhető funkciójaként definiálható. És ez az egész meghatározott alkalmazásfejlesztési szakaszban ellenőrzött.
Kattintson az alábbi linkre az egységteszttel kapcsolatos teljes információért: https://www.javatpoint.com/unit-testing.
2. Integrációs tesztelés
Miután sikeresen végrehajtottuk az egységtesztelést, megkezdjük az integrációs tesztelést. Ez a funkcionális tesztelés második szintje, ahol a függő modulok közötti adatáramlást teszteljük, vagy két szolgáltatás közötti interfészt ún. integrációs tesztelés .
Az integrációs tesztelés célja az utasítás pontosságának tesztelése az egyes modulok között.
Az integrációs tesztelés típusai
Az integrációs tesztelés szintén a következő részekre oszlik:
Növekményes integrációs tesztelés
Ha egyértelmű kapcsolat van a modulok között, növekményes integrációs tesztelést végzünk. Tegyük fel, hogy veszünk két modult, és elemezzük a köztük lévő adatáramlást, hogy jól működnek-e vagy sem.
Ha ezek a modulok jól működnek, hozzáadhatunk még egy modult, és újra tesztelhetjük. És folytathatjuk ugyanazt a folyamatot, hogy jobb eredményeket érjünk el.
Más szóval azt mondhatjuk, hogy a modulok fokozatos összeadása és a modulok közötti adatáramlás tesztelése ún. Növekményes integrációs tesztelés .
Az inkrementális integrációs tesztelés típusai
A növekményes integrációs tesztelés további két részre osztható, amelyek a következők:
Nézzük meg az integrációs tesztelés ilyen típusainak rövid bemutatását:
1. Felülről lefelé haladó növekményes integrációs tesztelés
Ebben a megközelítésben lépésről lépésre vagy fokozatosan hozzáadjuk a modulokat, és teszteljük a köztük lévő adatáramlást. Biztosítanunk kell, hogy az általunk hozzáadott modulok a a korábbiak gyermeke .
2. Alulról felfelé haladó növekményes integrációs tesztelés
Az alulról felfelé irányuló megközelítésben fokozatosan hozzáadjuk a modulokat, és ellenőrizzük a modulok közötti adatáramlást. És azt is győződjön meg arról, hogy az általunk hozzáadott modul a a korábbiak szülője .
Nem növekményes integrációs tesztelés/ősrobbanás módszer
Amikor az adatáramlás összetett, és nagyon nehéz besorolni egy szülőt és egy gyereket, akkor a nem növekményes integrációs megközelítést alkalmazzuk. A nem növekményes módszert más néven a Big Bang módszer .
Az integrációs tesztelésről és annak típusáról a következő linken tájékozódhat: https://www.javatpoint.com/integration-testing.
3. Rendszertesztelés
Ha végeztünk az egység és az integráció tesztelésével, folytathatjuk a rendszertesztet.
A rendszertesztelés során a tesztkörnyezet párhuzamos az éles környezettel. Úgy is ismert, mint végtől végig tesztelés.
Az ilyen típusú tesztelés során a szoftver minden attribútuma alá esünk, és teszteljük, hogy a végfunkció az üzleti követelményeknek megfelelően működik-e. És elemzi a szoftverterméket teljes rendszerként.
Kattintson az alábbi linkre a rendszertesztelésről szóló teljes információért: https://www.javatpoint.com/system-testing .
Nem-funkciós tesztelés
A fekete doboz tesztelésének következő része nem funkcionális tesztelés . Részletes információkat tartalmaz a szoftvertermékek teljesítményéről és az alkalmazott technológiákról.
A nem funkcionális tesztelés segít minimalizálni a szoftver gyártási kockázatát és a kapcsolódó költségeket.
java for ciklus
A nem funkcionális tesztelés kombinációja teljesítmény, terhelés, stressz, használhatóság és kompatibilitás tesztelése .
A nem funkcionális teszteléssel kapcsolatos további információkért tekintse meg a következő hivatkozást: https://www.javatpoint.com/non-functional-testing.
A nem funkcionális tesztelés típusai
A nem funkcionális tesztelés a tesztelés különböző részeire kategorizálva, amelyeket tovább fogunk tárgyalni:
1. Teljesítményteszt
A teljesítményteszt során a tesztmérnök bizonyos terhelés alkalmazásával teszteli az alkalmazás működését.
Az ilyen típusú nem funkcionális tesztelésnél a tesztmérnök csak több szempontra összpontosít, mint pl Válaszidő, terhelés, méretezhetőség és stabilitás szoftver vagy alkalmazás.
A teljesítményteszt osztályozása
A teljesítményteszt különböző típusú teszteléseket foglal magában, amelyek a következők:
A teljesítményteszt végrehajtása során bizonyos terhelést fogunk alkalmazni az adott alkalmazásra, hogy ellenőrizzük az alkalmazás teljesítményét, ún. terhelési tesztelés . Itt a terhelés kisebb vagy egyenlő lehet a kívánt terhelésnél.
Segítségével felismerhetjük a szoftver legnagyobb üzemi mennyiségét és a szűk keresztmetszeteket.
A terhelési teszteléssel kapcsolatos teljes információért tekintse meg az alábbi linket:
https://www.javatpoint.com/load-testing.
A szoftver felhasználóbarátságának és robusztusságának elemzésére szolgál a közös funkcionális határokon túl.
A stressztesztet elsősorban kritikus szoftverekhez használják, de minden típusú szoftveralkalmazáshoz is használható.
Az alábbi linkre kattintva részletesebben megismerheti a stressztesztet: https://www.javatpoint.com/stress-testing.
Elemzésként az alkalmazás teljesítményét bizonyos mérlegek terhelésének növelésével vagy csökkentésével úgy ismerjük, mint méretezhetőség tesztelése .
A méretezhetőségi tesztelés során ellenőrizhetjük a rendszer, folyamatok vagy adatbázis képességei felfelé irányuló igény kielégítésére. És ebben a Teszt esetek hatékonyan tervezik és hajtják végre.
A méretezhetőségi teszteléssel kapcsolatos részletes információkért kattintson az alábbi linkre:
https://www.javatpoint.com/scalability-testing.
A stabilitásvizsgálat egy olyan eljárás, amelynek során az alkalmazás teljesítményét úgy értékeljük, hogy a terhelést pontosan meghatározott ideig alkalmazzuk.
Elsősorban az alkalmazás állandósági problémáit és a kifejlesztett termék hatékonyságát ellenőrzi. Az ilyen típusú tesztelés során stresszes helyzetben is gyorsan megtaláljuk a rendszer hibáját.
python lista inicializálása
A stabilitásteszttel kapcsolatos részletes információkért tekintse meg az alábbi linket:
https://www.javatpoint.com/stability-testing.
2. Használhatóság tesztelése
Egy másik típus nem funkcionális tesztelés van használhatósági tesztelés . A használhatósági tesztelés során elemezzük egy alkalmazás felhasználóbarát jellegét, és felderítjük a szoftver végfelhasználói felületén található hibákat.
Itt a kifejezés felhasználóbarátság az alkalmazás következő szempontjait határozza meg:
- Az alkalmazásnak könnyen érthetőnek kell lennie, ami azt jelenti, hogy minden funkciónak láthatónak kell lennie a végfelhasználók számára.
- Az alkalmazás megjelenésének és érzetének jónak kell lennie, ami azt jelenti, hogy az alkalmazásnak kellemes megjelenésűnek kell lennie, és a végfelhasználó számára érezni kell a használatát.
A használhatósági teszteléssel kapcsolatos további információkért tekintse meg az alábbi linket:
https://www.javatpoint.com/usability-testing.
3. Kompatibilitási tesztelés
A kompatibilitási tesztelés során ellenőrizzük egy alkalmazás működőképességét meghatározott hardver- és szoftverkörnyezetekben. Ha az alkalmazás funkcionálisan stabil, akkor csak akkor megyünk tovább kompatibilitási tesztelés .
Itt, szoftver azt jelenti, hogy tesztelhetjük az alkalmazást különböző operációs rendszereken és más böngészőkön, ill hardver azt jelenti, hogy különböző méreteken tesztelhetjük az alkalmazást.
A kompatibilitástesztelés alapos megismeréséhez tekintse meg az alábbi linket:
https://www.javatpoint.com/compatibility-testing .
Szürke doboz tesztelése
Egy másik része kézi tesztelés van Szürke doboz tesztelése . Ez egy a fekete doboz és a fehér doboz tesztelésének együttműködése .
Mivel a szürke doboz tesztelése magában foglalja a belső kódoláshoz való hozzáférést a tesztesetek tervezéséhez. A szürke doboz tesztelését olyan személy végzi, aki ismeri a kódolást és a tesztelést is.
Más szóval azt mondhatjuk, hogy ha egy egyszemélyes csapat mindkettőt elvégezte fehér doboz és fekete doboz tesztelése , úgy tartják szürke doboz tesztelése .
A Gray box tesztelésével kapcsolatos részletes információkért tekintse meg az alábbi linket:
https://www.javatpoint.com/grey-box-testing.
Automatizálási tesztelés
A szoftvertesztelés legjelentősebb része az automatizálási tesztelés. Speciális eszközöket használ a manuális tervezési tesztesetek automatizálására emberi beavatkozás nélkül.
Az automatizálási tesztelés a legjobb módja a szoftvertesztelés hatékonyságának, termelékenységének és lefedettségének növelésének.
A manuálisan, gyorsan és ismételten végrehajtott tesztforgatókönyvek újrafuttatására szolgál.
Más szavakkal, azt mondhatjuk, hogy amikor egy alkalmazást bizonyos eszközök segítségével tesztelünk, az úgynevezett automatizálási tesztelés .
Automatizálási tesztelésre akkor fogunk menni, amikor különböző kiadások vagy több regressziós ciklus megy az alkalmazáson vagy szoftveren. Nem tudjuk megírni a tesztszkriptet vagy végrehajtani az automatizálási tesztelést a programozási nyelv ismerete nélkül.
Az automatizálási teszteléssel kapcsolatos további információkért tekintse meg az alábbi linket:
https://www.javatpoint.com/automation-testing.
Néhány más típusú szoftvertesztelés
A szoftvertesztben van néhány más típusú tesztelés is, amelyek nem részei a fent tárgyalt teszteléseknek, de ezek a tesztelések szükségesek bármely szoftver vagy alkalmazás teszteléséhez.
Nézzük meg egyenként az ilyen típusú teszteléseket:
Ban ben füstvizsgálat , teszteljük az alkalmazás alapvető és kritikus jellemzőit, mielőtt egy körös mélyreható és szigorú tesztelést végzünk.
Vagy az összes lehetséges pozitív és negatív érték ellenőrzése előtt ismert füstvizsgálat . A füstteszt végrehajtásának fő célja az alkalmazás alapvető és fő funkcióinak munkafolyamatának elemzése.
A füstvizsgálattal kapcsolatos további információkért tekintse meg az alábbi linket:
https://www.javatpoint.com/smoke-testing.
Józanság tesztelése
Arra szolgál, hogy az összes hibát kijavítsák, és a változtatások miatt ne merüljenek fel további problémák. Az épelméjűség tesztelése nem írt alá, ami azt jelenti, hogy nem tudjuk dokumentálni. Ellenőrzi az újonnan hozzáadott funkciók és összetevők helyességét.
A józansági vizsgálatokkal kapcsolatos részletes információkért az alábbi linkre kattintva tájékozódhat:
https://www.javatpoint.com/sanity-testing.
Regressziós teszt
A regressziós tesztelés a szoftvertesztelés leggyakrabban használt típusa. Itt a kifejezés regresszió azt jelenti, hogy újra kell tesztelnünk az alkalmazás nem érintett részeit.
A regressziós tesztelés a legalkalmasabb tesztelés az automatizálási eszközök számára. A projekt típusától és az erőforrások hozzáférhetőségétől függően a regressziós tesztelés hasonló lehet Újratesztelés .
Amikor a fejlesztők kijavítanak egy hibát, majd tesztelik az alkalmazások egyéb funkcióit, amelyek a hibajavítás miatt szimulálhatók, az úgynevezett regressziós teszt .
Más szóval azt mondhatjuk, hogy amikor egy projekthez új kiadás érkezik, akkor regressziós tesztelést végezhetünk, és egy új funkció miatt hatással lehet a korábbi kiadások régi funkcióira.
A regressziós teszteléssel kapcsolatos alapos ismeretek megszerzéséhez tekintse meg az alábbi linket:
https://www.javatpoint.com/regression-testing .
Felhasználói elfogadási teszt
A felhasználói elfogadási tesztelést (UAT) a tartományszakértő/ügyfél néven ismert egyéni csapat vagy az ügyfél végzi. Az alkalmazás ismerete a végtermék elfogadása előtt pedig ún felhasználói elfogadási teszt .
A felhasználói elfogadási tesztelés során elemezzük az üzleti forgatókönyveket és a valós idejű forgatókönyveket a különálló környezetben, az úgynevezett UAT környezet . Ebben a tesztelésben az alkalmazást az UAI előtt teszteljük az ügyfél jóváhagyása érdekében.
A felhasználói elfogadási teszttel kapcsolatos további információkért kattintson az alábbi linkre:
https://www.javatpoint.com/acceptance-testing.
Feltáró tesztelés
Ha a követelmény hiányzik, korai iterációra van szükség, és a tesztelőcsapat tapasztalt tesztelőket alkalmaz, amikor kritikus alkalmazásunk van. Új tesztelő mérnök lépett be a csapatba, majd megyünk a feltáró tesztelés .
A feltáró tesztelés végrehajtásához először minden lehetséges módon végignézzük az alkalmazást, tesztdokumentumot készítünk, megértjük az alkalmazás menetét, majd teszteljük az alkalmazást.
Kattintson a következő linkre, hogy teljes körű információt kapjon a feltáró tesztelésről:
https://www.javatpoint.com/exploratory-testing.
Adhoc tesztelés
Az alkalmazás véletlenszerű tesztelése, amint a build az ellenőrzött sorrendbe kerül, az úgynevezett Adhoc tesztelés .
Úgy is hívják Majomtesztelés és Gorilla tesztelés . Adhoc tesztelés során az ügyfél követelményeinek ellentmondó alkalmazást ellenőrizzük; ezért más néven negatív teszt .
Amikor a végfelhasználó véletlenül használja az alkalmazást, és hibát észlelhet. Ennek ellenére a speciális tesztelő mérnök alaposan használja a szoftvert, így előfordulhat, hogy nem azonosít hasonló észlelést.
Az Adhoc teszteléssel kapcsolatos részletes információkért olvassa el a következőket:
https://www.javatpoint.com/adhoc-testing.
Biztonsági tesztelés
A szoftvertesztelés elengedhetetlen része, a szoftveralkalmazás gyenge pontjainak, kockázatainak vagy fenyegetéseinek meghatározására szolgál.
A biztonsági tesztek végrehajtása segít elkerülni a kívülállók csúnya támadásait, és biztosítja szoftveralkalmazásaink biztonságát.
Más szóval azt mondhatjuk, hogy a biztonsági tesztelés elsősorban annak meghatározására szolgál, hogy az adatok biztonságban legyenek és kibírják-e a szoftver munkafolyamatát.
A biztonsági teszteléssel kapcsolatos részletekért tekintse meg az alábbi linket: https://www.javatpoint.com/security-testing.
Globalizációs tesztelés
A szoftvertesztelés másik fajtája az Globalizációs tesztelés. A globalizációs tesztelés segítségével ellenőrizhető, hogy a kifejlesztett szoftver több nyelven van-e vagy sem. Itt a szavak globalizáció az alkalmazás vagy szoftver felvilágosítását jelenti különböző nyelveken.
A globalizációs tesztelés segítségével megbizonyosodhat arról, hogy az alkalmazás több nyelvet és több funkciót is támogat.
A jelenlegi forgatókönyvekben több technológiai fejlesztés is tapasztalható, mivel az alkalmazások globális használatra készültek.
A globalizációs teszteléssel kapcsolatos teljes információkért tekintse meg az alábbi linket:
https://www.javatpoint.com/globalization-testing.
Következtetés
Az oktatóanyagban a szoftvertesztelés különféle típusait tárgyaltuk. De továbbra is létezik egy több mint 100-nál több tesztelési kategória listája. Azonban nem minden típusú tesztelést alkalmaznak minden típusú projektben.
Megbeszéltük a szoftvertesztelés leggyakrabban használt típusait, mint például fekete doboz tesztelés, fehér doboz tesztelés, funkcionális tesztelés, nem funkcionális tesztelés, regressziós tesztelés, Adhoc tesztelés stb. .
Ezenkívül a különböző szervezetekben különböző osztályozásokat vagy folyamatokat alkalmaznak, de az általános koncepció mindenhol hasonló.
Ezek a tesztelési típusok, folyamatok és végrehajtási megközelítések folyamatosan változnak, amikor a projekt, a követelmények és a hatókör változik.