Запуск теста на производственном коде / сервере

Question

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

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

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

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

Есть ли у вас какие-либо мысли по поводу тестирования производственного кода на реальном производственном сервере?

Большое спасибо, ребята!

Answer 1

Может быть, было бы полезно, если бы вы думали о сценариях селена как о «мониторинге» вместо «тестирования»? Я хотел бы надеяться, что на каждом крупном веб-сайте есть какой-то мониторинг, даже если это просто периодический PING или загрузка домашней страницы так часто. Хотя можно зайти слишком далеко, не бойтесь концепции в целом. Так какие же преимущества этого мониторинга / тестирования для вас и вашего клиента?

1. Каким-то образом не все лучшие в мире тесты могут предсказать странные вещи, которые будут делать пользователи, намеренно или просто благодаря цифрам (если 1 миллион обезьян на пишущих машинках может написать «Гамлет», представьте, что несколько сотен счастливых кликов что могут сделать пользователи? Проверка связи с сайтом может подсказать, работает ли он, но не в том случае, если таблица повреждена и отчет не работает, и все потому, что пользователь ввел значение с умлаутом в нем.

2. Хотя ваш сайт может отлично работать на промежуточных серверах, возможно, со временем он начнет ухудшаться. Если вы отслеживаете эффективность этих тестов на селен, вы можете опередить жалобы на медлительность. Конечно, как вы упомянули, убедитесь, что ваш мониторинг также не вызывает проблем! Возможно, вам придется убедить вашего клиента в том, что определенные тесты подходят для выполнения каждые X минут, а другие должны выполняться только один раз в день, в 3 часа утра .

3. Если вы в конечном итоге внесете экстренное изменение в действующий сайт, вы будете более уверены в том, что тесты выполняются, чтобы убедиться, что все в порядке.

Answer 2

Я давно работаю на аналогичных производственных серверах. Исходя из моего опыта, я могу сказать, что всегда лучше тестировать наши изменения / исправления изменений в среде Stage и просто развертывать их на рабочих серверах. Это связано с тем, что и промежуточные, и производственные среды одинаковы, за исключением объема данных. Если это действительно необходимо, было бы неплохо запустить несколько тестов на производственных серверах после установки кода / патча. Но не рекомендуется / хороший способ запускать тесты всегда на рабочем сервере.

Answer 3

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

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

[править], чтобы убедиться, что сайт работает, вы можете написать простую программу, которая пингует ее каждые 10 минут, вместо того, чтобы запускать весь ваш набор тестов.

Answer 4

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

Кроме того, может быть небезопасно предполагать, что, если поставщик услуг не испытывает каких-либо проблем, сайт функционирует должным образом. Что делать, если сайт завален запросами? Или, может быть, SQL, который отлично работает в тесте, начинает вызывать проблемы (тайм-ауты, блокировки и т. Д.) С большой производственной базой данных?

Answer 5

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

Answer 6

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