A szoftvertesztelés egy hihetetlenül összetett és intenzív terület, ahol a vállalatok és a független fejlesztők mind arra törekszenek, hogy termékeiket különböző tesztelési módszerekkel javítsák.
Az egyik leggyakoribb módszer, amelyet a vállalatok tesztelésre használnak, a fekete dobozos tesztelés, egy olyan technika, amely távolságot teremt a fejlesztők és a tesztelők között a pontos eredmények biztosítása és az elfogultság kiküszöbölése érdekében.
Ebben a részletes útmutatóban többet megtudhat arról, hogy mi a fekete dobozos tesztelés, hogyan kell elvégezni a fekete dobozos tesztelést, és milyen előnyökkel jár a fekete dobozos tesztelés bevezetése a szoftverfejlesztésben.
Mi az a fekete dobozos tesztelés?
A fekete dobozos tesztelés egy rendszer vagy szoftver tesztelésének folyamatára utal, anélkül, hogy előzetes ismeretekkel rendelkeznénk arról, hogy a rendszer vagy szoftver belsőleg hogyan működik. Ez nem csak arra vonatkozik, hogy nem ismeri magát a forráskódot, hanem arra is, hogy nem látta a szoftvert körülvevő tervdokumentációt. A tesztelők egyszerűen megadják a bemenetet és megkapják a kimenetet, ahogyan a végfelhasználó tenné. Bár ez egy egyszerű fekete dobozos tesztelés definíciója, mégis meghatározza az általános rendszert.
A fekete dobozos tesztelés célja, hogy a felhasználók a szokásosnál természetesebb módon lépjenek kapcsolatba a szoftverrel, anélkül, hogy a szoftver ismeretéből adódó előítéletekkel rendelkeznének.
Ebben a módszertanban a tesztek elvégzéséért felelős személyek különböznek azoktól, akik a szoftvert fejlesztették, így a két csapat elkülönül egymástól.
1. Mikor és miért van szükség fekete dobozos tesztelésre a szoftvertesztelésben?
A fejlesztési ciklusnak van néhány olyan szakasza, amikor a fekete dobozos tesztelés ideális, a legtöbb fekete dobozos tesztelésre a fejlesztés végén, röviddel a kiadás előtt kerül sor.
Ez olyan módszereket foglal magában, mint például a felhasználói átvételi tesztelés, amelynek során a szoftver a szoftver célközönségének tagjaihoz kerül, egyfajta kiadás előtti tesztelésként. Ez a béta tesztelés néven ismert, és ideális eszköz egy vállalat számára, mivel a nagyobb kitettség azt jelenti, hogy az emberek nagyobb valószínűséggel találnak potenciális hibákat a szoftverben.
A fejlesztési ciklus vége felé a fekete doboz módszertannal való munka elengedhetetlen, mivel ez az a verzió, amelyhez a felhasználó nagyobb valószínűséggel hozzáfér. Használhatna fekete dobozos tesztelést az egyes funkciókhoz, de ez meghiúsítaná a tesztelés célját.
2. Amikor nincs szükség fekete dobozos tesztelésre
A fekete dobozos tesztelésnek nagyon kevés célja van a fejlesztés legkorábbi szakaszában. Amikor egy vállalat a szoftver alapvető funkcionalitását építi ki, fehérdobozos tesztelést alkalmaz, hogy a fejlesztő láthassa, a kód mely pontján vannak problémák.
Nincs szükség fekete dobozos tesztelésre akkor sem, ha a szoftver nyílt forráskódú vagy viszonylag egyszerű webes eszköz, illetve ha egy harmadik fél kódolási projektjének segítésére tervezték, mivel viszonylag csupasz felhasználói felület van, és a felhasználó egyébként is hozzáférhet a program forráskódjához. Ha elvárja, hogy a felhasználó hozzáférjen a forráskódhoz, a fekete dobozos tesztelés elveszíti fő célját.
3. Ki vesz részt a fekete dobozos tesztelésben?
A fekete dobozos tesztelési folyamatban számos szerepkör vesz részt, ezek közül néhány a tesztelést végző vállalat jellegétől függ.
A fekete dobozos tesztelési folyamatban részt vevő jelentős szerepek a következők:
– Tesztelő
A tesztelő felelős a manuális tesztesetek elvégzéséért egy vállalatnál, alapos tesztesetek írásával, amelyek részletesen megvizsgálják az alkalmazást, mielőtt végrehajtják és jelentik az eredményeket. Ez a szerep elsősorban a manuális tesztelési folyamatokban létezik, ahol pedig a teszt automatizálása megtörtént, ott az automatizált rendszerek veszik át a szerepet.
– QA elemző
A minőségbiztosítási elemző felelős a tesztesetek programozásáért a minőségbiztosítási folyamat során, elsősorban akkor, ha a vállalat a minőségbiztosítási tesztek automatizálási folyamatát használja.
A folyamat magában foglalja mind a magas szintű funkcionalitást biztosító alapos tesztesetek tervezését, mind a tesztesetek végrehajtását, és az eredmények lekérdezését, amikor azok befejeződtek.
– Fejlesztő
A QA csapat által tesztelt szoftver fejlesztéséért felelős személy. A fejlesztő visszajelzést kap a tesztelő csapattól, és ennek megfelelően frissíti a szoftvert, a fejlesztőcsapat részeként dolgozik, de folyamatos kapcsolatban áll a tesztelőkkel.
– QA menedzser
A minőségbiztosítási vezető a minőségbiztosítási csapat vezetője, aki a tesztelők által végzett összes feladat irányításáért felelős.
Ez magában foglalja a tesztelési ütemterv összeállítását, a munkatársak számára a tennivalók listájának megszervezését, valamint a csapatban felmerülő konfliktusok megoldását. A fekete dobozos tesztelést is elmagyarázzák az új alkalmazottak képzésében.
– Projektvezető
A végső projekt minőségéért felelős személy, a projektvezető felügyeli a tesztelési folyamatot és a fejlesztést is, biztosítva, hogy az ügyfél a teljes megbízásnak megfelelő szoftvercsomagot kapjon.
A fekete dobozos tesztelés előnyei
A fekete dobozos tesztelésnek számos jelentős előnye van a fejlesztési munkában. Minél inkább tisztában van ezekkel az előnyökkel, annál jobban ki tudja használni őket, és minél több előnyt tud kihasználni a technikából.
A fekete dobozos tesztelés használatának néhány fő előnye a minőségbiztosításban:
1. Nincs szükség műszaki ismeretekre
A fekete dobozos megközelítés azt jelenti, hogy az alkalmazás vizsgálatakor nincs szükség műszaki ismeretekre.
A fekete dobozos tesztelés célja annak vizsgálata, hogyan működik az alkalmazás a végfelhasználó számára, és az átlagos felhasználó a legtöbb esetben nem rendelkezik fejlett technikai ismeretekkel. Ez csökkentheti a tesztelés költségeit, segítve a szervezetet abban, hogy több hibát fedezzen fel alacsonyabb költséggel, és ezáltal pénzügyileg hatékonyabbá váljon.
2. A felhasználó pontos modellezése
A fekete dobozos tesztelési folyamat végcélja, hogy megértsük, milyen problémák merülnek fel az alkalmazással, amikor a felhasználó a mindennapokban kapcsolatba lép vele.
A fekete dobozos tesztelés egyes típusai – amelyek a felhasználó viselkedésének reprodukálására összpontosítanak – nagy pontossággal modellezik a felhasználó viselkedését. Ez különösen igaz a felhasználói elfogadási tesztelésre, amelynek során a végfelhasználók megtapasztalják a terméket, és nem csak modellezik vagy szimulálják a felhasználó viselkedését, hanem ténylegesen megvalósítják azt.
A pontos modellezés segít feltárni minden olyan hibát, amely hatással van a felhasználó tényleges munkafolyamataira.
3. Képesség a tesztelés crowdsource-olására
A fekete dobozos tesztelés a tesztelés egyik legkönnyebben hozzáférhető formája, köszönhetően a viszonylag alacsony képzettségi követelményeknek.
Ez azt jelenti, hogy a vállalatok nem csak alacsonyabb szintű műszaki ismeretekkel rendelkező tesztelőket alkalmazhatnak, hanem a tesztelésüket crowdsource-olhatják a lelkes ügyfeleknek. Ez egyre gyakoribb a játékiparban, ahol a vállalatok korai hozzáférést kínálnak, és idővel frissítik a játékot, hogy megoldják a felhasználók által talált problémákat.
A hibák megtalálása ebben az esetben sokkal könnyebb, mivel az összes funkció sokkal nagyobb nyilvánosságot kap.
A fekete dobozos tesztelés kihívásai
A fekete dobozos tesztelés előnyei mellett van néhány nagyobb kihívás, amellyel számolnia kell. Ha tisztában van ezekkel a kihívásokkal, akkor alkalmazkodni tud hozzájuk, és a fekete dobozos tesztelés káros hatásainak csökkentésével növelheti a tesztelés színvonalát.
Néhány ilyen kihívás:
1. Nehéz megtalálni a probléma okait
A fekete dobozos tesztelés egyik fő hátránya, hogy nehezebb lehet megtalálni a problémák okát, ha a tesztelők nem férnek hozzá a forráskódhoz.
Miközben le tudják írni, hogy mi a hiba és mikor jelentkezik, nem tudják, hogy a forráskód melyik része okozza a problémát, vagy hogy miért.
A tesztelők ezt némileg enyhíthetik azzal, hogy alaposan feljegyzik a hibákat, és a fejlesztő részletes hibaüzenetei további betekintést nyújtanak a jövőbeli frissítésekhez.
2. Az automatizálás trükkösebb
Mivel aktívan próbáljuk megismételni azt a módot, ahogyan a felhasználó interakcióba lép egy szoftvercsomaggal, rendkívül nehéz lehet automatizálni a fekete dobozos tesztelési folyamatot.
Ennek első oka az, hogy a tesztelőnek nincs hozzáférése a forráskódhoz, ami megnehezíti a pontos teszteset kódolását. Ez párosul azzal a ténnyel, hogy a tesztelést úgy tervezték, hogy a lehető legjobban utánozza az emberi viselkedést, és az automatizációt kifejezetten úgy tervezték, hogy robotikusan viselkedjen.
Ezt a problémát úgy tudja ellensúlyozni, hogy automatizálja az egyszerűbb feladatokat, és ahol lehetséges, kombinálja az automatizálást a kézi tesztekkel.
3. A nagyszabású teszteléssel kapcsolatos nehézségek
Az automatizálással kapcsolatos fent említett nehézségek azt jelentik, hogy a nagyobb léptékű tesztelés bonyolultabb. A nagyszabású tesztelés sokkal több adatot szolgáltat a vállalatoknak a szoftverről, és azt jelenti, hogy a hibákat könnyebb megtalálni és megismételni.
A manuális tesztelés prioritásként való megkövetelése azt jelenti, hogy nehezebb lehet nagyobb léptékű tesztelést szervezni. Egyes vállalatok ezt egy “nyílt béta” rendszerrel ellensúlyozzák, amelyben bárki, akit érdekel a termék, segíthet a kiadás előtti tesztelésben, és önkéntes alapon visszajelzéssel támogathatja a vállalatot a korai verziókról.
A fekete dobozos tesztek jellemzői
A fekete dobozos teszteknek van néhány fő jellemzője, amelyekkel tisztában kell lenniük, és amelyek megkülönböztetik a tesztelést a szoftverminőség-ellenőrzés bármely más formájától.
Ezek a jellemzők a következők:
1. Nincs előzetes belső ismeret
A fekete dobozos tesztek nem igényelnek előzetes belső ismereteket a szoftverről. Ez bizonyos esetekben nehéz lehet, mivel a tesztelőknek van némi elképzelésük a tesztelendő szoftver aspektusairól és a keresett funkciókról, de ez tágan értelmezve azt jelenti, hogy nem láthatnak semmilyen belső dokumentációt.
Egyszerűen fogalmazva, ha az információ látható lenne a végfelhasználó számára egy alkalmazásboltban vagy egy weboldal letöltési oldalán, akkor a tesztelő is láthatja azt.
2. Külön tesztelők és fejlesztők
A tesztelési és a fejlesztési szakaszokat különböző személyek végzik egy fekete dobozos tesztelési helyzetben. Ez a különbségtétel a tesztelők ismereteinek hiányából ered, mivel a fejlesztők ismerik a forráskódot, mivel ők voltak felelősek a fejlesztésért.
A vállalatok ezt az adott helyzettől függően többféleképpen közelítik meg: egyesek külső szervezetet vesznek igénybe a tesztelés elvégzésére, a nagyobb vállalatok pedig külön tesztelői részleggel rendelkeznek, hogy elvégezzék ezt a munkát.
3. Késői tesztelés
Ez arra a fejlődési szakaszra utal, amelyben ez a tesztelés történik. A fekete dobozos tesztek egy meglévő alkalmazás viszonylag fejlett verziójára támaszkodnak, amely átfogó felhasználói felülettel rendelkezik, amely lehetővé teszi a teljes navigációt a szoftverben, és hozzáférést biztosít minden funkció elülső részéhez.
Ez azt jelenti, hogy a fekete dobozos tesztek csak a tesztelési folyamat néhány későbbi szakaszában lehetségesek, amikor mindezt már kezdetben kidolgozták. Bár a felhasználói felület és a vezérlőelemek idővel módosulhatnak, valamilyen formában létezniük kell, hogy a fekete dobozos tesztek hozzáférhessenek a funkciókhoz.
Mit tesztelünk a fekete dobozos tesztekben
A fekete dobozos tesztelés egy szoftvercsomag bizonyos aspektusait vizsgálja, és a szoftver egyes területein olyan extra információkat szolgáltat, amelyek az általános életminőséget növelő frissítésekhez vezetnek.
A szoftvercsomag néhány fő része, amelyet a tesztelők a fekete dobozos teszt során vizsgálnak, a következők:
1. Funkcionalitás
Egyes fejlesztők a fekete dobozos tesztelést használják annak biztosítására, hogy egy szoftver a szándékolt módon működjön egy olyan személy számára, aki nem rendelkezik megfelelő ismeretekkel.
Az emberek túlnyomó többsége, akik bármilyen szoftvert kereskedelmi célokra használnak, ezt anélkül teszi, hogy ismerné a szoftver belső működését, így a tesztelés e tudás birtokában azt jelenti, hogy ismeri a meglévő problémák megoldását.
Ez az alapos funkcionalitás-tesztelés biztosítja, hogy mindenki a legjobbat tapasztalja meg, amit az alkalmazás nyújtani tud, ahelyett, hogy olyan hibákkal találkozna, amelyeket a fehérdobozos tesztelés során nem látunk.
2. Felhasználói felület
A felhasználói felület minden olyan módot jelent, ahogyan a felhasználó gyakorlatilag kölcsönhatásba lép egy alkalmazással, hogy az elvégezzen egy sor feladatot. Ez magában foglalja a menüket, amelyekkel a felhasználó dolgozik, az alkalmazásban jelenlévő speciális gombokat és a szoftverben található márkajelzéseket.
A fejlesztők idejük nagy részét annak biztosításával töltik, hogy maga az alkalmazás az elvárásoknak megfelelően fusson, ami azt jelenti, hogy a felhasználói felületre kevesebb figyelem jut.
A fekete dobozos tesztelés során a tesztelők csak a szoftver felhasználói oldali funkcióit ismerik meg, így a tesztelés legtöbb más szakaszához képest nagyobb figyelmet fordítanak a felhasználói felületre.
3. Teljesítmény
A normális működés és a jó megjelenés mellett az alkalmazás teljesítménye is lényeges az ügyfelek tetszésének eléréséhez.
A teljesítmény több tényezőre utal, többek között arra, hogy az alkalmazás milyen gyorsan reagál a felhasználói bemenetekre, és milyen erőforrásokat használ fel egy adott eszközön.
Az olyan tesztelési formátumok, mint a végponttól végpontig tartó tesztelés, amelyek egy szoftver összes funkcióját vizsgálják, a fejlesztők láthatják, hogy mennyi memóriát használ egy alkalmazás, és hogy mely funkciók terhelik leginkább az adott eszközt, ami a hatékonysággal és a teljesítménnyel kapcsolatos frissítéseket irányítja az alkalmazás későbbi verzióiban.
Tisztázzuk a félreértéseket:
Fekete doboz vs. Fehér doboz vs. Greybox tesztelés
A fekete dobozos tesztelés egy olyan fogalom, amely hasonlóan hangzik a szürke dobozos és a fehér dobozos teszteléshez, de az elképzelések alapvetően nagyon különböznek egymástól. Összezavarásuk komoly kommunikációs problémákat okozhat a fejlesztési folyamatban, és a frissítési folyamat lelassulását, valamint kevésbé hatékony működését eredményezheti.
Olvasson tovább, hogy tisztázza a “dobozos tesztelés” különböző típusai körüli zűrzavart, hogy miben különböznek egymástól, és mikor érdemes használni őket.
1. Mi a White Box tesztelés?
A fehérdobozos tesztelés néha “üvegdobozos tesztelésként” ismert, és olyan tesztelési folyamatra utal, ahol a tesztelőnek teljes hozzáférése van a szoftver mögötti összes információhoz. Ez magában foglalja a forráskódhoz és a tervezési dokumentumokhoz való hozzáférést, valamint a csomag ügyféltájékoztatóját.
Ha például egy tesztelő a fejlesztési folyamat legkorábbi szakaszában dolgozik, és egyetlen funkciót vizsgál, a funkció forráskódjának megtekintése azt jelenti, hogy azonnal megtalálhatja a probléma okát.
Az egyik legjobb alkalom a fehérdobozos tesztelés alkalmazására elsősorban a belső feladatoknál van. Ez az alkalmazás funkcionális oldalának korai fejlesztésére vonatkozik, a gyors javítások ideálisak, mivel a kód elkendőzésének nincs haszna, ha nem szimuláljuk a felhasználói élményt. A nyílt forráskódú rendszereknél is alkalmazzák a fehér kód tesztelését, mivel a forráskód ilyenkor minden felhasználó számára elérhető.
Mi a különbség a white box és a black box tesztelés között?
A fő funkcionális különbség a fekete dobozos és a fehér dobozos tesztelés között az, hogy a tesztelő milyen szintű hozzáféréssel rendelkezik a szoftverhez, de ez sokkal jelentősebb hatással van a tesztelés olyan aspektusaira, mint például az időzítés.
A fekete dobozos tesztelés a folyamat későbbi szakaszában, a termék bevezetéséhez közeledve következetesebben alkalmazható, a fejlesztés alapfázisaiban pedig a fehér dobozos tesztelés átláthatósága és érzékenységének előnyeit élvezhetjük. A fekete dobozos teszt és a fehér dobozos teszt közötti különbség a szükséges szakértelem szintjében is megmutatkozik, mivel a fehér dobozos tesztelés a kódolás és a fejlesztés terén szükséges szakértelmet igényel ahhoz, hogy hatékonyabb legyen.
2. Mi a szürke doboz tesztelés?
A szürke dobozos tesztelés a tesztelés olyan formája, amelyben a felhasználónak van némi ismerete a kódról, de nincs teljes hozzáférése. Ez magában foglalja a tesztelt funkció forráskódjának meglétét vagy a tervdokumentáció egy részéhez való hozzáférést, hogy a felhasználó megértse, mi a szoftvercsomag általános szándéka.
Ha például egy tesztelő csak egy szoftvercsomag egyik funkcióját vizsgálja, akkor hozzáférhet az alkalmazásnak csak ehhez az egy részéhez tartozó forráskódhoz.
A vállalatok elsősorban akkor használják a szürke dobozos tesztelést, amikor azt vizsgálják, hogyan integrálódik egy alkalmazás egy harmadik féltől származó eszközzel. A folyamatnak csak egy részéhez férhetnek hozzá a forráskódhoz, ami korlátozza az alapos white box tesztelés elvégzésének lehetőségét. Ehelyett látják a harmadik féltől származó integráció bemeneteit és kimeneteit, valamint az integrációért felelős forráskódot.
A tesztelők ezt arra használják, hogy felmérjék, hogy a szoftver, a harmadik féltől származó alkalmazás vagy a kettő közötti integráció miatt merülnek-e fel problémák.
Mi a különbség a fekete dobozos és a szürke dobozos tesztelés között?
A fő különbség a fekete dobozos és a szürke dobozos tesztelés között ismét az információhoz való hozzáférés szintje, és a tesztelt szoftver típusa az egyik fő megkülönböztető tényező a tesztelési típusok között.
A szürke dobozos tesztelés általában harmadik féltől származó eszközöket, például felhőalapú adattárolást vagy külső feldolgozóeszközöket foglal magában, míg a fekete dobozos rendszerek általában egyetlen összefüggő egységet alkotnak. Sok fekete dobozos tesztet harmadik felek nem zavarnak, míg az integrált alkalmazásoknak alig van más választásuk, mint a szürke dobozos tesztelési módszertan szerint dolgozni.
3. Következtetés: Fekete doboz vs. fehér doboz vs. szürke doboz tesztelés
Végső soron alapvető különbségek vannak a fekete, a szürke és a fehér dobozos tesztelés között, amelyek mind azon alapulnak, hogy a tesztelő csapat elé kerülnek-e a kulisszák mögötti információk.
A fekete dobozos és a fehér dobozos tesztelés ennek a spektrumnak a végpontjai, a szürke dobozos tesztelés pedig mindent magában foglal, kivéve a harmadik féltől származó forráskódot, és csak egy adott funkció mögötti kódot láthatjuk.
Mindegyik tesztelési módszer szerepet játszik a szoftvertesztelésben, ezért időt és figyelmet kell fordítanunk a megtanulásukra és hatékony alkalmazásukra.
A Black Box tesztek típusai
A fekete dobozos tesztelésnek három fő típusa van, amelyek magukban foglalják az összes olyan tesztelést, amelyet egy vállalat a fekete dobozos módszertan segítségével végez. Ezek a következők:
1. Funkcionális tesztelés
A funkcionális tesztelés magában foglal mindent, ami az alkalmazás mechanikai működését övezi. Ez magában foglalja annak biztosítását, hogy az adatokat megfelelő módon kezelje, lehetővé tegye a felhasználók számára a megfelelő hitelesítő adatokkal történő bejelentkezést, valamint az információk és bevitelek feldolgozását az elvárásoknak megfelelően.
A funkcionalitás tesztelése a folyamat egyik legfontosabb szempontja, amely magában foglalja mind az alkalmazás helyi funkcionalitását, mind pedig azt, hogy az hogyan lép kölcsönhatásba külső eszközökkel és programokkal, például felhőalapú szolgáltatásokkal vagy egyszeri bejelentkezési eszközökkel.
2. Nem funkcionális tesztelés
A nem funkcionális tesztelés olyan tesztelés, amely a szoftver bármely olyan aspektusát vizsgálja, amely nem kapcsolódik kifejezetten az alkalmazás funkcionalitásához. Ez magában foglalja annak megállapítását, hogy az alkalmazás használható és könnyen érthető-e a felhasználók számára, kompatibilis-e az eszközök és operációs rendszerek széles skálájával, és hogyan teljesít jelentős terhelés mellett (bár ez bizonyos pontokon átcsúszhat a funkcionális tesztelésbe).
Ez elsősorban a fejlesztési folyamat vége felé történik, miután a teljes alkalmazás lefordításra került.
3. Regressziós tesztelés
A frissítés után a tesztelők átnézik az alkalmazást, hogy megbizonyosodjanak arról, hogy az teljesítette a tervezett funkciót, és nincsenek olyan nem kívánt mellékhatások, amelyek az alkalmazás visszafejlődését okozzák.
Ezt regressziós tesztelésnek nevezik, és alapvető része annak, hogy egy alkalmazás készen álljon a piacra lépésre.
A regressziós tesztelést minden egyes frissítés után alkalmazzák, hogy megbizonyosodjanak arról, hogy az alkalmazás funkcionális és nem funkcionális aspektusai megfelelnek-e a korábban elért színvonalnak.
Fekete doboz tesztelési technikák
A fekete dobozos tesztelési folyamat során a technikák széles skáláját alkalmazhatja a munkája színvonalának javítása érdekében. A minőségbiztosítási környezetben alkalmazott legfontosabb fekete dobozos tesztelési technikák közé tartozik:
1. Páros tesztelés
A páros tesztelés a tesztelés egy olyan formája, amely a szoftverben lehetséges adatbevitelek minden egyes kombinációjának kipróbálására összpontosít.
Például, ha az egytől tízig terjedő számok az egyik oszlopban az összes érvényes bejegyzést tartalmazzák, egy másikban pedig az összes ábécé karaktert, a páros tesztelés minden lehetséges kombinációt tesztel 1A-tól 10Z-ig. Ez a tesztelés olyan formája, amelynek elvégzése sok időt és erőfeszítést igényel a felhasználó számára, így ez az egyik olyan technika, amely a leginkább nyitott a potenciális hiperautomatizálás előtt. Ez rendkívül alapos, és megtalálja az adatbevitellel kapcsolatos esetleges problémákat.
2. Határérték-elemzés
Számos szoftver adatbevitelre épül, és az adatoknak meghatározott határok között kell dolgozniuk, amelyeken belül az ügyfélnek dolgoznia kell.
Például egy olyan rendszer, amelyet 1-től 100-ig terjedő számok kiszámítására terveztek, nehézségekbe ütközhet a 0 vagy annál alacsonyabb, illetve a 100-nál magasabb értékekkel.
A határérték-elemzés magában foglalja e határok tesztelését, számok bevitelét a szoftver által tesztelt határoknál és azok környékén, hogy megvizsgálja, vannak-e hibák a szoftvercsomag elvárt működési tartományának szélén. Ez elsősorban a számításokon alapuló rendszereknél előnyös, és segíthet a fejlesztőknek a határok kiigazításában vagy a problémák okának megtalálásában.
3. Állapotátmenet tesztelése
Sok program változik a különböző “állapotok” vagy “módok” között, és átmenetet igényel a folyamat egyik szakaszából a másikba. Ha ezek az átmenetek megfelelően működnek, az azt jelenti, hogy az oldal a felhasználó elvárásainak megfelelően működik, és nincsenek váratlan fennakadások.
Az állapotátmenet-tesztelés a tesztelés egy olyan formája, amely egy szoftver összes állapotátmenetét vizsgálja, biztosítva, hogy azok működőképesek legyenek, és bizonyosságot adva arról, hogy a felhasználó a szoftveren keresztül váratlan megszakítások nélkül működik.
Fekete doboz tesztelés a szoftverfejlesztés életciklusában
A fekete dobozos tesztelés olyan tudományág, amelyet elsősorban a szoftverfejlesztés életciklusának vége felé használnak. Ez magában foglal mindent, a felhasználók és a szoftver közötti interakció tesztelésétől kezdve a teljes béta hozzáférés biztosításáig, a fekete dobozos tesztelés pedig elsősorban akkor következik be, amikor az összes funkció a vártaknak megfelelően működik.
Ez rengeteg időt és erőfeszítést takarít meg a fehér dobozos teszteléssel szemben, amely magas szintű szakértelmet igényel, és akkor a legjobb, ha nincs szükség a fejlesztőcsapatra, amely azonnal változtatna a rendszer működésén.
Kézi vagy automatizált fekete dobozos tesztek?
A szoftvertesztelésnek két különböző formája van: a manuális tesztelés a hagyományos forma, amely a folyamat minden szakaszában szoftvertesztelőket alkalmaz. Ez határozott ellentmondásban áll az automatizált teszteléssel, amely egyre nagyobb mértékben használ mesterséges intelligenciát és gépi tanulást a feladatok emberi beavatkozás nélküli elvégzésére.
Olvasson tovább, hogy többet megtudjon a manuális és az automatizált tesztelésről, az egyes tesztek kihívásairól, és arról, hogy a kettő közül melyik az ideális egy vállalat számára.
1. Kézi fekete dobozos tesztelés – előnyök, kihívások, folyamatok
A kézi fekete dobozos tesztelés a fekete dobozos tesztelés önálló elvégzésének folyamatát jelenti, amely során a személyzet tagjai végzik el az összes feladatot, ahelyett, hogy a vállalat eszközkészletének részeként automatizálási platformot használnának.
A kézi tesztelés alkalmazásának néhány fő előnye a szoftverfejlesztésben az, hogy nagyobb rugalmasságot biztosít a tesztelés befejezésének módját illetően, és hogy a fejlesztők sokkal alaposabb, minőségi jellegű visszajelzést kaphatnak.
A manuális tesztelési folyamatnak azonban van néhány természetes kihívása. Az első ezek közül az a tény, hogy a kézi tesztelés sok időt vesz igénybe, mivel az emberek lassabban végzik el a feladataikat, mint az automatizált programok.
A másik a nagyobb hibalehetőség, mivel az emberek képesek rosszul kattintani vagy rossz sorrendben elvégezni a dolgokat. Ez végső soron pontatlanságot eredményezhet a vizsgálati adatokban.
A manuális tesztelés egy olyan folyamat, amely a vállalat alkalmazással kapcsolatos elvárásainak megismerésével kezdődik, majd olyan tesztesetek írásával, amelyek megkérdőjelezik ezt a feladatot, a tesztesetek végrehajtásával és az eredmények jelentésével a fejlesztőcsapatnak.
2. Fekete dobozos teszt automatizálás – előnyök, kihívások, folyamatok
Az automatizált tesztek olyan teszteket jelentenek, amelyeket egy vállalat egy szoftvercsomagon végez el egy automatizált rendszerrel végzett tesztesetek kitöltésével. Ezek harmadik féltől származó platformokat használnak a szoftvercsomag automatizálására, és az automatizált lépések a kifejezetten erre a célra készített tesztesetek alapján történnek.
A fekete dobozos teszt automatizálás legfőbb előnye a gyorsaság, mivel az automatizált programok sokkal kevesebb időt vesznek igénybe a teszt minden egyes futtatásához. Ez jelentős időnyereséget jelent a tesztelés során, amelyet az alkalmazás fejlesztésére fordíthat.
Egy másik előnye a pontosság, mivel egy jó automatizálási eszköz mindig ugyanabban a sorrendben végzi el ugyanazokat a feladatokat.
A hátrányok még mindig problémákat okozhatnak a fekete dobozos teszt automatizálásánál, az egyik fő probléma a mennyiségi adatokra való összpontosítás. Ez nagyszerű a mérőszámok szempontjából, de azt jelenti, hogy egy felhasználói elfogadhatósági teszt során kevés értékes információ nyerhető.
Az automatizált tesztelés viszonylag kevéssé rugalmas, mivel az elemzőknek mindig teljesen új teszteseteket kell kódolniuk, ha változtatni akarnak.
A teszt automatizálási folyamat egy sor teszteset megtervezésével kezdődik, amelyeket aztán a rendszerbe kódolnak, mielőtt a teszteket végrehajtanák, amelyek a befejezésről jelentést készítenek.
3. Következtetés: Kézi vagy fekete dobozos teszt automatizálás?
Végső soron a kézi és az automatizált fekete dobozos tesztelés közötti választás bonyolult, és attól függ, hogy mit keres egy rendszerben.
Ha magas szintű minőségi információkat keres, amelyeket felhasználhat a végfelhasználó számára történő tervezési változtatásokhoz, akkor a manuális tesztelés messze a jobb megoldás, az automatizált tesztelés pedig ideális a folyamat funkcionális és teljesítményfázisaiban.
Gondolja át, hogy mit keres a tesztelési folyamat minden egyes szakaszában, és így könnyedén kaphat olyan irányított adatokat, amelyek javítják a teljesítményét.
Mire van szüksége a fekete dobozos tesztelés megkezdéséhez?
Van néhány előfeltétel, amelyekkel rendelkeznie kell a fekete dobozos tesztelés megkezdése előtt, és amelyek mindegyike segít egy koherensebb tesztelési folyamat létrehozásában.
Néhány dolog, amivel rendelkeznie kell, mielőtt elkezdi a fekete dobozos tesztelési munkát:
1. Szoftverkövetelmények
A szoftverkövetelmények a tervezési feladat azon konkrét pontjaira vonatkoznak, amelyek teljesítésére a szoftvert tervezték. Ez számos dolgot jelenthet, kezdve attól, hogy egy bizonyos feladatsort kell elvégezni, egészen addig, hogy a használat során egy bizonyos megjelenés és érzés legyen.
Ezen információk birtokában néhány konkrét célt tűzhet ki maga elé a tesztelés során, a tesztelők pedig olyan tesztelési ütemtervet és tervet állíthatnak össze, amely koherensebb eredményeket eredményez, amelyek tájékoztatják a fejlesztőket a szoftverrel kapcsolatos problémákról.
Egyes vállalatoknál, mivel ez egy fekete dobozos teszt, a fejlesztők korlátozzák a tesztelő hozzáférését a briefhez.
2. Összeállított szoftver
Egy szoftver tesztelése előtt a minőségbiztosítási csapatnak hozzáféréssel kell rendelkeznie a szoftverhez. Ez általában azt jelenti, hogy a fejlesztők a szoftver legfrissebb verzióját biztosítják, és a csapat számára előnyös, hogy a szoftver egy teljesen frissen fordított verziója áll rendelkezésre a tesztek elvégzéséhez.
A legújabb verzió azt jelenti, hogy a tesztek a legújabb javításokat is tartalmazzák, ami azt jelenti, hogy a szoftver teljesítményét pontosan mutatja.
3. Tesztelési célok
A tesztelők általában úgy közelítenek a tesztelési időszakhoz, hogy bizonyos célokat tartanak szem előtt. Ezek a tesztelési célok pontosan meghatározzák, hogy mit tesztelnek az elkövetkező időszakban, legyen az a felhasználói elfogadhatóság, a végponttól végpontig tartó funkcionalitás vagy a penetrációs tesztek elvégzése.
A minőségbiztosítási vezetők általában ezeket a célokat tűzik ki, a tesztelés következő szakasza pedig általában attól függ, hogy a fejlesztőcsapat min dolgozott, és hogy a szoftver mely részeit érintik ezek a fejlesztések.
Fekete doboz tesztelési folyamat
A fekete dobozos tesztelési folyamat viszonylag precíz, és a vállalatok számára előnyös, ha a lehető legszorosabban követik a folyamat lépéseit. A fekete dobozos tesztelési folyamat különböző szakaszai a következők:
1. Teszttervezés
Kezdje a fekete dobozos tesztelési folyamatot egy bonyolult tervezési folyamattal. Ez magában foglalja a teszteléssel kapcsolatos összes egyéni cél megvitatását, a vizsgált szoftver konkrét aspektusait és a tesztelésre szánt erőforrásokat.
Az alaposabb tervezés azt jelenti, hogy mindenki tudja, hogy mit és mikor kell tennie, beleértve a tesztekben alkalmazott módszereket is.
2. Teszteset írása
A teszteset-írás a folyamat következő szakasza. A teszteset a teszt során elvégzendő lépések sorozatára utal, a részletesebb tesztesetek nagyobb fokú konzisztenciát biztosítanak a felhasználó számára.
Az automatizált tesztelési folyamat során ez magában foglalja a teszteset kódolását is, bármilyen automatizálási eszközzel tervezi is használni.
Ellenőrizze kétszer az összes tesztesetét, hogy megbizonyosodjon arról, hogy alaposak és egyértelműek a végrehajtandó lépések.
3. Teszteset végrehajtása
Miután elkészültek a tesztesetek, kezdje el a tesztesetek végrehajtását. Automatizálás esetén ez egy viszonylag egyszerű feladat lehet, amely magában foglalja a program útnak indítását és az eredményekre való várakozást. A kézi tesztelés a tesztelési esetek ismételt elvégzésén alapul, és a több ismétlés következetesebb, jó minőségű adatokhoz vezet.
Végezzen el minden tesztesetet a lehető leggondosabban, mivel minél pontosabb a tesztesetek végrehajtása, annál nagyobb az esélye annak, hogy az adatok hasznosak lesznek a fejlesztőcsapat számára.
4. Végső jelentés
A végső jelentési szakasz a folyamatnak azt a részét jelenti, amikor a tesztelő csapat jelentést tesz a fejlesztőknek.
Kezdje az összegyűjtött információk egyszerű összefoglalásával, majd ezt egészítse ki a tesztelők által gyűjtött összes mérőszámmal. Ez a fejlesztők számára kezdeti útmutatást nyújt a következő frissítések ideális irányáról, mielőtt megmutatná nekik a teljes adatállományt, ami lehetővé teszi számukra, hogy mélyebben megértsék a problémákat.
Legjobb gyakorlatok a fekete dobozos teszteléshez
A legjobb gyakorlatok követése iparágtól függetlenül minden vállalat számára elengedhetetlen. A legjobb gyakorlatok olyan magatartásformák és technikák sorozatát jelentik, amelyeket egy vállalat előnyösen alkalmaz a mindennapi munkája során, növelve a vállalat hatékonyságát és javítva a vállalat által használt szoftverek színvonalát.
Néhány ilyen gyakorlat, amely segít a vállalatnak javítani a fekete dobozos tesztelés minőségét, a következők:
1. A készségfejlesztésre összpontosítani
Ha olyan vállalatot vezet, amely egyszerre több szoftveren dolgozik, fontolja meg, hogy a tesztelési készségek és szakterületek fejlesztésére összpontosít. Minél több időt fordít a szakosodásra és a megfelelő készségek fejlesztésére, annál nagyobb az esélye, hogy a termékeiben meglévő problémákat ki tudja gyökereztetni.
Ez párosul a megfelelő készségekkel rendelkező emberek felvételével, de leginkább olyan vállalatok számára megfelelő, ahol szinte állandó szoftvertesztelés folyik, mivel mindig van haszna e képességek alkalmazásának.
2. Egyensúlyozza a munkaterhelést
Egyes tesztelői csoportok nagyon nagyok lehetnek, több tucat, vagy akár több száz munkatárssal, akik mindannyian rendszeresen végeznek teszteseteket.
A legjobb gyakorlat az, hogy a legtöbbet hozza ki ezekből a munkatársakból, ha időt szán rájuk, és körültekintően osztja ki őket konkrét feladatokra. A kiégés komoly problémákat okoz a szoftverfejlesztő iparban, de ez elkerülhető a jobb munkaterhelés-kezeléssel.
3. Konzisztens folyamatok létrehozása
A vállalatok olyan folyamatokra épülnek, amelyeket a munkatársak napi szinten végeznek el, a tesztelési folyamatok közé tartozik, hogy a vállalat hogyan írja meg a teszteseteket, hogyan végzi el a kutatást, és hogyan kommunikál az osztályok között.
A következetesség ezekben az esetekben kulcsfontosságú, mivel ez azt jelenti, hogy az emberek gyorsabban tanulnak, amikor belépnek a vállalathoz. Ez gyorsabb alkalmazkodást és jobb teljesítményt eredményez sokkal hamarabb, mint egy olyan vállalatnál, ahol nincs következetesség a feladatok között.
Ha teheti, ezeket a folyamatokat úgy alakítsa ki, hogy a személyzetet is bevonja a döntéshozatali folyamatba, mivel így biztosíthatja, hogy a személyzet egyetért a stratégiával.
7 hiba és buktató a fekete dobozos tesztek végrehajtásában
A hibák minden iparágban természetesek, de a hibák ismerete, mielőtt még lehetőséged lenne elkövetni őket, sok időt és energiát takaríthat meg.
A leggyakoribb hibák és buktatók, amelyekbe a fekete dobozos tesztelők beleesnek, a következők:
1. Meghatározott tesztelési kör hiánya
Egyes szervezetek a folyamatok megfelelő megtervezése nélkül kezdik el termékeik tesztelését, ami jelentős hiba.
A tervezés elmulasztásával a vállalatok elveszíthetik a tesztelés terjedelmét. Az egyeztetett hatókör segít a tesztelésnek a megfelelő léptékűvé válni és hatékonyan eredményeket elérni.
Ha nem állapodik meg a tesztelés hatóköréről, mielőtt elkezdené, komoly a kockázata annak, hogy túl széles körben tesztel, és túl sok időt vesz igénybe, hogy kevésbé releváns eredményeket kapjon.
2. Elsietett tesztelési folyamatok
A tesztelés nagyon hosszú ideig tartó folyamatnak tűnhet, különösen a teljes alkalmazás vizsgálatára tervezett, hosszadalmas tesztesetek esetében. Egyesek hajlamosak lehetnek elsietni a teszteket, különösen a korábbi tesztek megismétlésekor. Ez súlyos hiba. A tesztelés siettetése hibákhoz vezethet a teszteset végrehajtásában, ami rontja az adatok értékét, és végső soron azt jelenti, hogy ugyanazokat a teszteket mindenképpen újra el kell végeznie.
3. Automatizálás ellenőrzési folyamat nélkül
A teszt-automatizálás elsősorban arra összpontosít, hogy egy adatérték bevitele a folyamat végén a megfelelő kimenethez vezessen. E tesztek automatizálása úgy működik, hogy az automatizált folyamat kimenete összevethető az eredményekkel.
Egyes tesztelők jelentős hibát követnek el azzal, hogy nem számítják ki maguk az értéket, ami azt jelenti, hogy nincs módjuk ellenőrizni, hogy a kimenet helyes-e, és potenciálisan nem találnak jelentős hibákat az egész rendszerben.
4. A hibrid tesztelés elmulasztása
A hibrid tesztelés az automatizálás és a manuális tesztelés egyensúlyát jelenti, mivel a két módszer úgy működik, hogy tökéletesen fedezi egymás hibáit.
Egyes szervezetek azonban inkább a két módszer egyikére összpontosítanak. Ezzel komoly problémáknak és pontatlanságoknak teszi ki a tesztelését.
Végezze el a hibrid tesztelést, hogy minél kiegyensúlyozottabb legyen a tesztelése, és a lehető legjelentősebben csökkentse a hibák számát.
5. A regressziós tesztelés elmaradása
A regressziós tesztelésnek állandó folyamatnak kell lennie minden hatékony szoftvertesztelési rendszerben, és a tesztelés ezen formája megállapítja, hogy a szoftverfrissítések okoztak-e problémákat a rendszer más részein. A regressziós tesztelés elmulasztása azt jelenti, hogy a folyamat korai szakaszában tesztelt funkciók anélkül is meghibásodhatnak, hogy észrevenné.
A regressziós tesztelés elvégzésével biztosíthatja, hogy jobb minőségű terméket szállít, anélkül, hogy túl sok extra munkát fektetne a minőségbiztosítási folyamatba.
6. Aktívan vadászik a hibákra
Egyesek úgy gondolják, hogy a fekete dobozos tesztelés célja, hogy hibákat találjon egy szoftvercsomagban, és jelentse azokat a fejlesztőcsapatnak, és bár ez az egyik szempont, nem ez az egyetlen cél. A tesztelés azért létezik, hogy általában javítsa egy szoftvercsomag színvonalát.
Ha túlságosan a szoftver hibáira koncentrálsz, akkor a szabványos munkafolyamatokon kívülre kerülsz, a tesztelés hatókörén kívülre kerülsz, és figyelmen kívül hagyod a szoftver néhány fontosabb problémáját, cserébe azért, hogy a kód potenciálisan irreleváns hibáira vadászhass.
7. Az intuíció figyelmen kívül hagyása
A kézi tesztelésben a tesztelőnek azért van szerepe, mert van egy meglévő intuíciója és a kód ismerete, amely a lehetséges problémák felé irányítja, és tájékoztatja őket a vizsgálandó területekről, amikor dolgoznak.
Néhányan azonban úgy döntenek, hogy teljesen figyelmen kívül hagyják ezt az intuíciót, amikor teszteseteken dolgoznak. Azzal, hogy feljegyez mindent, amit tesztelni szeretne, és egy új tesztesetben ellenőrzi, teljes mértékben kihasználhatja technikai ismereteit, miközben az előkészített teszteseteket is befejezi.
A fekete dobozos tesztek kimeneteinek típusai
A fekete dobozos tesztelésből többféle kimeneti eredményt kaphat, amelyek mindegyike egyedi betekintést nyújt a vállalat számára, amely releváns frissítéseket kíván végrehajtani termékein, és javítja az ügyfelek által tapasztalt minőséget.
A fekete dobozos tesztek néhány fő kimenettípusa a következő:
1. Minőségi adatok
A fekete dobozos tesztek első kimeneti formája a minőségi adatok. Ezek az információk elsősorban az alkalmazást írják le, és olyan tesztekből származnak, mint a végponttól végpontig tartó tesztelés és a használhatósági tesztek.
A kvalitatív adatok jellemzően az alkalmazás színvonalát írják le, megvitatják az emberek tapasztalatait az alkalmazással kapcsolatban, és elmagyarázzák azokat a változtatásokat, amelyeket a tesztelő szeretne elvégezni.
Ezen adatok létrehozásakor a tesztelő jellemzően alapos jelentést ír, amely tartalmazza az összes bizonyítékot a pontjaihoz, és a minőségi véleményeket további jellemzőkkel, például képernyőképekkel támasztja alá, hogy mire hivatkoznak.
2. Kvantitatív adatok
Ez a metrikák formájában megjelenő egyértelmű numerikus adatokra utal, amelyeknél a tesztelő személyzet tagjai vagy az alkalmazás bizonyos részeit jegyzik fel, vagy numerikus adatokat kapnak egy automatizálási tesztelési protokolltól.
A mennyiségi információk általában hasznosabbak a fejlesztők számára, hogy különálló javításokat nyújtsanak, jelezve az alkalmazás olyan részeit, mint a teljesítményszint, a felhasznált erőforrások hatékonysága, valamint az alkalmazásban jelen lévő hibák és problémák száma.
A mennyiségi információkat egyszerűbb elemezni és értékelni, mint leíró jellegű megfelelőiket, mivel nincs szükség értelmezésre.
3. Hibaüzenetek
A hibaüzenetek akkor jelennek meg, ha a szoftver működése nem az elvárásoknak megfelelően működik. Ez lehet hardver- vagy szoftverprobléma, jellemzően a hibakód mellett a probléma rövid leírásával.
A fejlesztők hibakódok rendszerét hozzák létre, hogy segítsenek nekik leszűkíteni, hogy pontosan hol jelentkezik egy probléma a rendszerben, és néhány ötletet is megvalósíthatnak, például az első számjegy segítségével leszűkíthetik a problémát okozó funkciót, a másodikkal leírhatják, hogy mi volt a konkrét hiba, a harmadikkal pedig megadhatják a probléma okát.
A hibakódok rendszerének használata azt jelenti, hogy a fejlesztők azonnal tudják, mi a probléma, és dolgozhatnak a megoldáson.
Példák a Black box tesztekre
Míg a fekete dobozos tesztelés elmélete viszonylag egyszerű, a gyakorlati megvalósítása összetett folyamat lehet, különösen egy kezdő tesztelő számára. Egy fekete dobozos tesztelési példa megtekintése a gyakorlatban segíthet a tesztelés megszervezésében.
Néhány példa a fekete dobozos tesztelési módszerekre, beleértve a többféle tesztelést és a siker különböző fokozatait:
1. Hatástalan felhasználói elfogadási tesztelés
Egy vállalat a következő hetekben szeretné kiadni a termékét, de a felhasználói elfogadási tesztelésre még nem került sor. Az alkalmazás egy kötés oktatóprogram az idősebb közönség számára.
A fejlesztők igyekeznek felgyorsítani ezt a folyamatot, és gyorsan összegyűjteni a tesztelők egy csoportját, kizárólag a harmincas éveik közepén járó, nem kötögetőkkel tesztelve, mivel ők egy könnyebben elérhető csoport. Ez a csoport nem lát problémákat az alkalmazással kapcsolatban, és zöld utat ad a nyilvánosságra hozatalhoz.
A két csoport technikai ismereteinek ellentmondásos szintje miatt a célközönség jobban összezavarodik a szoftver használata során, és sok funkcióhoz nem tud hozzáférni. Válaszként a vállalat kénytelen sürgős frissítéseket végezni.
Az ehhez hasonló tesztelési hibák bizonyítják az alapos felkészülés fontosságát.
2. Sikeres végponttól végpontig tartó tesztelés
A végponttól végpontig tartó tesztelés azokra a tesztelésekre vonatkozik, amelyek akkor zajlanak, amikor az alkalmazás funkcionalitását első alkalommal teljesen összeállították egy szoftvercsomagba.
Egy vállalat gondosan megtervezte a végponttól végpontig tartó tesztelési folyamatot, és egy sor, kifejezetten a tesztelési feladatok elvégzésére felvett munkatársat alkalmaz, akik közül minden egyes tesztelési esetre két alkalmazottat különítettek el.
Gondos folyamatot követően elvégzik a tesztelési eseteket, és feljegyzik az összegyűjtött adatokat, a tesztelés végén pedig a minőségbiztosítási vezető egy egységes jelentésben foglalja össze az adatokat.
A fejlesztők ezt a jelentést az alkalmazás következő frissítéseinek és módosításainak megtervezéséhez használják, jelentősen javítva a terméket.
3. Automatizált regressziós tesztelés
Egy fejlesztő befejezett egy sor frissítést a szoftveréhez, amely a frissítéseket megelőzően a várakozásoknak megfelelően működött. A frissítések után a tesztelő csapat egy regressziós tesztelési folyamaton megy keresztül, az automatizálásra összpontosítva, és egy automatizált platformot szerezve az összes alapfunkció elvégzéséhez.
A csapat megírja a kódot egy tesztesethez, és végrehajtja a teszteseteket, átolvassa a tesztek összes eredményét, és megtalálja, hol vannak a lehetséges problémák.
Ez megakadályozza, hogy problémák merüljenek fel amiatt, hogy egy szervezet frissítéseket végez, és nem ellenőrzi, hogy ezek tartalmaznak-e problémát.
A fekete dobozos teszteléssel feltárt hibák és hibák típusai
Bár a hibák és a hibák nem jelentenek mindent a fekete dobozos tesztelési folyamatban, jelentős részét képezik annak, ahogyan a vállalatok a tesztelést végzik.
A fekete dobozos tesztelésben előforduló hibák és hibák néhány fő típusának ismerete segíthet kategorizálni a felmerülő problémákat, és jobban megérteni, hogy miért fordulnak elő.
A fekete dobozos teszteléssel felderíthető hibák és hibák néhány fő típusa a következő:
1. Használhatósági hibák
A használhatósági hibák a program olyan hibáira utalnak, amelyek valójában nem befolyásolják a funkcionalitást, de problémákat okozhatnak a felhasználónak, aki megpróbál kapcsolatba lépni a szoftverrel.
Ha például egy alkalmazásnak súlyos grafikai hibája van, technikailag még működik, de a megfelelő ikonok és szöveg nélkül a végfelhasználó nem tudja hatékonyan használni. Ezek a problémák általában az alkalmazás tervezését és azt a módot övezik, ahogyan a design betöltődik a felhasználó számára, mivel az összetettebb alkalmazások több grafikát igényelnek, amelyek összetettebbek, mint az egyszerűbb felhasználói felületeken.
2. Funkcionális hibák
A funkcionális hibák olyan problémákra utalnak, amelyek akkor jelentkeznek, amikor egy program egy része nem az elvártaknak megfelelően működik.
Például, ha egy adatbázis-szoftvert futtat, és megpróbálja az információkat egy bizonyos kategória szerint rendezni, és azt tapasztalja, hogy ez nem működik. Ez vonatkozik mind azokra a funkciókra, amelyek egyáltalán nem működnek, mind pedig azokra, amelyek látszólag működnek, de nem megfelelően.
Ezek lehetnek a legjelentősebb problémák egy alkalmazás esetében, jelentős kényelmetlenséget okozva a felhasználóknak és rontva a fejlesztő hírnevét, mivel a termék nem úgy működik, ahogyan azt hirdetik.
3. Összeomlik
Amikor egy szoftver összeomlik, akkor a szoftverrel alapvető probléma van, ami megakadályozza a futását. Az összeomlásoknak többféle formája is előfordulhat, például amikor egy alkalmazás teljes egészében bezárul, vagy egyszerűen csak lefagy a folyamat egy pontján.
Az összeomlás az egyik legsúlyosabb probléma, amely előfordulhat, mivel az alkalmazás teljes bezárásán és újbóli megnyitásán kívül nincs mód az alkalmazás működésének visszaállítására. Míg egyes alkalmazásoknál a háttérben még mindig zajlanak folyamatok, addig ezen a ponton túl már nincs mód a szoftverrel való interakcióra.
Közös fekete doboz tesztelési metrikák
A kézi fekete dobozos tesztelés kiválóan alkalmas minőségi adatok generálására, de ha a mennyiségi adatokra összpontosít, tisztában kell lennie az ellenőrzött metrikákkal. Ezeknek a mérőszámoknak a teljes körű megértése segít megérteni a platform hibáit, és prioritásként kezelni a különböző területeket, amelyeken dolgozni kell.
A munkája során gyakran előforduló fekete dobozos tesztelési mérőszámok közé tartoznak a következők:
1. Hibaarány
A hibaarány több dologra is utalhat, vagy a szoftver tesztelési ciklusa során előforduló hibák tiszta számára, vagy a tesztelési óránként előforduló hibákra. Az óránkénti mérőszámok jobbak, mivel inkább a szoftverben lévő hibák sűrűségét mutatják be, mintsem egyszerűen csak egy számot közölnének, ami a nagyobb alkalmazások esetében potenciálisan félreérthető.
A fejlesztők igyekeznek korlátozni a hibaarányt alkalmazásaikban, mivel minél kevesebb hiba van a szoftvercsomagban, annál jobb lesz az ügyfél számára a rendszer használatának élménye.
2. Válaszidő
Amikor egy tesztelő többet szeretne megtudni a felhasználó által tapasztalt teljesítményszintről, a válaszidő az egyik fő szempont, amit figyelembe kell vennie. Ez arra az időre utal, amely alatt a szoftver elvégzi a feladatot, miután a felhasználó beír egy kérést, a hosszabb válaszidők pedig egy viszonylag nem hatékony alkalmazást mutatnak. A magasabb válaszidők aggodalomra adnak okot, mivel a felhasználók elveszíthetik a türelmüket egy túl sokáig tartó alkalmazással szemben.
3. Felhasználói elégedettség
A legtöbb mérőszám a tiszta számokra összpontosít, amelyeket a szoftvercsomag és a tesztelő szoftver generál egy teszt során, de néhány mérőszám a véleményre összpontosít.
Ha egy vállalat például 1000 tesztelőt használó béta tesztet végez, adatokat gyűjthet az elégedettek számáról, és ezt százalékos értékké alakíthatja. Ez egy rendkívül hasznos mérőszám, amely a ciklus végén rendelkezésre áll, mivel a felhasználói elégedettség magasabb aránya azt mutatja, hogy a program több embernek tetszik, és azt jelzi, hogy a jövőben nagyobb valószínűséggel fog jól működni.
A legjobb Black Box tesztelési eszközök
A fekete dobozos tesztelés a tesztelés olyan formája, amely jelentősen támaszkodhat a kéznél lévő eszközökre, mind a fekete dobozos tesztelés automatizálására, mind a tesztekből származó információk rendszerezésére.
Az eszközök megfelelő kombinációjának használatával Ön és csapata sokkal hatékonyabban dolgozhat, és hatékonyabb folyamatokat építhet ki a minőségbiztosítási osztályon belül.
Tekintse meg az alábbiakban néhányat a legjobb fekete dobozos tesztelési eszközök közül, és tudja meg, hogy pontosan hogyan segíthetnek Önnek a gyarapodásban:
5 legjobb ingyenes fekete dobozos tesztelési eszköz
A kis és feltörekvő vállalatok, például a független fejlesztők nem rendelkeznek nagy költségvetéssel, amellyel a szoftverük létrehozásakor dolgozniuk kell. Ez számos kihívással járhat, beleértve a megfelelő eszközök megtalálását is.
Az alábbiakban bemutatunk néhányat a legjobb ingyenes eszközök közül, amelyek a független fejlesztők számára elérhetőek, és amelyekkel a munkafolyamatokat javíthatják a költségvetésükből:
1. ZAPTEST INGYENES KIADÁS
A ZAPTEST ingyenes kiadása tökéletes bevezetés a szoftverteszt automatizálásába. Ezt az eszközt kifejezetten úgy tervezték, hogy támogassa a bármilyen feladat automatizálását, így segít gyorsabban és hatékonyabban dolgozni, függetlenül attól, hogy milyen feladatot végez el.
A ZAPTEST ingyenes verziója rengeteg funkcionalitást tartalmaz, hogy támogassa bármilyen alkalmazás automatizálását… 1SCRIPT végrehajtás böngésző, eszköz, alkalmazás és párhuzamos végrehajtás az elérhető funkciók egyike.
2. JIRA
A JIRA ingyenes kiadásai ideális eszközök a hibák feljegyzésére, a jegyzetekben való részletezésükhöz és a fejlesztőcsapattal való kommunikáció során a prioritások meghatározásához.
Ez azonban nem egy mindenre kiterjedő automatizálási segédeszköz, hanem kizárólag a tesztelési folyamat projektmenedzsment oldalára specializálódott.
3. Szelénium IDE
Ez egy nyílt forráskódú alkalmazás, amely rögzíti és lejátssza a teszt-automatizálást, és jó eszköz arra, hogy megnézzük, mit lát egy automatizálási platform a teszt befejezésekor.
A Selenium egyik hibája a fejlett funkciók, például az automatizált feladatok platformok közötti integrációjának viszonylagos hiánya.
4. AutoHotkey
Az AutoHotkey egy teljesen ingyenes és nyílt forráskódú szkriptnyelv, amely a Windowshoz érhető el, és amelynek segítségével a felhasználók különböző méretű szkripteket hozhatnak létre, amelyek egyetlen billentyűleütés beírása után egy sor feladatot végeznek el.
Míg az AutoHotkey jó az egyszerű feladatok automatizálására, a nagyobb szkriptek és automatizálási követelmények esetén már nehézségekbe ütközhet.
5. Appium
Ez az eszköz elsősorban az iOS-alkalmazások automatizálásában jeleskedik, így ideális program, ha a mobilalkalmazások minőségének javítására törekszik.
Az Appium legnagyobb hátránya, hogy a termékek nagyon szűk körére korlátozódik, ami jelentősen csökkenti az elérhető piacot.
Az 5 legjobb vállalati Black Box tesztelési eszköz
Az ingyenes eszközök mind szépek és jók, de a vállalatoknak és a nagyvállalatoknak több funkcióra van szükségük ahhoz, hogy alaposan tesztelni tudják a szoftvereiket. Szerencsére a legjobb vállalati fekete dobozos tesztelési eszközök közül néhány átfogó funkcionalitással rendelkezik, és segít a vállalkozásoknak abban, hogy a minőségbiztosítási folyamatokba történő befektetésük jelentősen megtérüljön.
Néhány ideális vállalati fekete dobozos tesztelési eszköz, amelybe érdemes befektetni:
1. ZAPTEST ENTERPRISE EDITION
A ZAPTEST Enterprise kiadása az egyik legjelentősebb automatizálási eszköz a piacon, és akár 10-szeres megtérülést is biztosíthat a termékének.
Az olyan funkciók, mint a teljes munkaidős ZAP szakértőhöz való hozzáférés a csapat távoli részeként, valamint a korlátlan licencek biztosítják, hogy a fekete dobozos teszt automatizálást meredek tanulási folyamat nélkül, fix költséggel valósíthatja meg, függetlenül attól, hogy milyen gyorsan növekszik.
2. TestRail
A TestRail egy olyan platform, amely a valós idejű tesztelésre összpontosít, és célja, hogy összekapcsolja a teszteket egy egységes projektmenedzsment platformmal. Míg ez ideális a csapatirányítási munka központosításához, az automatizálási funkciók messze nem tökéletesek egy olyan fejlesztőcsapat számára, amely nagy hangsúlyt fektet az automatizált tesztekre.
3. Opkey
Az Opkey egy olyan platform, amely a kód nélküli automatizálásra összpontosít, ami azt jelenti, hogy a meglévő műszaki ismeretekkel nem rendelkező emberek is elkezdhetik automatizálni tesztelési szolgáltatásaikat.
Az Opkey egyik fő hibája a szoftvert körülvevő aktív közösség hiánya, ami miatt viszonylag tanácstalanul érezheti magát, ha olyan módon próbál automatizálni, ami új az Ön számára.
4. Perfecto
A Perfecto egy olyan eszköz, amely arra összpontosít, hogy segítse a felhasználókat a mobilalkalmazások automatizálásában komolyabb problémák nélkül, az eszközök széles skáláján dolgozva és a végponttól végpontig tartó tesztelési munkára összpontosítva.
Az alkalmazás azonban nem virtuális gépeken, hanem valódi eszközökön fut, ami egy újabb nagy költséggel növeli az amúgy is viszonylag drága tesztelési eszközt, korlátozott platformok esetén.
5. JIRA Enterprise
A tesztelés automatizálási oldalának befejezése mellett a projektmenedzsment továbbra is fontos, és itt jön a képbe a JIRA. Az Enterprise JIRA több tárhelyet kínál, és több felhasználó számára teszi lehetővé a platform elérését, de potenciális zavart okozhat az egyes felhasználók egyedi jogosultságainak és hozzáférésének szükségessége miatt. Ez sok adminisztratív időt vesz igénybe.
Mikor kell használni
Enterprise vs. Freemium Black Box eszközök?
Kezdetben a vállalatok többsége freemium black box eszközöket fog használni. Ennek gazdasági szempontból van értelme, mivel egyetlen intelligens vállalkozás sem akar olyan termékbe befektetni, amelyet nem ismer teljesen, legyen szó akár a projektmenedzsmentről, akár az automatizálásról.
A freemium eszközök nem csak a teljesen ingyenes alkalmazásokat foglalják magukban, hanem a vállalati termékek ingyenes verzióit is, amelyeket a vállalat akkor használ, amikor megtanulja, hogyan kell az eszközt a folyamataiba illeszteni.
Az ideális időpont egy szervezet számára, hogy a választott eszközt egy vállalati kiadásra frissítse, amikor a vállalat az ingyenes eszköz miatt súrlódásokat tapasztal a tesztelési folyamatokban. Legyen szó akár egy ingyenes eszközről, amely csak bizonyos számú licencet kínál, akár egy bizonyos mennyiségű tesztelésről, abban a pillanatban, amikor a tesztelési eszközeinek köszönhetően elkezdi tapasztalni a folyamatok hatékonyságának csökkenését, át kell térnie egy olyan vállalati verzióra, amely minden igényének megfelel.
Fekete doboz tesztelés ellenőrzőlista, tippek és trükkök
Mivel a fekete dobozos tesztelés egy rendkívül összetett tesztelési módszer, amely rengeteg lehetőséget kínál a szoftvercsomaggal kapcsolatos ismeretek bővítésére, van néhány dolog, amire figyelnie kell.
Néhány fontos tipp és trükk, amelyet érdemes felvenni a fekete dobozos tesztelés ellenőrzőlistájára:
– A megbízás megértése
Mielőtt elkezdené a teszteléssel kapcsolatos terveket készíteni, győződjön meg arról, hogy megértette a tesztelési időszak tágabb értelemben vett feladatát. Ez magában foglalja a szoftver megértését, amennyire csak lehetséges, és azt, hogy pontosan megtanulja, mit kell tesztelnie.
– Teszteset lektorálása
Próbáljon meg mindenkit bevonni a tesztelésbe, hogy értékelje a fekete dobozos tesztelés során használt teszteseteket. Minél több szem látja a teszteseteket a végrehajtás előtt, annál nagyobb az esélye a hibák kiküszöbölésének.
– Állítson össze egy listát a tennivalókról
A fekete dobozos tesztelésre való felkészülés nem technikai oldala ugyanolyan fontos lehet, mint a technikai oldal. A tervezés során hozzon létre egy összefüggő listát a tennivalókról, amely elrendezi, hogy ki a szoftver mely részét melyik konkrét időpontban teszteli. Ez csökkenti a zűrzavart, a lehetséges kiégést és a más feladatok átvétele miatti késedelmeket.
– Az eredmények azonnali rögzítése
A teszt által generált bármelyik eredményt azonnal rögzítheti. Ha túl sokáig várunk a kézi tesztekkel, akkor a problémákra rosszul emlékezhetünk, így az azonnali jegyzetek készítése jelentősen növeli a pontosságot.
– Kapcsolattartás a fejlesztőkkel
Beszélje meg a tesztelési időkeretet és stratégiát a fejlesztőkkel, hogy megértsék, mi történik, és mikor számíthatnak az új frissítéseken való munkára. Ez magában foglalja az egyértelmű folyamatok meghatározását, amelyek révén a részlegek kommunikálnak egymással.
– Cselekvőképes adatok
A jelentés megírásakor ügyeljen arra, hogy a fejlesztő számára megadott összes adat használható legyen. Ez segíti a csapatot abban, hogy olyan terméket fejlesszen ki, amely reagál a problémáira, és nem pedig azt, hogy a fejlesztő ne értse meg, milyen változtatásokat kell végrehajtania.
– Értse meg a prioritásait
Tesztelő csapatként az Ön prioritása végső soron annak biztosítása, hogy a vállalat kiváló minőségű terméket szállítson a felhasználóknak. Ha a tesztelés a vártnál egy kicsit tovább tart, ne feledje, hogy ez a minőség javulásáért cserébe, amit az ügyfél tapasztal, megérte.
– Ismerje a hierarchiát
Egy ideális fejlesztőcégben a fejlesztők és a tesztelők a hierarchia ugyanazon szintjén helyezkednek el, és ugyanolyan fontos beleszólásuk van abba, hogy a szoftver hogyan fejlődik. Ismerje meg a szervezeten belüli hierarchiát, és törekedjen arra, hogy mindenki megértse a jó tesztelés értékét.
– Egységes dokumentáció vezetése
Őrizze meg a tesztelés során keletkezett összes adat és jelentés másolatát. Nyomon követheti az alkalmazás módosításait, amelyekért a tesztelő csapat felelős, emellett visszanézheti a régi hibákat, hogy megnézze, megismétlődnek-e a jövőbeli kiadásokban.
Következtetés
A fekete dobozos tesztelés végső soron a szoftvertesztelési folyamat egyik legfontosabb része. Segít a vállalatoknak abban, hogy megbizonyosodjanak arról, hogy az általuk szállított termékek a lehető legmagasabb színvonalat képviselik, és a perspektívaváltást kihasználva egyedülálló betekintést nyújt abba, hogy egy külső felhasználó hogyan érzékeli és valósítja meg az alkalmazást.
Bármely vállalat, amely nem illeszti be folyamataiba az automatizált és a kézi fekete dobozos tesztelést, kihagy egy olyan lehetőséget, amellyel jelentősen javíthatja az alkalmazás minőségét. Teszteljen intelligensen, és learathatja a gyümölcsét, amikor ügyfelei hozzáférnek a termékéhez.
GYIK és források
Függetlenül attól, hogy mennyit tud a fekete dobozos tesztelésről, lehet, hogy további kérdései vannak, és szeretné még jobban megérteni a módszert. Az alábbi gyakran ismételt kérdésekben többet megtudhat a fekete dobozos tesztelésről, és hozzáférhet számos olyan forráshoz, amely többet tudhat meg a módszertanról.
1. A legjobb tanfolyamok a fekete dobozos teszt automatizálásról
Számos tanfolyam létezik a fekete dobozos teszt automatizálásáról, amelyeket követhet, és amelyek mindegyike más-más tesztelési színvonal elérésében segít.
Néhány a legelismertebb fekete dobozos tesztelési tanfolyamok közül:
– “Black-box és White-box tesztelés” by Coursera
– “A Black-Box szoftvertesztelési sorozat” a BBST által
– “Bevezetés a fekete dobozos szoftvertesztelési technikákba” by Udemy
– “Szoftverautomatizálási tesztelés” a London School of Emerging Technology által
– “Három kulcsfontosságú fekete dobozos tesztelési technika” by Udemy
2. Melyik a legjobb 5 interjúkérdés a fekete dobozos teszteléssel kapcsolatban?
A szoftvertesztelés egy rendkívül versenyképes terület, ahol minden egyes álláshelyre rengeteg jelentkező jelentkezik. Ha egy fekete dobozos teszteléssel kapcsolatos állásinterjúra jelentkezik, érdemes felkészülnie néhány olyan kérdésre, amelyekre az interjún fel kell készülnie:
– Milyen tapasztalata van a fekete dobozos tesztelésben?
– Mik a fő különbségek a fekete dobozos és a fehér dobozos tesztelés között?
– Korábbi munkakörökben szerzett már tapasztalatot szoftverautomatizálással kapcsolatban?
– Elmondanád nekünk, hogy mikor tapasztaltál kihívásokat a munkahelyeden, és hogyan győzted le őket?
– Mit gondolsz, mi lesz a fekete dobozos tesztelés jövője, és hogyan illenek a képességeid egy hosszú távú karrierhez a szoftvertesztelés területén?
3. A legjobb Youtube oktatóanyagok a fekete dobozos tesztelésről
A YouTube az egyik legfontosabb tanulási forrás a szoftvertesztelési készségeiket fejlesztő emberek számára, mivel ingyenes információforrást biztosít, amelyet felhasználhatsz a technikád fejlesztéséhez.
Néhány a legjobb oktatóanyagok közül, amelyeket érdemes megnézni, amikor a fekete dobozos tesztelést tanulja:
– “Black and White Box Testing Introduction – Georgia Tech – Szoftverfejlesztési folyamat” by Udacity
– “Black Box and Glass Box Testing” by MIT OpenCourseWare
– “7 fekete dobozos tesztelési technika, amit minden minőségbiztosítónak ismernie kell” – The Testing Academy
– “Fekete dobozos tesztelés | Mi a fekete dobozos tesztelés | Ismerje meg a fekete dobozos tesztelést” – Intellipaat
– “Mi az a fehér vs. szürke vs. fekete dobozos tesztelés?” ITProTV
4. Hogyan kell fenntartani a Black Box teszteket?
A fekete dobozos tesztek karbantartása – függetlenül attól, hogy kézi vagy automatizált tesztekről van szó – a tesztek folyamatos figyelemmel kíséréséből áll, és folyamatosan javításokat kell alkalmazni, ha problémák merülnek fel.
Ez magában foglalja annak biztosítását, hogy a tesztesetek minden egyes alkalommal az elvárásoknak megfelelően fussanak, és annak ellenőrzését, hogy az automatizált eszközök végigmennek-e az összes helyes lépésen. Tegye ezt a lehető leggyakrabban, hogy megelőzze a szabványok megcsúszását, mivel egy jól karbantartott fekete dobozos teszt a lehető legpontosabb eredményeket adja vissza.
5. A legjobb könyvek a fekete dobozos tesztelésről
Bár a fekete dobozos tesztelés és a szoftvertesztelés egésze folyamatosan fejlődő terület, számos olyan könyv van, amely továbbra is releváns, és sok betekintést nyújt a tesztelési munka javításához.
A fekete dobozos tesztelésről szóló legjobb könyvek közé tartozik:
– “Fekete doboz tesztelés: Boris Beizer: Techniques for Functional Testing of Software and Systems” (A szoftverek és rendszerek funkcionális tesztelésének technikái).
– “Szoftvertesztelés: Srinivasan Desikan, Gopalaswamy Ramesh: Principles and Practice (Alapelvek és gyakorlat)
– “Essentials of Software Testing” (A szoftvertesztelés alapjai) írta Ralf Bierig, Stephen Brown, Edgar Galván
– “Bevezetés a szoftvertesztelésbe” írta Paul Ammann, Jeff Offutt
