Документация и быстрый старт: RTHelper

Что такое RTHelper

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

Типовой рабочий цикл в RTHelper выглядит так:

Выбрать режим захвата: Web или UIA.
Добавить приложение в дерево.
Захватить нужные элементы интерфейса.
Перетащить элементы на панель Алгоритм.
Выбрать действие у каждого шага и заполнить параметры.
Запустить сценарий через Play или Debug.

Быстрый старт: первый полезный сценарий

Выберите Web или UIA и добавьте приложение в дерево.
Захватите 4 элемента: логин, пароль, кнопку входа и элемент «успешного входа».
Соберите цепочку: Write -> Write -> Click -> Wait -> Read -> Assert.
Прогоните через Debug, затем запустите 3 раза подряд через Play.

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

Для браузера

Сценарии поверх веб-страниц с использованием браузерного расширения RTHelper.

Для Windows-приложений

Сценарии для Windows-приложений через UI Automation.

Для сквозных проверок

В одном алгоритме можно сочетать действия в интерфейсе, ожидания, переменные, API и скриншот-тестирование.

Установка и первый запуск

Установка занимает несколько минут. Для первого знакомства достаточно приложения RTHelper и одного небольшого сценария.

Скачайте и установите приложение для Windows.
Если вы планируете автоматизировать веб-страницы, установите браузерное расширение RTHelper.
Запустите приложение и выполните вход в аккаунт.
Создайте новый проект или откройте существующий.

Для Web-режима нужно расширение браузера

Установите расширение в Chrome/Edge или Firefox, затем перезапустите браузер.

Тестовый проект для быстрого старта

Скачайте готовый пробный проект для ознакомления: test_project.rtwf. Затем откройте его в RTHelper через Открыть проект. В проекте уже есть Web-шаги. Для запуска в Edge или Chrome обязательно установите расширение RTHelper.

Web подходит для браузеров и сайтов.
UIA подходит для Windows-приложений.
UIA и ImageCompare доступны в Free; Recorder, InvokeApi, Debug, Breakpoint, Code и экспорт логов/отчётов относятся к возможностям Pro.

Что есть в интерфейсе

Интерфейс собран вокруг одного процесса: найти элементы, собрать шаги, настроить параметры и проверить запуск.

Дерево элементов

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

Панель «Алгоритм»

Список действий в порядке выполнения. Каждый шаг описывает действие над элементом или специальную операцию, например Wait.

Параметры шага

Здесь задаются аргументы действия: текст, путь к файлу, режим сравнения, таймаут, переменная результата.

Журнал выполнения

Показывает запуск по шагам, результат и текст ошибки. Это главная точка для разбора падений.

Почти весь сценарий собирается мышкой: сначала вы формируете дерево элементов, потом перетаскиваете нужные узлы на панель Алгоритм и выбираете действия.

Захват приложения и элементов

Захват объясняет RTHelper, с какими полями, кнопками и текстами должен работать сценарий.

Выберите тип захвата: Web или UIA.
Обновите список приложений.
Выберите нужное приложение в списке.
Нажмите Добавить приложение, чтобы поместить его в дерево.
Нажмите Выбрать элемент, чтобы войти в режим захвата.
Перейдите в нужное окно или вкладку.
Нажмите Ctrl, чтобы захватить выбранный элемент.
Нажмите Esc, чтобы выйти из режима захвата.

Для первого сценария обычно достаточно 3-5 элементов: поле ввода, кнопка, текст результата и, при необходимости, контейнер или окно.

Лучший подход: захватывать элементы с максимально стабильными атрибутами. Если у элемента постоянно меняются текст, индекс или часть id, такой локатор позже станет причиной нестабильных запусков.

Recorder: запись шагов

Recorder полезен, когда проще показать сценарий, чем собирать его с нуля. Включите запись, выполните действия как обычно, а затем доработайте получившийся алгоритм: добавьте ожидания, проверки и переменные. Recorder доступен в Pro.

Что делает Recorder

Собирает действия пользователя в Web и UIA-режимах.
Добавляет шаги в алгоритм в порядке выполнения.
Автоматически подтягивает элементы в дерево, если их ещё нет.
Доступные действия записи: Click, DoubleClick, Write, SelectItem, а для UIA-контролов также Press и Toggle.

Когда использовать

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

Как работать с Recorder

Выберите режим захвата: Web или UIA.
Выберите целевое приложение.
Нажмите REC и выполните нужные действия.
Нажмите STOP REC: шаги будут добавлены в алгоритм.
Проверьте и донастройте параметры шагов (ожидания, проверки, переменные).

Recorder даёт стартовую версию, а не финальный тест. После записи добавьте Wait, проверьте локаторы и прогоните сценарий в Debug перед регулярными запусками.

UIA и ComboBox

В UIA Recorder поддерживает запись выбора значения из выпадающего списка: при выборе пункта формируется шаг SelectItem(value) для UiaComboBox.

Как строить надёжный алгоритм

Надёжный сценарий не просто повторяет клики. Он умеет найти нужный элемент, дождаться готовности интерфейса и проверить результат. Если этой логики нет, сценарий может пройти один раз у автора и упасть на следующем прогоне.

Что такое атрибуты элемента

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

Почему сценарии падают

Обычно причина не в самом клике, а в нестабильном локаторе или в том, что следующий шаг выполняется раньше, чем интерфейс успел обновиться.

Как выбирать атрибуты

Оставляйте минимальный набор стабильных признаков, которых достаточно для поиска элемента.
Для Web в первую очередь смотрите на устойчивые id, name, data-*, aria-*, предсказуемый текст и понятный родительский контейнер.
Для UIA в первую очередь полезны AutomationId, Name, ControlType, стабильное окно или контейнер.
С осторожностью используйте MatchIndex, динамический текст, автогенерируемые классы и значения, которые меняются от запуска к запуску.
Если элемент можно однозначно найти по двум стабильным атрибутам, не добавляйте ещё пять лишних.

MatchIndex и MatchReverse: когда найдено несколько похожих элементов

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

Атрибут	Что делает	Когда использовать
`MatchIndex`	Выбирает совпадение по номеру. Значение `1` означает первый подходящий элемент в найденном списке.	Когда похожих элементов несколько, но нужный стабильно находится на известной позиции.
`MatchReverse`	Меняет направление выбора: RTHelper берёт элемент с конца списка совпадений.	Когда нужный элемент удобнее выбирать с конца, например последнюю строку таблицы или последнюю карточку в списке.

Включайте MatchIndex только если обычные атрибуты не могут однозначно найти элемент.
Если можно сузить поиск через Search Scope или стабильный атрибут, это обычно надёжнее индекса.
MatchReverse полезен вместе с индексом, когда важна позиция с конца списка совпадений.
После изменения этих параметров проверьте элемент через подсветку или короткий запуск сценария.

MatchIndex и MatchReverse зависят от порядка элементов. Если меняется сортировка, фильтр, пагинация, структура DOM или порядок окон, сценарий может выбрать другой элемент.

Search Scope: область поиска для элемента

Search Scope ограничивает область, где RTHelper ищет целевой элемент. Если у шага задан scope-элемент, поиск и кнопка «Подсветить» в дереве работают только среди дочерних элементов выбранной области.

Выберите шаг с целевым элементом в алгоритме.
В панели атрибутов заполните поле для scope-элемента (область поиска).
Для scope укажите, по возможности, стабильные атрибуты, а не только один XPath.
Проверьте через «Подсветить», что целевой элемент находится внутри выбранной области.

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

Хороший локатор легко объяснить: вы можете словами сказать, почему этот элемент будет найден завтра. Если объяснение звучит как «он сейчас третий в списке» или «у него такой XPath», то локатор, скорее всего, хрупкий.

Когда использовать XPath

В веб-сценариях XPath лучше считать запасным вариантом, а не основой. Он полезен, когда у элемента нет нормальных стабильных атрибутов, но длинные XPath часто ломаются после перестройки DOM, вставки нового контейнера или изменения вёрстки. Если можно найти элемент по устойчивым атрибутам или более простой и понятной структуре, это почти всегда надёжнее.

Зачем нужен Wait

Wait не просто задержка. Он нужен для синхронизации алгоритма с приложением. После клика интерфейс может ещё загружаться, менять текст, открывать диалог или перестраивать DOM. Если в этот момент сразу выполнить следующий шаг, сценарий будет падать случайно.

Ставьте Wait после действий, которые меняют экран: логин, переход, сохранение, открытие диалога, загрузка таблицы.
Ждите бизнес-результат: появление нужного элемента, изменение текста, исчезновение лоадера, активацию окна.
Не лечите синхронизацию только фиксированной задержкой. Задержка не знает, готов ли интерфейс на самом деле.

Практическое правило

Плохая цепочка: Click -> Read

Надёжная цепочка: Click -> Wait -> Read -> Assert

Как собрать алгоритм

Алгоритм в RTHelper читается почти как ручной тест-кейс: шаг за шагом, в порядке выполнения.

Перетащите захваченный элемент из дерева на панель Алгоритм.
Выберите тип элемента и действие в списках шага.
Заполните параметры в правой панели.
Повторите для остальных шагов.
Если нужен служебный шаг, добавьте его через кнопку + над алгоритмом.

Какие специальные шаги есть

Wait: ожидание условия.
Assert: сравнение двух значений.
LoadData: загрузка переменных из файла.
InvokeApi: вызов API и проверка ответа.
ImageCompare: скриншот-тестирование.
Code: вставка небольшого C#-фрагмента для проверки или преобразования данных.

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

Первый алгоритм: пошагово

Видеоурок: первый алгоритм в RTHelper

Посмотрите короткий ролик с практическим разбором первого небольшого алгоритма.

Ниже пример хорошего стартового сценария: вход в приложение или на сайт.

Что нужно захватить заранее

Поле логина.
Поле пароля.
Кнопку входа.
Элемент, который появляется после логина: заголовок, имя пользователя, dashboard, статусный текст.

Как собрать сценарий

Перетащите поле логина на панель Алгоритм, выберите действие Write.
В параметре текста укажите тестовый логин.
Перетащите поле пароля и выберите Write.
Перетащите кнопку входа и выберите Click.
Добавьте шаг Wait и настройте ожидание появления нужного элемента или изменения текста.
Если нужно прочитать результат, добавьте шаг Read и сохраните его в переменную.
Добавьте Assert или используйте встроенную проверку результата.
Запустите сценарий через Debug, пройдите его по шагам и убедитесь, что каждое действие отрабатывает в нужный момент.

Минимальный вариант

Write login -> Write password -> Click -> Wait -> Read -> Assert

Если это первый проект

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

Как понять, что первый алгоритм действительно готов

Он проходит минимум 3 запуска подряд без ручной помощи.
После действий, которые меняют экран, стоит Wait, а не только фиксированная задержка.
Проверяется бизнес-результат: текст, статус, элемент после входа, API-ответ или сравнение изображения.
Данные вынесены в переменные, а не зашиты в каждом шаге.

Если первый запуск не проходит

Симптом	Чаще всего причина	Что сделать
Шаг `Click` не находит элемент	Нестабильные атрибуты или захвачен не тот узел	Перезахватить элемент, оставить только стабильные признаки (`id`, `name`, `AutomationId` и т.п.)
`Read` возвращает пусто или старое значение	Чтение выполняется раньше обновления интерфейса	Добавить `Wait` на появление/изменение нужного элемента, затем повторить чтение
Сценарий проходит у автора и падает на другом ПК	Зависимость от таймингов, фокуса окна или динамических локаторов	Заменить фиксированные задержки на условия `Wait`, уточнить локаторы, добавить проверку результата
Падает непонятно где	Нет пошаговой диагностики	Включить `Debug`, поставить `Breakpoint` перед проблемным шагом, смотреть журнал выполнения

Общие настройки шага

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

Настройка	Для чего нужна
`Обязательный`	Если включено, ошибка шага останавливает алгоритм. Если выключено, ошибка будет записана в журнал, а сценарий попробует идти дальше.
`Пауза перед шагом`	Фиксированная пауза перед стартом шага в миллисекундах. Шаг всегда ждёт это время, даже если элемент уже готов.
`Ждать элемент`	Таймаут auto-wait перед действием. RTHelper повторяет поиск элемента в течение указанного времени и продолжает сразу, если элемент найден раньше. По умолчанию используется `800` мс, максимум `5000` мс, значение `0` отключает auto-wait.
`Переменная`	Сохраняет результат шага в переменную.
`Breakpoint`	Ставит остановку перед шагом в режиме пошагового выполнения.
`Выполнить шаг`	Позволяет прогнать только один конкретный шаг.

Пауза и auto-wait: в чём разница

Пауза перед шагом нужна редко: это жёсткая задержка, которая всегда замедляет сценарий. Ждать элемент мягче: шаг не ждёт лишнее время, если элемент уже появился, но даёт интерфейсу небольшой запас при загрузке, анимации или обновлении таблицы.

Для обычных кликов, ввода и чтения чаще оставляйте auto-wait включённым.
Если элемент появляется медленнее пяти секунд, добавьте отдельный шаг Wait с понятным условием.
Для специальных шагов без целевого элемента используйте их собственные параметры, например Timeout у Wait.

Встроенная проверка результата

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

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

Переменные и LoadData

Переменные помогают не зашивать данные в каждый шаг и передавать результаты между действиями. В RTHelper они подставляются через префикс $$.

Как использовать переменные

Укажите у шага имя переменной результата, например UserNameText.
В следующем шаге используйте её как $$UserNameText.
Переменные можно подставлять в текст, пути к файлам, проверки, условия ожидания и параметры шагов.
Можно объединять переменные и текст, например $$var + "some val".

Примеры

$$Login: логин для шага Write.
$$ExpectedTitle: ожидаемый заголовок в Assert.
$$ReferencePath: путь к эталонному изображению для ImageCompare.

Шаг LoadData

Шаг LoadData подгружает переменные из .csv, .xls или .xlsx.

Первый столбец: имя переменной.
Второй столбец: значение.
Каждая строка с непустым именем загружается в контекст выполнения.

Это самый удобный способ отделить тестовые данные от логики сценария.

Как работает Wait

Wait помогает синхронизировать сценарий с интерфейсом. Он ждёт не «на всякий случай», а до конкретного условия: появления элемента, изменения текста, готовности окна или другого признака, который важен для сценария.

Что делает Wait

Получает таймаут в миллисекундах.
Проверяет одно или несколько условий.
Если условий несколько, логика работает как OR: достаточно первого совпадения.
Если ни одно условие не выполнено до конца таймаута, шаг завершается ошибкой.

Как настроить шаг Wait

Добавьте шаг Wait.
Укажите Timeout.
Добавьте одно или несколько условий ожидания.
Для каждого условия задайте элемент, тип условия, тип сравнения, имя атрибута и значение.

Тип условия	Когда использовать
`CheckExists`	Когда нужно дождаться появления или исчезновения элемента.
`CheckUIA`	Когда нужно сравнить значение свойства элемента.
`GetWindowText`	Когда нужно дождаться конкретного текста у окна.
`Focused`	Когда важно дождаться фокуса на элементе.
`Active`	Когда нужно дождаться активности элемента.
`WindowLoaded`	Когда нужно убедиться, что окно полностью готово.

Типы сравнения в Wait

Equal: строгое совпадение.
NotEqual: несовпадение.
Regex: сравнение по регулярному выражению.
Wildcard: шаблон со знаками *, ? и #.

Если вы сохраняете результат Wait в переменную, туда попадёт индекс первого сработавшего условия. Если условий не было, полезного результата такой шаг не даёт.

Debug и Breakpoint

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

Кнопка	Что делает
`Play`	Запускает алгоритм без остановок.
`Debug`	Запускает алгоритм в пошаговом режиме.
`Pause`	Ставит текущий запуск на паузу.
`Next step`	Выполняет один следующий шаг.
`Continue`	Выходит из пошагового режима и продолжает обычный запуск.
`Stop`	Останавливает выполнение.

Breakpoint

Breakpoint ставится на конкретный шаг. Когда выполнение доходит до него, алгоритм останавливается перед шагом, а вы можете проверить параметры, переменные и состояние интерфейса.

Ставьте Breakpoint перед нестабильными шагами: клик по важной кнопке, ввод в поле, ожидание, визуальное сравнение.
После успешной отладки снимайте лишние Breakpoint, чтобы рабочий сценарий запускался без остановок.

История и статусы запусков

В RTHelper есть встроенная история запусков проекта: вы видите не только факт прохождения, но и режим, длительность, ошибку и подробности по каждому шагу. Это удобно для регрессии и разбора нестабильных сценариев.

Где открыть историю

Откройте менеджер проектов (кнопка с названием текущего проекта в верхней панели).
Нажмите Запуски.
В таблице выберите нужный прогон и нажмите Открыть.

Что показывается в истории

Поле	Что означает
`Date`	Дата и время завершения (или старта) запуска.
`Status`	Итог: `Passed`, `Failed` или `Cancelled`.
`Duration`	Сколько длился прогон.
`Error`	Текст первой критичной ошибки (если запуск упал).
`Mode`	Режим запуска: обычный `Run` или пошаговый `Debug`.
`Steps (total / failed)`	Сколько шагов выполнилось и сколько завершилось ошибкой.

Детали конкретного прогона

Список шагов с их состоянием и деталями ошибки/результата.
Скриншот падения (если он был сохранён во время выполнения).
Быстрый переход назад к общей истории запусков проекта.

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

Студия запусков

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

Важно: smoke в RTHelper — это не отдельный магический режим, а обычный набор сценариев, который вы сами называете и наполняете. Такой подход проще поддерживать: команда видит, что именно входит в smoke, в каком порядке это запускается и какие сценарии требуют внимания.

Когда использовать

Перед релизом или деплоем

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

Для регулярной регрессии

Разделите большую проверку на понятные наборы: авторизация, корзина, платежи, профиль, интеграции.

Для разбора нестабильности

Смотрите стабильность именно по запускам набора, время выполнения и сценарии, которые требуют внимания.

Для передачи результата команде

Экспортируйте фактический прогон в JSON, JUnit XML или Allure, чтобы сохранить контекст и результаты.

Как создать набор

Откройте Студию запусков из верхней панели.
Нажмите Новый.
Откройте фильтр Все и отметьте сценарии, которые должны входить в набор.
При необходимости измените порядок сценариев кнопками вверх/вниз на карточках.
Задайте понятное имя: например, Smoke checkout, Auth regression или Release 1.8 critical.
Сохраните набор.

Как запускать набор

Выберите сохранённый набор в левой колонке.
Укажите метаданные прогона: окружение, версию билда, цель запуска и комментарий.
Если нужно остановиться на первой ошибке, оставьте включённой опцию остановки очереди при падении.
Нажмите Запустить набор.
После прогона откройте быстрые ссылки на упавшие сценарии, чтобы перейти в подробности запуска.

Что означают метрики

Метрика	Как читать
`Стабильность`	Процент успешных запусков именно этого набора. Успешным считается прогон без ошибок и пропусков.
`Время выполнения`	Длительность последнего прогона набора. Помогает замечать, когда smoke или регрессия становятся слишком тяжёлыми.
`Требуют внимания`	Сценарии, у которых последний запуск упал или накопилась низкая стабильность. Подсказка показывает критерии и названия сценариев.
`Сценарии`	Количество сценариев в текущем наборе. Порядок карточек соответствует порядку запуска.

Экспорт и импорт

Экспорт набора сохраняет состав набора вместе со сценариями, чтобы его можно было перенести на другой компьютер или передать коллеге.
Импорт набора восстанавливает набор и добавляет отсутствующие сценарии, если они были в экспортированном файле.
Экспорт результатов прогонов в CSV, JSON, JUnit XML и Allure доступен в Pro.
CSV удобен для быстрой таблицы по последнему прогону.
JSON хранит human-readable структуру фактического прогона: набор, метаданные, порядок сценариев, длительности, ошибки, шаги и скриншоты.
JUnit XML подходит для CI-систем, которые умеют показывать тест-кейсы и падения в привычном формате.
Allure подходит, если команда собирает Allure-отчёты: туда попадают детали сценариев и environment.properties с окружением, билдом и целью запуска.

Хорошая практика: перед релизным прогоном заполните окружение и версию билда. Через неделю это часто важнее, чем сам факт падения: так проще понять, где именно воспроизвести ошибку и к какому деплою относится отчёт.

Тихий запуск и CI

Когда сценарий уже стабильно проходит в редакторе, его можно запускать без открытия интерфейса RTHelper. Это удобно для регулярной регрессии, локальных smoke-проверок и подключения к CI-пайплайну.

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

Запуск из файла

После установки RTHelper файл .rtwf можно запускать из Проводника: нажмите по файлу правой кнопкой мыши и выберите Запустить. В Windows 11 этот пункт может быть скрыт в классическом меню, поэтому сначала выберите Показать дополнительные параметры, а затем Запустить.

Базовая команда

RTHelper.exe --silent "C:\Tests\smoke.rtwf"

В этом режиме RTHelper читает сохранённый файл проекта, выполняет алгоритм и выводит краткий итог в консоль: состояние запуска, количество шагов, ошибки и длительность.

Полезные параметры

Параметр	Что делает
`--log "C:\Tests\smoke.log"`	Сохраняет обычный текстовый журнал выполнения.
`--junit "C:\Tests\junit.xml"`	Экспортирует результат в JUnit XML для CI-систем и отчётов о тестах.
`--allure "C:\Tests\allure-results.zip"`	Сохраняет Allure-результаты в zip-файл или указанную папку.
`--summary-json "C:\Tests\summary.json"`	Сохраняет структурированный JSON с итогом запуска и деталями шагов.
`--fail-on-step-failure`	Возвращает ненулевой код завершения, если хотя бы один шаг завершился ошибкой. Это главный флаг для CI.
`--quiet`	Отключает подробный вывод каждого шага в консоль.

Пример для регулярного прогона

RTHelper.exe --silent "C:\Tests\smoke.rtwf" --junit "C:\Tests\junit.xml" --summary-json "C:\Tests\summary.json" --fail-on-step-failure

Используйте --junit, если CI умеет показывать результаты тестов из JUnit XML.
Используйте --allure, если команда собирает Allure-отчёты.
Используйте --summary-json, если нужен собственный разбор результата или интеграция с внутренними инструментами.
Если запуск падает только в тихом режиме, сначала проверьте доступность приложения, расширение браузера, права пользователя и пути к файлам данных.

Тихий запуск не заменяет отладку. Сначала доведите сценарий до стабильного состояния через Debug, Wait, устойчивые атрибуты и историю запусков, а затем переносите его в регулярный прогон.

Нотация SendKeys

Шаг SendKeys понимает не только обычный текст, но и специальные клавиши, модификаторы и группы.

Что отправить	Как записать
Обычный текст	`Hello`
Enter, Tab, Esc, Delete	`{ENTER}`, `{TAB}`, `{ESC}`, `{DEL}`
Повтор клавиши	`{ENTER 3}`
Ctrl, Shift, Alt	`^a`, `+a`, `%a`
Комбинация для группы	`^(abc)`, `%({F4})`, `+({TAB})`
Фигурные скобки как текст	`{{` для `{` и `{}}` для `}`

Практические примеры

^{HOME}^+{END}{DEL}: выделить весь текст и удалить.
{TAB}{TAB}{ENTER}: перейти по форме и нажать Enter.
^(a): выбрать всё.

Параметр secInterval задаёт задержку между нажатиями в секундах, если вам нужно вводить текст медленнее.

Скриншот-тестирование через ImageCompare

ImageCompare нужен для визуальной проверки интерфейса. Он умеет работать в трёх режимах: сравнивать весь экран, искать эталон на экране и сравнивать конкретный выбранный элемент.

Режим	Когда использовать
`CompareScreen`	Когда нужно сравнить весь текущий экран с эталоном.
`FindOnScreen`	Когда нужно найти маленький эталонный фрагмент внутри текущего экрана.
`CompareElement`	Когда нужно сравнивать только выбранный элемент, а не весь экран.

Как настроить

Укажите ReferencePath: путь к эталонному изображению.
Выберите режим.
Задайте SimilarityThreshold, например 0.98.
Если нужно, укажите SaveDiffPath, чтобы сохранять diff-файл.
Для CompareElement обязательно привяжите элемент к шагу.
Для записи эталона используйте кнопку Record.

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

Видеоурок: пример работы со скриншот-тестированием

API-проверки через InvokeApi

Шаг InvokeApi позволяет проверять HTTP API прямо в алгоритме: отправлять запрос, валидировать статус и тело ответа, а также сохранять нужные части ответа в переменные для следующих шагов. Эта возможность входит в Pro.

Как добавить и настроить шаг

Нажмите + над списком алгоритма и добавьте специальный шаг InvokeApi.
В параметрах шага укажите Url и Method.
При необходимости заполните Headers, ContentType и Body.
Для встроенной проверки статуса задайте ExpectedStatus и оператор сравнения CompareSignStatus.
Для проверки тела ответа задайте ExpectedBody и CompareSignBody.

Сохранение полей ответа в переменные

В блоке сохранения результата можно добавить несколько строк и для каждой указать: имя переменной и поле ответа, которое нужно сохранить.

Поле	Что будет сохранено	Когда использовать
`Body`	Тело ответа целиком (строка).	Когда нужно передать весь ответ в следующий шаг.
`ResponseTime`	Время выполнения запроса.	Для проверок SLA или сравнения производительности.
`StatusCode`	HTTP статус-код.	Для ветвления сценария и дополнительных проверок.
`JsonBody`	Значение конкретного поля из JSON-тела.	Когда нужно достать отдельный ID, токен, флаг и другое поле.

Для варианта JsonBody укажите путь к полю в формате данных шага, например: Data.data.items[0].id.

Практика: храните URL, токены, ожидаемые значения и пути к JSON-полям в переменных и подставляйте через $$. Так API-сценарии проще поддерживать между окружениями.

Видеоурок: пример работы с API-проверками

Code-шаг для C#-логики

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

Используйте Code как точечное расширение сценария, а не как замену всему алгоритму. Основной поток лучше оставлять читаемым: UI-шаги, Wait, Assert, InvokeApi и ImageCompare должны быть видны в алгоритме.

Когда это полезно

Нужно привести значение к единому формату перед Assert.
Нужно собрать строку, JSON-фрагмент или вычисляемый параметр из нескольких переменных.
Нужно выполнить проверку, для которой неудобно заводить отдельный UI- или API-шаг.
Нужно сохранить результат вычисления в переменную и использовать его дальше через $$.

Практическое правило

Хороший Code-шаг короткий и объяснимый. Если фрагмент растёт до отдельного мини-приложения, лучше вынести логику в обычный C#-проект после экспорта или пересобрать сценарий из более понятных шагов.

Практические советы для стабильных сценариев

Сначала ждите, потом кликайте

Если интерфейс асинхронный, перед действием почти всегда нужен Wait, иначе сценарий будет падать случайно.

Храните данные отдельно

Логины, пароли, URL, ожидаемые тексты и пути к эталонам лучше выносить в LoadData и использовать через $$.

Проверяйте результаты сразу

Если шаг что-то возвращает, включайте встроенную проверку результата или ставьте Assert сразу после чтения.

Отлаживайте короткими прогонами

Новый сценарий лучше сначала собирать и запускать по 3-5 шагов, а не пытаться сразу отладить весь сквозной поток.

Оставляйте код точечным

Code-шаг удобен для небольших C#-проверок и преобразований, но основной сценарий должен оставаться понятным по шагам.

Переносите стабильные сценарии в тихий запуск

Когда сценарий прошёл отладку, запускайте его через --silent и сохраняйте отчёты для регулярной регрессии.

Чеклист перед тем как считать сценарий готовым

Сценарий проходит минимум несколько запусков подряд без ручного вмешательства.
На всех асинхронных участках есть Wait.
Ключевые шаги помечены как обязательные.
Основные результаты проверяются через Result Check, Assert или ImageCompare.
Данные вынесены в переменные, а не зашиты в десятках шагов.
Если используется Code, его назначение понятно по названию шага и он не скрывает основной поток сценария.
Для регулярного запуска подготовлена команда --silent с отчётом JUnit, Allure или summary-json.

Частые вопросы

С чего лучше начать: Web или UIA?

Если ваш сценарий живёт в браузере, начинайте с Web. Если это Windows-приложение, используйте UIA.

Можно ли построить первый сценарий без кода?

Да. Основной путь в RTHelper как раз рассчитан на визуальную сборку сценария через дерево элементов, панель «Алгоритм» и параметры шагов.

Когда использовать Assert, а когда встроенную проверку результата?

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

Почему сценарий работает нестабильно?

Чаще всего причина в отсутствии Wait, нестабильных локаторах, динамическом UI или в том, что сценарий пытается нажать на элемент до того, как он реально готов.

Что делать после первого рабочего алгоритма?

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