Code Coverage Measurement and Fault Localization Approaches
Authors: Horváth Ferenc 
Published: May 2024

A kódlefedettség mérés fontos szerepet játszik az ipari gyakorlatban és a tudományos kutatásokban is. Számos terület függ a kódlefedettségtől, például a teszt esetek generálása, a tesztek priorizálása és a hibalokalizáció is. Ezek közül az értekezés két fő témára fókuszál, és a tézispontok ennek megfelelően két részre oszlanak. Az értekezés első részének 3. fejezete a Java kódlefedettség mérésére szolgáló eszközök (forráskód- és bájtkód alapú) által adott lefedettségi eredmények összehasonlításáról számol be. A kísérleteket 5 népszerű eszközzel, 8 nyílt forráskódú programon és metódus szinten végeztük. Megállapítottuk, hogy a lefedettségibeli különbségek 1,5% és 40% közöttiek és mindkét irányban fellépnek. A különbségeket részletesen is vizsgáltunk az egyes teszt esetek és programelemek szemszögéből. A kódlefedettség számos alkalmazásánál (például a hibakeresésnél) az ilyen szintű finom különbségek komoly zavart okozhatnak. Az egyes tesztesetek között akár 14%-os, a metódusok között pedig több mint 20%-os különbségeket mértünk. Szisztematikusan megvizsgáltuk a különbségek okait, és azt találtuk, hogy a különbségek egy része eszköz-specifikus, míg a többi a mérési megközelítésnek tulajdonítható. Az okok listája iránymutatásként szolgálhat a lefedettségi eszközök felhasználói számára, hogy miként kerüljék vagy hárítsák el a problémákat, ha bájtkód-alapú megközelítést alkalmaznak. Azt is megmértük, hogy a különbségek milyen hatással vannak a kódlefedettség-alapú teszt priorizálásra és azt találtuk, hogy a priorizált listák jelentősen eltértek egymástól. Az alacsony korreláció kockázatot jelent, mert megjósolhatatlan egy adott lefedettségi pontatlanság potenciális felerősödése egy adott alkalmazásban. Az automatikus hibakeresés eszköztámogatása korlátozott, mivel gyakran a legkorszerűbb algoritmusok sem nyújtanak hatékony segítséget a felhasználónak. Általában csupán a gyanús kódelemek rangsorolt listáját kínálják és a hiba jellemzően nem a rangsor elején található. A spektrumalapú hibalokalizáció (a kódlefedettséget és a tesztek eredményeit használja a rangsor kiszámításához) esetén a fejlesztőnek jellemzően több elemet is meg kell vizsgálnia, mielőtt megtalálja a valóban hibásat. Az értekezés második részének 4. fejezete egy olyan megközelítést javasol, amelyben a fejlesztő interakcióba léphet az algoritmussal azáltal, hogy visszajelzést ad a rangsorolt lista elemeiről. Ezzel kihasználjuk a felhasználó tudását a rangsorolt lista aktuális elemének környezetéről, így akár nagyobb kódegységek is átpozícionálhatóak. A megközelítést először szimulált felhasználókkal értékeltük ki, ahol kétféle “bizonytalanságot” modelleztünk: a tudást és magabiztosságot. Az eredmények még erős felhasználói bizonytalanság esetén is figyelemre méltó javulást mutattak a hibalokalizáció hatékonyságában. Ezután a megközelítés hatékonyságát valódi felhasználókkal is vizsgáltuk és az eredmények alapján ígéretesnek bizonyult a módszer. Spektrumalapú hibalokalizáció során a programelemeket egy gyanússági érték alapján rangsorolják, amely bár segítheti a programozót a hiba megtalálásában, de nem ad semmilyen információt a gyanús kódelemekről. Bár történtek kísérletek arra, hogy a folyamatba vezérlési- vagy adatfolyam alapú információkat építsenek be, ezek a skálázhatósági problémák miatt nem jártak sikerrel. Az értekezés második részének 5. fejezete a spektrumalapú hibalokalizáció kiegészítését javasolja függvényhívási láncokkal (azaz a hívási verem pillanatfelvételeivel), amelyeken először elvégezzük a hibalokalizációt, majd az eredményeket visszavezetjük a függvényekre. A valós programokkal végzett kísérletek azt mutatják, hogy a javasolt módszer hatékonysága jelentősen jobb a hagyományos függvényszintű megközelítéshez képest és a számítási többletköltség is kezelhető mértékű.