Как мы тестируем OpenCart: процесс QA и контроль качества

Тестирование OpenCart-магазина перед запуском — это 7 этапов: unit-тесты, интеграционные тесты, UI-тесты через Selenium/Playwright, нагрузочные тесты, проверка совместимости, аудит безопасности и приёмочное тестирование (UAT). Каждый этап выявляет конкретный класс ошибок. Мы внедрили этот процесс в нашей команде, потому что 70% проблем на поддержке — следствие некачественного тестирования на этапе разработки.

Как не надо: тестировать только на «своём» браузере

Разработчик проверил магазин в Chrome — всё работает. Заказчик открывает в Safari на iPhone — кнопка «В корзину» не нажимается,

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

Как правильно: 7 этапов QA перед запуском

Мы проводим тестирование в таком порядке: юнит-тесты (проверяем каждую функцию отдельно), интеграционные тесты (взаимодействие модулей),

UI-тесты через Playwright (критические сценарии: регистрация — каталог — корзина — оформление — оплата), нагрузочные тесты (k6 или JMeter — 200+ одновременных пользователей), аудит безопасности (XSS, SQL-инъекции, CSRF), кросс-браузерная проверка (Chrome, Safari, Firefox, Edge, мобильные), приёмочное тестирование с заказчиком. Каждый этап пропускать нельзя — именно пропущенный этап оказывается тем самым, где пряталась критическая ошибка.

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

Зачем тестировать OpenCart перед запуском

OpenCart — платформа с открытым кодом и большой экосистемой модулей. Это гибкость и возможность доработки, но и риск конфликтов между модулями, несовместимости с версией PHP и ошибок в кастомном коде.

Из практики: в 70% проектов, которые приходят к нам на поддержку, проблемы возникают из-за некачественного тестирования на этапе разработки. Один не проверенный модуль может сломать весь checkout. Один SQL-запрос без индекса — замедлить каталог на 3 секунды. Один XSS в форме обратной связи — открыть путь для взлома.

Тестирование — не формальность. Это инвестиция: потратить 2–3 дня на QA перед запуском дешевле, чем исправлять проблемы в продакшене, теряя клиентов и деньги.

Этапы QA в наших проектах

Staging и Git: основа процесса

Прежде чем говорить о тестировании — о среде. Тестировать нужно не на продакшене, а на staging-сервере. Вот как мы организовываем процесс:

1. Git-репозиторий. Весь код OpenCart (включая модули и шаблоны) хранится в Git. Каждое изменение — отдельный коммит с описанием.
2. Staging-сервер. Зеркало продакшена: те же данные, та же конфигурация, но отдельный домен (staging.example.com). Здесь тестируем перед деплоем.
3. Деплой через CI/CD. После проверки на staging — автоматический деплой на продакшен через GitHub Actions или GitLab CI.
4. Бэкап перед каждым деплоем. Автоматический бэкап БД и файлов за 5 минут до деплоя. Если что-то пошло не так — откат за 2 минуты.

На моей практике, staging-сервер окупает себя на третьем проекте. Без него каждый деплой — это стресс и риск. С ним — рутинная операция.

Что конкретно мы проверяем

Checkout — критический путь

Оформление заказа — место, где теряется больше всего денег. Мы проверяем:

• Гостевой заказ (без регистрации)
• Заказ с регистрацией и авторизацией
• Все способы оплаты (ЮKassa, СБП, наложенный платёж, банковская карта)
• Все способы доставки (СДЭК, Boxberry, курьер, самовывоз)
• Применение промокодов и скидок
• Email/SMS-уведомления после заказа
• Интеграция с CRM: заказ появился в amoCRM/RetailCRM с правильными данными
• Интеграция с 1С: заказ ушёл в обмен, резервирование товара на складе

Особое внимание — edge-кейсам: пустая корзина, товар с нулевым остатком, доставка в отдалённый регион, одновременное оформление двух заказов на один товар.

Производительность

Мы замеряем время загрузки ключевых страниц на staging (без CDN и кеша — чтобы видеть реальную скорость):

Замеры на staging без CDN и Redis. На продакшене с кешем цифры будут лучше на 30–50%.

Нагрузочные тесты

Перед запуском крупного магазина (от 10 000 товаров или ожидаемого трафика от 500 одновременных посетителей) мы проводим нагрузочные тесты:

# Apache Bench: 100 запросов, 10 одновременныхab -n 100 -c 10 https://example.com/catalog/k6 run --vus 50 --duration 30m load-test.js

Цель: сервер должен выдерживать пиковую нагрузку без ошибок и с временем отклика менее 2 секунд. Факт. Если не выдерживает — проблема в хостинге, кеше или неоптимизированных запросах к БД.

Типичные ошибки, которые мы находим

1. Отсутствие бэкапов перед деплоем. Каждый второй проект приходит к нам без автоматических бэкапов. Один сбой = потеря данных за месяц.
2. Тестирование «глазами» вместо чек-листа. «Проверил, вроде работает» — не тестирование. Нужен чек-лист с конкретными сценариями, и каждый пункт проверяется отдельно.
3. Нет staging-сервера. Тестирование на продакшене — это риск для реальных клиентов. Если staging невозможен — хотя бы бэкап и тестирование в нерабочее время.
4. Не проверяют edge-кейсы. Пустая корзина, товар без остатка, кириллица в имени, спецсимволы в комментарии — именно эти ситуации ломают checkout.
5. Не проверяют интеграции. Заказ прошёл на сайте, но не ушёл в CRM. Оплата прошла, но статус не обновился. Товар зарезервирован, но остаток не уменьшился.

Что мы гарантируем

Каждый проект сопровождается гарантией на выполненные работы: от 30 до 90 дней в зависимости от объёма. Перед опасными изменениями — обязательный бэкап и тестирование на staging-сервере. Ошибки по нашей вине исправляем бесплатно.

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

Рекомендации из практики

Как лучше: QA OpenCart-магазина должно включать: проверку вёрстки на 3 размерах экрана, тестирование корзины и оплаты, проверку скорости. По практике, большинство критических багов находятся в платёжных модулях и корзине — проверяйте их в первую очередь.

Как не делать: Не выпускайте обновления без QA на тестовом стенде. Даже замена одной строки в языковом файле может вызвать ошибку 500, если нарушен синтаксис.

Кейс из практики: Команда QA тестировала магазин перед запуском. Нашли баг: на мобильных устройствах кнопка «Купить» наезжала на фото. Исправили до запуска — если бы не протестировали, потеряли бы часть мобильных продаж с первого дня.

Нужна помощь — закажите технический аудит: проверим и настроим.

Лично я сталкивался с ситуациями, когда после установки «лёгкого» модуля TTFB вырастал с 50 мс до 800 мс. Причина — кривой OCMOD-модификатор, который дёргал SQL-запросы без индексов. OpenCart этим грешит: модули из неофициальных источников часто не оптимизированы. Лечится аудитом запросов через slow-query-log и рефакторингом oc_product_to_category.

OCMOD — палка о двух концах. С одной стороны, позволяет править файлы без взлома ядра. С другой — десять модификаторов от разных авторов гарантированно конфликтуют. Особенно если один правит catalog/controller/product/category.php, а другой пытается расширить его функционал. Порядок загрузки OCMOD имеет значение, но документация об этом молчит.

FAQ

Вы даёте гарантию на работы?

Да. Гарантия — от 30 до 90 дней, фиксируется в договоре. В течение этого срока ошибки по нашей вине исправляем бесплатно. Срок зависит от объёма работ: доработка модуля — 30 дней, создание магазина — 90 дней.

Что будет, если после доработки что-то сломается?

Перед любыми изменениями — бэкап и тестирование на staging. Если проблема возникла по нашей вине — исправляем бесплатно. Если по вине клиента (обновил модуль самостоятельно, поменял хостинг) — обсуждаем индивидуально. В 90% случаев проблема решается за один рабочий день.

Сколько времени занимает тестирование?

Зависит от объёма: для небольшого магазина (до 1 000 товаров) — 1–2 дня. Для крупного каталога с интеграциями — 3–5 дней. Нагрузочные тесты — отдельный этап, 1–2 дня. Аудит безопасности — 2–3 дня.

Можно ли тестировать без staging?

Технически да, но с ограничениями: тестирование проводится в нерабочее время, после обязательного бэкапа. Это медленнее и рискованнее, чем staging. Рекомендую выделять хотя бы минимальный staging (VPS за 500 ₽/мес) — это страховка, которая окупается.

Источники

• OWASP Top 10
• Google: Web Performance

Подробнее про тестирование — закажите технический аудит.

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

Как не надо. Не копируйте готовые решения из интернета без проверки совместимости с вашей версией OpenCart и установленными модулями. То, что сработало у другого владельца магазина, может сломать ваш сайт — особенно если у вас нестандартная сборка. Всегда делайте бэкап перед любыми изменениями.

📌 Рекомендуем к прочтению:

• расчёт unit-экономики вашего магазина
• как увеличить средний чек магазина
• интеграцию с маркетплейсами
• как правильно считать прибыль магазина
• как написать продающие описания товаров
• как настроить приём платежей в OpenCart
• настройку email-уведомлений в OpenCart