[C++] Vinger – La enhetstester genereres intelligent og automatisk

Enhetstesting er et svært effektivt middel for å sikre programvarekvalitet, enten det er fra perspektivet tidlig intervensjon i testing eller fra egenskapene til enhetstester som kan verifiseres i høy hastighet uten å bli påvirket av brukergrensesnittet, så den testdrevne utviklingen som bransjen anbefaler, testdriveren som nevnes her, refererer mer til enhetstestdriveren. Likevel utfører det generelle utviklingsteamet fortsatt sjelden enhetstester systematisk, og testen for applikasjonsprogramvare utføres i større grad av profesjonelle testteam for å utføre black box-tester. Den største utfordringen med enhetstesting er ikke at input og output ikke kan bestemmes, det er tross alt allerede bestemt i modulutviklingsfasen, men at skriving av enhetstesttilfeller vil kreve mye utviklerarbeidstimer, og ifølge relevant statistikk vil tiden for enhetstesttilfeller til og med langt overstige utviklingstiden til selve funksjonen. Her er noen av de vanligste grunnene til at utvikling ikke skriver enhetstester:

●Kravene er alltid uendelige, og det er fortsatt funksjonelle krav som må realiseres i neste fase, og det er ikke tid til å fylle enheten

●Det er for mange enhetstester som kan suppleres, og det finnes ingen måte å starte på, så jeg motsetter meg subjektivt.

● Enhetstester er vanskelige å skrive. På den ene siden kan grunnen være at implementeringen av funksjonsfunksjonen ikke er rimelig nok, og på den andre siden finnes det ingen (eller ukjente) nyttige enhetstestrammeverk og mock-rammeverk.

● Enhetstester er ikke inkludert i arbeidsmengden.

For det andre er de funksjonelle kravene fortsatt ustabile, og kostnadsytelsen ved å skrive enhetstester er ikke høy. Med andre ord, hvis kravene endres i morgen, vil ikke bare funksjonskoden bli fjernet, men også enhetstestene. Hvis du ikke skriver enhetstester, vil ikke denne delen av innsatsen være forgjeves.

Faktisk er rotårsaken til punktene ovenfor at enhetstestskrivingen tar for mye tid, noe som til slutt fører til tap av kraft i den testdrevne motoren, noe som gjør at den vakre visjonen om testdrevet utvikling stopper opp i det virkelige scenariet, fordi det er for vanskelig og dyrt å bygge motoren for denne driften. De ulike "x"-enhetene på markedet og enhetstestrammeverk løser kun problemet med å generere testdrevne ytre rammer, uten noen brukslogikk og datagenereringsmuligheter basert på dyp programforståelse. Derfor gjør det utviklere motstandsdyktige i ulike utviklingsrelaterte situasjoner. Utgivelsen av Wings (for tiden for C) løser et av de største problemene for programmerere, og har potensial til å fundamentalt endre status quo for enhetstesting, noe som effektivt vil lette presset fra systemnivå black box-testing og automatisert testing basert på massive menneskelige ressurser.

Begrensningstesttilfellene genereres automatisk av programmer, og den mest kritiske underliggende teknologien er kompleks parameterparsing-teknologi. Det vil si at den vilkårlig kan definere nestelt nivå rekursiv parsing på kompilatornivå for vilkårlig komplekse typer. Uten dette gjennombruddet innen denne kritiske teknologien ville det automatiske testcasegenereringssystemet enten vært kommersielt inkompetent eller utvikle seg til å produsere samsvarende testdata med svært lav effektivitet. For eksempel kan det berømte fuzzingverktøyet American Fuzzy Lop ikke identifisere typen struktur som kreves av brukerens program, og må utvikle søkealgoritmen basert på det ytterste laget. Egenskapene til programmet er at inndataene på grensesnittnivå og datakravene til en intern modul er langt unna, og de eksterne dataene transformeres vanligvis lag for lag av kompleks transformasjon for å bli datastrukturtypen som kreves av den interne modulen, så mengden beregning og tid som kreves for å utforske fra det ytre laget vil være utenkelig. Basert på American Fuzzy Lop, for å kunne generere en legitim SQL-setning, må den interne modulen i programmet utforskes på dager, langt fra minutter eller timer. En annen begrensning er at inputene som hvert program kan overta er nøye strukturerte og kompilerte data med et stort antall regler, og det er svært urealistisk og ekstremt tidkrevende å generere disse dataene gjennom tilfeldige + utforskende metoder. Derfor er det ikke mulig å generere auto-genererte brukstilfeller både fra svartboksen og den ytterste inputen.

Hvis den brukstilfelle-drevne strukturen genereres fra analysen av programvarens interne struktur, er det nødvendig å ha en dyp forståelse av programvarens kompilasjonsstruktur. Et levedyktig system for generering av testtilfeller bør baseres på midten av programmet (nøkkelinngangspunktet) som det mest passende testinngangspunktet. Inngangene fra disse modulene har gjort fuzzy input om til svært strukturerte parametere. Så lenge disse komplekse strukturene kan identifiseres, de komplekse datatypene kan degraderes til enkle datatyper steg for steg, og parameterkonstruksjonen kan fullføres samtidig, kan genereringen av drivende brukstilfeller automatisk fullføres.

Modulbasert testing, som kan klassifiseres som tradisjonell enhetstesting, er den beste måten å finne og inneholde feil i FoU-fasen. På grunn av begrensningene ved enhetstesting må imidlertid et stort antall drivere utvikles, og promotering og anvendelse i bransjen er sterkt begrenset. Selvfølgelig kan enhetstester også utføres etter at systemet er integrert for å unngå å bygge virtuelle stubprogrammer.

Nebulas Testings Wings-produkt, som ble lansert i verden for første gang for noen dager siden, er et intelligent og fullautomatisert system for generering av enhetstesttilfeller, som har studert og løst følgende vanskeligheter, og som nå deles med deg.

(1) Grundig analyse av programparametere

Wings bruker den underliggende teknologien i kompilatoren for å danne modulobjekter basert på inndatakildefilen i henhold til funksjonen. Objektet inneholder inputparametrene til funksjonen, returverditypen og annen informasjon, som kan brukes av driverfunksjonsmodulen og testcase-modulen. Hver fil er en enhet som utfører grundig analyse av hver parameter i hver funksjon i den, og kan oppnå nøyaktig parsing og dekomponering for nestede typer, komplekse typer osv., forklare komplekse typer lag for lag som grunnleggende datatyper, og generere en beskrivelsesfil (PSD) av parameterstrukturen.

(2) Funksjonsdrift automatisk generering av moduler

Ifølge formatinformasjonen til PSD-filen genereres alle driverfunksjoner i kildeprogrammet som testes automatisk, og enhetstestingsprosessen er ikke lenger avhengig av at utviklerne skriver testfunksjoner manuelt, men trenger kun å kompilere de genererte driverfunksjonene og kildefilene under test sammen, og testresultatene kan kjøres og testresultatene vises. Testdriveren genererer automatisk programmet basert på PSD-beskrivelsen, bygger fullstendig automatisk alle parametere og nødvendige globale variabler som styrer testen under testing, og kan generere en strukturert testdriver i henhold til hierarkiet av komplekse variabler, noe som kan spare mye tid ved å skrive enhetstesttilfeller.

(3) Automatisk generering og håndtering av testdata

Den brukes til automatisk å generere testdata, som tilsvarer informasjonen som hentes ut av testfunksjonen, og dataene lagres i en JSON-fil med en viss hierarkisk logisk relasjon. Dataene og datatypen etter dekomponering og ekspansjon tilsvarer hverandre. Brukere kan vilkårlig marginalisere disse dataene i henhold til forretningsbehov, og bruke JSON-filer for å vise dem på en strukturert og hierarkisk måte, noe som er veldig tydelig. Testdataene inkluderer verdiene til globale variabler og parameterverdiene når funksjonen som testes kalles.

Wings tilbyr en enhetstestmetode for automatisk generering av førerfunksjoner, som hovedsakelig inkluderer følgende trinn:

Figur 1: Enhetstestdrevet byggeflyt

Strukturinformasjonen til programmet som testes inkluderer hovedsakelig de globale variablene og funksjonsinformasjonen i programmet, og funksjonsinformasjonen inkluderer hovedsakelig antall parametere, parametertyper og returverdityper for funksjonen. Det viktigste er å hente ut symbol- og typeinformasjon for noen komplekse typer, og analysere dem til grunnleggende datatyper lag for lag for å fullføre konstruksjonen av globale variabler og funksjonsparametere.

Typene variabler deles vanligvis inn i grunntyper, konstruksjonstyper, pekertyper og nulltyper. Wings bruker den underliggende kompilasjonsteknologien for å håndtere ulike variabeltyper på forskjellige måter.

(1) Grunnleggende typer, som usignert int u_int=20, Wings vil tolke navnet på variabelen til u_int og datatypen til usignert int.

(2) Konstruksjonstyper, konstruksjonstyper deles grovt inn i matriser, strukturer, felles og opptellingstyper.

● Array-type, som intarray[2][3], array-navnet er array, type int og lengde på 2D-array, oppførsel 2, kolonne 3.

●Strukturtype, for strukturer som matriser, strukturlenkede lister osv., ulike markører deles opp.

(3) Pekertype, f.eks. int **ptr = 0; , tolker pekeren som en nivå 2-peker av int-type.

(4) Null-type, som løses til å være NULL.

(5) Systemtyper, som fil, size_t osv., er merket som systemtyper, og vil bli lagt til malen og tildelt av brukeren.

(6) Funksjonspekertype, analyser returverditypen, parametertypen og antall parametere til funksjonen

For hver kompilasjonsenhet i kildeprogrammet som testes, lagres den parsede funksjonsinformasjonen i den tilsvarende PSD-strukturen, og følgende kildekodeeksempler beskrives:

   

I programmet ovenfor, void StructTypeTest3(myy_struct mm_struct[2])Den lagrede PSD-strukturen er som følger:

Betydningen av hver node i PSD-filen er som følger:

●StructTypeTest3 representerer funksjonsnavnet, parmType0 representerer parametertypen, og parmNum representerer antall parametere

●mm_struct representerer symbolet til funksjonsparameteren, baseType1 representerer klassifiseringen av typer (grunnleggende datatype, konstruksjonstype, pekertype, nulltype), type representerer spesifikke typer, inkludert int, char, short, long, double, float, bool, og disse typene usignerte typer og andre grunnleggende typer, og det finnes noen spesielle typer som: ZOA_FUN type representerer funksjonstype, StructureOrClassType representerer struct-typen, osv., og navnet representerer navnet på struct-, union- og enum-typen

●i_int representerer basistypen, som er den minste tildelingsenheten

●array_one representerer arraytypen, RowSize representerer lengden på arrayet, og arrayet kan deles inn i endimensjonale arrays, todimensjonale arrays, osv

●punkt representerer pekertypen, pekeren deles inn i peker på første nivå, peker på andre nivå, osv., og den generelle pekeren brukes som funksjonsparameter som et array, så for den grunnleggende typen peker brukes metoden dynamisk allokeringsarray for å tildele verdier, og brukeren kan endre den tilsvarende verdifilen etter behov.

● w representerer typen bitfelt, og bitfileld representerer antall sifre

●funksjonPtr representerer funksjonspekertypen, som analyserer parametertype, antall parametere og returverdiinformasjon henholdsvis.

●Dem står for konsortiumtype

● dy representerer enumtypen, og verdien representerer verdien av enumtypen

●fil representerer strukturtypen, SystemVar representerer denne variabelen tilhører variabelen i systemheaderfilen, for denne typen variabel legger Wings til malvariabler i malbiblioteket, brukere kan tildele spesielle verdier etter spesifikke behov. For eksempel håndteres filtypen som følger:

Brukere kan også legge til egne tildelingsmetoder. For systemtyper kan Wings skilles fra vanlige brukerdefinerte typer, og når man parser til systemets innebygde type, kan det stoppe rekursiv analyse nedover.

●g_int representerer globale variabler, og globalType representerer globale variabler

●next representerer den lenkede listestrukturen, og NodeType representerer denne strukturen som en lenket liste

●returnType representerer returverditypen til funksjonen.

I artikkelen ovenfor analyseres og hentes den strukturelle informasjonen til globale variabler og funksjoner ut, og følgende informasjon brukes til å lagre i PSD for å fullføre den overordnede genereringen av drivrammen til kildeprogrammet under testing.

Produksjonen er hovedsakelig delt inn i følgende aspekter:

Ø Deklarasjon av globale variabler

Ø Tilordneoperasjon av funksjonsparametere, i henhold til antall funksjonsparametere, tilordner verdier etter tur

Ø Tilordningen av globale variabler utføres sekvensielt i henhold til antall globale variabler som brukes i analysen

Ø Kall til den opprinnelige funksjonen

Noen punkter å merke seg er som følger:

●Under drivergenereringsprosessen blir noen spesialfunksjoner, som hovedfunksjoner, statiske funksjoner osv., ikke behandlet midlertidig fordi de ikke kan nås av omverdenen.

● For hver kildefil som testes, genereres en tilsvarende driverfil.

● Drivkontroll er inkludert i Driver_main.cpp for automatisk å konfigurere antall tester av funksjonen gjennom makroer

Driverfunksjonen generert av kildeprogrammet ovenfor er som følger:

● Alle variabler navngis før navnet på den opprinnelige variabelen, legg til _

●Ved å hente de tilsvarende testdataene, tildeles variablene etter tur

●For systemets innebygde parametere og brukerens spesialparametere, konfigureres tildelingsmetoden jevnt gjennom malmetoden.

●Tildel og kall parametere til funksjonen som testes.

Følgende er et sett med data generert i PSD-format i figur 3, hvert datasett lagres i JSON-format, noe som gjør det enklere å se det hierarkiske forholdet mellom dataene.

For hver kompilasjonsenhet genereres et sett med testdatafiler som tilsvarer alle funksjoner som standard, og verdigenereringen kan justeres med antall konfigurasjoner.

Hvordan fullføre genereringen av driver-rammeverket, følger en detaljert forklaring på hele genereringsprosessen til det åpne kildekodeprogrammet MySQL.

Følgende er hovedgrensesnittdiagrammet for Wings som tester Mysql:

Klikk på Fil-knappen for å sette prosjektmappen til kildeprogrammet under test. Når innstillingene er fullført, klikk på funksjonsoperasjonen, som hovedsakelig inkluderer parameterparsing, drivergenerering, verdifilgenerering og maltillegg. Følgende mapper genereres for analysen:

Blant dem genererer parameterparsing-modulen FunXml og GlobalXml, som lagrer funksjonsinformasjonen og global variabelinformasjon for hver uttrukne kompilasjonsenhet henholdsvis.

Drivergenereringsmodulen vil bli generert Wings_Projects tilsvarende mappe, som lagrer driverfilene for hver kompilasjonsenhet

Verdigenereringsmodulen lagrer de genererte testdataene for hver kompilasjonsenhet.

Følgende figur viser informasjonen om driverfilstrukturen lastet inn av Mysql, og navigasjonstreet til venstre er den genererte driverfilen, som inneholder funksjonene til hver kompilasjonsenhet, samt parameterne og globale variablene til funksjonene. Klikk på en av kompilasjonsenhetene for å laste inn den tilsvarende driverfilen og den tilsvarende verdifilen.

Ovenstående er driverfilen og verdifilen som tilsvarer den totale genereringen av Mysql, og driverfilen er beskrevet i detalj i følgende kode.

● For hver kompilasjonsenhet er referansen til den globale variabelen ved ekstern.

●Driverfunksjonen kalles ensartet Driver_XXX-metoden, JSON brukes som metode for å hente testdata, og tid representerer antall tester av en enkelt funksjon.

●For hver parametertildelingsoperasjon brukes det parsede PSD-lagringsformatet for å tildele verdier til hver lagstruktur etter tur.

Bruken av Wings er veldig enkel, følgende er en statistisk indeks over genererte testdata ved bruk av Mysql-kode som kan kompileres normalt i Visual Studio 2015 som et eksempel, hele genereringsprosessen krever ingen manuell inngripen, bare å formulere veien til kildekoden som må genereres og drives.

MySQLTestdata

Nedenfor er resultatene oppnådd ved bruk av kildekodestatistikkverktøyet, med over 4 millioner linjer med gyldig enhetstestkode generert av Wings helt automatisk. Det som er enda mer interessant, er at det kan sees at kostnaden for manuell utvikling av disse kodene er så høy som 1 079 arbeidsmåneder, og kostnaden er så mye som 10,79 millioner.

Wings har realisert det første utforskningssteget med programmet for automatisk å generere programmet, den første versjonen er for øyeblikket utgitt, interesserte utviklere kan laste den ned direkte på kodeskyplattformen (https://gitee.com/teststars/wings_release), kommersiell lisensiering gir en måneds ubegrenset funksjonsopplevelse, du kan raskt oppleve Wings' magiske kraft, Wings c-språkversjon støtter flere plattformer, som Visual Studio, VXWORKS, GCC, QT, osv. Wings er designet og utviklet av Nebulas-testteamet (www.teststar.cc), og interesserte utviklere kan ta kontakt med Nebulas-testteamet via Codeclouds interaktive plattform for å bidra med designideer og tilbakemeldinger på produktbruk (for de utmerkede forslagene kan Nebulas forlenge sin gratis bruksperiode med minst tre måneder). Wings har et sterkt, underliggende gen som i stor grad forbedrer programvarekvaliteten, og i fremtiden vil Wings i stor grad optimalisere lesbarheten til automatisk skrevne programmer (nærmere skrivenivået til gode programmerere) og støtte for C++-språket.