Использование машинного обучения для повышения эффективности выполнения тестов

Меня зовут Юсуке Шибуи, я работаю в компании Launchable старшим инженером-программистом. Я живу в сфере машинного обучения и написал несколько книг, в которых обсуждается производство систем машинного обучения. Посмотрите, если можно:

* Шаблон проектирования системы машинного обучения (японский) * Практическое руководство по разработке систем машинного обучения (на японском языке)

TL/DR: в этом блоге обсуждается выбор прогностического теста, который — это метод, который применяет ML для повышения эффективности выполнения тестов. Если вы инженер, который борется со временем/стоимостью выполнения теста, читайте дальше.

Тестирование в современной разработке программного обеспечения

В 2002 году вышла книга Разработка через тестирование". out, и с тех пор написание тестов в разработке программного обеспечения стало нормой. Затем распространились облако и DevOps, установив тем самым практику выполнения тестов в конвейерах CI/CD< /a> автоматически для обеспечения качества кода/продукта. Здесь есть всевозможные «тесты»: юнит-тесты, интеграционные тесты, системные тесты и так далее.

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

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

Исторически CI/CD выполнялась в управляемой инженером среде, такой как Jenkins. Сегодня доступны размещенные автономные службы непрерывной интеграции, такие как GitHub Actions и Обведите CI. Как и облачные сервисы, такие как AWS Code Pipeline и Azure Pipelines. Службы управления выполнением тестов E2E включают mabl и autify. В написании кода, включая написание тестов, по-прежнему преобладают локальные компьютеры для разработки, но выполнение тестов все больше смещается в сторону автоматизации в бесплатных или платных облачных средах.

По мере расширения ваших сервисов и роста кода тесты также увеличивают свой объем/тип. Особенно среди долго работающих сервисов количество тест-кейсов увеличивается, как увеличивается мертвый код: тесты, о которых вы не знаете, когда они появились, тесты, которые вы не знаете, что они тестируют. Эти проблемы отрицательно сказываются на продуктивности разработчиков по двум причинам:

1. Время и время выполнения CI/CD стоимость ненужных тестов
2. Люди теряют мотивацию для проведения ненужных тестов.

В результате запуска CI/CD в сервисах выполнение тестов стоит денег. Разработчики, ожидающие завершения тестов, увеличивают время, затрачиваемое разработчиками на обновление/объединение запросов на вытягивание. Сокращение времени цикла приводит к тому, что в руки пользователей попадает быстро улучшающийся ценный продукт. Чтобы сократить время выполнения тестов, мы часто прибегаем к распараллеливанию тестов или улучшениям среды выполнения тестов, но это приводит к увеличению затрат на услуги CI/CD, включая временные затраты. По мере роста продукта и программного обеспечения время выполнения тестов и эффективность разработчиков, как правило, снижаются (или растут затраты).

Вторая «стоимость людей &amp;amp;amp;amp;amp;amp; фактор мотивации еще более проблематичен. Я уверен, что каждый вновь написанный тест имел вескую причину, но по мере изменения программного обеспечения некоторые тесты неизбежно становятся ненужными. Однако для выяснения того, стало ли это ненужным, требуется знание спецификаций продукта/программного обеспечения. Насколько мне известно, большинство команд подходят к удалению тестов более консервативно, чем к удалению кода — вы не знаете, кто написал эти тесты, и вы не хотите нести ответственность за проблемы с качеством, вызванные этим удалением. В результате люди, которые поддерживают эти ненужные тесты, в конечном итоге тратят время на усилия, которые им не нужны. ценны.

Я хочу сказать, что написания тестов и их выполнения в CI/CD недостаточно для решения проблем поддержания качества и повышения производительности труда разработчиков.

Что такое прогнозирующий выбор теста?

Если в 2000-х появилась разработка через тестирование, а в 2010-х — CI/CD, то одна из новых тенденций 2020-х — Predictive Test Selection (PTS). Meta (ранее Facebook) представила этот метод повышения эффективности выполнения тестов, при котором машинное обучение используется для выбора тестов, важных для данного запроса на вытягивание.

Блог: Прогнозный выбор тестов: более эффективный способ обеспечения надежности изменений кода

Документ: https://arxiv.org/pdf/1810.05286.pdf

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

Когда код небольшой, а тестов мало, можно сделать вывод, что «если вы измените этот код, этот тест может провалиться» и/или «эти тесты часто терпят неудачу, возможно, они снова провалятся». Но по мере того, как программное обеспечение становится больше, это становится непрактичным. Predictive Test Selection использует журнал изменений кода и историю выполнения тестов в качестве входных данных и применяет машинное обучение для определить, какие тесты с большей вероятностью не пройдут для данного запроса на вытягивание.

В документе используются следующие функции:

* История изменений для файлов * Мощность файла * Целевая кардинальность * Расширения файлов * Количество отдельных авторов * Историческая частота отказов * Название проекта * Количество тестов * Минимальное расстояние между файлами и целями * Количество общих токенов

Целевыми данными обучения являются двоичные тесты "пройдено/не пройдено". Вышеуказанные функции вводятся в дерево принятия решений по повышению градиента (GBDT). GBDT — это алгоритм, сочетающий повышение градиента, ансамбль моделей и деревья решений. Популярная реализация включает XGBoost и LightGBM. Известно, что это очень эффективный метод обучения на табличных данных. В документе говорится, что они выбрали GBDT, потому что алгоритм легко доступен, быстро обучается, хорошо работает при положительных значениях & отрицательные случаи не сбалансированы и могут обрабатывать порядковые/категориальные данные.

Данные о прохождении/непрохождении теста записываются из журнала CI/CD для запросов на вытягивание вместе с данными об изменении кода/теста. Данные для обучения собираются автоматически по мере выполнения CI/CD.

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

Ценность модели заключается в том, чтобы находить тесты, которые могут дать сбой< /сильный>. Выполнение успешных тестов приводит к ненужному времени ожидания выполнения теста и ресурсам теста. И наоборот, отсутствие неудачных тестов приводит к потенциальным проблемам с качеством программного обеспечения. Predictive Test Selection упаковывает выбранные тесты с тестами, которые с наибольшей вероятностью не пройдут. Выбирая подмножество значимых тестов из всех тестов, он сокращает время ожидания, снижает стоимость и повышает качество за счет запуска неудачных тестов. Проведение изменений через тесты делает цикл выполнения тестов более эффективным при разработке программного обеспечения.

Тесты переупорядочены в зависимости от вероятности неудач. Это приводит к более быстрому отказу CI/CD и сокращает время, необходимое для начала работы над исправлением кода. Представьте, что у вас есть набор тестов, выполнение которого занимает 120 минут. Давайте воспользуемся Predictive Test Selection, чтобы выбрать 60-минутные тесты, которые с наибольшей вероятностью не пройдут. Если вы выполняете их случайным образом, в среднем инженеры будут ждать сбоя 30 минут. Теперь, если вы выполняете тесты в том порядке, в котором они могут дать сбой, то вероятность того, что этот набор тестов не сработает в течение первых 5 минут, станет намного выше. Это означает, что инженеры могут начать работу над изменением уже через 5 минут.

В эпоху, когда выполнение тестов CI/CD является нормой, а разработчики ждут, пока тесты появятся, — обычное дело, я знаю, что вы можете увидеть ценность времени ожидания CI/CD, которое увеличилось с 30 до 5 минут, независимо от вашего размер инженерной организации.

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

Анализ тестовых данных, такой как Predictive Test Selection, выявляет еще одну проблему — ненадежные тесты. Ненадежные тесты — это случайно не пройденные тесты. Когда вы изменяете несвязанный код или когда вы вообще не изменяете код, если тест по какой-то причине (например, из-за внешних причин или ограниченных ресурсов) не проходит тест, такие тесты называются ненадежными. Ненадежность трудно устранить, и часто достаточно простого повторного выполнения, чтобы они исчезли, поэтому борьба с неустойчивостью, как правило, теряет приоритет.

Что такое ненадежный тест?

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

Predictive Test Selection делает вывод о тестах, которые, скорее всего, не пройдут из-за внесения изменений в код. Поэтому желательно, чтобы среди выбранных тестов не было flaky. Поскольку ненадежность носит случайный характер, записывая результаты выполнения теста, можно рассчитать уровень ненадежности теста. Predictive Test Selection может исключить несвязанные ненадежные тесты из подмножества, тем самым устраняя ненужное выполнение тестов и сортировку сбоев.