WikiDer > Регрессионное тестирование - Википедия

Regression testing - Wikipedia
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Фон

По мере того, как программное обеспечение обновляется, изменяется или повторно используется на модифицированной цели, появление новых ошибок и / или повторное появление старых ошибок является довольно частым явлением. Иногда повторное появление происходит из-за того, что исправление теряется из-за плохого контроль версий практики (или простые человеческая ошибка в ревизионном управлении). Часто решение проблемы будет "хрупкий"в том смысле, что он устраняет проблему в узком случае, когда она была впервые обнаружена, но не в более общих случаях, которые могут возникнуть в течение срока службы программного обеспечения. Часто исправление проблемы в одной области непреднамеренно вызывает программная ошибка в другом районе. Наконец, может случиться так, что при переработке какой-либо функции некоторые из тех же ошибок, которые были сделаны в исходной реализации функции, будут сделаны при изменении дизайна.

Поэтому в большинстве ситуаций разработки программного обеспечения считается хорошая практика кодирования, когда ошибка обнаружена и исправлена, чтобы записать тест, который выявляет ошибку, и регулярно повторно запускать этот тест после последующих изменений в программе.[5] Хотя это можно сделать через ручное тестирование процедуры с использованием методов программирования, это часто делается с использованием автоматизированное тестирование инструменты.[6] Такой тестирование содержит программные инструменты, которые позволяют тестовой среде выполнять всю регрессию контрольные примеры автоматически; некоторые проекты даже настраивают автоматизированные системы для повторного запуска всех регрессионных тестов через определенные промежутки времени и сообщения о любых сбоях (которые могут означать регрессию или устаревший тест).[7] Обычная стратегия - запускать такую ​​систему после каждой успешной компиляции (для небольших проектов), каждую ночь или раз в неделю. Эти стратегии можно автоматизировать с помощью внешнего инструмента.

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

В корпоративном мире регрессионное тестирование традиционно проводилось Гарантия качества программного обеспечения команда после того, как команда разработчиков завершила работу. Однако устранение дефектов, обнаруженных на этом этапе, является наиболее дорогостоящим. Эта проблема решается ростом модульное тестирование. Хотя разработчики всегда писали тестовые примеры как часть цикла разработки, эти тестовые примеры обычно были либо функциональные тесты или же модульные тесты которые подтверждают только предполагаемые результаты. Тестирование разработчика заставляет разработчика сосредоточиться на модульном тестировании и включать как положительные, так и отрицательные тестовые примеры.[8]

Методы

К различным методам регрессионного тестирования относятся:

Проверить все еще раз

Этот метод проверяет все тестовые примеры текущей программы, чтобы проверить ее целостность. Хотя это дорого, так как необходимо повторно запускать все случаи, он гарантирует отсутствие ошибок из-за измененного кода.[9]

Выбор регрессионного теста

В отличие от Retest all, этот метод запускает часть тестирование (из-за стоимости повторного тестирования всего), если стоимость выбора части набора тестов меньше, чем стоимость метода повторного тестирования всего.[9]

Приоритезация тестовых случаев

Расставьте приоритеты для тестовых случаев, чтобы повысить скорость обнаружения ошибок набором тестов. Методы приоритезации тестовых примеров планируют тестовые примеры так, чтобы тестовые примеры с более высоким приоритетом выполнялись перед тестовыми наборами с более низким приоритетом.[9]

Типы приоритезации тестовых случаев

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

Гибридный

Этот метод представляет собой гибрид выбора регрессионного теста и приоритезации тестовых примеров.[9]

Преимущества и недостатки

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

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

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

Использует

Регрессионное тестирование можно использовать не только для тестирования правильность программы, но часто также для отслеживания качества ее вывода.[11] Например, в дизайне компиляторрегрессионное тестирование может отслеживать размер кода и время, необходимое для компиляции и выполнения сценариев набора тестов.

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

— Фред Брукс, Месяц мифического человека, п. 122

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

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

Рекомендации

  1. ^ Пеззе, Мауро; Янг, Михал (2008). Тестирование и анализ программного обеспечения: процесс, принципы и методы. Вайли. Действия по тестированию, направленные на решение проблем регрессии, называются (не) регрессионным тестированием. Обычно "не" опускается
  2. ^ Басу, Анирбан (2015). Обеспечение качества программного обеспечения, тестирование и показатели. PHI Learning. ISBN 978-81-203-5068-7.
  3. ^ Национальный исследовательский совет Комитет по устареванию авионики в военных самолетах: Старение авионики в военных самолетах. The National Academies Press, 2001, стр. 2: «Каждый цикл обновления технологий требует регрессионного тестирования».
  4. ^ Буланже, Жан-Луи (2015). Стандарты CENELEC 50128 и IEC 62279. Вайли. ISBN 978-1119122487.
  5. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: передовой опыт управления программным обеспечением. Пресса компьютерного общества Wiley-IEEE. п. 73. ISBN 978-0-470-04212-0.
  6. ^ Автоматизируйте регрессионные тесты, когда это возможно, Автоматическое тестирование: избранные передовые методы, Эльфриде Дастин, Интернет-книги по Safari
  7. ^ даВейга, Нада (06.02.2008). «Меняйте код без страха: используйте сеть защиты от регресса». Журнал доктора Добба.
  8. ^ Дадни, Билл (2004-12-08). «Тестирование разработчиков уже в ходу: интервью с Альберто Савойей и Кентом Беком». Получено 2007-11-29.
  9. ^ а б c d Дуггал, Гаурав; Сури, Бхарти (29 марта 2008 г.). Понимание методов регрессионного тестирования. Национальная конференция по вызовам и возможностям. Манди Гобиндгарх, Пенджаб, Индия. CiteSeerX 10.1.1.460.5875.
  10. ^ а б c Yoo, S .; Харман, М. (2010). «Минимизация, выбор и расстановка приоритетов регрессионного тестирования: обзор». Тестирование, проверка и надежность программного обеспечения. 22 (2): 67–120. Дои:10.1002 / stvr.430.
  11. ^ Колава, Адам. «Регрессионное тестирование, от программиста к программисту». Wrox.

внешняя ссылка