Тестирование WooCommerce для разработчиков

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

#10003; GT BOGO Engine PRO включает 30-дневную гарантию возврата денег.

Эта статья предназначена для разработчиков WooCommerce и технических руководителей, которые хотят применять профессиональную строгость тестирования для работы с промо-плагином. Мы рассмотрим шаблоны тестирования, которые имеют значение для развертывания промо-акций, как выглядят рабочие процессы постановки для промо-логики, почему автоматическое покрытие тестов имеет большее значение для промо-кода, чем для многих других категорий плагинов, и что GT BOGO Engine предоставляет разработчикам, которые хотят проверяемую промо-логику, а не развертывание кораблей и молотков.

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

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

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

Данные об отказе от корзины из Baymard Institute, основанные на 50 отдельных исследованиях отказа от корзины, ставят глобальный средний показатель в 70,22%. Непроверенная промо-логика способствует отказу от корзины, когда клиенты видят неожиданное поведение - скидки, которые должны применяться, но не применяются, цены, которые меняются между корзиной и кассой, или правила, которые дают разные результаты в разных состояниях корзины. Тестирование строгости уменьшает отказ, обеспечивая последовательное поведение рекламной логики во всем диапазоне состояний корзины, которые клиенты фактически составляют.

Как выглядит промо-тестирование производственного класса

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

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

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

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

Что GT BOGO Engine предоставляет для тестирования и постановки рабочих процессов

GT BOGO Engine является первой в мире системой автоматизации корпоративного класса Buy X Get Y, построенной специально для WooCommerce. Платформа включает в себя 48 суперсил, работающих внутри WooCommerce автоматически, плюс 200 предварительно построенных пакетов кампаний в 19 отраслях, а также утилиты тестирования, ориентированные на разработчиков, и дружественную к постановке архитектуру, которая поддерживает профессиональные рабочие процессы тестирования. Для ориентированного на тестирование использования, в частности, четыре возможности имеют значение для операционной реальности построения рекламных развертываний производственного уровня.

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

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

В-третьих, REST API платформы позволяет проводить интеграционное тестирование через наборы тестов, управляемых API. Тесты могут предоставлять сценарии тележек через API, проверять вычисленные сценарии тележек на соответствие ожидаемому поведению и проверять правильность запуска событий жизненного цикла. Шаблон тестирования, управляемый API, работает вместе с утилитами тестирования на уровне PHP платформы и обеспечивает покрытие тестов, которое отражает, как платформа ведет себя в реальных контекстах интеграции с клиентами. Для получения дополнительной информации о REST API см. скидки WooCommerce REST API.

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

Как разработчики структурируют тестирование и инсценируют рабочие процессы

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

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

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

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

Сравнение: случайное развертывание против производственно-пропагандистского тестирования

| Компонент рабочего процесса | Случайное развертывание | Производственно-штатный рабочий процесс | |-- |-- |-- | Полное покрытие по логике правил | Ограниченное покрытие по логике интегрирования | | Ограниченное покрытие по логике правил | | Ограниченное покрытие по логике правил | | Ограниченное покрытие по логике интеграции, интеллекту, жизненному циклу | | Пошаговая среда | Пошаговая среда | Требуется с репрезентативными данными | | Конфигурационная контрольная точка версии | Руководство | Скриптовано через JSON Экспортно-импортную структуру | Эксплицитно с контрольной точкой развёртывания | Явно с запиской заинтересованных сторон | Реактивный | Проактивный против базовых метрик | | Руководящие процедуры | Скриптовано с помощью восстановления конфигурации | Поймано в процессе восстановления конфигурации | Поймано в постановке | Поймано в постановке | Поймано в постановке | Поймано в постановке | По

Тестирование в реальном мире и шаблоны постановки

Небольшое агентство WordPress, обслуживающее 10 клиентов WooCommerce, внедряет стандартизированный рабочий процесс тестирования по всему портфелю. Каждый клиент имеет среду постановки, которая отражает производство, автоматизированные интеграционные тесты, которые выполняются на изменениях конфигурации, и контрольные точки развертывания, которые требуют явного входа в систему перед развертыванием производства. Стандартизация означает строгость тестирования в масштабах всего агентства независимо от того, какой специалист выполняет работу, что обеспечивает согласованное качество для клиентов и уменьшает производственные инциденты от ошибок рекламной логики.

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

Распределительная платформа B2B, использующая сложную рекламную логику с учетом уровня, реализует тестирование на основе сценария. Каждый уровень клиента имеет репрезентативные сценарии корзины в наборе тестов, с ожидаемым поведением ценообразования, документированным для каждого сценария. Тесты выполняются на каждом изменении конфигурации, чтобы убедиться, что поведение с учетом уровня остается правильным по мере развития правил. Модель на основе сценария улавливает регрессии в сложных правилах с несколькими условиями, которые было бы трудно обнаружить с помощью случайного тестирования. Для более широкого контекста на архитектуре разработчика см. руководство для разработчиков GT BOGO Engine.

Миграционный путь для существующих рабочих процессов тестирования

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

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

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

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

Структура цен и лицензий для разработки и тестирования

GT BOGO Engine PRO составляет 499 долларов в год за один магазин WooCommerce без уровней ценообразования на каждую функцию. Лицензия охватывает развертывание производства; среды постановки обычно используют бесплатный плагин ядра или лицензию на разработку в зависимости от требований к строгости тестирования развертывания. Большинство агентств и групп разработчиков используют бесплатный плагин ядра для сред постановки и лицензию PRO для производства, которая сохраняет эффективность тестирования инфраструктуры при защите производства с полными возможностями PRO.

Индивидуальные отраслевые PRO-пакеты стоят 79,99 долларов каждый. Три уровня пакетов предлагают экономию: Starter Bundle (299 долларов за 5 пакетов, экономия 100,95 долларов), Growth Bundle (299 долларов за 9 пакетов, экономия 220,91 долларов) и Complete Arsenal (799 долларов за 15 пакетов, экономия 400,85 долларов). Для агентств, работающих в средах постановки для нескольких клиентов, среда постановки обычно не нуждается в библиотеке полного пакета - этапные тесты сосредоточены на логике правил и шаблонах интеграции, а не на полном развертывании кампании, что означает, что постановка может работать с подмножеством пакетов.

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

Часто задаваемые вопросы от разработчиков

Какие утилиты тестирования выставляет платформа для модульного тестирования?

Платформа раскрывает макет корзины и клиентские контексты, которые пользовательский код использует в единичных тестах. Утилиты макетного контекста предоставляют структурированные тестовые вводы, которые соответствуют структурам производственного контекста, что означает, что единичные тесты, написанные против макетных контекстов, дают результаты, которые согласуются с производственным поведением. Утилиты тестирования документируются в руководстве для разработчиков и следуют стандартным шаблонам тестирования WordPress и WooCommerce.

Как платформа обрабатывает среды постановки с анонимными данными клиентов?

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

Можно ли перенаправить электронные письма жизненного цикла платформы в промежуточных средах?

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

Как платформа обрабатывает интеграцию CI/CD для рекламной логики?

Структура экспорта-импорта конфигурации поддерживает рабочие процессы CI/CD. Изменения конфигурации могут контролироваться версией, поскольку экспорт JSON применяется к средам постановки через импорт сценариев, проверяется через автоматизированные тестовые наборы и продвигается к производству через рабочие процессы развертывания сценариев. Модель интегрируется со стандартными платформами CI/CD (GitHub Actions, GitLab CI, Jenkins, CircleCI) без необходимости расширения для конкретной платформы.

Каковы типичные усилия по добавлению испытаний производственного уровня к существующим рекламным развертываниям?

Большинство существующих рекламных развертываний требуют от 2 до 4 недель целенаправленных усилий для добавления строгости тестирования производственного уровня. Охват тестированием блока занимает около недели. Охват тестированием блока занимает еще неделю. Настройка среды постановки с репрезентативными данными занимает несколько дней. Интеграция CI/CD занимает еще несколько дней. Совокупные усилия обеспечивают устойчивую строгость тестирования, которая защищает производственные развертывания от регрессии рекламной логики, которая обычно приводит к значительному сокращению промо-инцидентов в течение первого квартала после установления строгости тестирования. Для более широкого контекста на архитектуре разработчика см. Архитектура нулевого конфликта разработчика.

GT BOGO Engine построен GRAPHIC T-SHIRTS, настоящим магазином WooCommerce с более чем 1200 оригинальными проектами, работающими в масштабе. Посетите gtbogoengine.com, чтобы загрузить бесплатный плагин ядра, оценить утилиты тестирования и дружественную к постановке архитектуру и решить, соответствует ли платформа строгости тестирования, требуемой для вашего развертывания. Для более широкого контекста см.