Анализ воздействия тестирования — что это такое, как его протестировать и все остальное, что вам нужно знать

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

Несмотря на взрывной рост DevOps, только 10 % опроса Harvard Business Review< /a> респонденты описывают свой бизнес как «очень успешный в быстрой разработке и развертывании программного обеспечения».

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

Для команд, в которых медленные циклы тестирования мешают быстрой разработке, анализ влияния тестирования — это способ ускорить цикл разработки, выполняя только те тесты, которые относятся к измененному исходному коду.

Что такое анализ воздействия тестирования?

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

Традиционно анализ воздействия при тестировании программного обеспечения часто основывается на статическом анализе исходного кода для построения графиков зависимостей между кодом и тестами.

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

Например, вы можете вести список тестов, связанных с каждым модулем или компонентом в вашей системе, и обновлять этот список по мере внесения изменений.

Как выполнить анализ влияния теста

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

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

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

Практический пример кода Python: анализ влияния ручного тестирования

В приведенном ниже фрагменте кода имена тестов сопоставляются с компонентами, с которыми они связаны. В этом примере у нас есть три модуля:

* Авторизоваться * Создание аккаунта * Сброс пароля

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

# Define a dictionary that maps test names to the modules or components they are testing
tests_by_component = {
    "test_login": ["login_module"],
    "test_account_creation": ["account_creation_module"],
    "test_password_reset": ["password_reset_module"]
}

# Define a list of the components that have been modified
# This should be dynamically generated based on the code changes.
modified_components = ["login_module"]

# Determine which tests are likely to be affected by the changes
affected_tests = []
for test, components in tests_by_component.items():
    for component in components:
        if component in modified_components:
            affected_tests.append(test)

# Now, we can pass the affected tests to our test harness.
print(affected_tests)  # Output: ["test_login"]

Преимущества и проблемы анализа влияния тестирования

При эффективном выполнении анализ влияния тестирования дает множество преимуществ, в том числе:

* Сокращение времени, затрачиваемого на повторное тестирование

* Повышение общей эффективности процесса тестирования

* Лучшее опыт разработчика

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

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

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

Тестирование программного обеспечения в растущей организации: обычное состояние тестирования

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

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

Куда мы идем дальше?

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

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

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

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

Команда инженеров начинает беспокоиться, что такое положение дел неустойчиво.

* Что произойдет, если кто-то объединит неработающий код, потому что он проигнорировал тест, который выявил бы проблему?

* Сколько денег команда тратит на облачные ресурсы, чтобы постоянно повторять ненадежные тесты, которые они в конечном итоге игнорируют?

* Сколько времени они тратят на ожидание запуска тестов?

Главный технический директор стартапа решает, что пора погасить технический долг DevOps, прежде чем это приведет к дорогостоящему инциденту.

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

Усовершенствованный анализ воздействия тестирования с помощью предиктивного выбора тестов

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

Launchable демократизирует подход Predictive Test Selection, чтобы он был доступен для команд любого размера одним нажатием кнопки.

Predictive Test Selection от Launchable решает задачу Анализа влияния тестирования, используя возможности машинного обучения для оптимизации разработки программного обеспечения. Predictive Test Selection использует интеллектуальные данные, чтобы определить, какие тесты лучше всего подходят для каждого типа изменений.

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

В отсутствие этой практики командам приходится вручную создавать подмножества "выкурить тесты" или распараллелить их тесты.

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

Практический пример кода Python: выбор предиктивного теста с помощью Launchable и Pytest

Благодаря Launchable вам не нужно угадывать, какие тесты выполняются, и постоянно обновлять набор для анализа влияния тестов. Вот пример Python того, как Launchable может работать с платформой Pytest.

Настройка и выполнение Pytest с возможностью запуска

1. Установите pytest-launchable в своей среде с помощью pip3 install pytest-launchable

2. Создайте запускаемый файл конфигурации, запустив launchable-config --create.

3. Создайте ключ запускаемого API из https://app.launchableinc.com/

1. Установите его как переменную среды LAUNCHABLE_TOKEN на компьютере, на котором будут выполняться тесты.

   4. Из каталога, содержащего файл конфигурации Launchable, запустите pytest --launchable <your-pytest-project>

Ваши результаты pytest будут отправлены в Launchable. Затем Launchable начинает обучать модель машинного обучения на результатах ваших тестов с течением времени. Модель оптимизирует тесты, которые с наибольшей вероятностью окажутся полезными при минимальном времени тестирования.

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

Благодаря прогностическому выбору тестов Launchable команды обычно видят < a href="https://docs.launchableinc.com/features/predictive-test-selection/faq">сокращение времени тестирования на 60–80 % без ущерба для качества.

Основные причины, по которым организации выбирают функцию интеллектуального выбора Launchable:

* Экономьте время разработчиков

* Сокращение расходов на инфраструктуру

* Отправляйте код быстрее

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

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

Launchable легко интегрируется с вашим CI, независимо от частоты коммитов или количества веток Git, которые у вас есть. Он поддерживает все приложения и языки, и команды сообщают о сокращении времени тестирования до 90 % без какого-либо влияния на качество.