В чем разница тестирования черного и белого ящика?
Что проверяют
Понимаете ли вы, что различие в доступной информации, а не в инструменте или уровне тестирования. Заодно ждут упоминания серого ящика и техник проектирования проверок.
Как отвечать
Чёрный ящик это проверка поведения по требованиям, без знания устройства кода: есть вход, есть ожидаемый результат. Белый ящик это проверки, построенные на знании внутренней реализации: ветвлений, условий, обработки ошибок, запросов к базе.
Что даёт каждый подход:
- чёрный ящик: смотрит на систему глазами пользователя, ловит расхождение с требованиями, не привязан к реализации, поэтому тесты переживают рефакторинг. Слабое место в том, что редкие внутренние пути остаются непокрытыми, а тестировщик не знает, где именно риск;
- белый ящик: позволяет целенаправленно покрыть ветки, крайние условия и обработку ошибок, измерить покрытие. Слабое место в том, что тесты знают о реализации и ломаются при её изменении, а расхождение с требованиями так не найти вовсе;
- серый ящик: частичное знание устройства (схема базы, контракты сервисов, логи), и на практике тестировщик работает именно так.
Полезно назвать техники проектирования проверок для чёрного ящика: классы эквивалентности, граничные значения, таблицы решений, попарное тестирование, диаграммы переходов состояний. Для белого: покрытие операторов, ветвей, условий.
И связать с уровнями: модульные тесты обычно белый ящик, тесты API и интерфейса чёрный, но жёсткой привязки нет.
Где спотыкаются
Ставят знак равенства между белым ящиком и модульными тестами, а чёрным ящиком и ручной проверкой.
Гонятся за процентом покрытия как за целью: сто процентов строк не означает, что проверены нужные сценарии.
Не используют техники проектирования и пишут проверки наугад, из-за чего пропускают граничные значения.