[C++] Siivet – Anna yksikkötestien generointi älykkäästi ja automaattisesti

Yksikkötestaus on erittäin tehokas keino varmistaa ohjelmiston laatu, olipa kyse sitten varhaisen puuttumisen näkökulmasta testauksessa tai yksikkötestien ominaisuuksista, jotka voidaan varmistaa suurella nopeudella ilman, että käyttöliittymä vaikuttaa siihen. Alan suosittelema testipohjainen kehitys, tässä mainittu testikuljettaja, viittaa enemmän yksikkötestiajuriin. Kuitenkin yleinen kehitystiimi harvoin suorittaa yksikkötestejä järjestelmällisesti, ja sovellusohjelmistojen testauksen suorittavat enemmän ammattimaiset testaustiimit mustan laatikon testien suorittamiseksi. Yksikkötestauksen suurin vaikeus ei ole se, ettei syötettä ja tulosta voitaisi määrittää, sillä ne on jo määritelty moduulin kehitysvaiheessa, vaan se, että yksikkötestitapausten kirjoittaminen vie paljon kehittäjän työtunteja, ja asiaankuuluvien tilastojen mukaan yksikkötestitapausten aika ylittää jopa huomattavasti funktion kehitysajan. Tässä on muutamia yleisimpiä syitä, miksi kehitys ei kirjoita yksikkötestejä:

●Vaatimukset ovat aina loputtomat, ja toiminnallisia vaatimuksia on vielä toteutettava seuraavassa vaiheessa, eikä aikaa täyttää yksikköä

●Yksikkötestejä on liikaa täydennettäväksi, eikä aloitusta ole mahdollista, joten vastustan subjektiivisesti.

● Yksikkötestit ovat vaikeita kirjoittaa. Toisaalta syynä voi olla se, että funktionaalisen funktion toteutus ei ole riittävän kohtuullinen, ja toisaalta ei ole olemassa (tai tuntemattomia) hyödyllisiä yksikkötestikehyksiä ja mock-kehyksiä.

● Yksikkötestit eivät sisälly työkuormaan.

Toiseksi toiminnalliset vaatimukset ovat edelleen epävakaita, eikä yksikkötestien kirjoittamisen kustannustehokkuus ole korkea. Toisin sanoen, jos vaatimukset muuttuvat huomenna, ei ainoastaan toiminnallinen koodi hylätä, vaan myös yksikkötestit. Jos et kirjoita yksikkötestejä, tämä osa vaivaa ei ole turhaa.

Itse asiassa yllä mainittujen seikkojen juurisyy on se, että yksikkötestien kirjoittaminen vie liikaa aikaa, mikä lopulta johtaa testipohjaisen moottorin tehon menetykseen, mikä pysäyttää testauspohjaisen kehityksen kauniin vision todellisessa tilanteessa, koska moottorin rakentaminen tälle ajolle on liian vaikeaa ja kallista. Markkinoilla olevat erilaiset "x"-yksiköt ja yksikkötestauskehykset ratkaisevat vain testipohjaisten ulkokehysten tuottamisen ongelman ilman käyttötapauslogiikkaa ja syvälliseen ohjelmointiymmärrykseen perustuvia datan generointimahdollisuuksia. Siksi se tekee kehittäjistä vastustuskykyisiä erilaisissa kehitykseen liittyvissä tilanteissa. Wingsin julkaisu (tällä hetkellä C:lle) ratkaisee yhden suurimmista ongelmista ohjelmoijille ja voi muuttaa yksikkötestauksen nykytilaa perustavanlaatuisesti, mikä tehokkaasti helpottaa järjestelmätason mustan laatikon testauksen ja automatisoidun testauksen painetta, joka perustuu valtaviin henkilöstöresursseihin.

Rajoitetestitapaukset generoidaan automaattisesti ohjelmien toimesta, ja kriittisin taustalla oleva teknologia on monimutkaisten parametrien jäsennystekniikka. Toisin sanoen se voi mielivaltaisesti määritellä sisäkkäisen tason rekursiivisen jäsentämisen kääntäjätasolla mielivaltaisen monimutkaisille tyypeille. Ilman tätä läpimurtoa tässä kriittisessä teknologiassa automaattinen testitapausten generointijärjestelmä olisi joko kaupallisesti kyvytön tai kehittyisi tuottamaan vaatimustenmukaista testidataa hyvin alhaisella tehokkuudella. Esimerkiksi kuuluisa fuzzing-työkalu American Fuzzy Lop ei pysty tunnistamaan käyttäjän ohjelman vaatimaa rakennetta, vaan sen täytyy kehittää hakualgoritmia uloimman kerroksen mukaan. Ohjelman ominaisuudet ovat, että rajapintatason syöte ja sisäisen moduulin datavaatimukset ovat kaukana, ja ulkoinen data muunnetaan yleensä kerros kerrokselta monimutkaista muunnosta sisäisen moduulin vaatimaksi tietorakennetyypiksi, joten ulkoisen kerroksen tutkimiseen vaadittava laskenta ja aika ovat käsittämättömiä. Amerikkalaisen Fuzzy Lopin pohjalta, jotta voidaan luoda aito SQL-lause, ohjelman sisäinen moduuli täytyy tutkia päivissä, kaukana minuuteista tai tunneista. Toinen rajoite on, että syötteet, jotka kukin ohjelma voi ottaa haltuunsa, ovat huolellisesti jäsenneltyjä ja koottu dataa suurella määrällä sääntöjä, ja näiden tietojen tuottaminen satunnais- + tutkimusmenetelmillä on hyvin epärealistista ja erittäin aikaa vievää. Siksi ei ole mahdollista tuottaa automaattisesti luotuja käyttötapauksia sekä mustasta laatikosta että uloimmasta syötteestä.

Jos käyttötapauspohjainen analyysi perustuu ohjelmiston sisäiseen rakenteeseen, on välttämätöntä ymmärtää syvällisesti ohjelmiston käännösrakenne. Toimivan testitapausgenerointijärjestelmän tulisi perustua ohjelman keskiosaan (avainsisääntulopisteeseen) sopivimpana testien sisääntulopisteenä. Näiden moduulien syötteet ovat muuttaneet epämääräiset syötteet erittäin jäsennellyiksi parametreiksi. Kunhan nämä monimutkaiset rakenteet voidaan tunnistaa, monimutkaiset tietotyypit voidaan vaiheittaisesti hajottaa yksinkertaisiksi tietotyypeiksi ja parametrien rakentaminen voidaan suorittaa samanaikaisesti, jolloin ajokäyttötapausten generointi voidaan automaattisesti suorittaa.

Moduulipohjainen testaus, joka voidaan luokitella perinteiseksi yksikkötestaukseksi, on paras tapa löytää ja hallita vikkoja tutkimus- ja kehitysvaiheessa. Yksikkötestauksen rajoitusten vuoksi on kuitenkin kehitettävä suuri määrä ajureita, ja alan edistäminen ja soveltaminen ovat huomattavasti rajallisia. Tietenkin yksikkötestit voidaan suorittaa myös järjestelmän integroimisen jälkeen, jotta virtuaalisten stub -ohjelmien rakentaminen vältetään.

Nebulas Testingin Wings-tuote, joka lanseerattiin maailmalle ensimmäistä kertaa muutama päivä sitten, on älykäs ja täysin automatisoitu yksikkötestitapausten generointijärjestelmä, joka on tutkinut ja ratkaissut seuraavat haasteet, ja on nyt jaettu kanssasi.

(1) Ohjelman parametrien perusteellinen analyysi

Wings käyttää kääntäjän taustalla olevaa teknologiaa muodostaakseen moduuliobjekteja syötteen lähdetiedoston perusteella funktion mukaisesti. Objekti sisältää funktion syöteparametrit, palautusarvotyypin ja muuta tietoa, jota ajurifunktiomoduuli ja testitapausmoduuli voivat käyttää. Jokainen tiedosto on yksikkö, joka suorittaa perusteellisen analyysin kunkin funktion parametrista ja voi saavuttaa tarkan jäsentämisen ja hajottelun sisäkkäisille tyypeille, kompleksisille tyypeille jne., selittää monimutkaiset tyypit kerros kerrokselta perustietotyypeinä ja tuottaa kuvaustiedoston (PSD) parametrirakenteesta.

(2) Funktiokäyttöinen moduulien automaattinen generointi

PSD-tiedoston muototietojen mukaan kaikki testattavan lähdeohjelman ajuritoiminnot generoidaan automaattisesti, eikä yksikkötestausprosessi enää riipu kehittäjien manuaaliseen testifunktioiden kirjoittamiseen, vaan tarvitsee vain kääntää generoidut ajurifunktiot ja testattavat lähdetiedostot yhdessä, jolloin testitulokset voidaan suorittaa ja testitulokset nähdä. Testiajuri generoi ohjelman automaattisesti PSD-kuvauksen perusteella, rakentaa täysin automaattisesti kaikki parametrit ja tarvittavat globaalit muuttujat, jotka ohjaavat testattavaa testiä, ja voi luoda rakenteellisen testiajurin monimutkaisten muuttujien hierarkian mukaan, mikä säästää paljon aikaa yksikkötestitapausten kirjoittamisessa.

(3) Testidatan automaattinen generointi ja hallinta

Sitä käytetään automaattisesti testidatan tuottamiseen, joka vastaa testifunktion poimimia tietoja, ja data tallennetaan JSON-tiedostoon tietyn hierarkkisen loogisen suhteen kanssa. Hajotelman ja laajennuksen jälkeen data ja tietotyyppi vastaavat toisiaan. Käyttäjät voivat mielivaltaisesti marginalisoida nämä tiedot liiketoiminnan vaatimusten mukaisesti ja käyttää JSON-tiedostoja niiden esittämiseen rakenteellisessa ja hierarkkisessa muodossa, mikä on hyvin selkeää. Testidata sisältää globaalien muuttujien arvot sekä parametriarvot, kun testattava funktio kutsutaan.

Wings tarjoaa yksikkötestausmenetelmän kuljettajien toimintojen automaattiseen generointiin, joka sisältää pääasiassa seuraavat vaiheet:

Kuva 1: Yksikkötestaukseen perustuva rakennusprosessi

Testattavan ohjelman rakennetiedot sisältävät pääasiassa ohjelman globaalit muuttujat ja funktiotiedot, ja funktiotieto sisältää pääasiassa funktion parametrien, parametrityyppien ja palautusarvojen määrän. Tärkeintä on poimia symboli- ja tyyppitiedot joillekin monimutkaisille tyypeille ja analysoida ne perustietotyyppeihin kerros kerrokselta, jotta globaalit muuttujat ja funktioparametrit voidaan rakentaa loppuun.

Muuttujien tyypit jaetaan yleensä perustyyppeihin, rakennustyyppeihin, osoitintyyppeihin ja nollatyyppeihin. Wings käyttää taustalla olevaa käännösteknologiaa käsitelläkseen erilaisia muuttujatyyppejä eri tavoin.

(1) Perustyypit, kuten unsigned int u_int=20, Wings jäsentää muuttujan nimen muotoon u_int ja datatyypin unsigned intiksi.

(2) Rakennustyypit, rakennustyypit jaetaan karkeasti taulukoihin, rakenteisiin, yhteisiin ja luettelotyyppeihin.

● Taulukon tyyppi, kuten intarray[2][3], taulukon nimi on taulukko, tyyppi int ja 2D-taulukon pituus, käyttäytyminen 2, sarake 3.

●Rakenteen tyyppi, rakenteille taulukoina, rakenteisiin linkitettyinä listoina jne., eri merkit jaetaan.

(3) Pointerin tyyppi, esim. int **ptr = 0; , jäsentää osoittimen tason 2 osoittimeksi, jonka tyypin on int.

(4) Null-tyyppi, joka ratkaistaan olevan NULL.

(5) Järjestelmätyypit, kuten Tiedosto, size_t jne., on merkitty järjestelmätyypeiksi ja lisätään mallipohjaan sekä käyttäjä määrittää ne.

(6) Funktion osoitintyyppi, analysoi funktion palautusarvotyyppi, parametrityyppi ja parametrien määrä

Jokaiselle testattavan lähdeohjelman käännösyksikölle jäsennellyt funktiotiedot tallennetaan vastaavaan PSD-rakenteeseen, ja seuraavat lähdekoodiesimerkit kuvataan:

   

Yllä olevassa ohjelmassa void StructTypeTest3(myy_struct mm_struct[2])Tallennettu PSD-rakenne on seuraava:

Jokaisen solmun merkitykset PSD-tiedostossa ovat seuraavat:

●StructTypeTest3 edustaa funktion nimeä, parmType0 parametrityyppiä ja parmNum parametrien määrää

●mm_struct edustaa funktioparametrin symbolia, baseType1 edustaa tyyppien luokittelua (perustietotyyppi, rakennustyyppi, osoitintyyppi, null-tyyppi), tyyppi edustaa tiettyjä tyyppejä, kuten int, char, short, long, double, float, bool sekä nämä allekirjoittamattomat tyypit ja muut perustyypit, ja on olemassa joitakin erityistyyppejä kuten: ZOA_FUN type edustaa funktiotyyppiä, StructureOrClassType edustaa rakennetyyppiä jne., ja nimi edustaa rakenteen, unionin ja enum-tyypin nimeä

●i_int edustaa perustyyppiä, joka on pienin sijoitusyksikkö

●array_one edustaa taulukon tyyppiä, RowSize edustaa taulukon pituutta, ja taulukko voidaan jakaa yksiulotteisiin taulukoihin, kaksiulotteisiin taulukoihin jne

●Piste edustaa osoitintyyppiä, osoitin on jaettu ensimmäisen tason osoittimeen, toisen tason osoittimeen jne., ja yleistä osoitinta käytetään funktioparametrina taulukona, joten perusosoittimessa käytetään dynaamista allokointitaulukkomenetelmää arvojen määrittämiseen, ja käyttäjä voi muokata vastaavaa arvotiedostoa tarpeen mukaan.

● w edustaa bittikentän tyyppiä ja bitfileld numeroiden määrää

●functionPtr edustaa funktioosoitintyyppiä, joka analysoi parametrityypin, parametrien määrän ja palautusarvotiedot vastaavasti

●Dem tarkoittaa konsortiotyyppiä

● dy edustaa enum-tyyppiä, ja arvo edustaa enum-tyypin arvoa

●tiedosto edustaa rakennetyyppiä, SystemVar edustaa tämän muuttujan kuuluvan järjestelmän otsikkotiedoston muuttujaan; tälle muuttujatyypille Wings lisää mallimuuttujia mallipohjakirjastoon, käyttäjät voivat määrittää erityisarvoja erityisten tarpeiden mukaan. Esimerkiksi tiedostotyyppi käsitellään seuraavasti:

Käyttäjät voivat myös lisätä omia määritysmenetelmiään. Järjestelmätyypeissä siivet voidaan erottaa tavallisista käyttäjän määrittelemistä tyypeistä, ja kun jäsentää järjestelmän sisäänrakennettuun tyyppiin, se voi pysäyttää rekursiivisen analyysin alaspäin.

●g_int edustaa globaaleja muuttujia ja globalType edustaa globaaleja muuttujia

●next edustaa linkitettyä listarakennetta, ja NodeType esittää tämän rakenteen linkitettynä listana

●returnType edustaa funktion palautusarvotyyppiä.

Yllä olevassa artikkelissa analysoidaan ja poimitaan globaalien muuttujien ja funktioiden rakenteellinen tieto, ja seuraavia tietoja käytetään PSD-tallennukseen, jotta testattavan lähdeohjelman ajokehys voidaan tuottaa kokonaisuudessaan.

Sukupolvi jakautuu pääasiassa seuraaviin osa-alueisiin:

Ø Globaalimuuttujien julistus

Ø Funktioparametrien määritysoperaatio, funktioparametrien määrän mukaan, määrittele arvot vuorollaan

Ø Globaalien muuttujien määrittäminen suoritetaan järjestyksessä analyysissä käytettyjen globaalimuuttujien määrän mukaan

Ø Alkuperäisen toiminnon kutsu

Huomionarvoisia seikkoja ovat seuraavat:

●Ajureiden generointiprosessin aikana joitakin erityistoimintoja, kuten päätoimintoja, staattisia toimintoja jne., ei käsitellä väliaikaisesti, koska ulkomaailma ei pääse niihin käsiksi.

● Jokaiselle testattavalle lähdetiedostolle luodaan vastaava ajuritiedosto.

● Aseman ohjaus sisältyy Driver_main.cpp funktion testien määrän automaattiseen määrittämiseen makrojen avulla

Yllä olevan lähdeohjelman tuottama ajurifunktio on seuraava:

● Kaikki muuttujat nimetään ennen alkuperäisen muuttujan nimeä, lisää _

●Hankkimalla vastaavat testitiedot muuttujat määrätään vuorollaan

●Järjestelmän sisäänrakennettujen parametrien ja käyttäjän erityisparametrien osalta määritysmenetelmä on yhtenäisesti konfiguroitu mallimenetelmän avulla.

●Määritä ja kutsu parametrit testattavalle funktiolle.

Seuraavassa on joukko PSD-muodossa tuotettua dataa kuvassa 3, jokainen tietojoukko tallennetaan JSON-muodossa, mikä helpottaa tietojen hierarkkisen suhteen näkemistä.

Jokaiselle käännösyksikölle generoidaan oletuksena joukko testidatatiedostoja, jotka vastaavat kaikkia funktioita, ja arvojen generointia voidaan muuttaa konfiguraatioiden määrällä.

Kuinka suorittaa ajurikehyksen generointi, seuraavassa on yksityiskohtainen selitys avoimen lähdekoodin MySQL-ohjelman täydellisestä generointiprosessista.

Seuraavassa on Wingsin Mysql-testauksen pääkäyttöliittymäkaavio:

Klikkaa Tiedosto-painiketta asettaaksesi testattavan lähdeohjelman projektihakemiston. Kun asetukset on valmis, klikkaa funktiotoimintoa, joka sisältää pääasiassa parametrien jäsentämisen, ajurin generoinnin, arvotiedostojen generoinnin ja mallipohjan lisäämisen. Seuraavat kansiot luodaan analyysiä varten:

Näistä parametrien jäsennysmoduuli tuottaa FunXml:n ja GlobalXml:n, jotka tallentavat kunkin poimitun käännösyksikön funktiotiedon ja globaalin muuttujan tiedot.

Ajurigeneraattorimoduuli luodaan vastaavaan kansioon, Wings_Projects tallentaa kunkin käännösyksikön ajuritiedostot

Arvongeneraattorimoduuli tallentaa generoidut testitiedot jokaiselle käännösyksikölle.

Seuraava kuva näyttää Mysql:n lataaman ajuritiedostorakenteen tiedot, ja vasemmalla oleva navigointipuu on generoitu ajuritiedosto, joka sisältää kunkin käännösyksikön toiminnot sekä funktioiden parametrit ja globaalit muuttujat. Klikkaa yhtä käännösyksiköistä ladataksesi vastaavan ajuritiedoston ja vastaavan arvotiedoston.

Yllä oleva on ajuritiedosto ja arvotiedosto, jotka vastaavat koko Mysql:n generointia, ja ajuritiedosto on kuvattu yksityiskohtaisesti seuraavassa koodissa.

● Jokaiselle käännösyksikölle globaalin muuttujan viite on ulkoinen.

●Ajurivunktio on yhtenäisesti nimetty Driver_XXX-menetelmäksi, JSON käytetään testidatan keräämiseen ja ajat kuvaavat yhden funktion testien määrää.

●Jokaisessa parametrien määritysoperaatiossa käytetään jäsenneltyä PSD-tallennusmuotoa arvojen määrittämiseen jokaiselle kerroksen rakenteelle vuorotellen.

Wingsin soveltaminen on hyvin yksinkertaista, seuraavassa on tilastollinen indeksi Mysql-koodilla generoidusta testidatasta, joka voidaan kääntää normaalisti Visual Studio 2015:ssä. Koko generointiprosessi ei vaadi manuaalista puuttumista, tarvitsee vain muotoilla lähdekoodin polku, joka täytyy luoda ja ohjata.

mySQLTestitiedot

Alla on lähdekoodin tilastotyökalulla saatuja tuloksia, joissa Wings on tuottanut yli 4 miljoonaa riviä pätevää yksikkötestikoodia. Vielä mielenkiintoisempaa on, että näiden koodien manuaalisen kehityksen kustannukset ovat jopa 1 079 työviikkoa ja jopa 10,79 miljoonaa.

Wings on toteuttanut ohjelman ensimmäisen tutkimisen askeleen automaattisesti ohjelman luomiseksi, ensimmäinen versio on parhaillaan julkaistu, kiinnostuneet kehittäjät voivat ladata sen suoraan Code Cloud -alustalta (https://gitee.com/teststars/wings_release), kaupallinen lisensointi tarjoaa kuukauden rajattoman käyttökokemuksen, voit nopeasti kokea Wingsin maagisen voiman, Wingsin c-kieliversio tukee useita alustoja, kuten Visual Studio, VXWORKS, GCC, QT jne. Wingsin on suunnitellut ja kehittänyt Nebulaksen testaustiimi (www.teststar.cc), ja kiinnostuneet kehittäjät voivat ottaa yhteyttä Nebulaksen testaustiimiin Codecloudin interaktiivisen alustan kautta jakaakseen suunnitteluideoitaan ja tuotteen käyttöpalautetta (erinomaisista ehdotuksista Nebulas voi pidentää ilmaisen käyttöjakson vähintään kolmella kuukaudella). Wingsillä on vahva, taustalla oleva geeni, joka parantaa ohjelmistojen laatua merkittävästi, ja tulevaisuudessa Wings optimoi syvällisesti automaattisesti kirjoitettavien ohjelmien luettavuutta (lähempänä hyvien ohjelmoijien kirjoitustasoa) sekä C++-kielen tukea.