Интеграционное и системное тестирование

Время чтения: 5 мин

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

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

Кратко

Секция статьи "Кратко"

Интеграционное тестирование проверяет работу нескольких модулей в группе. Системное тестирование проверяет программную систему полностью.

Они решают проблему, которая остаётся после покрытия кода юнит-тестами — проверяют, как модули работают в связи друг с другом. Системное тестирование более обширно и само делится на несколько видов тестов по их типу и назначению.

Системные и интеграционные тесты тоже можно автоматизировать и встроить в CI/CD проекта.

Интеграционное тестирование

Секция статьи "Интеграционное тестирование"

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

Например, проверка одного из сценариев регистрации на бэкенде может быть описана в виде интеграционного теста. Такая проверка затронет и API-эндпоинты, и контроллеры, и общение в базой данных.

Когда использовать

Секция статьи "Когда использовать"

Когда мы хотим проверить работу нескольких модулей, но не всего проекта в целом.

Какие есть инструменты

Секция статьи "Какие есть инструменты"

Среди самых популярных инструментов можно назвать:

Рекомендации к тестам

Секция статьи "Рекомендации к тестам"

Выбрать подход

Есть два подхода к интеграции модулей для тестирования: «большой взрыв» и «инкрементальная интеграция». В первом подходе мы объединяем все модули, а затем проверяем сценарии.

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

Определить критические фичи

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

Подготовить тестовые данные

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

Подготовить заглушки и драйверы

Заглушки и драйверы похожи на стабы и моки. Заглушка вызывается тестируемой группой модулей — проверяет «выход» группы; а драйвер вызывает тестируемую группу — подаёт сигнал на «вход».

Системное тестирование

Секция статьи "Системное тестирование"

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

Их много, но мы выделим самые часто используемые:

  • End-to-end тесты;
  • скриншотные тесты;
  • тесты безопасности;
  • тесты производительности.

E2E-тестирование

Секция статьи "E2E-тестирование"

End-to-end (E2E) тесты — помогают нам имитировать, как пользователи будут работать с нашей программой.

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

  • зайти на такую-то страницу;
  • нажать такую-то кнопку;
  • увидеть такой-то текст.

Когда использовать

Секция статьи "Когда использовать"

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

Инструменты

Секция статьи "Инструменты"

Для описания таких сценариев у нас тоже богатый набор инструментов:

Можно также адаптировать и инструменты для интеграционного тестирования под E2E нужды.

Скриншотное тестирование

Секция статьи "Скриншотное тестирование"

Скриншотным тестированием мы проверяем регрессии пользовательского интерфейса. Сперва мы делаем скриншот-эталон, с которым потом сравниваем интерфейс после изменений.

Если скриншоты совпадают, значит UI остался тем же, и никаких ошибок при изменении кода мы не допустили. Если же скриншоты отличаются, мы что-то упустили из виду.

Когда использовать

Секция статьи "Когда использовать"

Когда мы хотим проверить, что UI остался неизменным после изменения кода.

Инструменты

Секция статьи "Инструменты"

Некоторые из E2E-инструментов содержат и функциональность для скриншотного тестирования:

Тестирование производительности

Секция статьи "Тестирование производительности"

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

Мы также сперва делаем эталонные замеры, с которыми затем сравниваем показатели после изменений кода.

Когда использовать

Секция статьи "Когда использовать"

Когда нам важно, чтобы производительность оставалась на установленном уровне.

Инструменты

Секция статьи "Инструменты"

Мы можем использовать как встроенные в браузер инструменты, так и отдельные сервисы:

Тестирование безопасности

Секция статьи "Тестирование безопасности"

Это больше относится к бэкенду, но иногда такие тесты пишут и для фронтенд-кода тоже. Чаще всего во фронтенде проверяют экранирование пользовательского ввода, защищённость куки и запросы к API.