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

Question

Какому типу тестирования, по вашему мнению, следует уделить особое внимание (для тестировщиков/контролеров качества) и почему?

Краткий набор определений из Википедии:

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

Черный ящик

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

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

· Разделение эквивалентности

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

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

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

· График причинно-следственных связей

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

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

· Матрица графика

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

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

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

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

· Тестирование базового пути

· Обозначение графа потока

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

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

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

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

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

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

3. Объединенные циклы

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

Что хуже?

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

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

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

Answer 8

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

Методы тестирования «черного ящика»:1.Раздел эквивалента 2.Анализ граничного значения 3.Решение таблица 4.Схема перехода состояния 4.Диаграмма вариантов использования

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

Методы тестирования белого ящика:1.Заявление покрытие 2.Покрытие решения 3.Покрытие филиала 4.Покрытие пути.

Answer 9

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

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

Answer 10

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

Answer 11

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

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

Answer 12

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

Answer 13

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

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

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

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

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

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

Answer 14

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

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

Answer 15

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

пока

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

Answer 16

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

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

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

• Модульное тестирование:Для тестирования путей внутри модуля
• Интеграционное тестирование: для тестирования путей между модулями.
• Тестирование системы:Для тестирования путей между подсистемами