# Тестирование методом черного ящика (Black Box Testing)

*Тестирование методом черного ящика (black box testing): Тестирование, функциональное или нефункциональное, без знания внутренней структуры компонента или системы (ISTQB).*

*Тестирование на основе спецификации (specification-based testing): Тестирование, основным базисом которого являются внешние вводы и выводы элемента тестирования, обычно на основе спецификации, а не ее реализация в исходном коде или исполнимом программном обеспечении. (ГОСТ 56920)*

Другие названия: Behavioral Testing, Specification-Based Testing, Input-Output Testing, непрозрачный ящик (opaque-box), закрытый ящик (closed-box), тестирование на основе спецификации (specification-based testing) или тестирование с глазу на глаз (eye-to-eye testing).

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

**Functional Testing**: этот тип касается функциональных требований или спецификаций приложения (functional requirements or specifications). Здесь различные действия или функции системы тестируются путем предоставления входных данных и сравнения фактического выхода с ожидаемым выходом. Например, когда мы тестируем раскрывающийся список, мы нажимаем на него и проверяем, что он раскрывается и все ожидаемые значения отображаются. Вот несколько основных типов функционального тестирования:

* Smoke Testing;
* Sanity Testing;
* Integration Testing;
* System Testing;
* Regression Testing;
* User Acceptance Testing;

**Non-Functional Testing**: Помимо функциональности требований, есть несколько нефункциональных аспектов, которые необходимо протестировать, чтобы улучшить качество и производительность приложения. Несколько основных типов нефункционального тестирования включают:

* Usability Testing;
* Load Testing;
* Performance Testing;
* Compatibility Testing;
* Stress Testing;
* Scalability Testing;

**Преимущества Black box testing**:

* Тестировщику не обязательно иметь технический опыт. Важно проводить тестирование, оказываясь на месте пользователя и думая с его точки зрения;
* Тестирование можно начинать после завершения разработки проекта / приложения. И тестировщики, и разработчики работают независимо, не мешая друг другу;
* Это более эффективно для больших и сложных приложений;
* Дефекты и несоответствия можно выявить на ранней стадии тестирования;

**Недостатки Black box testing**:

* Без каких-либо технических или программных знаний есть вероятность пропустить возможные условия тестируемого сценария;
* В оговоренное время есть вероятность протестировать не все входные и выходные значения;
* Полный Test Coverage невозможен для больших и сложных проектов;

**Парадигмы тестирования методом черного ящика (Paradigms of Black Box Software Testing)**

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

* **Domain driven**
  * Ключевые идеи:
    * «Попробуйте диапазоны и варианты»;
    * «Разделите мир на классы»;
  * Основной вопрос или цель:
    * Стратегия стратифицированной выборки. Разделите большое пространство возможных тестов на подмножества. Выберите лучших представителей из каждого набора;
  * Примеры кейсов:
    * Анализ эквивалентности простого числового поля;
    * Тестирование совместимости принтеров;
  * Сильные стороны:
    * Нахождение ошибок с наибольшей вероятностью с помощью относительно небольшого набора тестов;
    * Интуитивно понятный подход, хорошо обобщает;
  * Слепые зоны:
    * Ошибки, выходящие за рамки границ, или в очевидных особых случаях;
    * Кроме того, фактические домены часто остаются неизвестными;
* **Stress driven**
  * Ключевые идеи:
    * «Сокруши продукт»;
    * «Проведи его через отказы;
  * Основной вопрос или цель:
    * Узнать о возможностях и слабых сторонах продукта, проведя его через отказ и за его пределами. Что сбои в экстремальных случаях говорят нам об изменениях, необходимых в работе программы в нормальных случаях?
  * Примеры кейсов:
    * Большие объемы данных, подключения устройств, длинные цепочки транзакций;
    * Условия нехватки памяти, сбои устройств, вирусы и другие проблемы;
  * Сильные стороны:
    * Выявление слабых мест, в т.ч. дыр в безопасности;
  * Слепые зоны:
    * Слабости, которые не становятся более заметными из-за стресса;
* **Specification driven**
  * Ключевые идеи:
    * «Проверяйте каждое требование»;
  * Основной вопрос или цель:
    * Проверяйте соответствие (conformance) продукта каждому заявлению в каждой спецификации, документе с требованиями и т. д.;
  * Примеры кейсов:
    * Матрица прослеживаемости, отслеживает тестовые случаи, связанные с каждым элементом спецификации;
  * Сильные стороны:
    * Критическая защита от гарантийных претензий, обвинений в мошенничестве, потери доверия со стороны клиентов;
  * Слепые зоны:
    * Любые проблемы, не указанные в спецификациях или плохо решенные в спецификациях;
* **Risk driven**
  * Ключевые идеи:
    * «Сначала найди наибольшие ошибки»;
  * Основной вопрос или цель:
    * Расставьте приоритеты при тестировании с точки зрения относительного риска различных областей или проблем, которые мы могли бы проверить;
  * Примеры кейсов:
    * Переформулированный анализ классов эквивалентности;
    * Тестируйте в порядке частоты использования;
    * Стресс-тесты, тесты на обработку ошибок, тесты безопасности, тесты для поиска прогнозируемых или предполагаемых ошибок;
    * Образец из списка предсказанных ошибок;
  * Сильные стороны:
    * Оптимальная приоритезация (при условии, что мы правильно идентифицируем и расставляем по приоритетам риски);
    * Тесты высокой мощности;
  * Слепые зоны:
    * Риски, которые не были идентифицированы или которые на удивление более вероятны;
* **Random / statistical testing**
  * Ключевые идеи:
    * «Объемное тестирование с новыми кейсами»;
  * Основной вопрос или цель:
    * Пусть компьютер создает, выполняет и оценивает огромное количество тестов;
  * Примеры кейсов:
    * Валидация функции или подсистемы (например, тестирование эквивалентности функций) на основе оракулов (Oracle-driven);
    * Стохастическое (переход между состояниями) тестирование для выявления конкретных сбоев (ассерты, утечки и т. д.);
    * Оценка статистической надежности;
    * Частичный или эвристический оракул, чтобы найти некоторые типы ошибок без общей проверки;
  * Сильные стороны:
    * Регрессия не зависит каждый раз от одного и того же старого теста;
    * Частичные оракулы могут быстро и дешево находить ошибки в молодом коде;
    * Меньше вероятность пропустить невидимые извне внутренние оптимизации;
    * Может обнаруживать сбои, возникающие из-за длинных сложных цепочек, которые было бы трудно создать в соответствии с запланированными испытаниями;
  * Слепые зоны:
    * Нужно уметь отличать pass от failure. Слишком много людей думают: «Not crash = not fail»;
    * Кроме того, эти методы часто охватывают многие типы рисков, но затемняют необходимость в других тестах, которые не поддаются автоматизации;
* **Function Testing**
  * Ключевые идеи:
    * «Модульное тестирование черного ящика»;
  * Основной вопрос или цель:
    * Тщательно проверяйте каждую функцию по очереди;
  * Примеры кейсов:
    * Таблица, тестируйте каждый элемент по отдельности;
    * База данных, тестируйте каждый отчет по отдельности;
  * Сильные стороны:
    * Тщательный анализ каждого протестированного элемента;
  * Слепые зоны:
    * Упускает взаимодействия, пропускает исследование преимуществ предлагаемые программой;
* **Regression Testing**
  * Ключевые идеи:
    * «Повторить тестирование после изменений»;
  * Основной вопрос или цель:
    * Управляйте рисками, связанными с тем, что (а) исправление ошибки не устраняет ошибку или (б) исправление (или другое изменение) имело побочный эффект (side effect);
  * Примеры кейсов:
    * Регрессия ошибок, регрессия старых исправлений, общая функциональная регрессия;
    * Наборы автоматизированной регрессии графического интерфейса;
  * Сильные стороны:
    * Обнадеживает, укрепляет доверие, удобен для регуляторов;
  * Слепые зоны:
    * Все, что не вошло в регрессионную серию. Кроме того, поддержание этого стандартного списка может быть очень дорогостоящим;
* **Scenario / use case / transaction flow**
  * Ключевые идеи:
    * «Делай что-нибудь полезное и интересное»;
    * «Делайте одно за другим»;
  * Основной вопрос или цель:
    * Сложные случаи, отражающие реальное использование;
  * Примеры кейсов:
    * Оценивайте продукт на предмет соответствия бизнес-правилам, данным о клиентах и продукции конкурентов;
    * Тестирование жизненного цикла / Life history testing ([Hans Buwalda’s “soap opera testing”](https://www.agileconnection.com/sites/default/files/presentation/file/2018/W11_14.pdf));
    * Варианты использования (Use cases) - это более простая форма, часто основанная на возможностях продукта и пользовательской модели, а не на естественном наблюдении за системами такого типа;
  * Сильные стороны:
    * Сложные, реалистичные события. Может помогать справляться в ситуациях, которые слишком сложны для моделирования;
    * Выявляет сбои, которые происходят (развиваются) с течением времени;
  * Слепые зоны:
    * Отказ одной функции может сделать этот тест неэффективным;
    * Необходимо хорошо подумать, чтобы добиться хорошего покрытия;
* **User testing**
  * Ключевые идеи:
    * Стремитесь к реализму;
    * Давайте попробуем это с настоящими людьми (для разнообразия);
  * Основной вопрос или цель:
    * Выявить сбои, которые могут возникнуть по вине человека, то есть сбои в общей системе человек / машина / программное обеспечение;
  * Примеры кейсов:
    * Бета-тестирование;
    * Собственные эксперименты с использованием стратифицированной выборки целевого рынка;
  * Сильные стороны:
    * Проблемы дизайна более достоверны;
    * Может продемонстрировать, что некоторые аспекты продукта непонятны или приводят к высокому проценту ошибок при использовании;
    * Внутренние тесты можно контролировать с помощью логов, видео, отладчиков и других инструментов;
    * Внутренние тесты могут быть сосредоточены на областях / задачах, которые, по вашему мнению, являются (или должны быть) спорными;
  * Слепые зоны:
    * Покрытие не гарантировано (серьезные пропуски бета-тестирования, других пользовательских тестов);
    * Тестовые примеры могут быть плохо спроектированы, тривиальны, вряд ли выявляют малозаметные ошибки;
    * Бета-тестирование стоит денег;
* **Exploratory testing**
  * Ключевые идеи:
    * «Интерактивное, одновременное исследование, разработка тестов и тестирование»;
  * Основной вопрос или цель:
    * ПО поступает тестировщику без документации. Тестировщик должен одновременно узнавать о продукте и о тестовых примерах / стратегиях, которые позволят выявить продукт и его дефекты;
  * Примеры кейсов:
    * Полное тестирование test-it-today;
    * Сторонние компоненты;
    * Горилла-тестинг;
  * Сильные стороны:
    * Продуманная стратегия получения результата в неизвестности;
    * Стратегия выявления несоответствия ожиданиям клиентов;
  * Слепые зоны:
    * Чем меньше мы знаем, тем больше рискуем упустить.

Источники:

* [Black Box Testing: An In-Depth Tutorial With Examples And Techniques](https://www.softwaretestinghelp.com/black-box-testing/)
* [Cem Kaner, James Bach - “Paradigms of Black Box Software Testing”](http://kaner.com/pdfs/swparadigm.pdf)