Cisco ICM ソフトウェアアップグレードマイグレーションガイド ICM 4.6.2 からICM 5.0(0)、および ICM 4.6.2 またはICM 5.0(0) からICM/IP Contact Center Enterprise Edition リリース
システム整合性テスト
システム整合性テスト
発行日;2012/02/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

システム整合性テスト

システム整合性テスト

この付録のサンプル テスト ケースは、アップグレード マイグレーションの各手順の実行前、実行中、および実行後に、ICM の基本機能と耐障害性を検証することを目的としています。

 

表 A-1 システム整合性テスト 1:ICM プロセスのエラーの確認

テスト番号:
1
ICM プロセスの検証
ICM プロセスにエラーがないことを確認する。
すべての ICM サービスを開始します。
1. 主な ICM プロセスのウィンドウを目視で確認します。
テスト タイトル:
テストの目的:
テストの準備:
手順:
期待される結果:

1. Call Router

Router:稼動中になり、ピアと同期される(シンプレックスで動作している場合は除く)。

Ccagent:設定済みのすべてのペリフェラル ゲートウェイに接続される。

Rtsvr:AW に対するフィードが有効になる。

NIC がオンラインになる(NIC が設定されている場合)。

合格:__ 不合格: __

2. ロガー

Logger:それぞれのデータベースに接続され、ピアと同期される(シンプレックスで動作している場合は除く)。

MDS が稼動中になる。

HDS の場合 - レプリケーション:AW に接続される。

合格:__ 不合格: __

3. Admin Workstation

Updateaw:“waiting for new work” と表示される。

HDS の場合 - レプリケーション:レプリケーションおよびリカバリのためのクライアント接続が初期化される。

合格:__ 不合格: __

4. ペリフェラル ゲートウェイ

Mdsproc:稼動中になる。

Pgagent:稼動中になり、いずれかのサイドのセントラル コントローラに対してアクティブになる。

PIM:アクティブになる。

合格:__ 不合格: __

5. CTI Server

Cg[#]ctisvr:設定されたポート番号を使用してアクティブになる。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-2 システム整合性テスト 2:RTTEST

テスト番号:
2
テスト タイトル:
RTTEST
テストの目的:
すべての ICM セントラル サイト プロセスの現在の状態を検証し、すべてのデバイス(PG およびペリフェラル)がコールルータによって正しく認識されていることを確認する。
テストの準備:
すべての ICM サービスを完全デュプレックス モードで開始します(シンプレックスで動作している場合は除く)。各コールルータで RTTEST を実行します。
手順:
1. Rttest /system <コールルータ ホスト名> /cust <インスタンス名> /node routera を実行します。
2. RTTEST: status が表示されます。
3. 結果のスクリーン ショットを撮り、ステージング レポートに追加します。
4. 各コールルータでテストが完了したら、コマンド プロンプトを閉じます。
期待される結果:

1. 設定済みのすべてのプロセスがコールルータによって正常に認識される。

合格:__ 不合格: __

2. 設定済みのすべての物理コントローラがコールルータと通信している(CFO)。

合格:__ 不合格: __

3. 設定済みで稼動中のすべてのペリフェラルがコールルータによって正しく認識され、オンラインになる。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-3 システム整合性テスト 3:RTTEST debug/route

テスト番号:
3
テスト タイトル:
RTTEST debug/route
テストの目的:
すべてのコールが ICM ルータに送信され、ラベルが NIC に返されることを確認する。
テストの準備:
すべての ICM サービスを完全デュプレックス モードで開始します(シンプレックスで動作している場合は除く)。各コールルータで RTTEST を実行します。
手順:

1. Rttest /system <コールルータ ホスト名> /cust <インスタンス名> /node routera を実行します。

2. RTTEST: status が表示されます。

3. debug/route と入力します。

4. ルータ プロセス ログをダンプします。

5. ログを参照して、次の例のようなテキストがあるかどうかを確認します。

15:21:39 ra-rtr Trace:Route:dn=8004284322 ani=4127475709 ced=1 label=1684734757
15:21:39 ra-rtr Trace:Route:CRSDateOfCall=145679 CRSCallKey=105821
15:22:14 ra-rtr Trace:Route:dn=8886387653 ani=4403568854 ced= label=1620000006
15:22:14 ra-rtr Trace:Route:CRSDateOfCall=145679 CRSCallKey=114359
期待される結果:

1. ルータ ログに上のようなデータ出力が表示されている。

合格:__ 不合格: __

2. コールが監視され、正しいターゲットにルーティングされている。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-4 システム整合性テスト 5:SQL エラーログの確認

テスト番号:
5
テスト タイトル:
SQL エラーログの確認
テストの目的:
アップグレード後のロガーで SQL エラーログを参照して、SQL が正常に機能していることと、エラーがないことを確認する。
テストの準備:
アップグレード後のロガーですべての ICM サービスを開始し、SQL エラーログをダンプします。
手順:

1. c:\mssql7\log に移動します。

2. type errorlog と入力します。

3. SQL エラーログを確認します。

期待される結果:

1. エラーログに “Recovery Completed” と表示されている。

合格:__ 不合格: __

2. エラーログに正しい SQL バージョンが表示されている。

合格:__ 不合格: __

3. エラーがない。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-5 システム整合性テスト 6:OPCTEST

テスト番号:
6
テスト タイトル:
OPCTEST
テストの目的:
論理 PG の各ペアで pgagent プロセスおよび PIM プロセスとの接続を確認する。
テストの準備:
すべての ICM サービスを完全デュプレックス モードで開始します(シンプレックスで動作している場合は除く)。
手順:

1. opctest /cust <インスタンス名> /node <論理 PG ノード番号/サイド> を実行します。

2. opctest: status が表示されます。

3. 結果のスクリーン ショットを撮り、ステージング レポートに追加します。

4. 各 PG でテストを完了したら、コマンド プロンプトを閉じます。

期待される結果:

1. アクティブな PGAgent が両サイドのセントラル コントローラに接続されている(シンプレックスで動作している場合は除く)。

合格:__ 不合格: __

2. 関連する PIM がいずれかの PG ペアでアクティブになっている。

合格:__ 不合格: __

3. CTI Server がいずれかの PG ペアでアクティブになっている。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-6 システム整合性テスト 7:セントラル コントローラの耐障害性

テスト番号:
7
テスト タイトル:
セントラル コントローラの耐障害性
テストの目的:
セントラル コントローラがシンプレックス モードで機能することを確認する。
テストの準備:
すべての ICM サービスを完全デュプレックス モードで開始します。
手順:

1. コールルータ A でルータ サービスを停止します。

2. コールルータ B で、Router プロセスを開き、ルータ A のプロセスがダウンしていることを示すメッセージが表示されていることを確認します。

3. コールルータ A でルータ サービスを開始します。

4. ルータ B で、コールルータ A の Router プロセスと Logger プロセスが問題なく機能していることを示すメッセージが表示されているかどうか確認します。

5. 手順 1 ~ 4 を繰り返して、ルータ B を停止し、ルータ A でシンプレックス モードを検証します。

期待される結果:

1. コールルータ A でルータ サービスを停止すると、サイド A のセントラル サイトがダウンしていることを示すメッセージがコールルータ B で表示される。

合格:__ 不合格: __

2. コールルータ A でルータ サービスを開始すると、コールルータ A に同期されたことを示すメッセージがコールルータ B で表示される。

合格:__ 不合格: __

3. コールルータ A でルータ サービスを開始すると、サイド A の Router プロセスと Logger プロセスが問題なく機能していることを示すメッセージがコールルータ B で表示される。

合格:__ 不合格: __

4. コールルータ B でルータ サービスを停止すると、サイド B のセントラル サイトがダウンしていることを示すメッセージがコールルータ A で表示される。

合格:__ 不合格: __

5. コールルータ B でルータ サービスを開始すると、コールルータ B に同期されたことを示すメッセージがコールルータ A で表示される。

合格:__ 不合格: __

6. コールルータ B でルータ サービスを開始すると、サイド B の Router プロセスと Logger プロセスが問題なく機能していることを示すメッセージがコールルータ A で表示される。

合格:__ 不合格: __

7. ルータがシンプレックス モードで動作しているときに、コール処理が意図どおりに機能する。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-7 システム整合性テスト 8:PG の耐障害性

テスト番号:
8
テスト タイトル:
PG の耐障害性(論理 PG のペアごとにテスト ケースを作成)
テストの目的:
PG がシンプレックス モードのセントラル コントローラと通信でき、PIM がアクティブなままであることを確認する。
テストの準備:
すべての PG サービスをデュプレックス モードで開始します。
手順:

1. PGA がアクティブであることを確認します。

2. PGB がアイドルであることを確認します。

3. PGA でサービスを停止します。

4. PGB の状態がアイドルからアクティブに変化することを確認します。

5. PGA でサービスを開始します。

6. PGA の状態がアイドルであることを確認します。

7. 手順 1 ~ 6 を繰り返して、PGB を停止し、PG の機能が PGA にフェールオーバーされることを検証します。

期待される結果:

1. B サイドの PG でセントラル コントローラとの接続が維持され、PIM がアクティブになる。

合格:__ 不合格: __

2. A サイドの PG を再起動すると、A サイドの MDS/OPC プロセスによってアイドルへの状態変化が記録され、B サイドの PG はアクティブの状態を維持する。

合格:__ 不合格: __

3. A サイドの PG でセントラル コントローラとの接続が維持され、PIM がアクティブになる。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-8 システム整合性テスト 9:AW の設定とスクリプティング ツール

テスト番号:
9
テスト タイトル:
AW ツール
テストの目的:
ICM の基本設定とスクリプティング機能を検証する。
テストの準備:
すべてのルータ サービス、ロガー サービス、AW サービスを開始します。
手順:

1. ICM を設定します。Call Manager のルーティング クライアントとして、ダイヤル番号 5555、ラベル 1111、コール タイプ stagingtest を追加します。

2. DN 5555 からラベル 1111 を返す stagingtest という名前のルーティング スクリプトを作成します。コール タイプのスケジュールを終日/毎日に設定し、stagingtest スクリプトを stagingtest コール タイプに関連付けます。

3. stagingtest スクリプトをモニタ モードで開きます。

4. DN 5555 の Call Manager ルーティング クライアントに対してコール トレーサを実行します。

期待される結果:

1. ICM ツールから設定とスクリプトを作成して保存する際に、エラー メッセージが表示されない。

合格:__ 不合格: __

2. 期待どおりに、コール トレーサからラベル 1111 が返される。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-9 システム整合性テスト 10:Webview

テスト番号:
10
テスト タイトル:
Webview
テストの目的:
認証された ICM ユーザが Webview レポーティング ツールを開いてナビゲートできることを確認する。
テストの準備:
すべてのルータ サービス、ロガー サービス、AW サービスを開始します。
手順:

1. 1. [Configure ICM] > [Security] > [User List] を使用して、Webview ユーザを作成します。

ドメイン名 - 例:CUS

ユーザ名 - 例:test1

パスワード - 例:test1

[can create other user accounts] チェックボックスをオンにします。

2. Webview を開いてログインします。

ブラウザを開き、URL として http: //<AW ホスト名>/<ICM インスタンスの名前> を入力します。

ユーザ名として、<AW ドメイン名>/<ICM ユーザ リストで設定したユーザ名> を入力します。


) 注:Webview のユーザ名では、大文字と小文字が区別されます。


パスワードとして、<ユーザ名に関連付けられたパスワード> を入力します。

3. Webview レポートを選択します。

4. 左側のパネルから、さまざまなレポートを選択します。

期待される結果:

1. ICM で新しいユーザが正常に作成される。

合格:__ 不合格: __

2. 新しいユーザが Webview にログインできる。

合格:__ 不合格: __

3. 新しいユーザがレポート カテゴリを開いて、すべてのレポート テンプレートにアクセスできる。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-10 システム整合性テスト 11:Internet Script Editor

テスト番号:
11
テスト タイトル:
Internet Script Editor
テストの目的:
認証された ICM ユーザが Webview レポーティング ツールを開いてナビゲートできることを確認する。
テストの準備:
すべてのルータ サービス、ロガー サービス、AW サービスを開始します。
手順:

1. [Configure ICM] > [Security] > [User List] を使用して、ISE ユーザを作成します。

ドメイン名 - 例:CUS

ユーザ名 - 例:test2

パスワード - 例:test2

[can create other user accounts] チェックボックスをオンにします。

2. デスクトップに ISE クライアントをインストールします。

URL:<AW の IP アドレス>\install\iscripteditor.htm を入力します。

ISE のダウンロード リンクをクリックして、デスクトップに保存します。ダウンロードが完了したら、ブラウザを閉じます。

デスクトップ上の iscripteditor.exe を開いて、ISE のインストールを完了します(デスクトップにショートカットが作成されます)。

3. 3. ISE との接続を確立します。

ISE クライアントを開きます。

[接続] ウィンドウで、アドレス、ポート(デフォルト値は 80)、インスタンス名を入力し、[OK] をクリックします。

Admin Workstation のユーザ名、パスワード、ドメイン名を入力します。

4. stagingtest と名付けたスクリプトを編集モードで開き、DN ノードの場所を変更して、スクリプトを保存します。

期待される結果:

1. ISE クライアントがデスクトップへ正常にダウンロードされる。

合格:__ 不合格: __

2. ISE クライアントから AW の Script Editor にアクセスできる。

合格:__ 不合格: __

3. ユーザがスクリプトを開いて、編集し、保存できる。

合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-11 システム整合性テスト 12:Setup.log ファイルの確認

テスト番号:
12
テスト タイトル:
Setup.log ファイルの確認
テストの目的:
setup.log ファイルを参照して、アップグレード中のエラーを確認する。
テストの準備:
このファイルは、すべての ICM ノードの c:\temp ディレクトリに作成されます。
手順:

1. コマンド ラインで c:\temp\setup.log に移動します。

2. “findstr -I error setup.log” と入力します。

3. “findstr -I fail setup.log” と入力します。

期待される結果:
このログ ファイルにエラーや障害が記録されていない。
合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考:
 

 

表 A-12 システム整合性テスト 13:.log ファイルの確認

テスト番号:
13
テスト タイトル:
.log ファイルの確認
テストの目的:
icmsetup.log と apply.log file を参照して、ホットフィックスのインストール中のエラーを確認する。
テストの準備:
このファイルは、すべての ICM ノードの c:\icr ディレクトリに作成されます。
手順:

1. コマンド ラインで c:\icr\apply.log と c:\temp\icmsetup.log に移動します。

2. “findstr -I error install.log” と入力します。

3. “findstr -I fail install.log” と入力します。

期待される結果:
このログ ファイルにエラーや障害が記録されていない。
合格:__ 不合格: __
合格:(イニシャル)
 
不合格:(イニシャル)
 
不合格の理由:
 
備考: