Тестирование черного или белого ящика - что вы делаете первым?
14
В очень маленькой команде, где тестирование черного ящика и белого ящика выполняется одним и тем же человеком, что тестер должен сделать в первую очередь?
Я думаю, что это зависит от контекста. Вы в основном закончили реализацию спецификаций и хотите начать финальное тестирование или вообще говорите в любое время в течение цикла разработки? Как уже упоминалось в ответах, ваши разработчики, как правило, пишут модульные тесты, которые можно считать частью вашего whtie box-тестирования, поскольку эти кодеры понимают внутреннюю работу и хотят подтвердить функциональность своей реализации перед фиксацией.
Крис
Ответы:
11
Что бы ни было наиболее правильным.
Серьезно, тестирование белого ящика (т.е. тестирование внутренних частей кода) в идеале должно проводиться с помощью модульных тестов разработчиком, написавшим код. Модульные тесты будут создаваться со временем, и это будет частью процесса сборки, поэтому мы не будем тратить время плохого тестировщика на код, который, как мы знаем, работает не так, как должен. Модульное тестирование становится тем важнее, чем меньше ваша команда - особенно потому, что у вас нет армии тестеров, чтобы избавиться от проблем.
Тестирование «черного ящика» (т. Е. Тестирование через интерфейс пользователя / системы) обычно является тем, что делает большинство тестеров.
Все тестирование должно быть приоритетом того, насколько важна функция для готового продукта. Если миссия состоит в том, чтобы предоставить инструмент для выполнения X, а продукт не делает X, это большая проблема.
Хорошо сказано, лучший ответ, который я прочитал до сих пор.
Крис
5
черный
Тестирование черного ящика для проверки возможностей. Тестирование белого ящика при необходимости, если что-то сломано. Если все тесты черного ящика пройдены и покрытие хорошее, тестирование белого ящика не требуется.
Если, конечно, тесты черного ящика не пропустили тестирование ключевой части функциональности или конфигурации:}
Алан
3
@ Алан: тот же аргумент применим к тестированию белого ящика, поэтому предостережение «освещение хорошее»
Стивен А. Лоу
1
Согласовано - я полагаю, мое утверждение зависит от вашего определения хорошего освещения.
Алан
1
@DocBrown Я абсолютно не понимаю, как вы объяснили что-то отдаленно похожее на тестирование белого ящика. Тестирование Whitebox подразумевает следование путям ветвления данной реализации и написание тестовых примеров, которые будут использовать все пути. Если у вас еще нет реализации, то вы по определению не можете делать тесты whitebox. С TDD и BDD вы пишете тесты общей формы, заданной, когда тогда. Вы настраиваете входные данные или предварительное состояние, запускаете устройство и проверяете выходные данные, либо вызываете конечное состояние или вызовы третьих сторон. Это определение тестирования черного ящика.
Сэмми
1
@SamJudge: насколько я понимаю, когда вы заглядываете в код реализации и используете эту информацию для разработки очень специфических тестовых данных (которые затем передаются через открытый интерфейс), то оправданно называть это тестом белого ящика. Такой тест также не проходит, если результат не соответствует ожиданиям. Если вы позже посмотрите только на тест, вы, конечно, не сможете четко сказать, что «этот тест был произведен методом белого ящика (или черного ящика)», конечно.
Док Браун
3
Черный ящик.
Компоненты белого ящика обычно зависят от компонентов черного ящика, поэтому я хотел бы сначала проверить черный ящик, а затем перейти к белому.
Я не уверен, что вы подразумеваете под «компонентами черного ящика» и «компонентами белого ящика» - для меня они просто «компоненты» (которые могут быть протестированы с знанием или без знания базового кода или архитектуры)
Алан
Я не понимаю "зависимых" отношений, которые вы предлагаете здесь. Белый черный и черный ящик не являются компонентами, это скорее стиль тестирования любого компонента, как упоминает Алан. Разница заключается в подходе, принятом для проверки рассматриваемого компонента.
Крис
2
Сначала вы делаете белое тестирование, думая как программист / разработчик, чтобы убедиться, что все будет работать нормально. Затем вы проводите тестирование черного ящика, обычно пытаясь думать, что вы конечный пользователь, не думая о внутренней структуре программы. Иногда вам нужно думать как программист / разработчик, даже если вы проводите черное тестирование, потому что вы можете тестировать внутренний модуль, написанный другим человеком, и у вас нет доступа к коду.
Если вы хотите иметь хороший цикл тестирования, у вас должны быть разные люди, выполняющие оба :
Разработчик, сосредоточенный главным образом на тестировании «белого ящика», знает, что изменилось в коде в последнее время, какие области являются более сложными (и, следовательно, могут сломаться) и т. Д., И может соответствующим образом сосредоточить усилия на этих областях, которые могут привести к появлению новых дефектов.
С другой стороны, тестер QA, ориентированный на тестирование «черного ящика», может легче подходить к тестированию, чем конечный пользователь. Без каких-либо внутренних знаний о коде, они могут принять новый подход и не будут предвзяты из-за знания о том, как реализуются различные части решения. Они будут обнаруживать ошибки, которые разработчик мог упустить из виду, или регрессии от изменений кода, которые случайно нарушили другие области приложения.
Чтобы ответить на ваш вопрос, сначала нужно провести тестирование белого ящика. Но вам действительно нужно, чтобы другой человек проводил тестирование черного ящика, если вы хотите, чтобы он был эффективным.
Мне нравится начинать с тестирования черного ящика, затем использовать информацию о покрытии кода или отладчик, чтобы выяснить, что я делаю, и проанализировать, что происходит.
Но настоящий ответ - это зависит . Я, скорее всего, углублюсь в код раньше (или даже сначала), если буду выполнять тестирование API, но гораздо позже, если моя цель - рассмотреть некоторые крупные сквозные сценарии.
-1, TDD - тестирование белого ящика. В TDD важно знать, что делает код, участвующий в тесте (а что нет), чтобы написать следующий тест. Тестирование черного ящика означает, что тот, кто не имеет представления о коде (тестировщик, кто даже не должен знать, как кодировать), разрабатывает тесты.
Док Браун
1
Тогда мы не практикуем TDD таким же образом. TDD для меня - это обеспечение выполнения спецификаций класса / функции: тесты написаны для проверки того, что класс / функция ведет себя так, как указано, но может не заботиться о том, как код ведет себя за кулисами, пока эти спецификации поддерживаются ... что необходимо, учитывая, что тесты написаны до функциональности.
Матье М.
1
Тестирование черного ящика, потому что вы пишете тесты до того, как код существует. Тестер должен разрабатывать автоматические тесты, требующие много времени, параллельно с написанием кода разработчиком, чтобы быть эффективным в небольшой команде.
Если код уже написан, я бы посоветовал вам потратить некоторое время на наброски тестового покрытия с точки зрения «черного ящика», чтобы убедиться, что у вас есть время для мозгового штурма, прежде чем загромождать мозг реальным кодом. Тем не менее, вы можете переключиться на «белый ящик» и посмотреть на код, прежде чем вы слишком далеко зайдете в реальное тестирование, чтобы почувствовать опасные области и расставить приоритеты для тех тестов, которые вы мозговым штурмом ранее (и дополнить их новыми тестами, придуманными глядя на части кода, которые кажутся сложными или сомнительными).
Ни. Я стараюсь писать хорошие тесты, используя мой Right BICEP , имея в виду ПРАВИЛЬНЫЕ граничные условия, независимо от того, в каком порядке они приходят на ум. Это оба аббревиатуры, предложенные в Прагматическом модульном тестировании .
Моя цель - сосредоточиться на написании хороших тестов, а не на том, какой цвет писать первым.
«Белый» и «черный» не являются терминами модульного тестирования, поэтому, конечно, вы не беспокоитесь об этом. Модульные тесты - это де-факто белая коробка.
Этель Эванс
@ Этель Эванс: Это не тесты белого ящика по определению. Подавляющее большинство юнит-тестов - это тесты белого ящика, но это не обязательно. Любые тесты, которые отображают область входных данных на диапазон выходных данных функции, являются модульными тестами, но не обязательно должны знать детали реализации.
Стивен Эверс
0
Сначала сделайте это тестирование белого ящика .
Второй - тестирование черного ящика.
> Тестирование черного ящика
I. Тестер должен проверить работоспособность приложения, например, текстовое поле, переключатель, список, командную кнопку и т. Д.,
II. Тестер должен проверить не функционал приложения, такой как логотип, изображение, орфография, и т. Д.,
III. Тестер должен проверить весь поток приложения.
Примечание: для проверки положительных и отрицательных условий.
Ответы:
Что бы ни было наиболее правильным.
Серьезно, тестирование белого ящика (т.е. тестирование внутренних частей кода) в идеале должно проводиться с помощью модульных тестов разработчиком, написавшим код. Модульные тесты будут создаваться со временем, и это будет частью процесса сборки, поэтому мы не будем тратить время плохого тестировщика на код, который, как мы знаем, работает не так, как должен. Модульное тестирование становится тем важнее, чем меньше ваша команда - особенно потому, что у вас нет армии тестеров, чтобы избавиться от проблем.
Тестирование «черного ящика» (т. Е. Тестирование через интерфейс пользователя / системы) обычно является тем, что делает большинство тестеров.
Все тестирование должно быть приоритетом того, насколько важна функция для готового продукта. Если миссия состоит в том, чтобы предоставить инструмент для выполнения X, а продукт не делает X, это большая проблема.
источник
черный
Тестирование черного ящика для проверки возможностей. Тестирование белого ящика при необходимости, если что-то сломано. Если все тесты черного ящика пройдены и покрытие хорошее, тестирование белого ящика не требуется.
источник
Черный ящик.
Компоненты белого ящика обычно зависят от компонентов черного ящика, поэтому я хотел бы сначала проверить черный ящик, а затем перейти к белому.
источник
Сначала вы делаете белое тестирование, думая как программист / разработчик, чтобы убедиться, что все будет работать нормально. Затем вы проводите тестирование черного ящика, обычно пытаясь думать, что вы конечный пользователь, не думая о внутренней структуре программы. Иногда вам нужно думать как программист / разработчик, даже если вы проводите черное тестирование, потому что вы можете тестировать внутренний модуль, написанный другим человеком, и у вас нет доступа к коду.
источник
Если вы хотите иметь хороший цикл тестирования, у вас должны быть разные люди, выполняющие оба :
Разработчик, сосредоточенный главным образом на тестировании «белого ящика», знает, что изменилось в коде в последнее время, какие области являются более сложными (и, следовательно, могут сломаться) и т. Д., И может соответствующим образом сосредоточить усилия на этих областях, которые могут привести к появлению новых дефектов.
С другой стороны, тестер QA, ориентированный на тестирование «черного ящика», может легче подходить к тестированию, чем конечный пользователь. Без каких-либо внутренних знаний о коде, они могут принять новый подход и не будут предвзяты из-за знания о том, как реализуются различные части решения. Они будут обнаруживать ошибки, которые разработчик мог упустить из виду, или регрессии от изменений кода, которые случайно нарушили другие области приложения.
Чтобы ответить на ваш вопрос, сначала нужно провести тестирование белого ящика. Но вам действительно нужно, чтобы другой человек проводил тестирование черного ящика, если вы хотите, чтобы он был эффективным.
источник
Мне нравится начинать с тестирования черного ящика, затем использовать информацию о покрытии кода или отладчик, чтобы выяснить, что я делаю, и проанализировать, что происходит.
Но настоящий ответ - это зависит . Я, скорее всего, углублюсь в код раньше (или даже сначала), если буду выполнять тестирование API, но гораздо позже, если моя цель - рассмотреть некоторые крупные сквозные сценарии.
источник
Я бы сказал, сначала « черный ящик» , просто потому, что, как сторонник TDD, тесты пишутся до того, как код (или блок) все равно существует :)
Тестирование белого ящика (насколько я понимаю) более полезно при отладочном мышлении.
источник
Тестирование черного ящика, потому что вы пишете тесты до того, как код существует. Тестер должен разрабатывать автоматические тесты, требующие много времени, параллельно с написанием кода разработчиком, чтобы быть эффективным в небольшой команде.
Если код уже написан, я бы посоветовал вам потратить некоторое время на наброски тестового покрытия с точки зрения «черного ящика», чтобы убедиться, что у вас есть время для мозгового штурма, прежде чем загромождать мозг реальным кодом. Тем не менее, вы можете переключиться на «белый ящик» и посмотреть на код, прежде чем вы слишком далеко зайдете в реальное тестирование, чтобы почувствовать опасные области и расставить приоритеты для тех тестов, которые вы мозговым штурмом ранее (и дополнить их новыми тестами, придуманными глядя на части кода, которые кажутся сложными или сомнительными).
источник
Ни. Я стараюсь писать хорошие тесты, используя мой Right BICEP , имея в виду ПРАВИЛЬНЫЕ граничные условия, независимо от того, в каком порядке они приходят на ум. Это оба аббревиатуры, предложенные в Прагматическом модульном тестировании .
Моя цель - сосредоточиться на написании хороших тестов, а не на том, какой цвет писать первым.
источник
Сначала сделайте это тестирование белого ящика .
Второй - тестирование черного ящика.
> Тестирование черного ящика
I. Тестер должен проверить работоспособность приложения, например, текстовое поле, переключатель, список, командную кнопку и т. Д.,
II. Тестер должен проверить не функционал приложения, такой как логотип, изображение, орфография, и т. Д.,
III. Тестер должен проверить весь поток приложения.
Примечание: для проверки положительных и отрицательных условий.
источник