Тестирование интеграций с Битрикс24: чек-лист перед продакшеном

Интеграция с Битрикс24, которая прошла только ручную проверку «создал сделку — увидел в CRM», в проде обязательно столкнётся со сценарием, который никто не тестировал: массовый импорт, протухший токен посреди рабочего дня, дублирующееся событие, лимит запросов при квартальной распродаже. Этот чек-лист собран из реальных инцидентов, а не из теоретических соображений — пройдите его перед тем, как передавать интеграцию в продакшен клиенту.

Тестовый портал как обязательное условие

Ни один пункт этого чек-листа не должен проверяться на боевом портале клиента. Зарегистрируйте отдельный тестовый портал (бесплатно, занимает несколько минут) и наполните его синтетическими данными, похожими по объёму и структуре на реальные — с пользовательскими полями, характерными для этой отрасли, с несколькими сотнями тестовых сделок для проверки пагинации. Тестирование на пустом портале с тремя записями не выявит и половины проблем, которые проявятся на реальном объёме данных.

Проверка авторизации

• Токен корректно обновляется по refresh_token до истечения срока действия, а не только после первой ошибки expired_token
• Приложение переживает ситуацию, когда refresh_token тоже стал недействителен (например, администратор отозвал доступ) — не падает в бесконечный цикл повторных попыток
• Вебхук-версия интеграции корректно обрабатывает отзыв вебхука администратором (ошибка авторизации обрабатывается видимо, а не тихо проглатывается)
• Для мультипортальных приложений токены разных порталов не путаются между собой при параллельной обработке

Проверка лимитов и устойчивости к нагрузке

Намеренно спровоцируйте QUERY_LIMIT_EXCEEDED — отправьте несколько десятков запросов подряд без троттлинга и убедитесь, что ваш backoff реально срабатывает и в итоге все запросы выполняются успешно, а не теряются молча после исчерпания попыток. Проверьте поведение batch-запросов на границе лимита в 50 команд — что происходит, если вам нужно обработать 137 записей: корректно ли разбивается на группы по 50, не теряется ли последняя неполная группа.

// Пример нагрузочного теста лимита (псевдокод)
for (let i = 0; i < 30; i++) {
  queue.push(() => callMethod('crm.deal.list', { start: i * 50 }));
}
// Ожидаем: все 30 запросов завершатся успешно за счёт очереди с лимитом 2/сек,
// а не 429/QUERY_LIMIT_EXCEEDED без последующего retry

Проверка обработчиков событий

1. 1.Событие обрабатывается корректно при быстром повторном изменении одной записи (проверка на гонки)
2. 2.Повторная доставка одного и того же события не создаёт дублирующихся побочных эффектов (проверка идемпотентности)
3. 3.Обработчик отвечает порталу быстро (менее пары секунд), тяжёлая логика вынесена в асинхронную очередь
4. 4.При недоступности вашего сервера в течение часа события, произошедшие в этот период, находятся и обрабатываются последующей сверкой, а не теряются навсегда

Проверка установки и удаления приложения

Установите приложение на тестовый портал, поработайте с ним какое-то время (создайте записи, вызовите роботов, откройте виджеты), затем удалите его и проверьте три вещи: интерфейс портала не содержит «осиротевших» вкладок и пунктов меню, ваша база данных корректно очистила или архивировала данные этого портала, а все фоновые задачи (синхронизации, очереди), связанные с этой установкой, остановлены. Затем установите приложение повторно на тот же портал и убедитесь, что повторная установка не приводит к дублированию данных или конфликту с остатками от предыдущей установки.

Проверка на разных ролях и правах пользователей

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

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

Проверка сетевых сбоев и таймаутов

Смоделируйте недоступность внешних зависимостей интеграции: временно заблокируйте доступ к API 1С, платёжному шлюзу или другому внешнему сервису, к которому обращается ваша интеграция помимо самого Битрикс24, и проверьте, что REST-вызовы к порталу при этом не блокируются надолго и не приводят к каскадному отказу всей интеграции целиком. Отдельно проверьте таймауты собственных HTTP-клиентов — библиотека с таймаутом по умолчанию в 0 (бесконечное ожидание) — частая причина зависших процессов на проде при недоступности стороннего сервиса.

Курс школы: Вебхуки в Битрикс24 без программирования — от 9 990 ₽

Проверка версионирования данных и полей

Добавьте на тестовом портале новое пользовательское поле в CRM-сущность, с которой работает интеграция, уже после того, как код написан — убедитесь, что интеграция не падает при появлении незнакомого поля в ответе *.get или *.list, а корректно его игнорирует, если оно не используется в логике. Аналогично проверьте удаление значения из справочника (enumeration) — что происходит, если поле раньше содержало значение, а теперь это значение удалено администратором из списка допустимых на портале.

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

Финальный чек-лист перед передачей в продакшен

• Полный цикл установка/использование/удаление/повторная установка пройден на тестовом портале
• Лимит 2 запроса/сек и backoff при QUERY_LIMIT_EXCEEDED проверены под намеренной нагрузкой
• Обновление токена по refresh_token проверено, включая сценарий его отзыва администратором
• Обработчики событий проверены на идемпотентность и на устойчивость к недоступности сервера
• Интеграция протестирована под обычным пользователем с ограниченными правами, а не только под администратором
• Логирование покрывает все исходящие и входящие вызовы без утечки токенов и персональных данных в открытом виде
• Поведение при появлении новых/удалённых пользовательских полей CRM проверено и не приводит к падению

Организация регрессионного тестирования при обновлениях

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

Тестирование миграции при смене версии ядра Битрикс24

Платформа регулярно обновляет ядро, и хотя обратная совместимость REST API соблюдается почти всегда, изредка меняется поведение отдельных методов на граничных случаях (например, обработка пустых значений в фильтре или формат дат в ответе). Подпишитесь на канал технических новостей разработчиков Битрикс24 и, при анонсе значимых изменений в REST API, прогоняйте полный набор регрессионных тестов заранее на тестовом портале, у которого обновление уже применено, а не дожидайтесь жалоб клиентов после автоматического обновления их боевых порталов.

Нагрузочное тестирование при пиковых сценариях бизнеса

Если интеграция обслуживает бизнес с выраженной сезонностью или пиковой нагрузкой — распродажа, отчётный период, массовая рекламная кампания — обычного тестирования на стабильном потоке операций недостаточно. Смоделируйте кратный рост числа операций (например, в 5-10 раз больше типичного дневного объёма сделок) на тестовом портале и убедитесь, что очередь с ограничением скорости запросов справляется с накопленной нагрузкой в разумное время, не приводя к катастрофическому отставанию обработки на часы после окончания пикового периода.

1. 1.Определите ожидаемый пиковый объём операций для бизнеса заказчика (пиковый день, пиковый час)
2. 2.Смоделируйте этот объём на тестовом портале синтетическими операциями
3. 3.Замерьте, за какое время очередь обрабатывает накопленный объём после окончания пика
4. 4.Если время неприемлемо велико — рассмотрите приоритизацию операций в очереди или увеличение числа параллельных технических пользователей с отдельными лимитами
5. 5.Задокументируйте протестированный предел нагрузки — это конкретная цифра, а не общее ощущение «вроде справляется»

Юридическая и договорная сторона тестирования

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

Кто принимает решение о готовности к продакшену

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

План отката при обнаружении критичной проблемы в проде

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