Чек-лист приёмки интеграции Univer AI Agent перед запуском: регрессия браузеров Mac в 2026 году

В демонстрации агент изменил ячейки правильно, но команда не знает, что будет при отмене, потере связи или смене фокуса в браузере.

Быстрое решение: не считать демонстрацию основанием для запуска, а отдельно проверить состояние документа, границы действий агента, браузерное взаимодействие, восстановление и сохранение доказательств. Регрессию на Mac следует выполнять только для фактически поддерживаемых браузеров и целевых условий пользователей.

Кому пригодится: разработчикам Univer, проверяющим действия AI Agent в редакторе;
QA-инженерам, составляющим сценарии регрессии браузеров Mac и отчёты о сбоях;
техническим руководителям, которым нужно оценить готовность прав, восстановления и тестовых доказательств.

Сначала зафиксируйте сценарии, а не список функций

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

Выберите операции из реального продукта. Это может быть изменение значений в таблице, оформление диапазона, правка документа или работа с презентацией — при условии, что соответствующая часть приложения включена в ваш проект и сценарий реализован. Не следует предполагать, что установка Univer сама по себе предоставляет готовое подключение AI Agent: наличие нужной функции и её поведение определяются интеграцией проекта. Сверьте используемые компоненты и границы продукта с официальным репозиторием Univer и документацией по быстрому запуску таблиц.

Для каждого сценария запишите:

• [ ] Как пользователь начинает действие: кнопкой, командой или иным предусмотренным интерфейсом.
• [ ] Какую часть запроса агент преобразует в операцию редактора.
• [ ] Какие данные и элементы документа разрешено затрагивать.
• [ ] Что пользователь увидит до выполнения и после него.
• [ ] Как он поймёт, что действие отменено, завершилось с ошибкой или требует подтверждения.
• [ ] Где команда найдёт след выполнения: состояние документа, журнал приложения, снимок экрана или иной артефакт.

Разделите ответственность человека и агента. Например, человек задаёт цель и подтверждает опасную операцию, а агент предлагает или выполняет изменение в рамках разрешённой области. Это не готовая рекомендация о том, как именно Univer обрабатывает команды; это описание границы, которую следует реализовать и затем подтвердить тестом. Для проверки возможностей редактора используйте описание основных функций таблиц Univer, а не предположение, основанное на успешном демонстрационном сценарии.

Как проверить, что результат действий AI Agent верен?

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

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

Проведите сценарии отдельно:

• [ ] Успешное действие: агент получает однозначный запрос; проверяются изменённые данные, форматирование и отсутствие непредусмотренных изменений.
• [ ] Отмена: пользователь прерывает действие до завершения либо отменяет уже внесённые изменения, если продукт поддерживает такое поведение. Зафиксируйте, какой именно этап был отменён и что осталось в документе.
• [ ] Повторная отправка: одинаковый запрос передаётся повторно после задержки, потери ответа или повторного нажатия. Проверьте, не дублирует ли приложение операцию.
• [ ] Частичный результат: выполнение прерывается после того, как началась обработка. Установите, видит ли пользователь незавершённое состояние и может ли команда отличить его от успешно сохранённого результата.

Сравнивайте состояние по наблюдаемым свойствам, а не только по скриншоту. Например, значение в ячейке может быть правильным, но формат или соседний диапазон — измениться случайно. В таблицах и интерфейсах Univer документируйте как данные, так и визуальные признаки, существенные для сценария. Форматирование, расчёты и другие возможности редактора следует проверять в пределах функций, действительно задействованных в вашей сборке.

Операции, расширяющие поведение редактора, требуют отдельной проверки. В документации Univer описана точка расширения через пользовательские команды. Наличие такого механизма не доказывает, что конкретная команда безопасна, доступна AI Agent или корректно повторяется после сбоя. Для этого нужны тесты именно вашей реализации.

Не подменяйте проверку результата проверкой текста ответа агента. Сообщение «готово» не подтверждает сохранение документа: сопоставьте его с фактическим состоянием редактора и предусмотренным в проекте признаком сохранения.

Сохраните свидетельства до и после операции в форме, пригодной для повторной проверки: снимки экрана, экспортируемое состояние, структурированное сравнение или записи журнала — в зависимости от архитектуры продукта. Не собирайте данные, которые не нужны для воспроизведения теста. Командам, которым требуется согласовать порядок хранения и доступа к материалам, полезно заранее изучить условия конфиденциальности nuvcloud.

Что проверить в правах и защите от ошибочных действий

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

• [ ] Передайте агенту запрос на изменение за пределами разрешённой области. Ожидаемое поведение должно быть задано проектом: отказ, запрос подтверждения или иной контролируемый ответ.
• [ ] Проверьте операции с существенным эффектом — например, массовое изменение или удаление содержимого. Если продукт требует подтверждение, убедитесь, что без него действие не выполняется.
• [ ] Проверьте переход между документами или рабочими контекстами. Убедитесь, что разрешение, выданное для одного сценария, не становится основанием для изменения другого документа.
• [ ] Смоделируйте ошибку выполнения. Агент и интерфейс должны явно показать, что действие не завершено; последующие команды не должны молча расширять последствия сбоя.
• [ ] Проверьте доступность отказа и отмены для пользователя, который не обладает правами на подтверждение.

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

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

Какие проверки Mac-браузера включить в регрессию

Перечень браузеров и системных условий задавайте исходя из заявленной поддержки приложения и окружения пользователей. Запишите фактически проверенные версии macOS и браузеров, тип устройства, способ доступа к приложению и важные настройки. Нельзя переносить результат одной комбинации на браузеры или версии, которые команда не проверяла.

В каждом выбранном окружении пройдите пользовательский путь от начала до завершения действия:

• [ ] Фокус: после открытия панели агента, всплывающего окна или меню видно, какой элемент активен; переход фокуса не теряется и не перескакивает неожиданно.
• [ ] Клавиатура: сочетания клавиш, ввод текста, подтверждение и отмена работают в контексте редактора так, как предусмотрено продуктом.
• [ ] Прокрутка: проверяется прокрутка документа, таблицы и вложенных областей, в том числе при открытой панели или диалоге.
• [ ] Слои интерфейса: меню и всплывающие элементы не перекрывают важные кнопки; закрытие не оставляет экран заблокированным.
• [ ] Размер и компоновка: редактор, боковая панель и подтверждения остаются доступными при фактическом размере окна тестового устройства.
• [ ] Возврат в редактор: после взаимодействия с интерфейсом агента фокус и активное состояние документа соответствуют ожидаемому сценарию.

Порядок фокуса имеет значение для клавиатурной навигации и понимания того, где находится пользователь. Приёмочные критерии можно сопоставить с рекомендациями W3C по порядку фокуса, адаптируя их к интерфейсу приложения, а не копируя механически.

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

Особенно тщательно проверяйте поведение после сворачивания вкладки или переключения пользователя в другое окно. Страница может получать уведомление об изменении видимости; назначение и события соответствующего интерфейса описаны в документации Page Visibility API. Сам факт такого уведомления не говорит, как приложение должно восстанавливать запрос агента: ожидаемое поведение определяет команда, а тест должен подтвердить его в вашей реализации.

Как проверить восстановление после обрыва и повторного действия?

Восстановление проверяется на границах операции: до отправки запроса, во время ожидания ответа, после получения результата и при сохранении изменений. Если тестировать только сценарий полного обрыва страницы, можно пропустить случаи, когда интерфейс остаётся открытым, но действие уже не соответствует текущему состоянию документа.

Подготовьте воспроизводимую последовательность:

Шаг первый — зафиксируйте исходное состояние. Сохраните идентификатор тестового документа, значимые значения и форматирование, а также видимый статус редактора. Убедитесь, что команда способна вернуться к исходным условиям.

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

Шаг третий — проверьте состояние страницы. Обновите страницу, вернитесь к вкладке или откройте документ повторно — в соответствии с проверяемым пользовательским сценарием. Установите, сохранилось ли изменение, исчезло ли оно либо осталось незавершённым.

Шаг четвёртый — повторите запрос контролируемо. Перед повторной отправкой сравните текущее состояние с исходным и ожидаемым. Проверьте, не применилось ли изменение до потери ответа, чтобы повтор не создал лишнюю операцию.

Шаг пятый — сверьте интерфейс и след выполнения. Зафиксируйте сообщение об ошибке, статус запроса, состояние редактора и относящиеся к сценарию записи журнала. Если используются повторы тестов, заранее отделяйте их результат от первоначального: рекомендации о повторных попытках в тестах описывают механизм инструментария, но не доказывают, что операция приложения безопасна к повторному запуску.

Для каждой точки прерывания определите ожидаемое действие команды: остановить обработку, запросить повтор, сообщить о неопределённом результате или предложить сверить документ. Не выбирайте поведение по удобству демонстрации. Оно должно соответствовать требованиям продукта, а итоговый тест — показывать, что фактически произошло.

Оформите результаты так, чтобы их можно было воспроизвести

Запись о прохождении теста должна отвечать на практический вопрос: сможет ли другой инженер повторить проверку в сравнимом окружении и понять, почему результат признан приемлемым или нет? Для этого недостаточно статуса «прошло» и общего скриншота.

Для каждого случая заведите карточку:

• [ ] Идентификатор и цель: уникальное обозначение сценария и проверяемое требование.
• [ ] Окружение: версия macOS и браузера, способ запуска, важные настройки и дата выполнения.
• [ ] Предварительное состояние: документ, данные, права, состояние сохранения и открытые элементы интерфейса.
• [ ] Действия: последовательность пользователя и агента, включая точку отмены или сбоя.
• [ ] Ожидаемый результат: состояние документа, допустимые изменения и критерии отказа.
• [ ] Фактический результат: наблюдаемое поведение, а не предположение о том, что «должно было» произойти.
• [ ] Артефакты: снимки экрана, фрагмент журнала, сравнение данных или другая доказательная информация.
• [ ] Связь с дефектом: ссылка на запись о проблеме, если найдено расхождение, и отметка о повторной проверке после исправления.

Критерии выпуска определяет команда с учётом риска продукта, заявленной поддержки и требований пользователей; единого порога, подходящего каждому проекту, здесь нет. До запуска согласуйте, какие дефекты блокируют релиз, что можно принять с известным ограничением и кто уполномочен принять такой риск. После обновления редактора, браузера или интеграционного кода повторяйте затронутые сценарии, а не распространяйте старое заключение на новую комбинацию окружения.

Подход к проверке	Что он подтверждает	Чего сам по себе не подтверждает	Когда выбирать
Ручной сценарий на целевом Mac	Реальное взаимодействие с фокусом, прокруткой, окнами и редактором	Воспроизводимость без подробной записи; поведение в других версиях	Для первичной приёмки и сложных пользовательских путей
Автоматизированный браузерный тест	Повторяемость заданных шагов и проверок в настроенном тестовом окружении	Совместимость со всеми браузерами и устройствами пользователей	Для регрессии стабильных сценариев после изменений
Сравнение документа до и после операции	Изменения данных и связанных состояний, если они включены в сравнение	Корректность каждого элемента интерфейса и полноту пользовательского пути	Для проверки точности изменений агента
Проверка восстановления после сбоя	Поведение конкретного сценария при зафиксированном прерывании	Безопасность повторов в неиспытанных условиях	Для оценки сетевых сбоев, обновления страницы и повторной отправки

Сценарий регрессии	Что записать в матрице	Признак, требующий разбора
Возврат из панели агента в редактор	Состояние фокуса и активная область	Клавиатурные действия попадают не в тот элемент
Работа с диалогом подтверждения	Способ открытия и закрытия, результат подтверждения или отказа	Действие выполняется без предусмотренного подтверждения
Прокрутка документа при открытом интерфейсе агента	Какую область прокручивает тестировщик и что остаётся видимым	Прокрутка блокируется или перемещает неверную область
Переключение вкладки или возврат к странице	Состояние задачи и документа до и после возврата	Интерфейс показывает завершение без проверяемого результата
Повторная отправка после задержки	Исходное состояние, повторное действие и итоговые изменения	Появляются дополнительные или дублирующие изменения

Итоговый чек перед запуском

• [ ] Пользовательские сценарии соответствуют заявленной функциональности проекта на базе Univer.
• [ ] Для каждого действия агента известны разрешённая область и ожидаемое поведение при отказе.
• [ ] Результат проверяется по состоянию документа, а не только по сообщению агента.
• [ ] Отмена, повторная отправка и частичное выполнение испытаны отдельно.
• [ ] Регрессионная матрица содержит только фактически проверенные комбинации Mac, браузера и приложения.
• [ ] Для каждого существенного результата сохранены окружение, шаги и доказательства.
• [ ] Команда согласовала критерии блокировки релиза и порядок повторной проверки после исправлений.

Локальный Mac разработчика удобен, но результаты на нём трудно считать общей тестовой записью, если условия запуска и состояние машины меняются между участниками; эмуляция браузера может не воспроизвести все особенности целевого окружения, а покупка отдельного устройства ради разовой регрессии требует затрат и последующего обслуживания. Если команде нужен временный удалённый Mac для проверок по собственной матрице, можно оценить условия аренды Mac у nuvcloud и провести тесты в записанном окружении. Для длительной постоянной нагрузки или сценариев, которым необходим физический интерфейс устройства, аренда может оказаться неподходящим вариантом: решение следует выбирать по требованиям проекта, а заключение о совместимости ограничивать теми комбинациями, которые команда действительно проверила.