Программная регрессия — это тип программной ошибки , когда функция, которая работала до этого, перестает работать. Это может произойти после внесения изменений в исходный код программного обеспечения , включая добавление новых функций и исправление ошибок. [1] Они также могут быть вызваны изменениями среды, в которой работает программное обеспечение, например, обновлением системы, исправлением системы или переходом на летнее время . [2] Снижение производительности программного обеспечения — это ситуация, когда программное обеспечение по-прежнему работает правильно, но работает медленнее или использует больше памяти или ресурсов, чем раньше. [3]На практике были выявлены различные типы программных регрессий, в том числе следующие: [4]
Регрессии часто вызваны комплексными исправлениями ошибок , включенными в исправления программного обеспечения . Одним из способов избежать подобных проблем является регрессионное тестирование . Правильно разработанный план тестирования направлен на предотвращение такой возможности перед выпуском любого программного обеспечения. [5] Автоматизированное тестирование и хорошо написанные тестовые примеры могут снизить вероятность регрессии.
Были предложены методы, которые пытаются предотвратить внедрение регрессий в программное обеспечение на различных этапах разработки, описанных ниже.
Чтобы конечный пользователь не увидел регрессии после выпуска, разработчики регулярно проводят регрессионные тесты после внесения изменений в программное обеспечение. Эти тесты могут включать модульные тесты для обнаружения локальных регрессий, а также интеграционные тесты для обнаружения удаленных регрессий. [6] Методы регрессионного тестирования часто используют существующие тестовые примеры, чтобы свести к минимуму усилия, затрачиваемые на их создание. [7] Однако из-за объема этих существующих тестов часто необходимо выбрать репрезентативное подмножество, используя такие методы, как приоритизация тестовых случаев .
Для обнаружения регрессии производительности тесты производительности программного обеспечения запускаются на регулярной основе, чтобы контролировать время отклика и показатели использования ресурсов программного обеспечения после последующих изменений. [8] В отличие от функциональных регрессионных тестов, результаты тестов производительности могут различаться, то есть результаты могут различаться между тестами из-за различий в измерениях производительности ; в результате необходимо принять решение о том, является ли изменение показателей производительности регрессией, исходя из опыта и требований конечных пользователей. Для принятия этого решения иногда используются такие подходы, как проверка статистической значимости и обнаружение точки изменения . [9]
Поскольку отладка и локализация основной причины регрессии программного обеспечения может быть дорогостоящей, [10] [11] также существуют некоторые методы, которые в первую очередь пытаются предотвратить фиксацию регрессии в репозиторий кода . Например, Git Hooks позволяют разработчикам запускать тестовые сценарии до того, как изменения кода будут зафиксированы или отправлены в репозиторий кода. [12] Кроме того, анализ воздействия изменений применялся к программному обеспечению для прогнозирования влияния изменения кода на различные компоненты программы, а также для дополнения выбора тестовых случаев и определения приоритетов. [13] [14] Программные линтерытакже часто добавляются в обработчики коммитов, чтобы обеспечить согласованный стиль кодирования, тем самым сводя к минимуму стилистические проблемы, которые могут сделать программное обеспечение склонным к регрессиям. [15]