Запись событий щелчка мыши для тестирования GUI. Что надежнее пиксельных координат?
Я писал некоторые тестовые среды GUI, которые могут записывать и воспроизводить некоторые сценарии пользовательского интерфейса, записывая события мыши и клавиатуры и воспроизводя их.
События мыши в настоящее время записываются как (press or release, (x, y)), Однако это очень хрупко, потому что если только виджет назначения перемещается на несколько пикселей, но структура и все остальное остается прежним, тестовый сценарий перестает работать.
Какой лучший подход для этого? Некоторые вещи, о которых я могу думать
-
Запишите «путь к дереву» целевого виджета в дереве виджетов и их родительских виджетов. То есть
(press or release, (top level, first child, second child, destination))где «дочерний список» — это то, что возвращает QtQObjectсписок детей. Я думаю, что у этого есть недостаток, что тест теперь зависит от внутренней структуры кода. -
Дать каждый У тестируемого виджета уникальное имя, а при воспроизведении ищите виджет с этим именем. Кажется, что это небрежные накладные расходы.
Любые другие идеи, и каков общепринятый «лучший» подход к этому?
Решение
Технические характеристики
Вы сами решаете, в какой степени тестовые наборы связаны с конкретной настройкой теста и изменениями в коде. По сути, это вопрос того, насколько точны ваши спецификации.
С одной стороны, существуют «механические» или «тупые» тесты. Может случиться так, что вы тестируете с жестко контролируемыми начальными условиями: одни и те же настройки для начальных положений окна предварительно устанавливаются перед тестом, применяется тот же стиль платформы, доступны те же шрифты и т. Д. Тогда это разумное ожидание что если вы переключаете две кнопки в виджете или изменяете начальный размер окна / диалогового окна, тесты должны провалиться.
С другой стороны, существуют «человеческие» тесты. Вы можете пожелать, чтобы тесты были успешными, если человек чтение сценария из бумаги будет успешным на тесте. В таком случае незначительные изменения, такие как шрифты, расположение визуальных элементов и т. Д., Не важны: люди-тестеры легко адаптируются к таким изменениям.
Эти две крайности могут даже применяться сразу, но к разным частям приложения или к различным этапам жизненного цикла продукта.
Если вы разрабатываете пользовательский интерфейс для системы управления аэрокосмическими полетами, есть аспекты, которые могут потребовать полностью «механических», неадаптируемых испытаний, поскольку любые изменения в пользовательском интерфейсе, которые не охватываются изменениями спецификации, будут фактически ошибкой ,
Если вы разрабатываете потребительское приложение, вы можете сохранить спецификацию в исправлении ошибок или в небольших выпусках, но, например, можете ослабить это для основных выпусков.
Сотрудничество из тестовых случаев и проверенного кода
Для реализации более гибких, более похожих на человека тестов требуется определенное сотрудничество либо с протестированным кодом, либо с процессом генерации тестового набора, либо с обоими.
Процесс генерации тестового набора (тестовый сценарий, человек и т. Д.) Обладает важными знаниями о значении конкретного события. Например, щелчок по общей кнопке действительно предназначен для середины кнопки — тогда не имеет значения, если активная область кнопки имеет закругленные углы, которые не реагируют на нажатия. Щелчок также может быть назначен кнопке с надписью «ОК», независимо от того, находится ли эта кнопка справа или слева от панели кнопок на определенной платформе.
Тестируемый код также обладает важными знаниями о классификации конкретного события. Например, координаты щелчка могут быть важны сами по себе, если это щелчок на холсте программы рисования. Иначе, это может быть конкретный визуальный элемент в виджете, который важен, а не его точные координаты. В этом последнем случае изменения внешнего вида виджета из-за стилизации платформы или обновлений кода могут сделать относительные координаты устаревшими.
Другие решения
Других решений пока нет …