Pull to refresh

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

Reading time 6 min
Views 2.3K
Не так давно один из крупнейших интернет-магазинов проводил рекламную акцию в честь дня рождения компании. Для приёма заказов у них предусмотрены два виртуальных многоканальных телефонных номера 8-800 от разных операторов связи, а для их обработки написана своя система CRM и организована работа call-центра на аутсорсе. Изначальный прогноз заходов покупателей на сайт вызвал сомнения в том, что все системы справятся. Для того чтобы не потерять лиды, было решено протестировать телефонные каналы и CRM-систему.


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

Тестирование телефонии


Нашей задачей было создать распределенную телефонную нагрузку по России: 70% из Москвы, остальное из регионов. Во входящий поток нужно было подать голосовое сообщение, а на стороне call-центра было необходимо, чтобы сотрудник поднял трубку. В результате получилось два потока (исходящий и входящий), которые можно было проанализировать на качество голоса и сравнить с эталонными записями.

Так как клиенты интернет-магазина находятся в разных городах РФ, для имитации нагрузки были выделены номера для тестирования. В качестве провайдеров услуг связи для ЦОВ использовались два различных телекоммуникационных оператора. Нагрузка генерировалась с нарастанием до 5 CPS (Call Per Seconds) и с продолжительностью одного генерируемого вызова не менее 180 сек (3 минуты). Ограничение одновременного количества вызовов — до 350.



Для выявления ошибок в телекоммуникационном оборудовании и его тонкой настройки используется наша собственная МТТ Система генерации и сбора статистики. Это комплекс программно-аппаратных средств и методик генерации высоконагруженных тестов посредством SIP-телефонии и последующего анализа результатов.

Тестирование проводилось в три этапа:

  • На первых двух тестировались каналы операторов.

  • На третьем этапе тестировалась логика работы IVR центра обработки вызовов (ЦОВ) путем генерации нагрузки по каналам одного из операторов.

Методика тестирования


При помощи системы генерации нагрузки и сбора статистики создавался нарастающий поток вызовов на номер ЦОВ нашего клиента в соответствии с этапом проведения испытания. Это работало так:

  1. Система поочередно подставляла в качестве источника вызова номер из списка номеров АОН.

  2. Затем формировался вызов через узел связи, соответствующий подставляемому АОНу.

  3. Производилась запись транслируемого со стороны ЦОВ заказчика приветственного шаблонного файла с проговариваемым диктором текстом (в формате WAV, 8000Hz, моно) в течение 20 секунд после получения информации о соединении.

  4. После этого через паузу в 1 секунду в направлении ЦОВ заказчика проигрывался шаблонный файл с проговариваемым диктором текстом (в формате WAV, 8000Hz, моно).

  5. По результату вызова CDR (Call Detail Records) фиксировались качественные параметры соединений и создавалась ссылка на файл с записью.

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

Для анализа качества передаваемого голоса от системы генерации нагрузки МТТ в сторону ЦОВ заказчика было необходимо обеспечить ответ на вызов и проигрывание приветствия. Для этого центр обработки вызовов клиента выполнял следующие действия:

  1. Обеспечивал прием поступающих вызовов по каналам связи на арендуемые телефонные номера.

  2. При поступлении вызова проигрывал в канал связи шаблонный файл с проговариваемым диктором текстом (в формате WAV, 8000Hz, моно).

  3. Производил запись транслируемого от МТТ в сторону ЦОВ голоса диктора (в формате WAV, 8000Hz, моно) при снятии трубки оператором ЦОВ.

  4. Фиксировал результаты вызова в CDR (Call Detail Records) с указанием информации, которой будет достаточно для однозначной идентификации вызова генерируемого со стороны МТТ и входящего в ЦОВ заказчика, а также ссылку на файл с записью.

  5. По результатам выполнения нагрузочных тестов предоставлял данные для анализа в систему генерации и сбора статистики МТТ.

В результате сбора информации аналитическая система МТТ вычислила параметры PDD, PESQ MOS и подготовила сводные отчеты. Они строились путем объединения результатов в пулы набора значений на основе времени установления соединения между узлами сети МТТ и ЦОВ заказчика. Из наборов значений пулов и производился расчет сводных показателей качества обслуживания.

Справка: PDD (Post Dialing Delay) — время между началом звонка и моментом, когда телефон начинает звонить на вызываемой стороне. Другими словами PDD рассчитывается, как время между INVITE сообщением, отправленным вызывающей стороной, и RINGING сообщением от принимающей стороны.

PESQ (Perceptual Evaluation of Speech Quality) — семейство стандартов для оценки качества голоса из конца в конец. Стандартизированы рекомендациями ITU-T P.862. На текущий момент является стандартом де-факто оценки качества голоса. Используется большинством производителей телекоммуникационного оборудования и разработчиков программного обеспечения для совершения звонков.

Тестирование CRM


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

Для проведения тестирования использовался apache JMeter. CRM-систему загрузили 500 одновременными задачами по оформлению заказов.

Совет по настройке: JMeter «из коробки» использует всего 512 мегабайт, что для нагрузки даже в 100 потоков мало. Это легко исправляется настройкой JAVA-машины. В запускаемом файле Jmeter нужно увеличить heap size: set HEAP=-Xms512m -Xmx4096m

Входные данные брались из CSV файла. Мы реализовывали несколько сценариев заказа с разным количеством товаров и способами оформления. Для этого строки с данными содержали разные параметры. Каждая строка – это один оператор системы заказчика и товары заказа, которые оператор должен был оформлять.

test_crm_user_376;1a6cddfc0c077fe64fbe94983b2e5bde;111;номер;call;127322;103413001;1;null;1;116131;1;НТТестфамилия;НТТестимя;НТТестотчество;false

test_crm_user_126;8ae9ssc0d73b5305b58714c0c33a3c27;111;номер;call;127322;111634;1;110951005;1;111117;1;НТТестфамилия;НТТестимя;НТТестотчество;true




Примеры запросов


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

Приведем некоторые примеры формирования запросов:

login — авторизация. Здесь берутся данные из CSV и подставляются в запрос:
/crm/index.php?login=${login}&pass=${pass}&ANI=${ani}&SLNUM=${slnum}&module=${module}



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

/crm/index.php?SLNUM=${slnum}&ANI=111436609800&module=call
Парсинг параметров
.*ContactID'\s*,\s*'(\d+)'\);.*
.+CallBegin',\s*'(\d+)'.*
.+'operator_id'.+'(\d+)\|.+




search_by_whole_name — функция поиска товара. Здесь использовались данные, полученные из парсинга страницы:

/crm/modules/ajax/get_goods.php?&CONTACT_ID=${contact_id_g1}&IBLOCK_ID=7&BAN_SYM=%2C%3B&REP_SYM=&MODE=SEARCH&p=0&search=${commodity1}&type=&OFFER=1&ORDER_PROP_13=TV&ORDER_PROP_32=${slnum}&coupon=&user_id=0&LID=s1&order_id=&bonus_rubls=&bonus_rubls_status=active&_=1470218107193



С помощью if ветвился сценарий выполнения теста:

If commodity1 and associated commodity (orderline/upsell/list-top)
${__jexl(${commodity1} != null and ${commodity2} == null and ${commodity3} != null)}

В зависимости от входных данных выполнялись те или иные действия.



Отчеты


В результате тестирования JMeter формировал отчёты по каждому обращению к CRM.

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

Мы нашли простое решение этой проблемы: в jemeter.properties была добавлена переменая thread_id, что дало возможность фильтровать запросы по конкретному оператору.

sample_variables=splitting,order_id_g1,thread_id

Пример отчёта:



Итого


По телефонии изначально был запланирован сквозной тест, вместе с операторами call-центра. Однако, организационно это оказалось очень сложно сделать, так что одновременно проводились два параллельных теста в условиях, максимально приближенных к реальным. В процессе тестирования измерялось время до ответа оборудования колл-центра. Этот параметр имеет большое значение при проведении нагрузочного тестирования. При  большой нагрузке сильно возрастают задержки обработки вызовов на оборудовании колл-центра. Позвонивший клиент может даже не дождаться «гудков». Фиксировались и анализировались также коды ответов. Это мог быть факт ответа оборудования колл-центра, отбой со стороны колл-центра или коды ошибок. По анализу времени ответа и кодов приняли решение об усилении телефонных каналов и модернизации оборудования. Тест по CRM показал, что программное обеспечение выдержало нагрузку, но, конечно, программисты внесли некоторые изменения в настройки для увеличения стабильности.
Tags:
Hubs:
+3
Comments 0
Comments Leave a comment

Articles