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

Каждый начинающий тестировщик слышал о методах тестирования 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, а также для функционального тестирования.

© 2010—2017. Лаборатория качества