Тестовые учетные записи и продукты в производственной системе
Google JSON guide
Ответ отклика ответа data
{
"data": {
"id": 1001,
"name": "Wing"
}
}
Ответ об ошибке ответа error
{
"error": {
"code": 404,
"message": "ID not found"
}
}
, и если ваш клиент JS, вы можете использовать if ("error" in response) {}, чтобы проверить, есть ли ошибка.
6 ответов
Наличие учетных записей тестирования в производстве является чем-то, что я обычно осуждаю, потому что оно открывает потенциальную дыру в системе безопасности. Нужно стремиться копировать как можно больше продуктивной среды в тестировании, но существуют, очевидно, случаи, где это не возможно. Дорогое производство только аппаратные средства является главным примером. Я сказал бы как общая практика, ей нужно препятствовать, но как со всеми вещами, если можно обеспечить причину, которая имеет смысл Вам затем, Вы могли бы пропустить жесткое правило.
Никогда не тестируйте в напоминании, даже при том, что это - то, где весь доход сгенерирован/статистика, собраны/волшебство, происходит...?
Всегда имейте план производственного теста. Там будут проблемами, которые происходят на напоминании, или, если Вы неудачны, только происходит на напоминании. Если Вы ничего не имеете в распоряжении, в первый раз, когда необходимо протестировать на напоминании (которые обычно являются случаями высокого напряжения), Вы будете ручьем без весла.
Это не безопасно, чтобы иметь данные тестирования на напоминании, действительно необходимо быть осторожными.
Если Ваша база данных создается из сценариев автоматизированным способом, то это становится невопросом.
В моей среде мы используем круиз-контроль для непрерывных сборок. Сценарии SQL для генерации базы данных проверяются в CVS со всем остальным, и база данных восстановлена из тех сценариев ежедневно.
Наши данные тестирования являются вторым набором sql скриптов, которые запущены для тестовой базы данных и не выполняются для производственной базы данных.
Учитывая наши данные тестирования среды никогда не касается производственной базы данных.
Это решение действительно работает отлично для нас.
Я предполагаю, что полиция Лучшей практики заявила бы, что молитва "никогда не тестирует в напоминании" и возможно даже добавляет "разработчиков, не должен иметь доступа к напоминанию".
Однако я работаю над основанной на мейнфрейме системой, где существуют огромные различия между производством и тестом/обеспечением качества/королевским адвокатом; чем больше система, тем более вероятно такая ситуация. Кроме того, чем больше групп, которые имеют долю в приложении, тем более вероятно это.
Мне нужны больше чем две руки для подсчета, сколько раз мы могли только копировать проблему в продуктивной среде. Опция затем становится тестовыми таблицами/пользователями/данными создания или использованием живых данных о клиентах.
Время от времени мы действительно также создаем тестовые записи в производственных таблицах как некоторые пользователи/клиенты как наличие чего-то, что они могут искать/получать, который всегда является там.
Таким образом, мой совет состоит в том, что нормально вводить тестовые учетные записи/продукты в эксплуатацию, если это поможет диагностировать после ввода в эксплуатацию.
В ERP-системах (внутренне доступный только) у нас есть данные тестирования так, чтобы, когда мы перемещаем изменения от теста до продуктивных сред, мы могли протестировать целый процесс. Я просматриваю те данные как необходимое зло, так как тонкие различия в конфигурации между системами могут вызвать катастрофические результаты, поэтому после того как изменение работает, мы тестируем, полностью прежде "выпускает" его пользователям.
Как я сказал, хотя, это внутренние приложения только, таким образом, угрозы безопасности уменьшены несколько - это - очень обоснованная озабоченность.
Я не поместил бы данных тестирования в производственную систему, и при этом я не захочу иметь доступ к этой системе как разработчик.
Я работаю в промышленности с очень чувствительной медицинской и финансовой информацией и имею такую информацию, лишил бы возможности различать продуктивный от данных из системы тестирования.
По моему скромному мнению, лучшая практика является к абсолютно отдельному этими двумя мирами, и вложите капитал в установку процедуры для подготовки среды комплексного тестирования.