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

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

Об авторе

Занимается тестированием с 2012 года. Пришла в «Лабораторию качества» в 2016 году на позицию тестировщика. Сейчас работает тест-менеджером на одном из самых динамичных проектов «Лаборатории качества».

Поиск
Облако меток
api (5)kpi (1)kpi в тестировании (1)postman (1)rest api (2)scrum (1)scrumban (1)soap api (1)sqa days (1)TDD (1)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)ПОИНТ (2)Приёмочное тестирование (1)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (1)баги (4)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (1)ежемесячный отчет (12)интернет-магазин (1)исследовательское тестирование (2)коммуникации (3)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (19)лайф-хаки (3)локализация (1)международные проекты (1)метрики (2)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (7)обучение (6)оптимизация тестирования (13)поздравление (1)поздравления (2)пользовательские истории (1)пример (1)проблемы (1)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (5)разработчики (1)распределенная команда (3)решения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (44)тестирование безопасности (2)тестирование мобильных приложений (1)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (2)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (2)
Получите совет