Mi az automatizált tesztelés?
Ebben a leckében megismerheti az automatizált tesztelés előnyeit és a elvégezhető tesztelési típusokat. Azt is megtudhatja, hogy mi teszi a jó tesztet, és bemutat néhány, az Ön számára elérhető tesztelési eszköznek.
Mi az automatizált tesztelés?
Az automatizált tesztelés szoftveres módon hajtja végre a kódot, és hasonlítja össze a kapott eredményeket a várt eredményekkel. Ezzel szemben a felderítő vagy manuális tesztelést emberek végzik, és általában a tesztelési terv utasításait követve ellenőrzik, hogy a szoftver az elvárásoknak megfelelően működik-e.
A manuális tesztelésnek megvannak a maga előnyei. De ahogy a kódbázis mérete növekszik, a funkciók (a szélsőséges esetekre is kiterjedő) manuális tesztelése ismétlődővé, aprólékossá és hibalehetőségekkel telivé válhat. Az automatizált tesztelés segíthet kiküszöbölni a terhek egy részét, és lehetővé teszi a manuális tesztelők számára, hogy a legjobb megoldásra összpontosítsanak: biztosítva, hogy a felhasználók pozitív felhasználói élményben legyen része a szoftverrel kapcsolatban.
A tesztelési piramis
Ha az automatizált tesztelésre gondolunk, gyakori, hogy a teszteket rétegekre bontjuk. A tesztelési piramis néven ismert koncepciót Mike Cohn vetette fel Succeeding with Agile című könyvében.
Bár ez a Cohn-modell egy egyszerű verziója, a koncepció azt mutatja, hogy a legtöbb erőfeszítést olyan tesztek írására összpontosítja, amelyek ellenőrzik a szoftver alapvető szintjeit (1. ábra a piramisban), például függvényeket, osztályokat és módszereket. A funkciók kombinálása egyre kevesebb erőfeszítést igényel, például a felhasználói felület (UI) rétegében (2. ábra a piramisban). Az ötlet az, hogy ha ellenőrizni tudja, hogy az egyes alacsonyabb szintű összetevők a várt módon működnek-e külön, a magasabb szinteken végzett teszteknek csak azt kell ellenőrizniük, hogy több összetevő együttműködik-e a várt eredmény eléréséhez.
Mikor érdemes megírni a teszteket?
A válasz főként az igényeitől és a tesztírásban szerzett tapasztalataitól függ.
Soha nem késő teszteket adni a kódhoz, amelyet már megírt és üzembe helyezett. Ez különösen azokra a funkciókra vonatkozik, amelyek gyakran meghibásodnak, vagy nagy energiabefektetést kívánnak a tesztcsapattól.
Ha a folyamatos integrációhoz és a folyamatos kézbesítési folyamatokhoz kapcsolódik a tesztelés, két fogalomról fog hallani: a folyamatos tesztelés és a balra tolódás.
A folyamatos tesztelés azt jelenti, hogy a tesztelések a fejlesztési folyamat korai szakaszában futnak, ahogy minden változás áthalad a folyamaton. A balra tolódás a szoftver minőségének szem előtt tartását és tesztelését jelenti már a fejlesztési folyamat korai szakaszában.
A fejlesztők például gyakran hozzáadnak teszteseteket, amikor fejlesztik a funkciójukat, és a teljes tesztcsomagot futtatják, mielőtt beküldik a módosítást a folyamatba. Ez a megközelítés segít biztosítani, hogy az általuk létrehozott funkció a várt módon viselkedjen, és hogy ne szegje meg a meglévő funkciókat.
Az alábbi rövid videóban Abel Wang, a Microsoft felhőtanácsadója ismerteti, hogyan biztosítható a minőség fenntartása a DevOps-csomagban.
Kérdezd meg Ábelt
A bal oldali váltáshoz gyakran szükséges, hogy a tesztelők részt vegyenek a tervezési folyamatban, még mielőtt bármilyen kódot megírnak a funkcióhoz. Hasonlítsa össze ezt az "átadási" modellel, ahol a tesztcsapat csak a szoftver megtervezése és megírása után tesztelendő új funkciókkal jelenik meg. A folyamat végén felfedezett hibák hatással lehetnek a csapat teljesítési ütemezésére, és a hibák hetek vagy akár hónapok után is felfedezhetők, miután a fejlesztő eredetileg elkészítette a funkciót.
A kompromisszum
Az automatizált teszteléssel kompromisszumra van szükség. Bár az automatizált tesztelés lehetővé teszi a tesztelők számára, hogy a végfelhasználói élmény ellenőrzésére összpontosítsanak, a fejlesztőknek több időt kell fordítaniuk a tesztkód írására és karbantartására.
Az automatizált tesztelés célja azonban annak biztosítása, hogy a tesztelők csak a legjobb minőségű kódot kapják, amely bizonyítottan a várt módon működik. Ezért a fejlesztők visszanyerhetik az idejük egy részét azáltal, hogy kevesebb hibát kell kezelniük, vagy el kell kerülniük a kód újraírását egy olyan peremes eset miatt, amelyet eredetileg nem tekintettek meg.
További előnyök
A dokumentáció és a kód egyszerűbb újrabontásának lehetősége az automatizált tesztelés két további előnye.
Dokumentáció
A manuális tesztelési tervek dokumentálják, hogy a szoftvernek hogyan kell viselkednie, és hogy az egyes funkciók mire valók.
Az automatizált tesztek is szolgálhatják ezt a célt. Az automatizált tesztkód gyakran emberek számára is olvasható formátumú. A megadott bemenetek olyan értékeket jelölnek, amelyet a felhasználók megadhatnak. Minden társított kimenet meghatározza, hogy a felhasználók mely eredményt várják el.
Valójában sok fejlesztő a tesztalapú fejlesztési (TDD) módszert követi a tesztkód megírásával egy új funkció implementálása előtt . A módszer lényege, hogy a fejlesztő megírja a – gyakran specifikációnak nevezett – teszteket, amelyek eleinte sikertelenek. Ezután fokozatosan megírja a kódot a funkció implementálásához, amíg minden teszt sikeres nem lesz. Így a specifikáció nem csak dokumentálja a követelményeket, de a tesztre épülő fejlesztés folyamata segít biztosítani, hogy csak a funkció implementálásához szükséges mennyiségű kód legyen megírva.
Újrabontás
Tegyük fel, hogy egy nagy méretű kódbázist szeretne újrabontani, hogy bizonyos részei gyorsabban fussanak. Honnan tudhatja, hogy az újrabontási műveletek nem okozzák majd az alkalmazás más részeinek meghibásodását?
Az automatizált tesztek szerződéstípusként szolgálnak. Vagyis meg kell adnia a bemeneteket és a várt eredményeket. A sikeres tesztek után már egyszerűbben kísérletezhet és bonthatja újra a kódot. A módosítás elvégzésekor csak le kell futtatnia a teszteket, és ellenőrizni, hogy továbbra is sikeresek-e. Miután teljesítette az újrabontási célokat, elküldheti a módosítást a buildelési folyamatnak, hogy mindenki jól járjon, de kisebb a törés kockázata.
Milyen típusú automatizált tesztelési folyamatok léteznek?
Az automatikus tesztelésnek számos típusa létezik. Minden teszt külön célt szolgál. Például futtathat biztonsági teszteket annak ellenőrzése céljából, hogy a szoftver bizonyos részeit vagy funkcióit kizárólag arra jogosult felhasználók érhetik-e el.
Amikor megemlítjük a folyamatos integrációt és a buildelési folyamatot, általában a fejlesztési tesztelésre hivatkozunk. A fejlesztési tesztelés azon tesztekre utal, amelyek futtathatóak az alkalmazás teszt- vagy éles környezetben való üzembe helyezése előtt.
A linttesztelés, a statikus kódelemzés egy formája például ellenőrzi a forráskódot annak megállapításához, hogy az megfelel-e a csapat stíluskalauzának. A következetesen formázott kódokat mindenki könnyebben elolvashatja és karbantarthatja.
Ebben a modulban egységteszteléssel és kódlefedettségi teszteléssel fog dolgozni.
Az egységtesztelés ellenőrzi a program vagy kódtár legalapvetőbb összetevőit, például a különálló függvényeket vagy metódusokat. Meg kell adnia egy vagy több bemeneti értéket és a várt eredményeket. A tesztfuttató minden tesztet végrehajt, és ellenőrzi, hogy a tényleges és a várt eredmények egyeznek-e.
Tegyük fel például, hogy van egy függvénye, amely egy osztást tartalmazó aritmetikai műveletet hajt végre. Megadhat néhány értéket, amelyeket a felhasználóktól elvárhat, valamint a peremes esetek értékeit, például a 0 és a -1 értéket. Ha egy adott bemenet hibát vagy kivételt eredményez, ellenőrizheti, hogy a függvény ugyanazt a hibát okozza-e.
A kódlefedettségi tesztelés kiszámítja az egységtesztek által lefedett kód százalékos arányát. A kódlefedettség-tesztelés feltételes ágakat is tartalmazhat a kódban, így biztosítva, hogy a függvények lefedve legyenek.
Minél magasabb a kódlefedettség százaléka, annál biztosabb lehet benne, hogy később nem fog olyan hibát felfedezni a kódban, amely nem lett teljes mértékben tesztelve. Nem kell elérnie a 100%-os kódlefedettségeket. Valójában a kezdéskor valószínűleg azt fogja tapasztalni, hogy alacsony a százalékos aránya, de ez kiindulópontot ad, amelyből további teszteket adhat hozzá, amelyek lefedik a problémás vagy gyakran használt kódot.
Az egységtesztek elkülönítése
Amikor az egységtesztelésről tanul, olyan kifejezéseket hallhat, mint a zoknik, a csonkok és a függőségi injektálás.
Ne feledje, hogy egy egységtesztnek egy adott függvényt vagy metódust kell ellenőriznie, és nem azt, hogy több összetevő hogyan működik együtt. De ha van egy olyan függvénye, amely egy adatbázist vagy webkiszolgálót hív meg, hogyan kezeli ezt?
Egy külső szolgáltatás hívása nem csak az elkülönítést szakítja meg, de lelassíthatja a dolgokat. Ha az adatbázis vagy a webkiszolgáló leáll, vagy egyébként nem érhető el, a hívás a tesztfuttatást is megzavarhatja.
Olyan technikákkal, mint a gúnyolás és a függőséginjektálás, létrehozhat olyan összetevőket, amelyek ezt a külső funkciót utánozzák. A modul későbbi részében egy példát fog kapni.
Ezután pedig integrációs teszteket futtathat, amelyekkel ellenőrizheti, hogy az alkalmazás megfelelően működik-e egy valódi adatbázissal vagy webkiszolgálóval.
Mitől jó egy teszt?
A saját tesztek írása és mások által írt tesztek olvasása során jobban azonosíthatja a jó teszteket. Íme néhány útmutató az első lépésekhez:
- Ne teszteljen a tesztelés kedvéért: A teszteknek olyan célt kell szolgálniuk, amely nem egy ellenőrzőlista-elem, amelyet át kell lépned. Olyan teszteket írhat, amelyek ellenőrzik, hogy a kritikus kód a kívánt módon működik-e, és nem szakítja meg a meglévő funkciókat.
- Tartsa rövidre a teszteket: A teszteknek a lehető leggyorsabban be kell fejeződnie, különösen azokat, amelyek a fejlesztési és buildelési fázisokban történnek. Ha a tesztek a folyamat minden módosítása során futnak, nem szeretné, hogy szűk keresztmetszetek legyenek.
- Győződjön meg arról, hogy a tesztek megismételhetők: A tesztfuttatások minden alkalommal ugyanazokat az eredményeket eredményezik, függetlenül attól, hogy a számítógépen, egy munkatárs számítógépén vagy a buildelési folyamatban futtatja őket.
- A tesztek koncentrált állapotban tartása: Gyakori tévhit, hogy a tesztek mások által írt kódokat fednek le. A tesztek általában csak a kódra vonatkoznak. Például ha egy nyílt forráskódú grafikai kódtárat használ a projektben, nem szükséges tesztelnie a kódtárat.
- Válassza ki a megfelelő részletességet: Ha például egységtesztelést végez, az egyes teszteknek nem szabad több függvényt vagy metódust egyesítenie vagy tesztelnie. A függvények mindegyikét külön tesztelje, majd a későbbiekben integrációs tesztek írásával ellenőrizze, hogy az összetevők megfelelően működnek-e együtt.
Milyen típusú tesztelési eszközök érhetők el?
A használt tesztelési eszközök az éppen létrehozott alkalmazás típusától és a végrehajtandó tesztelés típusától függenek. A Selenium használatával például számos webböngészőn és operációs rendszeren végezhet felhasználói felületi tesztelést.
Függetlenül attól, hogy az alkalmazás milyen nyelven van megírva, számos teszteszköz érhető el.
Például a Java-alkalmazások esetében választhatja a Checkstyle-t a lint teszteléshez, a JUnitot pedig az egységteszteléshez.
Ebben a modulban az NUnitot fogjuk használni az egységteszteléshez, mivel ez népszerű a .NET-közösségben.