Управление несколькими браузерами, которые взаимодействуют друг с другом

Question

У нас есть сложное веб-приложение, которое использует много JavaScript вместе с XMPP и Rails-приложением. Это дошло до того, что нам нужно протестировать всю систему из конца в конец. Мы должны иметь возможность гарантировать, что различные задачи могут быть выполнены без ошибок, одной из таких задач было бы обсуждение сеанса чата 1 на 1 с другой стороной в системе. Поскольку все задачи нашего приложения позволяют пользователю взаимодействовать с пользователем, мы хотели бы иметь возможность имитировать это, одновременно управляя двумя браузерами, которые обмениваются данными через веб-приложение. Я подумывал использовать селен или watir и их функции ожидания, чтобы дождаться конкретных событий, прежде чем продолжить. Например:

1. открытые браузеры 2 на нашем сайте
2. браузер 1 ожидает вопрос будет опубликован
3. браузер 2 публикует вопрос, то ждет предложение, чтобы получить
4. браузер 1 видит вопрос, направляет предложение и ждет, чтобы он был принят
5. браузер 2 видит предложение и принимает его, то ждет сеанса чата, чтобы начать
6. и т.д ...

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

Итак, мой вопрос: кто-нибудь пробовал такое тестирование? Если да, то какие инструменты вы бы предложили использовать и у вас есть какие-либо советы по написанию тестов?

Нам нужно будет управлять фактическими браузерами, а не без головы, и для этого необходимо будет интегрировать это с нашим CI, в настоящее время мы используем Sauce Labs и селен в рамках нашей установки CI.

Answer 1

Чтобы быть честным, это звучит так, как будто оно принадлежит к категории «Somethings не должно быть автоматизировано».

Прогнозируемые вопросы:

• Один из браузеров не раскручивается должным образом, возможно, поставив другой браузер в тупиковой ситуации, пока время ожидания

• Если по какой-то причине ваш тест не Ждут» t получить весь путь, потому что ваш веб-сервер решил просто быть медленным, вы получите еще один тупик до тайм-аута.

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

Я уверен, что есть еще вопросы, но не могу думать из них прямо сейчас.

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

С помощью системы чата я проверил бы это вручную, и это то, где собака с вашим приложением станет самостоятельной.Получите всех в компании (от разработчика до ops и за ее пределами), чтобы проверить чат, потому что я уверен, что вы уже делаете IM что-то вроде.

Answer 2

У нас есть аналогичная (на самом деле более сложная установка) с iMacros Scripting Edition. Команды iimInit/iimPlay дают нам полный контроль над веб-браузером и подробными кодами ошибок.

Если один из браузеров не работает правильно, iimPlay вернет код ошибки, и мы сможем действовать соответствующим образом.

Главный недостаток iMacros заключается в том, что редакция сценариев является только Windows (хорошо для нас, когда мы работаем с ASP.NET). Но если это проблема для вас, попробуйте WatiR. Что бы вы ни использовали, хорошо Ошибка Коды возврата являются ключом к успеху.