[C++] Крила - Нека единичните тестове се генерират интелигентно и автоматично

Юнит тестването е много ефективен начин за осигуряване на качество на софтуера, независимо дали става дума за концепция за ранна намеса при тестване или характеристиките на unit тестовете, които могат да се проверяват с висока скорост без да бъдат засегнати от потребителския интерфейс, затова тестово базирано развитие, което индустрията препоръчва – тест драйверът, споменат тук, се отнася повече до unit test driver. Въпреки това, общият екип по разработка все още рядко изпълнява системни unit тестове, а тестовете за приложен софтуер се извършват по-често от професионални тестови екипи за черна кутия тестове. Най-голямата трудност при unit testing не е, че входът и изходът не могат да бъдат определени – все пак те са определени още на етапа на разработка на модула, а че писането на unit test казуси ще отнеме много човешки часове на разработчика, а според съответната статистика времето на unit тестовите случаи дори ще надвиши времето за разработка на самата функция. Ето някои от най-честите причини, поради които разработката не пише unit тестове:

●Изискванията винаги са безкрайни, а все още има функционални изисквания, които трябва да бъдат реализирани на следващия етап, и няма време да се запълни единицата

● Има твърде много модулни тестове, които не могат да бъдат допълнени, и няма как да започна, затова субективно се въздържам.

● Модулните тестове са трудни за писане. От една страна, причината може да е, че реализацията на функционалната функция не е достатъчно разумна, а от друга страна няма (или няма неизвестни) полезни рамки за unit test и имитационни рамки.

● Юнит тестовете не са включени в натоварването.

Второ, функционалните изисквания все още са нестабилни, а разходите за писане на unit тестове не са високи. С други думи, ако изискванията се променят утре, не само функционалният код ще бъде премахнат, но и юнит тестовете. Ако не пишеш unit тестове, тази част от усилията няма да е напразна.

Всъщност основната причина за горните точки е, че писането на unit тестове отнема твърде много време, което в крайна сметка води до загуба на мощност на тестовия двигател, което води до спиране на красивата визия за тестово разработване в реалния сценарий, защото е твърде трудно и скъпо да се построи двигателят за този двигател. Различните "x" единици на пазара и рамки за тестване решават само проблема с генерирането на външни рамки, управлявани чрез тестове, без никаква логика на случаи на употреба и възможности за генериране на данни, базирани на дълбоко разбиране на програмата. Затова това прави разработчиците устойчиви в различни сценарии, свързани с разработката. Пускането на Wings (в момента за C) решава един от най-големите проблеми за програмистите и има потенциала да промени фундаментално статуквото на unit testing, което ефективно ще облекчи натиска от системно ниво black box тестване и автоматизирано тестване, базирано на огромни човешки ресурси.

Тестовите случаи на ограничения се генерират автоматично от програми, а най-критичната основна технология е технологията за парсиране на сложни параметри. Тоест, той може произволно да дефинира вложено рекурсивно парсиране на ниво компилатор за произволно сложни типове. Без този пробив в тази критична технология, автоматичната система за генериране на тестови случаи би била или търговски неспособна, или би се развила, за да произвежда съвместими тестови данни с много ниска ефективност. Например, известният инструмент за fuzzing American Fuzzy Lop не може да идентифицира типа структура, необходим за програмата на потребителя, и трябва да развие алгоритъма за търсене въз основа на най-външния слой. Характеристиките на програмата са, че входът на ниво интерфейс и изискванията за данни на вътрешния модул са далеч, а външните данни обикновено се трансформират слой по слой на сложна трансформация, за да станат тип структура от данни, необходим от вътрешния модул, така че количеството изчисления и времето, необходимо за изследване от външния слой, ще бъде немислимо. Според американския Fuzzy Lop, за да може да се генерира легитимно SQL изявление, вътрешният модул на програмата трябва да бъде изследван за дни, далеч от минути или часове. Друго ограничение е, че входните данни, които всяка програма може да поеме, са внимателно структурирани и компилирани данни с голям брой правила, и е много нереалистично и изключително времеемко да се генерират тези данни чрез случайни + изследователски методи. Затова не е възможно да се генерират автоматично генерирани случаи на употреба както от черната кутия, така и от най-външния вход.

Ако case-driven методът се генерира от анализа на вътрешната структура на софтуера, е необходимо да имате дълбоко разбиране на компилационната структура на софтуера. Жизнеспособна система за генериране на тестови случаи трябва да се базира на средата на програмата (ключова входна точка) като най-подходящата входна точка на теста. Входовете на тези модули са превърнали неясните входове в силно структурирани параметри. Докато тези сложни структури могат да бъдат идентифицирани, сложните типове данни могат да се деградират стъпка по стъпка до прости типове данни, а изграждането на параметрите може да се завършва едновременно, генерирането на случаи на използване на управляващите може да бъде автоматично завършено.

Модулното тестване, което може да се класифицира като традиционно единично тестване, е най-добрият начин за откриване и ограничаване на дефекти във фазата на научноизследователска и развойна дейност. Въпреки това, поради ограниченията на юнит тестването, трябва да се разработят голям брой драйвери, а промоцията и приложението им в индустрията са силно ограничени. Разбира се, unit тестове могат да се изпълняват и след интеграцията на системата, за да се избегне създаването на виртуални кратки програми.

Продуктът Wings на Nebulas Testing, който беше пуснат в света за първи път преди няколко дни, е интелигентна и напълно автоматизирана система за генериране на единични тестови случаи, която е изследвала и решила следните трудности и сега се споделя с вас.

(1) Задълбочен анализ на параметрите на програмата

Wings използва основната технология на компилатора, за да формира модулни обекти въз основа на входния изходен файл според функцията. Обектът съдържа входните параметри на функцията, типа на връщаната стойност и друга информация, която може да се използва от модула на драйверната функция и модула на тестовия случай. Всеки файл е устройство, което извършва задълбочен анализ на всеки параметър от всяка функция в него и може да постигне точен разбор и декомпозиция за вложени типове, комплексни типове и др., да обясни сложни типове слой по слой като основни типове данни и да генерира описателен файл (PSD) на структурата на параметрите.

(2) Автоматично генериране на модули с функция

Според форматната информация на PSD файла, всички драйверни функции на изходната програма се генерират автоматично, а процесът на юнит тестване вече не разчита на разработчиците да пишат тестови функции ръчно, а само трябва да компилират генерираните драйверни функции и изходните файлове под тест, като резултатите от теста могат да се изпълняват и резултатите от теста могат да се разглеждат. Тестовият драйвер автоматично генерира програмата въз основа на описанието на PSD, напълно автоматично изгражда всички параметри и необходимите глобални променливи, които управляват теста, и може да генерира структуриран тестов драйвер според йерархията на комплексните променливи, което може да спести много време при писане на тестови случаи на единици.

(3) Автоматично генериране и управление на тестови данни

Използва се за автоматично генериране на тестови данни, които съответстват на информацията, извлечена от тестовата функция, и данните се съхраняват в JSON файл с определена йерархична логическа връзка. Данните и типът данни след декомпозиция и разширяване съответстват един на друг. Потребителите могат произволно да маргинализират тези данни според бизнес изискванията и да използват JSON файлове, за да ги представят по структуриран и йерархичен начин, което е много ясно. Тестовите данни включват стойностите на глобалните променливи и стойностите на параметрите, когато се извиква тестваната функция.

Wings предоставя метод за тестване на единици за автоматично генериране на функции на водача, който основно включва следните стъпки:

Фигура 1: Поток от изграждане, задвижван от unit тестове

Информацията за структурата на тестваната програма основно включва глобалните променливи и информацията за функциите в програмата, а информацията за функциите включва основно броя на параметрите, типовете параметри и типовете стойности на възвръщаемата стойност на функцията. Най-важното е да се извлече информацията за символите и типовете за някои сложни типове и да се анализират в основни типове слой по слой, за да се завърши изграждането на глобални променливи и параметри на функциите.

Типовете променливи обикновено се делят на основни типове, типове конструкции, типове указатели и нулеви типове. Wings използва основната компилационна технология, за да обработва различни типове променливи по различни начини.

(1) Основни типове, като unsigned int u_int=20, Wings ще парсират името на променливата в u_int и типа данни в unsigned int.

(2) Типовете конструкции, типовете конструкции се разделят грубо на масиви, структури, общи и изброяващи типове.

● Тип масив, като intarray[2][3], името на масива е масив, тип int и дължина на 2D масив, поведение 2, колона 3.

●Тип структура, за структури като масиви, свързани списъци със структури и др., различни маркери се разделят.

(3) Тип указател, напр. int **ptr = 0; , анализира указателя като ниво 2 с int тип.

(4) Нулев тип, който се определя като NULL.

(5) Типовете системи, като File, size_t и др., се маркират като системни типове и се добавят към шаблона и се присвояват от потребителя.

(6) Тип указател на функцията, анализиране на типа на връщаната стойност, типа параметър и броя параметри на функцията

За всяка компилационна единица на тестваната изходна програма информацията за функцията се съхранява в съответната PSD структура, като са описани следните примери с изходен код:

   

В горната програма void StructTypeTest3(myy_struct mm_struct[2])Запазената структура на PSD е следната:

Значенията на всеки възел във файла PSD са следните:

●StructTypeTest3 представлява името на функцията, parmType0 представлява типа параметър, а parmNum – броя параметри

●mm_struct представлява символа на параметъра на функцията, baseType1 представлява класификацията на типове (основен тип данни, тип конструкция, тип указател, нулев тип), тип представлява специфични типове, включително int, char, short, long, double, float, bool, и тези типове беззнакови типове и други основни типове, и има някои специални типове като: ZOA_FUN тип представлява тип функция, StructureOrClassType представлява типа структура и т.н., а името представлява името на типа структура, обединение и enum

●i_int представлява базовия тип, който е най-малката единица за присвояване

●array_one представлява типа масив, RowSize представлява дължината на масива, а масивът може да бъде разделен на едномерни, двумерни масиви и др.

●Точка представлява типа указател, указателят е разделен на първо ниво, второ ниво и т.н., а общият указател се използва като параметър на функцията като масив, така че за основния тип указател се използва методът за динамично разпределение на масив за присвояване на стойности, а потребителят може да модифицира съответния файл с стойности според нуждите.

● w представлява типа битово поле, а bitfileld – броя на цифрите

●functionPtr представлява типа на указателя на функцията, който анализира съответно типа параметъра, броя на параметрите и информацията за връщаната стойност

●Dem означава тип консорциум

● dy представлява типа enum, а стойността представлява стойността на типа enum

●file представлява типа структура, SystemVar представлява тази променлива, която принадлежи на променливата в системния заглавен файл; за този тип променлива Wings добавя шаблонни променливи към шаблонната библиотека, потребителите могат да присвояват специални стойности според конкретни нужди. Например, типът File се обработва по следния начин:

Потребителите могат също да добавят свои собствени методи за разпределение. За типовете системи Wings могат да се различат от обикновените потребителски дефинирани типове, а при парсване към вградения тип на системата могат да спрат рекурсивния анализ надолу.

●g_int представлява глобални променливи, а globalType представлява глобални променливи

●next представлява свързаната структура на списъка, а NodeType представя тази структура като свързан списък

●returnType представлява типа стойност на възвръщаемата стойност на функцията.

В горната статия структурната информация за глобалните променливи и функции се анализира и извлича, а следната информация се използва за запазване в PSD с цел завършване на цялостното генериране на управляващата рамка на изходната програма, която се тества.

Генерирането е основно разделено на следните аспекти:

Ø Декларация на глобални променливи

Ø Операция за присвояване на параметри на функциите, според броя на параметрите на функцията, присвоява стойности на свой ред

Ø Присвояването на глобални променливи се извършва последователно според броя на глобалните променливи, използвани в анализа

Ø Извикване на оригиналната функция

Някои моменти, които трябва да се отбележат, са следните:

●По време на процеса на генериране на драйверите някои специални функции, като основни функции, статични функции и др., не се обработват временно, тъй като не могат да бъдат достъпени от външния свят.

● За всеки тестван изходен файл се генерира съответен драйверен файл.

● Управлението на дисковете е включено в Driver_main.cpp за автоматично конфигуриране на броя тестове на функцията чрез макроси

Драйверната функция, генерирана от горната източникова програма, е следната:

● Всички променливи се именуват преди името на оригиналната променлива, добавете _

●Чрез получаване на съответните тестови данни, променливите се присвояват последователно

●За вградените параметри на системата и специалните параметри на потребителя, методът на присвояване е еднородно конфигуриран чрез шаблонния метод.

●Присвояване и извикване на параметри на тестваната функция.

Следва набор от данни, генерирани в PSD формат на Фигура 3, като всеки набор от данни е запазен в JSON формат, което улеснява виждането на йерархичната връзка между данните.

За всяка компилационна единица по подразбиране се генерира набор от тестови файлове с данни, съответстващи на всички функции, а генерирането на стойности може да се променя според броя на конфигурациите.

Как да завършим генерирането на драйверната рамка, по-долу е подробно обяснение на целия процес на генериране на отворената програма MySQL.

Следва основната интерфейсна диаграма на Wings, който тества Mysql:

Кликнете върху бутона Файл, за да зададете директорията на проекта на изходната програма, която е тествана. След като настройките са завършени, кликнете върху операцията на функцията, която основно включва парсиране на параметри, генериране на драйвери, генериране на стойностни файлове и добавяне на шаблони. Следните папки се генерират за анализа:

Сред тях модулът за парсиране на параметри генерира FunXml и GlobalXml, които съхраняват съответно информацията за функцията и глобалната променлива на всяка извлечена компилационна единица.

Модулът за генериране на драйвери ще бъде генериран Wings_Projects съответната папка, която съхранява файловете на драйверите за всяка компилационна единица

Модулът за генериране на стойност съхранява генерираните тестови данни за всяка компилационна единица.

Следващата фигура показва структурата на драйверния файл, заредена от Mysql, а навигационното дърво вляво е генерираният драйверен файл, който съдържа функциите на всяка компилационна единица, както и параметрите и глобалните променливи на функциите. Кликнете върху една от компилационните единици, за да заредите съответния драйверен файл и съответния файл със стойности.

Горното е файлът с драйвери и файловете със стойности, съответстващи на цялостното генериране на Mysql, а файлът с драйвери е описан подробно в следващия код.

● За всяка компилационна единица референтната на глобалната променлива е по външна променлива.

●Драйверната функция е еднородно наречена Driver_XXX метод, JSON се използва като начин за получаване на тестови данни, а умножаването представлява броя на тестовете на една функция.

●За всяка операция по присвояване на параметри се използва парсиран PSD формат за съхранение, за да се присвояват стойности на всяка слоева структура последователно.

Приложението на Wings е много просто, следва статистически индекс на генерираните тестови данни с помощта на Mysql код, който може да се компилира нормално във Visual Studio 2015, като пример; целият процес на генериране не изисква ръчна намеса, а само да формулира пътя на изходния код, който трябва да бъде генериран и управляван.

mysqlТестови данни

По-долу са резултатите, получени с помощта на инструмента за статистика на изходния код, с над 4 милиона реда валиден тест код, генериран напълно автоматично от Wings. Още по-интересно е, че може да се види, че разходите за ръчна разработка на тези кодове са до 1 079 човеко-месеца, а цената е до 10,79 милиона.

Wings е реализирала първата стъпка в изследването на програмата – автоматично генериране на програмата, първата версия е пусната в момента, заинтересованите разработчици могат да я изтеглят директно от платформата Code Cloud (https://gitee.com/teststars/wings_release), търговското лицензиране осигурява едномесечен неограничен период на функционалност, можете бързо да изпитате магическата сила на Wings, версията на Wings c на език поддържа множество платформи, като Visual Studio, vxworks, gcc, qt и др. Wings е проектиран и разработен от екипа Nebulas testing (www.teststar.cc), а заинтересованите разработчици могат да се свържат с екипа за тестване на Nebulas чрез интерактивната платформа на Codecloud, за да споделят техните идеи за дизайн и обратна връзка за използването на продукта (за отличните предложения, Nebulas може да удължи периода си за безплатно ползване поне с три месеца). Wings има силен, основен ген, който значително подобрява качеството на софтуера, а в бъдеще Wings ще оптимизира дълбоко четимостта на автоматично писаните програми (по-близо до нивото на писане на добрите програмисти) и поддръжката на езика C++.