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

Question

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

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

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

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

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

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

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

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

Answer 1

Вот мои 5 центов:

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

• Юнит-тестирование: для тестирования путей внутри юнита
• Интеграционное тестирование: для тестирования путей между блоками
• Системное тестирование: для тестирования путей между подсистемами

Answer 5

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

, а

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

Answer 6

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

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