Меня зовут Татьяна Головкина. Я руковожу группой тестирования решений 1С в департаменте ERP и учетных систем Ozon. В сфере тестирования работаю более 10 лет. Начала со специалиста по тестированию и пришла к текущей позиции руководителя группы.
Ручное тестирование
История становления тестирования во многих компаниях одинакова: изначально его нет вовсе. По мере роста количества доработок появляется ручное тестирование, которое поначалу применяется выборочно – только для отдельных задач, а не для всего объема работ.
Рассмотрим, как это происходит:
-
Разработчик. Первым шагом является ручное тестирование кода самим разработчиком. Он выполняет задачу и проверяет ее работоспособность.
-
Аналитики. Затем к тестированию подключаются аналитики. Они также вручную проверяют результат разработки на соответствие требованиям, описанным в техническом задании.
-
Специалисты по тестированию. Если в команде уже есть специалисты по тестированию, то часть задач переходит к ним. Но и они тестируют вручную.
Казалось бы, все хорошо: команда пишет, тестирует, разрабатывает и анализирует. Но чем больше становится объем задач, тем больше не хватает времени. Полностью протестировать весь объем задач становится невозможным. В этот момент начинаешь задумываться, что необходимо автоматизировать эти рутинные проверки и освободить время для других задач.
Что нас сподвигло задуматься об автоматизации:
-
Необходимость регулярных проверок.
-
У каждого продукта есть важный функционал, который пользователь использует постоянно. Такой функционал нужно регулярно проверять при каждом релизе и даже чаще.
-
Объем работ большой, он постоянно увеличивается, а свободных ресурсов не хватает.
-
Хочется исключить человеческий фактор из процесса постоянно повторяющихся одинаковых проверок.
-
Сокращение сроков выполнения регулярных проверок.
Мы начали анализировать: что у нас есть для того, чтобы начать внедрять автоматизацию.
Чем мы располагали в самом начале:
-
Windows-сервер с зарегистрированным GitLab Runner.
-
У каждой конфигурации был свой GitLab-репозиторий для ведения разработки.
-
Сборочная линия, настроенная для доставки релизов в продуктовую среду.
-
Рабочий SonarQube, на замечания которого никто не обращал внимания.
Первые автотесты
Нам предстояло проанализировать имеющиеся инструменты и решить, какой из них подходит для быстрого старта. Что использовать первым: тестер, сценарное тестирование, Vanessa-ADD, Vanessa Automation? Нам требовалось быстрое решение для проверки критически важного функционала «здесь и сейчас». Выбор пал на Vanessa-ADD, а точнее на ее компонент xddTestRunner, предназначенный для запуска дымовых тестов.
Причины выбора Vanessa-ADD:
-
Быстрый старт. Vanessa-ADD не предъявляет специальных требований для запуска в CI-контуре. Это обеспечивало быстрый старт с минимальными усилиями.
-
Масштабируемость. Так как у нас много конфигураций и они разные, соответственно, нам требовалась возможность запустить тесты во всех из них. Еще один критерий: тесты должны работать не только на управляемых формах, но и на обычных.
-
Готовые тесты. В 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. Скрипт получился большим и непонятным:
|
|
Логика работы скрипта:
-
Запуск анализа покрытия с необходимыми параметрами,
-
Циклическая проверка статуса успешного старта анализа и успешной вычитки файлов конфигурации,
-
Выполнение тестов,
-
Остановка покрытия,
-
Проверка корректности остановки и формирования файла с покрытием.
Не обошлось и без дополнительного скрипта. Он реализован при помощи OneScript и принудительно отправляет команду по http debug-серверу об отключении замеров, даже если какие-то клиенты не закрылись.
Визуализация результатов
Результаты покрытия видны в SonarQube. Появляется блок, отвечающий за покрытие. Виден процент покрытия кода:
Можно посмотреть, какие строки кода участвовали в тестировании. Красным отмечены строки, которые не тестируются:
Зеленым выделяются тестируемые строки:
Какой результат мы получили? Тестов много, а результат покрытия минимальный.
Причины низкого покрытия:
-
Конфигурации очень большие, много кода снято с поддержки (хотя мы его не меняем).
-
Тесты повторяют проверки одних и тех же участков кода. Например, проверка проведения документов в дымовых тестах перекрывается аналогичными проверками в сценарных тестах, не увеличивая общее покрытие.
Что мы предприняли, чтобы эту ситуацию изменить:
-
Уменьшили кодовую базу. Вернули замки на код вендора, который мы не изменяем.
-
Сфокусировались на покрытии исключительно дорабатываемого или разрабатываемого кода, поскольку код вендора уже протестирован и стабилен.
-
Стали целенаправленно анализировать непокрытые участки нашего кода и разрабатывать для них уникальные тесты.
Здесь нужно быть осторожными: исключение кода вендора может привести к снижению общего процента покрытия в отчетности, так как этот код мог частично покрываться тестами. Хотя абсолютное покрытие релевантного кода может расти, видимый прирост общего покрытия будет меньше ожидаемого.
Уход в контейнеры
Количество тестов и конфигураций растет неустанно. Мы стали сталкиваться с нехваткой ресурсов. Самым простым способом решить эту проблему было уйти в контейнеры.
Что нас к этому подтолкнуло:
-
Доступность GitLab Runner. На Windows-сервере очень большой поток задач, тесты остаются на заднем плане, вызывая длительное ожидание очереди.
-
Параллельный запуск. Не было возможности параллельно запускать много потоков на разных конфигурациях. Хотелось, чтобы все тесты проходили за ночь, а утром мы видели результат тестирования и могли работать дальше.
-
Борьба за ресурсы. Рост числа процессов требовал постоянного увеличения выделяемых ресурсов.
-
Зависимость от других команд. Мы хотели уйти от необходимости согласовывать свои задачи с задачами других команд.
Переход на контейнеры помог устранить перечисленные проблемы. Вместе с тем нам пришлось изменить свою работу. Что мы поменяли:
-
Изменили все скрипты, чтобы они могли работать не только под операционной системой Windows, но и под Unix-системами.
-
Доработали обработки и файлы настроек для возможности запуска под разными операционными системами.
-
Переписали скрипты в джобах с PowerShell на Bash.
-
Внесли изменения в код конфигураций, чтобы отказаться от внешних компонент, которые используются только на Windows.
-
Выделили большое количество времени на отладку и тестирование нового образа, который планировали использовать.
Bash vs PowerShell
Для примера – сравнение скрипта на PowerShell и Bash:
|
|
|
|
В примере, где анализ покрытия запускается под PowerShell, мы видим, что строка запуска выглядит намного больше. Под Bash она более компактная и читаемая. Передача аргументов и параметров запуска анализа покрытия выглядит более понятно.
Чтобы запустить процесс в фоне на PowerShell, нужно передать определенные команды. А чтобы запустить на Bash, необходимо передать только путь к самому каверджу (coverage) и поставить в конце знак амперсанд (&). Это запустит процесс в фоне.
Что мы получили в результате:
-
Достигнута параллельность на 100%.
-
Достигнута централизованная поддержка на всех уровнях, начиная от физического и заканчивая прикладным.
-
Достигнута возможность увеличения ресурсов «on demand» (по требованию).
Pipelines. Обзор процесса
Процесс начинается с обязательного обновления тестовых баз. Сразу после этого запускаются юнит-тесты (в тех конфигурациях, где они разработаны). Результаты этих тестов незамедлительно отправляются в рабочий мессенджер со ссылками на ответ, с уведомлением ответственных.
Далее происходит ключевой этап: параллельный запуск трех видов проверок – сценарных тестов, синтаксического контроля кода и дымовых тестов. Также, как и по юнит-тестам, по завершении каждого блока тестов отправляется отчет.
Финальный этап зависит от типа запуска:
-
Если тесты выполнялись без анализа покрытия кода, пайплайн завершает работу.
-
Если запуск включал анализ покрытия, выполняется дополнительная джоба – передача собранных данных в SonarQube. После успешной отправки данных процесс завершается.
К чему нужно быть готовыми, вставая на путь автоматизации
Стоит учитывать, что специалисты по автотестированию стоят дорого, а те, кто разбирается в CI и могут настроить всю систему, обходятся еще дороже. Для успешной автоматизации требуются специализированные знания в области CI, разработки и тестирования. Кроме того, процесс внедрения, настройки и разработки занимает значительное количество времени.
Необходимо выделять ресурсы – как человеческие, так и технические – на поддержание этих процессов. Также придется менять уже устоявшиеся рабочие процедуры, а это может вызвать сопротивление со стороны коллег.
Что можно получить в результате автоматизации
Процесс становится полностью автономным. Можно реализовать любые проверки, которые будут выполняться регулярно и без ручного вмешательства. При использовании Docker-образов процессы выполняются параллельно, без зависимости от доступности ресурсов или раннеров.
Еще одним важным преимуществом является универсальность CI-скриптов, которые можно адаптировать под любые конфигурации. После внедрения автоматизации количество инцидентов и ошибок в продакшн-среде значительно сокращается. Наконец, сам процесс автоматизации открывает новые возможности для развития и оптимизации работы.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
