«Нам нужно сделать регрессионное, функциональное и интеграционное тестирование» — а ты автоматизатор и уже задумываешься о том, что попал куда‑то не туда. Или же ты новичок, решивший пойти в тестировщики, смотришь вакансии и видишь, что этих видов тестирования чуть ли не сотня. Как же понять, что от тебя требуют и куда идти? Попробуем разобраться.
Важно сразу сказать, что виды тестирования разделяют по категориям — всё равно что разработчиков делят не только по яп, но и по тому, где этот яп применяется. Ведь java backend разработчик и java mobile разработчик это совершенно разные вещи!
Для начала разберемся, кто выполняет тесты
Здесь бизнес отвечает на вопрос «а кто будет проводить тесты?» и от этого уже пляшет дальше. По сути практически все виды тестирования можно проводить, либо ручным, либо автоматизированным способом. По этому приписка manual или automation отвечает только за то, своими руками ты будешь всё проверять, или будешь писать автоматизированные тесты.
Ручное тестирование
— сам тестировщик берет и ручками открывает сайт, тыкает регистрацию, пытается заказать помидор и смотрит, корректно ли всё работает.
Инструменты:
TestRail — хранилище тест‑кейсов с возможностью сбора статистики и запуска тестов
Xray — плагин для Jira, который позволяет получить функционал TestRail внутри Jira
Zephyr — аналогично Xray
Такой способ хорош, когда нужно быстро проверить новую поставку или за 5–10 минут убедиться, что продуктовый сайт не начал предлагать в продажу ванные от смежной системы. Однако, это всё одноразовая история и абсолютно не подходит для случаев, когда требуется проверять кучу разных сценариев сразу.
Автоматизированное тестирование
— а вот здесь уже начинается код для настоящих мужиков. В том плане, что ты не проверяешь сайт самостоятельно, а пишешь сценарии, эмулирующий работу пользователей.
Инструменты:
PlayWright — фреймворк для автоматизации браузеров, поддерживающий Chromium, Firefox и WebKit. Работает с динамическими веб‑приложениями, имеет встроенные ожидания и параллельный запуск тестов. Поддерживает JavaScript, TypeScript, Python, Java и C#.
Selenium — один из самых популярных инструментов автоматизации работы с браузерами. Поддерживает большинство браузеров и языков программирования, легко интегрируется в CI/CD
Cypress — фреймворк для автоматизации тестирования веб‑приложений на JavaScript/TypeScript. Легкий в настройке, имеет встроенный интерфейс и часто используется для frontend'а.
В таких случаях после новой поставки закладывается в районе недели‑двух на написание автотестов, которые покрывают собой различные требования бизнеса. Например, позитивные и негативные сценарии, покупка разных предметов и так далее
Основные типы тестирования
Все тесты так или иначе отвечают на вопрос, а что мы, собственно, тестируем.
Функциональное тестирование
— проверяет, работает ли система согласно требованиям.
Инструменты:
Postman — отдельное приложение, позволяющее отправлять API и curl запросы
Rest Assured — библиотека Java, позволяющая писать REST API тесты
Swagger — инструмент документации API, хранилище правил и endpoint'ов
PyTest — фреймворк для Python, позволяющий делать авто‑тесты
Инструменты автоматизации: Jenkins, Gitlab (CI), Docker
Например, в функциональном тестировании мы проверяем действительно ли форма логина работает по заданным правилам, и действительно ли мы не можем никаким образом заказать ванну в разделе с овощами. Отсылая к прошлому пункты, нам нет особой разницы как именно мы будем это проверять (руками или через авто‑тесты).
К функциональному тестированию относят такие виды тестов как:
Smoke test
Быстрая проверка на то, что основные функции работают. В основном smoke тесты проводят после новых сборок или при небольших изменениях, которые в теории могут отразиться на основных функциях.
Например:
запуск приложения
основные endpoints
форма регистрации
критические функции
Smoke test может быть, как ручным, так и автоматизированным. Хотя чаще всего на практике встречается именно второй вариант.
Sanity test
Конкретная проверка конкретного функционала после фикса. Чаще всего тестируется вручную
Regression test
Проверка того, что фикс конкретного функционала не сказался на остальных функциях системы. Допустим, разработчик слегка изменил форму заказа, и в рамках теста регресса нам следует проверять, что изменение формы заказа не повлияло на систему в целом.
Такой процесс крайне редко оставляют ручным и стараются максимально автоматизировать потому что регрессионные тесты запускают после каждого фикса (а то и каждую ночь) и они могут включать в себя от 5 до 500 разных сценариев.
Почему так? Потому что они созданы не для нового, а для проверки хорошо известного старого функционала.
Integration test
Проверка взаимодействий между компонентами системы. Например:
взаимодействие между двумя микросервисами
взаимодействие Api и базы данных
взаимодействие Api и брокера сообщений
В общем, проверяем как два и более элемента системы взаимодействуют между собой (кстати, проверка только одного микросервиса будет называться Unit тестом). Здесь уже могут требоваться знания брокеров сообщений, sql и прочих инструментов.
Процесс может быть, как ручным, так и автоматизированным. Но опять же чаще приоритет отдают автоматизации.
UI test
Проверка, что frontend отрабатывает корректно. Иными словами, кнопка прожимается, страница корректно отображается, появляется ошибка при вводе неправильного пароля. В общем работа только с тем, что видит пользователь.
Также применяется ручное и автоматизированное тестирование.
API test
Проверка, что backend отрабатывает корректно. Здесь идут проверки HTTP, Rest и прочие, чья цель убедиться в том, что конкретный запрос к бэкенду выдает корректный ответ. Например, работая в postman, мы можем проверять, что форма логина выдает 200 и токен, а попытка зайти на сайт без токена возвращает 401 ошибку.
Применяется ручное и автоматизированное тестирование с приоритетом последнего.
End‑to‑End test (e2e)
Проверка системы от начала до конца, проходя по полному пользовательскому сценарию и проверяя, и frontend, и backend, и взаимодействие микросервисов, и работу базы данных. По сути e2e включает в себя все пункты, перечисленные выше.
В основном такие тесты автоматизируют из‑за их размеров, а также ради регресса. Однако на небольших проектах вполне можно проверять систему вручную.
Нефункциональное тестирование
— проверяет характеристики системы, а не функционал (что идет из самого названия тестирования, кто бы мог подумать, да я просто гений, никто бы не догадался)
Инструменты:
K6 — используется для написания api и нагрузочных тестов с использованием JavaScript
Apache Jmeter — одно из самых популярных средств тестирования производительности с множеством протоколов
LoadRunner (PC) — набор инструментов для написания api тестов на языке C, в основном для веб‑тестирования. Включает в себя отдельное приложение для запуска тестов и внутренний мониторинг
Gatling — аналогично остальным, позволяет писать на Kotlin, Golang и Java
Нефункционально тестирование может быть только автоматизированным (за исключением пары тестов) и иногда прячется за названием Performance testing. По сути в нефункциональном тестировании нас интересует не то, а можем ли мы зарегистрироваться на сайте, а что будет с утилизацией CPU и RAM, если регистрацию попробуют пройти сразу 30 человек, и сколько времени уйдет на получение ответа от сервера. При этом такой вид тестирования в основном включает в себя все элементы системы.
Нефункциональное тестирование включает в себя:
Load Test
Проверяем, способна ли система выдержать большое количество пользователей. Условно на ПРОД сейчас в день приходят 10–20 пользователей. Мы в рамках теста будет проверять, что будет, если придет 40 пользователей. А 70? А 100? И здесь нас интересует в первую очередь характеристики системы под нагрузкой.
Stress Test
Проверяем поведение системы при отличных от нормального условиях. Например, у нас резко перестала отвечать смежная система или количество ядер цпу на сервере уменьшилось вдвое. Иными словами, мы целенаправленно ломаем систему, чтобы узнать, на что именно эта поломка повлияет и сможет ли система после нее восстановиться.
Spike Test
Отдельный вид стресс‑тестов, который проверяет, что будет, если нагрузка на конкретный функционал резко возрастет в пять раз.
Reliability (оно же stability) test
Проверяем поведение системы под длительной статичной нагрузкой.
Compatibility test
Проверяем, корректно ли работает система в другой среде (прим. другой браузер, расширение экрана, кроссплатформенность и т.п). В основном работа здесь идет с frontend, изредка заходя в api.
Инструменты: возвращаемся к Playwright и Selenium
Может быть, и ручным, и автоматизированным
Выводы: теперь вам стало чуть проще разбираться в бесконечном множестве различных тестов и требований. Спасибо за уделенное время!
