Gray box testing что это
Black-box
Проверка «черного ящика» – это метод тестирования программного обеспечения, при котором функциональность исследуется без рассмотрения кода, деталей реализации и знаний о внутреннем устройстве программного обеспечения (ПО). Тестировщики пишут тест-кейсы, опираясь только на требования и спецификацию программного обеспечения.
К сожалению, использование этого метода далеко не всегда является достаточным при тестировании, так как существует высокая вероятность пропуска ошибки. Рассмотрим пример из практики.
Мы занимались тестированием формы регистрации и оплаты для VPN-провайдера. При регистрации клиенту предлагался на выбор набор тарифных планов и дополнительных услуг. После выбора и оплаты регистрация завершалась, и клиент попадал в свой личный кабинет. Мы проверили эту процедуру вдоль и поперек: все работало так, как нужно, ровно до того чудесного дня, когда было принято решение ввести новый промоплан для привлечения клиентов. Первая акция такого рода прошла весьма успешно: при регистрации по промоплану клиенту начислялся бонус на счет, и давался бесплатный доступ на 30 дней к одному дружественному сервису.
Вторая промо-акция отличалась тем, что клиенту при регистрации предлагался на выбор один из трех дружественных сервисов для бесплатного доступа. И тут что-то пошло не так: всем новым клиентам отправлялся доступ только к дружественному сервису из первой акции. Мы получили волну возмущения в саппорте и отток клиентов.
Ошибка заключалась в том, что первая промо-акция была учтена в базе под названием promo_1, а вторая – под promo_12, promo_13 и promo_14, но при этом в базу все записывалось под именем promo_1. Данные промо-акции не внесли в спецификацию, поэтому тест-кейсы не были составлены для новых акций. У тестировщиков не было доступа в базу и они не могли проверить правильность записи о тарифном плане.
White-box
У этого метода существует несколько названий («стеклянный ящик», «открытый ящик» и др.), но чаще всего его все-таки именуют методом «белого ящика». Проверка «белого ящика» – это метод тестирования программного обеспечения, который предполагает, что внутренняя структура, устройство и реализация системы известны тестировщику.
Как правило, таким видом тестирования на проектах занимаются сами программисты, ведь для использования этого метода тестировщик должен обладать достаточно высокой квалификацией.
Степень сложности тестирования методом «белого ящика» зависит от сложности вашего приложения/сервиса и от количества функций, которые оно выполняет.
Вернемся к нашему примеру. На входе мы имеем название подписки, на выходе – информацию по ней. Обычно список подписок хранится в базе данных, подписки могут добавляться в произвольные моменты времени. Black-box тестирование просто не сможет обеспечить стопроцентное покрытие, ведь с точки зрения этого метода набор тестов устареет в момент добавления новой подписки в базу данных. В данном случае white-box тестирование имеет неоспоримое преимущество в виде прямого доступа к информации из базы данных. Наш набор тестов может загрузить список всех имеющихся подписок из базы данных и проверить, выдает ли контроллер в backend-е информацию о подписке для всех элементов списка.
Gray-box

Для удобства проверки разработчики предусмотрели возможность тестировщикам читать набор разрешенных функций из таблицы capabilities для каждого клиента. Тестировщики ставили тарифный план (подписку) и проверяли правильность изменения флагов в этой таблице. Без использования методики «серого ящика» проверка возможности для клиента совершить VPN-соединение в сочетании с дополнительными функциями потребовала бы гораздо больших затрат времени и труда.
Подведем итоги
Используя этот метод, тестировщики получают доступ к проектной документации и могут подготовить и создать более точные и полные тест-кейсы и сценарии тестирования. Наибольшая эффективность применения «серого ящика» достигается при тестировании web-приложений, web-сервисов, безопасности, GUI, а также для функционального тестирования.
Тестирование методом Серого ящика
Популярным вопросом при изучении особенностей тестирования является различие между методами тестирования. Найти информацию про Black-box и White-box не составит труда, а вот Gray-box не пользуется популярностью среди авторов обучающих статей. Мы решили это исправить и поможем разобраться, чем тест Серого ящика отличается от других.
Зачастую Серый ящик считают совокупностью видов White/Black-Box, так как он подразумевает, что внутреннее устройство тестируемого продукта нам известно лишь частично. Поэтому прежде, чем пытаться понять, что же такое Grey-Box-тестирование, стоит разобраться, из совокупности каких других методов оно состоит.
Black-box-тестирование
При тестировании методом Чёрного ящика тестировщик не имеет доступа к внутренней структуре компонентов системы. Следовательно, процедура получения и выбора тестовых случаев основывается на анализе спецификации компонентов системы без прямой осведомленности в их внутреннем устройстве.
Пример работы
Самым простым примером тестирования Black-Box будет любая проверка на триггер уведомлений, когда во время тестирования затрагиваются функционалы отправки, а у тестировщика нет доступа к почтовым ящикам/базе.
При данной стратегии тестировщик осуществляет проверку продукта, не имея информации об особенностях его реализации, используя только предусмотренный разработчиком интерфейс.
За Ожидаемый Результат в данном случае будут отвечать Требования и\или Спецификация.
White-Box-тестирование
Тестирование методом Белого ящика предполагает собой работу с «открытой» системой, где ее внутренняя структура, а также устройство и реализация заранее известны тестировщику на момент старта тестов.
Тестировщик имеет доступ к реализованному коду, тестовой документации, изучает их и получает всю необходимую информацию, как должен работать продукт.
На данном этапе остается лишь проверить фактические результаты выполнения, сравнить их с ожидаемыми: определенными кодом и проектной документацией.
Пример работы
Хорошим примером послужит любой проект с открытым исходным кодом.
Скачав и запустив подобные, можно писать автотесты, прогон которых и станет проверкой. У подобных проектов часто отсутствует пользовательский интерфейс, что отсекает возможность тестирования Black-box.
Основные различия между Black-box и White-Box
При тестировании методом Белого ящика необходимы знания программирования. Поэтому считается, что данным видом пользуются сами разработчики, так как им известен код. Они определяют уместные или неуместные паттерны проектирования, структуры классов. Для них разрабатываемая ими же система — Белый ящик.
Black-box не требует знаний программирования, поэтому с ним работает непосредственно отдел Тестирования.
Grey-Box-тестирование
При тестировании по принципу Серого ящика руководствуются не только спецификацией, но и ключевыми элементами проектирования.
Пример работы
Предоставлена информация о базе данных. Если программа использует для своей работы какую-либо БД, мы можем проанализировать типы полей, в которые записываются переменные программы. А потом проанализировать ограничения, которые накладывает база.
Например, если вводимая фамилия пользователя записывается в поле типа «строка» длиной 128 символов, мы должны:
Если программа интегрируется с другими внешними системами, помимо базы данных, можно также проанализировать ограничения таких систем. Например, если мы тестируем почтовый IMAP-клиент, следует убедиться, что он корректно обрабатывает длинные пути к папкам на сервере (чаще всего, ограничение на длину пути составляет 255 символов).
Кроме указанного, если мы имеем еще и доступ к коду программы, то мы можем:
Достоинства метода:
Тестировщик может проектировать и использовать более сложные сценарии тестирования.
Тестировщик работает вместе с разработчиком, что позволяет на начальном этапе убрать избыточные тест-кейсы. Это сокращает время функционального и нефункционального тестирования и положительно влияет на общее качество продукта.
Недостатки метода:
Возможность анализа кода и тестового покрытия ограничена, так как либо доступ к исходному коду отсутствует, либо у тестировщика отсутствуют знания для изучения данного кода.
Тесты могут быть избыточными в том случае, когда разработчик также проверяет свой код Unit-тестами.
Нельзя протестировать все возможные потоки ввода и вывода, поскольку на это требуется слишком много времени.
Заключение
Стратегия объединяет в себе цели двух других ящиков, одновременно является универсальным вариантом для случаев, когда нет возможности прибегнуть к White-Box-тестированию, но есть необходимость более значительного охвата тестами чем тот, что может предоставить нам Black-box. Тестирование методом Серого ящика будет ближе именно к Черному ящику из-за отсутствия необходимости в доступе тестировщика к исходному коду. Все тесты создаются на основе знания алгоритма, архитектуры, внутренних состояний, а также иных высокоуровневых описаний поведения программы.
Тестирование методом серого ящика: основные понятия и особенности
Любой начинающий тестировщик хоть раз, но слышал о таких понятиях, как тестирование черного, белого, а также серого ящика. На просторах Интернета можно найти массу полезного материала об особенностях проверки первых двух видов. А вот касательно тестирования серого ящика (англ. grey box testing) информации очень мало.
Чтобы хоть немного прояснить ситуацию, далее в статье будут рассмотрены базовые принципы «серого ящика» (его преимущества и явные недостатки), а также даны объяснения ситуаций, в которых он должен использоваться.
Тестирование серого ящика технически сочетает в себе некоторые элементы тестирования методами черного и белого ящика. А это значит, что знакомство с понятием тестирования серого ящика нужно начинать с анализа характеристик других 2 типов тестов.
Тестирование методом черного ящика
Тестирование черного ящика (англ. black box testing) – специальный метод проверки работоспособности программного обеспечения, при котором вся функциональность продукта исследуется без анализа исходного кода. Тестировщики создают логически понятные тест-кейсы, опираясь исключительно на требования из спецификации на проекте.
Преимущества:
С помощью данного метода тестирования можно выполнять следующие проверки:
Но не всегда данный тип тестирования является достаточным, ведь всегда есть риск пропустить серьезные ошибки.
Тестирование методом белого ящика
Тестирование белого ящика (англ. white box testing) – особый метод проверки ПО, который подразумевает, что внутренняя структура и технические особенности ПО досконально известны проверяющему.
Проверка белого ящика состоит из нескольких взаимодополняющих типов тестирования, используемых для оценки удобства применения веб-продукта, части кода или особого программного функционала.
На основе такого тестирования можно совершать следующие проверки:
Традиционно, подобным типом тестирования занимаются программисты, так как для таких проверок специалист должен обладать высокой технической квалификацией.
Базовые достоинства такого метода тестирования:
Тестирование методом серого ящика
Проверка серого ящика (англ. grey box testing) – специальный метод тестирования программного обеспечения с неполным знанием его внутреннего устройства. Чтобы выполнить подобный вид тестов, не нужно иметь доступ к исходному коду ПО.
Все тесты создаются на базе простого знания алгоритмов, архитектуры и иных высокоуровневых характеристик поведения продукта.
Типы тестов серого ящика:
Основные преимущества метода:
Недостатки:
Краткие итоги
Итак, тестирование методом серого ящика наиболее востребовано в ситуации, когда QA-инженеры могут получить полноценный доступ к проектной документации и у них есть достаточно времени на подготовку тест-кейсов со сценариями тестирования.
Максимальная польза от применения подобного вида тестирования наблюдается во время проверки веб-приложений, веб-сервисов, графического интерфейса пользователя, и при выполнении разнообразных функциональных тестов ПО, ориентированных на системную и клиентскую безопасность.
Gray box testing что это






Что пишут в блогах
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты

Каждый начинающий тестировщик слышал о методах тестирования black-box, white-box и gray-box (методы трех «ящиков»). В сети можно найти много информации о «черном» и «белом ящиках», но статьи о методе «серого ящика» встречаются редко. Такая ситуация кажется мне не совсем справедливой, ведь многие из нас используют в работе именно эту стратегию. Я попытаюсь немного исправить сложившееся положение, подробно рассмотрев плюсы и минусы «серого ящика» по сравнению с двумя другими методами и выяснив, в каких случаях его применение будет наиболее эффективным. Тестирование «серого ящика» сочетает в себе элементы black-box и white-box тестирования, а потому я начну свой рассказ с краткой характеристики каждого из методов.
Проверка «черного ящика» – это метод тестирования программного обеспечения, при котором функциональность исследуется без рассмотрения кода, деталей реализации и знаний о внутреннем устройстве программного обеспечения (ПО). Тестировщики пишут тест-кейсы, опираясь только на требования и спецификацию программного обеспечения.
— Позволяет быстро выявить ошибки в функциональных спецификациях.
— Тестировщику не нужна дополнительная квалификация.
— Тестирование проходит «с позиции» пользователя.
— Составлять тест-кейсы можно сразу после подготовки спецификации.
Метод имитирует поведение пользователя, у которого нет никаких знаний о внутреннем устройстве программы. Методом «черного ящика» проводятся следующие виды тестирования:
— функциональное;
— регрессионное;
— usability;
— smoke;
— GUI.
К сожалению, использование этого метода далеко не всегда является достаточным при тестировании, так как существует высокая вероятность пропуска ошибки. Рассмотрим пример из практики.
Мы занимались тестированием формы регистрации и оплаты для VPN-провайдера. При регистрации клиенту предлагался на выбор набор тарифных планов и дополнительных услуг. После выбора и оплаты регистрация завершалась, и клиент попадал в свой личный кабинет. Мы проверили эту процедуру вдоль и поперек: все работало так, как нужно, ровно до того чудесного дня, когда было принято решение ввести новый промоплан для привлечения клиентов. Первая акция такого рода прошла весьма успешно: при регистрации по промоплану клиенту начислялся бонус на счет, и давался бесплатный доступ на 30 дней к одному дружественному сервису.
Вторая промо-акция отличалась тем, что клиенту при регистрации предлагался на выбор один из трех дружественных сервисов для бесплатного доступа. И тут что-то пошло не так: всем новым клиентам отправлялся доступ только к дружественному сервису из первой акции. Мы получили волну возмущения в саппорте и отток клиентов.
Ошибка заключалась в том, что первая промо-акция была учтена в базе под названием promo_1, а вторая – под promo_12, promo_13 и promo_14, но при этом в базу все записывалось под именем promo_1. Данные промо-акции не внесли в спецификацию, поэтому тест-кейсы не были составлены для новых акций. У тестировщиков не было доступа в базу и они не могли проверить правильность записи о тарифном плане.
У этого метода существует несколько названий («стеклянный ящик», «открытый ящик» и др.), но чаще всего его все-таки именуют методом «белого ящика». Проверка «белого ящика» – это метод тестирования программного обеспечения, который предполагает, что внутренняя структура, устройство и реализация системы известны тестировщику.

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

Виды тестирования «серого ящика»:
— Матричное тестирование.
— Регрессионное тестирование.
— Шаблонное тестирование (pattern).
— Тестирование с помощью ортогонального массива.
— Тестирование серого ящика включает в себя плюсы тестирования «черного» и «белого». Другими словами, тестировщик смотрит на объект тестирования с позиции «черного» ящика, но при этом проводит анализ на основе тех данных, что он знает о системе.
— Тестировщик может проектировать и использовать более сложные сценарии тестирования.
— Тестировщик работает совместно с разработчиком, что позволяет на начальном этапе убрать избыточные тест-кейсы. Это сокращает время функционального и нефункционального тестирования и положительно влияет на общее качество продукта.
— Предоставляет разработчику достаточно времени для исправления дефектов.
— Возможность анализа кода и тестового покрытия ограничена, так как доступ к исходному коду отсутствует.
— Тесты могут быть избыточными в том случае, когда разработчик также проверяет свой код Unit-тестами.
— Нельзя протестировать все возможные потоки ввода и вывода, поскольку на это требуется слишком много времени
В нашем примере у каждого клиента мог быть набор дополнительных функций (capabilities):
— «can_vpn» – клиент мог подключиться к VPN;
— «can_double_vpn» – клиент получал возможность подключиться к VPN, используя функцию DoubleVPN;
— «can_port_forward» – клиент имел дополнительный порт для входящих подключений на стороне сервера;
— «can_promo1» – клиент имел доступ к дружественному сервису.
Для удобства проверки разработчики предусмотрели возможность тестировщикам читать набор разрешенных функций из таблицы capabilities для каждого клиента. Тестировщики ставили тарифный план (подписку) и проверяли правильность изменения флагов в этой таблице. Без использования методики «серого ящика» проверка возможности для клиента совершить VPN-соединение в сочетании с дополнительными функциями потребовала бы гораздо больших затрат времени и труда.
Из пре
— когда нет возможности использовать «белый ящик»;
— когда необходимо более полное покрытие по сравнению с «черным ящиком».
Используя этот метод, тестировщики получают доступ к проектной документации и могут подготовить и создать более точные и полные тест-кейсы и сценарии тестирования. Наибольшая эффективность применения «серого ящика» достигается при тестировании web-приложений, web-сервисов, безопасности, GUI, а также для функционального тестирования.
пятница, 26 января 2018 г.
Тестирование черного и белого ящика
Черный ящик (black box testing)
Тестирование черного ящика — это когда мы не знаем, как система устроена внутри. У нас нет доступа к коду или мы не умеем его читать. Поэтому ориентируемся только на внешнее поведение или ТЗ.
Это начинающий автомобилист. Заглянуть под капот? Ой, там слишком страшно, будем верить приборам и точка.
Это основной вид тестирования, с которого все начинают. Перед тем, как залезть в код, стоит научиться писать тесты на основе сценариев использования и знаний про тест-дизайн и классы эквивалентности.
Если я сейчас открою любой сайт:
Белый ящик (white box testing)
Тестирование белого ящика — это когда у нас есть доступ к коду, и мы его тестируем. Читаем сам код (статическое тестирование), запускаем в дебаге, пишем автотесты.
Если сравнивать с автомобилистом, то тут уже не новичок, а прошаренный. Сломалось что-то? Нафиг приборы, сразу лезем под капот, где все устройство чуть ли не наизусть уже знаем. Роемся там, ищем причину.
Самостоятельно освоить белый ящик трудновато, обычно с ним сталкиваются уже на реальной работе. Но можете поискать проекты с открытым исходным кодом и тестировать их.
Как пример открытого проекта — Folks, его можно скачать, запустить, и даже написать свои автотесты, прогон которых как раз и будет тестированием самого кода, белого ящика. User interface у folks нет и не будет, так что тестирование черного ящика там недоступно.
Плюсы подхода — можно писать меньше тестов. Мы ведь знаем, что тут и тут будет работать одинаково, видим по коду. Но иногда настолько углубляемся в код, что читаем именно его, а не ТЗ, и можем пропустить какие-то баги (см плюсы черного ящика)
Серый ящик (gray box testing)
Тестирование серого ящика — это совмещение. Мы смотрим в код и понимаем, как он устроен. А потом открываем само приложение и проверяем, как этот код отображается уже в нем, но ориентируемся уже больше на ТЗ.
На примере автомобилиста это самый распространенный сценарий. Чтобы получить права, мы должны пройти специальный курс, на котором рассказывается, как устроена машина внутри → это знание кода, white box. Но потом мы начинаем кататься на своей машине и в основном ориентируемся на приборы → user interface, black box. При этом мы трактуем показания приборов на основе знаний кода.
Если говорить про тестирование, то это любое тестирование системы через интерфейс, когда у вас есть доступ к коду, но нет знаний разработчика. Да, вы можете подсмотреть в коде какие-то простейшие вещи: какой тип данных у этого значения, какие настройки у полей итд. Но вот потроха сложных методов остаются за гранью )))
В итоге мы вроде знаем, как это все устроено, но частично. Поэтому перепроверяем по черному ящику, где-то напишем чуть больше тестов для перестраховки. Вообще самый оптимальный метод тестирования: вы и в коде баги можете найти, и по ТЗ проверить!
Главное, чтобы доступ к коду дали, хотя бы частичный ツ
Хотя есть и другая версия — знание высокоуровневой структуры приложения: модулей, баз, например, но без доступа к коду. Или знание алгоритма, но опять же без доступа к собственно коду. Например, по псевдокоду.
Но смысл один: мы что-то из кода знаем, а что-то нет.
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

















