Всем известно, что у тестировщиков в жизни много трудностей. И мы, команда QA Департамента общих прикладных сервисов (ДОПС) Сбера, знаем об этом не понаслышке, так как тестируем релизы сервисов Platform V — цифровой облачной платформы СберТеха (более 70 продуктов для быстрого создания и легкого масштабирования приложений любой сложности). Да‑да, именно на Platform V Сбер совершил свою цифровую трансформацию!
Релизы поставляют в банк из СберТеха. Всё бы ничего, пришли изменения — тестируй. Но основная сложность заключается в том, что у платформы десятки продуктов, из‑за чего работа усложняется в разы.
Что тут можно придумать и как облегчить и без того насыщенную жизнь тестировщиков? При проверке новых релизов мы используем все классические виды тестирования: нагрузочное, функциональное и их автоматизацию, деструктивное, тесты с потребителями. Но нам захотелось большего! «Как повысить скорость тестирования и снизить трудозатраты на это?», — такой вопрос засел у нас в головах. И вот, спустя какое‑то время, у нас родилась идея — разработать Синтетическое приложение Platform V.
В рамках выполнения запроса мы обращаемся к тем или иным сервисам Platform V, которые уже успели интегрировать с нашим приложением. К примеру, в сценарии «создание счёта» Синтетическое приложение за один запрос вызывает порядка 10 сервисов, аналогично тому, как это сделали бы реальные потребители платформы.
Вот некоторые из задействованных сервисов:
Мы одни из первых получаем обновления и подключаем новые сервисы платформы в качестве потребителя. То есть все ошибки, недочёты, опечатки мы собираем в полном объёме. Это и проблемы с документацией, и инсталляционные проблемы, и разница в окружениях.
За время работы над Синтетикой курьезных ситуаций случалось достаточно много. Но, пожалуй, один из самых забавных случаев, с которым мы столкнулись — это ответ на вопрос: «А почему все‑таки сервис не работает?». «Сейчас проблема в том, что вы подключили все, что указано в документации», — невозмутимо ответили нам в сопровождении.
Но, с другой‑то стороны, каждая проблема — это вызов. И так как у нас их много, мы быстро учимся. За прошедшие полтора годы мы превратились из обычных Java‑разработчиков в Java‑разработчиков, разбирающихся в CI/CD процессах, процессах сертификации и безопасности, администрировании инфраструктуры и, что немаловажно, закаливших свою нервную систему!
Ну а главное, что помогает переносить все невзгоды, — вера, что мы можем сделать продукт лучше. И, не побоимся этого сказать, — понимание того, что мы стоим на страже потребителя.
habr.com
Релизы поставляют в банк из СберТеха. Всё бы ничего, пришли изменения — тестируй. Но основная сложность заключается в том, что у платформы десятки продуктов, из‑за чего работа усложняется в разы.
Что тут можно придумать и как облегчить и без того насыщенную жизнь тестировщиков? При проверке новых релизов мы используем все классические виды тестирования: нагрузочное, функциональное и их автоматизацию, деструктивное, тесты с потребителями. Но нам захотелось большего! «Как повысить скорость тестирования и снизить трудозатраты на это?», — такой вопрос засел у нас в головах. И вот, спустя какое‑то время, у нас родилась идея — разработать Синтетическое приложение Platform V.
Что есть Синтетика?
Определение из документации гласит, что Синтетическое приложение — это «набор инструментов для тестирования платформенных сервисов, реализующий интеграционные бизнес‑сценарии, имитирующие реального потребителя». На деле же, наша Синтетика — это небольшое приложение, развернутое в облаке. Тут все по классике: OpenShift для контейнеризации, Egress/Ingress для организации трафика и все остальные необходимые сущности.
Как она тестирует?
Для проверки сервисов мы разработали большой интеграционный сценарий, в который входят базовые банковские операции: открытие счета, перевод денежных средств, выписки, платежи и другие. Синтетические сценарии максимально эмулируют запросы потребителей и задействуют сразу несколько продуктов платформы.В рамках выполнения запроса мы обращаемся к тем или иным сервисам Platform V, которые уже успели интегрировать с нашим приложением. К примеру, в сценарии «создание счёта» Синтетическое приложение за один запрос вызывает порядка 10 сервисов, аналогично тому, как это сделали бы реальные потребители платформы.
Вот некоторые из задействованных сервисов:
- DataSpace — сервис для работы с данными (аналог Hibernate).
- Audit — сервис для регистрации и долговременного хранения событий информационной безопасности.
- One‑Time‑Token — инструмент для контроля доступа.
- Archiving — сервис архивирования и передачи данных в аналитическую платформу.
В чём плюсы такого подхода?
Среди достоинств нашей Синтетики можно выделить следующие:- Атомарность. Множество сервисов могут существовать только в рамках продуктов потребителей. Подобные компоненты нельзя установить без использующего их приложения — они не могут существовать атомарно. Такие клиентские модули зачастую сложно протестировать «руками». И наше приложение — это оптимальное решение для их проверки.
- Новый слой тестирования. Так как мы так же, как и реальные потребители, раскатываемся в своем пространстве, то у нас есть собственный CI/CD процесс, в котором мы можем отлавливать возникающие инсталляционные дефекты.
- Интеграция. Кроме всего вышеперечисленного, мы проводим проверки непосредственно межсервисного взаимодействия: модуль авторизации, сервисы репликации данных.
Но не всё так просто…
На самом деле, раздел про проблемы является для нас самым болезненным Мы одни из первых получаем обновления и подключаем новые сервисы платформы в качестве потребителя. То есть все ошибки, недочёты, опечатки мы собираем в полном объёме. Это и проблемы с документацией, и инсталляционные проблемы, и разница в окружениях.За время работы над Синтетикой курьезных ситуаций случалось достаточно много. Но, пожалуй, один из самых забавных случаев, с которым мы столкнулись — это ответ на вопрос: «А почему все‑таки сервис не работает?». «Сейчас проблема в том, что вы подключили все, что указано в документации», — невозмутимо ответили нам в сопровождении.
Но, с другой‑то стороны, каждая проблема — это вызов. И так как у нас их много, мы быстро учимся. За прошедшие полтора годы мы превратились из обычных Java‑разработчиков в Java‑разработчиков, разбирающихся в CI/CD процессах, процессах сертификации и безопасности, администрировании инфраструктуры и, что немаловажно, закаливших свою нервную систему!
Ну а главное, что помогает переносить все невзгоды, — вера, что мы можем сделать продукт лучше. И, не побоимся этого сказать, — понимание того, что мы стоим на страже потребителя.
Промежуточные итоги
Итак, в сухом же остатке за прошедшие полтора года жизни к нашему приложению было подключено более 80% сервисов Platform V. Что привело к:- Значительному уменьшению времени тестирования на потребителях. Для интеграционного тестирования оно снизилось вдвое, а для Smoke тестирования в 4 раза.
- Расширению покрытия, включая интеграционный слой и CI/CD процессы.
- Упрощению процесса установки непосредственным потребителем сервиса.
Просто ли открывается ларчик, Или как протестировать сразу более 10 сервисов
Привет, Хабр! Всем известно, что у тестировщиков в жизни много трудностей. И мы, команда QA Департамента общих прикладных сервисов (ДОПС) Сбера, знаем об этом не понаслышке,...
habr.com