Clever Geek Handbook

販売前にオンラインストアの通信チャネルをテストする方法

少し前まで、最大のオンラインストアの1つが会社の誕生日を記念して広告キャンペーンを実施しました。 注文を受け取るために、異なる通信事業者から2つの仮想マルチチャネル電話番号8〜800があり、処理のために独自のCRMシステムを作成し、アウトソーシングされたコールセンターの作業を編成しました。 サイトへの顧客訪問の最初の予測は、すべてのシステムが対処するという疑問を提起しました。 リードを失わないために、電話チャネルとCRMシステムをテストすることにしました。





特定の負荷に達すると、IPテレフォニーは音声を大幅に歪ませ始めます。 そして、CRMが落ちた場合、人々は単に注文を受けられなくなります。 在庫不良のリスクを評価して、顧客は当社に頼りました。



テレフォニーテスト



私たちの仕事は、ロシアで分散電話負荷を作成することでした。70％はモスクワから、残りは地域からです。 着信ストリームに音声メッセージを送信する必要があり、コールセンターの側では、従業員が電話に出る必要がありました。 その結果、2つのストリーム（発信と着信）が得られ、音声品質を分析し、参照録音と比較することができました。



オンラインストアの顧客はロシア連邦のさまざまな都市にいるため、負荷をシミュレートするためにテスト用の番号が割り当てられました。 2つの異なる通信事業者が、コールセンターの通信サービスプロバイダーとして使用されました。 負荷は、最大5 CPS（1秒あたりの呼び出し）の増加で生成され、1つの生成された呼び出しの継続時間は少なくとも180秒（3分）でした。 同時呼び出しの数を350に制限します。







通信機器のエラーとその微調整を検出するために、 統計を生成および収集する独自のMTTシステムが使用されます。 これは、 SIPテレフォニーと結果のその後の分析によって負荷の高いテストを生成するためのソフトウェアとハ​​ードウェアのツールと方法のセットです。



テストは3段階で実施されました。





テスト方法



負荷生成および統計収集システムを使用して、テスト段階に応じて、クライアントのコールセンター番号への呼び出しフローが増加しました。 これは次のように機能しました。



  1. システムは、発信者ID番号のリストの番号を呼び出し元として交互に置き換えました。



  2. 次に、置換AONに対応する通信ノードを介してコールが形成されました。



  3. 顧客のコールセンターからブロードキャストされたウェルカムテンプレートファイルは、接続情報を受信して​​から20秒間、スピーカーが音声でテキスト（WAV形式、8000Hz、モノラル）で録音しました。



  4. その後、顧客のコールセンターの指示で1秒間停止した後、スピーカーで話されたテキスト（WAV形式、8000Hz、モノラル）でテンプレートファイルが再生されました。



  5. CDR（Call Detail Records）の呼び出し結果に基づいて、接続の定性的パラメーターが記録され、記録ファイルへのリンクが作成されました。



  6. 負荷テストの結果に従って、統計情報が分析されました



MTT負荷生成システムから顧客のコールセンターに向けて送信される音声の品質を分析するには、コールに応答してグリーティングを再生する必要がありました。 これを行うために、クライアントコールセンターは次のアクションを実行しました。



  1. リースされた電話番号への通信チャネルを介した着信コールの受信を保証しました。



  2. 通話が着信すると、スピーカーによって話されたテキスト（WAV形式、8000Hz、モノラル）でテンプレートファイルが通信チャネルに再生されました。



  3. DSCオペレーターがコールをピックアップしたときに、MTTからDAC（WAV形式、8000Hz、モノラル）に向かって放送されたスピーカーの音声を録音しました。



  4. コールの結果をCDR（コール詳細レコード）に記録しました。これは、MTTによって生成され、顧客のコールセンターに含まれるコールを一意に識別するのに十分な情報と、レコードを含むファイルへのリンクを示します。



  5. 負荷テストの結果に基づいて、MTT統計の生成および収集システムに分析用のデータを提供しました。



情報収集の結果、MTT分析システムはパラメーターPDD、PESQ MOSを計算し、要約レポートを作成しました。 これらは、MTTネットワークのノードとカスタマーコールセンター間の接続を確立する時間に基づいて、一連の値のプールで結果を組み合わせることによって構築されました。 プール値のセットから、サービス品質のサマリーインジケータの計算も実行されました。



ヘルプ：PDD（Post Dialing Delay）-通話の開始から、電話が着信側で鳴り始める瞬間までの時間。 つまり、PDDは、発呼側から送信されたINVITEメッセージと受信側からのRINGINGメッセージの間の時間として計算されます。



PESQ（音声品質の知覚評価）は、音声品質を端から端まで評価するための一連の標準です。 ITU-T P.862勧告により標準化されています。 現在、音声品質を評価するための事実上の標準です。 ほとんどの通信機器メーカーとソフトウェア開発者が電話をかけるために使用します。



CRMテスト



CRMをテストするために、専門家は高負荷シミュレーション条件のシナリオを作成しました。 そのフレームワーク内で、コールセンターのオペレーターの典型的な行動が説明されました。顧客のカードが提起され、商品が選択され、顧客データが入力されました。 貨物がかさばる場合、配達はいくつかの部分に分割されました。



テストには、Apache JMeterが使用されました。 CRMシステムには、500の同時チェックアウトタスクがロードされました。



チューニングのヒント：すぐに使用できるJMeterは512メガバイトしか使用しないため、100スレッドの負荷に対しても十分ではありません。 これは、JAVAマシンをセットアップすることで簡単に修正できます。 Jmeter実行可能ファイルで、ヒープサイズを増やす必要があります。setHEAP = -Xms512m -Xmx4096m



入力データはCSVファイルから取得されました。 異なる数の製品とクリアランス方法でいくつかの注文シナリオを実装しました。 このため、データ行には異なるパラメーターが含まれていました。 各行は、顧客のシステムの1つのオペレーターであり、オペレーターが発行しなければならない注文の商品です。



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ファイルの各要素は、オンラインストアのWebサイトからのリクエストです。 ユーザーのシナリオに基づいて、実際に送信されたリクエストを分析し、それらのセットを形成しました。 このセットは、コールセンターオペレーターの可能な動作を構成し、負荷がシミュレートされました。



クエリ生成の例を次に示します。



login — . CSV :

/crm/index.php?login=${login}&pass=${pass}&ANI=${ani}&SLNUM=${slnum}&module=${module}











インデックスページロード 。 承認後のリクエストページ。 ここで、スクリプトのさらなる作業に必要なデータを受け取りました。



/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 commodity1 and associated commodity (orderline/upsell/list-top)

${__jexl(${commodity1} != null and ${commodity2} == null and ${commodity3} != null)}







入力に応じて、特定のアクションが実行されました。







報告書



テストの結果、JMeterはCRMへの呼び出しごとにレポートを生成しました。



テスト開発プロセス中に、さまざまな演算子がスレッド名threadの値を繰り返しているため、特定の順序を特定できなかったことに気付きました。 これは、スレッドグループで指定された同時スレッドの合計数からスレッド名が形成されたためです。



この問題の簡単な解決策を見つけました。jemeter.propertiesにthread_id変数が追加され、特定のオペレーターによるリクエストのフィルタリングが可能になりました。



sample_variables=splitting,order_id_g1,thread_id







レポートの例：







合計



テレフォニーを通じて、コールセンターのオペレーターとともに、エンドツーエンドのテストが当初計画されました。 ただし、組織的には非常に困難であることが判明したため、実際のテストに可能な限り近い条件で2つの並行テストを同時に実行しました。 テスト中、コールセンターの機器の応答までの時間を測定しました。 このパラメータは、負荷テスト中に非常に重要です。 負荷が高い場合、コールセンター機器のコール処理遅延が大幅に増加します。 呼び出された顧客は、「ビープ音」を待つことさえできません。 応答コードも記録および分析されました。 これは、コールセンター機器の応答、コールセンター側からの電話の切断、またはエラーコードの可能性があります。 応答時間とコードを分析することで、電話チャネルを強化し、機器をアップグレードすることにしました。 CRMテストでは、ソフトウェアが負荷に耐えることが示されましたが、もちろん、プログラマーは安定性を高めるために設定にいくつかの変更を加えました。


More articles:


All Articles