Как победить день сурка → Автоматизация тестирования нового интерфейса КОМПАС-3D v17

[vasily-v-ryabov]

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

Просто если вы работаете только под Windows, странно, что не использовали инструменты на основе accessibility технологий, чтобы заскриптовать тесты в читабельном текстовом формате (а не координатами). Скриншоты — разумеется, для отдельных элементов интерфейса. Как же иначе-то.

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

[vasily-v-ryabov]

В моём предыдущем проекте мы тоже тестировали приложение с развесистой графикой. И там как раз небольшие изменения в отрисовке часто не являлись багом. Мы, конечно, сделали в HTML логах ссылочки типа «обновить эталон» (или как это ещё называют «обновить голдЫ»), но всё равно сотню картинок обновлять тупым кликерством напрягало. Была ещё мысль, а можно ли сделать авто аналитику для картинок, чтобы сказать «обнови все похожие изменения во всех эталонах». Но вопрос дальше не исследовали.

[vasily-v-ryabov]

Пороговые значения мы тоже применяли. Но случалось часто, что какой-нибудь большой 3D объект смещался на небольшую величину (потому что отрисовку осей координат улучшили, например). И тут 1% разницы не обойтись.

[kompas_3d]

всё равно сотню картинок обновлять тупым кликерством напрягало

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

[kompas_3d]

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

Мы не записываем координаты. Такие тестовые сценарии пришлось бы переписывать (перекликивать) заново, если в результате аналитического решения, скажем, кнопка переедет в другое место панели. Мы используем схему именования логических объектов в интерфейсе. Она проста и даёт тестовым сценариям необходимую устойчивость.

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

Растровые снимки (как результат тестов) используются только для сравнения рабочих областей. Снимки же интерфейса хранятся в xml-файлах, а картинки используются лишь для удобства тестировщика при обработке результатов. В условиях активной разработки ситуация когда отличия не являются багом возникает регулярно. Для её решения придуман и механизм правил для игнорирования ошибок.

[vasily-v-ryabov]

Значит, для testability у вас реализован собственный тестовый back door (если так можно назвать), через который вы получаете имена объектов в интерфейсе? Некоторые, например, делают служебный TCP сервер в приложении для подобных вещей. Интересно, какой подход у вас?

[kompas_3d]

Часть Магнитофона, отвечающая за запись и воспроизведение тестов, интегрирована в интерфейсный модуль КОМПАСа.

Другая часть (внешнее приложение) используется для удобного управления процессом запуска тестов и обработки результатов. В частности, она выполняет запуск КОМПАСа со специальными ключами командной строки.

[kompas_3d]

Рабочая область(это часть экрана, где модель отображается) хоть и работает с координатами, но не с координатами на экране, а с собственными трехмерными координатами внутри программы (х,y,z).