Всем привет! Меня зовут Ренат Дасаев. Являюсь руководителем направления интеграционного автотестирования в компании MOEX и сегодняшний рассказ будет посвящен истории процесса внедрения E2E-автотестов в тестирование бизнес-процессов Московской Биржи. В статье расскажу про наиболее важные аспекты, фичи и сервисы нашего направления. Забегая вперёд, скажу, что сейчас это одно из самых востребованных направлений тестирования в Группе компаний.
Для начала вкратце разберемся, что такое E2E-автотест. Это вид тестов, который проверяет бизнес функционал от момента его начала до завершения.
Похожие тесты уже, безусловно, существовали в нашей компании, но они, как правило, покрывали функционал, который не выходил за пределы одного департамента (подразделения). У нас же была задача покрыть автотестами функционал, проходящий через несколько департаментов. Теперь поговорим, откуда взялась такая потребность.
Предпосылки внедрения E2E-автотестирования
Многие компании, в том числе и наша, сталкиваются с дорогостоящим тестированием бизнес-пользователей на стендах UAT (User Acceptance Testing):
Поддерживать такой стенд — это большая задача, так как здесь представлены абсолютно все интеграции, как и на промышленном контуре. Полигон обновляется каждый день множеством версий различных микросервисов от разных продуктовых команд;
бизнес-пользователям необходимо выделять время на проведение тестирования в отрыве от их основной работы - операционной деятельности в промышленном контуре. А представьте себе, что для проверки бизнес-процесса (далее БП) необходимо участие нескольких подразделений и каждое подразделение должно последовательно выполнять шаги, то есть на синхронизацию между подразделениями также уходит время. А если где-то случается ошибка в интеграции/данных/конфигурациях, то нужно снова всё начинать сначала после исправления ошибки;
помимо тестирования нового функционала, бизнес-пользователям нужно проверять ещё критичные регрессионные кейсы, которые могли быть затронуты внедряемым изменением.
Для сокращения расходов на тестирование на UAT руководством нашей компании было принято решение о внедрении автоматического тестирования, которое позволило бы снять нагрузку с операционных департаментов по части регрессионных интеграционных критичных кейсов на UAT и сосредоточить их силы на тестировании нового функционала. В дополнение выполнялись бы проверки готовности данного полигона к пользовательскому тестированию, возможность непрерывно запускать тесты на множественные обновления микросервисов в разных системах, снижение сроков доставки кода в промышленный контур.
Команда
Для достижения выше поставленных задач была создана команда (в скобках поясняем, чем занимается на данном направлении):
начальник управления (анализ потребностей бизнес-заказчика, административный контроль за показателями в команде);
руководитель направления (техническая проработка потребности, делегирование задач в команде, участие в разработке автотестов и CI/CD процессов);
ведущий разработчик автотестов (разработка автотестов, развитие CI/CD процессов);
начинающий разработчик автотестов (разработка автотестов).
С недавнего времени нам также помогает бизнес-аналитик из нашего Управления с анализом функциональных задач, полученных от заказчика.
Направление E2E-автотестирование стартовало в феврале 2022 года. Далее расскажем, как мы отбираем задачи для покрытия автотестами.
Процесс отбора функционала для E2E-тестов
Критериев для отбора бизнес-процессов на покрытие e2e-автотестами несколько:
На ручную проверку функционала бизнес-пользователи регулярно тратят много своего времени, которое они могли бы направить в более ценное русло;
БП проходит через несколько систем;
Есть функциональное задание, из которого можно понять, как в целом устроен процесс, из каких частей состоит и пр.
После определения трудозатрат и внесения БП в план на автоматизацию, заказчик приступает к написанию ТЗ (техническое задание) и описывает сценарии тестов, если их еще нет. Эту часть работы мы зачастую выполняем вместе с заказчиком для более глубокого погружения.
В ТЗ описываются сценарии тестов с отражением всех используемых параметров. Как правило, автоматизации подлежат всего 1–2 сценария, в основном позитивные (негативные практикуются тоже, но это скорее исключение).
Почему так мало сценариев тестирования:
Данные тесты не имеют под собой цели проверять отдельно взятую функциональность, так как проверка корректности работы отдельных функций осуществляется автотестами продуктовых команд;
Сценарии повторяют те действия пользователя, которые он делает в рамках регрессионных интеграционных тестов, а таких сценариев обычно не много и их в целом достаточно для проверки взаимодействия систем, сетевой связанности и т. д.
Теперь перейдём к технической части вопроса.
Особенности процесса разработки E2E-тестов
При разработке автотестов стараемся придерживаться следующих положений:
Таблица 1. Список положений и эффект от их применения
Положение | Эффект |
Больше использовать в тестах rest API, меньше UI. | Это продиктовано более надежной и быстрой работой самого теста. Разработка и поддержка такого теста существенно дешевле, чем прохождение БП через UI. Но все же без использования UI в тестах не обошлось. В нашей компании сохраняется небольшое число крупных систем в виде монолита, у которых нет своих rest-api. В этих системах проводится крупный рефакторинг (перевод на микросервисы), но процесс этот не быстрый. |
Генерация моделей на основе swagger-документов. | Генерируем модель сервиса на основе его swagger. На выходе получаем python-объект (со всеми методами из swagger), с которым работаем уже в тесте. |
Совместная с другими командами разработка python-модулей и использование их в тестах.
| Обсудили со смежной командой этот подход и решили его придерживаться. На каждый микросервис, с которым взаимодействуем в тесте, пишем python-модуль (пакет), помещаем его в pypi-репозиторий (nexus). Если необходимо написать тест на БП, в которых участвуют микросервисы, для которых уже существует python-модули, то задача сводится лишь к тому, чтобы собрать конструктор из этих модулей (загрузив их из биржевого pypi-хранилища) и описать тестовый кейс. |
Генерация уникальных тестовых данных runtime. | Получаем независимые тестовые данные, которые не пересекаются с пользовательскими. Есть небольшой процент тестов (менее 10%), где мы используем уже созданные сущности ввиду сложности их создания в автоматическом режиме. |
Никаких зависимых тестов – все необходимые данные готовим фикстурами перед каждым тестом. Там, где нужно – подчищаем за собой после теста. | Все тесты атомарные, можно запустить любой из них когда угодно.
|
Детальное логирование всех запросов (http, sql, ftp, smb…). | Легко найти запрос и ответ в консоли выполнения теста. Особенно полезно при выяснении причин падения теста. |
Маркировка тестов списком микросервисов и БП. | Легко запускать группы тестов по маркировке: бизнес-процесс/микросервис |
Сбор всех инцидентов в БП. | Помогает в разборе падения тестов. Инциденты собираются на основе маркировок. |
Сбор всех логов микросервисов при падении автотеста. | Помогает в разборе падения тестов. Логи собираются на основе маркировок. |
Иметь все необходимые системы, сервисы и интеграции на стенде разработки автотестов. | Этот стенд мы поддерживаем своими силами, по интеграциям получаем консультации от внешних команд. Таким образом, мы знаем, как эти системы деплоятся, обновляются, настраиваются. Используем все те же инструменты и подходы в развертывании и конфигурировании сервисов, что и на стендах далее (приемочное тестирование, промышленная эксплуатация). Более подробно о стендах расскажем далее. |
Проведение ежедневных митингов. | Решаем технические проблемы. |
Использование практики дежурства | Поочередно каждый из исполнителей назначается на неделю дежурным. В его задачи входят: - разбор ночных прогонов на QA/UAT; - заведение артефактов на актуализацию автотестов; - заведение артефактов на ошибки/улучшение в сервисах; - актуализация конфигов сервисов; поддержка тестового контура. |
Полигоны
В нашей компании представлено много полигонов. Мы используем несколько из них:
QA – полигон для внутреннего тестирования. Для целей E2E развернуто два k8s-кластера с микросервисами, которые участвуют в БП, покрываемых тестами. Внутри этих кластеров есть множество неймспейсов (пространство имен), которые используются как инженерами по автоматизации тестирования смежных команд, так и инженерами функционального тестирования. На данном полигоне мы разрабатываем и отлаживаем тесты;
UAT (stage) – полигон приемочного тестирования. Данный полигон повторяет промышленный как по данным (на определенную дату), так и конфигурационно. На нем тестируются текущие боевые версии систем и перспективные релизы. После разработки автотеста на QA мы включаем новый тест в сборку для прогона уже на UAT. Это целевой полигон для наших тестов, т. к. здесь же тестируются заказчики. На данном стенде раскатываются уже проверенные сборки сервисов с других стендов QA, проверенные конфигурации и пр. Таким образом исключаются нестабильности и прогон тестов очень показателен. Особенно важен прогон автотестов за день до крупных релизов (участие в quality gates). Перед крупными релизами к нам обращаются продуктовые команды с целью прогнать тесты на тот или иной функционал, чтобы убедиться:
критичный функционал работает, как и ранее (код, который не менялся, т. е. регрессионное тестирование);
конфигурации и сетевая связанность сервисов в рабочем состоянии и корректны;
время ответов от сервиса находится на приемлемом уровне при обычной рабочей нагрузке.
PROD – полигон промышленной эксплуатации. На данном полигоне мы пока не запускаем E2E-автотесты на регулярной основе, но в планах на текущий год такая задача имеется.
Инструменты
Как и в любом деле, без хороших инструментов нельзя выполнить эффективно поставленные задачи. Поэтому мы разработали под свои нужды сервисы, которые успешно помогают нам в процессе автотестирования, а также используем мейнстримовые инструменты для разработки и деплоя. Далее расскажем о них.
Тестовый фреймворк
разработка автотестов и фреймворка ведется на языке программирования Python 3.8 (в текущем году планируется переход на 3.11);
в качестве тест-менеджера используется Pytest;
для работы с backend в основном используются:
rest-api: обертка над requests;
databases: ORM (SQLAlchemy), fdb (Firebird engine), cx_oracle (Oracle engine), psycopg2 (postgresql);
UI: обертка над selenium;
исходный код автотестов и фреймворка хранится в git.
CI/CD
Наш CI/CD – конвейер состоит из:
Jenkins – запуск автотестов;
GitlabCI – работа с конфигурациями, исходным кодом, создание базовых образов сервисов и тестов;
Vault – хранение конфигов для микросервисов;
Nexus – хранилище артефактов различного типа (docker, pypi и др.).
Как правило, конвейер завершает свою работу:
генерацией образа и отправки его в nexus;
и/или разворачиванием deployment в k8s через helm (где запускаются сервисы/тесты).
Ниже (см. рисунок 1) схематично изображен базовый pipeline по ночному регрессионному автотестированию в нашей команде.
Под стендом подразумевается совокупность всех k8s – кластеров, баз данных, торговых систем, шин и прочего, что покрывается интеграционными автотестами в рамках БП.
Запуск тестов
В запуске автотестов участвует самописный скрипт, который обходит папку tests и составляет списки тестов со всеми маркировками (в том числе своими). На выходе получаем несколько списков тестов:
которые можно запускать только в одном потоке;
которые можно запускать в несколько потоков (через multiprocessing. pool).
Также в каждом из этих списков учитывается время, пришедшее от сервиса статистики.
Затем, в зависимости от числа исполнителей, выполняется распараллеливание тестов (см. рисунок 2)
E2E-автотесты могут запускаться:
по расписанию каждую ночь на QA/UAT-полигонах посредством нашего CI/CD – сервера Jenkins;
при изменениях в версиях микросервисов, которые участвуют в покрытых БП (на основании маркировок) в течение дня (GitlabCI + Jenkins);
ручной запуск с рабочей станции или непосредственно из задания в Jenkins.
Результаты тестов
Важно не только прогнать автотесты, но и получить отчет, по которому можно легко анализировать:
сколько тестов упало;
места падений;
сообщения об ошибках;
логи микросервисов, скриншоты.
У нас используется:
allure framework: для построения отчетности на уровне инженеров автоматизации тестирования непосредственно в Jenkins;
allure test ops: для построения отчетности на уровне руководства.
Среди инструментов имеются полноценные сервисы (backend + frontend), которые мы разработали с нуля своими силами.
Сервис статистики
Сервис, позволяющий выгружать, обновлять и удалять статистику о времени прохождения тестов. Данная информация служит в дальнейшем для более эффективного распределения тестов при их запуске. Таким образом, самые длинные тесты запускаются в начале сборки, а ближе к концу самые короткие (более подробно в следующем разделе).
В данном сервисе есть разделение тестов по типу запуска – regress (как правило весь набор тестов)/smoke, а также debug (одиночный запуск)/multiple (с распараллеливанием). В зависимости от того, с какими параметрами запустилась сборка на CI/CD, из сервиса статистики запрашивается та или иная информация (формируется json на стороне тестового фреймворка и отправляется в сервис).
Данный сервис установлен как на QA-полигоне, так и на UAT-полигоне.
Основные параметры:
сервис написан на Python 3.8 с использованием библиотек: Django, Django REST Framework, Marshmallow;
для Django используются вспомогательные библиотеки: django-bootstrap4 , django-crispy-forms, django-filter и django-tables2;
в качестве БД используется SQLite;
для тестирования используется библиотека PyTest;
на Gitlab CI используются библиотеки: Coverage, Coverage-Badge и AnyBadge.
Сервис дашборды для руководства
Сервис, позволяющий агрегировать информацию с баг-трекинговой системы и сервиса статистики, строить статистику с данными. Какие это данные?
артефакты, заведенные командой E2E в разрезе проектов, типов и времени:
o можно с легкостью узнать, сколько и каких типов артефактов завели в любой месяц;
агрегировать число артефактов за определенный период в любом проекте;
соотношение числа открытых и закрытых артефактов по месяцам.
численные параметры прогонов тестов на UAT, из которых можно легко узнать:
с каким результатом выполняются прогоны (число падений);
как меняется число автотестов со временем;
как изменяется время исполнения тестов.
Прежде всего этот инструмент разрабатывался для руководства, чтобы оценивать метрики эффективности команды E2E.
Данный сервис установлен только на UAT-полигоне.
Основные параметры:
сервис написан на Python 3.8 с использованием библиотек: Dash, Gunicorn, Plotly, Pandas, самописные модули по работе с jira и сервисом статистики;
на Gitlab CI используются библиотеки: Coverage, Coverage-Badge и AnyBadge.
Теперь посмотрим на сервис дашборды в картинках (см. рисунок 4-8) чтобы лучше понимать в каком виде мы визуализируем информацию.
Сервис, помогающий в дежурстве
Сервис по формированию различных отчетов по мониторингу окружений с CI/CD процессов позволяет получить ответы на следующие вопросы:
какие сервисы и версии установлены на тестовом стенде;
насколько успешно работают процессы по автоматическому обновлению сервисов в течение дня и запуска после их обновлений смоук-тестов;
есть ли различия в конфигурациях сервисов между несколькими стендами.
Данный сервис установлен только на QA-полигоне. На UAT у нас нет доступа к системе управления версиями микросервисов. Но у нас есть доступ (как и подписка) к проекту в баг-трекинговой системе, через который проходят все артефакты, и поэтому мы в курсе, какие версии ушли на данный полигон.
Основные параметры:
сервис написан на Python 3.8 с использованием библиотек: Flask, Werkzeug, Gunicorn, самописная библиотека по работе с gitlabci;
на Gitlab CI используются библиотеки: Coverage, Coverage-Badge и AnyBadge.
Традиционно ниже представляем скриншоты данного сервиса (рисунок 9-13).
Дашборды для квартального планирования деятельности направления E2E
Также у нас есть доска, созданная в wiki, которая позволяет увидеть общее планирование всех задач на нашем направлении по кварталам со всеми оценками по трудоемкости и другими атрибутами.
Результаты направления за год и планы на будущее
Почти 1,5 года пролетели незаметно, и мы можем подвести промежуточные итоги нашей работы по направлению E2E-автотестирования бизнес-процессов:
бизнес-процессы:
покрыто 42 интеграционных БП Операционного блока, что высвободило у бизнес-пользователей 25,2 человеко-дня при проведении всего того регрессионного тестирования на UAT, что покрыто автотестами. При этом запуски Е2Е тестов проводятся не несколько раз за релиз (как руками бизнес-пользователей до этого), а каждую ночь или при каждом обновлении сервиса, покрытого е2е тестом. Релизный график больших информационных систем в нашей компании как правило раз в полтора месяца. Есть системы, которые выпускаются на еженедельной основе;
выстроен процесс отбора и согласования задач на автоматизацию E2E;
заведено более 278 артефактов в баг-трекинговую систему;
процессы автоматизации:
испробован новый подход с разделяемыми модулями, и он полностью себя оправдал. На данный момент со смежными командами (привет команде автоматизации тестирования проекта ЦУП/ЦРММ
Интересные статьи
Интересные статьи
