Як протестувати канали зв’язку інтернет-магазину перед розпродажем

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

канали

Тестування проводилося у три етапи:

    На перших двох тестували канали операторів.

  • На третьому етапі тестувалася логіка роботи IVR центру обробки викликів (ЦОВ) шляхом генерації навантаження каналами одного з операторів.

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

    За допомогою системи генерації навантаження та збору статистики створювався наростаючий потік викликів на номер ЦОВ нашого клієнта відповідно до етапу проведення випробування. Це працювало так:

      Система по черзі підставляла як джерело виклику номер зі списку номерів АВН.

    Потім формувався виклик через вузол зв'язку, відповідний підставою АОНу.

    Здійснювався запис транслюваного з боку ЦОВ замовника вітального шаблонного файлу з текстом, що промовляється диктором (у форматі WAV, 8000Hz, моно) протягом 20 секунд після отримання інформації про з'єднання.

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

  • За результатами виконання тестів навантаження проводився аналіз статистичної інформації
    • Для аналізу якості голосу, що передається від системи генерації навантаження МТТ у бік ЦОВ замовника було необхідно забезпечити відповідьна виклик та відтворення привітання. Для цього центр обробки дзвінків клієнта виконував такі дії:

    При надходженні виклику програвав у канал зв'язку шаблонний файл з текстом, що промовляється диктором (у форматі WAV, 8000Hz, моно).

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

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

  • За результатами виконання тестів навантаження надавав дані для аналізу в систему генерації та збору статистики МТТ.
    • В результаті збору інформації аналітична система МТТ обчислила параметри PDD, PESQ MOS та підготувала зведені звіти. Вони будувалися шляхом об'єднання результатів у пули набору значень з урахуванням часу встановлення з'єднання між вузлами мережі МТТ і ЦОВ замовника. З наборів значень пулів і проводився розрахунок зведених показників якості обслуговування.

    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 файлу. Ми реалізовували кілька сценаріїв замовлення з різною кількістю товарів та способами оформлення. Для цього рядки з даними містили різні параметри. Кожен рядок – це один оператор системи замовника та товари замовлення, які оператор мав оформляти.

    язку

    Приклади запитів

    Кожен елемент у JMeter файлі – це запит із сайту інтернет-магазину «ShoppingLive.Telecom». На основі користувальницького сценарію ми проаналізували фактично надіслані запити і з них сформували набір. Це набір і становив можливі варіанти поведінки оператора кол-центру, навантаження якого імітувалося.

    Наведемо деякі приклади формування запитів:

    канали

    протестувати

    search_by_whole_name - функція пошуку товару. Тут використовувалися дані, отримані з парсингу сторінки:

    канали

    За допомогою if розгалужувався сценарій виконання тесту:

    Якщо функція commodity1 і поєднана функція (orderline/upsell/list-top) $ != null and $ == null and $ != null)> Залежно від вхідних даних виконувались ті чи інші дії.

    протестувати

    В результаті тестування JMeter формував звіти щодо кожного звернення до CRM.

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

    Ми знайшли просте вирішення цієї проблеми: до jemeter.properties було додано зміну thread_id, що дало можливість фільтрувати запити по конкретному оператору.

    канали

    Ви можете допомогти і перевести небагато коштів на розвиток сайту