Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>29 июл 2025</li>

3 <li>0</li>

4 </ul><h2>Что такое функциональное тестирование и как оно проходит</h2>

5 И почему без него не обходится ни один успешный релиз.

6 Кадр: фильм "Бэтмен против Супермена" / DC Comics / Warner Bros.

7 Автор статей о программировании. 14 лет в IT. Умеет рассказывать о технологиях простыми словами. Автор спецпроекта Advertising for Social Change.

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

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

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

11 Содержание

12 <ul><li><a>Что такое функциональное тестирование и чем оно отличается от нефункционального</a></li>

13 <li><a>Виды функционального тестирования</a></li>

14 <li><a>Этапы проведения функционального тестирования</a></li>

15 <li><a>Инструменты, которые пригодятся в практике</a></li>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

33 <ul><li>Позитивные тестыпроверяют, корректно ли система работает с правильными входными данными. Например, ввод верного логина и пароля должен приводить к успешной авторизации пользователя.</li>

34 <li>Негативные тестыоценивают реакцию системы на ошибочные данные. Например, при вводе неверного пароля должно появляться сообщение "Неверные учётные данные".</li>

35 <li>Граничные тестыпроверяют поведение системы при крайних значениях. Это может быть ввод максимального количества символов в поле формы или минимальной суммы заказа.</li>

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

37 Изображение: Krauss /<a>Wikimedia Commons</a><a>Серый ящик (gray box)</a> - в этом случае тестировщик частично знаком с архитектурой системы, знает устройство ключевых процессов, но не имеет полного доступа к коду. Такой метод удобен для тестирования взаимодействий между компонентами, работы API или базы данных.

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

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

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

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

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

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

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

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

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

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

48 <ul><li>Не противоречат друг другу - не должно быть ситуаций, когда в документации указаны взаимоисключающие требования. Например, когда в задании предусмотрена разработка только под Windows, а в спецификациях заявлена поддержка Linux-систем.</li>

49 <li>Достаточно полны - требования должны содержать все детали, чтобы команда могла корректно реализовать функциональность и провести её тестирование. То есть формулировка "для регистрации пользователь должен ввести данные" неполная. Лучше конкретизировать: "для регистрации пользователь должен указать email, пароль (8-20 символов), имя и возраст (18+)".</li>

50 <li>Атомарны - каждое требование должно описывать одну функцию, которую можно протестировать как отдельную единицу. Вместо общего требования "пользователь должен сортировать товары" лучше указать отдельные: "пользователь должен сортировать товары по цене (от низкой к высокой и наоборот)", "пользователь должен сортировать товары по рейтингу" и так далее.</li>

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

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

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

54 <ul><li>Для крупных системнужен весь комплект: планы, тест-кейсы с чётко определёнными ожидаемыми результатами и матрицы отслеживания требований для контроля покрытия тестами.</li>

55 <li>В небольших проектахчасто достаточно чек-листов и ключевых сценариев. Например, для корпоративного сайта это может быть базовый набор: проверка работоспособности контактной формы, навигации, информационных разделов и формы обратной связи.</li>

56 <li>В стартапахобычно используют минимальную документацию или исследовательское тестирование - команда стремится пораньше выпустить продукт на рынок и быстро собрать первую обратную связь от пользователей для последующих доработок.</li>

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

58 ПолеОписаниеIDУникальный идентификатор теста (например, TC-001)НазваниеКраткое описание проверяемой функцииОписаниеЧто именно проверяется и в каком контекстеПриоритетВысокий, средний или низкийАвторКто составил тест-кейсДата созданияКогда был создан тест-кейсПредусловияСостояние системы до начала теста ("Пользователь не авторизован, открыта главная страница сайта")ШагиПоследовательность действий: - Первый шаг- Второй шаг- Третий шагОжидаемый результатЧто должна показать или сделать система (например, "Появляется сообщение об успешной регистрации")ПримечанияДополнительные данные, настройки, ссылки на макетыСтатусПройдено, провалено или не выполненоДата выполненияКогда тест-кейс выполнялся последний разКомментарийЗамечания, наблюдения, идеи по улучшениюПосле подготовки документации тестировщик формирует чёткое представление о данных, которые нужны для проверки системы. Например, для тестирования создания учётных записей понадобятся валидные и невалидные email-адреса, простые и сложные пароли, данные пользователей разных возрастных категорий, а также особые случаи: с учётными записями несовершеннолетних, посетителей из других стран и прочих.

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

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

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

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

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

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

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

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

67 <ul><li><a>Selenium WebDriver</a> - позволяет имитировать заполнение форм, проверять корректность валидации полей, тестировать работу интерфейса и моделировать пользовательские сценарии.</li>

68 <li><a>Cypress</a> - современный инструмент с простой настройкой и высокой скоростью работы. Подходит для проверки интерактивных элементов, таких как фильтры товаров.</li>

69 <li><a>TestComplete</a> - коммерческий инструмент с визуальным интерфейсом и поддержкой разных языков программирования. Позволяет записывать действия пользователя, создавать и модифицировать тесты на JavaScript, Python или C++.</li>

70 <li><a>Katalon Studio</a> - готовое решение для тестирования веба, мобильных приложений и API. Поддерживает одновременную работу с разными платформами и сценариями. Например, можно создать единый набор тестов, который проверит как корректность отображения интерфейса, так и работу API-запросов к серверу.</li>

71 <li><a>Robot Framework</a> - инструмент с открытым исходным кодом для создания тестов на понятном языке. Вы пишете простые команды вроде "Открыть браузер", "Ввести логин admin", "Проверить элемент dashboard", и система выполняет эти действия.</li>

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

73 <ul><li><a>Appium</a> - это кросс-платформенный инструмент с открытым исходным кодом для тестирования мобильных приложений на iOS и Android. Работает через<a>WebDriver API</a>и позволяет писать тесты на разных языках программирования (Java, Python или JavaScript).</li>

74 <li><a>Espresso</a> - фреймворк от Google для UI-тестирования Android-приложений. Он полностью интегрирован с Android Studio, отличается быстрым запуском тестов и обеспечивает стабильные результаты даже при сложных сценариях.</li>

75 <li><a>XCTest</a> - фреймворк от Apple для проведения модульных и UI-тестов на iOS. Позволяет проверять компоненты и интерфейс приложений на Swift и Objective-C прямо в Xcode, поддерживает асинхронные проверки и имитацию пользовательских действий.</li>

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

77 <ul><li><a>Postman</a> - популярный инструмент для тестирования<a>REST</a>и GraphQL API. Позволяет создавать коллекции запросов, писать тестовые скрипты, использовать переменные окружения, интегрироваться с CI/CD-процессами и другими сервисами.</li>

78 <li><a>REST Assured</a> - библиотека для тестирования REST API на Java. Предлагает удобный и читаемый синтаксис для проверки HTTP-запросов и ответов, легко интегрируется с<a> JUnit</a>и<a> TestNG</a>.</li>

79 <li><a>SoapUI</a> - мощный инструмент для тестирования<a>SOAP</a>и REST API с поддержкой сценариев, сложных проверок и нагрузочного тестирования. Например, с его помощью можно эмулировать одновременное подключение тысячи пользователей к серверу и проверить, как система справляется с пиковыми нагрузками.</li>

80 <li><a>Insomnia</a> - бесплатный инструмент с открытым исходным кодом для тестирования API. Позволяет создавать, отправлять и сохранять HTTP-запросы, организовывать их в пространства и запускать целые последовательности одним кликом мыши.</li>

81 </ul><a>Курс с трудоустройством: "Профессия Инженер по тестированию + ИИ" Узнать о курсе</a>