[C++] Tiivad – Las üksustestid genereeritakse nutikalt ja automaatselt

Ühiktestimine on väga tõhus viis tarkvara kvaliteedi tagamiseks, olgu see siis varajase sekkumise kontseptsioonist testimisel või üksustestide omadustest, mida saab kontrollida suurel kiirusel ilma kasutajaliidestest mõjutamata, seega tööstuse poolt soovitatud testipõhine arendus viitab siin mainitud testijuht pigem ühiktesti draiverile. Siiski viib üldarendusmeeskond üksusteste endiselt harva läbi süsteemselt ning rakendustarkvara testimist teostavad pigem professionaalsed testimismeeskonnad, et teha musta kasti teste. Üksustestimise suurim raskus ei ole see, et sisendit ja väljundit ei saa määrata, sest see on juba mooduli arendusfaasis määratud, vaid see, et üksustestjuhtumite kirjutamine võtab palju arendajate töötunde ning asjakohaste statistika kohaselt ületab üksustesti juhtumite aeg isegi funktsiooni arendusaja kaugele. Siin on mõned kõige levinumad põhjused, miks arendus ei kirjuta ühikteste:

●Nõuded on alati lõputud, funktsionaalsed nõuded tuleb järgmises etapis täita ja ruumi täitmiseks pole aega

●Ühikteste on liiga palju, mida täiendada, ja alustada pole võimalik, seega ma subjektiivselt vastu panen.

● Ühikteste on raske kirjutada. Ühelt poolt võib põhjuseks olla funktsionaalse funktsiooni teostus ebapiisav ning teiselt poolt puuduvad (või tundmatud) kasulikud ühikustesti raamistikud ja mock-raamistikud.

● Ühiktestid ei kuulu töökoormusse.

Teiseks on funktsionaalsed nõuded endiselt ebastabiilsed ning ühiktestide kirjutamise kulutõhusus ei ole kõrge. Teisisõnu, kui nõuded muutuvad homme, siis mitte ainult funktsionaalne kood, vaid ka ühiktestid. Kui sa ei kirjuta ühikteste, siis see osa pingutusest ei lähe asjata.

Tegelikult on ülaltoodud punktide juurpõhjus see, et üksustesti kirjutamine võtab liiga palju aega, mis lõpuks viib testipõhise mootori võimsuse kaotuseni, mistõttu testpõhise arenduse kaunis visioon jääb reaalses stsenaariumis seisma, sest selle mootori ehitamine on liiga keeruline ja kallis. Turul olevad erinevad "x" üksused ja ühiktestimise raamistikud lahendavad ainult testipõhiste välisraamide genereerimise probleemi, ilma igasuguse kasutusjuhtumi loogika ja andmegenereerimise võimalusteta, mis põhinevad sügaval programmimõistmisel. Seetõttu muudab see arendajad vastupidavaks erinevates arendusega seotud olukordades. Wingsi väljaandmine (praegu C-le) lahendab ühe suurima probleemi programmeerijatele ning võib oluliselt muuta ühiktestimise senist olukorda, mis tõhusalt leevendab süsteemitasemel musta kasti testimise ja automatiseeritud testimise survet, mis põhineb massiivsetel inimressurssidel.

Piirangutestjuhtumid genereeritakse automaatselt programmide poolt ning kõige olulisem aluseks olev tehnoloogia on keerukas parameetrite parsimise tehnoloogia. See tähendab, et see võib meelevaldselt määratleda pesastatud taseme rekursiivse parsingu kompilaatori tasemel suvaliselt keerukate tüüpide jaoks. Ilma selle läbimurdeta selles kriitilises tehnoloogias oleks automaatne testjuhtumite genereerimise süsteem kas kaubanduslikult võimetu või areneks tootma nõuetele vastavaid testandmeid väga madala efektiivsusega. Näiteks kuulus fuzzing-tööriist American Fuzzy Lop ei suuda tuvastada kasutaja programmi nõutavat struktuuri ning peab arendama otsingualgoritmi kõige välimise kihi põhjal. Programmi omadused seisnevad selles, et sisemise mooduli sisend liidese tasandil ja andmenõuded on kaugel ning välised andmed teisendatakse tavaliselt keeruka teisenduse kiht haaval, et saada sisemise mooduli nõutav andmestruktuuri tüüp, mistõttu väliskihilt uurimiseks kuluv arvutus ja aeg on mõeldamatu. Ameerika Fuzzy Lopi põhjal, et saada legitiimset SQL-lauset, tuleb programmi sisemist moodulit uurida päevadega, mitte minutite või tundidega. Teine piirang on see, et sisendid, mida iga programm saab üle võtta, on hoolikalt struktureeritud ja kompileeritud andmed suure hulga reeglitega, ning nende andmete genereerimine juhuslike + uurivate meetodite abil on väga ebarealistlik ja äärmiselt ajamahukas. Seetõttu ei ole teostatav genereerida automaatselt genereeritud kasutusjuhtumeid nii mustast kastist kui ka kõige välisemast sisendist.

Kui kasutusjuhtumipõhine element genereeritakse tarkvara sisemise struktuuri analüüsist, on vajalik tarkvara kompileerimisstruktuuri sügav arusaam. Elujõuline testjuhtumi genereerimise süsteem peaks põhinema programmi keskel (võtme sisenemispunktil) kui kõige sobivamal testi sisenemispunktil. Nende moodulite sisendid on muutnud udused sisendid väga struktureeritud parameetriteks. Kui neid keerukaid struktuure saab tuvastada, saab keerukaid andmetüüpe samm-sammult lihtsateks andmetüüpideks lagundada ning parameetrite ehitus saab samal ajal lõpule viia, ning juhtimise kasutusjuhtumite genereerimine saab automaatselt lõpule viia.

Moodulipõhine testimine, mida võib klassifitseerida traditsiooniliseks üksustestimiseks, on parim viis defektide leidmiseks ja ohjeldamiseks teadus- ja arendustegevuse faasis. Kuid ühiktestimise piirangute tõttu tuleb arendada suur hulk draivereid ning nende edendamine ja rakendamine tööstuses on oluliselt piiratud. Loomulikult saab üksusteste teha ka pärast süsteemi integreerimist, et vältida virtuaalsete stub-programmide ehitamist.

Nebulas Testingi Wings toode, mis toodi maailmas esmakordselt turule paar päeva tagasi, on intelligentne ja täielikult automatiseeritud ühiktesti juhtumite genereerimise süsteem, mis on uurinud ja lahendanud järgmised raskused ning on nüüd teiega jagatud.

(1) Programmi parameetrite põhjalik analüüs

Wings kasutab kompilaatori aluseks olevat tehnoloogiat, et moodustada mooduliobjekte sisendlähtefaili põhjal vastavalt funktsioonile. Objekt sisaldab funktsiooni sisendparameetreid, tagastusväärtuse tüüpi ja muud teavet, mida saavad kasutada draiverifunktsiooni moodul ja testjuhtumi moodul. Iga fail on üksus, mis teeb põhjaliku analüüsi iga funktsiooni parameetri kohta ning suudab saavutada täpse parseerimise ja dekompositsiooni pesastatud tüüpide, keerukate tüüpide jms jaoks, selgitada keerulisi tüüpe kiht-kihi kaupa põhiandmetüüpidena ning genereerida parameetrite struktuuri kirjeldusfaili (PSD).

(2) Funktsiooniajam moodulite automaatne genereerimine

PSD-faili vorminguinfo kohaselt genereeritakse kõik testitava lähteprogrammi draiverifunktsioonid automaatselt ning ühiktestimise protsess ei sõltu enam arendajate käsitsi testfunktsioonide kirjutamisest, vaid tuleb ainult genereeritud draiverifunktsioonid ja testitavad lähtefailid kokku kompileerida, et testitulemused täita ja testitulemusi vaadata. Testidraiver genereerib programmi automaatselt PSD kirjelduse põhjal, ehitab täielikult automaatselt kõik parameetrid ja vajalikud globaalsed muutujad, mis juhivad testi käitatavat, ning suudab genereerida struktureeritud testdraiveri vastavalt keerukate muutujate hierarhiale, mis võib ühiktestide kirjutamisel palju aega säästa.

(3) Testandmete automaatne genereerimine ja haldamine

Seda kasutatakse testandmete automaatseks genereerimiseks, mis vastab testfunktsiooni poolt eraldatud teabele ning andmed salvestatakse JSON-faili kindla hierarhilise loogilise seosega. Andmed ja andmetüüp pärast dekompositsiooni ja laiendamist vastavad üksteisele. Kasutajad võivad neid andmeid vastavalt ärinõuetele suvaliselt marginaliseerida ning kasutada JSON-faile, et kuvada neid struktureeritud ja hierarhiliselt, mis on väga selge. Testandmed sisaldavad globaalsete muutujate väärtusi ja parameetrite väärtusi, kui testitav funktsioon kutsutakse.

Wings pakub üksustestimise meetodit juhi funktsioonide automaatseks genereerimiseks, mis hõlmab peamiselt järgmisi samme:

Joonis 1: Ühikutestidel põhinev ehitusvoog

Testitava programmi struktuuriinfo hõlmab peamiselt globaalseid muutujaid ja funktsiooniinfot programmis ning funktsiooniinfo sisaldab peamiselt funktsiooni parameetrite, parameetrite ja tagastusväärtuste arvu. Kõige olulisem on eraldada sümboliinfo ja tüübiinfo mõnede keerukate tüüpide kohta ning analüüsida neid kihthaaval põhilisteks andmetüüpideks, et lõpetada globaalsete muutujate ja funktsiooniparameetrite konstrueerimine.

Muutujate tüübid jagunevad üldjuhul põhitüüpideks, ehitustüüpideks, osutajate tüüpideks ja nulltüüpideks. Wings kasutab aluseks olevat kompileerimistehnoloogiat, et käsitleda erinevaid muutujatüüpe erinevatel viisidel.

(1) Põhitüübid, nagu allkirjastamata int u_int=20, Wings parsivad muutuja nime u_int-ks ja andmetüübi unsigned int-iks.

(2) Ehitustüübid, ehitustüübid jagunevad umbkaudselt massiivideks, struktuurideks, ühisteks ja loendamistüüpideks.

● Massiivi tüüp, näiteks intarray[2][3], massiivi nimi on massiivi, tüüp int ja 2D massiivi pikkus, käitumine 2, veerg 3.

●Struktuuri tüüp, struktuuride puhul massiivide, struktuuridega seotud nimekirjade jms puhul jagatakse erinevad markerid.

(3) Osuti tüüp, nt int **ptr = 0; , tõlgendab osutit kui 2. taseme int tüüpi osutit.

(4) Nulltüüp, mis on NULL.

(5) Süsteemitüübid, nagu fail, size_t jne, märgitakse süsteemitüüpideks ning lisatakse mallile ja määratakse kasutaja poolt.

(6) Funktsiooni osuti tüüp, analüüsi tagastusväärtuse tüüpi, parameetri tüüpi ja funktsiooni parameetrite arvu

Iga testitava lähteprogrammi kompileerimisüksuse kohta salvestatakse parsitud funktsiooni info vastavasse PSD struktuuri ning kirjeldatakse järgmisi lähtekoodi näiteid:

   

Ülaltoodud programmis void StructTypeTest3(myy_struct mm_struct[2])Salvestatud PSD struktuur on järgmine:

Iga sõlme tähendus PSD-failis on järgmised:

●StructTypeTest3 tähistab funktsiooni nime, parmType0 parameetri tüüpi ja parmNum parameetrite arvu

●mm_struct tähistab funktsiooniparameetri sümbolit, baseType1 esindab tüüpide klassifikatsiooni (põhiandmetüüp, ehitustüüp, osuti tüüp, nulltüüp), tüüp tähistab konkreetseid tüüpe, sealhulgas int, char, short, long, double, float, bool ning need märgita tüübid ja teised põhitüübid, ning on mõned eritüübid, näiteks: ZOA_FUN type esindab funktsiooni tüüpi, StructureOrClassType tähistab struktuuri tüüpi jne ning nimi tähistab struktuuri, ühenduse ja enum-tüübi nime

●i_int tähistab baastüüpi, mis on väikseim määramisühik

●array_one tähistab massiivi tüüpi, RowSize massiivi pikkust ning massiivi saab jagada ühemõõtmelisteks massiivideks, kahemõõtmelisteks massiivideks jne

●punkt tähistab osuti tüüpi, osutaja jagatakse esimese taseme osutiks, teise taseme osutiks jne ning üldist osutit kasutatakse funktsiooniparameetrina massiivina, nii et põhilise osuti tüübi puhul kasutatakse väärtuste määramiseks dünaamilise jaotusmassiivi meetodit ning kasutaja saab vastavat väärtusfaili vastavalt vajadustele muuta.

● w tähistab bittivälja tüüpi ja bitfileld numbrite arvu

●functionPtr esindab funktsiooni osuti tüüpi, mis analüüsib vastavalt parameetrite tüüpi, parameetrite arvu ja tagastatava väärtuse infot

●Dem tähendab konsortsiumi tüüpi

● dy tähistab enum-tüüpi ja väärtus tähistab enum-tüübi väärtust

●fail tähistab struktuuri tüüpi, SystemVar tähistab selle muutuja kuulumist süsteemi päise faili muutujale, selle tüüpi muutuja puhul lisab Wings mallimuutujad malliteeki, kasutajad saavad määrata eriväärtusi vastavalt konkreetsetele vajadustele. Näiteks failitüüpi käsitletakse järgmiselt:

Kasutajad saavad lisada ka oma määramismeetodeid. Süsteemitüüpide puhul saab tiibu eristada tavapärastest kasutaja määratud tüüpidest ning süsteemi sisseehitatud tüübi parsimisel saab see peatada rekursiivse analüüsi allapoole.

●g_int tähistab globaalseid muutujaid ja globalType globaalseid muutujaid

●next tähistab lingitud loendi struktuuri ja NodeType seda struktuuri kui lingitud loendit

●returnType tähistab funktsiooni tagastusväärtuse tüüpi.

Ülaltoodud artiklis analüüsitakse ja ekstraheeritakse globaalsete muutujate ja funktsioonide struktuurset teavet ning järgmist teavet kasutatakse PSD-s salvestamiseks, et lõpetada testitava lähteprogrammi juhiraamistiku genereerimine.

Põlvkond jaguneb peamiselt järgmisteks aspektideks:

Ø Globaalsete muutujate deklaratsioon

Ø Funktsiooniparameetrite määramisoperatsioon, vastavalt funktsiooniparameetrite arvule, määra väärtused kordamööda

Ø Globaalsete muutujate määramine toimub järjestikku vastavalt analüüsis kasutatavate globaalsete muutujate arvule

Ø Algse funktsiooni kutse

Mõned punktid, mida tasub märkida, on järgmised:

●Draiverite genereerimise protsessi käigus ei töödelda ajutiselt mõningaid erifunktsioone, nagu põhifunktsioonid, staatilised funktsioonid jne, kuna välismaailm ei pääse neile ligi.

● Iga testitava lähtefaili jaoks genereeritakse vastav draiverifail.

● Draivi juhtimine on Driver_main.cpp kaasas, et automaatselt seadistada funktsiooni testide arvu makrode kaudu

Ülaltoodud lähteprogrammi poolt genereeritud draiverifunktsioon on järgmine:

● Kõik muutujad on nimetatud enne algse muutuja nime, lisa _

●Vastavad testandmed saades määratakse muutujad kordamööda

●Süsteemi sisseehitatud parameetrite ja kasutaja eriparameetrite puhul konfigureeritakse määramismeetod ühtlaselt mallimeetodi kaudu.

●Määra ja kutsu testitavale funktsioonile parameetrid.

Järgnevalt on PSD-formaadis genereeritud andmekogum joonisel 3, iga andmekogum salvestatakse JSON-formaadis, mis teeb andmete hierarhilise seose jälgimise lihtsamaks.

Iga kompileerimisüksuse jaoks genereeritakse vaikimisi testandmete failide komplekt, mis vastab kõigile funktsioonidele, ning väärtuste genereerimist saab muuta konfiguratsioonide arvu järgi.

Kuidas draiveriraamistikku genereerida, järgnevalt on üksikasjalik selgitus avatud lähtekoodiga programmi MySQL täielikust genereerimisprotsessist.

Järgnevalt on toodud Wings'i Mysql-i testimise peamine liidese diagramm:

Klõpsa Faili nuppu, et määrata testitava lähteprogrammi projektikataloog. Kui seaded on tehtud, klõpsa funktsioonitoimingul, mis hõlmab peamiselt parameetrite parsimist, draiverite genereerimist, väärtusfailide genereerimist ja mallide lisamist. Analüüsiks genereeritakse järgmised kaustad:

Nende hulgas genereerib parameetrite parsimise moodul FunXml ja GlobalXml, mis salvestavad vastavalt iga ekstraheeritud kompileerimisühiku funktsiooniinfot ja globaalset muutujate infot.

Draiverigeneratsiooni moodul genereeritakse vastavas kaustas, Wings_Projects salvestab iga kompileerimisüksuse draiverifailid

Väärtuse genereerimise moodul salvestab iga kompileerimisüksuse genereeritud testandmed.

Järgmine joonis näitab Mysql-i laaditud draiveri failistruktuuri infot ning vasakul olev navigeerimispuu on genereeritud draiverifail, mis sisaldab iga kompileerimisüksuse funktsioone, samuti funktsioonide parameetreid ja globaalseid muutujaid. Klõpsa ühel kompileerimisüksusel, et laadida vastav draiverifail ja vastava väärtuse fail.

Ülaltoodud on draiverifail ja väärtusfail, mis vastavad kogu Mysql-i genereerimisele, ning draiverifaili kirjeldatakse üksikasjalikult järgmises koodis.

● Iga kompileerimisühiku puhul on globaalse muutuja viide eksterni järgi.

●Draiverifunktsioon nimetatakse ühtlaselt Driver_XXX meetodiks, JSON kasutatakse testandmete saamiseks ja ajad tähistavad ühe funktsiooni testide arvu.

●Iga parameetrite määramise operatsiooni puhul kasutatakse parsitud PSD salvestusformaati, et määrata väärtused igale kihile.

Wingsi rakendus on väga lihtne, järgnevalt on statistiline indeks genereeritud testandmetest Mysql-koodi abil, mida saab tavapäraselt kompileerida Visual Studio 2015-s, kogu genereerimisprotsess ei vaja käsitsi sekkumist, vaid tuleb formuleerida lähtekoodi tee, mida tuleb genereerida ja juhtida.

MySQLTestiandmed

Allpool on toodud tulemused, mis on saadud lähtekoodi statistikatööriista abil, kus Wings genereerib täielikult automaatselt üle 4 miljoni rea kehtivat ühikutesti koodi. Veelgi huvitavam on see, et nende koodide käsitsi arendamise kulud ulatuvad kuni 1 079 töömehele ja kulud kuni 10,79 miljonile.

Wings on realiseerinud programmi esimese uurimisetapi, et programmi automaatselt genereerida, esimene versioon on praegu välja tulnud, huvilised arendajad saavad selle otse Code Cloud platvormilt (https://gitee.com/teststars/wings_release) alla laadida, kommertslitsentsid annavad ühe kuu piiramatu funktsionaalsuse kogemuse, saad kiiresti kogeda Wingsi maagilist jõudu, Wings c-keele versioon toetab mitut platvormi, näiteks Visual Studio, VXWORKS, GCC, QT jne. Wingsi on disaininud ja arendanud Nebulas testimise (www.teststar.cc) meeskond ning huvilised arendajad saavad Codecloudi interaktiivse platvormi kaudu ühendust võtta Nebulas testimismeeskonnaga, et jagada oma disainiideid ja tagasisidet tootekasutusele (suurepäraste soovituste korral saab Nebulas pikendada oma tasuta kasutusaega vähemalt kolme kuu võrra). Wingsil on tugev aluseks olev geen, mis parandab oluliselt tarkvara kvaliteeti, ning tulevikus optimeerib Wings põhjalikult automaatselt kirjutatud programmide loetavust (lähemal heade programmeerijate kirjutamistasemele) ja C++ keele tuge.