«Черный ящик» или «белый ящик»: простыми словами о сложном, но таком важном

Тестирование методом «черного ящика» организовано как тестирование не отдельных элементов системы, а всей системы в целом. Собственно говоря, название свое этот метод тестирования получил в связи с тем, что внутренние механизмы системы, ее модули и их взаимодействие неизвестны тестировщику. Да и неинтересны. Здесь тестировщик играет роль конечного пользователя программы. А единственное, что имеет значение для пользователя, это то, насколько корректно работает программа.

Хотя, конечно, здесь следует оговориться, что тестировщик играет роль не просто обычного пользователя, а пользователя-пессимиста, который, как Капитан Зеленый из мультфильма «Тайна третьей планеты», вечно вопрошает: «Ну, что у нас плохого?». Или же роль злоумышленника, пытающегося вывести систему из строя.

Что в центре внимания?

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

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

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

Какие техники применяются?

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

Работая только с вводами (вводные данные) и выводами (возвращаемые результаты), тестировщик может выполнять следующие процедуры:

• Общий серфинг по приложению, проверка каждой кнопки и работы отдельной функции на соответствие заданным спецификациям. По сути, здесь тестировщик играет роль пользователя, который работает с программой в рамках заданного функционала.
• Угадывание ошибок, при котором тестировщик проверяет функции приложения, которые могут оказаться наиболее уязвимыми. По сути, здесь тестировщик играет роль так называемого «пользователя со злым умыслом», который всячески старается спровоцировать некорректное поведение системы или взломать ее. Как правило, предугадывание ошибок используется в первую очередь для проверки безопасности информационной системы и поиска ее уязвимостей. Ключевыми здесь являются знания о том, каковы наиболее распространенные уязвимости и проблемы функционирования программного обеспечения такого рода, а также как можно спровоцировать проявление данных проблем и уязвимостей.
  
• Эквивалентное разделение (анализ по классам эквивалентности), при которым осуществляется группировка вводных данных по определенным признакам. Основная аксиома здесь следующая: однородные вводы должны приводить к релевантным однородным выводам. Следовательно, нет необходимости перебирать все входные значения, а нужно протестировать поведение системы на примере лишь одного представителя группы. В качестве вводных данных могут быть цифры, буквы и любые символы.
  
• Анализ приграничных значений, при котором проверяется работа системы с вводами, близкими к заданным границам. В большинстве случаев, в качестве вводных данных здесь используются только числа, что связано со спецификой кластеризации и установления границ в числовом формате. Однако, если, например, в качестве признака группировки и установления границ используется алфавитный порядок, то, соответственно, в качестве вводных данных следует использовать буквы.
  
• И, наконец, нагрузочное тестирование, при котором осуществляется проверка работы системы при высоких нагрузках, ее производительность, масштабируемость и т.д.
  

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

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

Что в центре внимания?

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

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

Итог работы тестировщика здесь следующий: «Так, так, так! Этот фрагмент исходного кода является неполным (имеет недостатки, ошибки, тупики и т. д.). Это, безусловно, приведет к некорректной работе программы. Теперь, господа разработчики, ваша задача исправить ошибки кода и предотвратить развитие подобных негативных сценариев.»

Какие техники применяются?

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

Работая с исходным кодом, тестировщик, как правило, выполняет следующие процедуры:

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

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