Тестирование методом "черного ящика" или тестирование методом "белого ящика" должны быть акцентом для тестеров?

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

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

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

Это - что-то вроде открытой двери, но в конце оба об одинаково важном.

, Что хуже?

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

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

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

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

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

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

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

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

Так, для ответа на исходный вопрос - и bb и wb важны для хорошего тестирования.

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

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

Оба тестовых подхода одинаково важны , по-моему.

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

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

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

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

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

Черный ящик

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

2 Используются следующие техники:

- Разбиение на эквивалентности

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

- Угадывание ошибок

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

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

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

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

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

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

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

Белый ящик

Используются следующие техники:

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

- Нотация графа потока

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

1. Тестирование условий

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

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

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

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

3. Конкатенированные циклы

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

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

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