Тестирование черного ящика против белого ящика
Какой тип тестирования вы бы назвали акцентом (для тестировщиков /QAs) и почему?
Быстрый набор определений из википедии:
Тестирование черного ящика
- берет внешнюю перспективу тестового объекта для получения тестовых случаев. Эти тесты могут быть функциональными или нефункциональными, хотя обычно они функциональные. Разработчик теста выбирает допустимый и недействительный ввод и определяет правильный вывод. Нет сведений о внутренней структуре тестового объекта.
Тестирование белого ящика
- использует внутреннюю перспективу системы для разработки контрольных примеров на основе внутренней структуры. Это требует навыков программирования, чтобы определить все пути через программное обеспечение. Тестировщик выбирает входные данные тестового примера для прохождения пути через код и определяет соответствующие выходные данные. При тестировании электрического оборудования каждый узел в цепи может быть проверен и измерен; Примером является внутрисхемное тестирование (ИКТ).
редактировать: просто чтобы прояснить немного, я понимаю, что оба важны, но обычно они различаются между dev и QA.
Важны ли внутренние знания для тестера /QA? Я слышал аргументы о том, что тестирование с учетом этих знаний позволяет им лучше тестировать проблемы, но я также слышал аргументы о том, что эти знания могут отвлекать внимание от функциональных потребностей и стимулировать "тестирование к коду", а не к намеченному решению.,
16 ответов
- Тестирование черного ящика должно быть в центре внимания тестировщиков /QA.
- Тестирование белого ящика должно быть в центре внимания разработчиков (то есть модульных тестов).
- Другие люди, которые ответили на этот вопрос, казалось, интерпретировали вопрос как Что важнее, тестирование белого ящика или тестирование черного ящика. Я тоже считаю, что они оба важны, но вы можете проверить эту статью IEEE, в которой утверждается, что тестирование белого ящика является более важным.
White Box Testing - это программный модульный тест. Разработчик или тестировщик уровня разработки (например, другой разработчик) гарантирует, что написанный им код работает должным образом в соответствии с подробными требованиями уровня, прежде чем интегрировать его в систему.
Тестирование черного ящика - это тестирование интеграции. Тестер гарантирует, что система работает в соответствии с требованиями на функциональном уровне.
Оба теста одинаково важны на мой взгляд.
Тщательное модульное тестирование выявит дефекты на стадии разработки, а не после того, как программное обеспечение будет интегрировано в систему. Тест черного ящика на системном уровне обеспечит правильную работу всех программных модулей при их объединении. Модульное тестирование на стадии разработки не выявит этих дефектов, поскольку модули обычно разрабатываются независимо друг от друга.
Черный ящик
1 Ориентирован на функциональность системы. Ориентирован на структуру (Программу) системы.
Используются 2 метода:
· Эквивалентное разбиение
· Граничный анализ
· Ошибка угадывания
· Гоночные условия
· Причинно-следственная графика
· Синтаксическое тестирование
· Тестирование состояния перехода
· Графическая матрица
Тестер может быть не техническим
Помогает выявить неопределенность и противоречие в функциональных характеристиках
Белая коробка
Используемые методы:
· Базовое тестирование пути
· Блок-схема
· Проверка структуры управления
Тестирование состояния
Тестирование потока данных
· Loop Testing
Простые петли
Вложенные циклы
Каскадные петли
Неструктурированные Петли
Тестер должен быть техническим
Помогает выявить проблемы логики и кодирования.
QA должен сосредоточиться на тестировании черного ящика. Основная цель QA - проверить, что делает система (отвечают ли функции требованиям?), А не как она это делает.
В любом случае, для QA должно быть сложно проводить тестирование белого ящика, так как большинство QA-парней не являются техническими специалистами, поэтому они обычно тестируют функции через пользовательский интерфейс (например, пользователи).
Шаг вперед, я думаю, что разработчики тоже должны сосредоточиться на тестировании черного ящика. Я не согласен с этой широко распространенной ассоциацией между модульным тестированием и тестированием белого ящика, но это может быть просто вопрос лексики / шкалы. По шкале модульного теста тестируемая система - это класс / метод, который имеет контракт (через свою подпись), и важным моментом является проверка того, что он делает, а не как. Более того, тестирование белого ящика подразумевает, что вы знаете, как метод выполнит свой контракт, что мне кажется несовместимым с TDD.
ИМХО, если ваша SUT настолько сложна, что вам нужно провести тестирование белого ящика, обычно наступает время для рефакторинга.
"Оба" было сказано выше, и это очевидный ответ... но IMO, тестирование белого ящика выходит далеко за рамки модульного тестирования разработчика (хотя я полагаю, что это может зависеть от того, где вы проведете черту между белым и черным). Например, анализ покрытия кода является распространенным подходом белого ящика - то есть, запустите некоторые сценарии или тесты и изучите результаты в поисках пробелов в тестировании. Даже если модульные тесты имеют 100% куб. См., Измерение куб. См в обычных пользовательских сценариях может выявить код, который может потребовать еще большего тестирования.
Еще одним местом, где помогает тестирование белого ящика, является проверка типов данных, констант и другой информации для поиска границ, специальных значений и т. Д. Например, если приложение имеет ввод, который принимает числовой ввод, подход, основанный только на bb, может потребовать от тестера "угадайте", какие значения были бы хороши для тестирования, тогда как подход wb может показать, что все значения между 1-256 обрабатываются одним способом, в то время как большие значения обрабатываются другим способом... и, возможно, число 42 имеет еще один путь кода,
Итак, чтобы ответить на оригинальный вопрос - и bb, и wb необходимы для хорошего тестирования.
По моему опыту, большинство разработчиков естественно переходят на тестирование белого ящика. Поскольку нам необходимо убедиться, что основной алгоритм является "правильным", мы склонны уделять больше внимания внутренним элементам. Но, как уже отмечалось, важно тестирование как белого, так и черного ящиков.
Поэтому я предпочитаю, чтобы тестеры уделяли больше внимания тестам "черного ящика", чтобы скрыть тот факт, что большинство разработчиков на самом деле этого не делают и зачастую не очень хорошо это делают.
Это не значит, что тестеры должны быть в курсе того, как работает система, просто я предпочитаю, чтобы они больше фокусировались на проблемной области и на том, как реальные пользователи взаимодействуют с системой, а не на функции SomeMethod(int x) правильно сгенерирует исключение, если x равен 5.
Обычно тестирование белого ящика не возможно для тестировщиков. Таким образом, единственный жизнеспособный ответ для тестировщиков - это подчеркнуть подход "черного ящика".
Однако при использовании методологии аспектно-ориентированного программирования и проектирования по контракту, когда цели тестирования программируются в целевой код как контракты (если смотреть со статического представления программы) и / или когда временная логика тестирования программируется в код как перекрестные сечения (динамическое представление логики теста), тестирование белого ящика станет не только возможным, но и предпочтительным вариантом для тестировщиков. С учетом сказанного, это будет требовать экспертизы, тестеры должны быть не только хорошими тестерами, но также хорошими программистами или не просто хорошими программистами.
Тестирование черного ящика: Тестирование черного ящика - это просто наблюдение, не требующее внутренних знаний или структуры программного продукта. просто ввод действительного и неверного ввода данных и ожидание правильного результата. здесь тестер находит дефект, но не может найти местоположение дефекта. Тестирование черного ящика выполняется на всех уровнях тестирования.
Методы тестирования черного ящика: 1. Эквивалентный раздел 2. Анализ граничных значений 3. Таблица решений 4. Диаграмма переходов между состояниями 4. Диаграмма прецедентов
Тестирование белого ящика: Тестирование белого ящика требует знания внутренней логики и структуры программного продукта. здесь мы проверим цикл, условие и ответвление. Здесь мы находим не только дефект, но также и местоположение дефекта.
Методы тестирования белого ящика: 1. Покрытие заявления 2. Покрытие решения 3. Покрытие филиала 4. Покрытие пути.
Это немного открытая дверь, но, в конце концов, оба одинаково важны.
Это хуже?
программное обеспечение, которое делает то, что ему нужно, но внутренне имеет проблемы?
программное обеспечение, которое должно работать, если вы посмотрите на источники, но не работает?
Мой ответ: ни то, ни другое не является приемлемым, но нельзя доказать, что программное обеспечение не содержит ошибок на 100%. Таким образом, вам придется сделать некоторые компромиссы. Второй вариант более заметен для клиентов, поэтому у вас возникнут проблемы с этим раньше. В конечном счете, первый вариант будет проблематичным.
Black Box Testing - это метод тестирования программного обеспечения, при котором внутренняя структура / дизайн / реализация тестируемого элемента НЕ известны тестировщику. White Box Testing - это метод тестирования программного обеспечения, при котором внутренняя структура / дизайн / реализация тестируемого элемента известны тестировщику.
- * Тестирование черного ящика: это тестирование на системном уровне для проверки функциональности системы, чтобы убедиться, что система выполняет все функции, для которых она была разработана, главным образом для выявления дефектов, обнаруженных в точке пользователя. Лучше нанять профессионального тестировщика для "черного ящика" вашей системы, потому что разработчик обычно тестирует с точки зрения того, что написанные им коды хороши и соответствуют функциональным требованиям клиентов, поэтому он может пропустить много вещей (я не понимаю не хочу никого обидеть)
- Whitebox - это первый тест, выполненный в SDLC. Он предназначен для выявления ошибок, таких как ошибки времени выполнения и ошибки компиляции. Это может быть сделано либо тестировщиками, либо самим разработчиком, но я думаю, что всегда лучше, если человек, написавший код, тестирует его. Он понимает их больше, чем другой человек.*
Что составляет "внутреннее знание"? Правильно ли знать, что такой-то алгоритм использовался для решения проблемы, или тестировщик должен видеть каждую строку кода, чтобы она была "внутренней"?
Я думаю, что в любом тестовом случае должны быть ожидаемые результаты, предоставляемые используемой спецификацией, а не определяемые тем, как тестер решает интерпретировать спецификацию, поскольку это может привести к проблемам, когда каждый думает, что они правы, и обвиняет другого в проблеме.
Вот мои 5 центов:
Как разработчик, я в основном пишу тесты для методов (в классе) в виде тестов белого ящика, просто потому, что я не хочу, чтобы мой тест ломался только потому, что я изменял внутреннюю работу своего кода.
Я хочу, чтобы мои тесты ломались, если поведение моего метода меняется (например, возвращает результат, отличный от предыдущего).
За последние 20 лет разработки я просто устал выполнять двойную работу только потому, что мои модульные тесты были сильно привязаны к коду, и мне нужно поддерживать как код приложения, так и тестовый код.
Я думаю, что создание разъединяющего кода (также когда вы тестируете код) - очень хорошая практика.
Еще 5 центов: я почти никогда не использую фальшивые фреймворки, потому что, когда я нахожу, что имитировать что-то обязательно, я вместо этого предпочитаю отделить свой код - и да, во многих случаях это очень возможно (особенно, если вы не работаете с унаследованным кодом):)
- Тестируя черный ящик, вы не видите внутреннюю работу тестируемой системы.
- Тестирование белого ящика - у вас есть полный обзор тестируемой системы. Вот несколько изображений, показывающих это.
Тестировщикам необходимо сосредоточиться на пирамиде тестирования. Вы захотите понять модульные тесты, интеграционные тесты и сквозные тесты. Каждый из них может быть выполнен как с использованием "черного ящика", так и "белого ящика". Начните с малого и постепенно изучите различные типы и когда их использовать. помните, вы не всегда можете все проверить.
Я только частично согласен с самым рейтинговым ответом на этот вопрос. Какой тип тестирования вы бы назвали акцентом (для тестировщиков /QAs) и почему?
- Я согласен с тем, что "тестирование черного ящика должно быть в центре внимания тестировщиков / QA".
- Я согласен с тем, что тестирование Белого ящика должно быть основным упором для разработчиков, но я не согласен с тем, что тестирование Белого ящика - это просто юнит-тесты
Я согласен с определением, которое здесь гласит, что метод тестирования White Box применим к следующим уровням тестирования программного обеспечения:
- Модульное тестирование: для тестирования путей внутри блока
- Интеграционное тестирование: для тестирования путей между устройствами
- Системное тестирование: для тестирования путей между подсистемами
Простое... Тестирование Blackbox иначе называют интеграционным тестированием или тестированием дымовой завесы. Это в основном применяется в распределенной среде, которая опирается на управляемую событиями архитектуру. Вы тестируете сервис на основе другого сервиса, чтобы увидеть все возможные сценарии. Здесь вы не можете полностью спрогнозировать все возможные результаты, потому что каждый компонент приложения SOA/Enterprise должен функционировать автономно. Это можно назвать тестированием высокого уровня
в то время как
Тестирование белого ящика относится к юнит-тестированию. где все ожидаемые сценарии и результаты могут быть эффективно спрогнозированы. т. е. вход и ожидаемый результат. Это можно назвать тестированием низкого уровня
* Тестирование в "черном ящике": если исходный код недоступен, тогда данные тестирования основаны на функциях программного обеспечения, независимо от того, как оно было реализовано. -strong text Примеры тестирования черного ящика: тестирование граничных значений и разбиение эквивалентности.
* Тестирование белого ящика. Если доступен исходный код тестируемой системы, то данные теста основаны на структуре этого исходного кода. -Примеры тестирования белого ящика: тестирование пути и тестирование потока данных.