Teszlefedettség: A szoftverminőség értelmes mérőszámai

A szoftverfejlesztés dinamikus világában a minőség biztosítása elsődleges fontosságú. A tesztlefedettség, egy olyan mérőszám, amely a forráskód tesztelés során végrehajtott arányát jelzi, létfontosságú szerepet játszik e cél elérésében. Azonban a magas tesztlefedettségi százalékok puszta elérése nem elegendő. Értelmes mérőszámokra kell törekednünk, amelyek valóban tükrözik szoftverünk robusztusságát és megbízhatóságát. Ez a cikk a tesztlefedettség különböző típusait, azok előnyeit, korlátait és a legjobb gyakorlatokat vizsgálja, amelyekkel hatékonyan építhetünk magas minőségű szoftvereket.

Mi az a tesztlefedettség?

A tesztlefedettség számszerűsíti, hogy egy szoftvertesztelési folyamat milyen mértékben futtatja le a kódbázist. Lényegében azt méri, hogy a kód mekkora hányada kerül végrehajtásra a tesztek futtatása során. A tesztlefedettséget általában százalékban fejezik ki. A magasabb százalék általában alaposabb tesztelési folyamatra utal, de ahogy azt majd látni fogjuk, ez nem tökéletes mutatója a szoftverminőségnek.

Miért fontos a tesztlefedettség?

• Azonosítja a teszteletlen területeket: A tesztlefedettség rávilágít a kód azon részeire, amelyeket nem teszteltek, felfedve a minőségbiztosítási folyamat lehetséges vakfoltjait.
• Betekintést nyújt a tesztelés hatékonyságába: A lefedettségi jelentések elemzésével a fejlesztők felmérhetik tesztcsomagjaik hatékonyságát és azonosíthatják a fejlesztendő területeket.
• Támogatja a kockázatcsökkentést: Annak megértése, hogy a kód mely részei vannak jól tesztelve és melyek nem, lehetővé teszi a csapatok számára, hogy rangsorolják a tesztelési erőfeszítéseket és csökkentsék a lehetséges kockázatokat.
• Megkönnyíti a kódellenőrzéseket: A lefedettségi jelentések értékes eszközként használhatók a kódellenőrzések során, segítve az ellenőröket, hogy az alacsony tesztlefedettségű területekre összpontosítsanak.
• Jobb kódtervezésre ösztönöz: Az a szükséglet, hogy a kód minden aspektusát lefedő teszteket írjunk, modulárisabb, tesztelhetőbb és karbantarthatóbb tervekhez vezethet.

A tesztlefedettség típusai

A tesztlefedettségi metrikák számos típusa különböző nézőpontokat kínál a tesztelés teljességéről. Íme néhány a leggyakoribbak közül:

1. Utasításlefedettség (Statement Coverage)

Definíció: Az utasításlefedettség a kódban lévő végrehajtható utasítások azon százalékát méri, amelyeket a tesztcsomag végrehajtott.

Példa:

            
function calculateDiscount(price, hasCoupon) {
  let discount = 0;
  if (hasCoupon) {
    discount = price * 0.1;
  }
  return price - discount;
}

            

              
                Copy
              
            
          

A 100%-os utasításlefedettség eléréséhez legalább egy tesztesetre van szükségünk, amely végrehajtja a `calculateDiscount` függvény minden kódsorát. Például:

• 1. teszteset: `calculateDiscount(100, true)` (végrehajtja az összes utasítást)

Korlátok: Az utasításlefedettség egy alapvető metrika, amely nem garantálja az alapos tesztelést. Nem értékeli a döntéshozatali logikát, és nem kezeli hatékonyan a különböző végrehajtási útvonalakat. Egy tesztcsomag elérheti a 100%-os utasításlefedettséget, miközben fontos szélsőséges eseteket vagy logikai hibákat kihagy.

2. Áglefedettség (Branch Coverage / Döntési Lefedettség)

Definíció: Az áglefedettség a kódban lévő döntési ágak (pl. `if` utasítások, `switch` utasítások) azon százalékát méri, amelyeket a tesztcsomag végrehajtott. Biztosítja, hogy minden feltétel `igaz` és `hamis` kimenetelét is teszteljék.

Példa (ugyanazt a függvényt használva, mint fent):

            
function calculateDiscount(price, hasCoupon) {
  let discount = 0;
  if (hasCoupon) {
    discount = price * 0.1;
  }
  return price - discount;
}

            

              
                Copy
              
            
          

A 100%-os áglefedettség eléréséhez két tesztesetre van szükségünk:

• 1. teszteset: `calculateDiscount(100, true)` (teszteli az `if` blokkot)
• 2. teszteset: `calculateDiscount(100, false)` (teszteli az `else` vagy alapértelmezett útvonalat)

Korlátok: Az áglefedettség robusztusabb, mint az utasításlefedettség, de még mindig nem fedi le az összes lehetséges forgatókönyvet. Nem veszi figyelembe a több záradékot tartalmazó feltételeket vagy a feltételek kiértékelésének sorrendjét.

3. Feltétellefedettség (Condition Coverage)

Definíció: A feltétellefedettség egy feltételen belüli logikai al-kifejezések azon százalékát méri, amelyeket legalább egyszer `igaz` és `hamis` értékre is kiértékeltek.

Példa:

            
function processOrder(isVIP, hasLoyaltyPoints) {
  if (isVIP && hasLoyaltyPoints) {
    // Speciális kedvezmény alkalmazása
  }
  // ...
}

            

              
                Copy
              
            
          

A 100%-os feltétellefedettség eléréséhez a következő tesztesetekre van szükségünk:

• `isVIP = true`, `hasLoyaltyPoints = true`
• `isVIP = false`, `hasLoyaltyPoints = false`

Korlátok: Bár a feltétellefedettség egy összetett logikai kifejezés egyes részeit célozza meg, előfordulhat, hogy nem fedi le a feltételek összes lehetséges kombinációját. Például nem biztosítja, hogy mind az `isVIP = true, hasLoyaltyPoints = false`, mind az `isVIP = false, hasLoyaltyPoints = true` forgatókönyvet egymástól függetlenül teszteljék. Ez vezet a következő lefedettségi típushoz:

4. Többszörös feltétellefedettség (Multiple Condition Coverage)

Definíció: Ez azt méri, hogy egy döntésen belül a feltételek minden lehetséges kombinációját tesztelték-e.

Példa: A fenti `processOrder` függvény használatával. A 100%-os többszörös feltétellefedettség eléréséhez a következőkre van szükség:

• `isVIP = true`, `hasLoyaltyPoints = true`
• `isVIP = false`, `hasLoyaltyPoints = false`
• `isVIP = true`, `hasLoyaltyPoints = false`
• `isVIP = false`, `hasLoyaltyPoints = true`

Korlátok: Ahogy a feltételek száma növekszik, a szükséges tesztesetek száma exponenciálisan nő. Összetett kifejezések esetén a 100%-os lefedettség elérése nem praktikus lehet.

5. Útvonallefedettség (Path Coverage)

Definíció: Az útvonallefedettség a kódon keresztüli független végrehajtási útvonalak azon százalékát méri, amelyeket a tesztcsomag végrehajtott. Minden lehetséges útvonalat a függvény vagy program belépési pontjától a kilépési pontjáig útvonalnak tekintünk.

Példa (módosított `calculateDiscount` függvény):

            
function calculateDiscount(price, hasCoupon, isEmployee) {
  let discount = 0;
  if (hasCoupon) {
    discount = price * 0.1;
  } else if (isEmployee) {
    discount = price * 0.05;
  }
  return price - discount;
}

            

              
                Copy
              
            
          

A 100%-os útvonallefedettség eléréséhez a következő tesztesetekre van szükségünk:

• 1. teszteset: `calculateDiscount(100, true, true)` (az első `if` blokkot hajtja végre)
• 2. teszteset: `calculateDiscount(100, false, true)` (az `else if` blokkot hajtja végre)
• 3. teszteset: `calculateDiscount(100, false, false)` (az alapértelmezett útvonalat hajtja végre)

Korlátok: Az útvonallefedettség a legátfogóbb strukturális lefedettségi metrika, de egyben a legnehezebben is elérhető. Az útvonalak száma exponenciálisan nőhet a kód bonyolultságával, így a gyakorlatban megvalósíthatatlanná teszi az összes lehetséges útvonal tesztelését. Általában túl költségesnek tartják a valós alkalmazásokhoz.

6. Függvénylefedettség (Function Coverage)

Definíció: A függvénylefedettség a kódban lévő függvények azon százalékát méri, amelyeket legalább egyszer meghívtak a tesztelés során.

Példa:

            
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

// Test Suite
add(5, 3); // Csak az add függvényt hívják meg

            

              
                Copy
              
            
          

Ebben a példában a függvénylefedettség 50% lenne, mivel a két függvényből csak egyet hívtak meg.

Korlátok: A függvénylefedettség, az utasításlefedettséghez hasonlóan, egy viszonylag alapvető metrika. Azt jelzi, hogy egy függvényt meghívtak-e, de nem ad információt a függvény viselkedéséről vagy az argumentumként átadott értékekről. Gyakran kiindulópontként használják, de a teljesebb kép érdekében más lefedettségi metrikákkal kell kombinálni.

7. Sorlefedettség (Line Coverage)

Definíció: A sorlefedettség nagyon hasonló az utasításlefedettséghez, de a fizikai kódsorokra összpontosít. Azt számolja, hogy hány kódsort hajtottak végre a tesztek során.

Korlátok: Ugyanazokkal a korlátokkal rendelkezik, mint az utasításlefedettség. Nem ellenőrzi a logikát, a döntési pontokat vagy a lehetséges szélsőséges eseteket.

8. Belépési/Kilépési pont lefedettség (Entry/Exit Point Coverage)

Definíció: Ez azt méri, hogy egy függvény, komponens vagy rendszer minden lehetséges belépési és kilépési pontját legalább egyszer tesztelték-e. A belépési/kilépési pontok a rendszer állapotától függően eltérőek lehetnek.

Korlátok: Bár biztosítja, hogy a függvényeket meghívják és visszatérnek, nem mond semmit a belső logikáról vagy a szélsőséges esetekről.

A strukturális lefedettségen túl: Adatfolyam- és mutációs tesztelés

Bár a fentiek strukturális lefedettségi metrikák, vannak más fontos típusok is. Ezeket a fejlett technikákat gyakran figyelmen kívül hagyják, pedig létfontosságúak az átfogó teszteléshez.

1. Adatfolyam-lefedettség (Data Flow Coverage)

Definíció: Az adatfolyam-lefedettség az adatfolyamok követésére összpontosít a kódon keresztül. Biztosítja, hogy a változók definiálva, használva és potenciálisan újra definiálva vagy definiálatlanul legyenek a program különböző pontjain. Az adatelemek és a vezérlési folyamat közötti kölcsönhatást vizsgálja.

Típusok:

• Definíció-Használat (DU) Lefedettség: Biztosítja, hogy minden változódefinícióhoz tartozó összes lehetséges használatot lefedjék a tesztesetek.
• Minden-Definíció Lefedettség: Biztosítja, hogy egy változó minden definíciója lefedett legyen.
• Minden-Használat Lefedettség: Biztosítja, hogy egy változó minden használata lefedett legyen.

Példa:

            
function calculateTotal(price, quantity) {
  let total = price * quantity; // 'total' definíciója
  let tax = total * 0.08;        // 'total' használata
  return total + tax;              // 'total' használata
}

            

              
                Copy
              
            
          

Az adatfolyam-lefedettség olyan teszteseteket igényelne, amelyek biztosítják, hogy a `total` változót helyesen számítják ki és használják fel a későbbi számításokban.

Korlátok: Az adatfolyam-lefedettség implementálása összetett lehet, mivel a kód adatfüggőségeinek kifinomult elemzését igényli. Általában számításigényesebb, mint a strukturális lefedettségi metrikák.

2. Mutációs tesztelés (Mutation Testing)

Definíció: A mutációs tesztelés során apró, mesterséges hibákat (mutációkat) visznek be a forráskódba, majd lefuttatják a tesztcsomagot, hogy kiderüljön, képes-e észlelni ezeket a hibákat. A cél a tesztcsomag hatékonyságának felmérése a valós hibák elkapásában.

Folyamat:

1. Mutánsok generálása: Módosított verziókat hoznak létre a kódból mutációk bevezetésével, például operátorok megváltoztatásával (`+`-ról `-`-ra), feltételek megfordításával (`<`-ról `>=`-re) vagy konstansok cseréjével.
2. Tesztek futtatása: Végrehajtják a tesztcsomagot minden mutánson.
3. Eredmények elemzése:
   • Megsemmisített mutáns: Ha egy teszteset megbukik egy mutánssal szemben, a mutáns „megsemmisítettnek” minősül, jelezve, hogy a tesztcsomag észlelte a hibát.
   • Túlélő mutáns: Ha minden teszteset sikeresen lefut egy mutánssal szemben, a mutáns „túlélőnek” minősül, ami a tesztcsomag gyengeségére utal.
4. Tesztek javítása: Elemzik a túlélő mutánsokat, és új teszteseteket adnak hozzá vagy módosítják a meglévőket, hogy azok észleljék ezeket a hibákat.

Példa:

            
function add(a, b) {
  return a + b;
}

            

              
                Copy
              
            
          

Egy mutáció megváltoztathatja a `+` operátort `-`-ra:

            
function add(a, b) {
  return a - b; // Mutáns
}

            

              
                Copy
              
            
          

Ha a tesztcsomagnak nincs olyan tesztesete, amely kifejezetten ellenőrzi két szám összeadását és a helyes eredményt, a mutáns túléli, ami egy hiányosságot tár fel a tesztlefedettségben.

Mutációs pontszám: A mutációs pontszám a tesztcsomag által megsemmisített mutánsok százalékos aránya. A magasabb mutációs pontszám hatékonyabb tesztcsomagra utal.

Korlátok: A mutációs tesztelés számításigényes, mivel a tesztcsomagot számos mutánson kell lefuttatni. Azonban a jobb tesztminőség és a hibák felderítése terén nyújtott előnyök gyakran felülmúlják a költségeket.

A kizárólag a lefedettségi százalékra való összpontosítás buktatói

Bár a tesztlefedettség értékes, kulcsfontosságú, hogy ne kezeljük a szoftverminőség egyetlen mércéjeként. Íme, miért:

• A lefedettség nem garantálja a minőséget: Egy tesztcsomag elérheti a 100%-os utasításlefedettséget, miközben mégis kihagy kritikus hibákat. Lehet, hogy a tesztek nem a helyes viselkedést állítják, vagy nem fedik le a szélsőséges eseteket és a határértékeket.
• Hamis biztonságérzet: A magas lefedettségi százalékok hamis biztonságérzetbe ringathatják a fejlesztőket, ami miatt figyelmen kívül hagyhatják a potenciális kockázatokat.
• Értelmetlen tesztek írására ösztönöz: Ha a lefedettség az elsődleges cél, a fejlesztők olyan teszteket írhatnak, amelyek csupán végrehajtják a kódot anélkül, hogy ténylegesen ellenőriznék annak helyességét. Ezek a „töltelék” tesztek kevés értéket adnak, sőt elfedhetik a valódi problémákat.
• Figyelmen kívül hagyja a tesztek minőségét: A lefedettségi metrikák nem értékelik maguknak a teszteknek a minőségét. Egy rosszul megtervezett tesztcsomagnak lehet magas a lefedettsége, de mégis hatástalan lehet a hibák felderítésében.
• Nehéz lehet elérni régi rendszereknél: A magas lefedettség elérése régi rendszereken rendkívül időigényes és költséges lehet. Újraírásra lehet szükség, ami új kockázatokat vet fel.

A legjobb gyakorlatok az értelmes tesztlefedettséghez

Ahhoz, hogy a tesztlefedettség valóban értékes mérőszám legyen, kövesse ezeket a legjobb gyakorlatokat:

1. Priorizálja a kritikus kódútvonalakat

Összpontosítsa tesztelési erőfeszítéseit a legkritikusabb kódútvonalakra, például a biztonsággal, teljesítménnyel vagy alapvető funkcionalitással kapcsolatosakra. Használjon kockázatelemzést azon területek azonosítására, amelyek a legvalószínűbben okoznak problémákat, és ennek megfelelően rangsorolja a tesztelésüket.

Példa: Egy e-kereskedelmi alkalmazás esetében priorizálja a fizetési folyamat, a fizetési kapu integrációjának és a felhasználói hitelesítési moduloknak a tesztelését.

2. Írjon értelmes állításokat (assertion)

Győződjön meg róla, hogy a tesztjei nemcsak végrehajtják a kódot, hanem ellenőrzik is, hogy az helyesen viselkedik-e. Használjon állításokat az elvárt eredmények ellenőrzésére és annak biztosítására, hogy a rendszer a helyes állapotban van minden teszteset után.

Példa: Ahelyett, hogy egyszerűen meghívna egy függvényt, amely kedvezményt számol, állítsa, hogy a visszaadott kedvezmény értéke helyes a bemeneti paraméterek alapján.

3. Fedje le a szélsőséges eseteket és a határértékeket

Fordítson különös figyelmet a szélsőséges esetekre és a határértékekre, amelyek gyakran a hibák forrásai. Teszteljen érvénytelen bemenetekkel, extrém értékekkel és váratlan forgatókönyvekkel, hogy feltárja a kód potenciális gyengeségeit.

Példa: Amikor egy felhasználói bevitelt kezelő függvényt tesztel, teszteljen üres karakterláncokkal, nagyon hosszú karakterláncokkal és speciális karaktereket tartalmazó karakterláncokkal.

4. Használjon többféle lefedettségi metrikát

Ne támaszkodjon egyetlen lefedettségi metrikára. Használjon metrikák kombinációját, például utasításlefedettséget, áglefedettséget és adatfolyam-lefedettséget, hogy átfogóbb képet kapjon a tesztelési erőfeszítésekről.

5. Integrálja a lefedettségelemzést a fejlesztési munkafolyamatba

Integrálja a lefedettségelemzést a fejlesztési munkafolyamatba azáltal, hogy a lefedettségi jelentéseket automatikusan futtatja a build folyamat részeként. Ez lehetővé teszi a fejlesztők számára, hogy gyorsan azonosítsák az alacsony lefedettségű területeket és proaktívan kezeljék azokat.

6. Használjon kódellenőrzéseket a tesztminőség javítására

Használjon kódellenőrzéseket a tesztcsomag minőségének értékelésére. Az ellenőröknek a tesztek érthetőségére, helyességére és teljességére, valamint a lefedettségi metrikákra kell összpontosítaniuk.

7. Fontolja meg a tesztvezérelt fejlesztést (TDD)

A tesztvezérelt fejlesztés (Test-Driven Development, TDD) egy olyan fejlesztési megközelítés, ahol a teszteket a kód megírása előtt írja meg. Ez tesztelhetőbb kódhoz és jobb lefedettséghez vezethet, mivel a tesztek vezérlik a szoftver tervezését.

8. Alkalmazza a viselkedésvezérelt fejlesztést (BDD)

A viselkedésvezérelt fejlesztés (Behavior-Driven Development, BDD) kiterjeszti a TDD-t azáltal, hogy a rendszer viselkedésének egyszerű nyelvi leírásait használja a tesztek alapjául. Ez olvashatóbbá és érthetőbbé teszi a teszteket minden érdekelt fél számára, beleértve a nem műszaki felhasználókat is. A BDD elősegíti a tiszta kommunikációt és a követelmények közös megértését, ami hatékonyabb teszteléshez vezet.

9. Priorizálja az integrációs és végponttól-végpontig teszteket

Bár az egységtesztek fontosak, ne hanyagolja el az integrációs és végponttól-végpontig teszteket, amelyek a különböző komponensek közötti interakciót és a teljes rendszer viselkedését ellenőrzik. Ezek a tesztek kulcsfontosságúak olyan hibák felderítésében, amelyek az egység szintjén esetleg nem nyilvánvalóak.

Példa: Egy integrációs teszt ellenőrizheti, hogy a felhasználói hitelesítési modul helyesen lép-e kapcsolatba az adatbázissal a felhasználói hitelesítő adatok lekéréséhez.

10. Ne féljen újraírni a tesztelhetetlen kódot

Ha olyan kóddal találkozik, amelyet nehéz vagy lehetetlen tesztelni, ne féljen újraírni (refaktorálni), hogy tesztelhetőbbé tegye. Ez magában foglalhatja a nagy függvények kisebb, modulárisabb egységekre bontását, vagy a függőséginjektálás használatát a komponensek szétválasztására.

11. Folyamatosan javítsa a tesztcsomagját

A tesztlefedettség nem egyszeri erőfeszítés. Folyamatosan vizsgálja felül és javítsa tesztcsomagját, ahogy a kódbázis fejlődik. Adjon hozzá új teszteket az új funkciók és hibajavítások lefedésére, és írja újra a meglévő teszteket azok érthetőségének és hatékonyságának javítása érdekében.

12. Egyensúlyozza a lefedettséget más minőségi metrikákkal

A tesztlefedettség csak egy darabja a kirakósnak. Vegyen figyelembe más minőségi metrikákat is, mint például a hibasűrűség, az ügyfél-elégedettség és a teljesítmény, hogy holisztikusabb képet kapjon a szoftverminőségről.

Globális perspektívák a tesztlefedettségről

Bár a tesztlefedettség alapelvei univerzálisak, alkalmazásuk régiónként és fejlesztési kultúránként eltérő lehet.

• Agilis módszertanok elterjedése: Az agilis módszertanokat alkalmazó, világszerte népszerű csapatok hajlamosak hangsúlyt fektetni az automatizált tesztelésre és a folyamatos integrációra, ami a tesztlefedettségi metrikák nagyobb mértékű használatához vezet.
• Szabályozási követelmények: Néhány iparágban, mint például az egészségügy és a pénzügy, szigorú szabályozási követelmények vonatkoznak a szoftverminőségre és a tesztelésre. Ezek a szabályozások gyakran előírnak bizonyos szintű tesztlefedettséget. Például Európában az orvostechnikai eszközök szoftverének meg kell felelnie az IEC 62304 szabványnak, amely hangsúlyozza az alapos tesztelést és dokumentációt.
• Nyílt forráskódú vs. zárt forráskódú szoftverek: A nyílt forráskódú projektek gyakran nagymértékben támaszkodnak a közösségi hozzájárulásokra és az automatizált tesztelésre a kódminőség biztosítása érdekében. A tesztlefedettségi metrikák gyakran nyilvánosan láthatók, ösztönözve a hozzájárulókat a tesztcsomag javítására.
• Globalizáció és lokalizáció: Amikor globális közönségnek fejleszt szoftvert, kulcsfontosságú a lokalizációs problémák, például a dátum- és számformátumok, pénznemszimbólumok és karakterkódolás tesztelése. Ezeket a teszteket szintén be kell vonni a lefedettségelemzésbe.

Eszközök a tesztlefedettség mérésére

Számos eszköz áll rendelkezésre a tesztlefedettség mérésére különböző programozási nyelvekben és környezetekben. Néhány népszerű opció:

• JaCoCo (Java Code Coverage): Széles körben használt nyílt forráskódú lefedettségi eszköz Java alkalmazásokhoz.
• Istanbul (JavaScript): Népszerű lefedettségi eszköz JavaScript kódhoz, gyakran használják olyan keretrendszerekkel, mint a Mocha és a Jest.
• Coverage.py (Python): Egy Python könyvtár a kódlefedettség mérésére.
• gcov (GCC Coverage): A GCC fordítóba integrált lefedettségi eszköz C és C++ kódhoz.
• Cobertura: Egy másik népszerű nyílt forráskódú Java lefedettségi eszköz.
• SonarQube: Platform a kódminőség folyamatos ellenőrzésére, beleértve a tesztlefedettség elemzését is. Különböző lefedettségi eszközökkel integrálható és átfogó jelentéseket nyújt.

Összegzés

A tesztlefedettség értékes mérőszám a szoftvertesztelés alaposságának felmérésére, de nem lehet a szoftverminőség egyetlen meghatározója. A lefedettség különböző típusainak, korlátainak és hatékony kihasználásuk legjobb gyakorlatainak megértésével a fejlesztőcsapatok robusztusabb és megbízhatóbb szoftvereket hozhatnak létre. Ne felejtse el rangsorolni a kritikus kódútvonalakat, értelmes állításokat írni, lefedni a szélsőséges eseteket, és folyamatosan javítani a tesztcsomagját, hogy a lefedettségi metrikák valóban tükrözzék a szoftver minőségét. Az egyszerű lefedettségi százalékokon túllépve, az adatfolyam- és mutációs tesztelés alkalmazása jelentősen javíthatja tesztelési stratégiáit. Végül a cél olyan szoftver építése, amely megfelel a felhasználók igényeinek világszerte, és pozitív élményt nyújt, függetlenül azok tartózkodási helyétől vagy hátterétől.