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

Question

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

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

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

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

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

Answer 1

Честно говоря, это звучит так, как будто это относится к категории "Что-то не должно быть автоматизировано".

Предвидимые проблемы:

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

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

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

Я уверен, что есть больше проблем, но не могу думать о них прямо сейчас.

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

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

Answer 2

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

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

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