A tesztautomatizálás a tesztelt szoftvertől különálló szoftverek alkalmazását jelenti a tesztek végrehajtásának vezérlésére, valamint a tényleges eredmények és a várt eredmények összehasonlítására. A tesztautomatizálás képes automatizálni néhány ismétlődő, de szükséges feladatot egy már meglévő, formalizált tesztelési folyamatban, vagy olyan további teszteket elvégezni, amelyeket manuálisan nehéz lenne megvalósítani. A tesztautomatizálás kulcsfontosságú szerepet játszik a folyamatos szállítás (continuous delivery) és a folyamatos tesztelés (continuous testing) megvalósításában.
Általános megközelítések Számos megközelítés létezik a tesztautomatizálásra, azonban az alábbiakban a leggyakrabban alkalmazott általános módszereket mutatjuk be:
Grafikus felhasználói felület tesztelése: Olyan tesztelési keretrendszer, amely felhasználói felületi eseményeket – például billentyűleütéseket és egérkattintásokat – generál, majd megfigyeli az ezek által kiváltott változásokat a felhasználói felületen. A cél annak ellenőrzése, hogy a program megfigyelhető viselkedése megfelel-e az elvárásoknak. API-vezérelt tesztelés:Olyan tesztelési keretrendszer, amely egy programozási interfészt használ az alkalmazás viselkedésének érvényesítésére. Az API-vezérelt tesztelés általában teljesen megkerüli az alkalmazás grafikus felhasználói felületét. Ez magában foglalhatja osztályok, modulok vagy könyvtárak nyilvános interfészeinek tesztelését is, különböző bemeneti argumentumok alkalmazásával annak ellenőrzésére, hogy a visszakapott eredmények helyesek-e.
Más megközelítések
Modell alapú tesztelés Az egyik módszer a tesztesetek automatikus generálására a modellalapú tesztelés, amely a rendszer egy modelljének felhasználásával állít elő teszteseteket, azonban a kutatások továbbra is számos alternatív módszert vizsgálnak ezen a területen. Egyes esetekben a modellalapú megközelítés lehetővé teszi nem technikai felhasználók számára is, hogy egyszerű angol nyelven hozzanak létre automatizált üzleti teszteseteket, így nincs szükség semmilyen programozásra ahhoz, hogy azokat különböző operációs rendszerekhez, böngészőkhöz vagy okoseszközökhöz konfigurálják.Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg: Test Design: Lessons Learned and Practical Implications. DOI: 10.1109/IEEESTD.2008.4578383. .
Regressziós tesztelés Bizonyos szoftvertesztelési feladatok – például a kiterjedt, alacsony szintű interfészek regressziós tesztelése – manuálisan igen fáradságosak és időigényesek lehetnek. Emellett a kézi tesztelés nem mindig hatékony bizonyos típusú hibák felismerésében. A tesztautomatizálás lehetőséget kínál ezen tesztelési feladatok hatékony elvégzésére.
Miután az automatizált tesztek elkészültek, gyorsan és többször is lefuttathatók. Ez költséghatékony módszert jelenthet a hosszú karbantartási időszakkal rendelkező szoftvertermékek regressziós tesztelésére. Még az alkalmazás életciklusa során végzett kisebb javítások is okozhatnak hibákat olyan funkciókban, amelyek korábban megfelelően működtek.
API tesztelés
Roman Savenkov: How to Become a Software Tester. Roman Savenkov Consulting, 2008,
Hayes, Linda G., "Automated Testing Handbook", Software Testing Institute, 2nd Edition, March 2004 Kaner, Cem, "Architectures of Test Automation ", August 2000
Az API-tesztelést is széles körben alkalmazzák a szoftvertesztelők, mivel lehetővé teszi számukra, hogy a követelményeket a grafikus felhasználói felület (GUI) megvalósításától függetlenül ellenőrizzék – gyakran már a fejlesztés korai szakaszában –, valamint hogy maga a teszt is megfeleljen a tiszta kód elveinek, különösen az egyetlen felelősség elvének. Az API-tesztelés során közvetlenül az API-kat vizsgálják az integrációs tesztelés részeként annak érdekében, hogy megállapítsák, megfelelnek-e az elvárt funkcionalitási, megbízhatósági, teljesítménybeli és biztonsági követelményeknek. Testing APIs protects applications and reputations, by Amy Reichert, SearchSoftwareQuality March 2015Mivel az API-k nem rendelkeznek grafikus felhasználói felülettel, az API-tesztelést az üzenetszinten végzik.Cameron Philipp-Edmonds (2014. augusztus 19.): All About API Testing: An Interview with Jonathan Cooper. Stickyminds. Az API-tesztelés különösen kritikusnak számít, ha az API az alkalmazás logikájához való elsődleges hozzáférési felületként szolgál.Sean Kenefick (2014. január 7.): Produce Better Software by Using a Layered Testing Strategy. Gartner.
Grafikus felhasználói felület (GUI) tesztelése Számos tesztautomatizálási eszköz kínál rögzítési és visszajátszási funkciókat, amelyek lehetővé teszik a felhasználók számára, hogy interaktívan rögzítsék a felhasználói műveleteket, majd azokat tetszőleges alkalommal visszajátsszák, összehasonlítva a tényleges eredményeket a várt eredményekkel. Ennek a megközelítésnek az előnye, hogy kevés vagy semmilyen szoftverfejlesztési ismeretet nem igényel. Ez a módszer bármely grafikus felhasználói felülettel rendelkező alkalmazásra alkalmazható. Ugyanakkor az ilyen funkciókra való támaszkodás komoly megbízhatósági és karbantarthatósági problémákat vethet fel. Például egy gomb átnevezése vagy áthelyezése az ablak másik részére szükségessé teheti a teszt újrarögzítését. A rögzítés és visszajátszás módszere gyakran irreleváns műveleteket is rögzíthet, vagy egyes műveleteket hibásan rögzíthet.
Ennek a típusú eszköznek egy változata a weboldalak tesztelésére szolgál. Ebben az esetben az "interfész" maga a weboldal. Azonban az ilyen keretrendszerek teljesen eltérő technikákat alkalmaznak, mivel HTML-t jelenítenek meg, és DOM-eseményekre figyelnek az operációs rendszer eseményei helyett. Általában fej nélküli böngészőket (headless browsers) vagy a Selenium Web Driver alapú megoldásokat használnak erre a célra.Headless Testing with Browsers. Travis CI dokumentáció. Elérhető: https://docs.travis-ci.com/user/gui-and-headless-browsers/ (Letöltés ideje: 2024. április 28.)Headless Testing with PhantomJS. PhantomJS hivatalos dokumentáció. Elérhető: http://phantomjs.org/headless-testing.html (Letöltés ideje: 2024. április 28.)Automated User Interface Testing. Devbridge. Elérhető: https://www.devbridge.com/articles/automated-user-interface-testing/ (Letöltés ideje: 2024. április 28.)
Ennek a típusú tesztautomatizálási eszköznek egy másik változata a mobilalkalmazások tesztelésére szolgál. Ez különösen hasznos a mobiltelefonokon használt különböző méretek, felbontások és operációs rendszerek nagy száma miatt. Ebben az esetben egy keretrendszert alkalmaznak a műveletek mobil eszközön történő végrehajtására, valamint az ezek eredményeinek összegyűjtésére.
Egy másik változat a szkriptmentes tesztautomatizálás, amely nem használ rögzítési és visszajátszási funkciókat, hanem az alkalmazás egy modelljét hozza létre, majd lehetővé teszi a tesztelő számára, hogy egyszerűen tesztparaméterek és feltételek megadásával hozzon létre teszteseteket, anélkül hogy bármilyen programozási ismeretre szükség lenne.
Módszertanok
Tesztvezérelt fejlesztés A tesztautomatizálás – többnyire egységtesztelés alkalmazásával – kulcsfontosságú eleme az extrém programozásnak és az agilis szoftverfejlesztésnek, ahol tesztvezérelt fejlesztésként (TDD) vagy teszt-első fejlesztésként ismert. Az egységtesztek már a kód megírása előtt megfogalmazhatók a funkcionalitás definiálására.
Ezek az egységtesztek azonban a fejlesztés során folyamatosan fejlődnek és bővülnek, ahogy új problémák merülnek fel, és a kódot refaktorálják. Vodde, Bas; Koskela, Lasse (2007). "Learning Test-Driven Development by Counting Lines". IEEE Software. 24 (3): 74–79. doi:10.1109/ms.2007.80. S2CID 30671391.A kódot csak akkor tekintik késznek, ha minden megkövetelt funkcióra vonatkozó összes teszt sikeresen lefut. A tesztvezérelt fejlesztés hívei szerint ez a megközelítés megbízhatóbb és költséghatékonyabb szoftvert eredményez, mint a kézi felfedező teszteléssel ellenőrzött kód.
Megbízhatóbbnak tartják, mivel jobb a kódfedettség, és a tesztek folyamatosan futnak a fejlesztés során, nem pedig csak egyszer, a vízesésmodell végén. A fejlesztő azonnal felfedezi a hibákat a módosítások elvégzésekor, amikor még a legköltséghatékonyabb azok kijavítása. Végül az egységtesztelés biztonságosabbá teszi a kód refaktorálását: a kód egyszerűbb formába történő átalakítása – kevesebb kóddublikációval, de azonos működéssel – sokkal kisebb valószínűséggel vezet új hibák bevezetéséhez, ha a refaktorált kódrészletek egységtesztekkel vannak lefedve.
Folyamatos tesztelés
Roman Savenkov: How to Become a Software Tester. Roman Savenkov Consulting, 2008,
Hayes, Linda G., "Automated Testing Handbook", Software Testing Institute, 2nd Edition, March 2004 Kaner, Cem, "Architectures of Test Automation ", August 2000
A folyamatos tesztelés (Continuous Testing) azt a folyamatot jelenti, amikor az automatizált tesztek végrehajtása a szoftver szállítási folyamatának részeként történik, annak érdekében, hogy azonnali visszajelzést kapjunk a szoftverkiadás-jelölt üzleti kockázatairól.Adam Auerbach (2015. augusztus): Part of the Pipeline: Why Continuous Testing Is Essential. TechWell Insights.Cameron Philipp-Edmonds (2015. december): The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola. Stickyminds. A folyamatos tesztelés során a tesztelés terjedelme az alsó szintű követelmények vagy felhasználói történetek validálásától kezdve egészen a rendszerkövetelmények értékeléséig terjed, amelyek az általános üzleti célokhoz kapcsolódnak.Wayne Ariola és Cynthia Dunlop (2015. október): DevOps: Are You Pushing Bugs to Clients Faster. PNSQC.
Megfontolások
Tényezők, amelyeket figyelembe kell venni a tesztautomatizálás bevezetésére vonatkozó döntés meghozatalakor Hogy mit, mikor, vagy egyáltalán szükséges-e automatizálni, kulcsfontosságú döntések, amelyeket a tesztelő (vagy fejlesztő) csapatnak kell meghoznia.Brian Marick: When Should a Test Be Automated?. StickyMinds.com. Letöltve: 2009. augusztus 20.
Egy 52 gyakorlati és 26 tudományos forrást átfogó, többnézőpontos irodalmi áttekintés szerint öt fő tényezőt kell figyelembe venni a tesztautomatizálási döntések meghozatalakor: a tesztelendő rendszer (System Under Test – SUT), a tesztek típusai és száma, a teszteszköz, emberi és szervezeti szempontok, átfogó (keresztmetszeti) tényezők. A tanulmány szerint a leggyakrabban említett egyedi tényezők a regressziós tesztelés szükségessége, a gazdasági szempontok és a tesztelendő rendszer (SUT) érettsége voltak.Garousi, Vahid; Mäntylä, Mika V. (2016. augusztus 1.): When and what to automate in software testing? A multi-vocal literature review. *Information and Software Technology*, 76. évf., 92–117. o. DOI: 10.1016/j.infsof.2016.04.015.
Plató hatás Bár az automatizált tesztek újrafelhasználhatóságát nagyra értékelik a szoftverfejlesztő cégek, ez a tulajdonság hátrányként is értelmezhető. Ez vezet az úgynevezett "peszticid paradoxonhoz", amikor az ismételten végrehajtott tesztforgatókönyvek már nem képesek az adott keretrendszerükön túli hibák észlelésére.
Ilyen esetekben a kézi tesztelés jobb befektetés lehet.
Ez a kettősség ismét azt a következtetést támasztja alá, hogy a tesztautomatizálásról szóló döntést egyedileg, a projekt követelményeit és sajátosságait figyelembe véve kell meghozni.
Mit kell tesztelni A tesztelési eszközök segíthetnek olyan feladatok automatizálásában, mint például a termék telepítése, a tesztadatok létrehozása, a grafikus felhasználói felület kezelése, a hibák észlelése (például tesztorákulumokkal ellátott elemző vagy figyelő ügynökök segítségével), a hibák naplózása, stb. – anélkül, hogy feltétlenül végponttól végpontig történő tesztautomatizálást valósítanának meg.
A tesztautomatizálás tervezésekor figyelembe kell venni a leggyakoribb elvárások folyamatos teljesítését: A platform és az operációs rendszer függetlensége