Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Тестирование и прогон автоматизации тестирования на продакшн-сервере. Стоит ли такое делать?

management
Теги: #<Tag:0x00007fedb7f6eee0>

(Александра Литвиненко) #1

Добрый день
Менеджера проектов хотят, что бы функциональные(иногда и юнит) тесты проходили на продакшиновых серверах.
Как мне обьяснили:

  • стейдж сервер должны быть настроен идентично продакшиновому и тесты должны проходить на стейдже и этого достаточно.
  • юнит тесты на локали или наCI сервере.

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

на сколько правильно прогонять тесты на продакшене? или как можно отлавливать такие баги на проде не прогоняя тестов?


(Ilya Pas2shkov) #2

Системы управления конфигурациями вам в помощь, например Chef/Ansible/Salt. Просто пишете рецепт/playbook/миньон, по которому будут раскатываться пакеты на продакшн, отлаживаете на тестовом окружении, и получаете конфигурацию с указанным уровнем идентичности. И по тому же рецепту разворачиваете на тестовом, а при удачном прохождении тестов - и на продакшн.

А тесты на продакшене гонять - русская рулетка. Слишком велик риск что-то сломать и слишком мала вероятность найти причину ошибки.


(Mykhailo Poliarush) #3

По моему личному мнению, тестирование на продакшине - это не очень хорошая затея. Так как были случаи воздействия на окружение, которое может быть губительным.

Конечно это никто не запрещает делать. И я даже на некоторых проектах выполнял такую практику, но на продакшине, это было максимум автоматические смоук или санити тесты, которые были очень безвредны.

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

  1. Полная автоматизация на предыдущих уровнях до продакшина
  2. На продакшине, проверяются только критичных тесты
  3. Исследовательское тестирование на продакшине
  4. Выявленные дефекты, должны анализироваться на предмет покрытия автоматическими тестами
  5. По выявленным причинам возникновения дефектов, провести анализ выявления области локализации дефектов
  6. И покрывать это все автоматическими тестами на предыдущих уровнях
  7. Соответственно в следующий раз, чтобы дефекты не прошли

Конечно можно и рассмотреть вариант полного запуска автоматических тестов на продакшине, но тогда надо быть на 100% уверенным, что ваши тесты никоем образом не влияют на окружение, существующие данные, под системы и т.д. Как обычно выявить такие зависимости тяжело, а после прогона уже поздно, так как уже будет что-то поломано.

Ну и последнее, это вопрос ответственности. Так как система живая, в случае, если что-то поломается, кто будет ответственный? Будьте тогда к вопросам, а почему мы вложили столько усилий и денег в автоматизацию, а она нам все поломала, или не нашла дефекты, или потушила вашу систему или загрузила БД и т.д.?


(Alsu Vadimovna) #4

На нашем проекте прогоняются тесты на продакшене, но во-первых, их мало, в пределах 10 штук, во-вторых, прогоняются только те, что нужны:

  1. проверяются критичные кейсы связанные с интеграцией с другими сервисами
  2. выполнение различных процедур, т.е. лезем в базу и проверяем, что все ок с различными сущностями, которые меняются при работе различных сервисов
  3. также проверяются самые важные кейсы, например, регистрация (тут же проверяется, что ходит почта), + самые приоритетные кейсы для бизнеса

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


(Михайло Єдемський) #5

Идея с тестами на проде не так уж и плоха, но нужно учитывать несколько моментов
Если есть какие-то сенситив данные и это 24/7 предоставляемый сервис:

  • нельзя использовать/модифицировать/удалять данные
  • нужен механизм клинапа и подготовки окружения
  • механизм рекавери окружения, в случае падения
  • зарезервированный сервис тайм

Если продукт не критичный и тесты не создают заметной нагрузки, то можно пакет базовых тестов хоть круглосуточно гонять - получится что-то вроде heart beat монитора.


(Александра Литвиненко) #6

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


(rpwheeler) #7

В заголовок вынесен слишком неконкретный вопрос.

Тут хорошо бы расписать, какие тесты могут прогоняться на продакшене, на что они могут повлиять, как часто это будет, на что и как может повлиять частота и пр. — ну, как @polusok уже расписал выше.

Я могу назвать пару ситуаций, когда прогонять вообще хорошо и правильно:

  1. “проверяются критичные кейсы связанные с интеграцией с другими сервисами” , о которых уже написала @uslashka .

Допустим, был апдейт продакшена, как быстрее всего проверить на какие-то критичные регрессии? Через автотесты, конечно же.

  1. та же ситуация, что и в п.1 (критичные кейсы), но прогон “неразрушающей” (т.е. такой. которая не может что-то поломать) регрессии раз в сутки , причём воообще ночью, допустим, чтобы совсем не создавать лишней нагрузки.

(Sergey Korol) #8

Особенно классно гонять тесты на окружении с живыми пеймент сервисами. Можно еще подключить CRUD и джиметром шарахнуть напоследок.

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


(vmaximv) #9

Свежий пример из жизни:
На продакшене приложение работает на кластере, который состоит из несколько десятков серверов, которые имеют совершенно различные конфигурации (ОС, БД и т.д.).
Перед релизом заказчик хочет проверить новый функционал на каждом сервере, т.к. в прошлом прецеденты были. Прод открыт 24/7 и никто, на длительное время, его останавливать не будет.


(Александра Литвиненко) #10

а как же прогонят тесты с живыми пеймент сервисами, если тестовые данные не пройдут… т.е юзать реальные карточки не вариант, если сразу будет идти снятие денег…
что подскажете?


(Sergey Korol) #11

Что мешает сделать необходимые проверки до официального оповещения клиентов? Админы закрывают доступ из мира. Команда QA / аналитиков проверяют заранее подготовленные сценарии. Если все ок, сервера открываются клиентам.

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


(vmaximv) #12

Так оно так и есть - новый функционал доступен только QA, но при этом изолированно его протестить невозможно. Т.е. имеем вполне “живой” прод и часть “скрытого” функционала, при тестировании которого нужно очень тесно взаимодействовать с “открытыми для мира” частями приложения. “Тушить” прод для проверки всех 10-20-30 серверов никто не будет - это займет довольно много времени даже при авто-тестировании, не говоря уже про мануальное.

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

Я веду к тому, что, иногда потребность прогонять автотесты на живом проде - это не прихоть, а реальная жизненная необходимость.


(Sergey Korol) #13

Если это интернет магазин, то можно использовать трик с изменением цен товара = 0.01 у.е. + не выход за рамки лимита возврата. Т.е. мы осуществляем ряд покупок, а потом возвращаем деньги на карту, если сумма не превысила лимит. Но опять-таки, я не зря ведь сказал о закрытии сервера миру, ибо при данном трике, люди могут воспользоваться измененными ценами и купить товар за 1 коп. :slight_smile:

В случае, если ПО пишется для банков, а пеймент сервисы самописные, сей вопрос может решиться на уровне двухсторонней договоренности.


(Sergey Korol) #14

Мораль сарказма в первом посте заключалась как раз в том, что подходить к тестированию на продакшене надо с умом и рукастой командой. UI автоматизация - штука нестабильная. И в случае с открытым миру сервером, любой фейл или непродуманный сценарий может стоить дорого. А у нас как обычно бывает: скажут джуну-автомейшену - надо потестить на продакшене. А он что? Да не вопрос. Ну и все в принципе. Билет в один конец.

С подобным вашему сценарием я не сталкивался. Но было бы интересно послушать, как выкручивались в данной ситуации.


(vmaximv) #15

Да просто - запустили, протестили, выпустили. Дело в том, что я негативно отношусь к приведению системы в нужное состояния искусственными методами (БД/конфигурационные файлы и т.д.) . А тесты оперируют данными исключительно ими же и созданными. Поэтому опасность разрушительного воздействия на систему практически равно нулю.


(Sergey Korol) #16

А никого не смущают dummy data, видимые наружу на продакшене? Что если клиенты смогут напрямую взаимодействовать с ними?


(vmaximv) #17

Тестовые данные маркируются кейвордом и скрываются от реальных пользователей.


(Sergey Korol) #18

Makes sense.


(asolntsev) #19

Юнит-тесты запускать на продакшн-серверах? Простите, такой запрос говорит о полном непонимании сути Юнит-тестов. По определению, Юнит-тесты не зависят от окружения и работают одинаково на любых серверах. Поэтому их достаточно запускать на CI и компах разработчиков.


(Dmitriy Karassev) #20

Эм, у нас как раз так спроектирована система автотестов - в основу заложены концепции, позволяющие тестировать на живых сайтах (CMS наша и на ней много магазинов/блогов - периодически осуществляя платную поддержку мы делаем апдейты… после чего все проверяем).
А сама ситуация с магазинами решается очень просто - тестовый аккаунт на PayPal и в перед :slight_smile: