stringtranslate.com

Дымовое тестирование (программное обеспечение)

В компьютерном программировании и тестировании программного обеспечения дымовое тестирование (также тестирование доверия , тестирование работоспособности , [1] тест проверки сборки ( BVT ) [2] [3] [4] и приемочный тест сборки ) является предварительным тестированием или тестированием работоспособности для выявления простых сбоев, достаточно серьезных, чтобы, например, отклонить предполагаемый выпуск программного обеспечения. Дымовые тесты представляют собой подмножество тестовых случаев , которые охватывают наиболее важную функциональность компонента или системы, используемых для оценки того, правильно ли работают основные функции программного обеспечения. [1] [2] При использовании для определения того, следует ли подвергать компьютерную программу дальнейшему, более детальному тестированию, дымовое тестирование может называться предварительным тестом [5] или вступительным тестом . [1] В качестве альтернативы это набор тестов, выполняемых для каждой новой сборки продукта, чтобы убедиться, что сборка тестируема, прежде чем она будет передана в руки тестирующей группы. [6] В парадигме DevOps использование шага теста проверки сборки является одним из отличительных признаков стадии зрелости непрерывной интеграции . [7]

Например, дымовой тест может отвечать на такие базовые вопросы, как «работает ли программа?», «открывается ли пользовательский интерфейс?» или «делает ли что-нибудь нажатие главной кнопки?». Целью дымового тестирования является определение того, настолько ли сильно сломано приложение, что дальнейшее немедленное тестирование становится ненужным. Как говорится в книге Lessons Learned in Software Testing [8] , «дымовые тесты в целом охватывают функции продукта за ограниченное время [...] если ключевые функции не работают или если ключевые ошибки еще не исправлены, ваша команда не будет тратить дополнительное время на установку или тестирование». [3]

Дымовые тесты часто выполняются быстро, что дает преимущества в виде более быстрой обратной связи, по сравнению с запуском более обширных наборов тестов , которые, естественно, занимают больше времени.

Частая реинтеграция с дымовым тестированием входит в число лучших отраслевых практик . [9] [ нужна цитата для проверки ] В идеале каждое подтверждение в репозиторий исходного кода должно запускать сборку непрерывной интеграции, чтобы как можно скорее выявить регрессии. Если сборки занимают слишком много времени, вы можете объединить несколько подтверждений в одну сборку, или очень большие системы могут перестраиваться раз в день. В целом, перестраивайте и повторно тестируйте так часто, как можете.

Тестирование дыма также проводится тестировщиками перед принятием сборки для дальнейшего тестирования. Microsoft утверждает, что после проверки кода « тестирование дыма является наиболее экономически эффективным методом выявления и исправления дефектов в программном обеспечении». [10]

Можно проводить дымовые тесты вручную или с помощью автоматизированного инструмента . В случае автоматизированных инструментов процесс, который генерирует сборку, часто инициирует тестирование. [ необходима цитата ]

Дымовые тесты могут быть функциональными тестами или модульными тестами . Функциональные тесты проверяют полную программу с различными входными данными. Модульные тесты проверяют отдельные функции, подпрограммы или методы объектов. Функциональные тесты могут включать в себя заскриптованную серию входных данных программы, возможно, даже с автоматизированным механизмом управления движениями мыши. Модульные тесты могут быть реализованы либо как отдельные функции внутри самого кода, либо как уровень драйвера, который ссылается на код без изменения тестируемого кода. [ необходима цитата ]

Этимология

В книге «Уроки тестирования программного обеспечения » Джем Канер, Джеймс Бах и Бретт Петтикорд описали происхождение термина: «Фраза « дымовой тест» происходит от электронного аппаратного тестирования . Вы подключаете новую плату и включаете питание. Если вы видите дым, идущий от платы, выключите питание. Вам не нужно проводить больше никаких тестов». [3]

Смотрите также

Ссылки

  1. ^ abc Глоссарий ISTQB® для схемы квалификации тестирования программного обеспечения Международного совета по квалификации тестирования программного обеспечения®, Глоссарий ISTQB Международного совета по квалификации тестирования программного обеспечения.
  2. ^ ab Дастин, Рашка, Пол. «Автоматизированное тестирование программного обеспечения — введение, управление и производительность». Addison-Wesley 1999, стр. 43-44. ISBN  0-201-43287-0 .
  3. ^ abc Kaner, Cem; Bach, James; Pettichord, Bret (2002). Уроки, извлеченные из тестирования программного обеспечения . Wiley Computer Publishing . стр. 95. ISBN 0-471-08112-4.
  4. ^ "Как: настроить и запустить тесты проверки сборки (BVT)". Библиотека MSDN для Visual Studio 2005. Получено 20.11.2010 .
  5. ^ 2013-03-20 ISTQB Terminologi for test av programvare, version 2.2 Glossary Working Party, International Software Testing Qualifications Board, Erik van Veenendaal (engelsk), Ernst von Düring (norsk) "входной тест: особый случай дымового теста для определения готовности компонента или системы к подробному и дальнейшему тестированию. Входной тест обычно проводится в начале фазы выполнения теста. См. также дымовой тест".
  6. ^ Сэмюэл Менакер; Шиталь Гуттиголи (14 декабря 2014 г.). Управление разработкой программного обеспечения. Сэмюэл Менакер, Шиталь Гуттиголи. п. 40. GGKEY:JH61NP21TXJ.
  7. ^ PowerShell Magazine, DevOps, инфраструктура как код и PowerShell DSC: Введение, Равикант С., 5 января 2016 г.
  8. ^ Джем Канер, Джеймс Бах, Брет Петтикорд, Уроки, извлеченные из тестирования программного обеспечения: контекстно-ориентированный подход . Wiley, 2001
  9. ^ Макконнелл, Стив. «Быстрое развитие». Microsoft Press, стр. 405
  10. ^ "Guidelines for Smoke Testing". Библиотека MSDN для Visual Studio 2005. 26 июня 2007. Получено 2010-11-20 .

Внешние ссылки