AI-система приоритизации тестов (Test Impact Analysis AI)

Мы сталкивались с проектами, где полный тестовый прогон занимал 40–90 минут. Один из клиентов — продуктовая команда из 25 разработчиков — делала более 100 коммитов в день. Каждый коммит блокировался на час, пока CI прогонял 1200 тестов. Разработчики уходили пить кофе, а потом переключались на другие задачи. Тесты запускали всё реже, баги всплывали в проде. Запускать все тесты на каждый коммит — дорого и медленно. Test Impact Analysis (TIA) — метод выбора минимального набора тестов по изменениям в коде. AI-подход расширяет классический TIA за счёт исторического анализа: какие тесты исторически находили баги в этих компонентах. Наш опыт показывает, что такой подход сокращает время CI в 3–5 раз без потери качества.

Как AI-приоритизация сокращает время CI?

Классический TIA работает через code coverage mapping: запускает все тесты с инструментацией, записывает какой тест покрывает какой файл, при следующем изменении выбирает только тесты, покрывающие изменённые файлы. Точный, но требует полного coverage-прогона как baseline.

AI-подход добавляет исторический сигнал:

• Тесты, которые исторически падали при изменениях в данном компоненте.
• Тесты с высокой семантической близостью к изменённому коду (через code embeddings).
• Тесты, покрывающие функции, использующие изменённые API.

class AITestSelector: def __init__(self, coverage_db, history_db, code_encoder): self.coverage_db = coverage_db # test → file coverage map self.history_db = history_db # history of test failures by change self.encoder = code_encoder # CodeBERT/UniXcoder embeddings def select_tests(self, changed_files: list[str], changed_diffs: list[str]) -> list[str]: # Coverage-based candidates coverage_tests = self.coverage_db.get_tests_for_files(changed_files) # History-based candidates history_tests = self.history_db.get_historically_related(changed_files) # Semantic similarity candidates diff_embedding = self.encoder.encode(changed_diffs) semantic_tests = self.find_semantic_matches(diff_embedding) # Merge and rank by failure probability all_candidates = coverage_tests | history_tests | semantic_tests return self.rank_by_failure_probability(all_candidates, changed_files) 

Почему классический TIA недостаточен?

Он не учитывает, что тест может покрывать файл, но не проверять критическую логику. Например, изменение в utils.py может затронуть все модули, но coverage покажет только тесты, напрямую тестирующие utils. AI-подход через эмбеддинги находит тесты, логически связанные с изменениями. Кроме того, классический TIA не ранжирует тесты по вероятности падения — мы запускаем их в порядке убывания риска, чтобы fast feedback приходил быстрее.

Как ранжировать тесты по вероятности падения?

После формирования набора кандидатов применяем ранжирующую модель LightGBM, обученную на истории CI. Признаки для ранжирования:

• Время последнего падения теста при изменении данного компонента.
• Cosine similarity между diff-эмбеддингом и эмбеддингом теста.
• Глубина покрытия: тест покрывает изменённую строку напрямую или через 2–3 вызова.
• Признак «критический тест»: тест связан с платёжным функционалом, аутентификацией и т.д.
• Исторический flakiness score теста.

Тесты ранжируются по убыванию failure_probability, CI запускает их в таком порядке — fast feedback приходит быстрее, так как тесты с высоким риском стартуют первыми.

Адаптивный выбор стратегии

Система автоматически переключается между режимами в зависимости от контекста изменений:

Кейс из практики

Один из проектов (1200 тестов, среднее время прогона 55 минут) испытывал постоянные задержки в CI при числе коммитов более 100 в день. После внедрения TIA AI среднее время CI для feature-коммитов сократилось до 12 минут — это ~78% ускорения. Процент запускаемых тестов на коммит составил 22% в среднем, при этом за полгода не было зафиксировано ни одной пропущенной регрессии. Ключевым фактором стала настройка исторического анализа: модель обучилась на 10 000+ предыдущих прогонов и научилась отличать изменения, затрагивающие критическую функциональность. Получите консультацию инженера — мы проанализируем ваш проект и спрогнозируем ускорение CI.

Шаги внедрения AI-приоритизации

1. Инструментирование сборщика coverage — настройка pytest-cov, JaCoCo или аналогов.
2. Сбор исторических данных CI — выгрузка пайплайнов, результатов прогонов, изменений.
3. Обучение ранжирующей модели (LightGBM) на вашем проекте.
4. Интеграция в пайплайн — GitHub Actions, GitLab CI, Jenkins, Buildkite.
5. Настройка дашборда метрик — среднее время CI, процент запускаемых тестов, количество пропущенных регрессий.
6. Документация и передача — сопровождение в течение месяца после внедрения.

Что входит в работу

При внедрении мы предоставляем:

• Инструментирование сборщика coverage (pytest-cov, JaCoCo, etc.) и настройка baseline.
• Сбор исторических данных CI (пайплайны, результаты прогонов, изменения).
• Обучение ранжирующей модели (LightGBM) на вашем проекте.
• Интеграцию в пайплайн (GitHub Actions, GitLab CI, Jenkins, Buildkite).
• Дашборд метрик: среднее время CI, процент запускаемых тестов, количество пропущенных регрессий.
• Документацию по настройке и сопровождению.

Интеграция

Поддержка GitHub Actions, GitLab CI, Jenkins, Buildkite. Плагины для pytest, JUnit, Go test, Jest. Хранение coverage map и исторических данных в PostgreSQL или ClickHouse.

Закажите внедрение AI-приоритизации тестов — наши инженеры оценят ваш проект и предложат решение под ключ с гарантией результата.