|
Vingar-Gör enhetstester intelligenta och helt automatiseradeförord Enhetstestning är ett mycket effektivt sätt att säkerställa mjukvarukvalitet, vare sig det gäller tidiga insatser i testning eller egenskaperna hos enhetstester som kan verifieras i hög hastighet utan att påverkas av användargränssnittet, så den testdrivna utveckling som branschen förespråkar, syftar testdrivrutinen som nämns i detta mer på enhetstestdrivrutinen. Dock utför det allmänna utvecklingsteamet fortfarande sällan enhetstester systematiskt, och testet för applikationsprogramvara utförs mer av professionella testteam för att utföra black box-tester. Den största svårigheten med enhetstestning är inte att in- och utdata inte kan bestämmas, eftersom det redan bestäms i modulutvecklingsstadiet, utan att skrivandet av enhetstestfall kommer att förbruka mycket utvecklararbetstimmar, och enligt relevant statistik kommer tiden för enhetstestfall till och med att vida överstiga själva utvecklingstiden för funktionen. Här är några av de vanligaste anledningarna till att utveckling inte skriver enhetstester: ●Kraven är alltid oändliga, och det finns fortfarande funktionella krav att uppfylla i nästa steg, och det finns ingen tid att fylla enheten ●Det finns för många enhetstester som kan kompletteras, och det finns inget sätt att börja, så jag motsätter mig subjektivt. ● Enhetstester är svåra att skriva. Å ena sidan kan anledningen vara att implementeringen av funktionella funktioner inte är tillräckligt rimlig, och å andra sidan finns det inga (eller okända) användbara enhetstestramverk och mock-ramverk. ● Enhetstester ingår inte i arbetsbelastningen. För det andra är de funktionella kraven fortfarande instabila, och kostnadsprestandan för att skriva enhetstester är inte hög. Med andra ord, om kraven ändras imorgon, kommer inte bara den funktionella koden att slopas, utan även enhetstesterna. Om du inte skriver enhetstester kommer denna del av ansträngningen inte vara förgäves. Faktum är att grundorsaken till ovanstående punkter är att enhetstestskrivningen är för tidskrävande, vilket så småningom leder till att den testdrivna motorn förlorar effekt, vilket gör att den vackra visionen av testdriven utveckling stannar i verkligheten, eftersom det är för svårt och dyrt att bygga motorn för denna drivning. De olika "x"-enheterna på marknaden och enhetstestramar löser endast problemet med att generera testdrivna yttre ramar, utan någon användningsfallslogik och datagenereringsmöjligheter baserade på djup programförståelse. Därför gör det utvecklare motståndskraftiga i olika utvecklingsrelaterade scenarier. Lanseringen av Wings (för närvarande för C) löser ett av de största problemen för programmerare och har potential att fundamentalt förändra status quo för enhetstestning, vilket effektivt kommer att minska trycket från systemnivå-black box-testning och automatiserad testning baserad på massiva mänskliga resurser. Testfallen för begränsningar genereras automatiskt av program, och den mest kritiska underliggande teknologin är teknik för komplex parameterparsing. Det vill säga, den kan godtyckligt definiera nästlad nivå rekursiv parsning på kompilatornivå för godtyckligt komplexa typer. Utan detta genombrott inom denna kritiska teknik skulle det automatiska testfallgenereringssystemet antingen vara kommersiellt inkompetent eller utvecklas för att producera kompatibla testdata med mycket låg effektivitet. Till exempel kan det berömda fuzzingverktyget American Fuzzy Lop inte identifiera vilken typ av struktur användarens program kräver, och behöver utveckla sökalgoritmen baserat på det yttersta lagret. Programmets egenskaper är att indata på gränssnittsnivå och datakraven för en intern modul är långt borta, och den externa datan transformeras vanligtvis lager för lager av komplex transformation för att bli den datastrukturtyp som krävs av den interna modulen, så mängden beräkning och tid som krävs för att utforska från det yttre lagret kommer att vara ofattbar. Baserat på American Fuzzy Lop måste den interna modulen i programmet utforskas på dagar för att kunna generera ett legitimt SQL-uttalande, långt ifrån minuter eller timmar. En annan begränsning är att de indata som varje program kan ta över är noggrant strukturerad och kompilerad data med ett stort antal regler, och det är mycket orealistiskt och extremt tidskrävande att generera dessa data genom slumpmässiga + utforskande metoder. Därför är det inte genomförbart att generera automatiskt genererade användningsfall från svarta lådan såväl som från den yttersta indatan. Om den användningsfallsdrivna effekten genereras från analysen av mjukvarans interna struktur är det nödvändigt att ha en djup förståelse för mjukvarans kompileringsstruktur. Ett gångbart system för att generera testfall bör baseras på mitten av programmet (nyckelingångspunkten) som den mest lämpliga testingångspunkten. Indata från dessa moduler har omvandlat fuzzy indata till mycket strukturerade parametrar. Så länge dessa komplexa strukturer kan identifieras, de komplexa datatyperna kan nedsättas till enkla datatyper steg för steg, och parameterkonstruktionen kan slutföras samtidigt, kan genereringen av drivande användningsfall automatiskt slutföras. Modulbaserad testning, som kan klassificeras som traditionell enhetstestning, är det bästa sättet att hitta och innehålla defekter i FoU-fasen. På grund av begränsningarna i enhetstestning behöver dock ett stort antal drivrutiner utvecklas, och marknadsföring och tillämpning i branschen är mycket begränsade. Självklart kan enhetstester också utföras efter att systemet är integrerat för att undvika att bygga virtuella stub-program. Nebulas Testings Wings-produkt, som lanserades i världen för första gången för några dagar sedan, är ett intelligent och fullt automatiserat system för generering av enhetstestfall som har studerat och löst följande svårigheter och nu delas med er. (1) Djupgående analys av programparametrar Wings använder kompilatorns underliggande teknik för att bilda modulobjekt baserat på indatakällfilen enligt funktionen. Objektet innehåller funktionens indataparametrar, returvärdestypen och annan information som kan användas av drivrutinsfunktionsmodulen och testfallsmodulen. Varje fil är en enhet som utför djupgående analys av varje parameter i varje funktion i den, och kan uppnå noggrann parsning och dekomposition för nästlade typer, komplexa typer etc., förklara komplexa typer lager för lager som grundläggande datatyper och generera en beskrivningsfil (PSD) av parameterstruktur. (2) Funktionsstyrning automatisk generering av moduler Enligt formatinformationen i PSD-filen genereras alla drivrutinsfunktioner i källprogrammet som testas automatiskt, och enhetstestprocessen förlitar sig inte längre på att utvecklare manuellt skriver testfunktioner, utan behöver endast kompilera de genererade drivrutinsfunktionerna och källfilerna under test tillsammans, och testresultaten kan köras och testresultaten ses. Testdrivrutinen genererar automatiskt programmet baserat på PSD-beskrivningen, bygger helt automatiskt alla parametrar och nödvändiga globala variabler som driver testet under test, och kan generera en strukturerad testdrivrutin enligt hierarkin av komplexa variabler, vilket kan spara mycket tid vid skrivande av enhetstestfall. (3) Automatisk generering och hantering av testdata Den används för att automatiskt generera testdata, vilket motsvarar informationen som extraheras av testfunktionen, och datan lagras i en JSON-fil med en viss hierarkisk logisk relation. Data och datatyp efter dekomposition och expansion motsvarar varandra. Användare kan godtyckligt marginalisera dessa data enligt affärsbehov och använda JSON-filer för att visa dem på ett strukturerat och hierarkiskt sätt, vilket är mycket tydligt. Testdata inkluderar värdena för globala variabler och parametervärdena när funktionen under test anropas. Wings tillhandahåller en enhetstestmetod för att automatiskt generera förarfunktioner, som huvudsakligen inkluderar följande steg: Figur 1: Enhetstestdrivet byggflöde 1 Extraktion av informationen från programmet som testasStrukturinformationen för det program som testas inkluderar huvudsakligen de globala variablerna och funktionsinformationen i programmet, och funktionsinformationen inkluderar främst antalet parametrar, parametertyper och returvärdestyper för funktionen. Det viktigaste är att extrahera symbol- och typinformation för vissa komplexa typer och analysera dem till grundläggande datatyper lager för lager för att slutföra konstruktionen av globala variabler och funktionsparametrar. Variablertyperna delas generellt in i grundläggande typer, konstruktionstyper, pekartyper och nulltyper. Wings använder den underliggande kompilationsteknologin för att hantera olika variabeltyper på olika sätt. (1) Grundläggande typer, såsom osignerad int u_int=20, Wings tolkar namnet på variabeln till u_int och datatypen till osignerad int. (2) Konstruktionstyper, konstruktionstyper delas grovt in i arrayer, strukturar, gemensamma och uppräkningstyper. ● Arraytyp, såsom intarray[2][3], arraynamnet är array, typ int och längd på 2D-array, beteende 2, kolumn 3. ●Strukturtyp, för structs som arrayer, structlänkade listor, etc., är olika markörer delade. (3) Pekartyp, t.ex. int **ptr = 0; , tolkar pekaren som en nivå 2-pekare av int-typ. (4) Null-typ, som upplöses till att vara NULL. (5) Systemtyper, såsom fil, size_t, etc., markeras som systemtyper och kommer att läggas till mallen och tilldelas av användaren. (6) Typ av funktionspekare, analysera returvärdestyp, parametertyp och antal parametrar för funktionen För varje kompileringsenhet i källprogrammet som testas lagras den tolkade funktionsinformationen i motsvarande PSD-struktur, och följande källkodsexempel beskrivs:
I ovanstående program void StructTypeTest3(myy_struct mm_struct[2])Den sparade PSD-strukturen är följande:
Betydelserna av varje nod i PSD-filen är följande: ●StructTypeTest3 representerar funktionsnamnet, parmType0 representerar parametertypen och parmNum representerar antalet parametrar ●mm_struct representerar symbolen för funktionsparametern, baseType1 representerar klassificeringen av typer (grundläggande datatyp, konstruktionstyp, pekartyp, nulltyp), type representerar specifika typer, inklusive int, char, short, long, double, float, bool, och dessa typer av osignerade typer och andra grundläggande typer, och det finns några specialtyper såsom: ZOA_FUN typ representerar funktionstyp, StructureOrClassType representerar struct-typen, etc., och namnet representerar namnet på struct-, union- och enum-typen ●i_int representerar bastypen, som är den minsta tilldelningsenheten ●array_one representerar arraytypen, RowSize representerar längden på arrayen, och arrayen kan delas in i endimensionella arrayer, tvådimensionella arrayer, etc ●punkt representerar pekartypen, pekaren delas in i första nivåpekaren, andranivåpekaren, etc., och den allmänna pekaren används som funktionsparameter som en array, så för den grundläggande typen av pekare används den dynamiska allokeringsarraymetoden för att tilldela värden, och användaren kan modifiera motsvarande värdefil efter behov. ● w representerar typen av bitfält, och bitfileld representerar antalet siffror ●functionPtr representerar funktionspekartypen, som analyserar parametertyp, antal parametrar och returneringsvärdeinformation respektive ●Dem står för consortium type ● dy representerar enumtypen, och värdet representerar värdet av enumtypen ●fil representerar strukturtypen, SystemVar representerar denna variabel tillhör variabeln i systemhuvudfilen, för denna typ av variabel lägger Wings till mallvariabler i mallbiblioteket, användare kan tilldela speciella värden efter specifika behov. Till exempel hanteras filtypen enligt följande:
Användare kan också lägga till egna tilldelningsmetoder. För systemtyper kan Wings särskiljas från vanliga användardefinierade typer, och när man parsar till systemets inbyggda typ kan det stoppa rekursiv analys nedåt. ●g_int representerar globala variabler, och globalType representerar globala variabler ●next representerar den länkade liststrukturen, och NodeType representerar denna struktur som en länkad lista ●returnType representerar funktionsns typ av returvärde. 2 Automatisk generering av förareI ovanstående artikel analyseras och extraheras den strukturella informationen för globala variabler och funktioner, och följande information används för att spara i PSD och slutföra den övergripande genereringen av drivramen för källprogrammet under test. Produktionen är huvudsakligen indelad i följande aspekter: Ø Deklaration av globala variabler Ø Tilldelingsoperation av funktionsparametrar, enligt antalet funktionsparametrar, tilldela värden i tur och ordning Ø Tilldelningen av globala variabler utförs sekventiellt enligt antalet globala variabler som används i analysen Ø Anrop för den ursprungliga funktionen Några punkter att notera är följande: ●Under drivrutinsgenereringsprocessen bearbetas vissa specialfunktioner, såsom huvudfunktioner, statiska funktioner etc., inte tillfälligt eftersom de inte kan nås av omvärlden. ● För varje källfil under test genereras en motsvarande drivrutinsfil. ● Drivkontroll ingår i Driver_main.cpp för att automatiskt konfigurera antalet tester av funktionen via makron Drivrutinsfunktionen som genereras av ovanstående källprogram är följande: ● Alla variabler namnges före namnet på den ursprungliga variabeln, lägg till _ ●Genom att erhålla motsvarande testdata tilldelas variablerna i tur och ordning ●För systemets inbyggda parametrar och användarens speciella parametrar konfigureras tilldelningsmetoden enhetligt genom mallmetoden. ●Tilldela och anropa parametrar till funktionen som testas. 3 Testdata genereras automatisktFöljande är en datamängd genererad i PSD-format i figur 3, varje datamängd sparas i JSON-format, vilket gör det lättare att se den hierarkiska relationen mellan datan.
För varje kompileringsenhet genereras som standard en uppsättning testdatafiler som motsvarar alla funktioner, och värdegenereringen kan modifieras med antalet konfigurationer. 4 MysqlProgramtestresultat visasHur man slutför genereringen av drivrutinsramverket, följer en detaljerad förklaring av hela genereringsprocessen för det öppna källkodsprogrammet MySQL. Följande är huvudgränssnittsdiagrammet för Wings som testar Mysql: Klicka på Fil-knappen för att ställa in projektkatalogen för källprogrammet under test. När inställningarna är klara, klicka på funktionsoperationen, som huvudsakligen inkluderar parameterparsing, drivrutinsgenerering, värdefilgenerering och malltillägg. Följande mappar genereras för analysen: Bland dem genererar parameterparsing-modulen FunXml och GlobalXml, som lagrar funktionsinformationen och global variabelinformation för varje extraherad kompileringsenhet. Drivrutinsgenereringsmodulen genereras Wings_Projects motsvarande mapp, som lagrar drivrutinsfilerna för varje kompileringsenhet Värdegenereringsmodulen lagrar de genererade testdata för varje kompileringsenhet. Följande figur visar informationen om drivrutinsfilstrukturen som laddats in av Mysql, och navigationsträdet till vänster är den genererade drivrutinsfilen, som innehåller funktionerna för varje kompileringsenhet samt parametrarna och globala variablerna för funktionerna. Klicka på en av kompileringsenheterna för att ladda motsvarande drivrutinsfil och motsvarande värdefil. Ovanstående är drivrutinsfilen och värdefilen som motsvarar den övergripande genereringen av Mysql, och drivrutinsfilen beskrivs i detalj i följande kod. ● För varje kompileringsenhet är referensen för den globala variabeln av extern. ●Drivrutinsfunktionen kallas enhetligt för Driver_XXX-metoden, JSON används som sätt att erhålla testdata, och tid representerar antalet tester av en enskild funktion. ●För varje parametertilldelningsoperation används det parsade PSD-lagringsformatet för att tilldela värden till varje lagerstruktur i tur och ordning. Tillämpningen av Wings är mycket enkel, följande är ett statistiskt index över genererad testdata med Mysql-kod som kan kompileras normalt i Visual Studio 2015 som exempel, hela genereringsprocessen kräver ingen manuell ingripande, utan behöver bara formulera källkodens väg som ska genereras och drivas. MySQLTestdata | Mysqlversion | | | | Tid det tar att analysera (PSDGenerationstid) | | Tiden det tar att driva genereringen | | Värdet genereras av den tid det tar att generera det | |
Datorkonfigurationsinstruktioner: | Operativsystem | | | Inter(R) Core(TM) i7-7700cpu 3,60GHz | | | | |
Nedan följer resultaten som erhållits med källkodens statistikverktyg, med över 4 miljoner rader giltig enhetstestkod som genereras helt automatiskt av Wings. Det som är ännu mer intressant är att man kan se att kostnaden för manuell utveckling av dessa koder är så hög som 1 079 manmånader, och kostnaden är så mycket som 10,79 miljoner.
Wings har insett det första steget i utforskningen genom programmet att automatiskt generera programmet, den första versionen är för närvarande släppt, intresserade utvecklare kan ladda ner det direkt på kodmolnsplattformen (https://gitee.com/teststars/wings_release), kommersiell licensiering ger en månads obegränsad funktionsupplevelse, du kan snabbt uppleva Wings' magiska kraft, Wings c-språkversion stödjer flera plattformar, såsom Visual Studio, VXWORKS, GCC, QT, osv. Wings är designat och utvecklat av Nebulas testteam (www.teststar.cc), och intresserade utvecklare kan kontakta Nebulas testteam via Codeclouds interaktiva plattform för att bidra med designidéer och feedback på produktanvändning (för de utmärkta förslagen som antagits kan Nebulas förlänga sin fria användningsperiod med minst tre månader). Wings har en stark, underliggande gen som kraftigt förbättrar mjukvarukvaliteten, och i framtiden kommer Wings att djupt optimera läsbarheten hos automatiskt skrivna program (närmare skrivnivån hos duktiga programmerare) och stöd för C++-språket.
|