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

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

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

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

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

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

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