Бисекция (программная инженерия)

Разработка программного обеспечения

Bisection — это метод, используемый в разработке программного обеспечения для определения наборов изменений , которые приводят к определенному изменению поведения. Он в основном используется для поиска патча, который внес ошибку . Другая область применения — поиск патча, который косвенно исправил ошибку.

Обзор

Процесс поиска набора изменений , который внес определенную регрессию, был описан как «изоляция исходных изменений» в 1997 году Брайаном Нессом и Вьет Нго из Cray Research . Регрессионное тестирование проводилось на компиляторах Cray в редакциях, включающих один или несколько наборов изменений. Редакции с известными регрессиями не могли быть проверены, пока разработчики не устранили проблему. Изоляция исходных изменений сузила причину до одного набора изменений, который затем можно было исключить из редакций, разблокировав их в отношении этой проблемы, пока автор изменения работал над исправлением. Несс и Нго обрисовали методы линейного поиска и бинарного поиска для выполнения этой изоляции. [1]

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

Метод деления пополам

Алгоритм деления кода пополам

История кода имеет структуру направленного ациклического графа , который может быть отсортирован топологически . Это позволяет использовать алгоритм поиска «разделяй и властвуй», который:

Алгоритмическая сложность

Двоичное деление выполняется в LSPACE, имея алгоритмическую сложность , обозначающую количество ревизий в пространстве поиска, и похоже на двоичный поиск . О ( бревно Н ) {\displaystyle O(\log N)} Н {\displaystyle N}

Желаемые свойства репозитория

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

Монотонность

Для того чтобы алгоритм бисекции идентифицировал один набор изменений, который вызвал изменение тестируемого поведения, поведение должно изменяться монотонно по всему пространству поиска. Для булевой функции, такой как тест pass/fail, это означает, что она изменяется только один раз по всем наборам изменений между началом и концом пространства поиска.

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

Поддержка автоматизации

Хотя метод деления пополам можно выполнить вручную, одним из его главных преимуществ является то, что его можно легко автоматизировать. [1] Таким образом, он может быть встроен в существующие процессы автоматизации тестирования : сбои в исчерпывающих автоматизированных регрессионных тестах могут запустить автоматическое деление пополам для локализации ошибок. Несс и Нго сосредоточились на его потенциале в среде непрерывной доставки Cray, в которой автоматически изолированный плохой набор изменений может быть автоматически исключен из сборок. [2]

Системы контроля версий Fossil , Git и Mercurial имеют встроенную функциональность для деления кода на части. [3] [4] [5] Пользователь может начать сеанс деления на части с указанным диапазоном ревизий, из которых система контроля версий предлагает ревизию для тестирования, пользователь сообщает системе, является ли протестированная ревизия «хорошей» или «плохой», и процесс повторяется до тех пор, пока не будет идентифицирована конкретная «плохая» ревизия. Другие системы контроля версий, такие как Bazaar или Subversion , поддерживают деление на части с помощью плагинов [6] или внешних скриптов. [7]

Тестовый набор Phoronix может автоматически выполнять деление пополам для выявления снижения производительности.

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

Ссылки

  1. ^ ab Ness, Brian; Ngo, Viet (1997). Сдерживание регрессии посредством изоляции изменений источника . Конференция по программному обеспечению и приложениям. IEEE. doi :10.1109/CMPSAC.1997.625082.
  2. ^ Целлер, Андреас (1999). Вчера моя программа работала. Сегодня — нет. Почему? . Европейская конференция по программной инженерии. Тулуза, Франция. doi : 10.1145/318774.318946 .
  3. ^ "Fossil: Help: bisect". www.fossil-scm.org . Получено 2020-09-03 .
  4. ^ "git-bisect(1)". git-scm.com . Получено 2017-08-05 .
  5. ^ "hg". Selenic.com . Получено 2017-01-09 .
  6. ^ "bisect - Найдите ревизию, в которой возникла ошибка, с помощью бинарного поиска — документация Bazaar 2.8.0dev1". Doc.bazaar.canonical.com . Получено 09.01.2017 .
  7. ^ "svn-bisect". Metacpan.org . Получено 2022-08-03 .
Взято с "https://en.wikipedia.org/w/index.php?title=Бисекция_(программная_инженерия)&oldid=1136432968"