Mi az automatizálási tesztelés (Végső útmutató a teszt-automatizálás elindításához)

Egy teljes útmutató az automatizálási tesztelés elindításához a projekteden:

Mi az automatizálási tesztelés?

Az automatizálási tesztelés egy szoftvertesztelési technika a tényleges eredmény tesztelésére és összehasonlítására a várt eredménnyel. Ezt tesztelési szkriptek írásával vagy bármilyen automatizálási tesztelési eszköz használatával lehet elérni. A teszt automatizálása az ismétlődő feladatok és egyéb, manuálisan nehezen elvégezhető tesztelési feladatok automatizálására szolgál.

automatizálási tesztelési útmutató

Az automatizálási tesztelést szeretné elindítani a projektjén, de az alábbiakban említett legalapvetőbb lépésekkel küzd:

  • Hogyan vezesse be az automatizálást a projektjében?
  • Hogyan válassza ki a legjobb és megfelelő automatizálási eszközt?
  • Hogyan fejlesszen szkripteket hatékonyan?
  • Hogyan hajtsa végre és tartsa karban a tesztszkripteket?
  • És végül mik azok a legjobb gyakorlatok, amelyeket követnie kell a sikeres automatizálási teszteléshez?

A mai napon a “Kezdetek az automatizálási teszteléssel” című tutorial-sorozattal terveztük gazdagítani a tudását. Ez az automatizálási oktatóanyag-sorozat lépésről lépésre, egyszerű példákkal válaszol a fenti kérdésekre.

Nézzük meg az Automatizálás megkezdése a projektjén című oktatóanyag-sorozatot!!!

Automatizálás végponttól végpontig tartó folyamata:

Tutorial #1: A legjobb útmutató az automatizálás elindításához a projekteden
Tutorial #2: Az automatizált tesztek típusai és néhány tévhit
Tutorial #3: 10 lépés az automatizálás bevezetéséhez a projekteden
Tutorial #4: A-tól Z-ig útmutató a legjobb automatizálási eszköz kiválasztásához
Tutorial #5: Scriptfejlesztés és automatizálási keretek
Tutorial #6: Az automatizálás végrehajtása és jelentése
Tutorial #7: A teszt automatizálás legjobb gyakorlatai és stratégiái

Automatizálási tippek:

Tutorial #8: 10 tipp, amit érdemes elolvasni a tesztelési munka automatizálása előtt
Tutorial #9: Miben különbözik a teszttervezés a manuális és az automatizálási projekteknél
Tutorial #10: Mikor érdemes az automatizálást választani?
Tutorial #11: Automatizálási tesztelési kihívások
Tutorial #12: Útmutató a koncepció bizonyításának (POC) megvalósításához az automatizálásban
Tutorial #13: Hogyan válasszuk ki a helyes teszteseteket az automatizáláshoz
Tutorial #14: Hogyan fordítsuk a manuális teszteseteket automatizálási szkriptekké

Automatizálási karrier:

Tutorial #15: Tippek, hogy jobb automatizálási tesztelő legyél
Tutorial #16: Teszt automatizálás – ez egy speciális karrier? A normál tesztelők is végezhetnek automatizálást?

Népszerű automatizálási eszközök:

Tutorial #17: Selenium oktatóanyagok 31+ A legjobb ingyenes Selenium oktatóanyagok
Tutorial #18: QTP Tutorials
Tutorial #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner teljesítményteszteléshez

Automatizálási keretek:

Tutorial #21: Miért van szükségünk keretrendszerekre az automatizáláshoz
Tutorial #22: A legnépszerűbb automatizálási keretrendszerek

Automatizálás az agilis világban:

Tutorial #23: Hogyan valósítsunk meg hatékony automatizálást az agilis világban

Más automatizálási eszközök:

Tutorial #24: A legjobb automatizálási teszteszközök
Tutorial #25: Sikuli GUI automatizálási eszköz
Tutorial #26: PowerShell: Desktop Application UI Automation With PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Geb Tool: Browser Automation Using Geb Tool
Tutorial #29: AutoIt: Hogyan kezeljük a felugró ablakokat az AutoIt segítségével
Tutorial #30: Cucumber: Automatizálás a Cucumber eszköz és a Selenium használatával
Tutorial #31: Protractor Testing Tool for End-to-end Testing of AngularJS Applications

Mobile Automation Testing:

Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial for Beginners
Tutorial #34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial #35: Ranorex Tutorial: A Powerful Desktop, Web, and Mobile Testing Tool

Domain Specific Automation Examples:

Tutorial #36: JAVA/J2EE alkalmazások automatizálása

Interjúra való felkészülés az automatizálási állásokra:

Tutorial #37: Automation Testing Interview Questions
Tutorial #38: Selenium Interview Questions

Lássuk a “The Ultimate Guide to Automation Testing” sorozat első bemutatóját!!

Mi az automatizálási tesztelés?

Ha egy szoftver bármit megtehet, akkor miért ne tesztelhetne egy szoftver egy szoftvert?

Az állítás logikusan hangzik számodra?

Ha igen, akkor gratulálok, most a Teszt-automatizáláson gondolkodsz, ami a központi pont, amit ebben az informatív oktatóanyag-sorozatban tárgyalni fogunk.

Képzeld el magad n az első napon a munkahelyeden SQA-ként. Bemutatnak neked egy tesztelendő alkalmazást. Ez egy ERP-alkalmazás, amely több száz űrlapot és több ezer jelentést tartalmaz. A feltáró tesztelést egy olyan űrlap megnyitásával kezded, amely körülbelül 50 különböző mezőt tartalmaz.

Megpróbálsz véletlenszerű adatokat beírni ebbe az űrlapba, ami körülbelül 20 percig tartott. Ezután megnyomja a submit gombot. Wolla!!! Egy hibaüzenet jelenik meg, amely úgy néz ki, mint egy kezeletlen kivétel. Ön nagyon boldog lesz. Büszkén feljegyzed a lépéseket, és jelented a hibát a hibakezelő rendszeredben. Nagyszerű erőfeszítés, igazán magabiztosnak és energikusnak érzed magad. Folytatod a tesztelést a nap végéig, és újabb hibákat találsz. “Csodálatos első nap”, gondoltad.

Most jön a következő nap, a fejlesztő kijavította a hibát és kiadja a build új verzióját. Ugyanazt az űrlapot teszteled ugyanazokkal a lépésekkel, és megállapítod, hogy a hibát kijavították. Megjelöli a javított hibát. Nagyszerű erőfeszítés. A hiba azonosításával hozzájárultál a termék minőségéhez, és mivel a hibát kijavították, a minőség javult.

Most jön a harmadik nap, a fejlesztő ismét kiadott egy újabb verziót. Most ismét tesztelned kell ezt az űrlapot, hogy megbizonyosodj arról, hogy nem találtál regressziós hibát. Ugyanez a 20 perc. Most egy kicsit unatkozol.

Most képzeld el, hogy innentől kezdve 1 hónap múlva folyamatosan újabb verziók jelennek meg, és minden egyes kiadásnál tesztelned kell ezt a hosszú űrlapot, plusz 100 másik hasonló űrlapot, csak hogy megbizonyosodj róla, hogy nincs regressziós hiba.

Most dühösnek érzed magad. Fáradtnak érzed magad. Elkezdesz lépéseket kihagyni. Körülbelül csak az összes mező 50%-át töltöd ki. A pontosságod nem ugyanaz, az energiád nem ugyanaz, és határozottan a lépéseid sem ugyanazok.

És egy nap az ügyfél ugyanazt a hibát jelenti ugyanabban az űrlapban. Szánalmasnak érzed magad. Most már nem érzed magad magabiztosnak. Úgy gondolod, hogy nem vagy elég kompetens. A vezetők megkérdőjelezik a képességeidet.

Van egy hírem számodra; ez a manuális tesztelők 90%-ának története. Te sem vagy más.

A regressziós problémák a legfájdalmasabb problémák. Emberek vagyunk. És nem tudjuk ugyanazt a dolgot minden nap ugyanolyan energiával, sebességgel és pontossággal elvégezni. Ezt a gépek teszik. Erre van szükség az automatizáláshoz, hogy ugyanazokat a lépéseket ugyanazzal a sebességgel, pontossággal és energiával ismételjük meg, mint az első alkalommal.”

Remélem, érted a lényeget!!!

Automatizált tesztelés egy barát

Amikor ilyen helyzet adódik, automatizáld a tesztesetet. A teszt automatizálás a barátod. Segít abban, hogy az új funkcionalitásra összpontosíthass, miközben a regressziókra is ügyelhetsz. Az automatizálással kevesebb mint 3 perc alatt kitöltheti ezt az űrlapot.

A szkript kitölti az összes mezőt, és képernyőképekkel együtt közli az eredményt. Sikertelenség esetén pontosan meg tudja határozni azt a helyet, ahol a teszteset kudarcot vallott, így segít Önnek könnyedén reprodukálni azt.

Automatizálás – a regressziós tesztelés költséghatékony módszere

Az automatizálás költségei kezdetben valóban magasabbak. Magában foglalja az eszköz költségét, majd az automatizálási tesztelési erőforrás költségét és a képzését.

Amikor azonban a szkriptek elkészültek, több százszor ismételten ugyanolyan pontossággal és meglehetősen gyorsan végrehajthatók. Ez sok órányi kézi tesztelést takarít meg. Így a költségek fokozatosan csökkennek, és végül a regressziós tesztelés költséghatékony módszerévé válik.

Automatizálást igénylő forgatókönyvek

A fenti forgatókönyv nem az egyetlen eset, amikor automatizált tesztelésre lesz szükség. Számos olyan helyzet van, amelyet manuálisan nem lehet tesztelni.

Például,

  1. Két kép pixelenkénti összehasonlítása.
  2. Két több ezer sort és oszlopot tartalmazó táblázat összehasonlítása.
  3. Az alkalmazás tesztelése 100 000 felhasználó terhelése alatt.
  4. Teljesítmény benchmarkok.
  5. Az alkalmazás tesztelése különböző böngészőkön és különböző operációs rendszereken párhuzamosan.

Ezek a helyzetek igénylik és kell is, hogy teszteljék az eszközöket.

Szóval, mikor érdemes automatizálni?

Az SDLC-ben az agilis módszertan korszakát éljük, ahol a fejlesztés és a tesztelés szinte párhuzamosan zajlik, és nagyon nehéz eldönteni, mikor érdemes automatizálni.

Nézzük meg a következő helyzeteket, mielőtt belevágunk az automatizálásba

  • A termék lehet kezdetleges stádiumban, amikor a terméknek még UI-ja sincs, ezekben a szakaszokban világosan át kell gondolnunk, mit szeretnénk automatizálni. A következő pontokat nem szabad elfelejteni.
    • A teszteknek nem szabad elavultnak lenniük.
    • Amint a termék fejlődik, könnyűnek kell lennie a szkriptek kiválasztásának és kiegészítésének.
    • Nagyon fontos, hogy ne ragadtassuk el magunkat, és biztosítsuk, hogy a szkriptek könnyen hibakereshetők legyenek.
  • Ne próbálkozzunk UI-automatizálással a kezdeti szakaszokban, mivel az UI gyakori változásoknak van kitéve, ezáltal a szkriptek meghibásodásához vezet. Amennyire lehetséges, válasszon API-szintű/nem UI-szintű automatizálást, amíg a termék stabilizálódik. Az API-automatizálás könnyen javítható és hibaelhárítható.

Hogyan döntsük el a legjobb automatizálási eseteket:

Az automatizálás a tesztelési ciklus szerves része, és nagyon fontos, hogy eldöntsük, mit szeretnénk elérni az automatizálással, mielőtt az automatizálás mellett döntenénk.

Az automatizálás által látszólag biztosított előnyök nagyon vonzóak, ugyanakkor egy rosszul szervezett automatizálási csomag elronthatja az egész játékot. A tesztelők az idő nagy részében a szkriptek hibakeresésével és javításával végezhetik, ami tesztelési időveszteséget eredményezhet.

Effektív tesztautomatizálás

Ez a sorozat elmagyarázza, hogyan lehet egy automatizálási csomagot elég hatékonnyá tenni ahhoz, hogy a megfelelő teszteseteket vegye fel, és a megfelelő eredményeket hozza a rendelkezésünkre álló automatizálási szkriptekkel.

Az olyan kérdésekre is választ kaptunk, mint a Mikor automatizáljunk, Mit automatizáljunk, Mit ne automatizáljunk, és Hogyan automatizáljunk stratégiailag.

A megfelelő tesztek az automatizáláshoz

A legjobb módja a probléma kezelésének, ha gyorsan kitalálunk egy, a termékünkhöz illő “automatizálási stratégiát”.

Az ötlet az, hogy a teszteseteket úgy csoportosítjuk, hogy minden csoport másfajta eredményt adjon. Az alábbi ábrán látható, hogyan csoportosíthatjuk a hasonló teszteseteinket, attól függően, hogy milyen terméket/megoldást tesztelünk.

Tesztesetek csoportosítása

Merüljünk most mélyebbre, és értsük meg, hogy az egyes csoportok mit segíthetnek nekünk elérni:

#1) Készítsünk egy tesztcsomagot az összes alapvető funkcionalitás pozitív tesztjéből. Ezt a csomagot automatizálni kell, és amikor ezt a csomagot bármelyik build ellen futtatjuk, az eredmények azonnal megjelennek. Bármelyik szkript, ami ebben a csomagban megbukik, S1 vagy S2 hibához vezet, és az adott build specifikusan kizárható. Tehát itt rengeteg időt takarítottunk meg.

Egy további lépésként ezt az automatizált tesztcsomagot a BVT (Build verification tests) részeként adhatjuk hozzá, és a QA automatizálási szkripteket a terméképítési folyamatba is be tudjuk ellenőrizni. Így amikor a build elkészül, a tesztelők ellenőrizhetik az automatizálási tesztek eredményeit, és eldönthetik, hogy a build alkalmas-e a telepítésre és a további tesztelési folyamatra vagy sem.

Ezzel egyértelműen elérjük az automatizálás céljait, amelyek a következők:

  • csökkentjük a tesztelési erőfeszítéseket.
  • A hibák korábbi szakaszokban történő megtalálása.

#2) Ezután következik a végponttól végpontig tartó tesztek csoportja.

A nagy megoldások esetében a végponttól végpontig tartó funkcionalitás tesztelése kulcsfontosságú, különösen a projekt kritikus szakaszaiban. Legyen néhány automatizálási szkriptünk, amelyek érintik a végponttól végpontig megoldás tesztjeit is. Amikor ezt a csomagot futtatjuk, az eredménynek jeleznie kell, hogy a termék egésze az elvárásoknak megfelelően működik-e vagy sem.

Az automatizálási tesztcsomagnak jeleznie kell, ha valamelyik integrációs darab elromlott. Ennek a csomagnak nem kell lefednie a megoldás minden egyes apró funkcióját/funkcionalitását, hanem a termék egészének működését kell lefednie. Amikor van egy alfa vagy béta vagy bármilyen más köztes kiadás, akkor az ilyen szkriptek jól jönnek, és bizonyos szintű bizalmat adnak az ügyfélnek.

A jobb megértés érdekében tegyük fel, hogy egy online vásárlási portált tesztelünk, a végponttól végpontig tartó tesztek részeként csak a kulcsfontosságú lépésekre kell kiterjednünk.

Az alábbiak szerint:

  • A felhasználó bejelentkezése.
  • Böngészés és tételek kiválasztása.
  • Fizetési lehetőség – ez a front end teszteket fedi le.
  • Backend rendeléskezelés (magában foglalja a több integrált partnerrel való kommunikációt, a készlet ellenőrzését, a felhasználónak küldött e-mailt stb.) – ez segít az egyes darabok tesztelési integrációjában és a termék lényegét is.

Az egyik ilyen szkript futtatása bizalmat ad, hogy a megoldás egésze jól működik.!

#3) A harmadik készlet a funkció/funkcionalitás alapú tesztek.

Elképzelhető például, hogy rendelkezünk egy fájl böngészésének és kiválasztásának funkciójával, így amikor ezt automatizáljuk, automatizálhatunk olyan eseteket, amelyek a különböző típusú fájlok kiválasztását, a fájlok méretét stb. tartalmazzák, így a funkciótesztelés megtörténik. Ha a funkcionalitásban bármilyen változás/hozzáadás történik, ez a csomag szolgálhat regressziós csomagként.

#4) A következő a listán a felhasználói felület alapú tesztek lennének. Lehet egy másik csomagunk, amely tisztán UI-alapú funkciókat tesztel, mint például a lapozás, szövegdoboz karakterkorlátozása, naptárgomb, legördülő ablakok, grafikonok, képek és sok ilyen, csak UI-központú funkció. Ezeknek a szkripteknek a hibája általában nem túl kritikus, kivéve, ha a felhasználói felület teljesen leállt, vagy bizonyos oldalak nem a várt módon jelennek meg!

#5) Létezhet még egy olyan tesztkészlet, amelyet egyszerű, de nagyon fáradságos manuálisan elvégezni. A fárasztó, de egyszerű tesztek az ideális automatizálási jelöltek, például 1000 ügyfél adatainak bevitele az adatbázisba egyszerű funkcionalitású, de rendkívül fárasztó manuálisan elvégezni, az ilyen teszteket automatizálni kell. Ha nem, akkor többnyire figyelmen kívül hagyják és nem tesztelik őket.

Mit NE automatizáljunk?

Az alábbiakban néhány olyan tesztet mutatunk be, amelyeket nem szabad automatizálni.

#1) Negatív tesztek/Failover tesztek

Negatív vagy failover tesztek automatizálásával nem szabad próbálkoznunk, mivel ezeknél a teszteknél a tesztelőknek analitikusan kell gondolkodniuk, és a negatív tesztek nem igazán egyszerűek, és nem adnak megfelelő vagy nem megfelelő eredményt, ami segíthet nekünk.

A negatív tesztek sok manuális beavatkozást igényelnek egy tényleges katasztrófa utáni helyreállítási forgatókönyv szimulálásához. Csak példaként említem, hogy olyan funkciókat tesztelünk, mint a webes szolgáltatások megbízhatósága – általánosítva itt az ilyen tesztek fő célja az lenne, hogy szándékos hibákat okozzunk, és megnézzük, mennyire megbízható a termék.

A fenti hibák szimulálása nem egyszerű, ez magában foglalhatja néhány stub befecskendezését vagy néhány eszköz használatát, és az automatizálás nem a legjobb módja annak, hogy ezt megtegyük.

#2) Ad hoc tesztek

Ezek a tesztek nem biztos, hogy mindig relevánsak a termék szempontjából, és ez akár olyasmi is lehet, amire a tesztelő a projekt indításának adott szakaszában gondolhat, és az ad-hoc tesztek automatizálására tett erőfeszítést is validálni kell annak a funkciónak a kritikusságával szemben, amelyet a tesztek érintenek.

Egy tesztelő, aki például egy olyan funkciót tesztel, amely az adatok tömörítésével/titkosításával foglalkozik, intenzív ad-hoc teszteket végezhetett különböző adatokkal, fájltípusokkal, fájlméretekkel, sérült adatokkal, adatok kombinációjával, különböző algoritmusokkal, több platformon stb.

Az automatizálás megtervezésekor lehet, hogy fontossági sorrendet kell felállítanunk, és nem az összes ad hoc teszt kimerítő automatizálását kell elvégeznünk csak erre a funkcióra, és végül marad egy kis időnk a többi kulcsfontosságú funkció automatizálására.

#3) Hatalmas előfeltételekkel rendelkező tesztek

Vannak olyan tesztek, amelyek hatalmas előfeltételeket igényelnek.

Egy termékünk például integrálódhat egy harmadik féltől származó szoftverrel néhány funkcióhoz, mivel a termék integrálódik bármilyen üzenetküldő várólistás rendszerrel, ami megköveteli a rendszerre való telepítést, a várólisták beállítását, a várólisták létrehozását stb.

A 3rd party szoftver lehet bármi, és a beállítás összetett lehet, és ha az ilyen szkriptek automatizáltak, akkor ezek örökre függnek a 3rd party szoftver funkciójától/beállításától.

Az előfeltételek közé tartozik:

A dolgok jelenleg egyszerűnek és tisztának tűnhetnek, mivel mindkét oldal beállítása megtörtént, és minden rendben van. Számos alkalommal láttuk, hogy amikor egy projekt a karbantartási fázisba lép, a projekt átkerül egy másik csapathoz, és végül olyan szkriptek hibakeresését végzik, ahol a tényleges teszt nagyon egyszerű, de a szkript egy 3rd party szoftver problémája miatt sikertelen.

A fenti csak egy példa, általánosságban érdemes szemmel tartani az olyan teszteket, amelyeknek fáradságos előzetes beállításai vannak egy egyszerű teszthez, ami utána következik.

Egyszerű példa a teszt automatizálására

Amikor egy szoftvert tesztelünk (webes vagy asztali környezetben), általában egeret és billentyűzetet használunk a lépések végrehajtásához. Az automatizálási eszköz ugyanezeket a lépéseket utánozza szkriptelés vagy egy programozási nyelv segítségével.

Példa: ha egy számológépet tesztel, és a teszteset az, hogy össze kell adni két számot, és meg kell nézni az eredményt. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

  1. Launch Calculator
  2. Press 2
  3. Press +
  4. Press 3
  5. Press =
  6. The screen should display 5.
  7. Close Calculator.

Automation Script:

//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(“5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that “5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. Minden tesztesetben összehasonlítjuk a várt eredményt a tényleges eredménnyel.

Az automatizált tesztelésre is ugyanez vonatkozik. Az egyetlen különbség itt az, hogy amikor ezt az összehasonlítást a tesztautomatizálásban végezzük, akkor azt minden eszközben másképp hívják.

Egyik eszköz “Assertion”-nak, másik “checkpoint”-nak, harmadik pedig “validáció”-nak hívja. De alapvetően ez csak egy összehasonlítás. Ha ez az összehasonlítás sikertelen, pl. a képernyőn 5 helyett 15 jelenik meg, akkor ez az állítás/ellenőrzési pont/érvényesítés sikertelen, és a teszteset sikertelennek minősül.

Ha egy teszteset egy állítás miatt sikertelen, akkor ez azt jelenti, hogy hibát fedezett fel a teszt automatizálással. Ezt jelentenie kell a hibakezelő rendszerébe, ahogyan a manuális tesztelés során szokta.

A fenti szkriptben az utolsó előtti sorban egy állítást hajtottunk végre. Az 5 a várt eredmény, a txtResult. DisplayText a tényleges eredmény, és ha ezek nem egyeznek meg, akkor megjelenik egy üzenet, hogy “A számológép nem mutatja az 5-öt”.

Következtetés

A tesztelők gyakran találkoznak projekthatáridőkkel és megbízásokkal, hogy automatizálják az összes esetet a tesztelési becslések javítása érdekében.

Az automatizálással kapcsolatban van néhány általános “téves” felfogás.

Az alábbiak:

  • Minden tesztesetet automatizálhatunk.
  • A tesztek automatizálása óriási mértékben csökkenti a tesztelési időt.
  • Nincsenek hibák, ha az automatizálási szkriptek zökkenőmentesen futnak.

Tisztában kell lennünk azzal, hogy az automatizálás csak bizonyos típusú tesztek esetében képes csökkenteni a tesztelési időt. Az összes teszt terv vagy sorrend nélküli automatizálása masszív szkriptekhez vezet, amelyek nehéz karbantartást igényelnek, gyakran hibáznak és sok manuális beavatkozást is igényelnek. Emellett a folyamatosan fejlődő termékeknél az automatizálási szkriptek elavulhatnak, és folyamatos ellenőrzésre szorulhatnak.

A megfelelő jelöltek csoportosítása és automatizálása rengeteg időt takarít meg, és az automatizálás minden előnyét biztosítja.

Ez a kiváló útmutató mindössze 7 pontban foglalható össze.

Automatizált tesztelés:

  • A programozottan végzett tesztelés.
  • A tesztek végrehajtásának vezérlésére szolgáló eszközt használ.
  • Összehasonlítja a várt eredményeket a tényleges eredményekkel (Assertions).
  • Automatizálhat néhány ismétlődő, de szükséges feladatot (Pl. A regressziós tesztesetek).
  • Automatizálhat néhány olyan feladatot, amelyet nehéz manuálisan elvégezni (Pl.G. Terhelés tesztelési forgatókönyvek).
  • A szkriptek gyorsan és ismételten lefuthatnak.
  • Hosszú távon költséghatékony.

Itt az automatizálás egyszerű kifejezésekkel van magyarázva, de ez nem jelenti azt, hogy mindig egyszerű a kivitelezése. Vannak benne kihívások, kockázatok és sok más akadály. Számos módja van annak, hogy a tesztautomatizálás rosszul sülhet el, de ha minden jól megy, akkor a tesztautomatizálás előnyei valóban hatalmasak.

A sorozat következő részei:

A következő oktatóanyagainkban az automatizálással kapcsolatos számos szempontot tárgyalunk majd.

Ezek közé tartozik:

  1. Az automatizált tesztek típusai és néhány tévhit.
  2. Hogyan vezesse be az automatizálást a szervezetében, és hogyan kerülje el a gyakori buktatókat a tesztautomatizálás során.
  3. Az eszközválasztási folyamat és a különböző automatizálási eszközök összehasonlítása.
  4. Script fejlesztés és automatizálási keretrendszerek példákkal.
  5. A teszt automatizálás végrehajtása és jelentése.
  6. A teszt automatizálás legjobb gyakorlatai és stratégiái.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.