首頁(yè)>>廠(chǎng)商>>CTI系統平臺廠(chǎng)商>>聯(lián)信志誠(MyComm)

【MyComm公司呼叫中心系統壓力測試報告】

MyComm呼叫中心壓力測試解決方案

2011/10/13

　　測試系統通過(guò)11條E1線(xiàn)路連接到被測系統，信令采用ISDN Pri。

　　測試設備:

　　4. 測試基礎數據

　　4.1. 測試數據準備

　　測試數據由被側方提供。

　　4.2. 數據交換格式定義

　　測試數據以excel文件格式提供，提供的數據包括：

　　1、欠費查詢(xún)所需要的用戶(hù)名，密碼
　　2、電費查詢(xún)所需要的用戶(hù)名，密碼
　　3、賬單傳真所需要的用戶(hù)名，密碼
　　4、等等。 請用戶(hù)補充需要的測試數據。

　　具體的Excel格式為：

　　4.3. 數據要求

　　為了測試系統在各種情況下的反應是否正常，要求這些數據當中有正確的數據也有錯誤的數據，錯誤數據請將有效數據字段標記為否。
　　1、報修、停電查詢(xún)?yōu)橹鳂I(yè)務(wù)，比例可以為70%
　　2、欠費查詢(xún)、電費查詢(xún)、賬單服務(wù)，比例為30%；
　　3、實(shí)際測試，具體比例應為可調整。

　　請用戶(hù)補充需要測試的業(yè)務(wù)流程詳細按鍵序列，如：

　　1、 F01保修流程。 電話(huà)接通后，測試系統模擬用戶(hù)按“1”鍵，延遲N秒，按‘2’鍵，延遲M秒，掛機。
　　2、 F02欠費流程。
　　3、 。。。
　　4、 FN流程。

　　4.4. 數據總量

　　總共提供N個(gè)用戶(hù)信息測試數據。

　　5. 測試用例設計

　　5.1. 測試用例設計原則

　　為了圓滿(mǎn)的完成這次測試，我們在設計測試用例時(shí)應該遵循以下原則：

　　1、完全覆蓋原則。

　　為了驗證系統的正確性，要求測試用例設計時(shí)能夠覆蓋全部語(yǔ)音流程。考慮到項目的實(shí)際情況，我們這次設計要求覆蓋N個(gè)流程，其他的意外處理流程不需要單獨設計。

　　2、流程分支的隨機性原則。

　　為了盡量模擬系統的實(shí)際情況，要求測試數據不要集中到某一個(gè)流程，盡量相對隨機走不同的流程。

　　3、 測試數據的足夠性原則。

　　為了測試系統的穩定性和大壓力下的系統運行效率和支持能力，要求準備足夠多的外撥數據。

　　5.2. 測試流程設計

　　根據被測系統的現有流程，我們分別設計測試流程：

　　測試流程列表：

　　5.3. 測試數據設計

　　5.3.1. 數據唯一標識

　　為了區別每一次呼叫，我們決定每次呼叫時(shí)傳送不同主叫號碼，作為唯一標識。 主叫號碼從10000000開(kāi)始使用。

　　5.3.2. 呼叫任務(wù)數據庫格式

　　外撥任務(wù)數據庫包含了系統外撥時(shí)需要的所有數據。 呼叫任務(wù)數據庫包含如下字段：

　　A、主叫號碼 20位字符串
　　B、被叫號碼 20為字符串
　　C、測試流程ID 1-5的整數
　　D、是否呼叫完成標志。整數，0標示為完成， 1表示已經(jīng)呼叫完成。

　　測試流程內容根據被測系統語(yǔ)音流程具體內容確定。

　　5.3.3. 呼叫任務(wù)生成器

　　呼叫任務(wù)的生成程序負責根據前面定義的規則，初步生成100萬(wàn)條呼叫數據。
　　主叫號碼從10000000開(kāi)始，每次加1，作為數據的唯一標示。
　　被叫號碼固定為：×××××，具體的生成呼叫數據流程圖：

　　6. 被測系統測試日志數據設計

　　為了分析系統功能的準確性，需要雙方記錄以下呼叫日志與數據：

　　6.1. 測試系統（CGS呼叫發(fā)生器）

　　表名：tMyCommCGSTaskHist

　　6.2. 被測系統（聲訊系統）

　　表名：tMyCommCIRCHist

CTI論壇編輯