A kézi tesztelés olyan szoftvertesztelési folyamat, amelyben a teszteseteket manuálisan hajtják végre automatizált eszköz használata nélkül. A tesztelő által manuálisan végrehajtott összes teszteset a végfelhasználó nézőpontja szerint. Biztosítja, hogy az alkalmazás működik-e, ahogyan a követelménydokumentumban szerepel, vagy sem. A teszteseteket úgy tervezik és hajtják végre, hogy a szoftveralkalmazás csaknem 100 százalékát teljesítsék. A teszteset-jelentések manuálisan is generálódnak.

A kézi tesztelés az egyik legalapvetőbb tesztelési folyamat, mivel a szoftver látható és rejtett hibáit egyaránt megtalálja. Az elvárt kimenet és a kimenet között a szoftver által megadott különbség hibaként van definiálva. A fejlesztő kijavította a hibákat, és átadta a tesztelőnek újbóli tesztelésre.

A kézi tesztelés minden újonnan kifejlesztett szoftver esetében kötelező az automatizált tesztelés előtt. Ez a tesztelés nagy erőfeszítéseket és időt igényel, de garantálja a hibamentes szoftvert. A kézi teszteléshez szükség van a kézi tesztelési technikák ismeretére, de semmiféle automatizált tesztelőeszközre nem.

A kézi tesztelés elengedhetetlen, mert az egyik szoftver tesztelés Az alapelv az, hogy „100%-os automatizálás nem lehetséges”.

Miért van szükség kézi tesztelésre?

Amikor egy alkalmazás megjelenik a piacon, és instabil, vagy hibát vagy problémákat okoz, vagy problémákat okoz, miközben a végfelhasználók használják.

Ha nem akarunk ilyen jellegű problémákkal szembesülni, akkor egy tesztelési kört kell végrehajtanunk, hogy az alkalmazás hibamentessé és stabillá tegyük, és minőségi terméket szállítsunk a kliensnek, mert ha az alkalmazás hibamentes, akkor a végfelhasználó kényelmesebben fogja használni az alkalmazást.

Ha a tesztelő mérnök kézi tesztelést végez, akkor végfelhasználói szemszögből tesztelheti az alkalmazást, és jobban megismerheti a terméket, ami segít megírni az alkalmazás megfelelő teszteseteit, és gyors visszajelzést adni az alkalmazásról.

A kézi tesztelés típusai

A kézi teszteléshez különféle módszereket használnak. Mindegyik technikát a tesztelési kritériumai szerint alkalmazzák. A kézi tesztelés típusai az alábbiak:

• Fehér doboz tesztelése
• Fekete doboz tesztelése
• Szürke doboz tesztelése

Fehér doboz tesztelése

A fehér doboz tesztelését a Fejlesztő végzi, ahol a kód minden sorát ellenőrzik, mielőtt átadják a tesztmérnöknek. Mivel a kód a Fejlesztő számára a tesztelés során látható, ezért White box tesztelésnek is nevezik.

A fehér doboz tesztelésével kapcsolatos további információkért tekintse meg az alábbi linket:

https://www.javatpoint.com/white-box-testing

Fekete doboz tesztelése

A feketedobozos tesztelést a Tesztmérnök végzi, ahol a vevő/kliens igényei szerint ellenőrizheti egy alkalmazás vagy szoftver működőképességét. Ebben a kód nem látható a tesztelés során; ezért nevezik fekete doboz tesztelésnek.

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

Gray Box tesztelés

A szürke doboz tesztelése a fehér doboz és a fekete doboz tesztelésének kombinációja. Olyan személy végezheti, aki ismerte a kódolást és a tesztelést is. Ha pedig az egyetlen személy fehérdobozos, valamint feketedobozos tesztelést végez az alkalmazáshoz, azt szürkedobozos tesztelésnek nevezzük.

A szürke doboz tesztelésével kapcsolatos további részletekért tekintse meg az alábbi linket:

https://www.javatpoint.com/grey-box-testing

A kézi tesztelés végrehajtása

• Először a tesztelő minden szoftverrel kapcsolatos dokumentumot megfigyel a tesztelési területek kiválasztásához.
• A tesztelő elemzi a követelménydokumentumokat, hogy lefedje az ügyfél által meghatározott összes követelményt.
• A Tester a teszteseteket a követelménydokumentum szerint fejleszti.
• Minden teszteset manuálisan hajtódik végre a fekete doboz és a fehér doboz tesztelésével.
• Ha hibák történtek, a tesztelő csapat értesíti a fejlesztőcsapatot.
• A fejlesztőcsapat kijavítja a hibákat és átadja a szoftvert a tesztelőcsapatnak, hogy újrateszteljék.

Szoftverkészítési folyamat

• A követelmény összegyűjtése után a két különböző csapatfejlesztő és tesztelő csapat rendelkezésére fog állni.
• Miután megkapta a követelményt, az érintett fejlesztő elkezdi írni a kódot.
• Addig pedig a tesztmérnök megérti a követelményt és elkészíti a szükséges dokumentumokat, eddig a fejlesztő kitöltheti a kódot és tárolhatja a Verzióvezérlő eszköz .
• Ezt követően a kód megváltozik a felhasználói felületen, és ezeket a változtatásokat egy külön csapat kezeli, amely az úgynevezett csapatot építeni .
• Ez az összeállítási csapat veszi a kódot, és egy összeállítási eszköz segítségével elkezdi a kód fordítását és tömörítését. Miután megkaptuk a kimenetet, a kimenet a zip-fájlba kerül, amely az úgynevezett Épít (alkalmazás vagy szoftver). Minden buildnek lesz valami egyedi száma, például (B001, B002).
• Ezután az adott Build telepítésre kerül a tesztkiszolgálón. Ezt követően a tesztmérnök hozzáfér ehhez a tesztkiszolgálóhoz a teszt URL segítségével, és megkezdi az alkalmazás tesztelését.
• Ha a tesztelő mérnök hibát talál, jelenteni kell az érintett fejlesztőnek.
• Ezután a fejlesztő reprodukálja a hibát a tesztszerveren, kijavítja a hibát, majd ismét eltárolja a kódot a Verzióvezérlés eszközben, majd telepíti az új frissített fájlt és eltávolítja a régi fájlt; ezt a folyamatot addig folytatjuk, amíg meg nem kapjuk a stabil Build-et.
• Amint megvan az istálló Build, átadjuk a megrendelőnek.

Megjegyzés1

• Miután összegyűjtöttük a fájlt a Control version eszközből, a build eszközzel fordítjuk a kódot magas szintű nyelvről gépi szintű nyelvre. A fordítás után, ha a fájl mérete megnő, akkor az adott fájlt tömörítjük, és a tesztszerverre ürítjük.
• Ezt a folyamatot a Építs csapatot , fejlesztő (ha a build team nincs ott, egy fejlesztő megteheti) vagy a tesztvezeték (ha az összeállítási csapat közvetlenül kezeli a zip-et és telepíti az alkalmazást a tesztkiszolgálóra, és értesíti a tesztmérnököt).
• Általában nem tudunk minden hibához új Build-et szerezni; különben az idő nagy részét csak a buildek létrehozására pazaroljuk.

Jegyzet 2

Építs csapatot

többsoros megjegyzés powershell

A build csapat fő feladata az alkalmazás vagy a Build létrehozása és a magas szintű nyelv alacsony szintű nyelvre átalakítása.

Épít

Ez egy szoftver, amelyet a kód alkalmazás formátumba konvertálására használnak. És néhány funkcióból és hibajavításokból áll, amelyeket átadnak a tesztmérnöknek tesztelési célból, amíg stabillá nem válik.

Verzióvezérlő eszköz

Ez egy szoftver vagy alkalmazás, amelyet a következő célokra használnak:

• Ebben az eszközben különféle típusú fájlokat menthetünk el.
• Mindig biztonságos, mert az eszközökből ugyanazokkal a bejelentkezési adatokkal érjük el a fájlt.
• Az eszközök elsődleges célja a meglévő fájlok módosításainak nyomon követése.

Példa az építési folyamatra

Nézzünk meg egy példát, hogy megértsük, hogyan építhetjük fel a folyamatot a valós forgatókönyvekre:

Amint a tesztmérnök megkapja a hibát, elküldik a fejlesztőknek, akiknek időre van szükségük az elemzéshez; ezt követően már csak a hibát javítja (a tesztmérnök nem tudja megadni a hibagyűjteményt).

A fejlesztő dönti el, hogy idejük szerint hány hibát tud kijavítani. A tesztmérnök pedig eldől, hogy melyik hibát kell először kijavítani az igényeinek megfelelően, mert a tesztmérnökök nem engedhetik meg maguknak a tesztelés leállítását.

És a tesztmérnök, aki megkapja a levelet, csak azt tudhatják, hogy melyik hibát javítja ki a a hibajavítások listája .

Az idő meg fog nőni, mert az első Buildnél a fejlesztőknek be kell írniuk a kódot a különböző funkciókba. És végül csak a hibajavításokat tudja elvégezni, és a napok száma csökken.

Megjegyzés3

Tesztciklus

A tesztciklus az az időtartam, amelyet a tesztelő mérnök minden összeállítás tesztelésére ad.

Különbségek a két felépítés között

Az egy buildben található hibák bármelyik jövőbeli Build-ben kijavíthatók, ami a tesztmérnök követelményeitől függ. Minden új Build a régi módosított változata, és ezek a módosítások lehetnek a hibajavítások vagy néhány új funkció hozzáadása.

Milyen gyakran kaptuk meg az új Build-ot

Kezdetben hetente kaptunk buildeket, de a tesztelés legújabb szakaszában, amikor az alkalmazás stabilizálódott, 3 naponként, két naponként vagy akár naponta is megkaptuk az új Build-et.

Hány építményt kapunk

Ha egy évet veszünk a projekt időtartamából, akkor 22-26 építkezést kaptunk.

Amikor megkapjuk a hibajavításokat

Általánosságban elmondható, hogy a hibajavításokat csak a tesztciklus befejezése után értjük meg, vagy a hibák gyűjteményét az egyik buildben kijavították, és az átadást a következő buildekben.

A kézi tesztelés előnyei

• Nem igényel programozási ismereteket a Black box módszer használatakor.
• A dinamikusan változó grafikus felületek tesztelésére szolgál.
• A Tester valódi felhasználóként kommunikál a szoftverrel, így képes felfedezni a használhatósági és felhasználói felületi problémákat.
• Ez biztosítja, hogy a szoftver száz százalékig hibamentes legyen.
• Költséghatékony.
• Könnyen megtanulható az új tesztelők számára.

A kézi tesztelés hátrányai

• Nagyszámú emberi erőforrást igényel.
• Ez nagyon időigényes.
• A tesztelő készségei és tapasztalatai alapján teszteseteket fejleszt ki. Nincs bizonyíték arra, hogy minden funkciót lefedtek volna, vagy sem.
• A tesztesetek nem használhatók újra. Minden új szoftverhez külön teszteseteket kell kidolgozni.
• Nem biztosít tesztelést a tesztelés minden aspektusára vonatkozóan.
• Mivel két csapat dolgozik együtt, néha nehéz megérteni egymás indítékait, ez félrevezetheti a folyamatot.

Kézi tesztelő eszközök

A kézi tesztelés során különböző típusú tesztelések, mint például egység, integráció, biztonság, teljesítmény és hibakövetés, különféle eszközök állnak rendelkezésre, mint például Jira , Bugzilla , Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube stb. piac. Az eszközök egy része nyílt forráskódú, mások pedig kereskedelmi jellegűek.

karaktert karakterláncra alakítani

A tesztelőeszközökkel kapcsolatos további információkért tekintse meg az alábbi linket:

https://www.javatpoint.com/software-testing-tools

Értsük meg őket egyenként:

LoadRunner

Ez a leggyakrabban használt teljesítménytesztelő eszközök. A LoadRunner főként az eljárások, számos megközelítés és alkalmazási környezet teljesítménytesztjének támogatására szolgál.

A LoadRunner eszköz végrehajtásának fő célja a teljesítményproblémák leggyakoribb forrásainak gyors osztályozása.

A LoadRunner jellemzői

• A LoadRunner eszköz n számú alkalmazást tartalmaz, ami csökkenti a jelentések megértéséhez és leírásához szükséges időt.
• A LoadRunner eszköz használatával alapos teljesítményteszt-jelentéseket kaphatunk.
• Csökkenti az elosztott terhelési tesztelés költségeit, és működési eszközt is kínál a telepítés nyomon követéséhez.

Citrusfélék

A Citrus egy integrációs tesztelőeszköz, amely a leggyakrabban használt tesztkeret. Be van írva Java programozás nyelv. Leginkább szerveroldali és kliensoldali kérésre és válaszadásra, valamint az XML JSON-fájlok érvényesítésére használják.

A végpontok közötti használati esetek teszteléséhez a citrus számos HTTP, JMS és SOAP protokollt támogat.

A citrusfélék jellemzői

Íme a Citrus eszköz néhány fontos funkciója:

• Üzenetek küldésére és fogadására szolgál.
• A Citrus nyílt forráskódú és licencelt formában is elérhető a piacon.
• Olcsó megoldást kínál.
• Az adatbázist a citrusos eszközzel tudjuk hitelesíteni.
• Leírja az üzenetek sorrendjét, felajánlja a teszttervet, és dokumentálja a teszt lefedettségét.
• Létrehozza az üzenetet és ellenőrzi a válaszokat.

TÁMAD

A ZAP egy nyílt forráskódú webalkalmazás-biztonsági szkenner. Ezt jelenti Zed Attack Proxy . Csakúgy, mint néhány más eszköz, ez is le van írva a JAVA programozási nyelv . Ez a leghatékonyabb Nyissa meg a webalkalmazásbiztonsági projekteket [OWASP].

A ZAP jellemzői

• Számos operációs rendszert támogat, például Windows, Linux, OS X.
• Beépülő modul alapú architektúrája van.
• Tartalmaz egy online piacteret, amely lehetővé teszi számunkra, hogy új vagy frissített funkciókat adjunk hozzá.
• A ZAP GUI vezérlőpultja könnyen használható.

Apáca

Az NUnit az egyik leggyakrabban használt egységtesztelő eszköz. Ez egy nyílt forráskódú eszköz, és elsősorban a JUnit .

Teljesen meg volt írva a C# programozási nyelv és mindenki számára alkalmas .Net nyelvek .

Más szavakkal, azt mondhatjuk, hogy az NUnit eszközt teljesen újratervezték, hogy számos .Net nyelvi tulajdonság előnyére váljon. Például:

Reflexióval kapcsolatos képességek. Egyéb egyéni attribútumok.

Az NUnit jellemzői

• Lehetővé teszi az állításokat az előnyosztály statikus metódusaként.
• Fenntartja az adatvezérelt teszteket.
• Számos platformot támogat, például a .NET mag Xamarin mobilt, a Silverlightot és a hatékony keretrendszert.
• Az NUnit képessége segít a tesztek egyidejű végrehajtásában.
• A tesztek betöltéséhez és végrehajtásához konzolfutót használ.

JIRA

A leggyakrabban használt hibakövető eszköz az JIRA , amely egy nyílt forráskódú eszköz. Hibakövetésre, projektmenedzsmentre és problémakövetésre használják.

Ebben az eszközben könnyedén nyomon követhetjük a szoftverrel kapcsolatos és a tesztmérnökök által előállított mindenféle hibát vagy hibát.

A JIRA jellemzői

• Ez egy időtakarékos eszköz.
• A Jira a hibák és problémák nyomon követésére szolgál.
• A dokumentációs feladatok megállapítására szolgál.
• A Jira egy nagyon hasznos eszköz a dokumentációnk fejlesztésének nyomon követésében.

A Jira eszközzel kapcsolatos teljes információért tekintse meg az alábbi linket: https://www.javatpoint.com/jira-tutorial.

SonarQube

A kézi tesztelés másik tesztelési eszköze a SonarQube, amely folyamatos kódminőséggel és kódbiztonsággal javítja munkafolyamatunkat. Rugalmas a beépülő modulok használatával.

Teljesen JAVA programozási nyelven íródott. Teljesen automatizált kiértékelést és integrációt kínál az Ant, Maven, Gradle, MSBuild és állandó integrációs eszközökkel. A SonarQube képes mérőszámok előzményeinek rögzítésére, és megadja az evolúciós grafikont.

A Sonarqube jellemzői

Az alábbiakban bemutatjuk a SonarQube eszköz néhány fontos funkcióját:

• Számos programozási nyelvet támogat, mint például a C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL stb.
• A GNU Lesser General Public License értelmében a Sonarqube ingyenesen elérhető.
• A SonarQube társult néhány fontos külső eszközzel, mint például a GitHub, az Active Directory, az LDAP és mások.
• A SonarQube egyesült a Visual Studio, az Eclipse és az IntelliJ IDEA fejlesztői környezetekkel, mivel a SonarLint beépülő modulok.

JMeter

A JMeter egy nyílt forráskódú eszköz, amely mind a statikus, mind a dinamikus erőforrások és a dinamikus webalkalmazások teljesítményének tesztelésére szolgál.

Teljesen a JAVA alkalmazásra készült, hogy betöltse a funkcionális teszt viselkedését és mérje az alkalmazás teljesítményét.

Lehetővé teszi a felhasználók vagy a fejlesztők számára, hogy a forráskódot más alkalmazások fejlesztésére használják.

A JMeter jellemzői

Az alábbiakban bemutatjuk a JMeter néhány alapvető jellemzőjét:

• Platformfüggetlen, amely elfogadja a JVM-hez hasonlókat Windows, Mac és Linux stb.
• Támogatja a felhasználóbarát grafikus felületet, amely interaktív és egyszerű.
• Hihetetlenül bővíthető a teljesítményteszt betöltése többféle szerverre.

A JMeterrel kapcsolatos további információkért tekintse meg az alábbi linket:

https://www.javatpoint.com/jmeter-tutorial.

Bugz-al

A kézi teszteléshez használt másik hibakövető eszköz az Bugz-al .

Sok szervezet a legszélesebb körben használja az alkalmazás különféle hibáinak nyomon követésére.

A Bugzilla egy nyílt forráskódú eszköz, amely segít az ügyfélnek és az ügyfélnek nyomon követni a hibákat. A Bugzilla tesztmenedzsment eszköznek is tekinthető, mert ebben könnyen összekapcsolhatunk más teszteset-kezelési eszközöket, mint például az ALM, a Quality Center stb.

A Bugzilla jellemzői

A Bugzilla néhány további funkcióval is rendelkezik, amelyek segítségével könnyen jelenthetjük a hibát:

• Támogatja a különféle operációs rendszereket, mint például a Windows, a Linux és a Mac.
• A Bugzilla segítségével többféle formátumban is listázhatunk egy-egy hibát.
• A felhasználói beállítások mérhetik az e-mailes értesítéseket.
• A Bugzilla fejlett keresési képességekkel rendelkezik.

Mantis

A Mantis egy webalapú hibakövető rendszer. A ManitsBT jelentése Mantis Bug Tracker . A szoftverhibák követésére szolgál, és PHP programozási nyelven hajtják végre. Ez is egy nyílt forráskódú eszköz.

A sáska jellemzői

Az adott szerszám néhány standard funkciója a következő:

• Ennek az eszköznek a segítségével teljes szöveges keresési elérhetőségünk van.
• A problémákon végrehajtott módosítások ellenőrzési nyomvonalai.
• Ez biztosítja a revízióvezérlő rendszer integrációját.
• Szövegmezők és jegyzetek revízióvezérlése

A hibakövető eszközökkel kapcsolatos további részletekért tekintse meg a következő hivatkozást: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Egy másik integrációs tesztelési eszköz az Tessy , amely a beágyazott szoftver integrációjának és egységtesztjének végrehajtására szolgál. Segít a szoftver vagy alkalmazás kódlefedettségének felderítésében is.

Könnyen kezelheti a teljes tesztszervezetet, beleértve az üzleti igényeket, a tesztkezelést, a lefedettség mennyiségét és a nyomon követhetőséget.

A Tessy három elsődleges funkciót tartalmaz, amelyek a következők:

• Tesztfelület-szerkesztő (TIE)
• Tesztadat-szerkesztő (TDE)
• Munkaterület.

A TESSY jellemzői

A TESSY alapfunkciói a következők:

• A teszt végrehajtási eredményeiről tesztjelentést készít.
• Támogatja a különböző programozási nyelveket, mint például a C és a C++.
• A Tessy a függvény interfészének értékelésére szolgál, és leírja a függvény által használt változót.

Az integrációs tesztelési eszközökkel kapcsolatos további információkért tekintse meg a következő hivatkozást: https://www.javatpoint.com/integration-testing-tools.

a java karakterláncot tartalmazza

Áttekintés

Ebben a cikkben részletes információkat láthattunk Kézi tesztelés, amely magában foglalja a kézi tesztelés definícióját, a kézi tesztelés szükségességét, a kézi tesztelés típusát, a kézi tesztelő eszközöket, a kézi tesztelés folyamatát, valamint annak néhány fontos előnyét és hátrányát.

Végül elmondhatjuk, hogy ez egy olyan folyamat, amelyben a tesztmérnöknek nagyon kitartónak, innovatívnak és érzékenynek kell lennie.

A kézi tesztelés során a tesztmérnöknek úgy kell gondolkodnia és kell végeznie, mint a végfelhasználói értelmezést.

A kézi tesztelés végrehajtásához a tesztmérnöknek produktív készségekre és képzelőerőre van szüksége. És több helyzetet vagy forgatókönyvet kell gondolniuk egy adott alkalmazás teszteléséhez.

Annak ellenére, hogy jelenleg szinte minden alkalmazást tesztelhetünk az automatizálási tesztelés segítségével, mégis szükséges a manuális tesztelés, mivel ez a szoftvertesztelés alapja.