От ручного тестирования до запусков в Docker: наш поиск идеального процесса

Меня зовут Татьяна Головкина. Я руковожу группой тестирования решений 1С в департаменте ERP и учетных систем Ozon. В сфере тестирования работаю более 10 лет. Начала со специалиста по тестированию и пришла к текущей позиции руководителя группы.

Ручное тестирование

История становления тестирования во многих компаниях одинакова: изначально его нет вовсе. По мере роста количества доработок появляется ручное тестирование, которое поначалу применяется выборочно – только для отдельных задач, а не для всего объема работ.

Рассмотрим, как это происходит:

1. Разработчик. Первым шагом является ручное тестирование кода самим разработчиком. Он выполняет задачу и проверяет ее работоспособность.

2. Аналитики. Затем к тестированию подключаются аналитики. Они также вручную проверяют результат разработки на соответствие требованиям, описанным в техническом задании.

3. Специалисты по тестированию. Если в команде уже есть специалисты по тестированию, то часть задач переходит к ним. Но и они тестируют вручную.

Казалось бы, все хорошо: команда пишет, тестирует, разрабатывает и анализирует. Но чем больше становится объем задач, тем больше не хватает времени. Полностью протестировать весь объем задач становится невозможным. В этот момент начинаешь задумываться, что необходимо автоматизировать эти рутинные проверки и освободить время для других задач.

Что нас сподвигло задуматься об автоматизации:

• Необходимость регулярных проверок.

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

• Объем работ большой, он постоянно увеличивается, а свободных ресурсов не хватает.

• Хочется исключить человеческий фактор из процесса постоянно повторяющихся одинаковых проверок.

• Сокращение сроков выполнения регулярных проверок.

Мы начали анализировать: что у нас есть для того, чтобы начать внедрять автоматизацию.

Чем мы располагали в самом начале:

• Windows-сервер с зарегистрированным GitLab Runner.

• У каждой конфигурации был свой GitLab-репозиторий для ведения разработки.

• Сборочная линия, настроенная для доставки релизов в продуктовую среду.

• Рабочий SonarQube, на замечания которого никто не обращал внимания.

Первые автотесты

Нам предстояло проанализировать имеющиеся инструменты и решить, какой из них подходит для быстрого старта. Что использовать первым: тестер, сценарное тестирование, Vanessa-ADD, Vanessa Automation? Нам требовалось быстрое решение для проверки критически важного функционала «здесь и сейчас». Выбор пал на Vanessa-ADD, а точнее на ее компонент xddTestRunner, предназначенный для запуска дымовых тестов.

Причины выбора Vanessa-ADD:

1. Быстрый старт. Vanessa-ADD не предъявляет специальных требований для запуска в CI-контуре. Это обеспечивало быстрый старт с минимальными усилиями.

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

3. Готовые тесты. В Vanessa-ADD предоставляется готовый набор универсальных дымовых тестов для основных проверок критичного функционала: проведение документов, проверка проводок (до/после), печатные формы, макеты СКД, запись элементов и групп справочников. Без лишних усилий мы получаем готовый набор полезных проверок.

Интеграция в CI (GitLab)

Затем мы приступили к решению вопроса о том, как интегрировать тексты в CI контур. Мы воспользовались GitLab CI и работающим Windows-сервером с зарегистрированным на нем gitlab-runner. На сервере уже был установлен OneScript с нужными библиотеками, а в vanessa-runner есть встроенные команды, позволяющие запускать тесты (в том числе и тесты Vanessa-add).

Ниже представлена наша джоба для их выполнения:

Команда vrunner xunit, отвечающая за запуск дымовых тестов, очень компактна и легко составляется:

Команде передается информация о базе, к которой мы будем подключаться, и информация о пользователе, под которым будет запускаться сеанс 1С. Для пользователя, под которым запускается vanessa-add, должны быть выданы полные права, права на открытие внешних обработок и снята защита от опасных действий.

Были ли какие-то сложности? А куда же без них

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

Кроме того, не во всех конфигурациях тесты запустились сразу. У нас есть некоторые особенности в разработке, из-за которых тесты пришлось адаптировать.

Результаты

За короткое время мы получили хороший набор тестов, который закрывает основные проблемы. Главное – эти тесты запускаются автоматически, без ручных усилий. Нам не нужно выделять сотрудника, который будет постоянно осуществлять проверку. Мы просто приходим утром на работу, открываем отчет и смотрим результаты.

Сейчас мы используем Vanessa-ADD во многих конфигурациях, дорабатываем эти дымовые тесты и пишем свои – под наши определенные потребности.

Сценарные автотесты с Vanessa Automation

Что было дальше? У нас много конфигураций на управляемых формах. Мы пришли к выводу, что нужно проверять, как пользователи работают в 1С: нажимают кнопки, выполняют действия и бизнес-процессы. Мы не искали инструмент, а сразу знали, что тут нам подходит Vanessa Automation. Она как раз предназначена для функционального тестирования. У нее большое сообщество, и она активно развивается.

Есть определенные особенности, которые следует учитывать при использовании Vanessa Automation. Это обязательные условия, которые нужно знать:

• Зарегистрированный на сервере runner (Jenkins или GitLab Runner) должен запускаться как приложение, а не как служба.

• Нельзя подключаться к серверу по RDP, иначе вместо скриншотов с ошибками получим черный экран. Нужно использовать VNC или перезагружать сервер перед запуском тестов.

• Требуется настроить автовход под пользователем ОС с последующим запуском runner (агента) как приложения.

Эти особенности повлекли за собой выделение отдельной виртуальной машины для запуска сценарных тестов, где были сделаны необходимые настройки для корректной работы Vanessa-automation. Вмешательство в инфраструктуру рабочего сервера было неприемлемо, так как оно могло стать причиной проблем и простоев в сборках релизов. В результате два вида тестов разделились и выполнялись на разных серверах и раннерах.

Интеграция в CI

С запуском в CI особых проблем не возникло. У Vanessa Runner есть команда vrunner vanessa для запуска сценарных тестов:

В строке можно передать файл с настройками:

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

Сложности, с которыми мы столкнулись:

• Необходимо знать особенности настройки окружения, иначе Vanessa Automation не будет работать.

• Необходимы знания для написания сценарных тестов на языке Gherkin.

• Необходимо поддерживать сценарные тесты. Они не универсальны. Сценарные тесты предназначены для определенного функционала и проверки его работы. Если в код были внесены изменения, также нужно изменять тесты.

• Нужно выделять время на разбор и анализ отчетов о прохождении тестов.

• Тесты выполняются дольше, потому что все действия выполняются на клиенте: выбор кнопок, запись, проведение и другие операции. Из-за этого время выполнения увеличивается.

Результат, который получили в итоге:

• Возможность проверять конкретные действия пользователя в системе и результат их выполнения.

• Возможность описания любых проверок и действий пользователя.

• Тесты запускаются автономно без участия человека. Все выполняется по расписанию в CI-контуре. Остается только просматривать готовый отчет.

Unit-тесты с YAxUnit

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

Какие сложности мы выявили:

• Код, который очень сложно поддается тестированию.

• Необходимость рефакторинга перед написанием тестов.

• Команда не обладала необходимыми знаниями. Один человек передавал знания всем остальным.

• В планирование разработки пришлось закладывать время на создание юнит-тестов для нового функционала.

• Пришлось выделять ресурсы на покрытие юнит-тестами уже разработанного функционала.

Что хотели получить от внедрения юнит-тестов:

• быстрые, точечные проверки кода;

• чистый код, который легко читать и поддерживать;

• возможность проверять код на этапе разработки;

• возможность запускать тесты на управляемых и обычных формах.

YAxUnit удовлетворял всем нашим потребностям.

Интеграция в CI

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

За запуск юнит-тестов отвечает строка:

Команде run передаются параметры подключения к информационной базе, пользователь, команда запуска YAxUnit и файл с настройками. Благодаря этому мы получаем точечные результаты, находим ошибки.

Отчеты о пройденных автотестах

Для просмотра результатов всех тестов мы используем TestOps. Как это выглядит:

Здесь есть возможность просмотреть все запуски за определенный период. Они хранятся в общем списке. Также можно добавить другую тестовую документацию, например, ручные тест-кейсы. Можно помечать запуски тегами: у меня VANESSA – это отчет о сценарном тестировании, XUNIT – отчет по дымовому тестированию.

Можно углубиться в отчет и посмотреть статистику:

Здесь видно процентное соотношение успешных тестов. Из общего количества тестов 98% прошли успешно.

Можно пойти еще глубже – увидеть конкретный тест и какая по нему была ошибка. Для дымовых тестов:

Для сценарных тестов также есть скриншоты, где была выявлена ошибка:

Анализ покрытия кода тестами с Coverage41С

Несмотря на активное тестирование множества конфигураций, у нас возник вопрос: что именно мы тестируем, в каком объеме, какой процент кода покрыт? Возможно, мы проверяем не самые важные участки? Для получения ответов мы обратились к анализу покрытия при помощи инструмента Coverage41С.

Существуют разные варианты оценки покрытия:

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

• По критичному функционалу: аналогичное разделение на критически важные компоненты и анализ их тестирования.

• По коду: оценка степени покрытия тестами всего кода конфигурации.

Нам были важны конкретные цифры покрытия разрабатываемых и изменяемых компонентов.

Требования для запуска

Для работы инструмента Coverage41С необходимы:

• сама утилита Coverage41С;

• установленная EDT либо еe библиотеки (путь к библиотекам нужно прописать в переменной окружения EDT_LOCATION);

• установленная Java;

• включенная отладка по HTTP;

• настроенный анализ проекта в SonarQube или другой инструмент, способный работать с итоговым файлом покрытия.

Сложности, с которыми мы столкнулись при внедрении инструмента:

• Хотя информацию в интернете можно было найти, реального опыта работы с Coverage41C не было.

• Информации в интернете мало. Имеющаяся информация не подходит под инструменты, с которыми мы работаем. Например, скрипты были на Bash, а мы использовали PowerShell; или примеры предназначались для файловых баз, а у нас используются клиент-серверные.

• При запуске в CI нужно, чтобы анализ покрытия работал в фоне и не блокировал дальнейшие шаги.

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

• По окончанию тестирования клиенты иногда не закрывались, оставались активными. Это приводило к зависанию отладки, невозможности повторного запуска. Приходилось перезагружать сервер отладки. В итоге результат покрытия отсутствовал.

• На клиент-серверных базах результирующий файл иногда содержал только клиентский или только серверный код. Данные о покрытии также были недостоверными.

Интеграция в CI

Мы преодолели проблемы, написав джобу для CI. Скрипт получился большим и непонятным:

Логика работы скрипта:

1. Запуск анализа покрытия с необходимыми параметрами,

2. Циклическая проверка статуса успешного старта анализа и успешной вычитки файлов конфигурации,

3. Выполнение тестов,

4. Остановка покрытия,

5. Проверка корректности остановки и формирования файла с покрытием.

Не обошлось и без дополнительного скрипта. Он реализован при помощи OneScript и принудительно отправляет команду по http debug-серверу об отключении замеров, даже если какие-то клиенты не закрылись.

Визуализация результатов

Результаты покрытия видны в SonarQube. Появляется блок, отвечающий за покрытие. Виден процент покрытия кода:

Можно посмотреть, какие строки кода участвовали в тестировании. Красным отмечены строки, которые не тестируются:

Зеленым выделяются тестируемые строки:

Какой результат мы получили? Тестов много, а результат покрытия минимальный.

Причины низкого покрытия:

• Конфигурации очень большие, много кода снято с поддержки (хотя мы его не меняем).

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

Что мы предприняли, чтобы эту ситуацию изменить:

1. Уменьшили кодовую базу. Вернули замки на код вендора, который мы не изменяем.

2. Сфокусировались на покрытии исключительно дорабатываемого или разрабатываемого кода, поскольку код вендора уже протестирован и стабилен.

3. Стали целенаправленно анализировать непокрытые участки нашего кода и разрабатывать для них уникальные тесты.

Здесь нужно быть осторожными: исключение кода вендора может привести к снижению общего процента покрытия в отчетности, так как этот код мог частично покрываться тестами. Хотя абсолютное покрытие релевантного кода может расти, видимый прирост общего покрытия будет меньше ожидаемого.

Уход в контейнеры

Количество тестов и конфигураций растет неустанно. Мы стали сталкиваться с нехваткой ресурсов. Самым простым способом решить эту проблему было уйти в контейнеры.

Что нас к этому подтолкнуло:

• Доступность GitLab Runner. На Windows-сервере очень большой поток задач, тесты остаются на заднем плане, вызывая длительное ожидание очереди.

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

• Борьба за ресурсы. Рост числа процессов требовал постоянного увеличения выделяемых ресурсов.

• Зависимость от других команд. Мы хотели уйти от необходимости согласовывать свои задачи с задачами других команд.

Переход на контейнеры помог устранить перечисленные проблемы. Вместе с тем нам пришлось изменить свою работу. Что мы поменяли:

• Изменили все скрипты, чтобы они могли работать не только под операционной системой Windows, но и под Unix-системами.

• Доработали обработки и файлы настроек для возможности запуска под разными операционными системами.

• Переписали скрипты в джобах с PowerShell на Bash.

• Внесли изменения в код конфигураций, чтобы отказаться от внешних компонент, которые используются только на Windows.

• Выделили большое количество времени на отладку и тестирование нового образа, который планировали использовать.

Bash vs PowerShell

Для примера – сравнение скрипта на PowerShell и Bash:

В примере, где анализ покрытия запускается под PowerShell, мы видим, что строка запуска выглядит намного больше. Под Bash она более компактная и читаемая. Передача аргументов и параметров запуска анализа покрытия выглядит более понятно.

Чтобы запустить процесс в фоне на PowerShell, нужно передать определенные команды. А чтобы запустить на Bash, необходимо передать только путь к самому каверджу (coverage) и поставить в конце знак амперсанд (&). Это запустит процесс в фоне.

Что мы получили в результате:

1. Достигнута параллельность на 100%.

2. Достигнута централизованная поддержка на всех уровнях, начиная от физического и заканчивая прикладным.

3. Достигнута возможность увеличения ресурсов «on demand» (по требованию).

Pipelines. Обзор процесса
Процесс начинается с обязательного обновления тестовых баз. Сразу после этого запускаются юнит-тесты (в тех конфигурациях, где они разработаны). Результаты этих тестов незамедлительно отправляются в рабочий мессенджер со ссылками на ответ, с уведомлением ответственных.

Далее происходит ключевой этап: параллельный запуск трех видов проверок – сценарных тестов, синтаксического контроля кода и дымовых тестов. Также, как и по юнит-тестам, по завершении каждого блока тестов отправляется отчет.

Финальный этап зависит от типа запуска:

• Если тесты выполнялись без анализа покрытия кода, пайплайн завершает работу.

• Если запуск включал анализ покрытия, выполняется дополнительная джоба – передача собранных данных в SonarQube. После успешной отправки данных процесс завершается.

К чему нужно быть готовыми, вставая на путь автоматизации

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

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

Что можно получить в результате автоматизации

Процесс становится полностью автономным. Можно реализовать любые проверки, которые будут выполняться регулярно и без ручного вмешательства. При использовании Docker-образов процессы выполняются параллельно, без зависимости от доступности ресурсов или раннеров.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.