Личный кабинет в Битрикс: чек-лист перед продакшеном

Личный кабинет в 1С-Битрикс можно открыть для тестировщика за час, но это ещё не означает, что он готов к продакшену. На боевом сайте чаще всего ломаются не форма входа, а связка профиля с заказом, повторная покупка, кеширование персональных страниц и права доступа. Ниже — практический чек-лист для проекта на 1С-Битрикс: Управление сайтом 24.x; пункты подходят и для близких версий, но названия настроек и состав компонентов нужно сверить с вашей редакцией.

Что проверить до начала

Соберите стенд, который повторяет продакшен хотя бы по версии PHP, базе данных, веб-серверу и настройкам кеширования. Проверка на локальной копии без HTTPS и с отключённым композитным режимом не показывает часть реальных проблем.

• версию 1С-Битрикс, PHP, СУБД и используемый шаблон сайта;
• тестовую учётную запись покупателя без административных прав;
• отдельную учётную запись администратора и пользователя с ролью менеджера;
• товар в наличии, товар с торговыми предложениями, цифровой товар, если он есть в каталоге;
• настроенные службы доставки, оплаты, SMS или электронной почты в тестовом режиме;
• доступ к журналам событий, логам веб-сервера и панели производительности Битрикс;
• резервную копию базы и файлов перед изменениями.

Проверка готовности: вы можете создать новый заказ тестовым покупателем, найти его в административной части и восстановить стенд из резервной копии.

Личный кабинет готов к релизу не тогда, когда пользователь может войти, а когда он не может увидеть или изменить ничего чужого.

Чек-лист пользовательских сценариев

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

1. Регистрация. Создайте пользователя с новым адресом электронной почты, проверьте обязательные поля, формат телефона, подтверждение регистрации и повторную отправку письма. Должно появиться ровно одно пользовательское профилирование, а пароль не должен отображаться в URL, HTML-ответе или письме в открытом виде.
2. Вход и выход. Войдите с правильным и неправильным паролем, выйдите из аккаунта, затем нажмите кнопку «Назад» в браузере. После выхода закрытые данные не должны открываться из истории или через старый URL.
3. Восстановление пароля. Запросите восстановление для существующего и несуществующего адреса. Сообщение для этих случаев лучше сделать одинаковым, чтобы не раскрывать наличие учётной записи. Ссылка должна быть одноразовой или ограниченной по времени согласно настройкам проекта.
4. Профиль. Измените имя, телефон и адрес, обновите страницу и войдите заново. Новые данные должны сохраняться в том профиле, который используется при оформлении заказа, а не только в отдельной форме кабинета.
5. Адреса доставки. Добавьте два адреса, выберите второй в корзине, оформите заказ и проверьте его в административной части. Удаление адреса, который уже сохранён в заказе, не должно менять исторические данные этого заказа.
6. История заказов. Создайте минимум два заказа, включая отменённый и оплаченный. Пользователь должен видеть только свои заказы, корректные статусы и состав каждой покупки. Ссылки из списка не должны вести на заказ другого пользователя при ручной замене идентификатора в URL.
7. Повторный заказ. Запустите повтор покупки из старого заказа с товаром в наличии и с товаром, которого больше нет. В первом случае товар должен попасть в корзину с актуальной ценой, во втором — пользователь должен получить понятное сообщение, а не ошибку PHP.
8. Профиль после оформления. Оформите заказ как авторизованный пользователь, затем измените контактные данные и создайте второй заказ. В первом заказе должны остаться данные на момент покупки, во втором — новые.
9. Мобильный сценарий. Пройдите регистрацию, вход, восстановление пароля и просмотр заказа на узком экране. Кнопки, ошибки валидации и маска телефона не должны перекрывать друг друга.

Три подхода к реализации кабинета

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

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

Что проверить в компонентах и настройках

Профиль и заказы

Проверьте, какие компоненты отвечают за разделы кабинета: персональную страницу, профиль, список заказов и детальную страницу заказа. Убедитесь, что они используют одну и ту же схему идентификации пользователя и не подменяют данные параметрами из URL.

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

Кеш и композитный режим

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

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

Формы и защита

На каждой форме проверьте CSRF-защиту¹, серверную валидацию и понятную обработку ошибок. Клиентская проверка в браузере не считается защитой: запрос можно отправить вручную, без JavaScript.

• нельзя сохранить чужой идентификатор пользователя или заказа через подмену POST-параметров;
• нельзя изменить статус заказа из формы покупателя;
• поля телефона, email и адреса проверяются на сервере;
• в HTML не выводятся служебные данные, токены и внутренние комментарии менеджера;
• ограничение частоты запросов применяется к входу и восстановлению пароля, если его предусматривает инфраструктура проекта;
• ошибки не раскрывают SQL-запросы, пути к файлам и конфигурацию сервера.

Почта и внешние сервисы

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

Для оплаты, доставки, SMS и бонусной программы проверьте не только успешный ответ, но и тайм-аут, повторный callback и частично выполненную операцию. Внешняя служба может прислать одно событие дважды, поэтому повторная обработка не должна создавать второй заказ или повторное списание.

Что ломается чаще всего

• «После входа открывается пустой кабинет». Проверьте группу пользователя, права на инфоблоки и настройки компонента, а затем посмотрите ошибки PHP и события Битрикс.
• «Заказ есть в админке, но его нет у покупателя». Сверьте пользователя, к которому привязан заказ, и фильтр списка заказов. Не исправляйте проблему только добавлением заказа в шаблон вручную.
• «После обновления сломалась верстка кабинета». Сравните локальную копию шаблона компонента с новой версией и прогоните сценарии после обновления ядра.
• «Пользователь видит старые данные». Очистите кеш и повторите тест под двумя аккаунтами. Если проблема исчезает только после полной очистки, ищите неправильное кеширование персонального ответа.
• «В письме ссылка ведёт на localhost или тестовый домен». Проверьте домен сайта, протокол и настройки почтовых событий на стенде и в продакшене.

Когда кабинет можно выпускать

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

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

Что делать дальше

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

¹ CSRF-защита — механизм, который не позволяет стороннему сайту незаметно отправить действие от имени пользователя, уже вошедшего в ваш магазин.