Перейти к содержимому
BXWiki

Тестирование и выкладка проекта на 1С-Битрикс

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

Как это работает

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

Модульные тесты пишут для технически сложного кода, низкоуровневых библиотек и случаев, где ручная проверка долгая. Для простой типовой функциональности они обычно не окупаются. Как их писать на практике при ядре, которое держит глобальное состояние, - в статье «Модульное тестирование».

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

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

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

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

Примеры

1. Идемпотентная миграция

$currentVersion = (int)\Bitrix\Main\Config\Option::get('my.module', 'db_version', 0);


$migrations = [
    1 => static function (): void {
        $connection = \Bitrix\Main\Application::getConnection();
        if (!$connection->isTableExists('my_module_item')) {
            \My\Module\ItemTable::getEntity()->createDbTable();
        }
    },
    2 => static function (): void {
        $connection = \Bitrix\Main\Application::getConnection();
        if (!$connection->getTableField('my_module_item', 'SORT')) {
            $connection->queryExecute('ALTER TABLE my_module_item ADD SORT INT DEFAULT 500');
        }
    },
];


foreach ($migrations as $version => $migration) {
    if ($version <= $currentVersion) {
        continue;
    }


    $migration();
    \Bitrix\Main\Config\Option::set('my.module', 'db_version', $version);
}

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

2. Расчёт нагрузки

средний уровень = хиты за сутки / 86400
пиковый уровень = средний × 2..3

Сценарий составляют по реальному поведению: доля посетителей каталога, карточек, поиска и оформления заказа отличается на порядки, и тест «только главная» показывает погоду на Марсе. Данные должны быть реального объёма - на пустом каталоге любой запрос быстрый.

3. Порядок выкладки

  1. Код и миграции проходят проверку на тестовом окружении - точной копии боевого.
  2. Перед обновлением боевого делают резервную копию и снимок для отката.
  3. Выкладывается код, затем выполняются миграции.
  4. Проверяются ключевые сценарии: главная, каталог, оформление заказа, вход.
  5. При проблеме - откат на снимок, а не спешный «хотфикс» на бою.

Справочник

ЭлементНазначениеОсобенности
Наборы условий проверкиописание ожидаемого поведенияхранятся вместе с требованиями
Модульные тестыпроверка отдельных частей кодадля сложного и низкоуровневого
Функциональные тестысценарии целикомобычно браузерная автоматизация
Бета-тестированиепроверка силами клиенталовит мелкие несоответствия
Монитор качестваштатная проверка перед сдачей
Генератор нагрузкипрогон сценариевпри нехватке машины - распределённый режим
Клиентские метрикизадержки, коды ответов, доля ошибок
Серверные метрикипроцессор, память, диски, сетьсопоставляются с клиентскими
Скрипты миграцийверсионирование структуры базыидемпотентные, версия в настройках
Цепочка окруженийразработка, тест, бойв стабильную ветку только проверенное
Резервная копия и снимокоткатделаются до выкладки

Частые ошибки

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

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

Миграции не идемпотентны. Повторный запуск ломает структуру или падает, а на разных серверах схема расходится.

Структуру базы правят руками на бою. Через несколько релизов никто не может воспроизвести окружение, а тестовый сервер перестаёт быть копией боевого.

Тестовое окружение отличается от боевого. Другая версия PHP, другие настройки кеша, другой объём данных - и тестирование перестаёт что-либо гарантировать.

Нет плана отката. Резервная копия и снимок делаются до выкладки, а не после того, как что-то пошло не так.

Частые вопросы

Как версионировать структуру базы?

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

Сколько нагрузки закладывать в тест?

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

Какие тесты писать на проекте на Битрикс?

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

Как быстро откатить неудачный релиз?

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

Связанные темы

Первоисточники