В поисках багов 24/7: что такое автотесты и как они помогают искать ошибки в приложениях

Как работают автотесты 

Любой тест — это, прежде всего, проверка продукта на соответствие требованиям. В широком смысле тесты бывают двух видов: ручные проводятся при непосредственном участие специалиста по тестированию, автотесты — без участия специалиста, автоматизировано. Структура и логика в обоих случаях одинаковая, только во втором случае на определенном этапе применяются средства автоматизации, после чего тестирование выполняется машинным кодом либо в инструментах Continuous integration/Continuous delivery (для краткости — CI/CD). 

Автотесты нужны, чтобы проверять целостность системы при добавлении в нее нового функционала. В частности, существует так называемая регрессионная модель, которая при добавлении новых фичей в продукт проверяет, не поломались ли старые. Это освобождает специалистов по тестированию от рутинных и довольно объемных проверок. Если тестировщики успели написать автотесты на новый функционал, остается только запустить набор автотестов, проверить, что все работает корректно, и дать добро на запуск функционала в прод. 

Автотесты не берутся ниоткуда, их пишут на основании каких-то артефактов — чек-листов, тестовых сценариев. Чтобы провести тест, в команде должен быть ручной тестировщик, создающий тестовые сценарии и составляющий чек-листы. Кроме того, нужен специалист по автоматизации, который на основании данных от тестировщика пишет код, выполняющий проверки. Иногда тестировщик и специалист по автоматизации — это один и тот же человек. Также нужны специальные инструменты: фреймворки для разработки и запуска тестов, инструменты для дальнейшего цикличного прогона тестов с машинными средствами, не зависящими от человека. 

Старая школа автотестов

Практика проведения автотестов, которая сейчас используется повсеместно, является олдскульной: человек проанализировал технические требования, на их основании написал проверки — тестовые сценарии либо чек-листы, а затем на их основании написал автоматизированный сценарий проверки. Тестирование такого формата появилось еще в 80-х, и вот уже более 40 лет этот метод активно применяется. 

Преимущества олдскульного подхода в том, что он экономит время и силы для других задач. Этот метод уменьшает энтропию в тестировании, так как постоянное увеличение ручной регрессионной модели может привести со временем к росту числа необходимых ручных тестировщиков. Если все представлено в виде автотестов, достаточно нажать несколько кнопок и запустить процесс проверки, что все хорошо. Недостаток такого подхода — в том, что разработчики кода автотестов стоят недешево, содержание команды таких специалистов может дорого обходиться бизнесу. Кроме того, процесс написания автотеста не всегда бывает быстрым и простым, поэтому важно оценить экономическую целесообразность перед запуском автотеста — некоторые проверки проще и дешевле выполнять вручную. 

Кому это нужно 

Такие автотесты подходят для уже устоявшейся команды с выстроенными процессами, у которой есть четкое понимание, что продукт будет расти и развиваться, новый функционал будет постоянно добавляться, и его нужно будет тестировать. Если такая команда не хочет раздувать штат ручных тестировщиков, ей проще все автоматизировать. Если в команде какая-то часть продукта уже покрыта автотестами и хочется поддерживать высокий уровень качества тестов, то тоже имеет смысл задуматься об автотестах. 

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

Этапы олдскульного автотеста 

Анализ документации

Системные и продуктовые аналитики после получения заявки на реализацию функционала от бизнеса выясняют все подробности. Так получается артефакт, называемый технической постановкой. На основании этой постановки разработчики реализуют бизнес-логику в виде кода, а тестировщики анализируют этот артефакт, проверяя, нет ли в нем противоречий и неточностей. 

Чек-листы и тестовые сценарии

На основании одобренной документации придумывается сценарий будущей проверки нового функционала. На выходе создаются либо чек-листы, либо тестовые сценарии. Первые обычно нужны для ручного тестирования, вторые — для автотестов. 

Исследовательское тестирование 

Этот этап применим к случаям, когда тестировщик только знакомится с продуктом или — при отсутствии в команде аналитика — рассматривает его реакцию на взаимодействия, не описанные в документации. Цель в таком случае — не проверить корректность работы конкретного функционала, а, скорее, исследовать продукт и его лимиты. 

Автоматизация тестирования 

Когда один и тот же набор проверок руками выполняется регулярно, имеет смысл его автоматизировать. Как уже было сказано выше, в некоторых случаях тестировщик справляется с этой задачей сам, в других случаях требуется помощь специалиста по автоматизации, чтобы встроить их в пайплайны инструментов CI/CD и запускать с нужной регулярностью. 

Ночные прогоны регресса 

Чтобы убедиться, что продукт работает как надо, часто проводят так называемые smoke-тесты (дымовые тесты). Они проверяют, что система завелась и работает стабильно. Такие проверки обычно проводятся по ночам, когда в систему никто ничего не вливает. 

Тренд по исправности продукта 

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

Автотесты новой волны

Есть и другой подход к проведению автотестов, более современный и прогрессивный. Речь о проверках с использованием искусственного интеллекта. Крупные компании могут позволить себе развернуть внутри своего контура какой-то инструмент, использующий ИИ, и привязать этот инструмент к собственным инструментам разработки и инструментам CI/CD. Такой инновационный инструмент на базе ИИ получает через консоль запрос на проведение автотеста, собирает продукт на тестовый стенд, запускает автотест и присылает результаты. 

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

Преимущества такого подхода — безусловная экономия на специалистах по тест-дизайну, по написанию кода. Почти всех их может заменить оператор, который пишет корректные запросы к ИИ. Из недостатков — такой ИИ нужно сначала собрать, обучить на примерах моделей, подготовить к работе. Это может быть небыстро и недешево. 

Автотесты с ИИ подойдут практически для любой команды, если, конечно, у этой команды уже есть обученный инструмент. Такие проверки можно проводить параллельно с тестами, проводимыми людьми, также можно поручать ИИ сразу несколько задач. Это удобно как для стартапов, так и для сложившихся команд с большим опытом. Но далеко не у всех есть ресурсы создавать такой инструмент на базе ИИ. 

Этапы автотеста с ИИ

Конвертация требований заказчика в техническую документацию через инструменты ИИ

На этом этапе можно попробовать не пользоваться услугами аналитика и самостоятельно сформулировать запрос для ИИ на базе требований заказчика, а затем при помощи того же инструмента ИИ сгенерировать техническую документацию, необходимую для начала автотеста. 

Проектирование архитектуры с помощью нейросетей

Документацию из предыдущего пункта можно использовать при составлении запроса к инструменту ИИ, чтобы спроектировать архитектуру на необходимое количество пользователей и построить схему их взаимодействия. На выходе корректно обученный и настроенный инструмент выдаст перечень необходимых инструментов для построения заданной архитектурной модели. 

Генерация сценариев проверки на основе документации, «скормленной» нейросетям

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

Генерация кода автотестов бэкенда на основании сценариев через нейросеть 

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

UI-тестирование с использованием Machine Learning, обучение на основе скриншотов и сценариев 

На этом этапе у нас есть некоторые сценарии использования нашего продукта, и мы хотим протестировать интерфейс. Инструмент ИИ анализирует скриншоты нашего интерфейса и генерирует сценарии проверки, которые могли бы помочь обнаружить баги в продукте. На выходе мы снова получаем код и список необходимых инструментов, либо код и скриншоты эталонных состояний. 

Где мы сейчас

На данный момент наша команда находится в промежуточной стадии — уже не все тесты выполняются олдскульно, но еще далеко не везде в процессы интегрирован ИИ. Дело в том, что все новые инструменты, в том числе ИИ, проходят проверку службой безопасности. До завершения проверки их нельзя применять на mission critical-продуктах. Поэтому сейчас ИИ в автотесты у нас добавлен только там, где пользоваться такими инструментами разрешено — в изолированных контурах.

Если говорить в общем, все наши проекты покрыты автотестами, которые регулярно выполняются в инструментах CI/CD по ночам и перед релизами. В активной стадии находится исследование внедрения инструментов ИИ, в частности — существующие тестовые сценарии редактируются при помощи искусственного интеллекта, с одной стороны, обучая его под нашу специфику, с другой стороны, — приводя все к единому, читаемому варианту. 

На проектах, где применимо UI-тестирование, ведется внедрение инструмента AI/ML для скриншотного тестирования и нахождения элементов, а также для дальнейшего применения элементов в создании UI-тестов. 

Прогресс не стоит на месте, и на смену отлаженным олдскульным подходам и инструментам приходят новые технологии. Да, тестировать можно и по-старому, с регулярным вливанием человеческих ресурсов в этот подход. Но можно приложить усилия, освоив новые инструменты, и увеличить скорость производства тестов.

Восстание машин 

Несмотря на широкое распространение ИИ, шансы на то, что машины полностью заменят тестировщиков в обозримом будущем, невелики. Современные инструменты на базе ИИ могут выдавать определенные артефакты — технические постановки, тестовые сценарии, но по-прежнему необходим квалифицированный человек, который адаптирует материалы, сгенерированные нейросетью, обработает их, подготовит к работе. 

Некоторое подобие нейросетей появилось еще в 60-х, и уже тогда многие говорили, что всех разработчиков вот-вот заменят роботы. Как показала практика, эти прогнозы оказались далеки от реальности. На деле появляются новые и новые специальности, с новым уровнем подготовки. Однажды аналитиков, разработчиков, инженеров DevOps-практик, тестировщиков все-таки заменит ИИ, но появятся новые профессии. Например, разработчики промптов для инструментов на базе ИИ, которые будут писать грамотные и качественные запросы к этим инструментам, максимизируя их эффективность. 

Читать далее:

Анализ самого старого скелета в Бразилии показал, куда исчезли древние строители

Главную идею Эйнштейна хотят проверить еще раз: как это изменит физику

Распад суперконтинентов выносит алмазы на поверхность Земли

^{Обложка: Wallpaperflare. Сведения о лицензии}