MyComm呼叫中心压力测试解决方案
2011/10/13
)
测试系统通过11条E1线路连接到被测系统,信令采用ISDN Pri。
测试设备:
设备名称 |
数量 | 设备配置 |
测试设备 | 1 | 4E1接口卡3块,共N个E1 |
信令配置 | / | 测试方信令 ISDN Pri,网络侧 被测方信令 ISDN Pri,用户侧 |
4. 测试基础数据
4.1. 测试数据准备
测试数据由被侧方提供。
4.2. 数据交换格式定义
测试数据以excel文件格式提供,提供的数据包括:
1、欠费查询所需要的用户名,密码
2、电费查询所需要的用户名,密码
3、账单传真所需要的用户名,密码
4、等等。 请用户补充需要的测试数据。
具体的Excel格式为:
查询类型 |
用户名 |
密码 |
有效数据 |
欠费查询 |
123456789 |
111111 | 是(正确的用户名密码) |
欠费查询 |
************ | ****** | 否(错误的用户名密码) |
电费查询 |
************ | ****** | 是 |
4.3. 数据要求
为了测试系统在各种情况下的反应是否正常,要求这些数据当中有正确的数据也有错误的数据,错误数据请将有效数据字段标记为否。
1、报修、停电查询为主业务,比例可以为70%
2、欠费查询、电费查询、账单服务,比例为30%;
3、实际测试,具体比例应为可调整。
请用户补充需要测试的业务流程详细按键序列,如:
1、 F01保修流程。 电话接通后,测试系统模拟用户按“1”键,延迟N秒,按‘2’键,延迟M秒,挂机。
2、 F02欠费流程。
3、 。。。
4、 FN流程。
4.4. 数据总量
总共提供N个用户信息测试数据。
5. 测试用例设计
5.1. 测试用例设计原则
为了圆满的完成这次测试,我们在设计测试用例时应该遵循以下原则:
1、完全覆盖原则。
为了验证系统的正确性,要求测试用例设计时能够覆盖全部语音流程。考虑到项目的实际情况,我们这次设计要求覆盖N个流程,其他的意外处理流程不需要单独设计。
2、流程分支的随机性原则。
为了尽量模拟系统的实际情况,要求测试数据不要集中到某一个流程,尽量相对随机走不同的流程。
3、 测试数据的足够性原则。
为了测试系统的稳定性和大压力下的系统运行效率和支持能力,要求准备足够多的外拨数据。
5.2. 测试流程设计
根据被测系统的现有流程,我们分别设计测试流程:
测试流程列表:
流程序号 | 外拨流程列表 | 流程比例(%) | 备注 |
F01 | 欠费查询 | 10 | |
F02 | 电费查询 | 10 | |
F03 |
账单传真 |
10 |
|
F04 |
报修及停电 |
10 | |
F05 | 转人工座席 | 10 | |
………… |
………… | ………… | ………… |
F N |
………… | ………… | ………… |
5.3. 测试数据设计
5.3.1. 数据唯一标识
为了区别每一次呼叫,我们决定每次呼叫时传送不同主叫号码,作为唯一标识。 主叫号码从10000000开始使用。
5.3.2. 呼叫任务数据库格式
外拨任务数据库包含了系统外拨时需要的所有数据。 呼叫任务数据库包含如下字段:
A、主叫号码 20位字符串
B、被叫号码 20为字符串
C、测试流程ID 1-5的整数
D、是否呼叫完成标志。整数,0标示为完成, 1表示已经呼叫完成。
测试流程内容根据被测系统语音流程具体内容确定。
5.3.3. 呼叫任务生成器
呼叫任务的生成程序负责根据前面定义的规则,初步生成100万条呼叫数据。
主叫号码从10000000开始,每次加1,作为数据的唯一标示。
被叫号码固定为:×××××,具体的生成呼叫数据流程图:
6. 被测系统测试日志数据设计
为了分析系统功能的准确性,需要双方记录以下呼叫日志与数据:
6.1. 测试系统(CGS呼叫发生器)
表名:tMyCommCGSTaskHist
6.2. 被测系统(声讯系统)
表名:tMyCommCIRCHist
CTI论坛编辑
MyComm公司呼叫中心系统压力测试报告实例 2011-10-13 |
沈阳华商晨报96128呼叫中心完成快速扩容 2011-07-28 |
MyCommIP呼叫中心助贵阳晚报96669热线快速扩容 2011-07-14 |
MyComm呼叫中心性能测试为集团客服系统保驾护航 2011-07-05 |
MyComm公司助海峡都市报开通台胞公共服务热线 2011-06-28 |