Не так давно один из крупнейших интернет-магазинов проводил рекламную акцию в честь дня рождения компании. Для приёма заказов у них предусмотрены два виртуальных многоканальных телефонных номера 8-800 от разных операторов связи, а для их обработки написана своя система CRM и организована работа call-центра на аутсорсе. Изначальный прогноз заходов покупателей на сайт вызвал сомнения в том, что все системы справятся. Для того чтобы не потерять лиды, было решено протестировать телефонные каналы и CRM-систему.
IP-телефония при достижении определенной нагрузки начинает значительно искажать голос. А если упадёт CRM, то люди просто не получат свои заказы. Оценив риск провала акции, заказчик обратился в нашу компанию.
Нашей задачей было создать распределенную телефонную нагрузку по России: 70% из Москвы, остальное из регионов. Во входящий поток нужно было подать голосовое сообщение, а на стороне call-центра было необходимо, чтобы сотрудник поднял трубку. В результате получилось два потока (исходящий и входящий), которые можно было проанализировать на качество голоса и сравнить с эталонными записями.
Так как клиенты интернет-магазина находятся в разных городах РФ, для имитации нагрузки были выделены номера для тестирования. В качестве провайдеров услуг связи для ЦОВ использовались два различных телекоммуникационных оператора. Нагрузка генерировалась с нарастанием до 5 CPS (Call Per Seconds) и с продолжительностью одного генерируемого вызова не менее 180 сек (3 минуты). Ограничение одновременного количества вызовов — до 350.
Для выявления ошибок в телекоммуникационном оборудовании и его тонкой настройки используется наша собственная МТТ Система генерации и сбора статистики. Это комплекс программно-аппаратных средств и методик генерации высоконагруженных тестов посредством SIP-телефонии и последующего анализа результатов.
Тестирование проводилось в три этапа:
При помощи системы генерации нагрузки и сбора статистики создавался нарастающий поток вызовов на номер ЦОВ нашего клиента в соответствии с этапом проведения испытания. Это работало так:
Для анализа качества передаваемого голоса от системы генерации нагрузки МТТ в сторону ЦОВ заказчика было необходимо обеспечить ответ на вызов и проигрывание приветствия. Для этого центр обработки вызовов клиента выполнял следующие действия:
В результате сбора информации аналитическая система МТТ вычислила параметры PDD, PESQ MOS и подготовила сводные отчеты. Они строились путем объединения результатов в пулы набора значений на основе времени установления соединения между узлами сети МТТ и ЦОВ заказчика. Из наборов значений пулов и производился расчет сводных показателей качества обслуживания.
Справка: PDD (Post Dialing Delay) — время между началом звонка и моментом, когда телефон начинает звонить на вызываемой стороне. Другими словами PDD рассчитывается, как время между INVITE сообщением, отправленным вызывающей стороной, и RINGING сообщением от принимающей стороны.
PESQ (Perceptual Evaluation of Speech Quality) — семейство стандартов для оценки качества голоса из конца в конец. Стандартизированы рекомендациями ITU-T P.862. На текущий момент является стандартом де-факто оценки качества голоса. Используется большинством производителей телекоммуникационного оборудования и разработчиков программного обеспечения для совершения звонков.
Для испытания CRM специалистами был написан сценарий условий имитации высокой нагрузки. В его рамках были описаны типовые действия оператора call-центра: поднималась карточка клиента, выбирался товар, заполнялись данные клиента и т.д. Если груз крупногабаритный, то доставка разбивалась на несколько частей.
Для проведения тестирования использовался apache JMeter. CRM-систему загрузили 500 одновременными задачами по оформлению заказов.
Совет по настройке: JMeter «из коробки» использует всего 512 мегабайт, что для нагрузки даже в 100 потоков мало. Это легко исправляется настройкой JAVA-машины. В запускаемом файле Jmeter нужно увеличить heap size: set HEAP=-Xms512m -Xmx4096m
Входные данные брались из CSV файла. Мы реализовывали несколько сценариев заказа с разным количеством товаров и способами оформления. Для этого строки с данными содержали разные параметры. Каждая строка – это один оператор системы заказчика и товары заказа, которые оператор должен был оформлять.
Каждый элемент в JMeter файле — это запрос с сайта интернет-магазина«ShoppingLive.Telecom». На основании пользовательского сценария мы проанализировали фактически направляемые запросы и из них сформировали набор. Это набор и составлял возможные варианты поведения оператора колл-центра, нагрузка на которого имитировалась.
Приведем некоторые примеры формирования запросов:
index — загрузка страницы. Запрос страницы после авторизации. Здесь мы получали данные, необходимые для дальнейшей работы скрипта:
search_by_whole_name — функция поиска товара. Здесь использовались данные, полученные из парсинга страницы:
С помощью if ветвился сценарий выполнения теста:
В зависимости от входных данных выполнялись те или иные действия.
В результате тестирования JMeter формировал отчёты по каждому обращению к CRM.
В процессе разработки теста мы заметили что у разных операторов повторялось значение потока thread name, что делало невозможным идентификацию конкретного заказа. Это происходило из-за того что thread name формировался из общего числа одновременных потоков указанных в группе thread group.
Мы нашли простое решение этой проблемы: в jemeter.properties была добавлена переменая thread_id, что дало возможность фильтровать запросы по конкретному оператору.
Пример отчёта:
По телефонии изначально был запланирован сквозной тест, вместе с операторами call-центра. Однако, организационно это оказалось очень сложно сделать, так что одновременно проводились два параллельных теста в условиях, максимально приближенных к реальным. В процессе тестирования измерялось время до ответа оборудования колл-центра. Этот параметр имеет большое значение при проведении нагрузочного тестирования. При большой нагрузке сильно возрастают задержки обработки вызовов на оборудовании колл-центра. Позвонивший клиент может даже не дождаться «гудков». Фиксировались и анализировались также коды ответов. Это мог быть факт ответа оборудования колл-центра, отбой со стороны колл-центра или коды ошибок. По анализу времени ответа и кодов приняли решение об усилении телефонных каналов и модернизации оборудования. Тест по CRM показал, что программное обеспечение выдержало нагрузку, но, конечно, программисты внесли некоторые изменения в настройки для увеличения стабильности.
IP-телефония при достижении определенной нагрузки начинает значительно искажать голос. А если упадёт CRM, то люди просто не получат свои заказы. Оценив риск провала акции, заказчик обратился в нашу компанию.
Тестирование телефонии
Нашей задачей было создать распределенную телефонную нагрузку по России: 70% из Москвы, остальное из регионов. Во входящий поток нужно было подать голосовое сообщение, а на стороне call-центра было необходимо, чтобы сотрудник поднял трубку. В результате получилось два потока (исходящий и входящий), которые можно было проанализировать на качество голоса и сравнить с эталонными записями.
Так как клиенты интернет-магазина находятся в разных городах РФ, для имитации нагрузки были выделены номера для тестирования. В качестве провайдеров услуг связи для ЦОВ использовались два различных телекоммуникационных оператора. Нагрузка генерировалась с нарастанием до 5 CPS (Call Per Seconds) и с продолжительностью одного генерируемого вызова не менее 180 сек (3 минуты). Ограничение одновременного количества вызовов — до 350.
Для выявления ошибок в телекоммуникационном оборудовании и его тонкой настройки используется наша собственная МТТ Система генерации и сбора статистики. Это комплекс программно-аппаратных средств и методик генерации высоконагруженных тестов посредством SIP-телефонии и последующего анализа результатов.
Тестирование проводилось в три этапа:
- На первых двух тестировались каналы операторов.
- На третьем этапе тестировалась логика работы IVR центра обработки вызовов (ЦОВ) путем генерации нагрузки по каналам одного из операторов.
Методика тестирования
При помощи системы генерации нагрузки и сбора статистики создавался нарастающий поток вызовов на номер ЦОВ нашего клиента в соответствии с этапом проведения испытания. Это работало так:
- Система поочередно подставляла в качестве источника вызова номер из списка номеров АОН.
- Затем формировался вызов через узел связи, соответствующий подставляемому АОНу.
- Производилась запись транслируемого со стороны ЦОВ заказчика приветственного шаблонного файла с проговариваемым диктором текстом (в формате WAV, 8000Hz, моно) в течение 20 секунд после получения информации о соединении.
- После этого через паузу в 1 секунду в направлении ЦОВ заказчика проигрывался шаблонный файл с проговариваемым диктором текстом (в формате WAV, 8000Hz, моно).
- По результату вызова CDR (Call Detail Records) фиксировались качественные параметры соединений и создавалась ссылка на файл с записью.
- По результатам выполнения нагрузочных тестов производился анализ статистической информации
Для анализа качества передаваемого голоса от системы генерации нагрузки МТТ в сторону ЦОВ заказчика было необходимо обеспечить ответ на вызов и проигрывание приветствия. Для этого центр обработки вызовов клиента выполнял следующие действия:
- Обеспечивал прием поступающих вызовов по каналам связи на арендуемые телефонные номера.
- При поступлении вызова проигрывал в канал связи шаблонный файл с проговариваемым диктором текстом (в формате WAV, 8000Hz, моно).
- Производил запись транслируемого от МТТ в сторону ЦОВ голоса диктора (в формате WAV, 8000Hz, моно) при снятии трубки оператором ЦОВ.
- Фиксировал результаты вызова в CDR (Call Detail Records) с указанием информации, которой будет достаточно для однозначной идентификации вызова генерируемого со стороны МТТ и входящего в ЦОВ заказчика, а также ссылку на файл с записью.
- По результатам выполнения нагрузочных тестов предоставлял данные для анализа в систему генерации и сбора статистики МТТ.
В результате сбора информации аналитическая система МТТ вычислила параметры 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;88007077707;call;127322;103413001;1;null;1;116131;1;НТТестфамилия;НТТестимя;НТТестотчество;false
test_crm_user_126;8ae9ssc0d73b5305b58714c0c33a3c27;111;88007077707;call;127322;111634;1;110951005;1;111117;1;НТТестфамилия;НТТестимя;НТТестотчество;trueПримеры запросов
Каждый элемент в JMeter файле — это запрос с сайта интернет-магазина«ShoppingLive.Telecom». На основании пользовательского сценария мы проанализировали фактически направляемые запросы и из них сформировали набор. Это набор и составлял возможные варианты поведения оператора колл-центра, нагрузка на которого имитировалась.
Приведем некоторые примеры формирования запросов:
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 показал, что программное обеспечение выдержало нагрузку, но, конечно, программисты внесли некоторые изменения в настройки для увеличения стабильности.
Поделиться с друзьями