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

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

С помощью функционального тестирования можно проверить:
● работоспособность приложения или сайта;
● его основные функции.

Если у пользователя не получается авторизоваться, это критичный баг ― ошибка, которую нужно исправить немедленно. Источник: mann-ivanov-ferber

Например, при тестировании приложения интернет-магазина можно проверить такие функции и возможности:

● авторизацию;
● добавление товара в избранное и в корзину;
● оплату;
● заказ доставки;
● отмену заказа;
● добавление отзыва или вопроса и т.д.

С точки зрения доступа к продукту выделяют два основных уровня функционального тестирования:

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

2. «Белый ящик» (white box) — тестирование с доступом к исходному коду, когда тестировщик понимает, как приложение работает изнутри. Для белого тестирования требуется большая квалификация тестировщика ― оно глубже тестирования без доступа к коду.

В роли специалиста, выполняющего тестирование на уровне «чёрного ящика», выступает каждый покупатель интернет-магазина. Источник: ozon

По уровням глубины функционального тестирования различают:

● Верхний уровень. Тестирование интерфейса — запуск приложения в браузере и проведение запланированных проверок.
● Средний уровень. Тестирование API — обращение к бэкенду, минуя пользовательский интерфейс.
● Нижний уровень. Тестирование баз данных — проверка валидных и невалидных значений с точки зрения бизнес-логики.
● Уровень взаимодействия. Тестирование интеграций — проверка, как приложение взаимодействует с внешними системами.

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

С точки зрения использования инструментов функциональное тестирование делится на:

● Ручное. Главный инструмент — голова тестировщика, его внимательность и заинтересованность.
● Автоматизированное — проводится с использованием специальных инструментов, их разберём ниже.

Задача уходит в разработку, а специалист в это время готовит документацию для тестирования. На основе документации составляются тестовый сценарий, чек-листы и тест-кейсы.

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

При функциональном тестировании используют разные методы. Рассмотрим подробнее некоторые из них:

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

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

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

■ Классы эквивалентности

Входящие данные, например дата или сумма, делятся на классы эквивалентности. Подразумевается, что в одном классе вся система функционирует одинаково.

Например, в системе интернет-магазина заложена логика: если пользователь покупает от 1 до 10 товаров, он получает скидку 10%, от 10 до 20 — 20%, и так далее до 50%-ной скидки. Если пользователь берет 50 или больше товаров, скидка будет 50%.

■ Метод граничных значений

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

Например, разработчики путают, с какого по счёту товара должна начинаться скидка в 10% — с девятого, десятого или одиннадцатого? Это частые ошибки, наравне с ошибками в датах — в ситуациях «до», «включительно», «не включительно», например в сроках проведения рекламных акциий. В граничных значениях тестировщику нужно проверить саму границу внутри класса и за его пределами — числа 10, 9 и 11.

■ Техника состояния переходов

Используется для сложных систем, например административных панелей или CRM-систем. Есть некая сущность, которая от создания до окончания существования меняет состояния. Тестировщик проводит с ней позитивные и негативные проверки и отслеживает, как сущность меняет состояние в системе. Например, позитивное тестирование в данном случае — это движение товара по стадиям «заказано — доставлено — отправлено в доставку — доставлено — возвращено». Негативным тестированием будет попытка продвинуть товар, минуя отдельные стадии, например сразу к стадии «возвращено», без создания заказа.

■ Техника попарного тестирования, или pairwise testing

Проверка всех возможных комбинаций системы по заданным параметрам.
Например, в сервисе записи к врачу пациенты выбирают день, время, специализацию врача и клинику, всего четыре поля. В сервисе зарегистрированы врачи двадцати специализаций от окулиста до дерматолога и три клиники — уникальных комбинаций можно составить сотни.
Техника попарного тестирования позволяет скомбинировать сочетание полей таким образом, чтобы протестировать все пары, но при меньшем количестве вариантов. Это можно сделать вручную, также для этого есть специальные инструменты: достаточно внести все значения, чтобы получить на выходе автоматически рассчитанный результат. Например, это PICT у Microsoft и IBM FoCuS у IBM.

Комбинаций в полях записи может быть больше ста, в зависимости от того, какое количество значений возвращает система. Источник: ugmk-clinic

Перечислим основные инструменты, которые тестировщики используют в работе чаще всего

● Тестовая документация
Это хранилище знаний о работе системы. Тестовая документация обычно хранится в гугл-доках или таблицах на личных дисках тестировщиков, а не в открытом доступе у всей команды. И это не лучшее решение. Предпочтительнее использовать специализированные системы для хранения, например Allure TestOps. Здесь можно удобно организовать систему хранения тестовой документации, постоянно её обновлять, проверять и интегрировать с другими системами.

● Автотест
Это скрипт, который тестировщик пишет самостоятельно. Цель автотеста — сымитировать взаимодействие пользователя с приложением и выявить возможные ошибки в работе системы.

● Apache JMeter и Яндекс.Танк
Инструменты для проведения нагрузочного тестирования ― проверки реакции системы на повышение рабочей нагрузки вплоть до максимальной.

● Chrome DevTools
Инструмент используется для тестирования фронтенда в браузере. Это встроенная функция, так называемая «панель разработчиков». На ней можно посмотреть, какие запросы уходят и какие скрипты выполняются.

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

● Эмуляторы мобильных приложений
Для тестирования мобильных приложений используют эмуляторы ― специальные программы, имитирующие работу той или иной операционной системы. Android Studio используют, чтобы тестировать приложения на Android, например, когда нужно развернуть файл приложения. В Android Studio тестировщик получает виртуальный телефон, в котором можно заходить на сайты, запускать приложения, авторизироваться в программах. Точно так же работают эмуляторы для iOS, например Xcode Simulator или Xamarin iOS Simulator.

● Инструменты для тестирования баз данных
Клиенты баз данных, например pgAdmin, DBeaver и PostgreSQL, используют, когда нужно получить из БД какие-то данные или изменить их.