Bejelentkezés

Kategória: Minőségbiztosítás

Minden, ami tesztelés.

  • Automatizáló framework-ök a szakmám során

    Eddigi pályafutásom során jó pár framework-höz volt szerencsém különféle programnyelvek mellett, és hát azt kell mondanom, hogy ideje ezeket összegyűjtenem, mert kezdem egy részét elfelejteni.

    • Selenium WebDriver (#C, JAVA)
    • HP UFT (Visual Basic Script)
    • Katalon Studio (Kotlin)
    • Cypress (JavaScript)
    • Playwright (TypeScript)

    Selenium + C# + NUnit

    Kezdjünk is bele. Szóval még az automatizáló pályám elején volt lehetőségem a munkám mellett gyakorolni, és az épp aktuális Selenium volt a választott C#-pal. Ez akkoriban azt jelentette, hogy ahogy ma egy demó kód kinéz, kb úgy irtam én is meg Visual Studioban, majd pedig NUnitban a saját gépemről futottak a tesztek. Attól függetlenül, hogy messze volt egy professziónális megoldástól, szépen fogta a regressziós hibákat.

    Valahogy így kell elképzelni, ahogy a tesztek futottak.

    HP UFT + Visual Basic Script + HP ALM

    Ez volt az első hivatalos automatizálós projektem, ami előtt még kaptam HP képzést is, bár ennél a munka és a szükséges tudás összeszedése internetről sokkal hasznosabbnak bizonyult. Ahogy nézem, a HP dolgai igencsak megváltoztak, más kezeli őket.

    HP ALM kapcsán a Gurunál találtam egy értékelhető leírást, és a jól emlékszem, én ennek az oldalnak használtam fel a tudásanyagát annak idején. Viszont jól látszik, hogy elszaladt az idő felette. Talán az egyik cimborám kérdezte pár éve, hogy mi a vélemenyem egy ilyen projektről, és már akkor azt mondtam, hogy kerülje el, mert nincs jövője.

    Annak idején ez az ökoszisztéma igencsak jól működött, bár ára is volt (cég fizette). Az ALM végezte a központosítást, az UFT pedig az automata tesztek fejlesztésért volt felelős.

    Így nézett ki az UFT.

    Az ALM pedig így.

    Szerintem ez a kettő együtt akkoriban zseniális párost alkotott.

    Katalon Studio

    Kísérletezgettem vele annak idején. Még tetszett is, de valahogy körülményesnek ítéltem meg a használatát. Ennél egy IDEs kódszerkesztővel jobban és minőségibben lehet/lehetett dolgozni. Az pozitív volt, hogy próbálta egy IDE-n belül kezelni a dolgokat, mint a HP UFT, viszont egy idő után kezdet átláthatatlanná válni számomra. Azóta egyébként valószínűleg ez is sokat fejlődött, bár nekem nem volt időm követni a változásokat.

    Valami ilyesmire emlékszem.

    Cypress + JavaScript

    Na ezt imádtam. Könnyedén és gyorsan lehetett benne dolgozni, bár csak 1 évet töltöttem vele. Egy negatívuma azért van/volt, hogy az async/await dolgokat maga kezeli. Ez az esetek túlnyomó többségében nagyon jól működik, de amikor valamiért ez nem jó, az fájdalmas tud lenni.

    Ha jól rémlik, én is VS Code-dal használtam, illetve GitLab-ban futottak a tesztek.

    Ha jól sejtem VS Codeban.

    Playwright + TypeScript

    Abszolút kedvenc. 3 évet töltöttem vele, és imádtam minden percet. Annyira könnyed és légies, és gyorsan lehet vele haladni annak köszönhetően, hogy zseniálisan van felépítve benne szinte minden, hogy csak ajánlani tudom.

    Több különböző nyelvet is támogat, bár nekem a TypeScript volt használatban. Illetve nagyon jól dokumentált. Nem volt szükség sok Google keresésre, mivel a leírás hozzá megválaszolt mindent.

    Ez pedig ilyen volt.

  • Manuális tesztelés, és/vagy automatizáció

    Amikor arról beszélünk, hogy mi a különbség a manuális és az automatizált tesztelés között, akkor nagyok sokan, nagyon sokféle választ adnak erre a kérdésre egy interjú során, majd pedig ezen meglátások többé-kevésbé mégsem valósulnak meg. Ennek oka többféle lehet. Például nem minden iparágban lehet ugyanazokat a szabályokat alkalmazni, vagy épp az üzleti érdek, kapacitás és/vagy tesztelésre fordítható anyagi javak ezt felülbírálják.

    Én meg azok köze tartozom, akik abban szocializálódtak, hogy a manuális tesztelés az a folyamat, ami az adott sprinten belül vizsgálja az új fejlesztést, és annak hatását az egész rendszerre. Ehhez persze érteni kell magát, az új fejlesztést, illetve, hogy mi módon kapcsolódik bele a már meglévő szisztémába. Ehhez normális esetben társulnak elfogadási kritériumok is, melyek a főbb csapásvonalak és működés leírását és elfogadását határozzák meg.

    Miután ez megvan, és az adott fejlesztés átment a minőségbiztosítás ezen folyamatán, utána következik az, ahol megvizsgálásra kerül, hogy mely tesztesetek szükségesek a regressziós folyamat ellátására. Azok kiválasztásra, majd pedig automatizálásra kerülnek, ezzel elérve azt a célt, hogy minden regressziós teszt futtatás során minimális emberi beavatkozással kaphassunk egy eredmény, ami igazolja, vagy épp cáfolja, hogy a rendszerünk az új fejlesztés után is megfelelően működik.

    Manuális tesztelésAutomatizálás
    üzleti logika teszteléseregresszió tesztek megvalósítása
    követelmény alapú megvalósításidő spórolás, ismétlődő teszt esetek
    bugok korai megtalálása, még az automatizálás előttgyors visszajelzés
    Exploratory és Ad-hoc tesztelésstabilan futó tesztek
    Manuális tesztelés

    A manuális tesztelés a szoftverek manuális tesztelésének folyamata a hibák feltárására. A tesztelőnek a végfelhasználó szerepét kell játszania, és az alkalmazás legtöbb funkcióját kell használnia a helyes viselkedés biztosítása érdekében. A tesztelés teljességének garantálása érdekében a tesztelő gyakran követ egy írásos teszttervet, amely végigvezeti a fontos teszteseteken.

    Áttekintés

    A folyamat egyik legfontosabb lépése a szoftver helyes viselkedésének tesztelése a végfelhasználók számára történő kiadást megelőzően.

    Kis léptékű mérnöki erőfeszítéseknél (beleértve a prototípusokat) elegendő lehet a feltáró tesztelés. Ennél az informális megközelítésnél a tesztelő nem követ szigorú tesztelési eljárást, hanem inkább az alkalmazás felhasználói felületét vizsgálja meg a lehető legtöbb funkciót felhasználva, és a korábbi tesztek során szerzett információkat felhasználva intuitív módon további teszteket vezet le. A feltáró manuális tesztelés sikere nagymértékben függ a tesztelő szakértelmétől, mivel a tudás hiánya a tesztelés hiányosságaihoz vezet. Az informális megközelítés egyik legfontosabb előnye, hogy intuitív betekintést nyerhetünk abba, milyen érzés használni az alkalmazást.

    A manuális szoftvertesztelésre támaszkodó nagyméretű mérnöki projektek szigorúbb módszertant követnek, hogy maximalizálják a fellelhető hibák számát. A szisztematikus megközelítés előre meghatározott tesztesetekre összpontosít, és általában a következő lépéseket foglalja magában:[1]

    • Kiválaszt egy magas szintű tesztelési tervet, amelyben kiválasztják az általános módszertant, meghatározzák és beszerzik az erőforrásokat, például az embereket, a számítógépeket és a szoftverlicenceket.
    • Részletes tesztesetek írása, a tesztelő által végrehajtandó világos és tömör lépések azonosítása, a várt eredményekkel együtt.
    • A tesztesetek kiosztása a tesztelőknek, akik manuálisan követik a lépéseket és rögzítik az eredményeket.
    • A tesztelők megállapításait részletező tesztelési jelentés készítése. A jelentést a menedzserek arra használják, hogy eldöntsék, kiadható-e a szoftver, és ha nem, akkor a mérnökök arra, hogy azonosítsák és kijavítsák a problémákat.

    A szigorú, teszteseteken alapuló megközelítés gyakran hagyományos a vízesésmodellt[2] követő nagy szoftverfejlesztési projektek esetében. Legalább egy nemrégiben készült tanulmány azonban nem mutatott drámai különbséget a hibák felderítésének hatékonyságában a feltáró tesztelés és a teszteset-alapú tesztelés között.[3]

    A tesztelés történhet fekete-, fehér– vagy szürkedobozos teszteléssel. A fehérdobozos tesztelés során a tesztelő a forráskódon keresztül az utasítások végrehajtásával foglalkozik. A feketedobozos tesztelés során a szoftver futtatása a hibák ellenőrzése céljából történik, és kevésbé foglalkozik azzal, hogy a bemenet feldolgozása hogyan történik. A fekete dobozos tesztelők nem férnek hozzá a forráskódhoz. A szürke dobozos tesztelés a szoftver futtatásával foglalkozik, miközben ismeri a forráskódot és az algoritmusokat.

    Statikus és dinamikus tesztelési megközelítés is alkalmazható. A dinamikus tesztelés a szoftver futtatását foglalja magában. A statikus tesztelés magában foglalja a követelmények, a kód szintaxisának ellenőrzését és minden más olyan tevékenységet, amely nem foglalja magában a program kódjának tényleges futtatását.

    A tesztelés tovább osztható funkcionális és nemfunkcionális tesztelésre. A funkcionális tesztelés során a tesztelő ellenőrzi a számításokat, az oldalon lévő bármely linket vagy bármely más mezőt, amely adott bemenet esetén kimenetet várhat. A nem funkcionális tesztelés többek között a tesztelt rendszer teljesítményének, kompatibilitásának és alkalmasságának, biztonságának és használhatóságának vizsgálatát foglalja magában.

    A kézi tesztelés előnyei

    • Alacsony költségű működés, mivel nem használnak szoftvereszközöket
    • A legtöbb hibát kézi teszteléssel meg lehet találni
    • Az emberek jobban figyelnek és ítélnek, mint az automatizált eszközök

    Összehasonlítás az automatizált teszteléssel

    A teszt automatizálás képes lehet csökkenteni vagy megszüntetni a tényleges tesztelés költségeit. A számítógép gyorsabban képes követni a rutinszerű lépéssorozatot, mint egy ember, és képes a teszteket éjszakára lefuttatni, hogy reggelre bemutassa az eredményeket. A tényleges teszteléssel megtakarított munkaerőt azonban a tesztprogram felügyeletével kell tölteni. A tesztelendő alkalmazás típusától és a választott automatizálási eszközöktől függően ez több munkát igényelhet, mint a manuális megközelítés. Ezenkívül egyes tesztelési eszközök nagyon nagy mennyiségű adatot mutatnak be, ami potenciálisan időigényes feladatot jelenthet az eredmények értelmezésében.

    Az olyan dolgokat, mint az eszközillesztők és a szoftverkönyvtárak, tesztprogramok segítségével kell tesztelni. Ezenkívül a nagyszámú felhasználó tesztelését (teljesítménytesztelés és terheléses tesztelés) jellemzően szoftverben szimulálják, nem pedig a gyakorlatban végzik el.

    Ezzel szemben a gyakran változó elrendezésű grafikus felhasználói felületeket nagyon nehéz automatikusan tesztelni. Léteznek tesztelési keretrendszerek, amelyek a felhasználói felületek regressziós tesztelésére használhatók. Ezek a billentyűleütések és egérmozdulatok sorozatainak rögzítésére, majd ezek lejátszására és annak megfigyelésére épülnek, hogy a felhasználói felület minden alkalommal ugyanúgy reagál-e. Sajnos előfordulhat, hogy ezek a felvételek nem működnek megfelelően, ha egy gombot áthelyeznek vagy átcímkéznek egy későbbi kiadásban. Az automatikus regressziós tesztet is becsaphatja, ha a program kimenete jelentősen változik.

    Forrás: Wikipédia