stringtranslate.com

Программная регрессия

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

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

Профилактика и обнаружение

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

До выпуска

Чтобы конечный пользователь не заметил регрессий после выпуска, разработчики регулярно проводят регрессионные тесты после внесения изменений в программное обеспечение. Эти тесты могут включать модульные тесты для выявления локальных регрессий, а также интеграционные тесты для выявления удаленных регрессий. [6] Методы регрессионного тестирования часто используют существующие тестовые примеры, чтобы минимизировать усилия, необходимые для их создания. [7] Однако из-за объема существующих тестов часто необходимо выбрать репрезентативное подмножество, используя такие методы, как расстановка приоритетов тестовых сценариев .

Для обнаружения снижения производительности на регулярной основе запускаются тесты производительности программного обеспечения , чтобы отслеживать время отклика и показатели использования ресурсов программного обеспечения после последующих изменений. [8] В отличие от тестов функциональной регрессии, результаты тестов производительности могут различаться , то есть результаты могут различаться в разных тестах из-за различий в измерениях производительности; в результате необходимо принять решение о том, представляет ли изменение показателей производительности регрессию, на основе опыта и требований конечного пользователя. Для принятия этого решения иногда используются такие подходы, как тестирование статистической значимости и обнаружение точек изменения . [9]

Прежде чем совершить

Поскольку отладка и локализация основной причины регрессии программного обеспечения может быть дорогостоящей, [10] [11] также существуют некоторые методы, которые пытаются в первую очередь предотвратить фиксацию регрессий в репозитории кода . Например, Git Hooks позволяет разработчикам запускать тестовые сценарии до того, как изменения кода будут зафиксированы или отправлены в репозиторий кода. [12] Кроме того, анализ воздействия изменений был применен к программному обеспечению для прогнозирования влияния изменения кода на различные компоненты программы, а также для дополнения выбора тестовых сценариев и определения приоритетов. [13] [14] Программные линтеры также часто добавляются в перехватчики фиксации, чтобы обеспечить единообразный стиль кодирования, тем самым сводя к минимуму стилистические проблемы, которые могут сделать программное обеспечение склонным к регрессии. [15]

Локализация

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

Функциональные регрессии

Распространенным методом локализации функциональных регрессий является bisection , который принимает в качестве входных данных как ошибочный коммит, так и ранее работающий коммит, и пытается найти основную причину, выполняя двоичный поиск между коммитами. [16] Системы контроля версий , такие как Git и Mercurial, предоставляют встроенные способы выполнения деления пополам заданной пары коммитов. [17] [18]

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

Регресс производительности

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

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

Дополнительные подходы включают написание модульных тестов с учетом производительности для облегчения локализации [27] и ранжирование подсистем на основе отклонений счетчика производительности. [28] Bisection также можно перепрофилировать для регрессии производительности, рассматривая коммиты, производительность которых ниже (или выше) определенного базового значения, как ошибочные, и выбирая левую или правую часть коммитов на основе результатов этого сравнения.

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

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

  1. ^ Вонг, В. Эрик; Хорган, младший; Лондон, Сол; Агравал, Хира (1997). «Исследование эффективного регрессионного тестирования на практике». Материалы Восьмого международного симпозиума по проектированию надежности программного обеспечения (ISSRE 97). IEEE. doi :10.1109/ISSRE.1997.630875. ISBN 0-8186-8120-9. S2CID  2911517.
  2. ^ Иегудай, Амирам; Тышберович, Шмуэль; Нир, Дор (2007). Обнаружение ошибок регрессии. Хайфская контрольная конференция. дои : 10.1007/978-3-540-77966-7_18 . Проверено 10 марта 2018 г.
  3. ^ Шан, Вэйи; Хасан, Ахмед Э.; Насер, Мохамед; Флора, Парминдер (11 декабря 2014 г.). «Автоматическое обнаружение снижения производительности с использованием регрессионных моделей на кластерных счетчиках производительности» (PDF) . Архивировано из оригинала (PDF) 13 января 2021 года . Проверено 22 декабря 2019 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  4. ^ Анри, Жан-Жак Пьер (2008). Сеть тестирования: интегральный подход к тестированию в крупных проектах программного обеспечения . Springer Science & Business Media. п. 74. ИСБН 978-3540785040.
  5. ^ Ричардсон, Джаред; Гуолтни, Уильям младший (2006). Отправим его! Практическое руководство по успешным программным проектам. Роли, Северная Каролина: Прагматичная книжная полка. стр. 32, 193. ISBN. 978-0-9745140-4-8.
  6. ^ Люнг, Харетон, КН; Уайт, Ли (ноябрь 1990 г.). «Исследование интеграционного тестирования и регрессии программного обеспечения на уровне интеграции». Материалы международной конференции по сопровождению программного обеспечения. Сан-Диего, Калифорния, США: IEEE. дои : 10.1109/ICSM.1990.131377. ISBN 0-8186-2091-9. S2CID  62583582.
  7. ^ Ротермель, Грегг; Харрольд, Мэри Джин; Дедия, Джейней (2000). «Выбор регрессионного теста для программного обеспечения C++». Тестирование, проверка и надежность программного обеспечения . 10 (2): 77–109. doi :10.1002/1099-1689(200006)10:2<77::AID-STVR197>3.0.CO;2-E. ISSN  1099-1689.
  8. ^ Вейкер, Э.Дж.; Воколос, FI (декабрь 2000 г.). «Опыт тестирования производительности программных систем: проблемы, подход и практический пример». Транзакции IEEE по разработке программного обеспечения . 26 (12): 1147–1156. дои : 10.1109/32.888628. ISSN  1939-3520.
  9. ^ Дейли, Дэвид; Браун, Уильям; Инго, Хенрик; О'Лири, Джим; Брэдфорд, Дэвид (20 апреля 2020 г.). «Использование обнаружения точек изменения для выявления снижения производительности программного обеспечения в системе непрерывной интеграции». Материалы Международной конференции по производительности. Ассоциация вычислительной техники. стр. 67–75. дои : 10.1145/3358960.3375791. ISBN 978-1-4503-6991-6. S2CID  211677818.
  10. ^ Нистор, Адриан; Цзян, Тянь; Тан, Лин (май 2013 г.). «Обнаружение, сообщение и исправление ошибок производительности». Материалы рабочей конференции по репозиториям программного обеспечения для майнинга (MSR). стр. 237–246. дои : 10.1109/MSR.2013.6624035. ISBN 978-1-4673-2936-1. S2CID  12773088.
  11. ^ Агарвал, Прагья; Агравал, Арун Пракаш (17 сентября 2014 г.). «Методы локализации неисправностей программных систем: обзор литературы». Заметки по разработке программного обеспечения ACM SIGSOFT . 39 (5): 1–8. дои : 10.1145/2659118.2659125. ISSN  0163-5948. S2CID  12101263.
  12. ^ "Git - Git Hooks" . git-scm.com . Проверено 7 ноября 2021 г.
  13. ^ Орсо, Алессандро; Апиваттанапонг, Тависуп; Харрольд, Мэри Джин (1 сентября 2003 г.). «Использование полевых данных для анализа воздействия и регрессионного тестирования». Заметки по разработке программного обеспечения ACM SIGSOFT . 28 (5): 128–137. дои : 10.1145/949952.940089. ISSN  0163-5948.
  14. ^ Цюй, Сяо; Ачарья, Митхун; Робинсон, Брайан (сентябрь 2012 г.). «Выбор конфигурации с использованием анализа влияния изменений кода для регрессионного тестирования». Материалы международной конференции по сопровождению программного обеспечения. стр. 129–138. дои : 10.1109/ICSM.2012.6405263. ISBN 978-1-4673-2312-3. S2CID  14928793.
  15. ^ Томасдоттир, Кристин Фьола; Аниче, Маурисио; ван Дёрсен, Ари (октябрь 2017 г.). «Почему и как разработчики JavaScript используют линтеры». Материалы международной конференции по автоматизированной разработке программного обеспечения. стр. 578–589. дои : 10.1109/ASE.2017.8115668. ISBN 978-1-5386-2684-9. S2CID  215750004.
  16. ↑ Гросс, Томас (10 сентября 1997 г.). «Отладка пополам». Материалы международного семинара по автоматической отладке. Электронная пресса Университета Линчепинга. стр. 185–191.
  17. ^ "Git - Документация git-bisect" . git-scm.com . Проверено 7 ноября 2021 г.
  18. ^ "hg - биссектриса" . www.selenic.com . Меркуриальный . Проверено 7 ноября 2021 г.
  19. ^ «Чтение 11: Отладка» . web.mit.edu . Массачусетский технологический институт.
  20. ^ Бузе, Бен; Вэй, Томас; Цзан, Чжицян; Миличевич, Александр; Глигорич, Милош (май 2019 г.). «VeDebug: инструмент регрессионной отладки для Java». Материалы Международной конференции по программной инженерии: сопутствующие материалы (ICSE-Companion). стр. 15–18. doi : 10.1109/ICSE-Companion.2019.00027. ISBN 978-1-7281-1764-5. S2CID  174799830.
  21. ^ Таха, А.-Б.; Тебо, С.М.; Лю, С.-С. (сентябрь 1989 г.). «Подход к локализации и повторной проверке ошибок программного обеспечения на основе поэтапного анализа потока данных». Материалы ежегодной международной конференции по компьютерному программному обеспечению и приложениям. IEEE. стр. 527–534. дои : 10.1109/CMPSAC.1989.65142. ISBN 0-8186-1964-3. S2CID  41978046.
  22. ^ Окариса, Фролин С.; Чжао, Боян (2021). «Локализация снижения производительности программного обеспечения в веб-приложениях путем сравнения сроков выполнения». Тестирование, проверка и надежность программного обеспечения . 31 (5): e1750. дои : 10.1002/stvr.1750. ISSN  1099-1689. S2CID  225416138.
  23. ^ «Анализ производительности во время выполнения» . Разработчики Chrome . Google . Проверено 7 ноября 2021 г.
  24. ^ «Справочник по анализу производительности — Microsoft Edge Development» . docs.microsoft.com . Майкрософт . Проверено 7 ноября 2021 г.
  25. ^ Яо, Кунди; Б. де Падуа, Гильерме; Шан, Вэйи; Спорея, Стив; Тома, Андрей; Саджеди, Сара (30 марта 2018 г.). «Log4Perf: предложение мест для журналов для мониторинга производительности веб-систем». Материалы Международной конференции по производительности. Ассоциация вычислительной техники. стр. 127–138. дои : 10.1145/3184407.3184416. ISBN 978-1-4503-5095-2. S2CID  4557038.
  26. ^ Ли, Хэн; Шан, Вэйи; Адамс, Брэм; Саях, Мохаммед; Хасан, Ахмед Э. (30 января 2020 г.). «Качественное исследование преимуществ и затрат на лесозаготовки с точки зрения разработчиков». Транзакции IEEE по разработке программного обеспечения . 47 (12): 2858–2873. дои : 10.1109/TSE.2020.2970422. S2CID  213679706.
  27. ^ Хегер, Кристоф; Хаппе, Йенс; Фарахбод, Рузбе (21 апреля 2013 г.). «Автоматическое выявление первопричин снижения производительности во время разработки программного обеспечения». Материалы Международной конференции по производительности. Ассоциация вычислительной техники. стр. 27–38. дои : 10.1145/2479871.2479879. ISBN 978-1-4503-1636-1. S2CID  2593603.
  28. ^ Малик, Харун; Адамс, Брэм; Хасан, Ахмед Э. (ноябрь 2010 г.). «Определение подсистем, ответственных за отклонения производительности при нагрузочном тесте». Материалы международного симпозиума по обеспечению надежности программного обеспечения. стр. 201–210. дои :10.1109/ISSRE.2010.43. ISBN 978-1-4244-9056-1. S2CID  17306870.