Полностью открытым решение быть не может оно включает внутренние компоненты и интеграции, завязанные на корпоративную инфраструктуру, CI и окружение. Однако концепция остаётся универсальной, и её можно воспроизвести в облегчённом виде на любой машине:
запись действий + UI-метаданных,
сценарии в виде JSON,
раннер, который воспроизводит шаги и выполняет проверки.
Я рассматриваю возможность собрать небольшую демонстрационную версию без корпоративных зависимостей чтобы показать сам подход. Если будет запрос на это со стороны сообщества, можно сделать такой вариант.
Спасибо за вопросы - отвечу кратко и в рамках того, что можно описывать публично.
Аналог UI Automation в Linux Прямого аналога Windows UIA нет. Есть AT-SPI, но поддержка фрагментирована и зависит от тулкита (GTK/Qt). Поэтому в Linux работает только облегчённый режим: базовые операции доступны, но без полноценного дерева UI. Это скорее вспомогательная возможность, а не основная платформа.
Надёжность тестов На Windows тесты получаются устойчивые именно за счёт многослойного поиска элементов и использования нескольких источников метаданных. Мы не стремимся к 100% стабильности - она недостижима в принципе - но достигаем высокой повторяемости при реальных сценариях.
Продемонстрировать запись/воспроизведение Рабочие записи привязаны к корпоративным приложениям, поэтому показывать их нельзя. Думаю над подготовкой краткого публичного демо на нейтральном приложении.
Визуализация фиксируемых элементов Визуализация есть, но она утилитарная: отображает структуру метаданных элемента и путь в UI-дереве. Это внутренний технический инструмент, он не предназначен для широкого использования.
Вкладывание скриптов Да, есть механизм компоновки сценариев, чтобы переиспользовать повторяющиеся последовательности действий. Это позволяет сократить объём тестов и уменьшить рутинные правки при изменениях UI.
Если будет интерес, могу позже подготовить отдельный материал по архитектурным принципам, не углубляясь в закрытую часть реализации.
Да, вы совершенно правы — в идеальном мире API для САПР должно закрывать все потребности тестирования. Но у нас ситуация такая, что оно, к сожалению, не охватывает весь функционал, особенно если говорить про рендеринг, работу с 2D/3D-моделями и визуализацию.
Поэтому мы идем через эмуляцию действий пользователя: это помогает не просто проверить интерфейс, но и убедиться, что сама система — взаимодействие с моделью, отрисовка, поведение инструментов — работает как надо. По сути, мы воспроизводим реальный сценарий использования, чтобы ничего не упустить.
Если бы API давало полный контроль над этими штуками, мы бы, конечно, с радостью на него опирались. Но пока оно не тянет, особенно в части рендеринга и динамики инструментов.
У нас все тесты работают через интерфейс, потому что в САПР без этого никак. Тут важно не только проверить, что команды отрабатывают, но и как все выглядит - особенно когда работаешь с 2D/3D моделями. Многие вещи просто нельзя проверить через API - как модель крутится, как инструменты работают, как выглядят настройки. Поэтому мы решили пойти путем эмуляции действий пользователя - так можно все проверить, включая графику.
Виртуальные машины действительно работают без вывода графического интерфейса на физический монитор (headless-режим), однако это не мешает нам брать скриншоты. Виртуализация даёт доступ к видеобуферу приложения, поэтому система сохраняет изображения напрямую оттуда, без необходимости фактического отображения интерфейса на экране пользователя.
Благодарю за отзыв!
Полностью открытым решение быть не может оно включает внутренние компоненты и интеграции, завязанные на корпоративную инфраструктуру, CI и окружение. Однако концепция остаётся универсальной, и её можно воспроизвести в облегчённом виде на любой машине:
запись действий + UI-метаданных,
сценарии в виде JSON,
раннер, который воспроизводит шаги и выполняет проверки.
Я рассматриваю возможность собрать небольшую демонстрационную версию без корпоративных зависимостей чтобы показать сам подход. Если будет запрос на это со стороны сообщества, можно сделать такой вариант.
Спасибо за вопросы - отвечу кратко и в рамках того, что можно описывать публично.
Аналог UI Automation в Linux
Прямого аналога Windows UIA нет.
Есть AT-SPI, но поддержка фрагментирована и зависит от тулкита (GTK/Qt). Поэтому в Linux работает только облегчённый режим: базовые операции доступны, но без полноценного дерева UI. Это скорее вспомогательная возможность, а не основная платформа.
Надёжность тестов
На Windows тесты получаются устойчивые именно за счёт многослойного поиска элементов и использования нескольких источников метаданных.
Мы не стремимся к 100% стабильности - она недостижима в принципе - но достигаем высокой повторяемости при реальных сценариях.
Продемонстрировать запись/воспроизведение
Рабочие записи привязаны к корпоративным приложениям, поэтому показывать их нельзя.
Думаю над подготовкой краткого публичного демо на нейтральном приложении.
Визуализация фиксируемых элементов
Визуализация есть, но она утилитарная: отображает структуру метаданных элемента и путь в UI-дереве.
Это внутренний технический инструмент, он не предназначен для широкого использования.
Вкладывание скриптов
Да, есть механизм компоновки сценариев, чтобы переиспользовать повторяющиеся последовательности действий. Это позволяет сократить объём тестов и уменьшить рутинные правки при изменениях UI.
Если будет интерес, могу позже подготовить отдельный материал по архитектурным принципам, не углубляясь в закрытую часть реализации.
Ответ:
Да, вы совершенно правы — в идеальном мире API для САПР должно закрывать все потребности тестирования. Но у нас ситуация такая, что оно, к сожалению, не охватывает весь функционал, особенно если говорить про рендеринг, работу с 2D/3D-моделями и визуализацию.
Поэтому мы идем через эмуляцию действий пользователя: это помогает не просто проверить интерфейс, но и убедиться, что сама система — взаимодействие с моделью, отрисовка, поведение инструментов — работает как надо. По сути, мы воспроизводим реальный сценарий использования, чтобы ничего не упустить.
Если бы API давало полный контроль над этими штуками, мы бы, конечно, с радостью на него опирались. Но пока оно не тянет, особенно в части рендеринга и динамики инструментов.
У нас все тесты работают через интерфейс, потому что в САПР без этого никак. Тут важно не только проверить, что команды отрабатывают, но и как все выглядит - особенно когда работаешь с 2D/3D моделями. Многие вещи просто нельзя проверить через API - как модель крутится, как инструменты работают, как выглядят настройки. Поэтому мы решили пойти путем эмуляции действий пользователя - так можно все проверить, включая графику.
Виртуальные машины действительно работают без вывода графического интерфейса на физический монитор (headless-режим), однако это не мешает нам брать скриншоты. Виртуализация даёт доступ к видеобуферу приложения, поэтому система сохраняет изображения напрямую оттуда, без необходимости фактического отображения интерфейса на экране пользователя.