С 29 сентября по 2 октября 2023 года прошел осенний партнерский семинар от фирмы 1С. На нем было представлено два доклада по автоматизированному тестированию.
Первый доклад в рамках секции «Облака для бизнеса»:
Автоматизированное тестирование подсистемы Фреш (Козырев И. О., ведущий разработчик, 1С).
Второй доклад в рамках секции «Развитие 1С:Бухгалтерии»:
Выполнение тестов по расписанию (Рагузин А. Е., разработчик, 1С).
Первый доклад основан на инструменте «Vanessa Automation», а второй про «1С:Сценарное тестирование». Так как блог подразумевает тематическое разделение по инструментам для автоматизированного тестирования, то рассказ по данному мероприятию поделен на две части - каждый в подборке соответствующего инструментария. Если вы читаете данную статью из конкретной подборки, но хотите прочитать и про второй доклад, то это можно сделать перейдя к нему по соответствующей ссылке в наименовании доклада.
Сразу забегая вперед, надо отметить, что процесс по внедрению автоматизированного тестирования для всей подсистемы Фреш был сложным, долгим и занял около года: от идеи до ощутимого результата.
Для начала ответим на вопрос: для чего вообще использовать автоматизированное тестирование? Причин может быть много, но было выделено две основные:
- Улучшение качества продукта.
- Сокращение затрат времени на выпуск новых версий.
В качестве «двигателя» был выбран инструмент «Vanessa Automation» по нескольким причинам:
- Инструмент развивается уже очень давно и большими шагами.
- Большое количество материалов.
- Большое сообщество.
После выбора инструмента, приступили к первой реализации и столкнулись с рядом проблем. Во-первых, Фреш - это очень крупный продукт, который состоит из большого числа компонентов. Во-вторых, все компоненты между собой взаимосвязаны и реализованы на разных технологиях.
Решением данных проблем стал выбор технологии Docker и в частности инструмента full_fresh: набор скриптов, которые позволяют быстро поднять всю технологию в определенном настроенном состоянии.
Docker - это технология, которая позволяет упаковать в контейнер приложение со всем окружением и зависимостями, а затем доставить и запустить его в целевой системе.
Full_fresh - это внутренний проект, но есть аналог в свободном доступе https://github.com/1C-Company/docker_fresh
Выглядит это следующим образом: есть список контейнеров, каждый из которых отвечает за свое: сервер 1С, СУБД, веб-сервер и т.д. При помощи данной технологии очень быстро можно развернуть всю нужную инфраструктуру и начать выполнять тесты в ней.
После того как это было реализовано, столкнулись с новым рядом проблем:
- Один поток тестирования - это очень долго, так как количество тестов всегда растет.
- Время выполнения тестов стало очень большим, потому что тестируется каждый коммит, а не ночные сборки. В первую очередь, это сделано для того, чтобы можно было быстро определить кто «наследил»: не адаптировал тесты под свою новую функциональность либо своей функциональностью «разломал» что-то чужое.
Коммит (Commit) - это способ сохранения изменений в коде. Каждый commit содержит информацию о том, что было изменено в коде и кем были внесены эти изменения. Они позволяют разработчикам отслеживать изменения в своем (или чужом) коде и возвращаться к предыдущим версиям, если это необходимо.
- Так как все работает в Docker, то нет возможности видеть, что происходит в контейнерах. Это скрыто за несколькими слоями, и когда тесты падают по таймауту, то непонятно, что собственно произошло.
- Из предыдущего пункта вытекает сложность расследования падения тестов.
Решением стала следующая архитектура:
В качестве хранилища кода используется Gitlab, а в качестве движка для автоматизации CI/CD применяется Gitlab CI/CD.
Есть некоторое количество раннеров (runners). В каждом раннере используется технология Docker-in-Docker и внутри запускаются n-ое количество стендов Фреша, в которых выполняются тесты. В первую очередь, это позволяет горизонтально масштабироваться, т.е. как только количество тестов становится большим и скорость их прохождения уменьшается, то можно увеличить количество потоков, добавляя, например, «железо». Минус данного подхода в том, что постоянно нужно новое «железо», так как количество автотестов постоянно растет.
Раннер (gitlab runner) - приложение, в рамках которого выполняются задачи и которое можно развернуть на разных типах систем: Linux, macOS, Windows, Docker, Kubernetes и так далее.
Docker-in-Docker (или dind) позволяет разработчикам запускать контейнер Docker внутри уже работающего контейнера Docker для поддержки конвейеров CI/CD и создания изолированных контейнерных сред.
Процессы работы с коммитами выглядят приблизительно следующим образом: первая стадия - это построение (формируются cf-ки и dt-ки). Стоит уточнить, что dt-ки грузятся гораздо быстрее в базу, чем cf-ки, потому, когда речь идет об экономии времени, то лучше использовать их.
Затем идет статический анализ кода: соответствие стандартам 1C, собственные проверки и т.д.
А далее начинается процесс тестирования, в котором проверяется два варианта: английский и русский интерфейсы.
Само тестирование поделено на две части: инициализацию и непосредственно тестирование.
Это было сделано для ускорения и параллельности прохождения тестов.
Инициализация - это отдельный job (задача), где загружаются все компоненты, все cf-ки и dt-ки, создается новый стенд и выполняются тесты из категории «первоначальное заполнение». В данной категории происходят те же действия, которые бы выполнял администратор, настраивая новый Фреш: настраивается взаимодействие с информационными базами и т.д.
Далее данный стенд выключается, архивируется и отправляется в облачное хранилище. И в зависимости от настроек (как видно на слайде выше, для каждой конфигурации настраивается свое количество потоков для выполнения), происходит распараллеливание: каждый поток скачивает из облака данный стенд, разворачивает его и запускает в нем тесты.
На слайде выше показан пример процесса тестирования «Менеджера сервиса» в шесть потоков. Стадия инициализации - это однопоточное действие. А далее происходит следующее: есть три потока тестирования, а внутри каждого из них еще два. Соответственно внутри каждого раннера параллельно живут два стенда, в которых выполняются тесты.
Механизм построен таким образом, что каждый раз, после завершения тестов (при удачном результате), время их выполнения записывается в информационную систему. Это сделано для того, чтобы определить количество потоков и равномерно распределить по ним тесты так, чтобы все потоки завершились примерно в одно время.
Для расследования проблем, связанных с результатом выполнения тестов, было использовано туннелирование: из каждого контейнера «прокидывается» туннель к определенному серверу, что дает нам возможность подключаться внутрь контейнера по VNC и, в некоторых случаях, можно наблюдать процесс выполнения тестов, чтобы определить по какой причине тест отваливается по таймауту.
VNC (Virtual Network Computing) - система удалённого доступа к рабочему столу компьютера, использующая протокол RFB (англ. Remote FrameBuffer, удалённый кадровый буфер). Управление осуществляется путём передачи нажатий клавиш на клавиатуре и движений мыши с одного компьютера на другой и ретрансляции содержимого экрана через компьютерную сеть.
Для более детального расследования причин падений тестов, после завершения их выполнения, стенд архивируется и отправляется в облако. После чего можно скачать архив, расположить его у себя на компьютере или сервере и одной командой развернуть стенд в том состоянии, в котором он оказался когда тесты завершились. Далее можно проанализировать технологический журнал, журнал регистрации конфигурации и сделать выводы о том, что же пошло не так.
Результатом внедрения автоматизированного тестирования стало нахождение многих сложно воспроизводимых и старых ошибок.
Ранее не удавалось их найти, по причине сложно воспроизводимых сценариев проверки, а так же потому, что данные ошибки являлись результатом взаимодействия нескольких сценариев. А за счет того, что процесс тестирования построен так, что тесты всегда сортируются для одинакового выполнения потоков по времени, то получается, что наборы тестов всегда разные. Это и повлияло на нахождение старого «нехорошего» кода, который сейчас исправлен, а значит, и система стала лучше.
Так же пришло понимание, что весь процесс автоматизированного тестирования - это очень долго и очень сложно со всех сторон. Во-первых, это выстраивание процессов, выбор технологии и разработка механизма, который это будет выполнять. И важный фактор - это люди! Людей надо обучить, людей надо приучить к тому, что тесты нужно писать! И писать правильно, с соблюдением регламентов, которые должны быть разработаны под конкретную ситуацию.
Удалось добиться того, что до команды тестирования доходит гораздо меньше ошибок, так как автотестами покрывается проверка базовых сценариев. Соответственно команда тестирования может сосредоточится на тех сценариях, которые являются более сложными.
И еще не очевидным моментом оказалось то, что параллельно можно тестировать новые версии платформы 1С при помощи тестов для подсистемы Фреш. Например, есть версия платформы №1, на которой проходят все тесты. Далее берем платформу №2 и запускаем те же самые тесты, в тех же условиях и они выполняются с ошибками. Соответственно в данной версии платформы есть какие-то ошибки. Показываем коллегам, которые занимаются разработкой платформы, вместе анализируем и стараемся исправить.
И хочется отметить, что автоматизацию может сделать каждый под свои условия, потому что «Vanessa Automation» это open-source проект. Он доступен на Githab. А для Фреша тоже есть проект Docker-fresh, который так же доступен на Githab.