Comments 8
Круто, что разработчики вложились в testability. Насколько я понимаю, рекордер основан на координатном методе, раз была проблема с разрешением экрана. Win32 хуки несложно использовать для мониторинга низкоуровневых событий мыши и клавиатуры.
Просто если вы работаете только под Windows, странно, что не использовали инструменты на основе accessibility технологий, чтобы заскриптовать тесты в читабельном текстовом формате (а не координатами). Скриншоты — разумеется, для отдельных элементов интерфейса. Как же иначе-то.
Вопрос: как часто бывает, что небольшие отличия в отрисовке не являются багом? И приходится обновлять все или большую часть эталонных картинок. Надо же просмотреть все отличающиеся пары изображений, вдруг реальную багу пропустишь! А их на 100 тестов, скажем, тысяча пар картинок.
Просто если вы работаете только под Windows, странно, что не использовали инструменты на основе accessibility технологий, чтобы заскриптовать тесты в читабельном текстовом формате (а не координатами). Скриншоты — разумеется, для отдельных элементов интерфейса. Как же иначе-то.
Вопрос: как часто бывает, что небольшие отличия в отрисовке не являются багом? И приходится обновлять все или большую часть эталонных картинок. Надо же просмотреть все отличающиеся пары изображений, вдруг реальную багу пропустишь! А их на 100 тестов, скажем, тысяча пар картинок.
В моём предыдущем проекте мы тоже тестировали приложение с развесистой графикой. И там как раз небольшие изменения в отрисовке часто не являлись багом. Мы, конечно, сделали в HTML логах ссылочки типа «обновить эталон» (или как это ещё называют «обновить голдЫ»), но всё равно сотню картинок обновлять тупым кликерством напрягало. Была ещё мысль, а можно ли сделать авто аналитику для картинок, чтобы сказать «обнови все похожие изменения во всех эталонах». Но вопрос дальше не исследовали.
Пороговые значения мы тоже применяли. Но случалось часто, что какой-нибудь большой 3D объект смещался на небольшую величину (потому что отрисовку осей координат улучшили, например). И тут 1% разницы не обойтись.
всё равно сотню картинок обновлять тупым кликерством напрягало
В интерфейса рекордера реализованы механизмы фильтрации тестов и мультиселект. Сортируешь, оставляя только то, что надо обновить, или выделяешь нужное, и одним нажатием все автоматом заменяется.
Насколько я понимаю, рекордер основан на координатном методе, раз была проблема с разрешением экрана. Win32 хуки несложно использовать для мониторинга низкоуровневых событий мыши и клавиатуры.
Мы не записываем координаты. Такие тестовые сценарии пришлось бы переписывать (перекликивать) заново, если в результате аналитического решения, скажем, кнопка переедет в другое место панели. Мы используем схему именования логических объектов в интерфейсе. Она проста и даёт тестовым сценариям необходимую устойчивость.
Вопрос: как часто бывает, что небольшие отличия в отрисовке не являются багом? И приходится обновлять все или большую часть эталонных картинок. Надо же просмотреть все отличающиеся пары изображений, вдруг реальную багу пропустишь! А их на 100 тестов, скажем, тысяча пар картинок.
Растровые снимки (как результат тестов) используются только для сравнения рабочих областей. Снимки же интерфейса хранятся в xml-файлах, а картинки используются лишь для удобства тестировщика при обработке результатов. В условиях активной разработки ситуация когда отличия не являются багом возникает регулярно. Для её решения придуман и механизм правил для игнорирования ошибок.
Значит, для testability у вас реализован собственный тестовый back door (если так можно назвать), через который вы получаете имена объектов в интерфейсе? Некоторые, например, делают служебный TCP сервер в приложении для подобных вещей. Интересно, какой подход у вас?
Часть Магнитофона, отвечающая за запись и воспроизведение тестов, интегрирована в интерфейсный модуль КОМПАСа.
Другая часть (внешнее приложение) используется для удобного управления процессом запуска тестов и обработки результатов. В частности, она выполняет запуск КОМПАСа со специальными ключами командной строки.
Другая часть (внешнее приложение) используется для удобного управления процессом запуска тестов и обработки результатов. В частности, она выполняет запуск КОМПАСа со специальными ключами командной строки.
Рабочая область(это часть экрана, где модель отображается) хоть и работает с координатами, но не с координатами на экране, а с собственными трехмерными координатами внутри программы (х,y,z).
Sign up to leave a comment.
Как победить день сурка → Автоматизация тестирования нового интерфейса КОМПАС-3D v17