[C++] Szárnyak – Legyen az egységtesztek intelligensen és automatikusan generálható

Az egységtesztelés nagyon hatékony eszköz a szoftver minőségének biztosítására, akár a tesztelés korai beavatkozásának fogalmából, akár az egységtesztek olyan jellemzőiről, amelyeket nagy sebességgel ellenőrizhetünk anélkül, hogy az UI befolyásolná, így az ipar által javasolt tesztalapú fejlesztés, a teszt illesztő, inkább az egységteszt illedőzserre utal. Azonban az általános fejlesztőcsapat továbbra is ritkán hajt végre egységteszteket rendszerszinten, és az alkalmazásszoftverek tesztelését inkább profi tesztcsapatok végzik fekete doboz tesztek elvégzéséhez. Az egységtesztelés legnagyobb nehézsége nem az, hogy a bemenet és kimenet nem határozható meg, hiszen már a modulfejlesztési szakaszban meg van határozva, hanem hogy az egységtesztesetek írása rengeteg fejlesztői munkaórát igényel, és a vonatkozó statisztikák szerint az egységteszt esetek ideje még messze meghaladja a függvény fejlesztési idejét. Íme néhány leggyakoribb ok, amiért a fejlesztés nem ír egységteszteket:

●A követelmények mindig végtelenek, a következő szakaszban még mindig vannak funkcionális követelmények, és nincs idő az egység kitöltésére

●Túl sok egységteszt van, amit kiegészíthetünk, és nincs mód a kezdésre, ezért szubjektíven ellenállok.

● Az egységtesztek írása nehéz. Egyrészt az lehet az oka, hogy a funkcionális függvény megvalósítása nem elég ésszerű, másrészt pedig nincsenek (vagy ismeretlen) hasznos egységteszt keretrendszerek és mock keretrendszerek.

● Az egységtesztek nem tartoznak a munkaterhelésbe.

Másodszor, a funkcionális követelmények továbbra is instabilak, és az egységtesztek írásának költséghatékonysága nem magas. Más szóval, ha holnap változnak a követelmények, nemcsak a funkcionális kódot szökik ki, hanem az egységteszteket is. Ha nem írsz egységteszteket, akkor ez a munka része nem lesz hiábavaló.

Valójában a fentiek gyökere az, hogy az egységteszt írása túl időigényes, ami végül a tesztvezérelt motor teljesítményvesztéséhez vezet, így a tesztvezérelt fejlesztés gyönyörű víziója megtorkol a valós helyzetben, mert túl nehéz és drága a motort ehhez a meghajtóhoz építeni. A piacon lévő különféle "x" egységek és egységtesztelési keretrendszerek csak a tesztvezérelt külső keretek generálásának problémáját oldják meg, anélkül, hogy bármilyen felhasználási eset logikai és mély programtudáson alapuló adatgeneráló képességeket nem kínálnának. Ezért a fejlesztők ellenállóvá teszik különböző fejlesztésekkel kapcsolatos helyzetekben. A Wings megjelenése (jelenleg a C számára) megoldja az egyik legnagyobb problémát a programozók számára, és alapvetően megváltoztathatja az egységtesztelés jelenlegi helyzetét, ami hatékonyan enyhíti a rendszerszintű fekete doboz tesztelés és az automatizált tesztelés nyomását, amely hatalmas emberi erőforrásokra épül.

A korlátozó teszteseteket automatikusan generálják a programok, és a legkritikusabb mögöttes technológia a komplex paraméterelemzés technológia. Vagyis tetszőlegesen definiálhatja a fordító szintjén a beépített rekurzív elemzést tetszőlegesen összetett típusok esetén. E kritikus technológia áttörése nélkül az automatikus teszteset-generáló rendszer vagy kereskedelmileg képtelen lenne, vagy fejlődött volna, hogy nagyon alacsony hatékonyságú, megfelelőségi tesztadatokat állítson. Például a híres fuzzáló eszköz, az American Fuzzy Lop nem tudja azonosítani, milyen típusú struktúrát igényel a felhasználó programja, és a keresési algoritmust a legkülső réteg alapján kell fejlesztenie. A program jellemzői, hogy az interfész szintjén lévő bemenet és a belső modul adatkövetelményei messze vannak, és a külső adatokat általában rétegenként, összetett transzformációban alakítják át, hogy a belső modul által igényelt adatszerkezeti típussá váljon, így a külső rétegből történő kutatáshoz szükséges számítási és idő mennyisége elképzelhetetlen lesz. Az amerikai Fuzzy Lop alapján, hogy legális SQL utasítást generálhassunk, a program belső modulját napok alatt kell felfedezni, nem perceket vagy órákat. Egy másik korlát, hogy az egyes programok által átvehető bemenetek gondosan strukturáltak és összeállítottak adatok, sok szabálysal, és nagyon irreális, rendkívül időigényes ezeknek az adatoknak véletlenszerű + explorációs módszerekkel generálása. Ezért nem lehetséges automatikusan generált felhasználási eseteket generálni a fekete dobozból és a legkülső bemenet mellett.

Ha a felhasználási eset-vezérelt rendszer a szoftver belső szerkezetének elemzéséből származik, akkor szükséges mélyreható megértést a szoftver fordítási struktúrájáról. Egy életképes teszteset-generáló rendszernek a program közepén (kulcsbelépési ponton) kell alapulnia, mint a legmegfelelőbb tesztbelépési pontnak. Ezeknek a moduloknak a bemenetei a homályos bemeneteket rendkívül strukturált paraméterekké alakították. Amíg ezek a bonyolult struktúrák azonosíthatók, a bonyolult adattípusok lépésről lépésre egyszerű adattípusokká bonthatók, és a paraméterépítés egyszerre elkészül, így automatikusan befejezhető a meghajtó használati esetek generálása.

A modulalapú tesztelés, amely hagyományos egységtesztelésként sorolható, a legjobb módja a hibák megtalálásának és ellenőrzésének az R&D fázisban. Azonban az egységtesztelés korlátai miatt sok versenyzőt kell fejleszteni, és az iparági népszerűsítés és alkalmazása jelentősen korlátozott. Természetesen az egységtesztek a rendszer integrálása után is végrehajthatók, hogy elkerüljék a virtuális stub programok építését.

A Nebulas Testing Wings terméke, amelyet néhány nappal ezelőtt mutattak be először a világon, egy intelligens és teljesen automatizált egységteszt esetgeneráló rendszer, amely tanulmányozta és megoldotta a következő nehézségeket, és most megosztja Önnel.

(1) Programparaméterek mélyreható elemzése

A Wings a fordító mögöttes technológiáját használja arra, hogy modulobjektumokat formáljon a bemeneti forrásfájl alapján a függvény szerint. Az objektum tartalmazza a függvény bemeneti paramétereit, a visszaadó értéktípust és egyéb információkat, amelyeket a meghajtó függvénymodul és a teszteset modul használhat. Minden fájl egy egység, amely alaposan elemezi az egyes függvények paramétereit, és pontos elemzést és felbontást érhet el beágyazott típusok, összetett típusok stb., rétegenként magyarázza a komplex típusokat alap adattípusokként, és létrehozhat egy paraméterszerkezeti leírásfájlt (PSD).

(2) Funkciómeghajtó automatikus modulgenerálása

A PSD fájl formátuminformációi szerint a tesztelt forrásprogram összes driver-függvénye automatikusan generálódik, és az egységtesztelési folyamat már nem támaszkodik arra, hogy a fejlesztők kézzel írják a tesztfunkciókat, csak a generált illezőprogram-függvényeket és a tesztelt forrásfájlokat kell összefordítani, így a teszteredmények végrehajthatók és a teszteredmények is megtekinthetők. A tesztillesztő automatikusan generálja a programot a PSD leírása alapján, teljesen automatikusan összeállítja az összes paramétert és szükséges globális változót, amelyek a teszt alatt álló tesztet hajtják, és képes strukturált tesztmeghajtót generálni a komplex változók hierarchiája szerint, ami sok időt takaríthat meg az egységteszt esetek írásában.

(3) A tesztadatok automatikus generálása és kezelése

Automatikusan tesztadatokat generálnak, amelyek megfelelnek a tesztfüggvény által kinyert információknak, és az adatokat egy JSON fájlban tárolják, amely egy bizonyos hierarchikus logikai viszonyt tartalmaz. Az adatok és az adattípus a felbontás és bővítés után egymásnak felelnek meg. A felhasználók önkényesen marginalizálhatják ezeket az adatokat az üzleti követelmények szerint, és JSON fájlokat használnak arra, hogy strukturált és hierarchikus módon jelenítsék meg azokat, ami nagyon világos. A tesztadatok tartalmazzák a globális változók értékeit, valamint azokat a paraméterértékeket, amikor a teszt alatt álló függvényt hívják.

A Wings egységtesztelési módszert kínál az illesztőfunkciók automatikus generálásához, amely főként a következő lépéseket foglalja magában:

1. ábra: Egységteszt-alapú építési folyamat

A tesztelt program szerkezeti információi főként a globális változókat és a függvényinformációkat tartalmazzák a programban, míg a függvényinformációk főként a függvény paramétereinek számát, paramétertípusait és visszatérési értéktípusait foglalják magában. A legfontosabb, hogy egyes összetett típusok szimbólum- és típusinformációit kinyerjük, és rétegenként elemezzük azokat alapvető adattípusokba, hogy befejezzük a globális változók és függvényparaméterek felépítését.

A változótípusokat általában alapvető típusokra, konstrukció típusokra, mutató típusokra és null típusokra osztják. A Wings az alapul szolgáló fordítási technológiát használja különböző változótípusok kezelésére különböző módokon keresztül.

(1) Alapvető típusok, mint például az aláíratlan int u_int=20, a Wings a változó nevét u_int-re, az adattípust pedig unsigned int-re értelmezi.

(2) Az építési típusok, az építési típusok nagyjából tömbökre, szerkezetekre, közös és felsorolási típusokra vannak osztva.

● Tömbtípus, például intarray[2][3], tömb név tömb, típus int és 2D tömb hossza, viselkedés 2, oszlop 3.

●Szerkezettípus, szerkezetek esetén tömbök, szerkezeti összekapcsolt listák stb., különböző jelölőket osztanak szét.

(3) Mutatótípus, pl. int **ptr = 0; , az int típusú 2. szintű mutatóként értelmezi az int.

(4) Null típus, amelyet NULL-nak oldunk.

(5) A rendszertípusok, mint például Fájl, size_t stb., rendszertípusokként vannak jelölve, amelyeket a sablonhoz adnak hozzá, majd a felhasználó rendeli hozzá.

(6) Függvénymutató típus, elemzed a függvény visszatérési értéktípusát, paramétertípusát és paramétereinek számát

A tesztelt forrásprogram minden fordítási egységéhez a parsírozott függvény információi a megfelelő PSD struktúrában tárolódnak, és a következő forráskód példákat írják le:

   

A fenti programban void StructTypeTest3(myy_struct mm_struct[2])A mentett PSD szerkezete a következő:

A PSD fájlban minden csomópont jelentése a következő:

●StructTypeTest3 a függvény nevét, a parmType0 a paramétertípust, a parmNum pedig a paraméterek számát

●mm_struct a függvényparaméter szimbólumát jelöli, a baseType1 a típusok osztályozását (alapadattípus, konstrukció típus, mutatótípus, null típus) jelöli, a type pedig konkrét típusokat, beleértve az int, char, short, long, double, float, bool, valamint ezek a jel nélküli típusok és más alapvető típusok, valamint vannak speciális típusok, például: ZOA_FUN type a függvény típust képviseli, A StructureOrClassType a struct típust stb., a név pedig a struct, union és enum típus nevét jelöli

●i_int az alaptípust jelöli, amely a legkisebb hozzárendelési egység

●array_one a tömbtípust jelöli, a SorMéret a tömb hosszát, és a tömb felosztható egydimenziós tömbökre, kétdimenziós tömbekre stb

● a pont a mutató típusát jelöli, a mutató első szintű mutatóra, másodszintű mutatóra osztott stb., az általános mutatót pedig függvényparaméterként használják tömbként, így az alapvető mutatótípusnál a dinamikus allokációs tömb módszert használják az értékek hozzárendelésére, és a felhasználó a szükséges értékfájlt módosíthatja.

● w a bitmező típusát, a bitfileld pedig a számjegyek számát jelöli

●functionPtr a függvénymutató típust jelöli, amely elemzi a paramétertípust, a paraméterek számát és a visszaadó értékadatokat

●Dem a konzorcium típus rövidítése

● dy az enum típust, az érték pedig az enum típus értékét jelöli

●file a struktúra típusát jelöli, SystemVar pedig azt jelenti, hogy ez a változó a rendszer fejlécéjében lévő változóhoz tartozik, ehhez a típushoz a Wings sablonváltozókat ad hozzá a sablonkönyvtárhoz, a felhasználók speciális értékeket rendelhetnek a specifikus igények szerint. Például a fájltípus a következőképpen kezelhető:

A felhasználók saját hozzárendelési módszereiket is hozzáadhatják. A rendszertípusok esetében a Szárnyak megkülönböztethetők a hagyományos felhasználó által definiált típusoktól, és a rendszer beépített típusára való elemzéskor lefelé leállíthatja a rekurzív elemzést.

●g_int globális változókat, globalType pedig globális változókat jelöl

●next a linkelt listastruktúrát jelöli, a NodeType pedig ezt a struktúrát egy összekapcsolt listaként

●returnType a függvény return érték típusát jelöli.

A fenti tanulmányban a globális változók és függvények szerkezeti információit elemzik és kinyerik, és a következő információkat használják a PSD-ben történő mentéshez, hogy befejezzük a tesztelt forrásprogram meghajtó keretrendszerének teljes generálását.

A generáció főként az alábbi szempontokra oszlik:

Ø Globális változók deklarációja

Ø A függvényparaméterek hozzárendelési művelete, a függvényparaméterek száma alapján, sorban rendelnek értékeket

Ø A globális változók hozzárendelése sorrendben történik az elemzés által használt globális változók száma szerint

Ø Az eredeti funkció hívása

Néhány fontos megjegyzés:

●Az illestavergenerálási folyamat során néhány speciális függvény, mint például a fő funkciók, statikus függvények stb., ideiglenesen nem kerülnek feldolgozásra, mert a külvilág nem fér hozzájuk.

● Minden tesztelt forrásfájlhoz egy megfelelő meghajtófájl generálódik.

● A meghajtóvezérlés is benne van a Driver_main.cpp-ben, amely automatikusan konfigurálja a függvény tesztjeinek számát makrók segítségével

A fenti forrásprogram által generált meghajtófüggvény a következő:

● Minden változót az eredeti változó neve előtt nevezünk el, hozzáadjuk _

●A megfelelő tesztadatok megszerzése után a változókat sorba rendelik

●A rendszer beépített paraméterei és a felhasználó speciális paraméterei esetén a hozzárendelési módszer egységesen van konfigurálva a sablon módszerrel.

●Rendeld meg és hívd meg a paramétereket a teszt alatt álló függvényhez.

Az alábbiakban a 3. ábrán PSD formátumban generált adathalmazt olvashatunk, minden adathalmazt JSON formátumban mentenek, így könnyebb látni az adatok hierarchikus kapcsolatát.

Minden fordítási egységhez alapértelmezés szerint egy tesztadat-fájlkészletet generálnak, amelyek minden függvényhez tartoznak, és az értékgenerálás módosítható a konfigurációk számával.

Hogyan fejezzük be az illegasztó keretrendszer generálását, az alábbiakban részletes magyarázat található a MySQL nyílt forráskódú program teljes generálási folyamatáról.

Az alábbiakban a Wings Mysql tesztelésének fő felületrajza látható:

Kattintson a Fájl gombra, hogy beállítsa a tesztelt forrásprogram projektkönyvtárát. A beállítások befejezése után kattintson a függvényműveletre, amely főként paraméterelemzést, illevezető-generálást, értékfájl-generálást és sablon hozzáadást foglal magában. Az elemzéshez a következő mappák kerülnek létre:

Ezek közül a paraméterelemző modul generálja a FunXml és a GlobalXml fájlokat, amelyek minden kinyert fordítási egység függvény- és globális változó információit tárolják.

A driver generation modul Wings_Projects megfelelő mappában generálódik, amely tárolja az egyes fordítási egységek illesztőprogramfájljait

Az értékgeneráló modul tárolja az egyes fordítási egységekhez tartozó generált tesztadatokat.

A következő ábra a Mysql által betöltött illesztőprogramfájl-struktúra adatait mutatja, a bal oldali navigációs fa pedig a generált driver fájl, amely tartalmazza minden fordítási egység függvényeit, valamint a függvények paramétereit és globális változóit. Kattintson az egyik fordítási egységre, hogy betöltse a megfelelő illesztőprogramfájlt és a megfelelő értékfájlt.

A fentiek az illezőprogramfájl és értékfájl, amelyek a MySQL teljes generálásához felelnek meg, és a driver-fájlt részletesen leírja a következő kód.

● Minden összeállítási egységre a globális változó hivatkozása extern alapján történik.

●A driver függvény egyformán a Driver_XXX módszernek van elnevezve, a JSON-t használják a tesztadatok megszerzésére, és az idők egyetlen függvény tesztjeinek számát jelenti.

●Minden paraméter-hozzárendelési művelethez a parzált PSD tárolóformátumot használják, hogy sorra értékeket rendeljenek minden rétegstruktúrához.

A Wings alkalmazása nagyon egyszerű, az alábbiakban a Mysql kóddal generált tesztadatok statisztikai indexe található, amely normálisan fordítható Visual Studio 2015-ben, például az egész generálási folyamat nem igényel kézi beavatkozást, csak a forráskód útvonalát kell megfogalmazni, amit generálni és vezetni kell.

MySQLTesztadatok

Az alábbiakban a forráskód statisztikai eszközzel szerzett eredményeket olvassák, amelyek több mint 4 millió sornyi érvényes egységtesztkódot generálnak a Wings teljesen automatikusan. Ami még érdekesebb, hogy látható, hogy ezeknek a kódoknak a kézi fejlesztésének költsége akár 1 079 munka-hónapot is igényel, míg a költség akár 10,79 milliót is elér.

A Wings felismerte a program első felfedezési lépését, hogy automatikusan generálja a programot, az első verzió jelenleg megjelent, az érdeklődő fejlesztők közvetlenül letölthetik a Code Cloud platformról (https://gitee.com/teststars/wings_release), a kereskedelmi licenc egy hónapos korlátlan funkciós élményt biztosít, gyorsan átélheted a Wings varázslatos erejét, a Wings c nyelvi verziója több platformot támogat, például Visual Studio-t, VXWORKS, GCC, QT stb. A Wings-et a Nebulas tesztelési (www.teststar.cc) csapata tervezi és fejlesztette, és az érdeklődő fejlesztők a Codecloud interaktív platformján keresztül kapcsolatba léphetnek a Nebulas tesztcsapatával, hogy hozzájáruljanak tervezési ötleteikkel és termékhasználati visszajelzéseikkel (a kiváló javaslatok alapján a Nebulas legalább három hónappal meghosszabbíthatja ingyenes használati idejét). A Wings erős, alapvető génnel rendelkezik, amely jelentősen javítja a szoftverminőséget, és a jövőben mélyen optimalizálja az automatikusan írt programok olvashatóságát (közelebb áll a jó programozók írásszintjéhez) és a C++ nyelv támogatását.