Тестовые аккаунты и продукты в производственной системе

Question

Стоит ли разрабатывать систему так, чтобы тестовые учетные записи и продукты присутствовали и были активны в производстве, или не должно быть загрязнения производственных баз данных тестовыми объектами, даже если ваша команда по доставке знает, что не следует отправлять какие-либо коробки, адресованные «Тестовому клиенту»? ?

Я реализовал протоколы обмена сообщениями, в спецификации которых есть атрибут test="True", и задался вопросом, должна ли современная схема включать метаданные для маркировки заказов, счетов, транзакций и т. д.как тестовые объекты, которые обрабатываются так же, как и любой другой объект, но незадолго до того момента, когда тратятся деньги.Т.е.:он имитирует списание средств с воображаемой кредитной карты и имитирует отправку посылки.

Не ожидается, что это заменит полностью разделенную базу данных тестирования, разработки и контроля качества, но даже с ними у нас всегда были известные Test SKU и Test Customer в производственной системе.Безвреден?

Answer 1

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

Answer 2

Я полагаю, что полиция передового опыта сформулировала бы мантру «никогда не тестируйте в рабочей версии» и, возможно, даже добавила бы: «разработчики не должны иметь доступа к рабочей версии».

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

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

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

Поэтому я советую запускать тестовые аккаунты/продукты в производство, если это поможет устранить неполадки после запуска.

Answer 3

Если ваша база данных создается из скриптов в автоматическом режиме, то это становится не вопросом.

В моей среде мы используем круиз-контроль для непрерывной сборки.Сценарии SQL для создания базы данных проверяются в CVS вместе со всем остальным, и база данных ежедневно перестраивается на основе этих сценариев.

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

Учитывая нашу среду, тестовые данные никогда не затрагивают рабочую базу данных.

Это решение действительно отлично подходит для нас.

Answer 4

Я бы не стал помещать какие-либо тестовые данные в производственную систему и не хотел бы иметь к ней доступ в качестве разработчика.

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

ИМХО, лучшая практика — полностью разделить эти два мира и инвестировать в создание процедуры подготовки комплексной среды тестирования.

Answer 5

В наших ERP-системах (доступных только изнутри) у нас есть тестовые данные, поэтому при переносе изменений из тестовой среды в производственную мы можем протестировать весь процесс.Я считаю эти данные неизбежным злом, поскольку тонкие различия в конфигурации между системами могут привести к катастрофическим результатам, поэтому, как только изменение вводится в эксплуатацию, мы полностью тестируем его, прежде чем «выпустить» его пользователям.

Однако, как я уже сказал, это только внутренние приложения, поэтому риски безопасности несколько уменьшаются — это очень серьезная проблема.

Answer 6

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

Всегда имейте план производственных испытаний.На проде могут возникнуть проблемы или, если не повезет, только происходит на проде.Если у вас ничего нет на месте, в первый раз, когда вам нужно будет протестировать на проде (обычно это случаи сильного стресса), вы окажетесь в ручье без весла.

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