Человек-конкурентоспособные патчи в автоматическом программном ремонте с помощью Repairnator

Ремонтник - это бот. Он постоянно отслеживает программные ошибки, обнаруженные во время непрерывной интеграции программного обеспечения с открытым исходным кодом, и пытается их автоматически исправить. Если ему удастся синтезировать действительный патч, Repairnator предложит патч разработчикам-людям, замаскированным под фальшивую человеческую личность. На сегодняшний день Repairnator смог выпустить 5 патчей, которые были приняты разработчиками-людьми и навсегда слиты с базой кода. Это веха для человеческой конкурентоспособности в исследованиях по разработке программного обеспечения для автоматического восстановления программ. В этом посте мы расскажем историю об этом исследовании, проведенном в Королевском технологическом институте KTH, в Инрии, в Лилльском университете и в Валансьенском университете.

Исследования по восстановлению программ основаны на идее, что алгоритмы могут заменить людей, чтобы исправить ошибки в программном обеспечении [4]. Исправление ошибки - это патч, который вставляет, удаляет или изменяет исходный код. Например, в следующем патче разработчик изменил условие оператора if:

- если (х <10)
+ если (х <= 10)
Foo ();

Бот восстановления программы - это искусственный агент, который пытается синтезировать патчи исходного кода. Он анализирует ошибки и производит исправления так же, как разработчики, вовлеченные в деятельность по сопровождению программного обеспечения. Эта идея бота для восстановления программ разрушительна, потому что сегодня люди ответственны за исправление ошибок. Другими словами, мы говорим о боте, предназначенном для (частичной) замены разработчиков на утомительные задачи.

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

Человек-конкурентоспособности

Чтобы продемонстрировать, что восстановление программы конкурентоспособно для человека, бот восстановления программы должен найти высококачественный патч, прежде чем человек сделает это. В этом контексте патч можно считать конкурентоспособным человеком, если он удовлетворяет двум условиям своевременности и качества. Своевременность относится к тому, что система должна найти патч перед человеком-разработчиком. Другими словами, система-прототип должна производить исправления в порядке минут, а не дней. Кроме того, патч, сгенерированный ботом, должен быть достаточно корректным, такого же качества - корректным и читаемым - по сравнению с патчем, написанным человеком. Обратите внимание, что есть патчи, которые выглядят корректно с точки зрения бота, но все же они некорректны (в литературе это называется переоснащением патчей [6, 3]). Эти патчи, возможно, неконкурентоспособны, потому что люди никогда не примут их в своей кодовой базе.

Следовательно, для того, чтобы патч был конкурентоспособным человеком 1) бот должен синтезировать патч быстрее, чем разработчик-человек 2) патч должен быть достаточно хорошо оценен разработчиком-человеком и окончательно объединен в базе кода.

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

Чтобы преодолеть эту проблему, в начале проекта мы решили, что все исправления Repairnator будут предлагаться с поддельной человеческой идентичностью. Мы создали пользователя GitHub с именем Luc Esape, который представлен в качестве разработчика программного обеспечения в нашей исследовательской лаборатории. Люк имеет аватарку и выглядит как младший разработчик, стремящийся сделать взносы с открытым исходным кодом на GitHub. А теперь представьте, что Repairnator, замаскированный под Люка Эсапе, предлагает патч: разработчик, рассматривающий его, думает, что он рассматривает человеческий вклад. Этот камуфляж необходим для проверки нашей научной гипотезы о конкурентоспособности человека. Теперь, ради этики, настоящая личность Люка раскрывается в каждом из его запросов на получение ответа.

Автоматический ремонт и непрерывная интеграция

Непрерывная интеграция, то есть CI, - это идея о том, что сервер компилирует код и выполняет все тесты для каждого коммита, выполненного в системе контроля версий программного проекта (например, Git). На языке CI существует сборка для каждого коммита. Сборка содержит информацию об используемом снимке исходного кода (например, ссылку на коммит Git), результат компиляции и выполнения теста (например, сбой или успех) и журнал трассировки выполнения. Считается, что сборка дает сбой, если компиляция не удалась или по крайней мере один тестовый случай дал сбой. Было показано, что примерно одна из четырех сборок дает сбой, и что наиболее распространенной причиной сбоя сборки является сбой теста [8].

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

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

Центр внимания Repairnator на сбоях сборки уникален, но он вписывается в общую картину интеллектуальных ботов для программного обеспечения [2]. Например, в Facebook есть инструмент под названием SapFix, который исправляет ошибки, обнаруженные при автоматическом тестировании. Кроме того, злоумышленники и защитники ботов DARPA Cyber ​​Grand Challenge стараются быть конкурентоспособными по отношению к экспертам по безопасности.

Ремонтнатор в двух словах

В 2017–2018 годах мы разработали, внедрили и эксплуатировали Repairnator, бота для автоматического восстановления программ. Repairnator специализируется на устранении сбоев сборки, возникающих при непрерывной интеграции. Он постоянно отслеживает тысячи подтверждений, передаваемых на платформу хостинга кода GitHub, и анализирует их соответствующие сборки. Каждую минуту он запускает новые попытки восстановления, чтобы исправить ошибки перед разработчиком. Он предназначен для того, чтобы двигаться как можно быстрее, потому что участвует в гонке: если Repairnator находит патч перед разработчиком, он конкурирует с человеком.

Давайте теперь дадим обзор того, как работает робот Repairnator.

Основным входом Repairnator являются непрерывные интеграционные сборки, запускаемые коммитами, сделанными разработчиками (верхняя часть рисунка, (a) и (b)) на основе проектов GitHub (a). Выходные данные Repairnator являются двойными: (1) он автоматически создает исправления для восстановления неудачных сборок (g), если таковые имеются; (2) он собирает ценные данные для будущих исследований ремонта программы (h) и (k). Постоянно, Repairnator контролирует всю непрерывную деятельность проектов GitHub ©. Сборки CI представлены в качестве входных данных для трехступенчатого конвейера: (1) первый этап собирает и анализирует журналы сборки CI (e); (2) второй этап направлен на локальное воспроизведение сбоев сборки, которые произошли на CI (f); (3) на третьем этапе запускаются различные прототипы программ ремонта, полученные в результате последних научных исследований. Когда исправление найдено, участник проекта Repairnator выполняет быструю проверку работоспособности, чтобы не тратить драгоценное время разработчиков с открытым исходным кодом. (i) Если она находит патч невырожденным, она затем предлагает его оригинальным разработчикам проекта в виде запроса на GitHub (j). Затем разработчики следуют своему обычному процессу пересмотра кода и слияния.

Repairnator должен работать в данной программной экосистеме. Благодаря нашему опыту работы с Java в прошлых исследовательских проектах, реализация прототипа Repairnator сосредоточена на восстановлении программного обеспечения, написанного на языке программирования Java, построенного с помощью набора инструментов Maven, в проектах с открытым исходным кодом, размещенных на GitHub, в которых используется платформа непрерывной интеграции Travis CI. ,

Экспедиционные достижения

Мы работаем с Repairnator с января 2017 года, в три этапа. В течение месяца, в январе 2017 года, мы провели экспериментальный эксперимент с первоначальной версией прототипа. С 1 февраля 2017 года по 31 декабря 2017 года мы запустили Repairnator с фиксированным списком из 14 188 проектов, который мы называем «Экспедиция № 1». С 1 января 2018 года по 30 июня 2018 года Repairnator контролировал поток сборки Travis CI в режиме реального времени, мы называем его «Экспедиция № 2».

Основная цель экспериментального эксперимента состояла в том, чтобы проверить наш дизайн и начальную реализацию. Мы обнаружили, что наш прототип способен выполнять около 30 попыток ремонта в день, учитывая наши вычислительные ресурсы. Что еще более важно, этот экспериментальный эксперимент подтвердил наши основные технологические предположения: значительная часть популярных проектов с открытым исходным кодом использует Travis, и большинство из них используют Maven в качестве технологии сборки. Это означало, что у нас будет реальный шанс достичь нашей цели - синтезировать конкурентный патч в этом контексте.

Во время Экспедиции № 1, результаты которой подробно представлены в [7], Repairnator проанализировал 11 523 сборки с ошибками теста. Для 3551 из них (30,82%) Repairnator смог локально воспроизвести провал теста. Из 3551 попытки ремонта Repairnator обнаружил 15 патчей, которые могли бы пройти сборку CI. Однако наш анализ исправлений показал, что ни одно из этих исправлений не было конкурентоспособным для человека, потому что они пришли слишком поздно (Repairnator выпустил исправление после разработчика) или имели низкое качество (по совпадению они сделали сборку успешной).

Экспедиция № 2 является успешной. Он показал, что технология восстановления программ перешла границу человеческой конкурентоспособности. Repairnator выпустил 5 исправлений, которые соответствуют критериям человеческой конкурентоспособности, определенным выше: 1) исправления были произведены раньше, чем человеческие, 2) разработчик-человек принял исправления как допустимые вклады, и исправления были объединены в основную базу кода.

Человеческий конкурс на Github, патчи, синтезированные роботом Repairnator и принятые разработчиком:

  • 12 января 2018 года, aaime / geowebcache / pull / 1, «Спасибо за патч!»
  • 23 марта 2018 г., parkito / BasicDataCodeU […] / pull / 3 «объединить коммит 140a3e3 в parkito: разработка»
  • 5 апреля 2018 года, dkarv / jdcallgraph / pull / 2 «Спасибо!»
  • 3 мая 2018, eclipse / ditto / pull / 151 «Круто, спасибо за то, что прошли процесс Eclipse и за исправление».
  • 25 июня 2018 г., donnelldebnam / CodeU […] / pull / 151 «Спасибо!»

Первый патч, слитый нашим ботом по восстановлению программы, был принят разработчиком-человеком 12 января 2018 года. Вот история: 12 января 2018 года в 12:28 была запущена сборка для проекта aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Сборка не удалась после 2 минут выполнения, потому что два теста были ошибочными. Спустя сорок минут, 12 января 2018 года в 13:08, Repairnator обнаружил сбойную сборку во время регулярного мониторинга и запустил доступные системы восстановления программ, настроенные в Repairnator. Десять минут спустя, в 13:18, он нашел заплатку.

12 января 2018 года, в 13:35, член команды Repairnator взял исправление, сгенерированное Repairnator, и проверил открытие соответствующего pull-запроса на GitHub. 12 января 2018 года, в 14:10, разработчик принял патч и объединил его с комментарием: «Странно, я думал, что уже исправил это ... возможно, я сделал это в каком-то другом месте. Спасибо за патч! » Это был первый патч, выпущенный Repairnator и принятый в качестве полноценного вклада разработчика-человека, который окончательно слился с базой кода. Другими словами, Repairnator впервые был конкурентоспособным человеком.

После 6 месяцев работы в Repairnator было объединено 5 патчей, разработанных человеком, которые перечислены выше.

В целом, проект Repairnator выполнил свою миссию. Он показал, что восстановление программы можно рассматривать как соревнование между людьми: Repairnator обнаружил участки 1) перед людьми, 2) которые были признаны людьми хорошего качества.

Будущее

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

Остановимся подробнее на одном моменте - вопросе интеллектуальной собственности. 3 мая 2018 года Repairnator выпустил хороший патч для проекта eclipse / ditto GitHub. Вскоре после того, как он предложил исправление, один из разработчиков спросил: «Мы можем принимать только запросы на извлечение, которые приходят от пользователей, подписавших Лицензионное соглашение Eclipse Foundation Contributor». Мы были озадачены, потому что бот не может физически или морально подписать лицензионное соглашение и, вероятно, не имеет права делать это. Кто владеет интеллектуальной собственностью и ответственностью вклада ботов: оператор робота, разработчик бота или разработчик алгоритма ремонта? Это один из интересных вопросов, раскрытых проектом Repairnator.

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

Хотите присоединиться к сообществу Repairnator? Чтобы регулярно получать новости о Repairnator, отправьте электронное письмо по адресу repairnator.subscribe@4open.science!

- Мартин Монперрус, Саймон Урли, Томас Дюрио, Матиас Мартинес, Бенуа Бодри, Лайонел Синтурье

В прессе:

  • Загадочная жизнь Люка Эсапе, экстраординарного исправителя ошибок. Его большой секрет? Он не человек (Томас Клэберн, The Register)

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

  • [1] Дж. Р. Коза (2010). Соревнования человека с результатами генетического программирования. Генетическое программирование и развивающиеся машины 11 (3–4), с. 251–284. Цитируется:
  • [2] C. Lebeuf, M. D. Storey и A. Zagalsky (2018) Программные боты. IEEE Software 35, с. 18–23. Цитируется: Автоматическое восстановление и непрерывная интеграция.
  • [3] М. Мартинес, Т. Дюрио, Р. Соммерар, Дж. Сюань и М. Монперрус (2016) Автоматическое исправление реальных ошибок в Java: крупномасштабный эксперимент с набором данных Defects4j. Эмпирическая разработка программного обеспечения, стр. 1–29. Цитируется: Человеческая конкурентоспособность.
  • [4] М. Монперрус (2017) Автоматическое восстановление программного обеспечения: библиография. ACM Computing Surveys. Цитируется: Автоматическое восстановление и непрерывная интеграция.
  • [5] А. Мурджа, Д. Янссенс, С. Демейер и Б. Василеску (2016). Среди машин: взаимодействие человека с ботом в социальных сетях. В трудах конференции ОМС 2016 года Расширенные тезисы о человеческом факторе в вычислительных системах, с. 1272–1279. Цитируется: Человеческая конкурентоспособность.
  • [6] Э. К. Смит, Э. Т. Барр, К. Ле Гуэс и Й. Брюн (2015 г.) Является ли лекарство хуже болезни? переоснащение в автоматизированной программе ремонта. В материалах 10-го Совместного совещания по основам разработки программного обеспечения 2015 года, с. 532–543. Внешние ссылки: Документ, цитируемый: Человеческая конкурентоспособность.
  • [7] С. Урли, З. Ю., Л. Синтурье и М. Монперрус (2018) Как разработать программу для восстановления бота? Выводы из проекта «Ремонтатор». В ICSE 2018–40-я Международная конференция по программной инженерии, «Отслеживание программной инженерии на практике», «Внешние ссылки: Ссылка»: Экспедиционные достижения, Будущее
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta и S. Panichella (2017) Повесть об ошибках сборки CI: Открытый исходный код и Перспектива финансовой организации. На Международной конференции по сопровождению и развитию программного обеспечения, на которую ссылаются: Автоматическое восстановление и непрерывная интеграция.