Об исследовании
Хотелось бы сразу четко обозначить, что же такое тестирование программного обеспечения. Основная его цель состоит в том, чтобы найти ошибки в работе программы, непрописанные разработчиками ПО. Если тесты пройдены успешно, то можно смело сказать, что ваша программа готова к выпуску.
Кажется, что найти ошибку в программном обеспечении не так сложно, особенно если у разработчика уже есть опыт использования ПО с багами. Да, есть ошибки, которые можно легко заметить и найти, но разработчики часто не видят уязвимые места, которые даже после их тщательной работы могут обнаружить хакеры. При помощи тестирования мы хотим находить ошибки прежде, чем станем жертвами несчастных случаев из-за нарушений безопасности и автомобильных аварий. Как сообщает The Associated Press, по вине программных ошибок автомобилей Toyota в 2000—2010 годах погибли 89 человек.
Главная цель проекта заключается в автоматическом исправлении технических дефектов или ошибок в программах. Практически любое программное обеспечение содержит ошибки, особенно с появлением непрерывных процессов разработки, тестирования и внедрения. Сейчас разработчикам становится всё сложнее устранять ошибки своевременно. Поэтому необходимо сохранять программное обеспечение как можно более защищенным от дефектов, и многие исследователи, в том числе и я, пытаются найти решение и разработать метод автоматического устранения неполадок. В этом конкретном проекте я стараюсь увеличить скорость автоматического исправления технических ошибок, чтобы максимально сократить время между их обнаружением и устранением.
Автоматическое исправление технических багов тестировалось многими исследователями, включая меня. Первые результаты были приняты индустрией, и такие компании как Фэйсбук уже начали использовать автоматическое устранение таких багов как неисправный поинтер, который указывает на несуществующую ячейку.
Что это решит
У всех есть свои интересы. Меня интересуют языки программирования, верификация программного обеспечения и тестирование, все это неразрывно связано с пониманием компьютерных программ. Не так давно автоматическое исправление ошибок стало для меня отдельной темой для исследования. Думаю, в будущем, ПО будет создаваться искусственным интеллектом, что позволит разработчикам уделять больше времени для работы над ключевыми программными компонентами.
За последнее десятилетие автоматическое исправление ошибок совершило довольно большой скачок вперед, благодаря усилиям разработчиков, в том числе и моим. Я работал над улучшением автоматически генерируемых патчей и автоматическим устранением ошибок. Думаю, что следующий прорыв, который нам необходим — быстрая скорость. До сих пор считалось, что автоматическое исправление ошибок будет использоваться в пакетном режиме, поэтому вопрос скорости не стоял на первом месте. Разработчики запускают автоматическое устранение ошибок и уходят домой. А к следующему утру участки, автоматически отлаженные за ночь, готовы к просмотру. Но опыт показывает, что исправлять ошибки лучше всего сразу же после написания баг-программы, пока разработчик еще помнит, что он там написал. Поэтому я предложил исследование высокоскоростных автоматических исправлений ошибок.
Конкуренты
Это был международный грант и разработки предлагали исследователи со всего мира. Facebook получили 145 заявок и отобрали 10 победителей, в числе которых был я. Это число (6,9%) показывает, насколько жестче была конкуренция по сравнению с получением гранта на топовых конференциях, где процент одобренных заявок обычно составляет 20%.
Все 10 лауреатов премии и их исследования опубликованы на сайте Facebook Research. Победителями стали известные исследователи в своих областях из престижных университетов: Университет Карнеги-Меллон, Университетский колледж Лондона, Калифорнийский университет в Беркли и Берлинский университет Гумбольдта.
Дальнейшие планы
Автоматизированное устранение ошибок — всё еще молодая область, и есть много вещей, над которыми стоит поработать. Нам нужен метод, который может исправить большее количество ошибок более точно и быстро, и я планирую работать в этом направлении. В перспективе хотелось бы, чтобы искусственный интеллект cмог не только исправлять ошибки, а помогал разработчикам на протяжении всего процесса работы.
Как многие другие академические исследования, проекты в области автоматического устранения технических ошибок не могут быть решены путём одного исследования. Надо учесть множество измерений для того, чтобы идея стала практичной. Как я уже говорил, я делаю акцент на скорости устранения технических ошибок, но скорость — это лишь одно измерение для решения задачи. Другие измерения включают в себя процент успешности распознавания ошибок, точность устранения проблем и т.д. В науке и технологиях улучшение одного измерения помогает развитию другого, и это то, чем я планирую заняться в будущем — продолжать расширять границы автоматического решения технических проблем в различных измерениях.
Что касается применимости подобной техники, ранее я использовал её в автоматическом формировании обратной связи для программ, написанных студентами. Данная, так называемая, умная система тьюторства является одной из областей, где результаты исследования могут быть применены.
Комментарии (8)
slovak
09.01.2019 22:24+1Практически любое программное обеспечение содержит ошибки, особенно с появлением непрерывных процессов разработки, тестирования и внедрения
Подскажите, как понимать данное предложение?
Мне читается как: CI/CD и тестирование привело к бОльшему количеству багов.lxsmkv
10.01.2019 04:23Я перефразирую: «С появлением скоростных трасс, и хорошего дорожного покрытия количество ДТП увеличилось.» В такой формулировке все логично.
Возвращаясь к изначальной фразе, тут есть как минимум психологический фактор — чем больше ты полагаешься на внешние системы контроля тем меньше контролируешь сам.
Система сборки и ее контроля автоматизирована, можно накидывать код в три раза быстрее. Но код от этого лучше не становится. Цикл разработки становится короче. Увеличивается давление на разработчика (нужно успеть уже не к послезавтра, а к сегодняшнему вечеру), и он больше предпочитает быстрые решения правильным.
А что до тестов — они не делают программу лучше. Они не делают программистов лучше. Они всего лишь выявляют некоторые дисфункции в программе.
Тесты вообще не обеспечивают качество программ (quality assurance) — это делают разработчики. Обеспечение качества это сделать так, чтобы ошибок не возникало. Не ставить радары и штрафовать за превышение скорости, а сделать так чтобы водители не превышали скорость.
Расскажу одну байку. Меня как-то спросили, сколько мне потребуется времени, чтобы автоматизировать набор тестов на подсистему. Я сказал, что это зависит от того, насколько она будет рабочей. Ведь если во время написания теста ты натыкаешься на ошибку в системе, то ее в первую очередь нужно устранить. Тогда мне сказали: «Ну, предположим там все закончено, все работает». На что я ответил, что если «все работает» то тесты уже не нужны. Такой вот «парадокс».
slovak
10.01.2019 15:51чем больше ты полагаешься на внешние системы контроля тем меньше контролируешь сам.
Так откажитесь от компилятора — и контролируйте все сами. Напишите проект с бинарем в 1 МБ и поделитесь Вашей продуктивностью и количеством ошибок на пути.
Ваша логика в корне не верна, Вы не принимаете во внимание ограниченнойсть ресурсов человеческого мозга. Автоматизация позволяет повысить уровень абстракции и производить более сложные продукты.lxsmkv
10.01.2019 16:57Все так. Но автоматизация как таковая не улучшает качество конечных продуктов.
Взять какой-нибудь продвинутый станок с ЧПУ. Качество производимых деталей будет конечно лучше, детали будут производится быстрее. Но появится брак другого типа. Ошибки человека программирущего машину, и ошибки при проектировании детали. Увеличилось количество фабриката, появились проблемы с хранением. Появился брак из-за неправильного хранения.
И как Вы верно сказали, мы можем быстрее делать более сложные системы, но брак полностью не устраняется, он скорее переходит на другой уровень.
Появились фреймворки для javascript, разработка сложных систем ускоррилась, но стало необходимым тонкое понимание устройства фреймворка и его неправильное использование приводит к браку.
У меня есть стойкое ощущение того, что эволюция систем производства не улучшает качества конечной продукции. Она только позволяет производить более сложные системы в более короткие сроки. А ошибки как были так и есть, только другие.
Что касается изначальной фразы, скажу честно, у меня нет цифр для сравнения, и вряд ли такое сравнение можно провести. Думаю даже оно не имеет смысла, как сравнение современного автомобиля, и квадроцикла Форда. Так что это чисто мое «ощущение» основанное на личном опыте в проекте. Я бы сказал, что качество производимых продуктов не уменьшилось и не увеличилось. Но это ничем не подкрепленная гипотеза.
SiliconValleyHobo
>начали использовать автоматическое устранение таких багов как неисправный поинтер, который указывает на несуществующую ячейку
LOL
Ну а вообще тема довольно известная. Грант как грант, тема как тема. Хотелось бы вайтпепер почитать, но что-то не нагугливается. А вот что забавно, дак это посмотреть на публикации чела и на его соавторов:
Там, как правило, полная дичь в соавторстве с Тормасовым — видимо, улучшают показатели института по статьям, лол
Еще нашел студенческую статью — опросник по студентам и натягивание компьютер саенса на него
И еще статья посерьезнее, но написанная им в Сингапуре. Причем, что самое смешное, у него там числится Попилополис как институт
По итогу мне кажется, что это профанация, деньги уйдут на студенческую нерабочую поделку и зарплату профессору.
VitalityM
Тоже посмотрел его статьи, есть вполне серьезные работы за последние 2 года, а есть где он числиться 4ым-5ым автором, я бы не стал на них сильно внимание обращать. В целом нормальный чел, хотя тема на мой взгляд не самая интересная. С февраля 2019 он переезжает в Корею кстати.
ratijas