Функциональное тестирование

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

Это основной вид тестирования направленный на проверку всех требований.

Функциональное тестирование- это вид тестирования, при котором выявляется некорректная /неправильная работа функционала программы. Проверка функций и характеристик разрабатываемого ПО. Этот вид тестирования занимает 90% времени отведённого на тестирование.

Функциональное тестирование предполагает проверку функциональных требований: логики и бизнес-правил приложения или системы. Полноценное системное/функциональное тестирование является самым трудоёмким процессом и может занимать до 80% всего бюджета проекта по тестированию.(Ф.Брукс)

Тестирование функциональности может проводиться в двух аспектах:

1. требования
2. бизнес-процессы

Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев. В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии. Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.
Тестирование в перспективе «бизнес-процессы» использует знание бизнес- процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии, как правило, основываются на случаях использования системы.

Пример функциональных тестов:

• Переход по разделам форума.
• Поиск по сайту.
• Подписка на рассылку - письма с информацией приходят.

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

Ниже приводится пошаговый процесс проведения функционального тестирования:

1. Понять функциональные требования
2. Идентифицировать тестовые входные данные или тестовые данные на основе требований
3. Вычислить ожидаемые результаты с выбранными входными значениями теста
4. Выполнить тестовые примеры
5. Сравните фактические и рассчитанные ожидаемые результаты

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

1. Unit testing
2. Integration testing
3. Interface testing.
4. System testing
5. Regression testing
6. Smoke testing
7. Sanity testing
8. Acceptance testing

Unit testing

1. При использовании этого типа функционального тестирования во время модульного тестирования тестируется наименьшая функциональная и тестируемая единица кода.
2.В основном выполняется разработчиками, поскольку это метод тестирования «белого ящика».
3. Выполняется на самых ранних этапах разработки, что помогает выявить дефекты на начальных этапах разработки. Это помогает сэкономить на более высоких затратах на исправление дефектов на более поздних этапах STLC.

Integration testing

1. Два или более протестированных компонента программного обеспечения объединяются вместе и тестируются для подтверждения ожидаемого взаимодействия между ними.
2. Между устройствами происходит обмен командами, данными, вызовами БД, вызовами API, обработкой микросервисов, и во время этой интеграции не наблюдается никакого неожиданного поведения.

Interface testing

1. Часть интеграционного тестирования; проверяется корректность обмена данными, передачи данных, сообщений, вызовов и команд между двумя интегрированными компонентами.
2. Связь между базой данных, веб-сервисами, API или любым внешним компонентом и приложением проверяется во время тестирования интерфейса.
3. Во время передачи данных или команд не должно быть никаких ошибок или несоответствий формата. Если возникла такая проблема, ее необходимо исправить.
4. Тестирование интерфейса — это тестирование связи между различными интерфейсами, а интеграционное тестирование — это тестирование интегрированной группы модулей как единого целого.

System testing

1.Все компоненты системы объединяются и система тестируется на соответствие и корректность техническим требованиям (Функциональным или Системным).
2. Это метод тестирования «черного ящика», который проверяет интегрированную систему.
3. Оно выполняется перед приемочным тестированием пользователя (UAT) в STLC (жизненный цикл тестирования программного обеспечения).
4. Тестирование системы проводится практически в реальной среде и в соответствии с реальным использованием.

Regression testing

1. После некоторых улучшений или исправлений кода разработчиками становится очень важно запустить набор регрессионных тестов. Регрессия запускается, чтобы гарантировать, что эти изменения кода не помешали существующим рабочим функциям или что в код не внесен какой-либо новый дефект.
2. Сценарии регрессионного тестирования представляют собой подмножество существующих функциональных тестов, которые охватывают основные функции системы.
3. Случаи регрессии необходимо обновлять, добавлять и удалять в соответствии с изменениями приложения.
4. Случаи регрессионного тестирования являются лучшими кандидатами для автоматического тестирования, поскольку они выполняются часто и требуют времени для выполнения.

Smoke testing

1.После разработки, когда выпускается новая сборка, в приложении проводится Smoke testing, чтобы убедиться в работе всех сквозных основных функций.
2. Smoke testing обычно проводится для сборок, созданных на начальном этапе разработки приложения, которые еще не стабильны.
3. Если во время тестирования какая-либо основная функциональность не работает должным образом, данная конкретная сборка отклоняется. Разработчикам необходимо исправить ошибки и создать новую сборку для дальнейшего тестирования.
4. После успешного Smoke testing приложение готово к следующему уровню тестирования.

Sanity testing

1. Sanity testing выбираются из набора регрессионных тестов, охватывающих основные функции приложения.
2. Sanity testing проводится на новой сборке, созданной разработчиками для относительно стабильного приложения.
3. Когда приложение успешно проходит Sanity testing, оно готово к следующему уровню тестирования.
4. Легко спутать Smoke testing и Sanity testing. Чтобы протестировать исходное приложение после новой сборки, выполняется Smoke testing. После многих выпусков, как только приложение становится стабильным, для одного и того же приложения проводится Sanity testing.

Acceptance testing

1. В ходе приемочного тестирования проверяется приемка приложения конечным пользователем. Цель этого тестирования — убедиться, что разработанная система соответствует всем требованиям, которые были согласованы при создании бизнес-требований.
2. Выполняется сразу после тестирования системы и перед окончательным выпуском приложения в реальном мире.
3. Приемочное тестирование становится критерием, позволяющим пользователю принять или отклонить систему.
4. Это метод тестирования «черного ящика», поскольку нас интересует только готовность приложения к рынку и реальным пользователям.

Полезные ссылки:

Functional testing article/eng

Functional testing types article/eng

Functional testing article/rus

Functional testing video tutorial/eng

Functional testing video tutorial/rus