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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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