# Тестирование методом черного ящика (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) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/testirovanie-metodom-chernogo-yashika-black-box-testing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.