Research Article

PreventativeTestPro: масштабируемый гибридный фреймворк тестирования, использующий наблюдаемость и генеративный ИИ для проактивной инженерии качества программного обеспечения

DOI:

10.3791/69316

⸱

March 24th, 2026

 ,  ,  , 
1Vishwakarma University, 2Kasetsart University

In This Article

Summary

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Abstract

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Система способствует одновременному проведению тестов с помощью мгновенной анализа журналов на основе ИИ, что способствует непрерывной обратной связи между операциями и тестированием. Он был проверен в нескольких корпоративных сценариях, включая SaaS-платформы на базе микросервисов и экосистемы SAP BTP. Эмпирические результаты четырёх производственных внедрений и бета-группы из 49 инженеров показывают снижение до 30% в среднем времени до устранения, более чем на 95% соответствие SLA и значительное улучшение как в охвате тестов, так и в отслеживании дефектов. Лёгкое подключение к отраслевым стандартам инструментов иллюстрирует его возможность plug-and-play.

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

Introduction

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Растущая популярность гибкой парадигмы в софтверном бизнесе привела к росту интереса к средам непрерывной интеграции. Преимущества таких систем включают бесшовную интеграцию регулярных изменений программ, что приводит к ускоренной и экономичной эволюции программного обеспечения. В результате он эффективно управляет такими задачами, как строительные процедуры, проведение тестов и отчётность по результатам тестов. Тестирование программного обеспечения внедряется с самого начала программной инженерии. Практика тестирования программного обеспечения была внедрена для оценки егокачества 1. Тестирование включает в себя ряд действий, направленных на выявление и устранение возможных ошибок в программном обеспечении до его внедрения конечным пользователям. Тестирование программного обеспечения — это дорогостоящий этап в процессеразработки 2. Стоимость тестирования программного обеспечения и отладки составляет более 50 процентов от общей стоимостиразработки — 3,4. Расходы, связанные с регрессионным тестированием, зависят от сложности применения и масштаба тестового набора5.

Гибкая методология приводит к быстрому внедрению изменений в производстве, что, в свою очередь, приводит к большому числу проблем с поддержкой из-за обратной связи. Управление трудностями поддержки — очень важная и важная ответственность, о чём свидетельствует тот факт, что 68% потребителей выражают готовность платить премию за продукты и услуги от компании, известной превосходным обслуживаниемклиентов 6. Согласно исследованию, 86% клиентов, получающих отличное обслуживание, с большей вероятностью становятся лояльными защитниками бизнеса вдолгосрочной перспективе 7. Согласно исследованию, 89% покупателей более склонны совершать повторные покупки, если у них был положительный опыт обслуживания8. Согласно исследованию, 93% клиентов склонны совершать повторные покупки у компаний, предоставляющих исключительный сервис9. Для предоставления отличного обслуживания клиентов важно оперативно и эффективно решать запросы поддержки с высоким качеством. Качество имеет решающее значение при стремлении к более быстрой доставке, поскольку стоимость решения проблем с поддержкой возрастает со временем, а уровень эскалации— 10.

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

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

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

Чтобы получить представление о том, как отрасль решает вопросы поддержки и проводит профилактическое тестирование, мы провели описательное исследование с помощью интервью с профессионалами в области11. На основе данных интервью было подчеркнуто, что главным препятствием при реализации любого решения является недостаток времени для обеспечения качества. Во время собеседования были отмечены несколько проблем, включая повышение квалификации сотрудников, расходы на обслуживание, низкую отдачу от инвестиций, а также выбор и интеграцияинструментов 11.Эта информация также была подтверждена в «Отчёте о состоянии качества 2024» от Katalon. Прежде чем предложить какие-либо решения по вопросам, упомянутым в интервью, мы провели сравнительную оценку инструментов, чтобы выяснить, существуют ли существующие инструменты или алгоритмы, которые решают указанные вопросы13, 14. Сейчас у нас нет необходимых инструментов или алгоритмов, специально разработанных для решения проблем, обсуждаемых на собеседовании.

Эта работа вводит инновационный метод, использующий данные наблюдаемости для выявления проблем поддержки на ранней стадии (даже до их сообщения) и проведения соответствующих тестовых случаев, тем самым повышая надёжность и надёжность программных систем. Эта стратегия основана на использовании данных наблюдаемости для выявления аномалий, установления связей с вероятными проблемами и инициирования проведения целенаправленных тестовых случаев, которые с высокой вероятностью выявят основную причину проблемы. Предлагаемое решение направлено на сокращение разрыва между операциями программного обеспечения и тестированием, позволяя проактивно и быстро реагировать на поддержку проблем. Предлагаемое решение позволяет создавать новые тестовые случаи, если они отсутствуют в наборе, тем самым улучшая охват тестов. Предлагаемая стратегия также направлена на решение вопросов, поднятых в интервью и в докладеKatalon 11, 12, 13, 14.

Наблюдаемость в контексте теории управления относится к степени, в которой внутренние состояния системы могут быть выведены из её внешних выходов. В области программной инженерии понятие наблюдаемости относится к возможности мониторинга и понимания состояния программной системы с использованием выходных данных, таких как журналы, метрики, следы и события15, 16, 17. Наш анализ литературы включает изучение наблюдаемости и её использования в тестировании программного обеспечения. Однако мы обнаружили ограниченную доступную литературу по этой теме. Поэтому мы также включили обсуждения инновационных профилактических тестов и связанных с ними исследований. Наш обзор литературы дополнительно подразделён на 3 различные группы.

Богатиновский и др.18 представляют CLog — контекстно-ориентированную нейронную сеть и метод кластеризации, предназначенный для решения проблемы нестабильных лог-данных и недостаточного покрытия сбоев путём выявления значимых подпроцессов и обнаружения сбоев на фоне внезапных переходов контекста. Басби и др.19 предлагают методологию на основе логарифма для генерации анонимных тестовых случаев, предсказывая последовательности пользователей для репликации без личных данных; однако вариации уровня параллелизма и логгеров сохраняются как значительные ограничения. Ли иКанг 20 предлагают реализовать архитектуру тестирования для тестирования линейки программного обеспечения, чтобы улучшить наблюдаемость и управляемость в присутствии механизмов изменчивости. Модель QEX21 объединяет данные из различных источников тестирования, предоставляя чёткую и полезную информацию во время проведения испытаний. Лал иКумар, 22 года, подчеркивают важность возможности видеть и контролировать интеллектуальное тестирование. Они рекомендуют использовать автоматизацию на базе искусственного интеллекта, чтобы сделать тестирование быстрее, эффективнее и более тщательным. Бриан и др.23 иллюстрируют применение аспектно-ориентированного программирования в Java для эффективного инструментирования контрактов и инвариантов, тогда как Барал иОффутт 24 подчёркивают проблему ошибочных утверждений в тестах, приводящих к «слепым тестам», которые не выявляют неправильное поведение.

Rott 25 отмечает, что современные анализы и визуализации в Teamscale делают акцент на процессе тестирования программного обеспечения, позволяя тестировщикам получать доступ к обработанным артефактам, специфичным для необходимых задач и ситуации. Коллинз иLucena 26 подчеркивают важность проведения большого количества тестов в CI-конвейере перед развертыванием в продакшн. Говорят, что многоуровневое тестирование — хороший способ убедиться, что продукт качественный, и сократить проблемы с поддержкой.

BugSwarm 27 предлагает метод анализа сбоев тестов CI, сопоставляя коренные причины с соответствующими решениями. Дудила иЛетия 28 изучают методы тестирования белого и чёрного ящика, предлагая согласованную стратегию для снижения усилий по отладке в процессе разработки. Фушихара и др.29 исследовали «тестовые запахи» в приложениях на Python, анализируя их прогрессию через модификации кода для улучшения управления тестовым кодом. SUPERNOVA 30 — это система для отбора тестов и предотвращения неисправностей, использующая данные, автоматизацию и машинное обучение для улучшения качества. Araujo 31 предлагает стратегию обслуживания, ориентированную на старение программного обеспечения. Эта стратегия использует корректирующее обслуживание, когда возможны изменения кода, и профилактические стратегии, когда изменения могут вызвать простои системы, что снижает количество сбоев сервиса. Эндрю и др.32 исследуют параллельное тестирование на мутации — процесс, при котором классы многократно мутируется, тестируются и загружаются до тех пор, пока все варианты не будут оценены. Данн и др.33 предлагают метрики уязвимостей безопасности, которые присваивают веса компонентам, чтобы подчеркнуть важность тщательного тестирования. Наконец, Хо и др.34 используют индекс последовательных множеств для поиска местоположения дефектов и подтверждения проблем. Это показывает, что коренные причины часто связаны с большинством неудачных тестовых случаев в программных приложениях.

Access restricted. Please log in or start a trial to view this content.

Protocol

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Архитектура системы и краткое описание прототипа:

В данном исследовании представлена усовершенствованная и адаптируемая прототипная система PreventativeTestPro, которая демонстрирует проактивный подход к инженерии качества, использующий данные наблюдаемости и крупные языковые модели (LLM) для дальнейшего улучшения решения проблем поддержки. Система стремится решать современные проблемы доставки программного обеспечения, автоматизируя обнаружение аномалий, анализ первопричин, а также интеллектуальное выполнение и разработку тестовых случаев для нерешённого покрытия с использованием синтетического мониторинга, данных наблюдаемости и интеграции с GenAI. Архитектура модульна и состоит из трёх основных компонентов: сборщика и анализатора данных наблюдаемости, слоя интеллекта, управляемого GenAI, и движка оркестрации и исполнения тестов, как подробно указано на рисунке 1.

figure-protocol-1
Рисунок 1: Вход-выход предлагаемой системы. Данные о наблюдаемости, а также выходные данные наблюдателей, тестовый репозиторий и правила картирования, предоставляются в качестве входных данных вместе с тестовыми стендами BHRAMARI, которые создают тестовые стенды на базе ИИ для повышения устойчивости тестовых случаев. Предлагаемая система генерирует инструментирование аномалий, рекомендации, генерируемые ИИ, выполнение соответствующих тестовых случаев, документацию и отчетность, а также выявление и создание отсутствующих тестовых случаев. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 2 показывает архитектуру предлагаемого подхода. На рисунке показаны ввод, обработка и вывод системы. Также даётся всестороннее описание системы, которое затем переводится в объяснение для лучшего понимания основных особенностей.

figure-protocol-2
Рисунок 2: Архитектура системы предлагаемой системы с сборщиком и анализатором данных наблюдаемости, слоем интеллекта на базе GenAI, а также движком оркестрации и выполнения тестов . Этот рисунок иллюстрирует внутреннюю архитектуру системы PreventativeTestPro, разделённую на три слоя: Уровень Observability Collector агрегирует данные из нескольких источников, включая события браузера, логи, HAR-файлы, логи бэкенда, метрики и трассы. Generative AI Intelligence Layer использует эти данные для анализа первопричин, приоритизирования аномалий и автономного создания тестовых случаев (UI, API, руководства) и документации с помощью LLM. Модуль BHARAMARI также создаёт новые испытательные стенды. Engine Test Orchestration and Execution отображает расхождения с тестовыми случаями, выполняет тесты одновременно, оценивает результаты и информирует инженерные команды, системы тикетов и панели управления для контроля и мониторинга разрешений в реальном времени. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Модуль Observability Data Collector and Analyzer служит сенсорной системой платформы, непрерывно собирая данные о оцениваемом приложении в большом масштабе, с несколькими аспектами. В случае фронтенд-мониторинга для мониторинга событий на стороне браузера внедряются синтетические агенты мониторинга, такие как структуры Document Object Model (DOM), действия пользователей, такие как клики, ховеры и входы, а также HAR-файлы, захватывающие информацию о запросах и ответах сети и API. PreventativeTestPro также встроен в OBSERVER для расширения возможностей браузеров. Бэкенд-мониторинг нацелен на анализ логов, при котором запрашивается и обрабатывается информация о наблюдаемости на стороне сервера, включая журналы приложений, сообщения об ошибках, информационные и отладочные сообщения, логи трассировки стека и исключений, метрики производительности, такие как время отклика, и трассировку с использованием технологий, таких как OpenTelemetry или New Relic. Система будет работать с синтетическими агентами, имитирующими пользовательский трафик и взаимодействие, а сборщики журналов конденсируют поступающие данные в реальном времени. Собранные данные затем нормализуются в структурированные форматы и передаются другим вычислительным блокам для дальнейшего анализа.

Суть PreventativeTestPro — это уровень интеллекта, управляемый GenAI, который использует крупные языковые модели (LLM), такие как GPT, для чтения и анализа наблюдаемых данных, а также контекстуализации и генерации ответов. Модуль занимается анализом корневой причины: процессом интерпретации логов и трассировок корневой причины для объяснения технических ошибок с помощью понятных терминов, таких как NullPointerException на определённой строке кода и предполагаемая причина проблемы, например, неинициализированная переменная. При генерации тестовых случаев система использует автотесты, которые генерируются путём преобразования шаблонов исключений или последовательности событий в исполняемые тестовые скрипты, например, тесты Selenium или API, а также создаёт читаемые человеком тестовые процедуры, которые могут запускать сотрудники службы контроля качества. Тесты API эволюционировали за счёт преобразования журналов HAR и трассировки в последовательность запросов API с ожидаемыми утверждениями, а все сгенерированные тестовые случаи дополнительно усовершенствованы эффективными тестовыми стендами за счёт интеграции с BHRAMARI. В системе рекомендаций предлагаются дальнейшие улучшения, расширение покрытия тестов и возможности интеграции CI/CD, в зависимости от поведения анализируемой системы. Движок ИИ использует структурированные данные наблюдаемости с помощью инженерии подсказок и обогащения контекста для представления лог-контекста с помощью шаблонов подсказок, которые передают структурированные запросы в LLM, а затем генерирует результаты в функциональной форме, такие как фрагменты кода, спецификации тестового случая и документация на естественном языке.

Модуль Test Orchestration and Execution Engine управляет приоритетом тестирования, планированием и выполнением, обеспечивая автоматическую валидацию на основе деталей покрытия изменений кода, тегов и отображения аномалий. Отображение и выбор теста включает связывание аномалий в картах или инструментальных паттернах с известными тестовыми случаями с помощью движка правил отображения, а затем выполнение тестовых случаев в соответствии с установленным отображением. Возможности одновременного выполнения тестов позволяют одновременно запускать различные типы тестов, таких как функциональные, производительные или безопасные тесты в различных средах, а также координировать использование Selenium, JMeter и ZAP в качестве инструментов в конвейерах автоматизации. Реализация цикла обратной связи гарантирует, что результаты выполнений ведутся в журнал, а в случае неудачи тестирования изменения передаются поддерживающим системам, включая Jira и Azure DevOps, для их отслеживания и устранения.

Гипотеза:

H1 (операционная эффективность): Считается, что объединение данных наблюдаемости и интеллекта, управляемого ИИ, улучшит операционные показатели, особенно за счёт снижения среднего времени на разрешение (H1a), среднего времени на анализ (H1b), среднего времени обнаружения производственных проблем (H1c) и среднего времени развертывания исправлений в производстве (H1d). Эти изменения должны упростить выполнение требований Соглашения об уровне обслуживания (SLA) (H1e), ускоряя обнаружение, анализ и развертывание, при этом минимизируя простои системы.

H2 (Эффективность тестирования): Также считается, что эффективность тестирования программного обеспечения повысится за счёт увеличения охватов тестов (H2a), параллельного проведения тестовых случаев (H2b) и интеллектуального приоритетирования тестов (H2c). Ожидается, что рекомендации, созданные ИИ (H2D), также помогут как в тестировании, так и в операционных рабочих процессах. Это поможет быстрее выявлять ошибки, ускорять обратную связь и поддерживать профилактические и долговечные практики обеспечения качества.

Тематика и аудитория:

Этот прототип показывает общий дизайн системы, основную идею и пошаговое задание фреймворка PreventativeTestPro. Также подробно объясняется, как настроить правильные тестовые стенды/входные данные для выборок и дают советы по решению проблем. Материал предназначен для инженеров по качеству программного обеспечения, которые уже знают основы Java и хотят научиться использовать профилактическое тестирование для повышения надёжности и эффективности программного обеспечения.

Настройка среды:

Дополнительный файл 1 содержит пошаговое описание и программу, необходимые для общения с PreventativeTestPro. Это включает инструкции по установке необходимой среды, как запускать и останавливать сервисы инструмента, а также чёткое объяснение основного использования инструмента. Чтобы получить более подробную документацию, а также инструкции по использованию продвинутых инструментов, инструкции по настройке и другие организационные детали, обратитесь к официальным источникам GitHub, посвящённым проекту: конкретная страница Wiki в адрес https://github.com/sohambpatel/PreventativeTests/wiki и основной README в https://github.com/sohambpatel/PreventativeTests?tab=readme-ov-file/readme.

Примеры входных данных:

Примеры входных файлов можно найти в репозитории GitHub: https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/Inputs. Фреймворк может сразу запускать заранее заданные тестовые случаи и наборы данных этих файлов. Они используются как опорные входы для проверки настройки среды и получения тех же результатов, что описаны в этом протоколе.

Выходы выборок:

Репозиторий GitHub (https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/SampleOutputs) содержит конкретные образцы выходных данных профилактического тестового фреймворка в сыром виде. С помощью этих файлов пользователи могут напрямую просматривать структуру и детали сгенерированных отчётов и метрик, демонстрируя результаты, достигнутые инструментом в ходе работы. Это руководство важно для изучения конвейера данных и подтверждения ожидаемого поведения фреймворка при воссоздании экспериментального процесса.

Прототип исполнения:

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

На этом этапе PreventativeTestPro GUI можно использовать для выбора лучшего рабочего процесса профилактического тестирования. На рисунке 3 показано пять вариантов, каждый из которых представляет собой отдельный этап процесса тестирования: параллельный запуск тестов, создание тестового набора на основе мониторингового результата путём приоритизации существующих тестовых случаев, создание ручных тестовых случаев, автоматизированное тестирование и поиск коренной причины. Когда пользователь делает выбор, запускается назначенный рабочий процесс. После этого на следующих этапах могут быть добавлены дополнительные режимы (такие как генерация тестовых случаев с помощью ИИ или анализ первопричинных причин). Этот хорошо организованный интерфейс позволяет проводить профилактические испытания, которые можно повторить и разбить на более мелкие части.

figure-protocol-3
Рисунок 3: Пользовательский интерфейс 1 системы. На рисунке показан пользовательский интерфейс PreventativeTestPro, который позволяет выбрать один из пяти различных способов проведения профилактического тестирования: 1. Профилактический тест, параллельное выполнение: начать тестирование, 2. Профилактический тест, финализация набора тестов на основе мониторинга синтетических приложений, 3. Профилактический тест, генерирующий ручные тестовые случаи с помощью GenAI, 4. Профилактический тест, генерирующий автоматизированные тестовые случаи с помощью GenAI, 5. Профилактический тест, Анализ коренных причин с помощью GenAI. В раз можно выбрать только один вариант. Модульный дизайн облегчает проведение профилактических тестов и добавляет создание и диагностику тестов на базе искусственного интеллекта. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

На рисунке 4 показан интерфейс Parallel Execution фреймворка. На этом этапе пользователь вводит URL приложения, которое хочет протестировать, и абсолютный путь к файлу свойств с настройками конфигурации. После настройки входных данных пользователь может одновременно запускать тесты, нажав кнопку Start Testing, которая также отслеживает тестируемый сайт и генерирует журналы безопасности, производительности, консоли и JavaScript. Можно остановить текущее выполнение, нажав кнопку «Остановить тестирование». Кнопка «Получить рекомендацию» позволяет получать инсайты с помощью ИИ из записанных логов. Такой дизайн обеспечивает одновременное выполнение нескольких категорий тестов (функциональных, производительных и безопасных), что облегчает поиск задач и быстрее.

figure-protocol-4
Рисунок 4: Пользовательский интерфейс 2 системы. На рисунке показан режим параллельного выполнения фреймворка PreventativeTestPro. Пользователь указывает URL целевого приложения и путь к файлу свойств с деталями конфигурации. Опции включают Start Testing (для параллельного запуска функциональных, безопасных и производительных тестов и записи журналов), Stop Testing (для остановки выполнения) и Get Recommendation (для получения AI-ориентированных аналитических данных из логов и метрик). Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

На рисунке 5 показан интерфейс финализации тестирования на основе мониторинга фреймворка PreventativeTestPro. На этом этапе пользователь задаёт путь для выходного файла мониторинга, запрос JSON-пути для получения узлов ошибок или исключений, а путь тестового репозитория — для сохранения созданных случаев. После настройки входных данных пользователь сначала может получить имена класса и метода, которые к ним подходят, а затем отсортировать тестовые случаи по тест-пулу по найденному классу и методу. Этот этап приоритизации показывает, как использовать данные мониторинга для эффективного ранжирования тестовых случаев.

figure-protocol-5
Рисунок 5: Пользовательский интерфейс 3 системы. На этом рисунке показано, как приоритизировать тестовый набор в фреймворке PreventativeTestPro с использованием синтетических результатов мониторинга. Пользователь вводит путь к выходному файлу мониторинга, путь JSON для получения исключений/ошибок и путь к тестовому репозиторию (офлайн). Опции Get Class/Method Name и Get Test Cases можно использовать, чтобы превратить аномалии сопоставления в тестовые случаи, которые можно запускать. Это гарантирует, что задачи во время выполнения включены в процесс тестирования. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

На рисунке 6 показан интерфейс ручной генерации тестовых случаев PreventativeTestPro. На этом этапе пользователь указывает программе, где найти файл трассы стека, отображающий аномалию, предоставляя абсолютный путь к файлу трассы стека и путь к файлу свойств конфигурации. После настройки входных данных можно запустить опцию Generate Test Cases, которая превратит аномалию в структурированные ручные тестовые случаи. Это гарантирует, что ранее произошедшие ошибки во время выполнения всегда включаются в процесс тестирования. Фреймворк облегчает создание тестовых случаев за счёт автоматизации процесса. Это сокращает ручную работу, улучшает покрытие тестов и делает тесты более надёжными, а также предотвращает повторение той же проблемы. Этот шаг — очень важная связь между поиском проблем и обеспечением качества до их возникновения.

figure-protocol-6
Рисунок 6: пользовательский интерфейс 3 системы. На этом рисунке показано интерфейс генерации тестовых случаев PreventativeTestPro. Он превращает трассировки стека аномалий в ручные тестовые случаи в Behavior-Driven Development (BDD), которые можно использовать. Пользователь указывает пути к файлу трассы стека и файлу свойств, затем нажимает «Generate Test Cases», чтобы автоматически создать случаи, соответствующие обнаруженному сбою. Это гарантирует, что задачи во время выполнения всегда превращаются в регрессионные тесты, которые можно повторять. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

На рисунке 7 показан интерфейс автоматизированной генерации тестовых случаев PreventativeTestPro. На этом этапе пользователь указывает абсолютный путь к выходному файлу JSON observability и путь к конфигурационному файлу свойства. При нажатии кнопки Generate Automated Test Cases система обрабатывает мониторинговые данные и создаёт тестовые случаи, которые можно запускать, чтобы показать те же проблемы, что и раньше.

figure-protocol-7
Рисунок 7: Пользовательский интерфейс 4 системы. На этом рисунке показана автоматизированный интерфейс генерации тестовых случаев PreventativeTestPro, который создаёт тесты, которые можно запускать с использованием данных наблюдаемости. Пользователь указывает путь к файлу свойств и выходному файлу JSON наблюдаемости. Затем они нажимают «Generate Automated Test Cases», чтобы создать скрипты, которые можно запускать (в форматах Selenium и TestNG). Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

figure-protocol-8
Рисунок 8: Пользовательский интерфейс 5 системы. На этом рисунке показана интерфейс инструментирования аномалий PreventativeTestPro для анализа коренных причин (RCA). Пользователь указывает путь к файлу свойств и файлу трассировки стека, затем выбирает RCA для запуска анализа на основе ИИ. Этот этап превращает обнаруженные аномалии в структурированные диагностические инсайты, что гарантирует устранение неисправностей таким образом, который можно повторять и быть специфичным для конкретной задачи. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Устранение неполадок:

Таблица 1 показывает самые важные точки устранения неполадок, касающиеся только кода приложения. Эти пункты — быстрый способ вспомнить, как исправлять проблемы на уровне кода, возникающие при запуске фреймворка PreventativeTestPro. Документация проекта содержит дополнительную информацию и пошаговые инструкции для читателей, желающих помочь с устранением неполадок, влияющих на общую функциональность приложения. Полный ресурс можно получить по ссылке: https://github.com/sohambpatel/PreventativeTests/wiki/How-to-use%3F. Этот дополнительный справочник гарантирует, что пользователи не только решают проблемы с кодированием, но и учатся устранять функции, что позволяет им эффективнее использовать фреймворк.

Поведение ошибокКоренная причинаКак это исправить?
Подача заявки не начинаетсяJava Path не задаётсяВ переменной Окружение установите JAVA_HOME
Сервер выходит из строя при запускеПорт 8080/9090 используется (в частности, при использовании Docker)Обновление отображения портов Docker
Контент GenAI не является нулевымВозможно, токен истёкСгенерируйте токен и обновите config.properties перед тем, как предоставлять его в качестве входных данных
Экземпляр браузера, сгенерированный фреймворком, не подключается к сетиЛибо сервер ZAP не работает, либо учетные данные ZAP некорректныВключите ZAP перед запуском приложения, если оно работает и проблема сохраняется, обновите учетные данные ZAP в config.properties перед тем, как вводить их

Таблица 1: Распространённые предложенные ошибки системы и быстрые исправления. В этой таблице показаны распространённые ошибки, устранение неполадок и быстрые исправления, которые можно применить для их устранения.

Access restricted. Please log in or start a trial to view this content.

Results

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Результаты отраслевого кейса:

Основываясь на наших исследованиях, которые сосредоточены на практ...

Access restricted. Please log in or start a trial to view this content.

Discussion

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

В данном исследовании представлена PreventativeTestPro — комплексная платформа тестирования и наблюдаемости, объединяющая синтетический мониторинг, данные наблюдаемости и генеративную автоматизацию на базе ИИ для повышения качества программного обеспечения. Система состоит из трёх основных модулей: сборщика и анализатора данных наблюдаемости, генеративного уровня интеллекта на базе ИИ и движка оркестрации и выполнения тестов. В совокупности эти компоненты создают обратную связь, в которо...

Access restricted. Please log in or start a trial to view this content.

Disclosures

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Авторы заявляют, что у них нет известных конкурирующих финансовых интересов или личных отношений, которые могли бы повлиять на работу, описанную в этой статье. Мы подтверждаем, что Близнецы применялись только для грамматической доработки и переформулировки предложений, чтобы их было легче читать. Чтобы быть правильными и этически правильными, авторы тщательно пересмотрели все изменения, предложенные ИИ, чтобы сохранить первоначальную научную коннотацию.

Acknowledgements

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Автор выражает благодарность за значительную поддержку и сотрудничество, оказанные со стороны следующих организаций в ходе этого исследования. Совместные экспериментальные кейсы с этими компаниями сыграли решающую роль в подтверждении предлагаемого инструмента и метода. Выражаем благодарность компаниям GazonTech, Lopa Engineering, Afour Technologies, QJ Technologies и SecureLayer7 за предоставление доступа к практической среде, техническим знаниям и ценным отзывам в ходе экспериментального этапа. Их активное участие значительно повысило практическую значимость и удобство результатов исследования. Автор выражает глубокую благодарность за их готовность участвовать в академических исследованиях и за преданность инновациям и постоянному совершенствованию в областях программной инженерии и кибербезопасности.

Access restricted. Please log in or start a trial to view this content.

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
Apache MavenApache Software Foundation3.9.6Инструмент управления зависимостями и проектами для проектов на Java
ChatGPT (GPT-3.5 Turbo API)OpenAIhttps://platform.openai.com/api-keysДля генерации рекомендаций по тестированию на основе ИИ из логов, ручного создания тестовых случаев, автоматизированных тестовых случаев и анализа первопричины
Компьютер (разработка/тестовая машина)Стандартный настольный компьютер/ноутбук-Используется для разработки, выполнения и тестирования PreventativeTestPro
Дисковое пространство--Рекомендуется не менее 10 ГБ свободного места на диске для логов, отчётов и тестовых артефактов
DockerDocker Inc.27 (https://docs.docker.com/desktop/setup/install/windows-install/) Используется для контейнеризации с целью обеспечения воспроизводимости между средами
ИдиGit SCMGit версии 2.45.2.Windows.1Система контроля версий, используемая для разработки и сотрудничества
Репозиторий GitHubGitHubhttps://github.com/sohambpatel/PreventativeTestsПубличный репозиторий, содержащий исходный код, документацию, наборы данных и примеры
Google ChromeGoogle140.0.7339.128Основной браузер, используемый для синтетического мониторинга и тестирования
ЯваOracle / OpenJDK21.0.2Используется для разработки программного обеспечения и выполнения PreventativeTestPro
Операционная системаНезависимый от платформы-Инструмент работает на любой ОС с установленными Java и Maven (Windows, Linux, macOS).
OWASP ZAPФонд OWASP2.14.0Инструмент сканирования безопасности и обнаружения уязвимостей
Процессор--Intel i5 или выше (или эквивалент) рекомендованы для параллельного выполнения и обработки с помощью ИИ
RAM--Рекомендуется минимум 8 ГБ оперативной памяти для тестов и мониторинга через браузер

References

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  1. A novel approach to multiple criteria based test case prioritization. Abid, R., Nadeem, A. 2017 13th International Conference on Emerging Technologies (ICET), Islamabad, Pakistan, , (2017).
  2. Khatibsyarbini, M., Isa, M. A., Jawawi, D. N., Tumeng, R. Test case prioritization approaches in regression testing: A systematic literature review. Inf Softw Technol. 93, 74-93 (2017).
  3. Enhanced weighted method for test case prioritization in regression testing using unique priority value. Ammar, A., Baharom, S., Ghani, A. A. A., Din, J. 2016 International Conference on Information Science and Security (ICISS), Pattaya, Thailand, , (1109).
  4. Using artificial bee colony for code coverage based test suite prioritization. Konsaard, P., Ramingwong, L. 2015 2nd International Conference on Information Science and Security (ICISS), Seoul, Korea, 10, Forthcoming.
  5. Rosero, R. H., Gómez, O. S., Rodríguez, G. Regression testing of database applications under an incremental software development setting. IEEE Access. 5, 18419-18428 (2017).
  6. Customer Service Expectations 2018. , Gladly. Available at: https://www.gladly.com/blog/2018-customer-service-expectations-survey/ (2018).
  7. Must-Know Customer Service Statistics. , Khoros. Available at: https://khoros.com/blog/must-know-customer-service-statistics (2025).
  8. State of the Connected Customer, 4th Ed. , Salesforce. Available at: https://c1.sfdcstatic.com/content/dam/web/en_us/www/documents/research/salesforce-state-of-the-connected-customer-4th-ed.pdf (2025).
  9. Customer Acquisition Study. , HubSpot. Available at: https://blog.hubspot.com/service/customer-acquisition-study (2025).
  10. IT Ticket Handling Best Practices. , Ivanti. Available at: https://www.ivanti.com/blog/it-ticket-handling-best-practices (2025).
  11. Patel, S., Patil, K., Chumchu, P. Quantitative data set on test prioritization and preventative tests. Mendeley Data. V2, (2023).
  12. State of Software Quality Report 2024. , Katalon. Available at: https://katalon.info/hubfs/download-content/ebook/State%20of%20Software%20Quality%20Report%202024.pdf (2025).
  13. Patel, S., Patil, K., Chumchu, P. OBSERVER: Observing Browser Synthetic Environments for Robotization, Verification, Efficiency, and Resilience. Softw Impacts. 24, 100752(2025).
  14. Patel, S., Patil, K., Chumchu, P. Comparative analysis of software solutions for preventative testing and test prioritization. Mendeley Data. V2, (2024).
  15. Intro to Synthetic Monitoring . , New Relic. Available at: https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/intro-synthetic-monitoring (2025).
  16. Observability Glossary. , SolarWinds. Available at: https://www.solarwinds.com/resources/it-glossary/observability (2025).
  17. Patel, S., Patil, K., Chumchu, P. BHRAMARI: Bug driven highly reusable automated model for automated test bed generation and integration. Softw Impacts. 21, 100687(2024).
  18. Failure identification from unstable log data using deep learning. Bogatinovski, J., Nedelkoski, S., Wu, L., Cardoso, J., Kao, O. 2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid), Taormina, Italy, , (2022).
  19. Creating test cases for testing software using anonymized log data. U.S. Patent. , US11709764B2. USPTO (2023).
  20. Towards test architecture based software product line testing. Lee, J., Kang, S. 2014 IEEE 38th Annual Computer Software and Applications Conference (COMPSAC), Vasteras, Sweden, , (2014).
  21. QEX: Automated testing observability and QA developer experience framework. Locke, H. L., Ting Keshia, Y. K., Yu, J. C. K., Chua, H. Y. 2023 IEEE Conference on Software Testing, Verification and Validation (ICST), Dublin, Ireland, , (1109).
  22. Intelligent testing in software industry. Lal, A., Kumar, G. 2021 12th International Conference on Computing Communication and Networking Technologies (ICCCNT), Kharagpur, India, , (2021).
  23. Instrumenting contracts with aspect-oriented programming to increase observability and support debugging. Briand, L. C., Dzidek, W. J., Labiche, Y. 2005 21st IEEE International Conference on Software Maintenance (ICSM), Budapest, Hungary, , (1109).
  24. An empirical analysis of blind tests. Baral, K., Offutt, J. 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST), Porto, Portugal, , (1109).
  25. Rott, J. Test intelligence: How modern analyses and visualizations in Teamscale support software testing. 2022 1st International Workshop on Visualization in Testing of Hardware, Software, and Manufacturing (TestVis), Oklahoma City, OK, USA, , (2022).
  26. Collins, E. F., de Lucena, V. F. Software test automation practices in agile development environment: An industry experience report. 2012 7th International Workshop on Automation of Software Test (AST), Zurich, Switzerland, , (2012).
  27. BugSwarm: Mining and continuously growing a dataset of reproducible failures and fixes. Tomassi, D. A., Dmeiri, N., Wang, Y., Bhowmick, A., Liu, Y. C., Devan, P. T. 2019 IEEE/ACM International Conference on Software Engineering (ICSE), Montreal, Canada, , (2019).
  28. Towards combining functional requirements tests and unit tests as a preventive practice against software defects. Dudila, R., Letia, I. A. 2013 International Conference on Control Systems and Computer Science (ICCP), Sinaia, Romania, , (2013).
  29. Fushihara, Y., Aman, H., Amasaki, S., Yokogawa, T., Kawahara, M. A trend analysis of test smells in Python test code over commit history. 2023 49th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Durres, Albania, , (2023).
  30. SUPERNOVA: Automating test selection and defect prevention in AAA video games using risk-based testing and machine learning. Senchenko, A., Patterson, N., Samuel, H., Ispir, D. 2022 IEEE Conference on Software Testing, Verification and Validation (ICST), Valencia, Spain, , (2022).
  31. A software maintenance methodology: An approach applied to software aging. Araujo, J., Melo, C., Oliveira, F., Pereira, P., Matos, R. 2021 IEEE International Systems Conference (SysCon), Vancouver, BC, Canada, , Forthcoming.
  32. Mutual Automobile Insurance Company. Mutation Testing in Parallel Threads. U.S. Patent. , US11163675B1. USPTO (2021).
  33. Machine learning-based decision-making for autonomous systems communication. U.S. Patent. , US11366748B1. USPTO (2022).
  34. Use sequential set index for root cause location and problem detection. U.S. Patent. Huo, Z. P., et al. , US11645142B1. USPTO (2023).
  35. Selenium WebDriver. , Selenium. https://www.selenium.dev (2025).
  36. The Katalon Platform. , Katalon. Available from: https://katalon.com (2025).
  37. Apache JMeter. , Apache Software Foundation. Available from: https://jmeter.apache.org (2024).
  38. OWASP ZAP (Zed Attack Proxy). , OWASP Foundation. Available from: https://www.zaproxy.org/ (2025).
  39. Xray by Xpand IT. Xray - Test Management for Jira. , Xray. Available from: https://www.getxray.app (2025).
  40. Tricentis Copilot. , Tricentis. Available from: https://www.tricentis.com/products/copilot/ (2025).
  41. SmartQ Tech Products. , SmartQ Technologies. Available from: https://www.thesmartq.com/smartq-tech-products/ (2025).

Access restricted. Please log in or start a trial to view this content.

Reprints and Permissions

Request permission to reuse the text or figures of this JoVE article

Request Permission

Tags

Hybrid TestingObservability AutomationGenerative AI TestingSoftware Quality EngineeringTest OrchestrationBlack Box TestingWhite Box TestingLog AnalysisRegression CoverageAnomaly Detection

Related Articles