Испытание черного ящика против белого ящика

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

тестирование черного ящика равно интеграционному тестированию. Тестер гарантирует, что система работает в соответствии с требованиями на функциональном уровне.

оба подхода теста не менее важно на мой взгляд.

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

Черный Ящик

1 Основное внимание уделяется функциональности системы Фокусируется на структуре (программе) системы

2 Используемые методы :

· разбиение равнозначности

· анализ граничных значений

· ошибки угадывания

· условия гонки

· причинно-следственная графика

· тестирование синтаксиса

* тестирование состояния перехода

· Graph matrix

тестер может быть нетехническим

помогает определить неопределенность и противоречие в функциональных спецификациях

Белая Коробка

используемые методы:

* Тестирование Базового Пути

· Поток Графической Нотации

· Испытание Структуры Управления

1. Условие Испытаний

2. тестирование потока данных

· Тестирование Петли

1. Простые Петли

2. Вложенные Циклы

3. Сцепленные Циклы

4. Неструктурированных Петель

   тестер должен быть технический

   помогает определить логическое и кодирование проблемы.

"оба", как было указано выше, и это очевидный ответ...но ИМО, тестирование белого ящика выходит далеко за рамки модульного тестирования разработчика (хотя я предполагаю, что это может зависеть от того, где вы проводите линию между белым и черным). Например, анализ покрытия кода-это общий подход "белого ящика", то есть запуск некоторых сценариев или тестов и изучение результатов в поисках дыр в тестировании. Даже если модульные тесты имеют 100% cc, измерение cc в обычных пользовательских сценариях может выявить код, который может потребоваться даже больше испытаний.

другое место, где помогает тестирование белого ящика, - это изучение типов данных, констант и другой информации для поиска границ, специальных значений и т. д. Например, если приложение имеет вход, который принимает числовой вход, подход bb только может потребовать от тестировщика "угадать", какие значения будут хороши для тестирования, в то время как подход wb может показать, что все значения между 1-256 обрабатываются одним способом, а большие значения обрабатываются другим способом...и, возможно, номер 42 есть еще один путь кода.

Итак, чтобы ответить на первоначальный вопрос-оба bb и wb необходимы для хорошего тестирования.

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

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

Это не для скажем, что тестировщики должны оставаться в неведении о том, как работает система, просто я предпочитаю, чтобы они больше фокусировались на проблемной области и как фактические пользователи взаимодействуют с системой, а не будет ли функция SomeMethod(int x) правильно выбрасывать исключение, если x равен 5.

Это немного открытая дверь, но в конце концов оба примерно одинаково важны.

Что хуже?

1. программное обеспечение, которое делает то, что ему нужно сделать, но внутренне имеет проблемы?

2. программное обеспечение, которое должно работать, если вы посмотрите на источники, но не?

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

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

tecniques испытания черного ящика: 1. Раздел Equivalance 2. Границы Функционально-Стоимостного Анализа 3. Таблица решений 4. Диаграмма Перехода Состояния 4. Вариант использования схемы

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

методы испытания белой коробки: 1. Охват Ведомостей 2. Охват Решений 3. Охват Ветвей 4. Покрытие Пути.

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

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

QA должен сосредоточиться на тестирование черного ящика. Основная цель QA-проверить, что делает система (соответствуют ли функции требованиям ?), а не как он это делает.

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

дальше, я думаю developpers тоже следует сосредоточиться на тестирование черного ящика. Я не согласен с этим распространенным связь между модульным тестированием и тестированием белого ящика, но это может быть просто вопрос словаря/шкалы. В масштабе единичного теста Тестируемая Система класс/метод, который имеет контракта (его подписания) и важный момент-проверить, что он делает, а не как. Кроме того, тестирование белого ящика подразумевает, что вы знаете, как метод заполнит свой контракт, который кажется мне некомпетентным с TDD.

IMHO, если ваш SUT настолько сложен, что вам нужно сделать белый ящик тестирование, это обычно время для рефакторинга.

Что означает "внутреннее знание"?"Подходит ли знание того, что такой-то алгоритм использовался для решения проблемы, или тестер должен видеть каждую строку кода, чтобы она была "внутренней"?"

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

• *тестирование черного ящика: тест на системном уровне для проверки функциональности системы, чтобы убедиться, что система выполняет все функции, для которых она была разработана, в основном для выявления дефектов, обнаруженных в точке пользователя. Лучше нанять профессионального тестировщика для черного ящика вашей системы, потому что разработчик обычно тестирует с точки зрения того, что коды, которые он написал, хороши и отвечают функциональным требованиям клиентов, чтобы он мог пропустить много вещей (я не обидеть кого-нибудь)
• Whitebox-это первый тест, который выполняется в SDLC.Это выявить ошибки, такие как ошибки выполнения и компиляции errrors это может быть сделано либо тестировщиками или самим разработчиком, но я думаю, что его всегда лучше, что человек, который написал код проверяет его.Он понимает их больше, чем кто-либо другой.*

тестирование черного ящика-это метод тестирования программного обеспечения, в котором внутренняя структура/ дизайн/ реализация тестируемого элемента не известна тестеру. Тестирование White Box-это метод тестирования программного обеспечения, в котором тестеру известна внутренняя структура/ дизайн/ реализация тестируемого элемента.

*испытание черного ящика: Если исходный код недоступен, то тестовые данные основаны на функции программного обеспечения независимо от того, как оно было реализовано. -сильная textExamples из черного ящика тестирование: тестирование краевых и разделение эквивалентности.

* "белого ящика" тестирование: Если исходный код тестируемой системы доступен, то тестовые данные основаны на структуре этого исходного кода. - Примеры тестирования белого ящика: тестирование пути и поток данных тестирование.

простой...Тестирование Blackbox иначе известно как интеграционное тестирование или тестирование дымовой завесы . Это в основном применяется в распределенной среде, которая зависит от архитектуры, управляемой событиями. Вы тестируете службу на основе другой службы, чтобы просмотреть все возможные сценарии. Здесь вы не можете полностью прогнозировать все возможные выходные данные, потому что каждый компонент приложения SOA/Enterprise предназначен для автономной работы. Это можно назвать высоким уровнем тестирование

пока

испытание белой коробки ссылается на блок-испытание. где можно эффективно прогнозировать все ожидаемые сценарии и результаты. Я. E ввод и ожидаемый вывод.Это можно назвать низкоуровневым тестированием

Я только частично согласен с лучшим ответом на этот вопрос. Какой тип тестирования, по вашему мнению, должен быть акцентом (для тестировщиков/QAs) и почему?

1. Я согласен с тем, что: "тестирование черного ящика должно быть акцентом на тестеры / QA."
2. Я согласен, что тестирование белого ящика должно быть акцентом на разработчики, но я не согласен с тем, что тестирование White Box - это просто единица тесты.

Я согласен с определением здесь которая гласит этот метод тестирования белого ящика применим к следующим уровням тестирования программного обеспечения:

• модульное тестирование: для тестирования путей в блок
• интеграционное тестирование:для тестирования путей между блоками
• тестирование системы: для тестирования путей между подсистемами

вот мои 5 копеек:

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

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

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

Я думаю, что создание кода развязки (также при тестировании кода) - очень хорошая практика.

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