1

Прежде чем перейти к ответу, давайте определим, что я имею в виду (обратите внимание, что вы можете иметь различные определения, и это часть проблемы, , но это то, что я использую)С макетным тестированием, являются ли единичные тесты + системные тесты?

издеваться тестирование aka тестирование на основе поведения --- проверяет код на правильную вещь, т.е. тесты проверяют поведение. Все соратники издеваются.

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

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

системные тесты --- проверьте систему как «черный ящик», то есть с точки зрения пользователя, который не имеет доступа к внутренним устройствам системы. Реальные компоненты используются (база данных, http и т. Д.)

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

  • Поведение на основе модульных тестов следует убедиться, что компоненты разговаривать друг с другом правильно
  • системные тесты должны поймать ошибок с использованием реальных компонентов

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

Что мне не хватает?

Обновление: «Достаточно», я имею в виду, что эти модульные тесты + системные тесты поймают все ошибки, обнаруженные в модуле + интеграция + системные тесты.

Обновление: «Достаточно», я имею в виду, есть ошибки, которые в блоке + интеграция + системные тесты обнаружат, что системные тесты не будут найдены? То, что я действительно ищу, - это пример, который показывает интеграционные тесты.

+3

Нет такой вещи, как «достаточно». Вы проверяете столько, сколько можете дать выделенное время. Тесты интеграции часто полезны в качестве замены людей, нажимая кнопки. Или в местах, где побочные эффекты или предпосылки реализации могут вызвать проблемы при изменении кода. – Will

+0

Я удивлен количеством людей, слепо ударяющих вверх по комментарию. «Люди, нажимающие кнопки» - это то, что я называю системным тестом, но, по-видимому, никто не удосужился прочитать вопрос. То же «побочные эффекты реализации» будут застигнуты системными тестами (но тесты интеграции скажут вам, где это). –

+0

Они, вероятно, отвечают с первого комментария. Что касается определений, они, по-видимому, различаются. Что касается вашего ожидания от того, какие тесты могут быть выполнены. Они не магические сети, тянущие во всех возможных ошибках. Мне жаль, что они ... – Will

ответ

0

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

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

Так что это зависит от вашего определения «необходимости». Наложение между различными категориями тестов не может повредить и может обеспечить ценность, если они помогут вам быстрее обнаружить ошибки. Это зависит от величины значения, которое я предполагаю (каков ROI для обоих).

0

Здесь можно ответить. (Я честно считаю, что это сложный вопрос с реальным ответом «это зависит»). Ответ в соответствии с этим видео является то, что интеграционные тесты не нужны (ну, вроде ... название вводит в заблуждение):

«JB Rainsberger - Комплексные тесты афера»

http://vimeo.com/80533536

Смысл этого ответа заключается в том, что

  • изолированных модульных тестов (модульное тестирование, где находятся сотрудники высмеивают) должны быть действительно сотрудничество/контрактные тесты.
  • в части проверки совместной работы, вы 1) проверяете ожидания, 2) проверяете, правильно ли компонент отвечает ответам соавторов.

Ex: тестируемый объект является адресной книгой, которая использует специальный объект адрес сбора для хранения списка адреса. (Хорошо, это действительно глупый пример.) В 1) вам нужно убедиться, что адресная книга вызывает коллекцию, когда ее предполагают (ожидания). В 2) вам нужно проверить, работает ли адресная книга в разных состояниях коллекции --- нет адресов, 1 адрес, некоторые адреса, многие адреса и т. Д. (На практике вы, вероятно, ограничили бы их деловые случаи использования.) является государственным тестом, обычно использующим заглушку для соавтора.

  • в контрактно-испытательной части, добавить тесты для каждого теста для совместной работы. Объект, находящийся под тестированием, теперь является объектом сбора адресов. Для 1), ожидания, может ли он ответить на вопросы? Для 2), обработка ответов, может ли он правильно ответить?

  • У каждого объекта есть тесты для совместной работы. Каждый сотрудник имеет соответствующие тесты на контракт, а также собственный набор тестов для совместной работы. Это формирует «кольцевую модель» архитектуры. «Внешний слой» ведет переговоры с внешними службами (база данных, http и т. Д.). Для этого вы используете интеграционные тесты.

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

Помимо этого, этот метод тестирования совместной работы/контракта может иметь собственный набор проблем. Соответствующие тесты объединяются --- изменение в одном требует изменения в другом. Использование заглушки может привести к ложным срабатываниям. Интуитивно кажется, что этот тип тестирования имеет нетривиальные затраты на обслуживание.

0

Прежде всего, я не вижу разницы между тем, что вы описали как модульные тесты и макет-тесты.

Как пояснил @danludwig, это зависит от вашей ROI. если вы пишете короткий скрипт для загрузки всех фильмов из плейлиста youtube, то вам, вероятно, вообще не нужны какие-либо тесты. когда вы делаете всемирный магазин для навязчивых покупок системы управления самолетами, то, что вы упомянули, определенно недостаточно (тесты на деградацию, тесты на отказ и, вероятно, многие другие).

из моего опыта в статистическом веб-приложении, если у вас много модульных тестов, вам не нужно много интеграционных тестов. иногда вы будете предвидеть потенциальные проблемы с интеграцией, и вы пишете требуемые тесты, а иногда ваши тестеры найдут проблемы в UAT, а затем вы добавите требуемые тесты. но все же число интеграционных тестов будет намного меньше, чем единичные тесты

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

вещь, чтобы помнить:

  • важной частью тестирования черного ящика также тестирование
  • проникновения и помнить о тестах производительности
Смежные вопросы