【MyComm公司呼叫中心系統(tǒng)壓力測試報告】
MyComm呼叫中心壓力測試解決方案
2011/10/13
）
1. 測試定義
測試系統(tǒng)：MyCommCGS呼叫發(fā)生器。
被測系統(tǒng)：××××××××××××。
測試流程：呼叫發(fā)生器模擬用戶發(fā)起呼叫，并按照測試用例，能夠模擬按鍵輸入的測試系統(tǒng)語音流程。
被測流程：現(xiàn)有××××××××××××語音流程。在測試階段，被測流程需要增加能夠?qū)懗鰷y試數(shù)據(jù)的呼叫日志記錄。
主動外撥服務模塊：負責從數(shù)據(jù)庫的呼叫任務表中，批量讀取呼叫任務，提交給MyCommServer，對拒絕的任務，重復提交；接收但失敗的任務，可再次呼叫；呼叫成功的記錄，不再重復呼叫。
呼叫記錄表：由任務生成器批量生成呼叫任務記錄。
任務生成模塊：按照事先約定的規(guī)則、提供的測試數(shù)據(jù)，生成批量呼叫任務。
2. 測試目標
根據(jù)前期的溝通內(nèi)容，本次測試需要達到以下測試目標：
(1)、性能測試
測試目的：驗證被測系統(tǒng)在語音通道全部占滿的情況下，驗證被測系統(tǒng)交換機、CTI服務器、IVR服務器性能運行狀況。包括：CPU占用率、內(nèi)存使用量、網(wǎng)絡流量等。
驗證手段： 滿負載情況下，觀察windows的任務管理器，記錄系統(tǒng)資源消耗情況。
記錄方式：系統(tǒng)截屏。
(2)、穩(wěn)定性測試
觀察系統(tǒng)在長時間（24小時）、大壓力（N個E1 占用率超過80%）情況下系統(tǒng)是否運行正常。
3. 測試方案
3.1. 模擬測試方案
測試系統(tǒng)通過11條E1線路連接到被測系統(tǒng)，信令采用ISDN Pri。
測試設備:
4. 測試基礎數(shù)據(jù)
4.1. 測試數(shù)據(jù)準備
測試數(shù)據(jù)由被側(cè)方提供。
4.2. 數(shù)據(jù)交換格式定義
測試數(shù)據(jù)以excel文件格式提供，提供的數(shù)據(jù)包括：
1、欠費查詢所需要的用戶名，密碼
2、電費查詢所需要的用戶名，密碼
3、賬單傳真所需要的用戶名，密碼
4、等等。 請用戶補充需要的測試數(shù)據(jù)。
具體的Excel格式為：
4.3. 數(shù)據(jù)要求
為了測試系統(tǒng)在各種情況下的反應是否正常，要求這些數(shù)據(jù)當中有正確的數(shù)據(jù)也有錯誤的數(shù)據(jù)，錯誤數(shù)據(jù)請將有效數(shù)據(jù)字段標記為否。
1、報修、停電查詢?yōu)橹鳂I(yè)務，比例可以為70%
2、欠費查詢、電費查詢、賬單服務，比例為30%；
3、實際測試，具體比例應為可調(diào)整。
請用戶補充需要測試的業(yè)務流程詳細按鍵序列，如：
1、 F01保修流程。 電話接通后，測試系統(tǒng)模擬用戶按“1”鍵，延遲N秒，按‘2’鍵，延遲M秒，掛機。
2、 F02欠費流程。
3、 。。。
4、 FN流程。
4.4. 數(shù)據(jù)總量
總共提供N個用戶信息測試數(shù)據(jù)。
5. 測試用例設計
5.1. 測試用例設計原則
為了圓滿的完成這次測試，我們在設計測試用例時應該遵循以下原則：
1、完全覆蓋原則。
為了驗證系統(tǒng)的正確性，要求測試用例設計時能夠覆蓋全部語音流程�？紤]到項目的實際情況，我們這次設計要求覆蓋N個流程，其他的意外處理流程不需要單獨設計。
2、流程分支的隨機性原則。
為了盡量模擬系統(tǒng)的實際情況，要求測試數(shù)據(jù)不要集中到某一個流程，盡量相對隨機走不同的流程。
3、 測試數(shù)據(jù)的足夠性原則。
為了測試系統(tǒng)的穩(wěn)定性和大壓力下的系統(tǒng)運行效率和支持能力，要求準備足夠多的外撥數(shù)據(jù)。
5.2. 測試流程設計
根據(jù)被測系統(tǒng)的現(xiàn)有流程，我們分別設計測試流程：
測試流程列表：
5.3. 測試數(shù)據(jù)設計
5.3.1. 數(shù)據(jù)唯一標識
為了區(qū)別每一次呼叫，我們決定每次呼叫時傳送不同主叫號碼，作為唯一標識。 主叫號碼從10000000開始使用。
5.3.2. 呼叫任務數(shù)據(jù)庫格式
外撥任務數(shù)據(jù)庫包含了系統(tǒng)外撥時需要的所有數(shù)據(jù)。 呼叫任務數(shù)據(jù)庫包含如下字段：
A、主叫號碼 20位字符串
B、被叫號碼 20為字符串
C、測試流程ID 1-5的整數(shù)
D、是否呼叫完成標志。整數(shù)，0標示為完成， 1表示已經(jīng)呼叫完成。
測試流程內(nèi)容根據(jù)被測系統(tǒng)語音流程具體內(nèi)容確定。
5.3.3. 呼叫任務生成器
呼叫任務的生成程序負責根據(jù)前面定義的規(guī)則，初步生成100萬條呼叫數(shù)據(jù)。
主叫號碼從10000000開始，每次加1，作為數(shù)據(jù)的唯一標示。
被叫號碼固定為：×××××，具體的生成呼叫數(shù)據(jù)流程圖：
5.3.4. 按鍵語音文件生成器
由于系統(tǒng)中播放語音文件的命令中同時播放的文件數(shù)有限制（10 個語音文件）， 因此我們會事先根據(jù)被側(cè)方給出的證件號碼、密碼生成對應的語音文件。在IVR
流程中我們會直接調(diào)用證件號碼對應的語音文件名。
5.4. 呼叫發(fā)起程序設計
1、 呼叫發(fā)起程序啟動后， 向CTIserver 注冊，注冊成功后繼續(xù)下面的邏輯。
2、 定時掃描外撥任務數(shù)據(jù)庫，查找外撥任務。
3、 向服務器提交外撥任務請求。（外撥流程號作為外撥參數(shù)提交）
4、 測試IVR 根據(jù)傳遞過來的流程號讀取數(shù)據(jù)庫，進行外撥
5、 如果外撥成功，則修改數(shù)據(jù)庫中該記錄的外撥是否成功字段。
6、 如果外撥失敗，下次的定時器繼續(xù)提交。
5.5. 外撥IVR 流程的設計
測試系統(tǒng)外撥成功后，會啟動對應的外撥流程。外撥流程根據(jù)系統(tǒng)的外撥參數(shù)或數(shù)據(jù)庫得到按鍵序列。 流程依照按鍵序列一次播放模擬按鍵，延遲一定時間后掛機。
示例流程如下：
6. 被測系統(tǒng)測試日志數(shù)據(jù)設計
為了分析系統(tǒng)功能的準確性，需要雙方記錄以下呼叫日志與數(shù)據(jù)：
6.1. 測試系統(tǒng)（CGS呼叫發(fā)生器）
表名：tMyCommCGSTaskHist
6.2. 被測系統(tǒng)（聲訊系統(tǒng)）
表名：tMyCommCIRCHist
CTI論壇編輯
相關閱讀: