Я записываю сценарий в протоколе web / http, но при ответе получаю ошибки

Записав сценарий дважды и проверив различия вручную, я обнаружил, что в моих URL-адресах есть несколько «слушателей», например:

web_submit_data("bla_bla_2", 

            "Action=http://e34jbsl00267.somesone.se:8080/xxx/xxx/81174/xxx?5-1.IBehaviorListener.0-considerSomeList-considerSomeRepeater-4-considerSomeListItem-considerSomeMain-innerPanel-considerDetails-considerForm-considerRulesChoices",
            "Method=POST",

При удалении всего с конца по URL-адресу до 'xxx? 5-' сценарий воспроизводится нормально, но при наличии этих списков он не будет работать с ошибкой 500, а вставка URL-адреса выше в новом браузере дает мне ошибку страница, созданная из приложения.

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

Справка?

BR fugmag

0
Magnus Jensen 7 Фев 2013 в 17:35
А использование ajaxtruclient позволило воспроизвести сценарий. может быть, Truclient был разработан для таких богатых интернет-приложений ...
 – 
Magnus Jensen
7 Фев 2013 в 19:53
Решено. вместо этого выполните следующее: stackoverflow.com/questions/14780394/…
 – 
Magnus Jensen
9 Фев 2013 в 04:13
Проблема здесь продолжается: stackoverflow.com/questions/14780394/… Thanx
 – 
Magnus Jensen
9 Фев 2013 в 04:14

1 ответ

Лучший ответ

Запишите это дважды и сравните записи. ЕСЛИ отличается, то это подтвердит гипотезу корреляции. Обычно, когда происходит 500, запрещая искаженный запрос, он просто выходит из контекста с состоянием приложения из предыдущего запроса, возвращается неожиданная страница.

Вы можете перекрестно проверить неожиданную страницу, следуя стандартным методам тестирования, для каждого шага есть ожидаемый результат. Используйте web_reg_find () или web_reg_save_param () для проверки значений из каждого отправленного запроса страницы, который указывает, что ожидаемая страница была возвращена. Если ожидаемая страница не была возвращена, прервите поток сценария бизнес-процесса, очистите его, а затем либо вернитесь в бизнес-поток, либо перейдите к следующей итерации. (return (1); приведет к немедленному выполнению итерации системы без соблюдения темпа итерации)

0
James Pulley 7 Фев 2013 в 19:56
Хорошо, Джеймс. Результаты разные, но это так называемое многофункциональное интернет-приложение, как в Web 2.0, т.е. щелчок по некоторым элементам изменит «внешний вид» страницы, так как один щелчок приводит к появлению коллекции радиокнопок и так далее. Думаю, TruClient разработан для решения таких задач, и воспроизведение работает с использованием TruClient. также я попытался удалить «элементы» в приведенном выше фрагменте кода, и это сработало, но коллекция радиокнопок не отображалась в средстве просмотра во время воспроизведения, что указывает на то, что их удаление привело к тому, что элементы страницы не отображались.
 – 
Magnus Jensen
7 Фев 2013 в 22:38
Браузер воспроизведения не является полнофункциональным, поэтому считайте журнал достоверным. Поскольку у вас есть динамические элементы в игре, вполне вероятно, что вам нужно будет сопоставить элементы на линии. И да, TruClient - это путь для истинных асинхронных приложений. Можно иметь компоненты JaX (без A) и при этом иметь синхронный бизнес-процесс HTML.
 – 
James Pulley
7 Фев 2013 в 23:19
Хорошо, Джеймс, что вы имеете в виду под «коррелирующими элементами на линии»?
 – 
Magnus Jensen
7 Фев 2013 в 23:30
Значит, можно использовать протокол http со страницами Ajax, я так понимаю, вы имеете в виду? Не могли бы вы привести мне пример корреляции элементов в строке?
 – 
Magnus Jensen
8 Фев 2013 в 19:35
Корреляция потребует понимания всего сценария и будет здесь вне контекста поддержки коллег. Я обычно записываю трижды. Дважды с одинаковыми учетными данными и данными, а третий - с разными учетными данными и данными. Это гарантирует, что я могу идентифицировать все с помощью сеанса, состояния, времени и бизнес-процесса.
 – 
James Pulley
9 Фев 2013 в 03:59