ОПЫТ ИСПОЛЬЗОВАНИЯ ПРЕДИКТИВНЫХ ML-МОДЕЛЕЙ ПРИ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ПО

АННОТАЦИЯ

Тестирование программного обеспечения сопровождается значительными трудозатратами. Автоматизация частично снижает нагрузку, однако объём тестового кода может достигать значительной доли общего объёма проекта. Поэтому задача оценки значимости тестов становится ключевой в управлении качеством. В работе рассматривается опыт создания предиктивной модели, устанавливающей функциональную связь между плотностью дефектов и наличием тестов для конкретных блоков кода. Модель применена как для задач AI-агента по генерации тестов, так и для системы управления тестированием. В качестве среды выполнения использовалась GIGA IDE, а сервис языковой модели был предоставлен GIGA CODE.

ABSTRACT

Software testing remains one of the most labor-intensive stages of software development. Even when testing is automated, the volume of test code frequently approaches a substantial fraction of the overall project codebase, which increases the cost of maintenance and complicates the evolution of the system. This study examines the use of predictive machine-learning models to estimate the influence of individual tests on defect density in the source code. A predictive model based on LSTM architecture was developed to relate structural characteristics of code, test coverage and expected defect density. The model enables the prioritization of unit tests and manual test cases, supports automatic generation and deactivation of tests, and provides mechanisms for optimizing test coverage within an AI-agent integrated into the GIGA IDE environment using GIGA CODE. The proposed approach demonstrates the possibility of reducing defect density without excessive growth of the test codebase, contributing to more efficient management of software quality.

Ключевые слова: AI-агенты; предиктивные модели; генеративные модели; LLM; тест-кейс; unit-тест; автоматизация тестирования; приоритизация тестов; Defect Density; GIGA IDE; GIGA CODE; Java; Spring; Jakarta.

Keywords: AI agents; predictive models; generative models; LLM; test case; unit test; test automation; test prioritization; defect density; GIGA IDE; GIGA CODE; Java; Spring; Jakarta.

Введение

В прикладной разработке программного обеспечения существует правило, согласно которому автоматические тесты (тесты на дым, модульные тесты, интеграционные тесты) должны обеспечивать покрытие не менее 50 % исходного кода ПО [1].

При наличии жёсткой зависимости тестов от прикладного кода они становятся неотъемлемой частью проекта: изменение сигнатур методов (функций, процедур), вызываемых из автоматических тестов, приводит к прямым синтаксическим ошибкам в тестовом коде.

По мере замещения ручных тестов автоматическими возрастает нагрузка на инженеров-разработчиков. Исходный код приложения, требующий поддержки и сопровождения, увеличивается пропорционально доле автоматизированных тестов. При этом в практике прикладной разработки нередко наблюдается ситуация, когда инженеры-разработчики и QA-инженеры, оперируя различными артефактами — исходным кодом и системой управления тестированием (TMS), — дублируют работу друг друга. В результате рост доли кода, покрытого автотестами, не приводит к пропорциональному снижению количества ручных тестов. Подобный эффект, в частности, может проявляться при внедрении концепции Shift Left, что приводит к непропорциональному увеличению трудозатрат на выпуск релизов и ухудшению метрики Lead Time [2].

На первый взгляд может показаться, что данная проблема решается за счёт использования больших языковых моделей (LLM) для генерации тестов, например с применением GIGA CODE. Однако тесты, генерируемые исключительно на основе исходного кода, обладают ограниченной применимостью и в большинстве случаев относятся к категории тестов на дым. Низкая стоимость их генерации делает привлекательной идею существенного увеличения тестового покрытия, что, в свою очередь, приводит к росту общего объёма кода проекта, подлежащего сопровождению. При этом любые изменения в прикладном коде требуют актуализации сгенерированных тестов.

Рост кодовой базы проекта параллельно с ростом плотности покрытия тестами был проанализирован на собственной кодовой базе, результаты чего представлены на рис. 1.

Рисунок 1. Зависимости a) Defect Density (DD) от плотности покрытия тестами всех типов b) Относительный размер кодовой базы от плотности покрытия unit-тестами

Как видно из рис. 1, при увеличении доли кода, покрытого автотестами, сохраняется приблизительно линейный рост общей кодовой базы проекта. При этом отчётливо выделяется интервал значений плотности покрытия (30–70 %), в котором наблюдается снижение плотности дефектов за счёт роста числа автоматических регрессионных тестов.

В связи с этим актуализируется задача оценки вклада каждого конкретного теста в ожидаемое снижение плотности дефектов всего приложения. В практике ручного тестирования аналогичной характеристикой является приоритет теста (priority), который определяется QA-инженером экспертно, исходя из значимости требований. Такой подход может приводить к недооценке значимости тестов с точки зрения сложности и особенностей реализации требований в программном коде. Подход «black box», с одной стороны, не использует апостериорную информацию о коде, с другой — не позволяет корректно приоритизировать тестовые сценарии и управлять затратами на обеспечение качества.

Фактически возникают две близкие по смыслу задачи: приоритизация unit-тестов и переприоритизация ручных тестов с учётом специфики реализации требований в коде. Решение этих задач возможно на основе предиктивной модели, связывающей программный код, подлежащий тестированию, с плотностью дефектов DD (Defect Density).

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

Для достижения поставленной цели в работе решаются следующие задачи: анализ зависимости плотности дефектов от плотности тестового покрытия; формирование набора гипотез о значимости тестов на уровне методов; построение и обучение предиктивной модели на основе структурных характеристик кода; интеграция модели в среду разработки для задач приоритизации тестов, генерации unit-тестов и тестовых кейсов.

Материалы и методы

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

Предполагалось, что функциональная связь между плотностью покрытия unit-тестами и тест-кейсами кода является одинаковой с точки зрения влияния на плотность дефектов DD (Defect Density). Также предполагалось, что как ручные тесты, так и unit-тесты могут быть привязаны непосредственно к методам, фасадирующим части бизнес-логики, а именно к методам публичного API, методам бизнес-логики и методам доступа к данным. Для выявления соответствующих методов и определения их роли использовались маркеры, присутствующие в коде применяемых frameworks.

В рамках модели значимость теста предполагалось определять на основании параметров, характеризующих структуру и сложность программного кода. К таким параметрам были отнесены сложность входных и выходных данных метода, цикломатическая сложность кода метода, а также длина цепочки вызовов по коду. Суммарный вектор параметров целевой функции включал 58 параметров.

На основании выдвинутых гипотез предполагалось сформулировать функцию, явно связывающую ожидаемую плотность дефектов (DD) в исходном коде проекта с наличием или отсутствием теста для соответствующего метода. Вместе с тем сформулированный набор гипотез определил ряд архитектурных и технологических ограничений.

Предполагалось, что анализируемый код реализует слоистую архитектуру (layered architecture) вне зависимости от схемы компоновки по доменам — монолитной или микросервисной. В архитектуре выделялись слои API, Business Logic и Data Access, при этом допускалось смешивание двух из трёх смежных слоёв. Код анализируемых проектов был разработан на языках Java или Kotlin с использованием frameworks Spring и (или) Jakarta (JavaX), обладающих маркирующими аннотациями и интерфейсами для указанных слоёв.

Значимым для тестирования рассматривался только код маркированных методов или публичные методы маркированных типов. Код вызываемых приватных методов, декомпозирующих публичные методы, учитывался опосредованно — через цикломатическую сложность публичных методов по цепочкам вызовов.

Для построения целевой функции использовалась архитектура LSTM (Long Short-Term Memory) [4]. В результате обучения модели удалось достичь значения коэффициента детерминации R² = 0,98. Полученные зависимости плотности дефектов DD от доли методов, покрытых unit-тестами, для различных слоёв layered architecture представлены на рис. 2.

Рисунок 2. Зависимость DD от доли методов, покрытые тестами для разных слоев Layered architecture

Результаты и обсуждение

В результате построения предиктивной модели были получены зависимости плотности дефектов DD от доли методов, покрытых unit-тестами, для различных слоёв слоистой архитектуры приложения. Соответствующие зависимости представлены на рис. 2.

Как видно из представленных графиков, зависимость плотности дефектов от плотности покрытия тестами носит нелинейный характер. Это указывает на возможность оптимизации состава кода, который целесообразно выбирать для покрытия unit-тестами или ручными тестами. В частности, при меньшей плотности тестов наибольший эффект с точки зрения снижения DD демонстрируют тесты для API-слоя.

С одной стороны, поскольку unit-тесты обеспечивают регрессионное тестирование без покрытия нового инкремента функциональности, зависимости не сходятся к нулю при покрытии тестами более 90 %. С другой стороны, доля проектов с таким уровнем покрытия в обучающей выборке недостаточна для того, чтобы в этой области модель обладала сопоставимой прогностической силой по сравнению с областью меньшей плотности покрытия.

Построенная предиктивная модель получила ряд прикладных применений. В частности, модель используется для оценки и переоценки приоритета unit-тестов и тестовых кейсов, генерации новых unit-тестов, деактивации существующих тестов, а также для автоматического создания ручных тестовых кейсов на основе анализа кода. Дополнительно модель применяется для управления приоритетами тестов в системе управления тестированием.

Целевая предиктивная модель была интегрирована в плагин Test Model для GIGA IDE [5], обеспечивающий синхронизацию unit-тестов, описанных в коде, и тестовых кейсов, представленных в системе управления тестами (Test Case Management System). Используемые frameworks JUnit и Allure позволяют детально специфицировать unit-тесты непосредственно в коде. Это снижает зависимость от TMS-систем, однако при невозможности полного отказа от них приводит к расхождениям между фактическим набором тестов в коде и описаниями тестов в TMS. Реализованный плагин направлен на устранение данного расхождения.

Одним из параметров, подлежащих синхронизации, является приоритет теста, который в большинстве случаев задаётся экспертно. Предиктивная модель была использована для валидации и определения приоритета unit-теста, отражённого в TMS в форме соответствующего тестового кейса. Проверка выполняется путём сопоставления фактического значения приоритета теста с его значением, вычисленным на основании влияния теста на плотность дефектов DD.

Формирование шкалы приоритетов было реализовано за счёт расчёта распределения тестов по величине их влияния на DD на обучающей выборке модели. Тесты были сгруппированы по уровню вклада в снижение плотности дефектов, после чего были определены пороговые значения, отделяющие одну группу от другой. Конкретный характер шкалы зависит от используемой TMS-системы. Пример реализации шкалы с тремя уровнями приоритета приведён в таблице 1.

Таблица 1.

Пример реализации шкалы приоритетов тестов

В рамках управления unit-тестами предиктивная модель была также использована как элемент AI-агента (плагин AutoTest для GIGA IDE). Модель применялась для генерации unit-тестов для наиболее значимых с точки зрения влияния на DD элементов проекта, а также для поиска и деактивации наименее значимых unit-тестов с целью снижения затрат на сопровождение программного кода.

В обеих задачах предполагалось, что unit-тесты реализованы с использованием framework JUnit 5. Генерация кода тестов осуществлялась с применением помощника разработчика GIGA CODE [6] в контуре интегрированной среды разработки GIGA IDE. Процедуры сбора контента для генерации тестов, построения pipeline генерации и верификации результата выходят за рамки данной публикации. Деактивация unit-тестов выполнялась без использования LLM-инструментов за счёт добавления аннотации @Disabled (JUnit 5) на уровне класса.

Применение предиктивной модели осуществлялось по следующему алгоритму. На первом этапе код проекта с использованием встроенных инструментов GIGA IDE проверялся на наличие целевых frameworks. При их отсутствии пользователь получал уведомление о невозможности применения агента. Далее на основе маркеров frameworks средствами GIGA IDE строилась редуцированная форма кода, включающая методы и связанные с ними тесты, после чего агент рассчитывал значение метрики DD для текущего состояния проекта.

Для каждого маркированного элемента выполнялся what-if анализ, в рамках которого оценивалось изменение DD в случае генерации нового теста или деактивации существующего. Если для метода отсутствовал unit-тест и его создание приводило к снижению DD более чем на заданный порог T_A, пользователю предлагалось запустить генерацию теста либо генерация выполнялась автоматически в зависимости от настроек. Если для метода существовал unit-тест и его деактивация приводила к ухудшению показателя менее чем на порог T_R, пользователю предлагалось деактивировать тест либо соответствующее действие выполнялось автоматически.

Правила валидации и модификации кода были реализованы в форме отдельных инспекций (inspections) и автоматических исправлений (quick fix), реализованных через API GIGA IDE. Эти правила опирались на модельные значения DD, вычисляемые до модификации кода (DD_B) и после возможной модификации (DD_M).

Плотность вносимых изменений регулировалась за счёт выбора значений порогов T_A и T_R, что позволяло управлять плотностью unit-тестов и объёмом кода, требующего последующего сопровождения. Примеры режимов работы агента с различными наборами пороговых значений представлены в таблице 2.

Таблица 2.

Набора режимов работы агента с разным набором порогов

Третий апробированный сценарий применения предиктивной модели это автоматизация создания ручных тестовых кейсов. Модель была интегрирована в плагин Test Model для GIGA IDE совместно с GIGA CODE и использовалась для формирования новых тестовых кейсов в TMS-системе.

Первые этапы алгоритма совпадали с описанными ранее для unit-тестами.

Далее для каждого маркированного элемента выполнялся what-if анализ, оценивающий снижение DD при создании тестового кейса, покрывающего функциональность соответствующего метода.

Если для метода отсутствовал тестовый кейс и его создание приводило к снижению DD более чем на заданный порог T_A, пользователю предлагалось инициировать генерацию тестового кейса либо генерация выполнялась автоматически.

Генерация тестового кейса включала автоматическое заполнение параметров, приведённых в таблице 3: приоритета, заголовка, описания и шагов.

Формирование текстовых элементов осуществлялось на основе специализированных промтов и анализа кода метода с использованием GIGA CODE.

Таблица 3.

Параметры генерации тестовых кейсов

В отличие от формирования тестовых кейсов по требованиям, описанный подход применим в ситуациях, когда объём тестовых кейсов невелик, а программный код не сопровождается формализованной документацией или требованиями. Сформированные описания и шаги тестового кейса отражают действия, которые может выполнить QA-инженер при тестировании, преимущественно для API-слоя приложения. Данное ограничение учитывалось в реализации, в том числе за счёт использования аннотаций frameworks Spring и Jakarta для выявления публикуемых endpoint-ов.

Плотность генерируемых тестовых кейсов, как и в случае с unit-тестами, регулировалась посредством выбора пороговых значений, что обеспечивало согласованность режимов работы агента.

Заключение

В рамках проведённого исследования были выполнены статистические исследования влияния плотности тестов на плотность дефектов в программном обеспечении. Полученные результаты подтверждают, что с ростом плотности тестового покрытия наблюдается снижение плотности дефектов.

При этом выявлено, что данная зависимость носит нелинейный характер и может сопровождаться пропорциональным ростом количества ручных тестов и (или) unit-тестов, а также увеличением общего объёма кода, подлежащего сопровождению.

Нелинейность выявленной зависимости делает актуальной задачу управления составом тестов и их приоритетами.

Формальное увеличение тестового покрытия не всегда приводит к сопоставимому улучшению показателей качества и может создавать дополнительные затраты на сопровождение программного продукта.

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

На основании проведённого статистического анализа была построена предиктивная модель, предсказывающая влияние конкретного unit-теста для определённого участка программного кода на ожидаемое снижение плотности дефектов.

Модель была внедрена в форме отдельного агента, реализованного как плагин для интегрированной среды разработки GIGA IDE с использованием AI-помощника GIGA CODE.

Разработанный подход был применён для решения задач управления unit-тестами, включая выбор методов для генерации тестов и исключение избыточных тестов, а также для задач управления тестовыми кейсами при необходимости восстановления или уточнения их приоритетов. Практическая апробация модели показала возможность более осознанного управления тестовой инфраструктурой без избыточного роста объёма тестового кода.

Список литературы:

1. Aniche M. Effective Software Testing: A Developer’s Guide. — New York: Simon and Schuster, 2022. — 352 p.
2. Gay G., Staats M., Whalen M., Heimdahl M. The Risks of Coverage-Directed Test Case Generation // IEEE Transactions on Software Engineering. — 2015. — Vol. 41. — P. 803–819.
3. Burke A. S., Chen E. K., Clark T. Y., et al. An Orchestrated Survey of Methodologies for Automated Software Test Case Generation // Journal of Systems and Software. — 2013. — Vol. 86, № 8. — P. 1978–2001.
4. Hochreiter S., Schmidhuber J. Long short-term memory // Neural Computation. — 1997. — Vol. 9, № 8. — P. 1735–1780. — DOI: 10.1162/neco.1997.9.8.1735.
5. Интегрированная среда разработки GIGA IDE [Электронный ресурс]. — URL: https://gigaide.ru/ (дата обращения: 10.12.2025).
6. AI-ассистент разработчика GIGA CODE [Электронный ресурс]. — URL: https://gigacode.ru/ (дата обращения: 10.12.2025).