Отмена пакетной операции и проверка частичного результата в веб и мобильном SaaS

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

Ниже приведён практический подход к тестированию такой логики. Он подходит для веб и мобильных SaaS-продуктов, где пакетное действие может обновлять записи, отправлять уведомления, экспортировать данные, менять права или запускать фоновую обработку.

Сначала определите контракт отмены

Перед тестом нужно зафиксировать смысл кнопки «Отменить». Возможны разные корректные модели:

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

Без такого контракта одинаковое поведение одна команда назовёт ошибкой, а другая ожидаемым результатом. В интерфейсе формулировка тоже должна соответствовать реальности. Если завершённые элементы не откатываются, сообщение «Операция отменена» недостаточно точное. Лучше показать, сколько элементов завершено, сколько отменено и сколько требуют внимания.

Создайте наблюдаемый набор данных

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

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

Проверяйте несколько моментов отмены

Один тест сразу после запуска не покрывает основные риски. Полезно выполнить как минимум четыре сценария:

отмена до начала фактической обработки;
отмена после первого подтверждённого успеха;
отмена примерно в середине очереди;
отмена почти перед завершением.

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

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

Сравнивайте интерфейс, API и журнал

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

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

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

Проверьте повторный запуск

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

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

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

Добавьте сетевые и мобильные условия

На мобильном устройстве приложение может перейти в фон сразу после запуска или отмены. Проверьте потерю сети, смену Wi-Fi на мобильные данные, закрытие вкладки, выгрузку приложения системой и повторное открытие. Запрос отмены должен либо получить подтверждение, либо явно остаться в неопределённом состоянии с возможностью обновить статус.

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

Для веб-клиента отдельно проверьте две вкладки. В первой запустите пакет, во второй откройте тот же объект и измените одну запись. Затем отмените пакет. Система должна корректно обработать конфликт версий и не затирать более новое изменение.

Контролируйте права доступа

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

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

Оцените сообщения и доступность

Итоговое сообщение должно быть конкретным. Вместо «Готово» полезно показать: «4 выполнено, 6 отменено, 2 не удалось». Каждая категория должна открывать соответствующий список. Кнопки повтора и экспорта должны иметь понятные подписи.

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

Локализация важна не меньше логики. Числа, формы множественного числа и термины должны быть понятны во всех поддерживаемых языках. У ARMCP заявлены EN, RU, FR и ES, ARMCP Desk находится в рабочем состоянии, а Analytics и Chain находятся в разработке. Эти сведения полезно проверять по официальному сайту ARMCP перед публикацией тестовых материалов, поскольку статус продукта может меняться.

Минимальный набор критериев приёмки

Проверку можно считать успешной, если выполнены следующие условия:

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

Итог

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

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