[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 представляет тип структуры и т.д., а имя — название типа struct, union и enum

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

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

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

● w — тип битового поля, а bitfileld — количество цифр

●functionPtr представляет тип указателя функции, который анализирует тип параметра, количество параметров и информацию о возвратных значениях соответственно

●Dem — тип консорциума

● dy обозначает тип enum, а value — значение типа 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 реализовала первый этап исследований программы — автоматическая генерация программы, первая версия уже выпущена, заинтересованные разработчики могут скачать её напрямую на облачную платформу (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++.