Особенности тестирования «серого ящика»

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

Black-box

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

Достоинства метода:

• Позволяет быстро выявить ошибки в функциональных спецификациях.
• Тестировщику не нужна дополнительная квалификация.
• Тестирование проходит «с позиции» пользователя.
• Составлять тест-кейсы можно сразу после подготовки спецификации.

Метод имитирует поведение пользователя, у которого нет никаких знаний о внутреннем устройстве программы. Методом «черного ящика» проводятся следующие виды тестирования:

• функциональное;
• регрессионное;
• usability;
• smoke;
• GUI.

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

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

Вторая промо-акция отличалась тем, что клиенту при регистрации предлагался на выбор один из трех дружественных сервисов для бесплатного доступа. И тут что-то пошло не так: всем новым клиентам отправлялся доступ только к дружественному сервису из первой акции. Мы получили волну возмущения в саппорте и отток клиентов.
Ошибка заключалась в том, что первая промо-акция была учтена в базе под названием promo_1, а вторая – под promo_12, promo_13 и promo_14, но при этом в базу все записывалось под именем promo_1. Данные промо-акции не внесли в спецификацию, поэтому тест-кейсы не были составлены для новых акций. У тестировщиков не было доступа в базу и они не могли проверить правильность записи о тарифном плане.

White-box

У этого метода существует несколько названий («стеклянный ящик», «открытый ящик» и др.), но чаще всего его все-таки именуют методом «белого ящика». Проверка «белого ящика» – это метод тестирования программного обеспечения, который предполагает, что внутренняя структура, устройство и реализация системы известны тестировщику.

Тестирование в «белом ящике» включает в себя несколько типов тестирования, применяемых для оценки удобства использования приложения, блока кода или конкретного программного пакета:

• Unit-тестирование;
• интеграционное;
• системное;
• тестирование безопасности.

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

Достоинства метода «белого ящика»:

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

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

Вернемся к нашему примеру. На входе мы имеем название подписки, на выходе – информацию по ней. Обычно список подписок хранится в базе данных, подписки могут добавляться в произвольные моменты времени. Black-box тестирование просто не сможет обеспечить стопроцентное покрытие, ведь с точки зрения этого метода набор тестов устареет в момент добавления новой подписки в базу данных. В данном случае white-box тестирование имеет неоспоримое преимущество в виде прямого доступа к информации из базы данных. Наш набор тестов может загрузить список всех имеющихся подписок из базы данных и проверить, выдает ли контроллер в backend-е информацию о подписке для всех элементов списка.

Gray-box

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

Виды тестирования «серого ящика»:

• Матричное тестирование.
• Регрессионное тестирование.
• Шаблонное тестирование (pattern).
• Тестирование с помощью ортогонального массива.

Достоинства метода:

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

Недостатки метода:

• Возможность анализа кода и тестового покрытия ограничена, так как доступ к исходному коду отсутствует.
• Тесты могут быть избыточными в том случае, когда разработчик также проверяет свой код Unit-тестами.
• Нельзя протестировать все возможные потоки ввода и вывода, поскольку на это требуется слишком много времени

В нашем примере у каждого клиента мог быть набор дополнительных функций (capabilities):

• «can_vpn» – клиент мог подключиться к VPN;
• «can_double_vpn» – клиент получал возможность подключиться к VPN, используя функцию DoubleVPN;
• «can_port_forward» – клиент имел дополнительный порт для входящих подключений на стороне сервера;
• «can_promo1» – клиент имел доступ к дружественному сервису.

Для удобства проверки разработчики предусмотрели возможность тестировщикам читать набор разрешенных функций из таблицы capabilities для каждого клиента. Тестировщики ставили тарифный план (подписку) и проверяли правильность изменения флагов в этой таблице. Без использования методики «серого ящика» проверка возможности для клиента совершить VPN-соединение в сочетании с дополнительными функциями потребовала бы гораздо больших затрат времени и труда.

Подведем итоги

Из представленной информации можно понять, что метод «серого ящика» помогает в следующих случаях:

• когда нет возможности использовать «белый ящик»;
• когда необходимо более полное покрытие по сравнению с «черным ящиком».

Используя этот метод, тестировщики получают доступ к проектной документации и могут подготовить и создать более точные и полные тест-кейсы и сценарии тестирования. Наибольшая эффективность применения «серого ящика» достигается при тестировании web-приложений, web-сервисов, безопасности, GUI, а также для функционального тестирования.