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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Это не безопасно иметь тестовые данные на prod, вам нужно быть осторожным.

Answer 6

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

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

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

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

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