Сообщений в теме: 12

[nazarov]

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

[Clauster]

А что не получается-то? Или вы в школе операторы ветвления не проходили?

[Tiana]

1. Выполнить действие.
2. Анализ текущей ситуации.
3. Оценка текущего и желаемого результата. Оператор IF и описание дальнейших действий для каждого условия.

[nazarov]

)) Я думал может есть возможность писать примерно так:

"Сделать"
Window SetContext, "Caption=Тест;Class=TfmMain", ""
GenericObject Click, "Text=ActionMainMenuBar1", "Coords=86,10"
"Не получилось"
начало
SQALogMessage...
Exit Sub
конец
"Получилось"
SQALogMessage...
.....

[Nadezhda]

Чтобы скрипт, как вы выразились, не глохнул, нужно выбрать опцию Continue Execution в Tool/GUI Playback Options/Error Recovery.
Насколько мне известно, аналога try-catch в SQABasic нет. Для того, чтобы "попробовать" что-то сделать, можно предположить, что может вам помешать это сделать. Например, вы не уверены, что элемент, по которому вам нужно кликнуть, присутствует. Тогда нужно использовать функцию SQAFindObject, и только если она даст положительный результат, продолжать действовать. Это предупреждающий подход.
Конечно, не всегда можно предсказать, что может помешать выполнить то или иное действие. Тогда нужно использовать подход, который описала Tiana, т.е. после выполнения действия анализировать, выполнилось ли оно в действительности.

[nazarov]

Я так и знал.

[Tiana]

Чтобы скрипт, как вы выразились, не глохнул, нужно выбрать опцию Continue Execution в Tool/GUI Playback Options/Error Recovery.

Тут я не совсем согласна. Если функциональность в приложении взаимозависима, т.е. нельзя перейти к следующему шагу без корректного завершения предыдущего или сложно спрогнозировать результат, то выбор опции Continue Execution/Skip Current Script/Abort Playback зависит от степени связности выполняемых процедур/функций.
На мой взгляд, опция Skip Current Script может быть более удобна при соответствующей организации скриптов. Т.е в пределах одного скрипта вызываются взаимозависимые функции. Если где-то происходит сбой, ошибка записывается в лог, затем начинается выполнение следующего скрипта, успешность выполнения которого, не зависит от сбоя в предыдущем скрипте.

Насколько мне известно, аналога try-catch в SQABasic нет.

Можно покопаться в "On Error Statement".

Nadezhda, а чем отличается этот подход:

Для того, чтобы "попробовать" что-то сделать, можно предположить, что может вам помешать это сделать. Например, вы не уверены, что элемент, по которому вам нужно кликнуть, присутствует. Тогда нужно использовать функцию SQAFindObject, и только если она даст положительный результат, продолжать действовать. Это предупреждающий подход.

от этого:

1. Выполнить действие. (к примеру, загрузить страницу)
2. Анализ текущей ситуации. (страница загружена или нет)
3. Оценка текущего и желаемого результата. (проверка контента страницы, наличия объектов, значений их свойств). Оператор IF и описание дальнейших действий для каждого условия. (продолжать действовать, но то, как действовать, зависит от каждого случая/результата).

По-моему суть одна, а по-вашему выходит, что подхода два

[Nadezhda]

В описанных подходах суть действительно одна, а разница в том, что я предложила проверять возможность выполнения действия до выполнения действия. Т.е. получается сначала пункт 2 - анализируем ситуацию, потом 3 - сравниваем ожидаемый и полученный результаты, и потом по одной из веток IF пункт 1 - выполняем действие.

Если функциональность в приложении взаимозависима, т.е. нельзя перейти к следующему шагу без корректного завершения предыдущего или сложно спрогнозировать результат, то выбор опции Continue Execution/Skip Current Script/Abort Playback зависит от степени связности выполняемых процедур/функций.
На мой взгляд, опция Skip Current Script может быть более удобна при соответствующей организации скриптов.

Согласна. Мне следовало написать не "нужно", а "можно" выбрать указанную опцию. Все зависит от конкретной ситуации.

[Tiana]

Т.е. получается сначала пункт 2 - анализируем ситуацию, потом 3 - сравниваем ожидаемый и полученный результаты

Сами себя запутали :) Обычно анализируется ситуация, после выполнения действия, для возможности выполнения следующего действия (цикл). Вроде такого - мы же не можем анализировать была ли корректно загружена страница до того, как мы выполнили действие "загрузить страницу".
Мы анализируем корректность загрузки страницы и возможность входа в пользователя в систему (к примеру), и затем уже выполняем вход пользователя в систему и проверяем выполнение входа и т.д.

[Nadezhda]

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

Здесь вы объединили оба варианта

мы же не можем анализировать была ли корректно загружена страница до того, как мы выполнили действие "загрузить страницу". 

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

Мы анализируем корректность загрузки страницы

Это анализ после выполнения действия "загрузка страницы"

и возможность входа в пользователя в систему

а это - до выполнения действия "вход пользователя".

Например, для анализа корректности загрузки мы можем проверить название страницы или окна браузера, а для проверки возможности входа пользователя в систему - наличие и доступность полей ввода логина и пароля и кнопки "Войти". Причем не обязательно корректная загрузка страницы будет обозначать возможность выполнения входа пользователя.

[Tiana]

Обсуждение напоминает мне "что раньше было яйцо или курица".

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

Здесь вы объединили оба варианта

Здесь я описала более детально описанный мною выше подход. Что сначала все-таки есть действие. Ведь с чего вы начинаете выполнение ваших скриптов, сразу с проверки или все-таки с действия (загрузка браузера/страницы)? Думаю, что с загрузки браузера. После чего будет следовать набор проверок и соответствующих последующих действий.

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

Было ли какое-то действие перед тем, как ссылка появилась? Думаю, что было. Т.е. сначала все таки "действие", которое привело к появлению необходимой Вам ссылки.

Тут бы я немного перефразировала:

Мы анализируем корректность загрузки страницы

Это анализ после выполнения действия "загрузка страницы"

и возможность входа в пользователя в систему

а это - до выполнения действия "вход пользователя".

вот так:
Анализ корректности загрузки страницы - это анализ после выполнения действия "загрузка страницы". Возможность входа пользователя в систему - это анализ после действия "загрузка страницы" и до действия "вход пользователя в систему".

Например, для анализа корректности загрузки мы можем проверить название страницы или окна браузера, а для проверки возможности входа пользователя в систему - наличие и доступность полей ввода логина и пароля и кнопки "Войти". Причем не обязательно корректная загрузка страницы будет обозначать возможность выполнения входа пользователя.

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

[Nadezhda]

[Tiana]

Да, только каких усилий это стоило!