Как да тестваме комуникационните канали на онлайн магазин преди продажби

Тъй като клиентите на онлайн магазина се намират в различни градове на Руската федерация, бяха определени номера за тестване, за да се симулира натоварването. Два различни телекомуникационни оператора бяха използвани като доставчици на комуникационни услуги за кол центровете. Зареждането беше генерирано с увеличение до 5 CPS (Call Per Seconds) и с продължителност на едно генерирано повикване не по-малко от 180 секунди (3 минути). Ограничете броя на едновременните разговори - до 350.

Тестването беше проведено на три етапа:

На третия етап беше тествана логиката на IVR call center (CSC) чрез генериране на товар по каналите на един от операторите.

Техника на тестване

С помощта на системата за генериране на натоварване и събиране на статистика беше създаден нарастващ поток от обаждания към номера на кол центъра на нашия клиент в съответствие с етапа на теста. Работеше по следния начин:

След това се формира повикване през комуникационния център, съответстващ на заместения идентификатор на повикващия.

Файл на шаблон за поздрав с изговарян текст (във формат WAV, 8000Hz, моно), излъчен от централния офис на клиента, е записан в рамките на 20 секунди след получаване на информация за връзката.

След това, след пауза от 1 секунда в посока на кол центъра на клиента, се възпроизвежда шаблонния файл с текста, изговарян от говорителя (във формат WAV, 8000Hz, моно).

Въз основа на резултатите от тестовете за натоварване беше анализирана статистическа информация

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

Когато пристигна повикване, пуснах файл с шаблон с изговорения текст (във формат WAV, 8000Hz, моно) в комуникационния канал.

Произведе запис на гласовото излъчване на диктора от MTT към кол центъра (във формат WAV, 8000Hz, моно), когато операторът на кол центъра взе приемника.

Записа резултатите от разговора в CDR (Call Detail Records) с посочване на информация, която ще бъде достатъчна, за да идентифицира еднозначно обаждането, генерирано от MTT и клиента, влизащ в кол центъра, както и връзка към файла със записа.

Въз основа на резултатите от тестовете за натоварване той предостави данни за анализ на системата за генериране и събиране на статистически данни за MTT.

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

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

CRM тестване

За да тестват CRM, специалистите написаха сценарий на условия за симулация с голямо натоварване. В неговата рамка бяха описани типични действия на оператор на кол-център: беше издигната клиентска карта, избран продукт, попълнени клиентски данни и т.н. Ако товарът е извънгабаритен, тогава доставката е разделена на няколко части.

За тестване е използван Apache JMeter. CRM система, заредена с 500 едновременни задачи за плащане.

Съвет за настройка: JMeter използва само 512 MB извън кутията, което не е достатъчно за натоварване дори от 100 нишки. Това може лесно да бъде поправено чрез настройване на JAVA машината. Във файла за изпълнение на Jmeter трябва да увеличите размера на купчината: set HEAP = -Xms512m -Xmx4096m

Входните данни са взети от CSV файл. Приложихме няколко сценария за поръчка с различно количество стоки и методи на регистрация. За това редовете за данни съдържаха различни параметри. Всеки ред е един оператор на системата на клиента и елементите на поръчките, които операторът е трябвало да издаде.

Поискайте примери

Всеки елемент във файла JMeter е заявка от сайта на онлайн магазина "ShoppingLive.Telecom". Въз основа на потребителския сценарий анализирахме реално изпратените заявки и образувахме набор от тях. Това зададе и направи възможни опции за поведението на оператора на кол центъра, чието натоварване беше симулирано.

Ето няколко примера за формиране на заявки:

search_by_whole_name - функция за търсене на продукт. Тук използвахме данните, получени от анализирането на страницата:

Скриптът за изпълнение на теста беше разклонен, като се използва, ако:

Ако стока1 и свързана с нея стока (ред за поръчка/продажби/списък отгоре)
$! = null и $ == null и $! = null)>

В зависимост от входните данни са извършени определени действия.

В резултат на тестването JMeter генерира отчети за всяко обаждане до CRM.

По време на разработването на теста забелязахме, че различните оператори имат една и съща стойност на името на нишката, което прави невъзможно идентифицирането на конкретна поръчка. Това се дължи на факта, че името на нишката се формира от общия брой едновременни нишки, посочени в групата нишки.

Намерихме просто решение на този проблем: променлива thread_id беше добавена към jemeter.properties, което направи възможно филтрирането на заявки от конкретен оператор.

Можете да помогнете и да прехвърлите някои средства за разработването на сайта