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

Question

Какой тип тестирования вы бы назвали акцентом (для тестировщиков / QAs) и почему?

Быстрый набор определений из википедии:

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

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

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

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

edit: просто чтобы прояснить немного, я понимаю, что оба важны, но обычно они различаются между dev и QA.

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

Answer 1

• Тестирование черного ящика должно быть в центре внимания тестировщиков / QA.
• Тестирование белого ящика должно быть в центре внимания разработчиков (то есть модульных тестов).
• Другие люди, которые ответили на этот вопрос, казалось, интерпретировали вопрос как Что более важно, тестирование белого ящика или тестирование черного ящика . Я тоже считаю, что они оба важны, но вы можете проверить эту статью IEEE , в которой утверждается, что тестирование белого ящика является более важным.

Answer 2

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

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

Оба метода испытаний одинаково важны по моему мнению.

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

Answer 3

Черный ящик

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

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

· Эквивалентное разбиение

· Граничный анализ

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

· Расовые условия

· Причинно-следственный график

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

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

· Графическая матрица

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

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

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

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

· Базовое тестирование пути

· Блок-схема

· Проверка структуры управления

1. Проверка состояния

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

· Loop Testing

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

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

3. каскадные петли

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

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

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

Answer 4

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

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

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

ИМХО, если ваша SUT настолько сложна, что вам нужно провести тестирование белого ящика, обычно наступает время для рефакторинга.

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

Методы тестирования черного ящика: 1. Эквивалентный раздел 2. Граничный анализ стоимости 3. Таблица решений 4. Государственная диаграмма перехода 4. Диаграмма прецедентов

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

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

Answer 10

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

Что хуже?

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

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

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