Черный и белый ящик тестирование кратко

Обновлено: 05.07.2024

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

Самым высоким уровнем в иерархии подходов к тестированию будет понятие типа, которое может охватывать сразу несколько смежных техник тестирования. То есть, одному типу тестирования может соответствовать несколько его видов. Рассмотрим, для начала, несколько типов тестирования, которые отличаются знанием внутреннего устройства объекта тестирования.

Black Box

Summary: Мы не знаем, как устроена тестируемая система.

Согласно ISTQB, тестирование черного ящика – это:

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

неправильно реализованные или недостающие функции;
ошибки интерфейса;
ошибки в структурах данных или организации доступа к внешним базам данных;
ошибки поведения или недостаточная производительности системы;

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

Пример:

Тестировщик проводит тестирование веб-сайта, не зная особенностей его реализации, используя только предусмотренные разработчиком поля ввода и кнопки. Источник ожидаемого результата – спецификация.

Поскольку это тип тестирования, то он может включать и другие его виды. Тестирование черного ящика может быть как функциональным, так и нефункциональным. Функциональное тестирование предполагает проверку работы функций системы, а нефункциональное – общие характеристики нашей программы.

Техника черного ящика применима на всех уровнях тестирования (от модульного до приемочного), для которых существует спецификация. Например, при осуществлении системного или интеграционного тестирования, требования или функциональная спецификация будут основой для написания тест-кейсов.

Техники тест-дизайна, основанные на использовании черного ящика, включают:

классы эквивалентности;
анализ граничных значений;
таблицы решений;
диаграммы изменения состояния;
тестирование всех пар.

Преимущества:

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

Недостатки:

тестируется только очень ограниченное количество путей выполнения программы;
без четкой спецификации (а это скорее реальность на многих проектах) достаточно трудно составить эффективные тест-кейсы;
некоторые тесты могут оказаться избыточными, если они уже были проведены разработчиком на уровне модульного тестирования.

Противоположностью техники черного ящика является тестирование методом белого ящика, речь о котором пойдет ниже.

White Box

Summary: Нам известны все детали реализации тестируемой программы.

Тестирование методом белого ящика (также прозрачного, открытого, стеклянного ящика или же основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы за пределы ее внешних интерфейсов.

Согласно ISTQB: тестирование белого ящика – это:

тестирование, основанное на анализе внутренней структуры компонента или системы;
тест-дизайн, основанный на технике белого ящика – процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.

Пример:

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

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

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

Преимущества:

тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;
можно провести более тщательное тестирование с покрытием большого количества путей выполнения программы.

Недостатки:

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

Сравнение Black Box и White Box

Grey Box

Summary: Нам известны только некоторые особенности реализации тестируемой системы.

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

Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.

Пример:

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

Техника серого ящика применима на разных уровнях тестирования: от модульного до системного, но, главным образом, применяется на интеграционном уровне для проверки взаимодействия разных модулей программы.

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

Тестирование белого и черного ящиков в одном предложении

Вот самое простое определение: Тестирование белого ящика базируется на знаниях об устройстве системы. Тестирование черного ящика базируется на знаниях требований к системе.

Это и есть основной смысл и главное отличие между двумя подходами. Но в этой статье мы копнем глубже. Вот, что мы рассмотрим:

Какие цели у тестирования белого и черного ящиков?
В чем отличия между подходами?
Какой подход выбрать для проекта?

Давайте открывать ящики и смотреть, что там внутри!

Что такое тестирование черного ящика?

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

Тестирование черного ящика делится на:

Функциональное тестирование – проверка функциональности приложения (“Что приложение делает?”)
Нефункциональное тестирование – проверка производительности, безопасности, usability (“Как приложение работает?”)

В тестирование черного ящика также входит и так называемое тестирование на основе опыта (Experience-based testing). QA проверяет приложение, основываясь на интуиции и опыте тестирования других похожих проектов.

Какая цель у тестирования черного ящика?

Главная цель – проверить, что приложение разработано в соответствии с требованиями, соответствует ожиданиям клиента и не содержит ошибок.

Проводя тестирование черного ящика, нужно получить ответы на следующие вопросы:

Работают ли все функции приложения правильно?
Совпадает ли внешний вид приложения с макетами?
Выполняются ли пользовательские сценарии?
Корректны ли данные?

Как проводить тестирование черного ящика?

Проведение такого тестирования требует подготовки – вот, что нужно сделать заранее:

Провести анализ требований и спецификаций
Узнать о приложении в целом
Подготовить тест-кейсы
Подготовить тестовые данные (в том числе и для негативных сценариев)

Когда всё вышеперечисленное сделано, QA выполняет тест-кейсы и делает детальный отчет с результатами, сообщает о найденных ошибках и повторно тестирует после исправления багов разработчиками.

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

Как подготовить данные и тест-кейсы для тестирования черного ящика?

Глубокий анализ функциональности и вдумчивое и осознанное написание тест-кейсов позволяют значительно сократить количество тестов, которые нужно будет провести.

Вот основные техники для разработки тест-кейсов для функционального тестирования:

Граничные значения

Граничные значения это входные или выходные данные (которые пользователь может вводить в поля), которые находятся в непосредственной близости от классов эквивалентности.

Классы эквивалентности

Классы эквивалентности это наборы входных данных, обработка которых приводит к одному и тому же результату.

Давайте отойдем от теории и попробуем понять, что это, на примере:

Представьте, что вам нужно протестировать поле “возраст” в форме приложения, предназначенного для людей от 20 до 30 лет. Поле принимает значения типа integer. Какие здесь будут классы эквивалентности и граничные значения?

Классы эквивалентности:

20-30 – позитивный тест
От минус бесконечности до 19 и от 31 до плюс бесконечности – негативный тест

Граничные значения: 19, 20, 21, 29, 30, 31

20, 21, 29, 30 – позитивный тест
19, 31 – негативный тест

Таблица решений (Decision table)

Таблица решений показывает возможные комбинации входных данных и ожидаемых результатов. Используется для создания тест-кейсов.

Давайте рассмотрим ее на примере.

Вы тестируете онлайн магазин предлагает скидки и бесплатную доставку. Если вы размещаете заказ на сумму больше 10000 рублей, вы получаете 10% скидку. Если делать заказ на сумму больше 15000 рублей – 15% скидку. Если на сумму больше 20000 рублей – 20% скидку и бесплатную доставку. Таблица решений будет выглядеть следующим образом:

Условия скидки	Т1	Т2	Т3	Т4
Заказы до 10 000 рублей	Да
Заказы больше 10 000 рублей	Да
Заказы больше 15 000 рублей	Да
Заказы больше 20 000 рублей	Да
Размер скидки	Т1	Т2	Т3	Т4
10%	Нет	Да	Нет	Нет
15%	Нет	Нет	Да	Нет
20%	Нет	Нет	Нет	Да
Бесплатная доставка	Нет	Нет	Нет	Да

Преимущества тестирования черного ящика

QA проводит тестирование, пользуясь приложением так, как это делал бы конечный пользователь
Позволяет найти несоответствия между спецификацией и разработанным приложением
QA не должен глубоко погружаться в особенности разработки и архитектуры
В рамках тестирования создается документация, включающая в себя тест-кейсы
Тест-кейсы могут быть автоматизированы

Недостатки тестирования черного ящика

Требования или спецификация могут быть неточными и/или непонятными, поэтому могут быть трудности с написанием тест-кейсов.
Может быть сложно протестировать все части приложения.

Перейдем к тестированию белого ящика:

Что такое тестирование белого ящика?

Тестирование белого ящика (стеклянного ящика) проверяет исходный код и ставит целью убедиться, что он работает правильно. Инженер, занимающийся тестированием должен знать программирование на достаточном уровне. Часто такое тестирование проводят сами разработчики.

Два основных метода проведения тестирования белого ящика:

Statement coverage testing – покрытие операторов. Во время тестирования покрывают код так, чтобы во время тестирования каждый оператор выполнился хотя бы один раз.
Decision/Branch coverage testing – покрытие решений. Код покрывается тестами так, чтобы во время тестирования выполнились все ветки всех условных операторов.

Как подготовиться к тестированию белого ящика?

Есть много инструментов, библиотек и фрейворков для тестирования белого ящика. Мы сфокусируемся на JEST – библиотеке для тестирования JavaScript кода. То, что мы выбрали эту библиотеку не говорит о том, что она лучшая – просто на ней удобнее показывать примеры (прим.ред. – вот материал нашего читателя с подборкой best practices для Unit-тестирования фронтенда)

Рассмотрим JavaScript функцию:

Вы, скорее всего, заметили, что выполнение условий в функции будет зависеть от входных данных.

Чтобы легче понять все ветвления внутри функции, используем code2flow. Он поможет преобразовать код в граф:

Теперь мы можем приступить к написанию первого теста.

Как проводить тестирование белого ящика?

Покрытие операторов (Statement coverage testing)

Нужно подобрать входные данные и вызвать функцию таким образом, чтобы каждый из операторов выполнился хотя бы один раз. Для 100% покрытия достаточно сделать 2 теста и вызвать функцию со следующими параметрами:

Coverage-отчет выглядит следующим образом:

Покрытие решений (Decision coverage testing)

Из coverage-отчета на предыдущем изображении понятно, что строки 4, 9, 16 не покрыты. Чтобы покрыть их, нужно добавить тесты, которые при выполнении функции пойдут по веткам, содержащим эти непокрытые строки. Тестовые данные будут выглядеть следующим образом:

Тест будет выглядеть следующим образом:

Теперь наш coverage-отчет полностью зеленый:

Преимущества тестирования белого ящика

Очень большая точность
Просто автоматизировать
Позволяет определить, где в коде произошла ошибка
Для выполнения тестирования не нужен UI

Недостатки тестирования белого ящика

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

Что лучше? Белый или черный ящик использовать?

Мир тестирования не черный и не белый – он серый 🙂 Поэтому здесь нет правильного ответа и нет лучшего подхода.

Лучшее решение – комбинировать белый и черный ящик. Это гарантирует покрытие всего приложения тест-кейсами и качественную проверку как исходного кода, так и бизнес-функциональности.

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

Тестирование белого ящика

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

Тестирование белого ящика предполагает поиск и улучшение следующих моментов:

Нерабочих или неоптимизированных участков кода
Потеря безопасности
Рабочие процессы и сценарии ввода
Условные процессы
Неправильное функционирование объектов
Некорректное отображения информации.

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

Как осуществляется тестирование белого ящика?

Есть два шага для реализации данного этапа.

Шаг 1. Изучение исходного кода.

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

Шаг 2. Создание и внедрение алгоритмов проверки

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

Основной подход – анализ кода. Выборка недоработок в процессе внедрения алгоритмов тестирования. Все алгоритмы запускаются по несколько раз на разных участках кода, помогая изъять возможные проблемные участки.

От тестировщика не требуется выполнения всего процесса вручную. Существует большое количество инструментов, которые помогут автоматизировать рабочий процесс и сохранить время.

Тестирование черного ящика

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

Метод черного ящика применим на следующих уровнях тестирования

Тестирование системы
Тестирование интеграции
Приемочных испытаниях

Количество методов тестирования зависит от сложности продукта, т.е. ящика.

Подходы к разработке алгоритмов тестирования черного ящика бывают следующие:

Причинно-следственные (определение случаев и их воздействия на систему)
Анализ крайних значений (определение границ ввода)
Разметка эквивалентности (действительные и недействительные разметки)

Тестирование серого ящика

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

Подходы к тестированию

Тестирование шаблонов
Тестирование матрицы
Регрессионное тестирование
Тестирование с использованием ортогонального массива

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

Почему оба подхода до сих пор существуют? Разве тестирование с доступом к коду не эффективнее? Может существует золотая середина? Давайте разбираться.

Черный ящик

Разработка тестов методом черного ящика (black box test design technique) — процедура создания и/или выбора тестовых сценариев, основанная на анализе функциональной или нефункциональной спецификации компонента или системы без знания внутренней структуры. (ISTQB)

Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит.

Основной посыл такого тестирования в том, что мы не знаем, как устроена тестируемая система. Имеется ввиду изнутри. При таком тестировании тестировщик очень похож на обычного пользователя: тест анализ и исследование продукта он проводит опираясь на ТЗ (техническое задание), спецификации и прочую документацию, которая описывает этот продукт.

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

Пример. Заходим в приложение вызова такси и видим возможность привязать карту для автоматической оплаты. Начинаем думать как пользователь:
— Что, если привязать заблокированную карту?
— А если забыть/неверно указать срок действия карты?
— Долларовая карта привяжется?
— А может можно после вызова такси и подачи машины быстро отвязать ее до списания оплаты… Что тогда будет? Спишутся средства? Или водителю придет уведомление, что оплата изменилась с безналичной на наличную?

По сути, мы тестируем и строим предположения на основе того, что видим и рисуем себе в голове. То есть мы только предполагаем, что элементы должны работать таким образом и на основании этого подбираем тесты, но точно не уверены, что это именно так.

Либо открываем спецификацию и смотрим, как система должна работать. Потом запускаем продукт и сверяем его с тем, что указано в спецификации.

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

Тестировщик не обязан обладать (глубокими) знаниями в области программирования.
Поведение приложения исследуется в контексте реальной среды выполнения и учитывает её влияние.
Поведение приложения исследуется в контексте реальных пользовательских сценариев.
Тест-кейсы можно создавать уже на стадии появления стабильных требований.
Процесс создания тест-кейсов позволяет выявить дефекты в требованиях.
Допускает создание тест-кейсов, которые можно многократно использовать на разных проектах.

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

Белый ящик

Разработка тестов методом белого ящика (white-box test design technique): Процедура разработки или выбора тестовых сценариев на основании анализа внутренней структуры компонента или системы. (ISTQB)

Белый ящик является полной противоположностью черному ящику. При тестировании черного ящика, нам необходимо запускать программу и смотреть, что она делает. А в белом этого не требуется. Достаточно смотреть на код программы.

Основной посыл этого типа тестирования — нам известны все детали реализации тестируемой программы.

Тестирование методом белого ящика (прозрачного, открытого, стеклянного ящика, основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации – обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы, за пределы ее внешних интерфейсов.

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

Показывает скрытые проблемы и упрощает их диагностику.
Допускает достаточно простую автоматизацию тест-кейсов и их выполнение на самых ранних стадиях развития проекта.
Обладает развитой системой метрик, сбор и анализ которых легко автоматизируется.
Стимулирует разработчиков к написанию качественного кода.
Многие техники этого метода являются проверенными, хорошо себя зарекомендовавшими решениями, базирующимися на строгом техническом подходе.

Не может выполняться тестировщиками, не обладающими достаточными знаниями в области программирования.
Тестирование сфокусировано на реализованной функциональности, что повышает вероятность пропуска нереализованных требований.
Поведение приложения исследуется в отрыве от реальной среды выполнения и не учитывает её влияние.
Поведение приложения исследуется в отрыве от реальных пользовательских сценариев.

Серый ящик. Отдельный вид или миф?

Его основной посыл в том, что нам известны только некоторые особенности реализации тестируемой системы.

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

Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.

Кто-то говорит, что этот вид тестирования — это симбиоз белого и черного ящика. Кто-то противопоставляет его белому и черному, опираясь на то, что внутренняя структура тестируемого объекта изначально известна частично и выясняется по мере исследования.

Думаю, что на собеседовании это явно стоит упомянуть.

Почему все ящики эффективны?

Методы белого и черного ящика не являются конкурирующими или взаимоисключающими. Наоборот, они гармонично дополняют друг друга, компенсируя имеющиеся недостатки.

Параллельное использование черного и белого ящиков увеличивает покрытие возможных сценариев:

То есть у каждого из методов тестирования свои неоспоримые плюсы, которые помогают выпустить качественный продукт.

Читайте также: