Home

Оригинальная публикация

Мы – Владимир Мясников и Владислав Егоров — представители команды интеграционного тестирования Mir Plat.Form (АО «НСПК»). Сегодня мы расскажем про разработанный и развиваемый нами инструмент автоматизации, позволивший сократить рутину во внутренних процессах команды.

Предисловие

Платёжная экосистема Mir Plat.Form включает в себя несколько десятков систем, большинство из которых взаимодействуют между собой по различным протоколам и форматам. Мы, команда интеграционного тестирования, проверяем соответствие этих взаимодействий установленным требованиям.



На данный момент команда работает с 13 системами уровня mission и business critical. Mission critical системы обеспечивают выполнение Mir Plat.Form своих основных функций, обеспечивающих стабильность и непрерывность функционирования банковской карточной системы РФ. Системы уровня business critical отвечают за поддержку предоставляемых клиентам Mir Plat.form дополнительных сервисов, от которых зависит непосредственная операционная деятельность компании. Частота выкатывания релизов в ПРОД варьируется от раза в неделю до раза в квартал, всё зависит от системы и готовности участников к частоте обновлений. В общей сложности мы насчитали около 200 релизов, прошедших через нашу команду в прошлом году.

Простая математика гласит следующее: количество проверяемых цепочек это — N-систем * M-интеграций между ними * K-релизов. Даже на примере 13 систем * 11 интеграций * 27 версий релизов получается примерно 3 861 возможных вариантов совместимости систем. Кажется, ответ очевиден – автотесты? Но проблема чуть серьезнее, только автотесты не спасут. Учитывая растущее количество систем и их интеграций, а также различную частотность релизов, всегда имеется риск протестировать неправильную цепочку версий систем. Следовательно, имеется риск пропустить дефект в межсистемном взаимодействии, например, влияющий на корректность работы платежной системы (ПС) «Мир».

Естественно, в ПРОДЕ наличие такого рода багов недопустимо, и задача нашей команды – свести такой риск до нуля. Если помните текст выше, любой «чих» влияет не только на внутренние системы Mir Plat.form, но и на участников рынка: банки, торгово-сервисные предприятия (ТСП), физические лица и даже на другие платежные системы. Поэтому для устранения рисков мы пошли следующим путем:

• Ввели единую базу выпуска релизов. Для этой задачи вполне хватило календаря релизов в Confluence с указанием версий систем, установленных в ПРОД;
• Отслеживаем интеграционные цепочки в соответствие с релизными датами. Здесь мы тоже не стали изобретать велосипед, он нам потребуется дальше. Для решение данной задачи использовали Epic структуры в JIRA для интеграционного тестирования релизов. Пример структуры для релиза 1.111.0 системы System3:

С одной стороны, все эти действия позволили улучшить понимание команды о тестируемых интеграциях, версиях систем и последовательности их выхода в ПРОД. С другой — все равно осталась вероятность некорректного тестирования вследствие человеческого фактора:

1. В случае, если дату релиза какой-нибудь системы подвинули, то члену команды необходимо вручную поправить календарь и всю структуру в JIRA, в том числе сроки выполнения задач и, возможно, версии тестируемых систем;
2. Перед тестированием интеграции необходимо убедиться, что окружение для тестирования состоит из нужных версий систем. Для этого необходимо вручную пробежаться по тестовым стендам и выполнить пару консольных команд.

Вдобавок появилась дополнительная рутинная работа, отнимающая иногда значительную часть времени.

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

Какие опции хотелось реализовать в разрабатываемой системе?

1. Наглядный календарь релизов с возможностью вывода версий всех систем на конкретную дату;

2. Мониторинг окружений для интеграционного тестирования:

• список окружений;
• наглядное отображение тестовых стендов и систем, входящих в состав отдельного окружения;

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

3. Автоматизированную работу с задачами в Jira:

• создание Epic структуры релиза;
• управление жизненным циклом задач на тестирование;
• актуализация задач в случае сдвига даты релиза;
• подкладывание allure-отчетов в задачи на тестирование.

4. Автоматизированную работу с ветками в Bitbucket, а именно создание релизных веток в проектах:

• интеграционных автотестов;
• автодеплоя интеграционного окружения.

5. Интуитивно понятный UI для запуска автотестов и обновления версий систем.

Что есть СМИТ

Так как система несложная, мы не стали особо мудрить с технологиями. Бэкенд написали на Java с использованием Spring Boot. Фронтенд — на React. К базе данных особенных требований не было, поэтому мы выбрали MySql. Поскольку у нас принято работать с контейнерами, то все вышеперечисленные составляющие завернули в Docker, собирая при помощи Docker Compose. Работает СМИТ быстро и так же надежно, как остальные системы Mir Plat.Form.

Интеграции

• Atlassian Jira. В джире создаются, открываются, принимаются в работу и закрываются задачи на тестирование каждой конкретной интеграции, если все тесты прошли успешно — прикладывается ссылка на allure отчет в комментарии.
• Atlassian BitBucket. В битбакете лежит код проекта автотестов, где инженеры по автоматизации ведут список окружений, настраивают его и добавляют/убирают системы в определенные окружения. Также там создаются “релизные” ветки под каждую новую версию системы, где будут вестись работы по актуализации кода и бизнес логики тестовых сценариев.
• Jenkins. Все тесты из проекта автотестирования можно запускать через Jenkins, для каждого набора тегов у нас предусмотрена своя джоба. Отдельные джобы нужны для того, чтобы не грузить все шаги каждый раз, а загружать только нужные с помощью указания glue для Cucumber.
• Системы. У СМИТа есть необходимость взаимодействовать с самими системами. Так СМИТ узнает актуальные версии систем путем выполнения определенных команд по ssh.

Ведение списков систем

Перед тем как в СМИТе вести календарь и мониторить состояние окружений, необходимо завести список тестируемых систем и взаимосвязи между ними. Все настройки можно произвести через веб-интерфейс:



После добавления тестируемой системы в список СМИТ:

1. “постучится” на все хосты систем, имеющих название SYS_CMD в списке окружений;
2. узнает версию этой системы с помощью команды, указанной в конфигурации;
3. запишет к себе в базу текущую версию данной системы и окружения, в которых она фигурирует.

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

Календарь релизов

После того, как владельцы систем или тим лиды команд разработки продуктов сообщают нам дату установки нового релиза в ПРОД, мы регистрируем этот релиз в календаре. Получается вот такая вот картина:



Можно легко заметить конфликты, где за несколько дней устанавливается сразу несколько релизов и возможна “жара”. Об этих конфликтах уведомляются владельцы продуктов, ведь ставить несколько новых версий систем в один день действительно опасно.

Также на странице с календарем имеется функция вывода версий всех систем на конкретную дату:



Стоит отметить, что при регистрации нового релиза в календаре СМИТ автоматически создает Epic структуру в Jira и релизные ветки в проектах в Bitbucket.

Состояние окружений

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



Как видно на скриншоте, СМИТ обнаружил на хосте host-4.nspk.ru неактуальную версию System 4 и предлагает обновить её. Если нажать красную кнопку с белой стрелкой, то СМИТ вызовет Jenkins джоб на деплой актуальной версии системы в текущем окружении. Также есть возможность обновить все системы после нажатия соответствующей кнопки.

Окружения для интеграционного тестирования

Стоит немного рассказать про то, как мы задаем тестовые окружения. Одно окружение представляет собой некий набор стендов с развернутыми системами Mir Plat.form и настроенной интеграцией (на одном стенде — одна система). В общей сложности у нас 70 стендов, разбитых на 12 окружений.

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

{  
   "properties":{  
      "comment":"Общие system property для всех Environment. Могут быть переопределены персональными property, а также всем, что при запуске тестов в System.getProperties()",
      "common.property":"some global property"
   },
   "environments":[  
      {  
         "comment":"Если отсутствует name, то Environment получит имя common + порядковый номер. Например common1",
         "name":"env_1",
         "properties":{  
            "comment":"Персональные system property данного Environment. Могут переопределять общие property. Могут быть переопределены всем, что при запуске тестов в System.getProperties()",
            "env1.property":"some personal property"
         },
         "DB":{  
            "comment":"Пример TestResource'а DbTestResource. Если не указано поле id, то оно автоматически будет взято из ключа",
            "url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",
            "driver":"com.mysql.jdbc.Driver",
            "user":"fo",
            "password":"somepass"
         },
         "SYS_CMD":{  
            "comment":"Пример TestResource'а на основе RemoteExecCmd. Должен иметь параметр type = remote",
            "type":"remote",
            "host":"10.111.111.111",
            "username":"user",
            "password":"somepass"
         }
      }
   ]
}

Помимо того, что данный файл необходим для работы проекта интеграционных автотестов, он также является дополнительным конфигурационным файлом для СМИТа. При запросе обновлении информации об окружениях в СМИТе отправляется HTTP запрос в API нашего bitbucket, где мы храним проект с интеграционными автотестами. Таким путем СМИТ получает актуальное содержимое файла конфигураций из master ветки.

Запуск тестов

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



На странице тестирования системы (в данном примере — System 3) можно выбрать перечень систем, с которыми нужно проверить интеграцию. После выбора нужных интеграций и нажатия на кнопку “Запустить тестирование”, СМИТ:

1. Сформирует очередь и последовательно запустит соответствующие Jenkins джобы;
2. мониторит выполнение джоб;
3. меняет статус у соответствующих задач в Jira:

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

Вывод

СМИТ был создан для минимизации рисков интеграционного тестирования, но нам как команде хотелось бОльшего! В частности, одним из желаний было, чтобы по одному нажатию кнопки автотесты запускались с правильным тестовым окружением, проверялось все в нужных интеграционных соответствиях, задачи в Jira сами открывались и закрывались вместе с отчетами. Такая утопия автотестеров: скажи системе, что проверить, — и иди пить кофе :)

Подведем итог, что у нас получилось реализовать:

1. Наглядный календарь релизов с возможностью вывода версий всех систем на конкретную дату;
2. UI для отслеживания состояния наших окружений, позволяющий посмотреть перечень и версии систем, установленных на конкретном окружении;
3. Оповещение пользователей о неактуальных версиях систем с возможностью обновления до актуальной;
4. UI с интуитивно понятным запуском интеграционных автотестов для всей системы или для отдельных интеграций на определенном окружении;
5. Автоматическое создание и закрытие Epic и Task в Jira, прикладывание Allure отчетов к ним;
6. Автоматическое создание релизных веток в Bitbucket.

О планах на будущее

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

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

Обсудить в форуме