В последние годы использование технологий Deep Learning позволило достичь значительного прогресса в таких областях, как распознавание образов, автоматический перевод и др. Этот успех, а также разработки в области беспилотных автомобилей и достижения компьютера в игре GO, позволили фантазировать о том, что Искусственный Интеллект скоро будет делать ту работу, которую сейчас выполняют люди, и будет претендовать на их рабочие места.
Повсеместная замена людей на роботов — процесс увлекательный, но не быстрый. Однако уже сейчас можно использовать возросшие вычислительные мощности компьютеров для того, чтобы облегчить решение задач, с которыми люди сталкиваются каждый день. Например, процесс написания программ. Использование систем, которые облегчают процесс программирования, не является чем-то исключительным, любая среда разработки предоставляет множество таких инструментов.
В этой статье представленна технология, помогающая программисту написать тест на основе модуля на языке Java. Технология позволяет значительно сэкономить время по сравнению с написанием теста вручную.
Тесты
В процессе создания программного модуля мы всегда хотим быть уверены, что запрограммированный функционал соответствует нашим требованиям. Для того чтобы знать, что реальное поведение созданной нами программы соответствует ожидаемому результату, используются тесты.
Необходимость, все плюсы и минусы написания тестов перечислены здесь. Однако несомненно то, что написание тестов требует значительного времени (исследования показывают, что разработчики тратят до 30% времени на создание тестов). Кроме того, эта деятельность не развивает функциональность основного программного модуля, поэтому логично, что многие команды стараются избежать написания тестов. С другой стороны, поддержка старого функционала и программирование нового сильно осложняются без использования тестов.
Помимо контроля правильности выполнения программы тесты могут также объяснять функциональность выполняемой программы на “естественном языке”. То есть тестовые скрипты могут сопровождаться текстом-документацией, которая объясняет поведение теста и тестируемой программы в парадигме BDD .
В данной статье мы обсуждаем технологию автоматической генерации тестов. При синтезе тестов мы будем использовать Gherkin-нотацию.
Пример теста на русском языке с использованием Gherkin:
# language: ru
@all
Функция: Аутентификация банковской карты
Банкомат должен спросить у пользователя PIN-код банковской карты
Банкомат должен выдать предупреждение, если пользователь ввел неправильный PIN-код
Аутентификация успешна, если пользователь ввел правильный PIN-код
Предыстория:
Допустим пользователь вставляет в банкомат банковскую карту
И банкомат выдает сообщение о необходимости ввода PIN-кода
@correct
Сценарий: Успешная аутентификация
Если пользователь вводит корректный PIN-код
То банкомат отображает меню и количество доступных денег на счету
@fail
Сценарий: Некорректная аутентификация
Если пользователь вводит некорректный PIN-код
То банкомат выдает сообщение, что введённый PIN-код неверный
BDD, TDD
Техники TDD и BDD подразумевают, что тест пишется до начала разработки самого тестируемого модуля (https://ru.wikipedia.org/wiki/Разработка_через_тестирование),
Test -> Module
Не обсуждая плюсы и минусы подхода TDD и BDD, нужно сказать, что в жизни очень часто встречаются ситуации (а, возможно, таких случаев большинство), когда тесты пишутся после готовности модуля, или тесты не пишутся вовсе. Это приводит к тому, что код становится нечитаемым и сложно поддерживаемым, приводя, в частности, к феномену legacy code.
Таким образом, мы предлагаем возможность синтезировать тест и описание кода в формате BDD на основе готового кода — в том случае, если тестов вообще не было или тесты собирались писать после создания программного модуля.
Module -> Test
Синтез
Процесс создания тестов начинается с анализа готового программного модуля. В данный момент мы работаем с классами, написанными на Java. Общая схема работы такая — вначале мы собираем логи и информацию о выполнении программного модуля, затем на основе этих логов обучаем нейронную сеть, далее используем нейронную сеть для генерации готовых тестовых скриптов.
Сбор логов
Допустим, у нас есть модуль, обслуживающий клиентский банковский счет.
Мы собираем логи на каждом шаге программы, начиная с информации об input и output, и заканчивая изменениями переменных
Сам сбор происходит следующим образом:
Мы берем инпуты — это могут быть данные из access логов, или варианты, предоставленные программистом, или автоматически сформированные данные с помощью различных генетических или рандомных механизмов (Evosuite, Randoop).
В особых случаях мы можем оставить модуль сбора логов в продакшене, но в общем случае это не рекомендуется.
Обучение нейросети
Обучение нейронной сети происходит в парадигме Neural Programmer-Interpreters.
NPI работает так: на основе входных данных (на картинке, “previous NPI state”, “environment observation”, “input program”) предсказывает команда (“output program”).
Умея распознавать environment для предскзывания простых программ (операции сложения, ссотировки), программа может предсказывать Gherkin нотацию для этих данных. Качество использования NPI зависит как от возможности обрабатывать определенные входные данные, так и от развития архитектуры нейросети.
Таким образом, обученная нейросеть решает традиционную для программного синтеза задачу — как найти правильную программу (Gherkin нотацию, тест-кейс) для текущих входных данных (env1’).
Генерация скриптов.
На основе обученной нейросети генерируются тест-кейсы. В самом простом случае — списки данных, которые прошли валидно, и списки данных, которые валидацию не прошли.
Готовые скрипты можно редактировать с учетом финальных требований. Тесты Gherkin написаны на “естественном языке”, что подразумевает возможность прочтения и редактирования этих тестов всей командой, как теми, кто писал код, так и теми, кто не имел отношения к разработке модуля.
При каждом выполнении тесты будут проверять те условия, которые в них закодированы. В том случае, если функционал тестируемого программного модуля изменился, нейронную сеть можно обучить повторно для генерации новых тестов.
Выполнение тестов на языка Gherkin производится на тестовом фреймворке Cucumber.
Фреймворк поддерживает автоматическое выполнение скриптов при сборке с помощью Maven.
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-java</artifactId>
<version>1.2.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-junit</artifactId>
<version>1.2.4</version>
</dependency>Также Cucumber интегрируется с другими инструментами continuous integration, такими как Jenkins и прочее.
Генерация тестовых скриптов, ограничения
У автоматического генератора есть сразу несколько ограничений. Все они обусловлены тем, что программа не «учится» программировать или «понимать» алгоритмы. Цель программы — уметь сопоставлять понятные ей виды входных данных с выходными данными, и подбирать лейблы, что является простым случаем conditional program generation:
Простые кейсы
Не обладая интуицией или глубоким пониманием логики работы программы, система может выявлять только простые случаи сбоев программы (например, параметры которые приводят к сообщениях об ошибках), в то же время остаются кейсы, которые могут быть выявлены только программистом.
Ограниченный набор логируемых параметров
Легко логировать и анализировать нейросетью примитивные типы (строчки, цифры), сложнее логировать и анализировать объекты.
Выявление простых взаимосвязей
Соответственно, легко выявлять простые взаимосвязи в простых данных. Все вышеперечисленное подразумевает, что, на данный момент, валидация и доработка автоматических тестов происходит вручную.
Перспективы
Главное направление развития системы — увеличение количества и сложности распознаваемых паттернов.
В случае интереса, буду рад обсудить более подробно — email to nayname@gmail.com
Автор: Fedor11111
