Особенности тестирования «серого ящика» // Gray Box Testing
Каждый начинающий тестировщик слышал о методах тестирования black-box, white-box и gray-box (методы трех «ящиков»). В сети можно найти много информации о «черном» и «белом ящиках», но статьи о методе «серого ящика» встречаются редко. Такая ситуация кажется мне не совсем справедливой, ведь многие из нас используют в работе именно эту стратегию. Я попытаюсь немного исправить сложившееся положение, подробно рассмотрев плюсы и минусы «серого ящика» по сравнению с двумя другими методами и выяснив, в каких случаях его применение будет наиболее эффективным. Тестирование «серого ящика» сочетает в себе элементы black-box и white-box тестирования, а потому я начну свой рассказ с краткой характеристики каждого из методов.
Black Box
Проверка «черного ящика» – это метод тестирования программного обеспечения, при котором функциональность исследуется без рассмотрения кода, деталей реализации и знаний о внутреннем устройстве программного обеспечения (ПО). Тестировщики пишут тест-кейсы, опираясь только на требования и спецификацию программного обеспечения.
Достоинства метода:
- 🔘 Позволяет быстро выявить ошибки в функциональных спецификациях.
- 🔘 Тестировщику не нужна дополнительная квалификация.
- 🔘 Тестирование проходит «с позиции» пользователя.
- 🔘 Составлять тест-кейсы можно сразу после подготовки спецификации.
Метод имитирует поведение пользователя, у которого нет никаких знаний о внутреннем устройстве программы. Методом «черного ящика» проводятся следующие виды тестирования:
К сожалению, использование этого метода далеко не всегда является достаточным при тестировании, так как существует высокая вероятность пропуска ошибки. Рассмотрим пример из практики.
Мы занимались тестированием формы регистрации и оплаты для VPN-провайдера. При регистрации клиенту предлагался на выбор набор тарифных планов и дополнительных услуг. После выбора и оплаты регистрация завершалась, и клиент попадал в свой личный кабинет. Мы проверили эту процедуру вдоль и поперек: все работало так, как нужно, ровно до того чудесного дня, когда было принято решение ввести новый промоплан для привлечения клиентов.
Первая акция такого рода прошла весьма успешно: при регистрации по промоплану клиенту начислялся бонус на счет, и давался бесплатный доступ на 30 дней к одному дружественному сервису.
Вторая промо-акция отличалась тем, что клиенту при регистрации предлагался на выбор один из трех дружественных сервисов для бесплатного доступа. И тут что-то пошло не так: всем новым клиентам отправлялся доступ только к дружественному сервису из первой акции. Мы получили волну возмущения в саппорте и отток клиентов.
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, а также для функционального тестирования.
Автор - Ольга Панина