Что такое функциональное тестирование и как оно проходит

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

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

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

Содержание

• Что такое функциональное тестирование и чем оно отличается от нефункционального
• Виды функционального тестирования
• Этапы проведения функционального тестирования
• Инструменты, которые пригодятся в практике

Что такое функциональное тестирование и чем оно отличается от нефункционального

С помощью функционального тестирования проверяют, правильно ли программа выполняет свои функции в соответствии с требованиями заказчика или техническими спецификациями. При нём фокусируются на конкретных действиях системы, обработке входных данных и соответствии полученных результатов ожиданиям. Проще говоря, такое тестирование отвечает на вопрос: «Делает ли система именно то, что должна делать?»

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

При этом тестировщика обычно не интересует устройство программы или её код — важна лишь работа системы с точки зрения конечного пользователя. Например, при проверке функции добавления товара в корзину тестировщик не вникает в работу базы данных, а просто убеждается, что после нажатия кнопки «Добавить в корзину» товар появляется в корзине с правильным названием, ценой и количеством.

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

Пример простого тест-кейса для проверки отправки сообщения через форму обратной связи на сайте

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

Чтобы лучше понять разницу, представьте, что вы купили новый автомобиль. Когда вы проверяете, заводится ли двигатель, едет ли машина, включаются ли фары и открываются ли окна, — это функциональное тестирование. А вот нефункциональное тестирование отвечает на другие вопросы: насколько быстро машина разгоняется, удобно ли ею управлять, безопасна ли она и комфортна ли поездка.

Далее мы не будем углубляться в нефункциональное тестирование, поскольку это отдельная большая тема. Если хотите узнать подробности, рекомендуем нашу статью про мобильное тестирование. В ней QA lead компании SberDevices Руслан Мурадов на примерах показывает, как эти два вида тестирования работают вместе и дополняют друг друга.

Читайте также:

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

Виды функционального тестирования

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

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

По уровню детализации

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

Модульное тестирование (unit testing) проверяет отдельные функции или компоненты в изоляции от остальной системы. При этом компоненты намеренно тестируются отдельно, чтобы исключить влияние других частей программы. Например, вы можете проверить алгоритм расчёта скидки и убедиться, что при покупке на 10 000 рублей цена снижается на 15%, — как и предусмотрено логикой приложения.

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

Системное тестирование — это комплексная проверка приложения, которая позволяет убедиться, что система работает как единое целое. Для такого тестирования есть разные подходы. Например, с помощью smoke-тестов быстро оценивают базовую работоспособность приложения, а при end-to-end-тестировании проводят проверку всех пользовательских сценариев — от регистрации на сайте до оплаты и отслеживания статуса заказа.

Приёмочное тестирование (UAT) проводится с участием заказчика или конечных пользователей перед релизом продукта. Его главная цель — убедиться, что система полностью соответствует бизнес-требованиям и готова к эксплуатации в реальных условиях. Например, при работе с банковским приложением клиент может проверить, корректно ли работает перевод средств, правильно ли отображается история транзакций и своевременно ли приходят уведомления о подозрительных операциях.

Читайте также:

JUnit: модульное тестирование в Java и test-driven development

По доступу к внутренней логике

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

Чёрный ящик (black box) — подход, при котором тестировщик взаимодействует только с внешним интерфейсом системы и оценивает её поведение исключительно по входным и выходным данным. Этот метод обычно включает в себя три основных типа тестовых сценариев:

• Позитивные тесты проверяют, корректно ли система работает с правильными входными данными. Например, ввод верного логина и пароля должен приводить к успешной авторизации пользователя.
• Негативные тесты оценивают реакцию системы на ошибочные данные. Например, при вводе неверного пароля должно появляться сообщение «Неверные учётные данные».
• Граничные тесты проверяют поведение системы при крайних значениях. Это может быть ввод максимального количества символов в поле формы или минимальной суммы заказа.

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

Серый ящик (gray box) — в этом случае тестировщик частично знаком с архитектурой системы, знает устройство ключевых процессов, но не имеет полного доступа к коду. Такой метод удобен для тестирования взаимодействий между компонентами, работы API или базы данных.

Например, при тестировании оплаты в интернет-магазине специалист понимает, что система должна отправить запрос к платёжному шлюзу, получить подтверждение и корректно обработать ответ. На основе этого тестировщик проверяет различные сценарии: успешную оплату, отказ от транзакции, потерю соединения во время платежа и многое другое.

Белый ящик (white box) — метод, при котором тестировщик имеет полный доступ к исходному коду, внутренней структуре и алгоритмам приложения. Такой подход помогает обнаружить скрытые дефекты, которые сложно выявить только через пользовательский интерфейс. Кроме того, тестирование методом белого ящика позволяет выявить утечки памяти и другие возможные проблемы с производительностью.

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

Читайте также:

Идентификация, аутентификация, авторизация: чем они различаются

По проверяемым характеристикам

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

Пригодность (suitability) — этот критерий помогает убедиться, что система соответствует спецификации и выполняет все задачи, которых ожидают от неё пользователи. Например, в банковском приложении тестировщик проверяет возможность просмотра баланса, перевода средств, оплаты услуг, получения выписки и других основных операций.

Точность (accuracy) — при проверке специалист оценивает корректность обработки и вычисления данных, а также соответствие результатов ожиданиям пользователя. Так, в финансовом приложении критически важно проверить расчёты процентных ставок по кредитам и вкладам, а в налоговом калькуляторе — правильность применения всех вычетов.

Взаимодействие (interoperability) — этот аспект отражает способность системы обмениваться данными с другими компонентами и внешними сервисами. Например, мобильное приложение интернет-магазина должно без ошибок взаимодействовать с платёжными системами, различными сервисами доставки и CRM-системой компании.

Безопасность (security) — этот критерий позволяет оценить защищённость системы от несанкционированного доступа, утечек данных и других уязвимостей. Если тестировщик работает с системой документооборота, то он может проверить корректность разграничения доступа к конфиденциальным документам, защиту каналов передачи информации или надёжность механизмов цифровой подписи.

Читайте также:

Боль тестировщика: с какими проблемами сталкиваются QA‑инженеры

Этапы проведения функционального тестирования

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

Анализ требований

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

• Не противоречат друг другу — не должно быть ситуаций, когда в документации указаны взаимоисключающие требования. Например, когда в задании предусмотрена разработка только под Windows, а в спецификациях заявлена поддержка Linux-систем.
• Достаточно полны — требования должны содержать все детали, чтобы команда могла корректно реализовать функциональность и провести её тестирование. То есть формулировка «для регистрации пользователь должен ввести данные» неполная. Лучше конкретизировать: «для регистрации пользователь должен указать email, пароль (8–20 символов), имя и возраст (18+)».
• Атомарны — каждое требование должно описывать одну функцию, которую можно протестировать как отдельную единицу. Вместо общего требования «пользователь должен сортировать товары» лучше указать отдельные: «пользователь должен сортировать товары по цене (от низкой к высокой и наоборот)», «пользователь должен сортировать товары по рейтингу» и так далее.

Если в требованиях есть противоречия или неточности, тестировщик должен сообщить об этом команде или заказчику и уточнить все детали.

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

Разработка тестовой документации

На основе изученных требований специалист составляет план тестирования, готовит тест-кейсы с критериями приёмки, чек-листы для быстрых проверок и сценарии для комплексного тестирования функциональности. Объём документации зависит от типа проекта:

• Для крупных систем нужен весь комплект: планы, тест-кейсы с чётко определёнными ожидаемыми результатами и матрицы отслеживания требований для контроля покрытия тестами.
• В небольших проектах часто достаточно чек-листов и ключевых сценариев. Например, для корпоративного сайта это может быть базовый набор: проверка работоспособности контактной формы, навигации, информационных разделов и формы обратной связи.
• В стартапах обычно используют минимальную документацию или исследовательское тестирование — команда стремится пораньше выпустить продукт на рынок и быстро собрать первую обратную связь от пользователей для последующих доработок.

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

Подготовка тестовых данных и тестирование

После подготовки документации тестировщик формирует чёткое представление о данных, которые нужны для проверки системы. Например, для тестирования создания учётных записей понадобятся валидные и невалидные email-адреса, простые и сложные пароли, данные пользователей разных возрастных категорий, а также особые случаи: с учётными записями несовершеннолетних, посетителей из других стран и прочих.

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

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

Читайте также:

Что такое QA-тестирование и как оно устроено

Логирование ошибок и приёмка

В процессе тестирования все проблемы заносятся в баг-репорт — специальный документ, где описываются обнаруженные ошибки, шаги для их воспроизведения, влияние на систему и другие важные детали. Например, тестировщик может обнаружить, что при попытке оплаты заказа с промокодом SALE50 система вместо скидки выдаёт ошибку 404.

После завершения функционального тестирования разработчики получают отчёт с описанием обнаруженных ошибок. Они устраняют эти ошибки, после чего тестировщик повторно проверяет все проблемные участки. Такой цикл «тестирование — исправление» повторяется до тех пор, пока система не будет соответствовать заданным требованиям.

После прохождения всех проверок продукт передаётся на приёмку. На этом этапе обычно проводится демонстрация системы, и заказчик оценивает, соответствует ли функциональность его ожиданиям. Например, в случае с приёмкой интернет-магазина заказчик может проверить весь путь покупателя: от регистрации и поиска товара до оформления заказа и получения подтверждения по электронной почте.

Инструменты, которые пригодятся в практике

Раньше тестирование проводилось вручную: специалисты открывали приложение, вводили данные, нажимали кнопки, делали скриншоты и записывали результаты в Excel. Такой подход был эффективен, пока системы оставались простыми, а требования — минимальными.

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

Инструменты автоматизации позволяют запускать тесты по расписанию, при каждом коммите или перед релизом. Например, настроенный CI/CD-пайплайн может автоматически запускать регрессионные тесты ночью и отправлять отчёт к началу рабочего дня. Это экономит сотни часов ручной работы, повышает стабильность продукта и помогает быстрее находить критические ошибки.

• Selenium WebDriver — позволяет имитировать заполнение форм, проверять корректность валидации полей, тестировать работу интерфейса и моделировать пользовательские сценарии.
• Cypress — современный инструмент с простой настройкой и высокой скоростью работы. Подходит для проверки интерактивных элементов, таких как фильтры товаров.
• TestComplete — коммерческий инструмент с визуальным интерфейсом и поддержкой разных языков программирования. Позволяет записывать действия пользователя, создавать и модифицировать тесты на JavaScript, Python или C++.
• Katalon Studio — готовое решение для тестирования веба, мобильных приложений и API. Поддерживает одновременную работу с разными платформами и сценариями. Например, можно создать единый набор тестов, который проверит как корректность отображения интерфейса, так и работу API-запросов к серверу.
• Robot Framework — инструмент с открытым исходным кодом для создания тестов на понятном языке. Вы пишете простые команды вроде «Открыть браузер», «Ввести логин admin», «Проверить элемент dashboard», и система выполняет эти действия.

Читайте также:

CI/CD: что это и почему без неё не обходится разработка ПО

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

• Appium — это кросс-платформенный инструмент с открытым исходным кодом для тестирования мобильных приложений на iOS и Android. Работает через WebDriver API и позволяет писать тесты на разных языках программирования (Java, Python или JavaScript).
• Espresso — фреймворк от Google для UI-тестирования Android-приложений. Он полностью интегрирован с Android Studio, отличается быстрым запуском тестов и обеспечивает стабильные результаты даже при сложных сценариях.
• XCTest — фреймворк от Apple для проведения модульных и UI-тестов на iOS. Позволяет проверять компоненты и интерфейс приложений на Swift и Objective-C прямо в Xcode, поддерживает асинхронные проверки и имитацию пользовательских действий.

Читайте также:

Что такое Android Studio и как ей пользоваться

Инструменты для тестирования API позволяют проверять взаимодействие между клиентом и сервером: корректность HTTP-запросов, структуру ответов, а также поведение системы при возникновении ошибок и работе под повышенной нагрузкой.

• Postman — популярный инструмент для тестирования REST и GraphQL API. Позволяет создавать коллекции запросов, писать тестовые скрипты, использовать переменные окружения, интегрироваться с CI/CD-процессами и другими сервисами.
• REST Assured — библиотека для тестирования REST API на Java. Предлагает удобный и читаемый синтаксис для проверки HTTP-запросов и ответов, легко интегрируется с JUnit и TestNG.
• SoapUI — мощный инструмент для тестирования SOAP и REST API с поддержкой сценариев, сложных проверок и нагрузочного тестирования. Например, с его помощью можно эмулировать одновременное подключение тысячи пользователей к серверу и проверить, как система справляется с пиковыми нагрузками.
• Insomnia — бесплатный инструмент с открытым исходным кодом для тестирования API. Позволяет создавать, отправлять и сохранять HTTP-запросы, организовывать их в пространства и запускать целые последовательности одним кликом мыши.

Читайте также:

Что такое GraphQL, как он работает и зачем понадобился