Метод для автоматизации тестирования и контроля качества программных продуктов Targeted Test Selection (T-TS) был разработан исследователями R&D-центра Т-Технологий во Владивостоке. Он позволяет запускать лишь часть тестов, но при этом находить почти все потенциальные ошибки в коде.
Как объяснили разработчики, в крупных компаниях, постоянно выпускающих обновления для программного обеспечения, тестирование каждой новой версии становится все более длительным и требует большого объема ресурсов. На проверку уходят десятки часов, тратится мощность сотен серверов.
Новый метод позволяет запускать лишь около 15 процентов от полного набора тестов, но при этом он находит более 95 процентов возможных ошибок, вызванных изменениями, которые вносятся в программу. Это значит, что разработчики получают обратную связь о проблемах гораздо быстрее, а исправление багов, или ошибок, обходится значительно дешевле.
Разработка, в частности, уже была протестирована на программной инфраструктуре Т-Банка, где ежедневно вносятся десятки тысяч изменений в коде и проводятся тысячи тестов.
Зачем нужны тесты
Мало кто задумывается, что сложные IT-системы, которыми многие уже привыкли пользоваться каждый день, нуждаются в постоянном обновлении. В сфере финансовых технологий, логистики, интернет-торговли и маркетплейсов, телекоммуникаций, государственных онлайн-сервисов обновление программного обеспечения происходит ежедневно. Каждая минута простоя при этом обходится дорого, а быстрая обратная связь, которую получают разработчики программ, экономит деньги компании или бюджета и снижает риск появления ошибок.
Обновление компьютерной программы можно сравнить с ремонтом в большом доме. Нередко бывает так: стоит подкрутить кран на кухне, как потечет труба в ванной. Тесты в IT-сфере - это плановая "проверка комнат", как при ремонте. Они позволяют убедиться, что при внесении изменений ничего не было сломано ни в соседних комнатах, ни в других частях дома, прежде чем пустить людей внутрь.
Эти проверки становятся все более дорогими и сложными, поскольку IT-системы растут, у них появляется все больше функций и связей между ними. При этом возникает необходимость довольно часто выпускать новые релизы, или обновления. Крупному бизнесу зачастую требуется обновлять программное обеспечение каждый день, а иногда и несколько раз в день. При таком высоком темпе на полную проверку всей системы попросту не хватает времени. К тому же нужно проверить множество интеграций, или дополнительных сервисов и приложений, таких как платежи, доставки и так далее. Процесс осложняется еще и тем, что существуют различные типы устройств - смартфоны, планшеты, ноутбуки, разные операционное системы, интернет-браузеры, с которыми необходимо проводить тесты на совместимость. При этом каждая новая версия программы должна быть безопасной и стабильной.
Чем отличается новый метод
Авторы исследования сравнивают обычное автоматическое тестирование с работой станции техобслуживания, где проверяется одна деталь автомобиля за другой. Такой подход гарантирует безопасность, но его эффективность значительно снижается из-за больших затрат времени и денег. В случае с использованием метода автомеханики будут заранее знать, какие детали может затронуть ремонт, и начнут проверку именно с них.
В мире уже предложены способы ускорить процесс проведения тестов, но чаще всего они завязаны на так называемых картах покрытия кода. Они показывают, какой процент исходного кода выполняется во время запуска тестирования, и помогают понять, насколько хорошо проверяются различные части кода. Чтобы такие карты покрытия оставались актуальными, нужны отдельные ресурсы и время на их обновление при поступлении малейших изменений.
Также мировые разработчики пытаются ускорить процесс проведение тестов с помощью машинного обучения, но все же большинство решений опирается на традиционные методы, такие как карты покрытия. Новый метод, напротив, позволяет отказаться от дорогостоящего сопоставления кода, а всю необходимую информация взять из истории самого хранилища данных, или репозитория.
Система T-TS не нуждается в картах покрытия кода и использует статистику прошлых изменений. Она самостоятельно анализирует, кто и какие именно файлы изменил в коде, сколько раз это происходило и как часто эти изменения приводили к ошибкам. Для оценки изменений используется принцип "мешка слов" (bag-of-words), широко применяемый в поисковых системах. Они представляют текст в виде набора ("мешка") отдельных слов и не учитывают порядок их следования. Важно только, какие это слова и сколько раз они встречаются. В данном методе каждой единицей в "мешке" становится конкретный файл или модуль программы. Кроме того, система отдельно учитывает ближайшие к тестам файлы, еще больше адаптируясь к вносимым изменениям.
По подобному принципу работает фильтрация электронной почты. Если письма с определенного адреса часто оказывались спамом, то почтовая система проверит их в первую очередь, не тратя время на просмотр всей переписки. Так же происходит и с тестами: система сама прогнозирует, какие из них с наибольшей вероятностью обнаружат ошибки при новых изменениях, опираясь на опыт прошлых сбоев. Новый метод "учится" на истории проекта, анализирует, где чаще всего происходили сбои. За счет этого запускается меньше тестов, экономятся ресурсы и время, а в результате разработчики получают почти тот же уровень обнаружения ошибок.
Открытие доступно для всех
Результаты своей работы авторы исследования опубликовали в открытом доступе. Они отмечают, что метод совместим с любым языком программирования и не требует уникальной настройки под каждый проект. Его можно интегрировать в инфраструктуру любой компании, работающей по принципу CI/CD - непрерывной автоматизированной разработки и обновления программного обеспечения, где критично важна скорость выпуска новых релизов.
На практике внедрение нового метода позволяет компаниям значительно сократить время, которое требуется на исполнение тестового конвейера. Разработчики быстрее получают сведения об ошибках, а значит, их проще и дешевле исправить. Метод работает даже при очень больших и разветвленных кодовых базах данных. К примеру, его могут масштабировать и внедрять крупные финтехкомпании. Поскольку он доступен в виде открытого исходного кода, его можно легко интегрировать в бизнес и создавать свои ИИ-продукты. Разработчикам предоставлена возможность настройки баланса между скоростью и полнотой контроля качества. Это особенно актуально при необходимости быстрого выпуска обновлений программного обеспечения.
Так, в сфере транспорта и логистики существуют сложные системы управления складами, терминалами и перевозками, которые учитывают расписание, маршрутизацию, отслеживания доставок, а также интеграцию с таможней. Здесь изменения выходят часто, а простой недопустим, он приведет к остановке всего бизнеса. Решение дальневосточных специалистов сокращает длительность проверок, поэтому обновления дойдут до пользователей быстрее и будут работать стабильно.
Для онлайн-торговли и маркетплейсов требуется постоянное обновление каталогов, цен, акций, сведений о покупках, платежах, доставках. Каждый день выпускаются объемные релизы, на тестирование остается все меньше времени.
В банковской сфере и финтехе предъявляются высокие требования к качеству и безопасности операций и всех других действий, существует множество дополнительных сервисов и приложений. Новый метод помогает быстрее делать проверки критически важных сценариев.
Также его можно применять в сфере государственных сервисов, где в обновлениях нуждаются порталы услуг, реестры, системы документооборота, транспортные платформы "умного города", а также в области здравоохранения, образовательных технологий, подбора персонала.