Регрессионное тестирование

редактировать
Проверка того, не нарушили ли изменения программного обеспечения функциональность, которая раньше работала

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

Содержание

  • 1 Предпосылки
  • 2 Методы
    • 2.1 Повторное тестирование всех
    • 2.2 Выбор регрессионного теста
    • 2.3 Приоритизация тестовых примеров
      • 2.3.1 Типы приоритезации тестовых примеров
    • 2.4 Гибрид
  • 3 Преимущества и недостатки
  • 4 Использование
  • 5 См. Также
  • 6 Ссылки
  • 7 Внешние ссылки

Справочная информация

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

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

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

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

Методы

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

Повторное тестирование всех

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

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

В отличие от Retest all, этот метод запускается

Последняя правка сделана 2021-06-03 11:56:08
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте