1. 测试定义

　　测试系统：MyCommCGS呼叫发生器。
　　被测系统：××××××××××××。
　　测试流程：呼叫发生器模拟用户发起呼叫，并按照测试用例，能够模拟按键输入的测试系统语音流程。
　　被测流程：现有××××××××××××语音流程。在测试阶段，被测流程需要增加能够写出测试数据的呼叫日志记录。
　　主动外拨服务模块：负责从数据库的呼叫任务表中，批量读取呼叫任务，提交给MyCommServer，对拒绝的任务，重复提交；接收但失败的任务，可再次呼叫；呼叫成功的记录，不再重复呼叫。
　　呼叫记录表：由任务生成器批量生成呼叫任务记录。
　　任务生成模块：按照事先约定的规则、提供的测试数据，生成批量呼叫任务。

2. 测试目标

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

　　(1)、性能测试

　　测试目的：验证被测系统在语音通道全部占满的情况下，验证被测系统交换机、CTI服务器、IVR服务器性能运行状况。包括：CPU占用率、内存使用量、网络流量等。
　　验证手段： 满负载情况下，观察windows的任务管理器，记录系统资源消耗情况。
　　记录方式：系统截屏。

　　(2)、稳定性测试

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

3. 测试方案

3.1. 模拟测试方案
 

　　测试系统通过11条E1线路连接到被测系统，信令采用ISDN Pri。

　　测试设备:

4. 测试基础数据

4.1. 测试数据准备

测试数据由被侧方提供。

4.2. 数据交换格式定义

测试数据以excel文件格式提供，提供的数据包括：

1、欠费查询所需要的用户名，密码

2、电费查询所需要的用户名，密码

3、账单传真所需要的用户名，密码

4、等等。 请用户补充需要的测试数据。

具体的Excel格式为：

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. 测试流程设计

根据被测系统的现有流程，我们分别设计测试流程：

测试流程列表：

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.2. 被测系统（声讯系统）

表名：tMyCommCIRCHist