[C++] Крила — Дозвольте модульні тести генеруватися інтелектуально та автоматично

Юніт-тестування є дуже ефективним засобом забезпечення якості програмного забезпечення, чи то з точки зору концепції раннього втручання у тестування, чи характеристик юніт-тестів, які можна перевірити на високій швидкості без впливу інтерфейсу, тому тест-орієнтована розробка, яку пропонує індустрія, тест-драйвер, більше стосується юніт-тест-драйвера. Однак загальна команда розробників досі рідко систематично виконує модульні тести, а тестування додаткового програмного забезпечення більше виконують професійні тестувальні команди для виконання тестів у чорній скриньці. Найбільша складність юніт-тестування полягає не в тому, що вхід і вихід не можна визначити, адже це вже визначено на етапі розробки модуля, а в тому, що написання модульних тестів забере багато людських годин розробника, а за відповідною статистикою час юніт-тесту навіть значно перевищить час розробки самої функції. Ось кілька найпоширеніших причин, чому розробка не пише юніт-тести:

● Вимоги завжди безмежні, і ще є функціональні вимоги, які потрібно реалізувати на наступному етапі, і часу на заповнення одиниці немає

● Занадто багато юніт-тестів, які потрібно доповнювати, і немає способу почати, тому я суб'єктивно опираюся.

● Юніт-тести складно писати. З одного боку, причина може полягати в тому, що реалізація функціональної функції недостатньо розумна, а з іншого — немає (або невідомих) корисних фреймворків юніт-тесту та мок-фреймворків.

● Юніт-тести не включені до навантаження.

По-друге, функціональні вимоги залишаються нестабільними, а витрати на написання юніт-тестів невисоки. Іншими словами, якщо завтра вимоги зміняться, буде скасовано не лише функціональний код, а й юніт-тести. Якщо ви не пишете юніт-тести, ця частина зусиль не буде марною.

Насправді корінь наведених пунктів полягає в тому, що запис юніт-тестів надто трудомісткий, що зрештою призводить до втрати потужності тестового двигуна, що призводитиме до зупинки прекрасного бачення тест-орієнтованої розробки в реальному сценарії, оскільки створення двигуна для цього приводу надто складне і дороге. Різні пристрої «x» на ринку та фреймворки для тестування одиниць вирішують лише проблему генерації зовнішніх кадрів, керованих тестуванням, без логіки використання та можливостей генерації даних на основі глибокого розуміння програм. Отже, це робить розробників стійкими до різних сценаріїв, пов'язаних із розробкою. Випуск Wings (наразі для C) вирішує одну з найбільших проблем для програмістів і має потенціал докорінно змінити статус-кво юніт-тестування, що ефективно зменшить тиск від системного чорного ящика та автоматизованого тестування на основі величезних людських ресурсів.

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

Якщо кейс-орієнтований на використання генерується аналізом внутрішньої структури програмного забезпечення, необхідно глибоко розуміти структуру компіляції програмного забезпечення. Життєздатна система генерації тестових випадків має базуватися на середині програми (ключовій точці входу) як на найбільш відповідній точці входу в тест. Вхідні дані цих модулів перетворили нечіткі входи на високо структуровані параметри. Поки ці складні структури можна ідентифікувати, складні типи даних можна поступово розкладати до простих типів, а побудову параметрів можна завершити одночасно, генерація кейсів використання драйверів може бути автоматично завершена.

Модульне тестування, яке можна класифікувати як традиційне модульне тестування, є найкращим способом виявлення та виявлення дефектів на етапі НДДКР. Однак через обмеження юніт-тестування потрібно розробити велику кількість драйверів, а просування та застосування в галузі значно обмежені. Звісно, після інтеграції системи також можна виконувати юніт-тести, щоб уникнути створення віртуальних заглушених програм.

Продукт Wings від Nebulas Testing, який вперше був запущений у світі кілька днів тому, є інтелектуальною та повністю автоматизованою системою генерації одиничних тестових випадків, яка вивчила та вирішила наступні труднощі і тепер доступна для вас.

(1) Глибокий аналіз параметрів програми

Wings використовує базову технологію компілятора для формування об'єктів модулів на основі вхідного вихідного файлу відповідно до функції. Об'єкт містить вхідні параметри функції, тип поверненого значення та іншу інформацію, яку можуть використовувати модулі драйверної функції та модуль тестового випадку. Кожен файл є одиницею, яка виконує глибокий аналіз кожного параметра кожної функції в ньому і може досягти точного розбору та розкладу для вкладених типів, комплексних типів тощо, пояснювати складні типи шар за шаром як базові типи даних і генерувати файл опису (PSD) структури параметрів.

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

Згідно з форматною інформацією файлу PSD, усі драйверні функції тестуваної програми автоматично генеруються, і процес юніт-тестування більше не залежить від ручного написання тестових функцій розробниками, а лише потрібно скомпілювати згенеровані драйверні функції та вихідні файли разом, після чого результати тестування можна виконати та переглянути. Тестовий драйвер автоматично генерує програму на основі опису PSD, повністю автоматично створює всі параметри та необхідні глобальні змінні, які керують тестуванням, і може генерувати структурований тестовий драйвер відповідно до ієрархії комплексних змінних, що дозволяє значно заощадити час при написанні одиничних тестових кейсів.

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

Він використовується для автоматичної генерації тестових даних, які відповідають інформації, отриманій тестовою функцією, і дані зберігаються у JSON-файлі з певною ієрархічною логічною залежністю. Дані та тип даних після декомпозиції та розгортання відповідають один одному. Користувачі можуть довільно маргіналізувати ці дані відповідно до бізнес-вимог і використовувати JSON-файли для структурованого та ієрархічного відображення, що є дуже зрозумілим. Тестові дані включають значення глобальних змінних і значення параметрів, коли викликається функція, що тестується.

Wings надає метод юніт-тестування для автоматичної генерації функцій водія, який в основному включає такі кроки:

Рисунок 1: Потік збірки, керований юніт-тестом

Інформація про структуру програми, що тестується, переважно включає глобальні змінні та інформацію про функції в програмі, а інформація про функції — кількість параметрів, типи параметрів і типи повернених значень функції. Найважливіше — витягти інформацію про символи та типи для деяких складних типів і проаналізувати їх на базові типи даних шар за шаром, щоб завершити побудову глобальних змінних і функційних параметрів.

Типи змінних зазвичай поділяються на базові типи, типи конструкцій, типи вказівників і нульові типи. 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 додає змінні шаблону до бібліотеки шаблону, користувачі можуть призначати спеціальні значення відповідно до конкретних потреб. Наприклад, тип файлу обробляється наступним чином:

Користувачі також можуть додавати власні методи призначення. Для типів систем Wing можна відрізнити від звичайних типів, визначених користувачами, і при парсінгу з вбудованим типом системи можна зупинити рекурсивний аналіз вниз.

●g_int представляє глобальні змінні, а globalType — глобальні змінні

●next представляє структуру зв'язаного списку, а NodeType — цю структуру як зв'язаний список

●returnType позначає тип поверненого значення функції.

У наведеній вище статті аналізується та вилучається структурна інформація глобальних змінних і функцій, а наступна інформація використовується для збереження в PSD з метою завершення загальної генерації керуючої структури тестуваної програми.

Генерація переважно поділяється на такі аспекти:

Ø Декларація глобальних змінних

Ø Операція призначення параметрів функції, відповідно до кількості параметрів функції, по черзі присвоює значення

Ø Призначення глобальних змінних виконується послідовно відповідно до кількості глобальних змінних, що використовуються в аналізі

Ø Виклик оригінальної функції

Деякі моменти, на які варто звернути увагу, такі:

●Під час процесу генерації драйвера деякі спеціальні функції, такі як основні функції, статичні тощо, не обробляються тимчасово, оскільки до них не може отримати доступ для зовнішнього світу.

● Для кожного тестуваного вихідного файлу генерується відповідний драйверний файл.

● Керування приводом включено в Driver_main.cpp для автоматичного налаштування кількості тестів функції за допомогою макросів

Функція драйвера, згенерована вищезазначеною вихідною програмою, виглядає так:

● Усі змінні мають імена перед іменем оригінальної змінної, додайте _

●Отримуючи відповідні тестові дані, змінні призначаються по черзі

●Для вбудованих параметрів системи та спеціальних параметрів користувача метод призначення уніфіковано налаштований через шаблонний метод.

●Призначити та викликати параметри функції, що перевіряється.

Нижче наведено набір даних, згенерованих у форматі PSD на рисунку 3, кожен набір даних збережений у форматі JSON, що полегшує розгляд ієрархічного взаємозв'язку даних.

Для кожного компіляційного блоку за замовчуванням генерується набір тестових файлів даних, що відповідають усім функціям, а генерацію значень можна змінювати за кількістю конфігурацій.

Як завершити генерацію драйверного фреймворку, нижче наведено детальне пояснення повного процесу генерації відкритої програми MySQL.

Нижче наведено основну діаграму інтерфейсу для тестування Mysql у Wings:

Натисніть кнопку «Файл», щоб встановити каталог проєкту програми-джерела, що тестується. Після завершення налаштувань натисніть на функцію, яка в основному включає парсінг параметрів, генерацію драйверів, генерацію файлів значень і додавання шаблону. Для аналізу генеруються такі папки:

Серед них модуль парсингу параметрів генерує FunXml і GlobalXml, які зберігають інформацію про функції та глобальну змінну для кожного витягнутого компіляційного блоку відповідно.

Модуль генерації драйверів буде згенерований Wings_Projects відповідній папці, яка зберігає файли драйверів для кожного блоку компіляції

Модуль генерації цінності зберігає згенеровані тестові дані для кожного блоку компіляції.

Наступне зображення показує структуру файлу драйвера, завантажену Mysql, а навігаційне дерево зліва — це згенерований файл драйвера, який містить функції кожного блоку компіляції, а також параметри та глобальні змінні функцій. Натисніть на один із блоків компіляції, щоб завантажити відповідний файл драйвера та відповідний файл значень.

Вищенаведено файл драйвера та файл значення, що відповідають загальному генерації Mysql, і файл драйвера детально описаний у наступному коді.

● Для кожної компіляційної одиниці посилання глобальної змінної є зовнішнім.

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

●Для кожної операції призначення параметрів для присвоєння значень кожній структурі шару використовується формат зберігання PSD.

Застосування Wings дуже просте: нижче наведено статистичний індекс згенерованих тестових даних із використанням коду Mysql, який можна нормально скомпілювати у Visual Studio 2015, наприклад, увесь процес генерації не потребує ручного втручання, достатньо сформулювати шлях вихідного коду, який потрібно згенерувати та керувати.

mySQLТестові дані

Нижче наведено результати, отримані за допомогою інструменту статистики вихідного коду, з понад 4 мільйонами рядків дійсного коду одиничного тесту, повністю автоматично згенерованих Wings. Ще цікавіше те, що можна побачити, що вартість ручної розробки цих кодів сягає 1 079 людино-місяців, а вартість — до 10,79 мільйона.

Wings зробила перший крок у дослідженні програми — автоматична генерація програми, перша версія вже випущена, зацікавлені розробники можуть завантажити її безпосередньо на платформу cloud коду (https://gitee.com/teststars/wings_release), комерційне ліцензування забезпечує місячний період необмеженого функціонального досвіду, ви можете швидко відчути магічну силу Wings, версія Wings мовою c підтримує кілька платформ, таких як visual studio, vxworks, gcc, qt тощо. Wings розроблений і розроблений командою тестування Nebulas (www.teststar.cc), і зацікавлені розробники можуть зв'язатися з командою тестування Nebulas через інтерактивну платформу Codecloud, щоб поділитися своїми ідеями дизайну та відгуками про використання продукту (за чудові пропозиції Nebulas може продовжити період безкоштовного використання щонайменше на три місяці). Wings має потужний, прихований ген, який значно покращує якість програмного забезпечення, і в майбутньому Wings глибоко оптимізує читабельність автоматично написаних програм (ближче до рівня письма хороших програмістів) та підтримку мови C++.