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

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Cancel Create

QA_bible / vidy-metody-urovni-testirovaniya / testirovanie-metodom-chernogo-yashika-black-box-testing.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Cannot retrieve contributors at this time
194 lines (177 sloc) 19.5 KB

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents Copy raw contents

Copy raw contents

Тестирование методом черного ящика (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

• Ключевые идеи:

• «Попробуйте диапазоны и варианты»;
• «Разделите мир на классы»;

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

• Анализ эквивалентности простого числового поля;
• Тестирование совместимости принтеров;

• Нахождение ошибок с наибольшей вероятностью с помощью относительно небольшого набора тестов;
• Интуитивно понятный подход, хорошо обобщает;

• Ошибки, выходящие за рамки границ, или в очевидных особых случаях;
• Кроме того, фактические домены часто остаются неизвестными;

• Ключевые идеи:

• «Сокруши продукт»;
• «Проведи его через отказы;

• Узнать о возможностях и слабых сторонах продукта, проведя его через отказ и за его пределами. Что сбои в экстремальных случаях говорят нам об изменениях, необходимых в работе программы в нормальных случаях?

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

• Выявление слабых мест, в т.ч. дыр в безопасности;

• Слабости, которые не становятся более заметными из-за стресса;

• Ключевые идеи:

• «Проверяйте каждое требование»;

• Проверяйте соответствие (conformance) продукта каждому заявлению в каждой спецификации, документе с требованиями и т. д.;

• Матрица прослеживаемости, отслеживает тестовые случаи, связанные с каждым элементом спецификации;

• Критическая защита от гарантийных претензий, обвинений в мошенничестве, потери доверия со стороны клиентов;

• Любые проблемы, не указанные в спецификациях или плохо решенные в спецификациях;

• Ключевые идеи:

• «Сначала найди наибольшие ошибки»;

• Расставьте приоритеты при тестировании с точки зрения относительного риска различных областей или проблем, которые мы могли бы проверить;

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

• Оптимальная приоритезация (при условии, что мы правильно идентифицируем и расставляем по приоритетам риски);
• Тесты высокой мощности;

• Риски, которые не были идентифицированы или которые на удивление более вероятны;

• Ключевые идеи:

• «Объемное тестирование с новыми кейсами»;

• Пусть компьютер создает, выполняет и оценивает огромное количество тестов;

• Валидация функции или подсистемы (например, тестирование эквивалентности функций) на основе оракулов (Oracle-driven);
• Стохастическое (переход между состояниями) тестирование для выявления конкретных сбоев (ассерты, утечки и т. д.);
• Оценка статистической надежности;
• Частичный или эвристический оракул, чтобы найти некоторые типы ошибок без общей проверки;

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

• Нужно уметь отличать pass от failure. Слишком много людей думают: «Not crash = not fail»;
• Кроме того, эти методы часто охватывают многие типы рисков, но затемняют необходимость в других тестах, которые не поддаются автоматизации;

• Ключевые идеи:

• «Модульное тестирование черного ящика»;

• Тщательно проверяйте каждую функцию по очереди;

• Таблица, тестируйте каждый элемент по отдельности;
• База данных, тестируйте каждый отчет по отдельности;

• Тщательный анализ каждого протестированного элемента;

• Упускает взаимодействия, пропускает исследование преимуществ предлагаемые программой;

• Ключевые идеи:

• «Повторить тестирование после изменений»;

• Управляйте рисками, связанными с тем, что (а) исправление ошибки не устраняет ошибку или (б) исправление (или другое изменение) имело побочный эффект (side effect);

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

• Обнадеживает, укрепляет доверие, удобен для регуляторов;

• Все, что не вошло в регрессионную серию. Кроме того, поддержание этого стандартного списка может быть очень дорогостоящим;

• Ключевые идеи:

• «Делай что-нибудь полезное и интересное»;
• «Делайте одно за другим»;

• Сложные случаи, отражающие реальное использование;

• Оценивайте продукт на предмет соответствия бизнес-правилам, данным о клиентах и продукции конкурентов;
• Тестирование жизненного цикла / Life history testing (Hans Buwalda’s “soap opera testing”);
• Варианты использования (Use cases) — это более простая форма, часто основанная на возможностях продукта и пользовательской модели, а не на естественном наблюдении за системами такого типа;

• Сложные, реалистичные события. Может помогать справляться в ситуациях, которые слишком сложны для моделирования;
• Выявляет сбои, которые происходят (развиваются) с течением времени;

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

• Ключевые идеи:

• Стремитесь к реализму;
• Давайте попробуем это с настоящими людьми (для разнообразия);

• Выявить сбои, которые могут возникнуть по вине человека, то есть сбои в общей системе человек / машина / программное обеспечение;

• Бета-тестирование;
• Собственные эксперименты с использованием стратифицированной выборки целевого рынка;

• Проблемы дизайна более достоверны;
• Может продемонстрировать, что некоторые аспекты продукта непонятны или приводят к высокому проценту ошибок при использовании;
• Внутренние тесты можно контролировать с помощью логов, видео, отладчиков и других инструментов;
• Внутренние тесты могут быть сосредоточены на областях / задачах, которые, по вашему мнению, являются (или должны быть) спорными;

• Покрытие не гарантировано (серьезные пропуски бета-тестирования, других пользовательских тестов);
• Тестовые примеры могут быть плохо спроектированы, тривиальны, вряд ли выявляют малозаметные ошибки;
• Бета-тестирование стоит денег;

• Ключевые идеи:

• «Интерактивное, одновременное исследование, разработка тестов и тестирование»;

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

• Полное тестирование test-it-today;
• Сторонние компоненты;
• Горилла-тестинг;

• Продуманная стратегия получения результата в неизвестности;
• Стратегия выявления несоответствия ожиданиям клиентов;

• Чем меньше мы знаем, тем больше рискуем упустить.

• Black Box Testing: An In-Depth Tutorial With Examples And Techniques
• Cem Kaner, James Bach — “Paradigms of Black Box Software Testing”

Источник: github.com

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

Привет, Вы узнаете про черный ящик, Разберем основные ее виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое черный ящик, белый ящик, серый ящик , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

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

1. Модели черного , серого и белого ящиков

Черный я́щик — термин, используемый для обозначения системы , внутреннее устройство и механизм работы которой очень сложны, неизвестны или неважны в рамках данной задачи. «Метод черного ящика» — метод исследования таких систем, когда вместо свойств и взаимосвязей составных частей системы, изучается реакция системы, как целого, на изменяющиеся условия. Подход черного ящика сформировался в точных науках (в кибернетике , системотехнике и физике) в 1920—1940-х годах и был заимствован другими науками (например, бихевиористической психологией ). Тестирование методом черного ящика или поведенческое тестирование — стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве (коде) тестируемого объекта.

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

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

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

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

Тестирование методом белого ящика (англ. white-box testing), также тестирование стеклянного ящика (англ. glass-box testing), структурное тестирование (англ. structural testing) — тестирование, которое учитывает внутренние механизмы системы или компонента (ISO/IEC/IEEE 24765). Обычно включает тестирование ветвей, маршрутов, операторов (см. покрытие кода). При тестировании выбирают входы для выполнения разных частей кода и определяют ожидаемые результаты. Это напоминает внутрисхемное тестирование (англ.) . Black Box черный ящик тестирование методом черного ящик Summary: Мы не знаем, как устроена тестируемая система. Тестирование методом «черного ящика», также известное как тестирование, основанное на спецификации или тестирование поведения – техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы. Согласно ISTQB:

2. Тестирование черного ящика – это:

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

Почему именно «черный ящик»? Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит . Об этом говорит сайт https://intellect.icu . Целью этой техники является поиск ошибок в таких категориях:

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

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

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

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

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

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

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

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

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

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

Недостатки метода четного ящика:

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

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

Методы разработки тестов с использованием черного ящика

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

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

3. White Box белый ящик тестирование методом белого ящика

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

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

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

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

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

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

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

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

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

Уровни и методы тестирования с использованием белого ящика

1. Модульное тестирование . Тестирование методом белого ящика выполняется во время модульного тестирования, чтобы убедиться, что код работает должным образом, до того, как произойдет интеграция с ранее протестированным кодом. Тестирование методом белого ящика во время модульного тестирования потенциально выявляет многие дефекты на раннем этапе и помогает устранить дефекты, которые возникают позже, после интеграции кода с остальной частью приложения, и, следовательно, снижает влияние ошибок на более поздних этапах разработки.
2. Интеграционное тестирование . Тестирование белого ящика на этом уровне написано для проверки взаимодействия интерфейсов друг с другом. Тестирование на уровне модулей позволило убедиться, что каждый код протестирован и работает соответствующим образом в изолированной среде, а интеграция проверяет правильность поведения в открытой среде с помощью тестирования белого ящика для любых взаимодействий интерфейсов, известных программисту.
3. Регрессионное тестирование . Тестирование белого ящика во время регрессионного тестирования — это использование переработанных тестовых случаев белого ящика на уровне модульного и интеграционного тестирования.

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

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

Недостатки метода белого ящика:

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

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

4. Grey Box серый ящик , тестирование методом серого ящика

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

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

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

Пример использования метода серого ящика:

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

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

Методы используемые при тестировани методом серого ящика

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

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

Достоинства тестирования методом серого ящика

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

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

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

Вау!! Ты еще не читал? Это зря!

• Абстракция
• Квантовый оракул
• Криптография белого ящика
• Компьютерный эксперимент
• Компьютерное моделирование
• Дизайн экспериментов
• Тестирование в сером ящике
• Математическая модель
• Идентификация нелинейной системы
• Оценка параметров
• Дизайн исследования
• Научное моделирование
• Моделирование
• Статистическая модель
• Системная динамика
• Идентификация системы
• Системная реализация
• Теориясистем
• ABX тест
• Приемочное тестирование
• Слепой эксперимент
• Граничное тестирование
• Fuzz-тестирование
• Тестирование в сером ящике
• Проект Metasploit
• Проверка на вменяемость
• Дымовое испытание
• Тестирование производительности программного обеспечения
• Тестирование программного обеспечения
• Нагрузочное тестирование
• Автоматизация тестирования
• Модульное тестирование
• Сканер безопасности веб-приложений
• Хакер в белой шляпе
• Обезьянье тестирование (monkey testing)

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

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

Источник: intellect.icu

Что такое Black Box Testing?

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

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

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

Тестирование по стратегии чёрного и белого ящика — два вида тестирования, часто выполняемых разработчиками на этом этапе.

В статье мы расскажем о тестировании по стратегии чёрного ящика (black box testing), а также о фундаментальных сходствах и отличиях чёрного и белого ящика.

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

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

Она может применяться на всех уровнях тестирования ПО, но в основном используется на высоких уровнях.

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

Тестировщик осуществляет ввод, а вывод рассматривается как часть этой методики тестирования ПО.

Это позволяет определять реакцию системы на ожидаемые и неожиданные действия пользователя, время реакции, сложности юзабилити и проблемы с надёжностью.

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

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

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

Этот тип тестирования также называют тестированием opaque box, closed box, specification-based и eye-to-eye.

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

Эта методика тестирования разделяется на следующие типы:

▍ Функциональное тестирование

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

В этой методологии задействуется дымовое тестирование (smoke testing)/санитарное тестирование (sanity testing), интеграционное тестирование и системное тестирование для проверки уникальных функций и возможностей ПО.

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

▍ Нефункциональное тестирование

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

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

▍ Регрессионное тестирование

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

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

Методики Black Box Testing

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

▍ 1. Эквивалентное разделение

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

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

▍ 2. Анализ граничных значений

Тестировщики легко могут выявить уникальное поведение систем в диапазоне рядом с заданным граничным значением. Например, в поле допускается ввод чисел только от 0 до 99. Граничные значения (-100, 99 и 100) позволяют тестировщикам удобным образом убедиться в правильной проверке вводимых данных.

▍ 3. Симуляция таблицы решений

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

▍ 4. Тестирование на изменение состояния

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

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

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

▍ 5. Угадывание ошибок

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

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

Плюсы Black Box Testing

▍ 1. Быстрая разработка тестовых случаев

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

▍ 2. Тестирование можно отдавать на аутсорс

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

▍ 3. UX конечного пользователя

Тесты проводятся с точки зрения конечных пользователей.

▍ 4. Критическая оценка

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

Недостатки Black Box Testing

▍ 1. Пути тестирования могут упускаться или повторяться

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

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

▍ 2. Некоторые части приложения могут оказаться неизученными

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

▍ 3. Потребность в чётких и явных спецификациях тестирования

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

Заключение

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

• black box
• тестирование по
• testing
• software testing
• ruvds_перевод

Источник: habr.com