Тесто как настроить интерфейс

Обзор модульного и интеграционного тестирования Spring Boot

Модульное и интеграционное тестирование — неотъемлемая часть вашей повседневной жизни как разработчика. Однако для новичков Spring Boot написание содержательных тестов для своих приложений оказывается проблемой:

С чего начать мои усилия по тестированию?

Как Spring Boot может помочь мне в написании эффективных тестов?

Какие библиотеки мне использовать?

В этом блоге вы получите обзор того, как модульное и интеграционное тестирование работает со Spring Boot. Кроме того, вы узнаете, на каких функциях и библиотеках Spring следует сосредоточиться в первую очередь. Эта статья действует как агрегатор, и в нескольких местах вы найдете ссылки на другие статьи и руководства, которые более подробно объясняют концепции.

Модульное тестирование с помощью Spring Boot

Модульные тесты составляют основу вашей стратегии тестирования. Каждый проект Spring Boot, который вы запускаете с помощью Spring Initializr, имеет прочную основу для написания модульных тестов. Настраивать практически нечего, так как Spring Boot Starter Test включает в себя все необходимые строительные блоки.

Помимо включения и управления версией Spring Test, этот Spring Boot Starter включает и управляет версиями следующих библиотек:

Библиотеки проверки утверждений, такие как AssertJ, Hamcrest, JsonPath и т. Д.

Вы можете найти введение в этот швейцарский нож тестирования и включенных в него библиотеках тестирования в этом сообщении блога.

В большинстве случаев ваши модульные тесты не нуждаются в какой-либо конкретной функции Spring Boot или Spring Test, поскольку они будут полагаться исключительно на JUnit и Mockito.

С помощью модульных тестов вы изолированно тестируете, например, свои *Service классы и имитируете каждого сотрудника тестируемого класса:

Как видно из раздела import тестового класса выше, Spring вообще не включается. Следовательно, вы можете применять методы и знания, полученные из модульного тестирования любого другого приложения Java.

Вот почему важно изучить основы JUnit 4/5 и Mockito, чтобы максимально использовать возможности модульного тестирования.

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

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

Тесты фрагментов Spring Context

В дополнение к традиционным модульным тестам вы можете писать тесты с помощью Spring Boot, которые нацелены на определенные части (фрагменты) вашего приложения. TestContext Spring фреймворка вместе с Spring Boot адаптирует Spring контекст с достаточным количеством компонентов для конкретного теста.

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

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

Spring Boot предлагает много аннотаций, позволяющих проверить различные части вашего приложения в отдельности: @JsonTest , @WebMvcTest , @DataMongoTest , @JdbcTest и т.д.

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

Две наиболее важные аннотации (сначала изучите их):

Также доступны аннотации для других нишевых частей вашего приложения:

При их использовании важно понимать, какие компоненты входят в состав, TestContext а какие нет. Документация Javadoc каждой аннотации объясняет выполненную автоконфигурацию и цель.

Вы всегда можете расширить контекст автонастройки для своего теста, явно импортировав компоненты с помощью @Import или определив дополнительные компоненты Spring Beans, используя @TestConfiguration :

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

Ловушка JUnit 4 и JUnit 5

Одна большая ловушка, с которой я довольно часто сталкиваюсь, отвечая на вопросы на Stack Overflow, — это сочетание JUnit 4 и JUnit 5 (JUnit Jupiter, если быть более конкретным) в одном тесте. Использование API разных версий JUnit в одном тестовом классе может привести к неожиданным результатам и сбоям.

Важно следить за импортом, особенно за @Test аннотацией:

Другими индикаторами для JUnit 4 являются: @RunWith , @Rule , @ClassRule , @Before , @BeforeClass , @After , @AfterClass .

С помощью JUnit 5 vintage-engine ваш набор тестов может содержать как тесты JUnit 3/4, так и JUnit Jupiter, но каждый тестовый класс может использовать только одну конкретную версию JUnit. Рассмотрите возможность миграции существующих тестов, чтобы использовать различные новые функции JUnit Jupiter (параметризованные тесты, распараллеливание, модель расширения и т. д.). Вы можете постепенно мигрировать свой набор тестов, так как вы можете запускать тесты JUnit 3/4 рядом с тестами JUnit 5.

Документация JUnit включает советы по миграции JUnit 4, а также имеются инструменты (JUnit Pioneer или эта функция IntelliJ) для автоматической миграции тестов (например, импорт или проверки утверждений).

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

Кроме Spring Boot Starter Test другие зависимости тестования также могут включать более старые версии JUnit:

Чтобы избежать (случайного) включения зависимостей JUnit 4 в будущем, вы можете использовать Maven Enforcer Plugin и определить его как запрещенную зависимость. Это приведет к сбою сборки, как только кто-то включит новую тестовую зависимость, которая транзитивно потянет JUnit 4.

Обратите внимание, что, начиная с Spring Boot 2.4.0, зависимость Spring Boot Starter Test больше не включает vintage-engine файл по умолчанию.

Интеграционные тесты с Spring Boot: @SpringBootTest

С помощью интеграционных тестов вы обычно тестируете несколько компонентов вашего приложения в комбинации. Большая часть времени вы будете использовать @SpringBootTest аннотацию для этой цели и доступ к приложению с внешней стороны с помощью либо WebTestClient или TestRestTemplate .

@SpringBootTest будет заполнять весь контекст приложения для теста. При использовании этой аннотации важно понимать атрибут webEnvironment . Без указания этого атрибута такие тесты не будут запускать встроенный контейнер сервлетов (например, Tomcat) и вместо этого будут использовать имитацию среды сервлетов. Следовательно, ваше приложение не будет доступно через локальный порт.

Вы можете переопределить это поведение, указав либо, DEFINE_PORT либо RANDOM_PORT :

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

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

Здесь в игру вступают Testcontainers. Testcontainers будет управлять жизненным циклом любого Docker контейнера для вашего теста:

Для ознакомления с Testcontainers рассмотрите следующие ресурсы:

Если ваше приложение обменивается данными с другими системами, вам нужно решение для имитации этого HTTP-взаимодействия. Это довольно часто бывает, когда вы, например, получаете данные из удаленного REST API или токенов доступа OAuth2 при запуске приложения. С помощью WireMock вы можете заглушить и подготовить HTTP-ответы для имитации удаленной системы.

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

Сквозные тесты с Spring Boot

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

Вы также можете выполнить тесты E2E для развернутой версии приложения, например, в среде dev или staging прежде чем приступить к развертыванию в рабочей среде.

Для приложений, которые используют рендеринг на стороне сервера (например, Thymeleaf) или автономной системы, когда серверная часть Spring Boot обслуживает интерфейс, вы можете использовать @SpringBootTest для этих тестов.

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

Следующий тест демонстрирует, как получить доступ и протестировать общедоступную страницу приложения Spring Boot с помощью Selenide:

Вы можете найти больше информации о Selenide в этом сообщении в блоге.

Для компонентов инфраструктуры, которые необходимо запустить для тестов E2E, Testcontainers играет большую роль. Если вам нужно запустить несколько Docker контейнеров, вам пригодится модуль Docker Compose из Testcontainers :

Резюме

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

Кроме того, аннотации Spring Boot test упрощают написание тестов для различных частей вашего приложения. Вы получите специально созданный Spring TestContext только с соответствующими Spring beans.

Чтобы познакомиться с модульными и интеграционными тестами для ваших проектов Spring Boot, рекомендуются следующие шаги:

Избегайте ловушки JUnit 4 и JUnit 5.

Ознакомьтесь с различными аннотациями тестирования Spring Boot, которые автоматически настраивают фрагменты контекста.

Узнайте, как Spring TestContext Caching может помочь сократить общее время выполнения вашего набора тестов.

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

Кроме того, активность сообщества на Stack Overflow для таких тегов, как spring-test , spring-boot-test или spring-test-mvc , довольно хороша, и есть большая вероятность, что вы получите помощь. Я также часто отвечаю на вопросы, связанные с тестированием, на Stack Overflow.

Удачного модульного и интеграционного тестирования с помощью Spring Boot,

Источник

Как делать A/Б тесты в Google Optimize [бесплатно и без программиста]

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

Для этих задач подходит Google Optimize. Этот сервис создан для тестирования изменений на страницах и оценки их эффективности с точки зрения поведения пользователей. Детально разобрали, как с ним работать, какие есть виды тестирования, по шагам показали настройку А/Б теста.

Для чего нужен Google Optimize

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

Упрощенно процесс выглядит так:

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

Структура Google Optimize

Чтобы было проще разобраться с работой сервиса, полезно понимать его структуру. Она состоит из трех уровней:

1. Аккаунт — первый уровень, с которого начинается работа с сервисом.
2. Контейнер — второй уровень. В каждом контейнере — информация о сайте и проводимых экспериментах.
3. Эксперимент — здесь запускаются эксперименты для тестирования гипотез. О видах тестирования мы еще расскажем.

Для внесения изменений на сайт используется браузерное расширение Google Optimize. Расширение позволяет редактировать существующие элементы или добавлять новые для проведения экспериментов — без вмешательства в исходный код сайта.

Работа с сервисом: интерфейс и основные возможности

Перейдите на страницу Google Optimize (можете сделать это по прямой ссылке или найти сервис в Google Marketing Platform).

Кликните «Start for free».

После клика вы будете перенаправлены на русскоязычную версию сервиса (Google Оптимизация).

Обратите внимание, для работы с сервисом вам нужен аккаунт Google (если у вас его нет — создайте), а также аккаунт Google Аналитики.

Настраиваем контейнер

После создания аккаунта в Google Optimize необходимо добавить первый контейнер. В нем будут храниться данные о ресурсах, с которыми проводятся эксперименты, и сами эксперименты.

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

Чтобы переименовать контейнер, откройте его и кликните по кнопке «Настройки».

Затем кликните по знаку карандаша в блоке «Сведения о контейнере».

Если вы планируете проводить тесты на разных сайтах, удобно следовать такой логике: для одного сайта — один контейнер. Однако это не обязательное условие. В одном контейнере могут быть проекты для нескольких сайтов.

Выбираем тип проекта (эксперимента)

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

• протестировать цвет или текст CTA-кнопок;
• сравнить эффективность посадочной страницы с видео на первом экране и без него;
• проанализировать эффективность разных форм обратной связи и т. д.

В сервисе доступно 4 вида проектов. Расскажем о каждом из них.

Эксперимент А/Б

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

Google будет распределять трафик между вариантами страницы в зависимости от настроек:

• Равномерно — каждый вариант получит равную долю трафика. Например, если вы создали 5 вариантов страницы, каждый из них получит по 20% от общего трафика.
• Заданную вручную долю трафика. В настройках вы можете указать, на какой из вариантов направить больше трафика.

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

Дополнительно можно указать, какая доля общего трафика должна участвовать в эксперименте.

Самый простой пример А/Б теста — тестирование разного цвета кнопок. Например, изначально на сайте стоит CTA-кнопка синего цвета, но мы хотим проверить гипотезу: изменится ли конверсия, если кнопка будет более яркой (скажем, красной). Для этого создаем вариант исходной страницы с измененным цветом кнопки.

После запуска проекта Google Optimize будет рандомизированно распределять трафик между вариантами страницы и сравнивать эффективность по заданному параметру (например, по уровню конверсии).

Многовариантный эксперимент

В отличие от А/Б теста он позволяет протестировать изменение сразу нескольких элементов.

Например, этот вариант подойдет, если нужно протестировать два заголовка и три изображения.

Система создаст все возможные комбинации страниц, в зависимости от того, сколько элементов и какое количество вариантов мы хотим протестировать. В нашем примере будет создано 6 комбинаций (2 заголовка * 3 картинки = 6).

Если вы хотите посмотреть, изменение какого элемента на странице даст больший прирост конверсий, используйте этот вариант экспериментов.

Эксперимент с переадресацией

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

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

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

Чтобы узнать, что сработает лучше, создайте в Google Optimize эксперимент с переадресацией и укажите две страницы с разным URL:

• в качестве исходной укажите лендинг, где все расписано максимально подробно;
• в качестве тестируемой — лаконичный.

После завершения тестов вы получите данные и узнаете, какой из вариантов посадочной страницы сработал лучше.

Персонализация

Позволяет вносить изменения на сайте для персонализированного показа определенной аудитории. Персонализация нужна после того, как вы уже провели эксперимент (например, А/Б тест) и определили выигрышный вариант изменений. На основе этого варианта Google Optimize создаст персонализацию. Ее можно настроить для показа любому сегменту аудитории.

Также «Персонализация» пригодится в случаях, когда нужно запустить краткосрочную акцию для определенного сегмента аудитории. Например, с 1 по 31 июля вы хотите предложить бесплатную доставку клиентам из Москвы. Для этого создаете проект с типом эксперимента «Персонализация». Вносите изменения на сайт с помощью браузерного расширения Google Optimize — добавляете текст с информацией о бесплатной доставке. В настройках таргетинга указываете целевое местоположение — Москва.

После запуска эксперимента жители Москвы будут видеть ваше предложение, а остальным пользователям будет показана обычная версия страницы.

Настраиваете и ведете контекст/таргет? Подключитесь в Click.ru, и вы будете получать до 6% от оборота с контекстной и до 10% от оборота с таргетированной рекламы. Кроме того, вы получите доступ к бесплатным инструментам и объедините всю рекламу в одном интерфейсе (единый баланс, один договор, закрывающие документы).

Как создать и запустить A/Б тест в Google Optimize: пример настройки

Покажем пошагово, как запустить тест в Google Optimize. Для примера возьмем сайт детской тематики.

• Тип эксперимента: А/Б тест.
• Тестировать будем цвет кнопок в превью статей блога.

Первым делом создаем проект в контейнере:

В базовых настройках указываем:

• название эксперимента (делаем его информативным, чтобы можно было сразу понять, что именно тестировали);
• URL страницы, на которой будем тестировать вид кнопок;
• в блоке с вариантами экспериментов выбираем «Эксперимент А/Б».

В созданном проекте необходимо:

• создать варианты с измененными элементами на странице для тестирования;
• задать правила таргетинга — здесь нужно указать, какая аудитория должна участвовать в эксперименте;
• связать проект с аккаунтом Google Аналитики;
• настроить основные и дополнительные цели (по ним Google Optimize будет определять, какой вариант более эффективен).

По умолчанию эксперимент длится 90 дней, а затем завершается. 90 дней — максимальный срок эксперимента, продлить его нельзя. Единственное, что можно сделать — уменьшить срок, настроить график запуска и окончания. Для этого кликните по иконке часов в панели инструментов.

Затем нужно указать дату начала и окончания эксперимента. Если длительность для вас не важна, можете указать только дату начала — через 90 дней эксперимент завершится автоматически.

Создаем варианты страницы с измененным элементом

На странице блога у нас есть превью статей и кнопка «Read More» оранжевого цвета. С помощью теста мы хотим узнать, будут ли чаще кликать на нее и открывать полную статью, если изменить цвет кнопки.

В эксперименте установим красный цвет для кнопки. Жмем «Создать вариант», указываем название и сохраняем его.

Затем кликаем по кнопке «Изменить».

Откроется страница блога, на которой будет показана панель инструментов расширения Google Optimize. Если расширение у вас еще не установлено, при нажатии на «Изменить» система предложит установить его. Меняем цвет кнопки «READ MORE» на красный и сохраняем изменения.

По умолчанию трафик распределяется между исходной страницей и тестовыми вариантами поровну. У нас только один тестовый вариант, поэтому распределение трафика — 50/50.

Это соотношение можно изменить вручную и установить любое другое: например, 60% — для исходной страницы, 40% — для тестовой.

Настраиваем таргетинг: выбираем аудиторию, которая будет участвовать в эксперименте

Кликаем по ссылке «правила выбора целевой аудитории».

Выбираем тип правил для настройки таргетинга.

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

• аудитории из Google Аналитики;
• трафик из Google Ads (например, направить на тестируемую страницу трафик из определенного аккаунта, кампании, группы объявлений или ключевого слова);
• таргетинг на основе UTM-меток. Можно показывать тестовую страницу только тем, кто переходит по ссылке с определенной UTM-меткой. Например, так можно таргетироваться на аудитории из разных рекламных каналов (email-рассылки, реклама в Facebook и т. д.);
• определенные устройства. К примеру, можно показывать тестируемые варианты страницы только пользователям смартфонов;
• пользователи с определенных городов, регионов или стран;
• таргетинг по технологиям (здесь можно указать операционную систему, браузер или тип мобильного устройства).

Задаем геотаргетинг

В правилах таргетинга кликаем по пункту «Геоданные». Выбираем из выпадающего списка уровень, на котором будем задавать таргетинг. Здесь доступно четыре уровня:

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

Задаем правило для страницы

В блоке «Таргетинг на страницы» жмем «Добавить правило для URL».

Здесь необходимо указать адрес страницы, при переходе на которую пользователям будут показаны тестируемые варианты.

Устанавливаем связь с Google Analytics

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

При авторизации в Google Optimize мы использовали тот же аккаунт Google, на котором зарегистрирована Google Аналитика. Поэтому выбираем нужный ресурс из списка. Выбираем представление «Все данные по веб-сайту».

Жмем «Создать». Сервис генерирует обновленный тег счетчика Аналитики. Вставляем код в разделе на сайте.

После установки связи с Google Аналитикой в интерфейсе отобразится уникальный идентификатор эксперимента.

Выбираем основную и дополнительные цели, по которым будет оцениваться эффективность эксперимента

В блоке «Цели» указываем основную цель эксперимента — она нужна для оценки результатов и определения выигрышного варианта. Есть два способа:

• выбрать из списка — выбрать цель, которая уже есть в Google Аналитике;
• создать собственную — создать новую цель.

Нужная нам цель уже есть в связанном аккаунте Google Аналитике, поэтому выбираем пункт «Выбрать из списка». Во всплывающем окне покажется список доступных целей. Кликаем по нужной — она будет установлена в качестве основной цели.

Также можно указать до двух дополнительных целей (для замеров дополнительных метрик).

Указываем дополнительные настройки

В принципе, проект уже можно запускать, но давайте пройдемся по дополнительным настройкам (находятся в блоке «Настройки» после настроек целей).

На что здесь нужно обратить внимание:

• Установка кода Оптимизации. Здесь можно проверить, корректно ли установлен код Оптимизации на страницах сайта и работает ли он.
• Распределение трафика. По умолчанию здесь установлено значение 100%. Это значит, что все посетители сайта будут участвовать в эксперименте: кому-то будет показана исходная версия страницы, кому-то — измененная. Если у вашего сайта небольшая посещаемость, не рекомендуем менять эту настройку. Если сузить и без того небольшой трафик, в эксперименте будет недостаточно данных для принятия взвешенного решения об оптимизации сайта. Для ресурсов с большим трафиком можно установить меньший процент.

Следующий шаг — запуск проекта. Кликаем по кнопке «Ок» на панели инструментов. Сервис покажет код проекта, который необходимо разместить на тестируемой странице сайта.

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

Источник