Запись взаимодействия с пользователем для автоматизации тестирования Tcl Tk

Question

Я хочу провести несколько тестов в нашем приложении tcl tk относительно взаимодействия с пользователем. Поскольку в приложении есть части, похожие на САПР, для которых важно каждое движение мыши, я хотел бы сделать что-то вроде записи всех событий некоторых пользовательских взаимодействий. Моей целью было бы воспроизвести эти события позже и при каждом изменении программы, чтобы обнаружить потенциальные изменения. Или даже лучше убедиться, что GUI ведет себя всегда одинаково и выдает всегда одинаковые данные.

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

Есть ли возможность добиться этого?

Answer 1

Относительно легко записывать события определенных типов с bind - вы найдете это <ButtonPress>, <ButtonRelease>, <Enter>, <Leave>, <FocusIn>, <FocusOut>, <KeyPress> а также <KeyRelease> охватывайте практически все, что вас интересует, а затем воспроизводите их event generate, (Вам необходимо записать довольно много информации о каждом событии, чтобы правильно сгенерировать его, но базовая модель - это модель событий X с похожими именами.) Предполагая, что вы не хотите поддерживать функцию вырезания и вставки между приложениями. или перетаскивание для целей записи; это сильно усложняет. Скорее всего, у вас будет много событий; запись в базу данных SQLite может иметь большой смысл.

Однако вы должны тщательно продумать, какие части приложения вы хотите записать. Имеет ли значение, что порядок двух кнопок во внешней оболочке приложения вне CAD-подобной области поменялся местами по порядку? Для большинства пользователей, если вы четко понимаете, что делают кнопки (с помощью четких меток и значков), это не очень важно, но для воспроизведения записанных событий это может иметь огромное значение. Вместо этого, для частей приложения, которые являются простыми кнопками и полями редактирования, я бы не записывал их детали, а просто записывал бы, когда нажимаются кнопки, и изменения в текстовом содержимом записей и так далее. По сути, он захватывает события более высокого уровня, и его намного проще правильно воспроизвести. Только когда пользователь находится в этой основной области САПР, вам нужны все детали.

Также остерегайтесь изменений размеров шрифта и размеров экрана / масштабирования. Они могут изменить то, как все устроено, и могут произойти из-за изменений на уровне системы, выходящих за рамки вашего приложения.

Answer 2

Мы начали так, как вы описываете: запишите все эти тысячи событий движения и т. Д. Включая точные временные параметры, которые также чрезвычайно важны для приложения с графическим интерфейсом.

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

Два самых больших улучшения, которые мы представили

• Сжатие события: распознайте действие высокого уровня, которое пользователь хотел выполнить (например, выбор пункта меню). Записанная команда activItem затем выполнит необходимую работу (эмуляцию события) при воспроизведении.

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

Однако для того, чтобы это работало свободно, потребовалось несколько лет. Включая центральный репозиторий карты объектов, проверки свойств и скриншотов, описания тестов высокого уровня в BDD и другие. Не стесняйтесь взглянуть на продукт Squish for Tk, который вышел из этой работы.