Запущение теста на Производственном Коде/Сервере
Да это может иметь конструктора, и это определяется и ведет себя точно так же, как конструктор любого другого класса. За исключением того, что абстрактные классы нельзя непосредственно инстанцировать, только расширенные, таким образом, использование поэтому всегда от конструктора подкласса.
6 ответов
Может быть, вы подумаете о сценариях селеном как о «мониторинге», а не о «тестировании»? Я надеюсь, что на каждом крупном веб-сайте ведется какой-то мониторинг, даже если это просто периодический PING или периодическая загрузка домашней страницы. Хотя можно зайти слишком далеко, не бойтесь концепции в целом. Так каковы некоторые преимущества этого мониторинга / тестирования для вас и вашего клиента?
Почему-то не все лучшее в мире тестирование может предсказать странные вещи, которые будут делать пользователи, намеренно или просто с помощью числовых значений (если 1 Миллионы обезьян на пишущих машинках могут написать Гамлета, представьте, что могут сделать несколько сотен щелчков мыши, счастливые пользователи? Пинг сайта может сказать вам, работает ли он, но не то, что таблица повреждена и отчет теперь не работает. все потому, что пользователь ввел значение с умлаутом в нем.
Хотя ваш сайт может отлично работать на промежуточных серверах, возможно, со временем он начнет ухудшаться. Если вы следите за производительностью этих тестов на селен, вы можете опередить жалобы на медлительность. Конечно, как вы упомянули, убедитесь, что ваш мониторинг также не вызывает проблем! Возможно, вам придется убедить своего клиента, что одни тесты подходят для запуска каждые X минут, а другие - только один раз в день, в 3 часа ночи.
Если вы в конечном итоге внесете экстренные изменения в действующий сайт, вы будьте более уверены, зная, что проводятся тесты, чтобы убедиться, что все в порядке.
Я бы посоветовал каждую ночь выполнять теневое копирование производственной базы данных в промежуточную / тестовую среду и запускать там модульные тесты каждую ночь. Подход, предложенный клиентом, был бы хорош для того, чтобы убедиться, что новые данные, введенные в систему, не вызывают исключений в системе, но я не согласен с тем, чтобы делать это в производственной среде.
Запуск его в промежуточной среде даст вам возможность оценивать функции по мере поступления новых данных в систему без использования производственной среды в качестве испытательного стенда.
[править], чтобы убедиться, что сайт работает, вы можете написать простую программу, которая проверяет его каждые 10 минут, вместо того, чтобы запускать для него весь ваш набор тестов.
Что изменится в производственной среде среда, в которой вам потребуется запускать автоматические тесты? Я понимаю, что вам может потребоваться мониторинг и оповещения, чтобы убедиться, что серверы работают и работают.
Я долгое время работал над аналогичными производственными серверами. Исходя из своего опыта, я могу сказать, что всегда лучше тестировать наши изменения / исправления в среде Stage и просто развертывать их на производственных серверах. Это связано с тем, что промежуточная и производственная среды похожи, за исключением объема данных. Если это действительно необходимо, было бы нормально провести несколько тестов на производственных серверах после установки кода / патча. Но это не рекомендуемый / хороший способ всегда запускать тесты на рабочем сервере.
Каким бы ни был выбор, будь то решение типа мониторинга или тестирования, вы должны прежде всего предупреждать своих клиентов. Как вы уже упоминали, тестирование в производственной среде почти никогда не является хорошей идеей. Как только они узнают об опасностях и если нет другого логического выбора, тщательно составьте минимальные тесты. Применяйте их слоями и строго следите за ними, чтобы убедиться, что они не вызывают проблем с приложением.
Я согласен с Питером, что это больше похоже на мониторинг, чем на тестирование. Разница небольшая, но, на мой взгляд, очень важная. Если требования клиента связаны с соглашениями об уровне обслуживания, их запросы не выглядят слишком диковинными.
Кроме того, может быть небезопасно предполагать, что, если поставщик услуг не испытывает каких-либо проблем, сайт работает должным образом. Что, если сайт завален запросами? Или, возможно, SQL, который отлично работает при тестировании, начинает вызывать проблемы (тайм-ауты, блокировки и т. Д.) С большой производственной базой данных?