Недавно я был нанят для проекта, который включает в себя работу с несколькими сторонними "корпоративными" системами и вокруг них. Из-за того, что я представляю из-за астрономических затрат и усилий, необходимых для создания достаточно точной копии производственной среды, перспектива создания реальной среды разработки кажется крайне малой.
Это конечно не идеально. С другой стороны, я полагаю, что должны быть люди, которые безопасно тестируют и внедряют программное обеспечение в нереплицируемых средах, подобных этой, и я, вероятно, могу пойти по их стопам.
Как это делают те, кто эффективно справляется с подобными ситуациями?
testing
development-process
Джейсон Светт
источник
источник
Ответы:
Это происходит все время в реальном мире. Я знаю парня, который пишет приложения, которые контролируют гигантские сельскохозяйственные теплицы - вентиляцию, отопление, контроль влажности, вы называете это. У него нет «тестовой теплицы», но у него есть программа-симулятор, предоставленная компанией, которая создает реальные аппаратные системы. Если код корректно работает с симулятором, предполагается, что он корректно работает с реальным оборудованием. В редких случаях симулятор оказывается неправильным, но это проблема компании-производителя теплиц, потому что он не симулирует правильно.
источник
Это ситуации, в которых первыми были документация по API, документы по управлению интерфейсом и эмуляторы. В компании, в которой я работал ранее, это действительно происходило, это часто происходило в рамках проекта на определенных этапах интеграции, когда один сегмент был готов, но другие были позади, над какой-то другой функцией работали, или по какой-то другой причине они не смогли развернуть последняя версия своего сегмента для нашей тестовой системы. Итак, да, у нас действительно была точная копия нашей производственной среды, на которой мы тестировали; однако на практике все сегменты никогда не были готовы по графику, но интерфейсы были согласованы и заблокированы до начала разработки, и были созданы эмуляторы, которые могли бы по большей части имитировать поведение других сегментов.
Как уже говорилось в ответе, эмулятор - это то, что позволит провести тестирование перед развертыванием. Хороший эмулятор; однако, зависит от четко определенных интерфейсов и документации.
источник
Я нахожусь в таких ситуациях все время.
Вам, конечно, не нужно взаимодействовать со всем приложением, но, возможно, с некоторыми интерфейсами. Убедитесь, что вы подтвердили и подробно документировали интерфейсы, затем настройте макеты этих интерфейсов только для того, чтобы убедиться, что ваш добавленный / измененный код работает так, как вы предполагали.
Вы также можете сделать гибрид. Попробуйте воспроизвести части, которые вы можете довольно легко выполнить, а затем «подключиться» к реальным системам (если это возможно в вашей ситуации). Я сделал это с некоторым успехом - в некоторых случаях, когда моя логика и серверное программное обеспечение работали локально, но у меня все еще были соединения с реальной системой ERP для проверки вызовов и т. Д. Не идеально, но это редко случается.
Учитывая, что у вас есть только производственная система для работы - обратите внимание, что вы не можете рассчитывать только время, сэкономленное на настройке реплики, но вы должны учитывать бизнес-риск использования в основном непроверенного кода с живыми бизнес-данными. Ваш код будет менее надежным, чем код, проверенный на реплике. Могут ли системы быть недоступны в течение некоторого времени? Могут ли они быть восстановлены в случае повреждения данных? Сколько это стоит?
На предприятиях рекомендуется создавать реплики (или, возможно, более одной) продукции в момент настройки производственной среды. В этот момент дополнительные расходы не будут такими большими.
источник
Наша система работает с рядом крупных внешних систем. Мы объединяем следующие подходы при их тестировании, если у нас нет полной сквозной настройки:
источник