Почему тесты на дым полезны при непрерывной интеграции?

Question

Обычно мы проводим тесты дыма, чтобы проверять важные функции, когда мы получаем новую сборку. После выполнения тестов на дым мы обязательно перейдем к следующему этапу (следующий уровень тестирования). Я слышал от своих коллег, что тесты на дым действительно полезны, когда ваша команда использует Continuous Integration и DevOps. Тесты на дым всегда полезны, но как это будет более выгодно с комбинацией CI и DevOps?

Answer 1

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

Answer 2

Обычно я слышал, что тестирование на дым обычно используется для проверки на ручное тестирование, которое вы выполняете для проверки работоспособности. This article определяет тестирование дыма следующим образом:

Дым тестирования, также известный как «Build проверочное испытание», тип тестирования программного обеспечения, который включает в себя неисчерпывающим набор тестов , которые направлены на то, чтобы наиболее работают важные функции. Результаты этого тестирования используются для определения того, достаточно ли построена конструкция для продолжения дальнейших испытаний.

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

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

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