В компьютерном программировании и тестировании программного обеспечения дымовое тестирование (также тестирование доверия , тестирование работоспособности , [1] тест проверки сборки ( BVT ) [2] [3] [4] и приемочный тест сборки ) является предварительным тестированием или тестированием работоспособности для выявления простых сбоев, достаточно серьезных, чтобы, например, отклонить предполагаемый выпуск программного обеспечения. Дымовые тесты представляют собой подмножество тестовых случаев , которые охватывают наиболее важную функциональность компонента или системы, используемых для оценки того, правильно ли работают основные функции программного обеспечения. [1] [2] При использовании для определения того, следует ли подвергать компьютерную программу дальнейшему, более детальному тестированию, дымовое тестирование может называться предварительным тестом [5] или вступительным тестом . [1] В качестве альтернативы это набор тестов, выполняемых для каждой новой сборки продукта, чтобы убедиться, что сборка тестируема, прежде чем она будет передана в руки тестирующей группы. [6] В парадигме DevOps использование шага теста проверки сборки является одним из отличительных признаков стадии зрелости непрерывной интеграции . [7]
Например, дымовой тест может отвечать на такие базовые вопросы, как «работает ли программа?», «открывается ли пользовательский интерфейс?» или «делает ли что-нибудь нажатие главной кнопки?». Целью дымового тестирования является определение того, настолько ли сильно сломано приложение, что дальнейшее немедленное тестирование становится ненужным. Как говорится в книге Lessons Learned in Software Testing [8] , «дымовые тесты в целом охватывают функции продукта за ограниченное время [...] если ключевые функции не работают или если ключевые ошибки еще не исправлены, ваша команда не будет тратить дополнительное время на установку или тестирование». [3]
Дымовые тесты часто выполняются быстро, что дает преимущества в виде более быстрой обратной связи, по сравнению с запуском более обширных наборов тестов , которые, естественно, занимают больше времени.
Частая реинтеграция с дымовым тестированием входит в число лучших отраслевых практик . [9] [ нужна цитата для проверки ] В идеале каждое подтверждение в репозиторий исходного кода должно запускать сборку непрерывной интеграции, чтобы как можно скорее выявить регрессии. Если сборки занимают слишком много времени, вы можете объединить несколько подтверждений в одну сборку, или очень большие системы могут перестраиваться раз в день. В целом, перестраивайте и повторно тестируйте так часто, как можете.
Тестирование дыма также проводится тестировщиками перед принятием сборки для дальнейшего тестирования. Microsoft утверждает, что после проверки кода « тестирование дыма является наиболее экономически эффективным методом выявления и исправления дефектов в программном обеспечении». [10]
Можно проводить дымовые тесты вручную или с помощью автоматизированного инструмента . В случае автоматизированных инструментов процесс, который генерирует сборку, часто инициирует тестирование. [ необходима цитата ]
Дымовые тесты могут быть функциональными тестами или модульными тестами . Функциональные тесты проверяют полную программу с различными входными данными. Модульные тесты проверяют отдельные функции, подпрограммы или методы объектов. Функциональные тесты могут включать в себя заскриптованную серию входных данных программы, возможно, даже с автоматизированным механизмом управления движениями мыши. Модульные тесты могут быть реализованы либо как отдельные функции внутри самого кода, либо как уровень драйвера, который ссылается на код без изменения тестируемого кода. [ необходима цитата ]
В книге «Уроки тестирования программного обеспечения » Джем Канер, Джеймс Бах и Бретт Петтикорд описали происхождение термина: «Фраза « дымовой тест» происходит от электронного аппаратного тестирования . Вы подключаете новую плату и включаете питание. Если вы видите дым, идущий от платы, выключите питание. Вам не нужно проводить больше никаких тестов». [3]