Норматив учитывает ИИ или ИИ учитывает норматив. Умеем и то и то.
ИИ не заменил разработчиков, а стал им помощником. Эта помощь может выражаться как в скорости решения рутинных задач, так и в качестве при решении сложных задач.
Когда агент гарантированно закроет какой-то фронт работ, безусловно, это скажется на трудоемкости типовых работ в сторону уменьшения.
Что касается корректности выбора норматива и сложности на задаче при оценке, то да, ИИ это проверяет и формирует определенный отчет для владельцев этой практики для понимания, что можно еще улучшить, чтобы команды выбирали корректные типовые работы и сложности при оценке трудоемкости задач.
2) На данный момент мы используем языковую модель Qwen3-30B-A3B, развернутую через vLLM. Это трансформерная LLM семейства Qwen (аналог GPT-подобных моделей), распространяемая с открытыми весами под лицензией Apache 2.0, что допускает коммерческое использование, модификацию и развертывание в инфраструктуре заказчика.
3) Тесты генерируются тестировщиком по мере необходимости при добавлении нового функционала. Мы автоматизировали процесс тестирования – если ранее при добавлении функционала пользователь писал тест каждый раз под новый функционал, теперь ему необходимо под этот новый функционал описать сценарий, а тест за него напишет LLM. Насчет анализа нового кода агентом напрямую без описания сценария пользователем, тут вопрос не в логичности, а в ограничении ресурсов. Анализ кодовой базы – процесс непростой, для этого необходимо использовать модели с сильно бОльшим контекстом.
В дальнейшем планируется развитие агента – одним из направлений развития как раз и является генерация пользовательского сценария по измененному коду с помощью LLM. В этом случае дальнейшая цепочка генерации теста не изменится, поменяется лишь способ получения исходного сценария (тест-кейса).
4) QA должен понимать какой функционал тестируется, какие входные и выходные данные для тестирования функционала должны использоваться. Глубокое понимание архитектуры проекта ему не требуется.
Пользователь, который подает на вход сценарий, подает его осознано, т.е. знает и понимает какие эндпоинты и для чего используются.
В качестве примера рассмотрим следующий кейс.
Пользователь задает сценарий в терминологии бизнеса: "Добавь тип суммы, поменяй у него название, удали его, проверь, что его больше нет #apionly"
ИИ как раз отбирает необходимые эндпоинты:
POST /agreement-amount-type
PUT / agreement-amount-type/{agreementAmountTypeld}
Если какие-то параметры не будут учтены в одном из вариантов автотестов, то тест не будет пройден, ИИ получит ошибку, прочитает ее и исправит тест относительно текста ошибки.
5) В промте у нас описаны правила построения автотеста, а также в некоторых инструкциях мы явно указываем, как делать не надо. Также от чуши спасает абстрагирование от деталей вызова API/события за счет использования заготовленных методов (определенных в Groovy-сервисе для запуска тестов). То есть LLM не нужно знать, как подключаться к брокеру или как звать API по REST. LLM использует заготовленные нами "кубики" и понимает, что в случае отбора API POST/api/request надо в тесте использовать метод clientPost(), а в случае отправки события и ожидания ответа – sendEventAndWaitForReply().
Дополнительно после отбора API/событий мы проверяем их наличие в документации. Если это результат фантазий LLM, то тест генерироваться не будет. Если LLM сильно фантазирует при генерации теста, то мы это пресекаем проверкой валидности теста при запуске – откровенная «чушь» успехом при запуске не завершится.
Защита от логических ошибок в тестах происходит на нескольких уровнях:
1) После указания пользовательского сценария (заявленного тест-кейса) сначала происходит отбор API/событий по семантической близости с заявленным тест-кейсом. После этого отобранные API/события явно выводятся пользователю, и он может проваладировать корректность их отбора.
При этом дополнительно после отбора API/событий и ответа от LLM мы сопоставляем отобранные API/события с задокументированными. Если в документации такие API/события мы не находим, то тест далее не генерируется.
2) Наш Groovy-сервис, который запускает сгенерированные моделью тесты, включает в себя обертки для осуществления REST/асинхронных запросов. Мы определяем методы (clientPost(), clientGet(),sendEventAndWaitForReply()), которые скрывают детальную реализацию REST/асинхронного взаимодействия. Логика в методах детерминирована.
При обращении к LLM с просьбой составить тест мы передаем системный промпт, в котором четко регламентируем структуру теста с примерами – явно указываем, какие методы разрешено использовать (наши высокоуровневые – clientPost(), clientGet(), sendEventAndWaitForReply()). То есть мы снимаем с модели нагрузку на продумывание детальной реализации отправки POST запроса или взаимодействия с брокером – это мы берем на себя, а модели нужно лишь позвать нужные "кубики".
3) Помимо этого, результаты работы модели выводятся в чат, и пользователь может наблюдать за процессом генерации теста. Пользователю виден тест на каждой итерации генерации, виден лог после запуска теста – при анализе теста он видит какие "кубики" использовались и входные параметры, которые LLM посчитала нужным проставить. После запуска теста в логах он видит результат вызова API/отправки/получения события – выходные параметры выводятся в лог.
Спасибо за внимательность! Вы правы, конфигурация стенда важна. Мы поправили опечатку в статье, тесты проводились на сети 25GbE.
Однако ваш тезис про "упор в сеть" остается актуальным. Тем не менее, тесты релевантны по двум причинам:
1. Эффективность ресурсов (CPU/RAM). Чтобы просто забить сеть до предела S3 Архипелаг использовал 28% доступной мощности. Это означает, что у нас остается большой запас вычислительной мощности, который можно реализовать, использовав более быструю сеть.
2. Тесты на IOPS (мелкие файлы) и LIST-операции (метаданные) упираются не в пропускную способность сети, а в архитектуру хранения и работу с диском. Там сеть не является "узким горлышком", и именно там S3 Архипелаг демонстрирует кратный отрыв от конкурентов (в 2-3 раза быстрее).
Тест показывает главное: мы получаем максимум из доступного канала с минимальными затратами ресурсов сервера.
При чтении система проверяет контрольные суммы. Если обнаружено повреждение, а данные реплицированы, запрос перенаправляется на здоровую копию - клиент получает корректные данные.
Для борьбы с последствиями появления "битого" участка мы настроили мониторинг алертов и периодическую проверку целостности томов. При обнаружении bit rot поврежденные тома восстанавливаются из здоровых реплик.
В планах полностью автоматизировать этот процесс, чтобы система сама восстанавливала поврежденные блоки в фоновом режиме.
Для полноценной работы базы MS SQL Server в Digital Q.DataBase ее нужно предварительно перенести (смигрировать) в собственный формат Digital Q.DataBase.
В первую очередь, данную функциональность выбирают клиенты, которым нужно решение из РРПО, сертифицированное ФСТЭК, или поддержка вендора - лидера рынка
Данное решение реализовано для работы с временными таблицами, содержащий key-value наполнение.
Норматив учитывает ИИ или ИИ учитывает норматив. Умеем и то и то.
ИИ не заменил разработчиков, а стал им помощником. Эта помощь может выражаться как в скорости решения рутинных задач, так и в качестве при решении сложных задач.
Когда агент гарантированно закроет какой-то фронт работ, безусловно, это скажется на трудоемкости типовых работ в сторону уменьшения.
Что касается корректности выбора норматива и сложности на задаче при оценке, то да, ИИ это проверяет и формирует определенный отчет для владельцев этой практики для понимания, что можно еще улучшить, чтобы команды выбирали корректные типовые работы и сложности при оценке трудоемкости задач.
1) Нет, конкретное действие делать нет необходимости. Успешный тест выкладывается автоматически в репо продукта.
2) В тесте может быть вызов API или отправка\получения события, на каждый тест у нас отображаются логи в диалоге с ИИ, пользователь их видит.
1) У нас развернуто внутри контура Диасофт.
2) На данный момент мы используем языковую модель Qwen3-30B-A3B, развернутую через vLLM. Это трансформерная LLM семейства Qwen (аналог GPT-подобных моделей), распространяемая с открытыми весами под лицензией Apache 2.0, что допускает коммерческое использование, модификацию и развертывание в инфраструктуре заказчика.
3) Тесты генерируются тестировщиком по мере необходимости при добавлении нового функционала. Мы автоматизировали процесс тестирования – если ранее при добавлении функционала пользователь писал тест каждый раз под новый функционал, теперь ему необходимо под этот новый функционал описать сценарий, а тест за него напишет LLM. Насчет анализа нового кода агентом напрямую без описания сценария пользователем, тут вопрос не в логичности, а в ограничении ресурсов. Анализ кодовой базы – процесс непростой, для этого необходимо использовать модели с сильно бОльшим контекстом.
В дальнейшем планируется развитие агента – одним из направлений развития как раз и является генерация пользовательского сценария по измененному коду с помощью LLM. В этом случае дальнейшая цепочка генерации теста не изменится, поменяется лишь способ получения исходного сценария (тест-кейса).
4) QA должен понимать какой функционал тестируется, какие входные и выходные данные для тестирования функционала должны использоваться. Глубокое понимание архитектуры проекта ему не требуется.
Пользователь, который подает на вход сценарий, подает его осознано, т.е. знает и понимает какие эндпоинты и для чего используются.
В качестве примера рассмотрим следующий кейс.
Пользователь задает сценарий в терминологии бизнеса: "Добавь тип суммы, поменяй у него название, удали его, проверь, что его больше нет #apionly"
ИИ как раз отбирает необходимые эндпоинты:
POST /agreement-amount-type
PUT / agreement-amount-type/{agreementAmountTypeld}
DELETE / agreement-amount-type/{agreementAmountTypeld}
GET / agreement-amount-types
Затем происходит генерация теста.
Если какие-то параметры не будут учтены в одном из вариантов автотестов, то тест не будет пройден, ИИ получит ошибку, прочитает ее и исправит тест относительно текста ошибки.
5) В промте у нас описаны правила построения автотеста, а также в некоторых инструкциях мы явно указываем, как делать не надо. Также от чуши спасает абстрагирование от деталей вызова API/события за счет использования заготовленных методов (определенных в Groovy-сервисе для запуска тестов). То есть LLM не нужно знать, как подключаться к брокеру или как звать API по REST. LLM использует заготовленные нами "кубики" и понимает, что в случае отбора API POST/api/request надо в тесте использовать метод clientPost(), а в случае отправки события и ожидания ответа – sendEventAndWaitForReply().
Дополнительно после отбора API/событий мы проверяем их наличие в документации. Если это результат фантазий LLM, то тест генерироваться не будет. Если LLM сильно фантазирует при генерации теста, то мы это пресекаем проверкой валидности теста при запуске – откровенная «чушь» успехом при запуске не завершится.
Защита от логических ошибок в тестах происходит на нескольких уровнях:
1) После указания пользовательского сценария (заявленного тест-кейса) сначала происходит отбор API/событий по семантической близости с заявленным тест-кейсом. После этого отобранные API/события явно выводятся пользователю, и он может проваладировать корректность их отбора.
При этом дополнительно после отбора API/событий и ответа от LLM мы сопоставляем отобранные API/события с задокументированными. Если в документации такие API/события мы не находим, то тест далее не генерируется.
2) Наш Groovy-сервис, который запускает сгенерированные моделью тесты, включает в себя обертки для осуществления REST/асинхронных запросов. Мы определяем методы (clientPost(), clientGet(),sendEventAndWaitForReply()), которые скрывают детальную реализацию REST/асинхронного взаимодействия. Логика в методах детерминирована.
При обращении к LLM с просьбой составить тест мы передаем системный промпт, в котором четко регламентируем структуру теста с примерами – явно указываем, какие методы разрешено использовать (наши высокоуровневые – clientPost(), clientGet(), sendEventAndWaitForReply()). То есть мы снимаем с модели нагрузку на продумывание детальной реализации отправки POST запроса или взаимодействия с брокером – это мы берем на себя, а модели нужно лишь позвать нужные "кубики".
3) Помимо этого, результаты работы модели выводятся в чат, и пользователь может наблюдать за процессом генерации теста. Пользователю виден тест на каждой итерации генерации, виден лог после запуска теста – при анализе теста он видит какие "кубики" использовались и входные параметры, которые LLM посчитала нужным проставить. После запуска теста в логах он видит результат вызова API/отправки/получения события – выходные параметры выводятся в лог.
Спасибо за внимательность! Вы правы, конфигурация стенда важна. Мы поправили опечатку в статье, тесты проводились на сети 25GbE.
Однако ваш тезис про "упор в сеть" остается актуальным. Тем не менее, тесты релевантны по двум причинам:
1. Эффективность ресурсов (CPU/RAM). Чтобы просто забить сеть до предела S3 Архипелаг использовал 28% доступной мощности. Это означает, что у нас остается большой запас вычислительной мощности, который можно реализовать, использовав более быструю сеть.
2. Тесты на IOPS (мелкие файлы) и LIST-операции (метаданные) упираются не в пропускную способность сети, а в архитектуру хранения и работу с диском. Там сеть не является "узким горлышком", и именно там S3 Архипелаг демонстрирует кратный отрыв от конкурентов (в 2-3 раза быстрее).
Тест показывает главное: мы получаем максимум из доступного канала с минимальными затратами ресурсов сервера.
При чтении система проверяет контрольные суммы. Если обнаружено повреждение, а данные реплицированы, запрос перенаправляется на здоровую копию - клиент получает корректные данные.
Для борьбы с последствиями появления "битого" участка мы настроили мониторинг алертов и периодическую проверку целостности томов. При обнаружении bit rot поврежденные тома восстанавливаются из здоровых реплик.
В планах полностью автоматизировать этот процесс, чтобы система сама восстанавливала поврежденные блоки в фоновом режиме.
Отправьте, пожалуйста, ваш вопрос в службу поддержки по e-mail: supportqdb@diasoft.ru, и вам помогут разобраться.
Для полноценной работы базы MS SQL Server в Digital Q.DataBase ее нужно предварительно перенести (смигрировать) в собственный формат Digital Q.DataBase.
В первую очередь, данную функциональность выбирают клиенты, которым нужно решение из РРПО, сертифицированное ФСТЭК, или поддержка вендора - лидера рынка
Данное решение реализовано для работы с временными таблицами, содержащий key-value наполнение.