MyComm呼叫中心压力测试解决方案

2011/10/13

目 录

1. 测试定义

2. 测试目标

3. 测试方案

3.1. 模拟测试方案

4. 测试基础数据

4.1. 测试数据准备

4.2. 数据交换格式定义

4.3. 数据要求

4.4. 数据总量

5. 测试用例设计

5.1. 测试用例设计原则

5.2. 测试流程设计

5.3. 测试数据设计

5.3.1. 数据唯一标识

5.3.2. 呼叫任务数据库格式

5.3.3. 呼叫任务生成器

5.3.4. 按键语音文件生成器

5.4. 呼叫发起程序设计

5.5. 外拨IVR流程的设计

6. 被测系统测试日志数据设计

6.1. 测试系统(CGS呼叫发生器)

6.2. 被测系统(声讯系统)

1. 测试定义

测试系统：MyCommCGS呼叫发生器。

被测系统：××××××××××××。

测试流程：呼叫发生器模拟用户发起呼叫，并按照测试用例，能够模拟按键输入的测试系统语音流程。

被测流程：现有××××××××××××语音流程。在测试阶段，被测流程需要增加能够写出测试数据的呼叫日志记录。

主动外拨服务模块：负责从数据库的呼叫任务表中，批量读取呼叫任务，提交给MyCommServer，对拒绝的任务，重复提交；接收但失败的任务，可再次呼叫；呼叫成功的记录，不再重复呼叫。

呼叫记录表：由任务生成器批量生成呼叫任务记录。

任务生成模块：按照事先约定的规则、提供的测试数据，生成批量呼叫任务。

2. 测试目标

根据前期的沟通内容，本次测试需要达到以下测试目标：

(1)、性能测试

测试目的：验证被测系统在语音通道全部占满的情况下，验证被测系统交换机、CTI服务器、IVR服务器性能运行状况。包括：CPU占用率、内存使用量、网络流量等。

验证手段： 满负载情况下，观察windows的任务管理器，记录系统资源消耗情况。

记录方式：系统截屏。

(2)、稳定性测试

观察系统在长时间(24小时)、大压力(N个E1 占用率超过80%)情况下系统是否运行正常。

3. 测试方案

3.1. 模拟测试方案

测试系统通过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，作为数据的唯一标示。

被叫号码固定为：×××××，具体的生成呼叫数据流程图：

5.3.4. 按键语音文件生成器

由于系统中播放语音文件的命令中同时播放的文件数有限制(10 个语音文件)， 因此我们会事先根据被侧方给出的证件号码、密码生成对应的语音文件。在IVR

流程中我们会直接调用证件号码对应的语音文件名。

5.4. 呼叫发起程序设计

1、 呼叫发起程序启动后， 向CTIserver 注册，注册成功后继续下面的逻辑。

2、 定时扫描外拨任务数据库，查找外拨任务。

3、 向服务器提交外拨任务请求。(外拨流程号作为外拨参数提交)

4、 测试IVR 根据传递过来的流程号读取数据库，进行外拨

5、 如果外拨成功，则修改数据库中该记录的外拨是否成功字段。

6、 如果外拨失败，下次的定时器继续提交。

5.5. 外拨IVR 流程的设计

测试系统外拨成功后，会启动对应的外拨流程。外拨流程根据系统的外拨参数或数据库得到按键序列。 流程依照按键序列一次播放模拟按键，延迟一定时间后挂机。

示例流程如下：

6. 被测系统测试日志数据设计

为了分析系统功能的准确性，需要双方记录以下呼叫日志与数据：

6.1. 测试系统(CGS呼叫发生器)

表名：tMyCommCGSTaskHist

6.2. 被测系统(声讯系统)

表名：tMyCommCIRCHist

CTI论坛编辑

相关阅读: