文档文库
手机版
投诉建议
热门搜索： 心得体会 演讲稿 思想汇报
首页 > 存储转发机制优化系统测试方案及案例

存储转发机制优化系统测试方案及案例

发布时间：2010-09-02 16:05:48   来源：文档文库   
小 中 大
字号：
手机查看

一级XXXX枢纽

存储转发机制优化系统测试方案及案例



Document Information

Project Name:

Document Version No:

1.0

Document Version Date:

2005-08-16

Prepared By:

Preparation Date:

2005-08-16

Reviewed By:

Review Date:

Distribution List

From

Date

Company / Role

Email / Phone

To

Action*

Due Date

Company / Role

Email / Phone

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

Version History

Ver. No.

Ver. Date

Revised By

Description

Filename

1.0

2005-08-17

黄锡波

初稿

1.0

2005-08-26

黄锡波

根据测试评审会议修正压力测试方案

1.1

2005-08-28

黄锡波

修改压力测试方案及压力测试的操作方法



版 权 说 明



1. 引言

1.1. 概述

本测试方案及案例主要测试一级BOSS系统的存储转发机制优化系统

1.2. 适用范围与读者对象

1.3. 准入条件

该测试案例主要进行功能及系统测试，在程序员完成单元测试后进行功能及系统测试。

1.4. 测试人员

本系统的测试需要对于存储转发机制优化系统的构架熟悉，并且熟悉业务的要求。本测试需要一名测试人员。

1.5. 参考文档

《存储转发机制优化概要设计_v1.3.doc》

《一级BOSS抗容功能规格说明书》

1.6. 缩略语

1． BOSS：业务运营支撑系统（Business Operation Support System）

2. 约定

2.1. 测试目标

通过功能及测试，达到以下目标：

✧ 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。

✧ 产品规定的操作和运行稳定。

✧ Bug数和缺陷率控制在可接收的范围之内。

2.2. 测试标准

本节所述的接收标准是指可测试的标准，这个标准以测试员接收测试为限。单元测试接收标准的详细规定参见附件一：测试接收标准。其余各阶段接收标准，以经过审核后的上一阶段测试报告为准，每一阶段停止标准的详细规定参见附件二：测试停止标准。

2.3. 错误级别定义

见附件三：错误级别

2.4. 测试工作流程

测试工作流程见附件四：测试工作流程

BUG通过StartTeam报告给开发人员

2.5. 案例编号规则

测试案例编号：

正常案例编号：SAF_PV+四位编号，如：SAF_PV0001

异常案例编号：SAF_NV+四位编号，如：SAF_NV0001

系统测试案例编号:SAF_SYS+四位编号，如：SAF_SYS0001

2.6. 案例编写要点

见附件五：案例编写要点

3. 测试环境和测试工具

自主开发一个自动充填SAF表的脚本，运做过程的关键检查点脚本。数据库使用ORACLE 9.2.0.1.0

3.1. 服务器环境说明

服务器环境如下：

服务器操作系统：HP-UX 11.11

服务器IP：10.1.132.5

JDK版本：JDK 1.4.1 1.4.1.03-030630-22:07-PA_RISC2.0 PA2.0

测试环境是:

中心:

服 务 器: 10.1.132.5

用 户: cmcbadm

系统目录: csc:/home/cmcbadm及/opt/webMethods

webMethods端口: 5555

数 据 库: 10.1.132.5

配 置: jdbc:oracle:thin:@10.1.132.5:1521:dbtest2 & user=cmcbadm

CSN1:

服 务 器: 10.1.132.5

用 户: wm_sn1

系统目录: csn1:/home/wm_sn1及/opt/webMethods

webMethods端口: 6666

数 据 库: 10.1.132.5

配 置: jdbc:oracle:thin:@10.1.132.5:1521:dbtest2 & user=csn1

CSN2:

服 务 器: 10.1.132.5

用 户: wm_sn2

系统目录: csn2:/home/wm_sn2及/opt/webMethods

webMethods端口: 8888

数 据 库: 10.1.132.5

配 置: jdbc:oracle:thin:@10.1.132.5:dbtest2 & user=csn2

3.2. 数据库环境说明

配置信息参见服务器环境说明的数据库部分。

3.3. 客户端环境说明

4. 风险及规避

4.1. 本次测试过程中，可能出现的风险如下：

✧ 转发涉及到落地方，如何模拟一个落地方？

✧ 日切前后如何模拟？

✧ 测试环境运行太慢、环境配置没有说明书（或不完整）及系统启动/关闭时间长等造成效率低下

✧ BUG的修复没有认真评估，此BUG解决却引起新的BUG

✧ 模块功能的实现情况

✧ 系统整体功能的实现情况

✧ 代码的编写质量

✧ 人员经验以及对软件的熟悉度

✧ 开发人员、测试人员关于项目约定的执行情况

4.2. 风险的规避：

✧ 与沟通环境的模拟问题

✧ 有一个独立的性能较好的测试服务器，有完善的环境配置说明书

✧ BUG的修复要认真评估

✧ 模块功能或系统整体功能的实现较好，运行流畅

✧ 代码的编写质量较好，经过反复的单元测试

✧ 与设计人员多沟通

✧ 项目约定的执行情况良好

5. 测试案例

5.1. 正常情况测试（positive cases）

5.1.1. [SAF_PV0001：参数设置]

案例名称

参数设置

案例编号

0001

优先级别

A

测试目的

系统能够正确读取参数设置，并按照设定的参数运行。

预置条件

测试数据描述

• SAF_DISPATCHERS（SAF线程定义表）定义数据：INTERVAL＝5000ms（间隔时间）

• SAF_DISP_PARTIES（线程－落地方关系定义表）：STOP_FLAG＝Y/N

• SAF_DISP_PARTIES（线程－落地方关系定义表）：HPARTY_ID落地方机构码与某线程对应

测试案例执行步骤

• 关闭saf多线程，打开debug，预期结果:间隔时间是5000ms

• 关闭saf多线程，打开debug，如果STOP_FLAG＝Y,打开saf多线程,预期结果:线程是不会起来。反之,当STOP_FLAG＝N,预期结果：线程能够起来

• HPARTY_ID落地方机构码没有定义上海,做一笔落地方是上海的VIP机场交易,检查saf表,预期结果：STATUS=1(未处理)

• SAF_DISPATCHERS（SAF线程定义表）定义线程记录3条，重起来线程，预期结果：线程数3条（注意线程名字）

预期结果

正确依照设置的参数运行

备注

OK

5.1.2. [SAF_PV0002：优先级]

案例名称

优先级

案例编号

0002

优先级别

A

测试目的

验证系统是否按照优先级运行

预置条件

测试数据描述

基本基础数据

测试案例执行步骤

• 关闭saf线程

• SAF_DISPATCHERS（SAF线程定义表）定义FETCH_NUM＝5(一个时间间隔内取多少条交易), SAF_DISP_PARTIES（线程－落地方关系定义表）定义H_CUR_NUM＝H_MAX_NUM ＝2（落地方接收能力）

• 做6笔交易，把saf表中的6条数据从小到大排序，优先级别依次为：4，5，6，4，5，6

• 起来saf线程（reload），检查saf表的status＝2为止，关闭saf线程

• 检查log，预期结果：

begin time:1124869364401

// 预期结果：捞5条,发送2条（优先级别是6的）, 同一个优先级别的先进先出

seq id:1000BOSS0824152908TC010*********_Req

This id is Send:1000BOSS0824152908TC010*********_Req

seq id:1000BOSS0824152932TC010*********_Req

This id is Send:1000BOSS0824152932TC010*********_Req

seq id:1000BOSS0824152903TC010*********_Req

seq id:1000BOSS0824152926TC010*********_Req

seq id:1000BOSS0824152857TC010*********_Req

end time:1124869364627

sleep4774

thread name:wang

begin time:1124869369376

// 预期结果：捞4条,发送2条（优先级别是5的）, 同一个优先级别的先进先出

seq id:1000BOSS0824152903TC010*********_Req

This id is Send:1000BOSS0824152903TC010*********_Req

seq id:1000BOSS0824152926TC010*********_Req

This id is Send:1000BOSS0824152926TC010*********_Req

seq id:1000BOSS0824152857TC010*********_Req

seq id:1000BOSS0824152921TC010*********_Req

end time:1124869369534

sleep4842

thread name:wang

begin time:1124869374386

// 预期结果：捞2条,发送2条（优先级别是4的）, 同一个优先级别的先进先出

seq id:1000BOSS0824152857TC010*********_Req

This id is Send:1000BOSS0824152857TC010*********_Req

seq id:1000BOSS0824152921TC010*********_Req

This id is Send:1000BOSS0824152921TC010*********_Req

end time:1124869374510

• 最后检查tlog同一Id的交易，预期结果：status＝1100

把saf的6笔交易改成冲正交易，重复上述操作，检查是否满足高优先级优先及同一个优先级别的先进先出

下面是预期结果：正确的log记录：

thread name:wang

begin time:1124936583980

seq id:1000BOSS0825095736TC010*********_Req

This id is Send:1000BOSS0825095736TC010*********_Req

seq id:1000BOSS0825095746TC010*********_Req

This id is Send:1000BOSS0825095746TC010*********_Req

seq id:1000BOSS0825095730TC010*********_Req

seq id:1000BOSS0825095752TC010*********_Req

seq id:1000BOSS0825095724TC010*********_Req

end time:1124936584137

thread name:wang

begin time:1124936588985

seq id:1000BOSS0825095730TC010*********_Req

This id is Send:1000BOSS0825095730TC010*********_Req

seq id:1000BOSS0825095752TC010*********_Req

This id is Send:1000BOSS0825095752TC010*********_Req

seq id:1000BOSS0825095724TC010*********_Req

seq id:1000BOSS0825095741TC010*********_Req

end time:1124936589112

thread name:wang

begin time:1124936594006

seq id:1000BOSS0825095724TC010*********_Req

This id is Send:1000BOSS0825095724TC010*********_Req

seq id:1000BOSS0825095741TC010*********_Req

This id is Send:1000BOSS0825095741TC010*********_Req

end time:1124936594217

预期结果

正确按照优先级发送，填写saf、Tlog正确

备注

OK

5.1.3. [SAF_PV0003：SAF线程定义表]

案例名称

SAF线程定义表

案例编号

0003

优先级别

A

测试目的

验证落地方的接收能力和发送的记录数

预置条件

测试数据描述

基本基础数据

测试案例执行步骤

• 关闭saf线程

• SAF_DISPATCHERS（SAF线程定义表）定义FETCH_NUM＝5(一个时间间隔内取多少条交易), SAF_DISP_PARTIES（线程－落地方关系定义表）定义H_CUR_NUM＝H_MAX_NUM ＝2（落地方接收能力）

• 做6笔交易，起来saf线程（reload），检查saf表的status＝2为止，关闭saf线程

• 检查log，预期结果：

thread name:wang

begin time:1124867252596

thread name:sheng

begin time:1124867252600

• // 预期结果：捞5条,发送2条

seq id:1000BOSS0824150634TC010*********_Req

This id is Send:1000BOSS0824150634TC010*********_Req

seq id:1000BOSS0824150641TC010*********_Req

This id is Send:1000BOSS0824150641TC010*********_Req

seq id:1000BOSS0824150647TC010*********_Req

seq id:1000BOSS0824150654TC010*********_Req

seq id:1000BOSS0824150659TC010*********_Req

end time:1124867252731

sleep4865

thread name:wang

begin time:1124867257605

// 预期结果：捞4条,发送2条

seq id:1000BOSS0824150647TC010*********_Req

This id is Send:1000BOSS0824150647TC010*********_Req

seq id:1000BOSS0824150654TC010*********_Req

This id is Send:1000BOSS0824150654TC010*********_Req

seq id:1000BOSS0824150659TC010*********_Req

seq id:1000BOSS0824150705TC010*********_Req

end time:1124867257751

sleep4854

thread name:wang

begin time:1124867262615

// 预期结果：捞2条,发送2条

seq id:1000BOSS0824150659TC010*********_Req

This id is Send:1000BOSS0824150659TC010*********_Req

seq id:1000BOSS0824150705TC010*********_Req

This id is Send:1000BOSS0824150705TC010*********_Req

end time:1124867262869

• 最后检查tlog同一Id的交易，预期结果：status＝1100

预期结果

能够按照线程捞的条数、落地方的接收能力发送，填写saf、Tlog正确

备注

OK

5.1.4. [SAF_PV0004：SAF分发线程组模块]

案例名称

SAF分发线程组模块

案例编号

0004

优先级别

A

测试目的

验证StartsSAFWorkers是否可以控制重入

验证SAF_Worker是否可以控制重入

预置条件

测试数据描述

• 正确启动后并正常发送数据

• StartsSAFWorkers再启动一次，预期结果：控制重入（查询线程名字）

• SAF_Worker再启动一次，预期结果：控制重入（查询线程名字）

测试案例执行步骤

预期结果

正确控制重入

备注

OK

5.1.5. [SAF_PV0005：WorkStart日切表现]

案例名称

WorkStart日切表现

案例编号

0005

优先级别

A

测试目的

验证日切前、正在日切中、日切完成状态时，WorkStart的

预置条件

测试数据描述

测试案例执行步骤

• 例如30日准备切到31日

• 对于30日的数据，日切前发送取cutoffday，正在日切中，取lastcutoffday

• 对于31日的数据，正在日切中，取cutoffday

• 日切后，取cutoffday（做31日数据，30日的不管了）

先关闭saf线程，30日的有6条冲正数据未处理，把sys_para的CURRCUTOFFDAY= 20030331, LASTCUTOFFDAY=20030330, CUTOFFSTATUS=1(处于日切状态中),然后起来saf线程

预期结果：log:

thread name:wang

begin time:1124938610498

seq id:1000BOSS0825095736TC010*********_Req

This id is Send:1000BOSS0825095736TC010*********_Req

seq id:1000BOSS0825095746TC010*********_Req

This id is Send:1000BOSS0825095746TC010*********_Req

seq id:1000BOSS0825095730TC010*********_Req

seq id:1000BOSS0825095752TC010*********_Req

seq id:1000BOSS0825095724TC010*********_Req

end time:1124938610721

thread name:wang

begin time:1124938615505

seq id:1000BOSS0825095730TC010*********_Req

This id is Send:1000BOSS0825095730TC010*********_Req

thread name:caochao

begin time:1124938615958

seq id:1000BOSS0825095752TC010*********_Req

This id is Send:1000BOSS0825095752TC010*********_Req

end time:1124938616015

sleep943

seq id:1000BOSS0825095724TC010*********_Req

seq id:1000BOSS0825095741TC010*********_Req

end time:1124938616056

thread name:wang

begin time:1124938620501

seq id:1000BOSS0825095724TC010*********_Req

This id is Send:1000BOSS0825095724TC010*********_Req

seq id:1000BOSS0825095741TC010*********_Req

This id is Send:1000BOSS0825095741TC010*********_Req

end time:1124938620657

先关闭saf线程，30日的有6条冲正数据未处理，把sys_para的CURRCUTOFFDAY= 20030331, LASTCUTOFFDAY=20030330, CUTOFFSTATUS=0(日切状态一进完成),做一条31日的数据,然后起来saf线程

预期结果:

不会取30日的未完成的冲正数据,取的是31日的交易数据

thread name:wang

begin time:1124940601452

end time:1124940601665

sleep526

seq id:1000BOSS0825112910TC010*********_Req

This id is Send:1000BOSS0825112910TC010*********_Req

end time:1124940601985

预期结果

正确取逻辑工作日

备注

OK

5.1.6. [SAF_PV0006：WorkStart特殊条件处理]

案例名称

WorkStart特殊条件处理

案例编号

0006

优先级别

A

测试目的

验证WorkStart在特殊条件下处理

预置条件

测试数据描述

基本基础数据

测试案例执行步骤

与程序员交流，查程序是否考虑了下列特殊条件的处理

• 若发送个数为0，预期结果：不取SAF交易，继续循环

• 若落地方个数为0，预期结果：不取SAF交易，继续循环

预期结果

有考虑并在程序中已经实现

备注

OK

5.1.7. [SAF_PV0007：SAF监控器（TO BE DISCUSSED）]

案例名称

SAF监控器（TO BE DISCUSSED）

案例编号

0007

优先级别

A

测试目的

验证监控SAW Worker thread线程的死活状态

预置条件

测试数据描述

基本基础数据

测试案例执行步骤

起来Saf线程，KILL线程后是否重起，预期结果：自动重起

预期结果

监控状态正确

备注

OK

5.1.8. [SAF_PV0008：日对帐，月对帐(to be discussed)]

案例名称

日对帐，月对帐(to be discussed)

案例编号

0008

优先级别

A

测试目的

日对帐，月对帐单可以在SAF中并发送

预置条件

测试数据描述

基本基础数据

测试案例执行步骤

SAF表新增的字段指定缺省值

将hparty_id缺省值设为’8888’，作为一个特殊的落地方，由某个发送线程负责发送。发送线程将交易发给Dispatcher，Dispatcher使用报文中的domain_id,hsn_duns作为依据，发送到真正的落地方。这样不改动日终程序，日对帐，月对帐报文也可以正确发送到落地方

将bip_nice缺省值设为6，优先级为最高，这样日对帐，月对帐作为最高优先级交易得到快速发送。但是或许对后续业务的优先级设置有影响

执行/opt/cmcb/bin/cmcb_cronjob.sh stl dayendbatch 0即可

查询saf表,预期结果：有hparty_id=8888的记录,并按照报文中的落地方正确发出

预期结果

日对帐，月对帐单在SAF中正确发送

备注

OK

5.2. 异常情况测试（negative cases）

5.2.1. [SAF_NV0001：测试案例名称]

根据存储转发机制优化系统特点，异常情况案例不考虑单独撰写，异常情况的测试点已经关联到正常情况案例中，这样可以强化事件的关联测试和提高测试覆盖面。

5.3. 界面测试案例

（无）

5.4. 系统测试

5.4.1. 性能/压力测试方案

节点数

Saf总记录

未处理数

已处理数

间隔时间

中心捞数/次

线程数

每线程处理的省

每省承受

初级测试兼顾功能测试3省

1k

1k

0

5s

100

3

1

30/60/90

20%的省

(6省)

10k

3k

7k

60s

100

6

1

30/60/90

120/150/180

80%的省

(24省)

500k

200k

300k

300s

200

8

3

4*(30/60/90)

4*(120/150/180)

80%的省

(24省)

500k

100k

400k

300s

200

8

3

4*(30/60/90)

4*(120/150/180)

80%的省

(24省)

500k

50k

450k

300s

200

8

3

4*(30/60/90)

4*(120/150/180)

80%的省

(24省)

1000k

100k

900k

500s

200

8

3

4*(30/60/90)

4*(120/150/180)

每个测试方案的测试方法和预期结果与案例SAF_SYS0001同一模型

插入数据sal

select seq, bip_nice, status from saf where seq=(select max(seq) from saf)

select * from saf

select count(*) from saf where status='1'

--2101,4711,2201,5311,3111,3511,5511,2501,5711,5911,8981,2001,7711,9711,2701,7311,7911,3711,8911,2801,2301,2901,8511,8711,9311

update saf set hparty_id='9311' where seq>='1000BOSS0825492001TC010*********_Req' and seq<='1000BOSS0825499999TC010*********_Req'

select 300000+8000*25 from dual

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'sheng', '2101', 60, 60, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'sheng', '4711', 60, 60, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'sheng', '2201', 60, 60, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'caochao', '5311', 90, 90, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'caochao', '3111', 90, 90, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'caochao', '3511', 90, 90, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'wang', '5511', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'wang', '2501', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'wang', '5711', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a1', '5911', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a1', '8981', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a1', '2001', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a2', '7711', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a2', '9711', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a2', '2701', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a3', '7311', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a3', '7911', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a3', '3711', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a4', '8911', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a4', '2801', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a4', '2301', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a5', '2901', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a5', '8511', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a5', '8711', 30, 30, 'N');

INSERT INTO SAF_DISP_PARTIES ( DISPATCHER_NAME, HPARTY_ID, H_CUR_NUM, H_MAX_NUM,

STOP_FLAG ) VALUES (

'a5', '9311', 30, 30, 'N');

5.4.2. [SAF_SYS0001：性能状况]

案例名称

性能状况

案例编号

0001

优先级别

A

测试目的

检查不同参数组合的性能表现

预置条件

测试数据描述

基本基础数据

做1020条saf交易,均为未处理的数据

测试案例执行步骤

关闭saf线程

定义三个线程,对应的落地方关系是2101、2201、2501

定义saf（Ordey By Seq asc），优先级的定义4、5、6、4、5、6、。。。,落地方依次为2101,2201,2501

三个线程捞saf数据间隔时间是5000ms，一次捞100条saf记录

2101、2201、2501的接收能力分别是：30、60、90

记录内存、CPU、IO的记录

启动saf线程

每隔5s记录中心的内存、CPU、IO记录

观察testlog。Log，直到发送完毕为止（程序中发送语句临时注释，即不发送）

检查testlog。Log，若T2-T1>=T,则告警且sleep1秒（须调整间隔时长，使得T- (T2-T1)>=10s,这时需停止线程,调整参数后重来）。否则Sleep（T- (T2-T1)）

停止saf线程

对中心的内存、CPU、IO记录进行分析

画出曲线图分析

对testlog进行分析:

检查是否满足三个原则?(优先级高的先发,同级时间优先,落地方承受能力)

线程名与落地方的对应关系是否有错(即自己的线程才可以发送自己的数据)

类似下列数据:

thread name:wang

begin time:1124868753770

seq id:1000BOSS0824152903TC010*********_Req

This id is Send:1000BOSS0824152903TC010*********_Req

seq id:1000BOSS0824152926TC010*********_Req

This id is Send:1000BOSS0824152926TC010*********_Req

end time:1124868753885

sleep4885

thread name:wang

begin time:1124868758775

end time:1124868758787

sleep4988

计算并检查:

捞saf记录=100?

2101、2201、2501的发送分别是：30、60、90

Sleep时间对吗？

中心间隔时间对吗？

画出捞时间曲线图

下面是原始测试数据和图表分析

结果原始数据:

线程wang的第一个循环数据:

检查是否满足三个原则?(优先级高的先发,同级时间优先,落地方承受能力):测试结果OK

线程名与落地方的对应关系是否有错(即自己的线程才可以发送自己的数据):测试结果OK

计算并检查:

捞saf记录=100?测试结果:OK

2101、2201、2501的发送分别是：30、60、90?测试结果:OK

Sleep时间对吗？捞并发送时间:173ms,sleep=5000-173=4827ms,查sleep正确,sleep共43次,平均sleep4789.3ms,MAX=4874ms,MIN=4304ms

中心间隔时间对吗？测试结果:OK

图标说明：捞saf数据且发送数据所耗时间(ms)图

X轴为线程循环次数，Y轴为捞saf数据且发送数据所耗时间(ms)

支撑数据和测试结果表

线程

每次捞saf数量

落地方

落地方

接收能力

压力测试项

压力测试结果

线程1

100

2101

30

捞次数/睡次数

49/49

最少/最大/平均捞数据耗时ms

141/879/264

最少/最大/平均睡眠时间ms

4121/4859/4735

线程2

100

2201

60

捞次数/睡次数

43/43

最少/最大/平均捞数据耗时ms

126/696/210

最少/最大/平均睡眠时间ms

4304/4874/4789

线程3

100

2501

90

捞次数/睡次数

49/49

最少/最大/平均捞数据耗时ms

132/870/247

最少/最大/平均睡眠时间ms

4130/4868/4752

三个进程共捞且发送saf记录共22740条

三个进程共捞且发送saf记录共耗时12937毫秒

3进程共同捞且发送saf数据平局速度: 1757.749(条/秒)

图标说明：Memory free检测图

X轴为每间隔5秒循环检测Memory free次数，Y轴为Memory free值（M）

Memory free值来源于服务器的TOP命令中Memory free值

图标说明：userCpu、sysCpu idleCpu的平均值检测图

X轴为每间隔5秒循环检测Cpu次数，Y轴为userCpu、sysCpu idleCpu的平均值

userCpu、sysCpu idleCpu值来源于服务器的TOP命令中userCpu、sysCpu idleCpu的Avg值

预期结果

符合性能需求

备注

/

详细压力测试情况请阅读《压力测试报告（存储转发机制优化系统）.doc》

6. 自动测试

（无）

7. 测试报告

测试报告一般一周出报告一次（周末下班前），报告放在StartTeam中，并EMAIL给开发人员。

测试报告框架如下：

一、测试概要

1.1 测试计划及执行

1.2 测试系统环境配置

二、测试情况

2.1基本测试

测试方法、测试案例执行状况、测试结果

2.2组件测试

测试方法、测试案例执行状况、测试结果

2.3接口测试

测试方法、测试案例执行状况、测试结果

2.4整体测试

测试方法、测试案例执行状况、测试结果

三、测试结果分析

3.1测试充分性评价

3.2改进建议

8. 测试任务和进度

测试阶段

测试任务

工作量估计

(人日)

人员分配

开始时间

截止时间

第一阶段

方案设计、案例设计

2

黄锡波

2005-08-17

2005-08-18

方案设计、案例设计review

1

王峰/焦求智

2005-08-19

2005-08-19

理顺测试环境/熟悉环境

1

焦求智/黄锡波

2005-08-19

2005-08-22

StartTeam管理工具

1

闫健勇

2005-08-19

2005-08-19

第二阶段

测试：

正常情况（案例8个）

系统测试（案例1个）

2

黄锡波

2005-08-25

2005-08-26

补充案例/完善案例

1

黄锡波

2005-08-26

2005-08-26

补充测试

1

黄锡波

2005-08-29

2005-08-29

第三阶段

回归测试/完善案例

/

黄锡波

/

/

9. 附件

9.1. 附件一：测试接收标准

前言：接收标准为程序员经过单元测试后，提交测试时应达到的最低标准，如不满足，则返还开发，重新提交测试。

9.1.1. 接收资料完整，如资料不完整，则不予接收

1． 经过审核程序源代码。

2． 用来运行单元测试的相关的模块（测试模块或其他模块）。

3． 必要的数据库文件。

4． 必要的配置。

5． 经过审核过的概要和详细的设计文档、帮助文件、其他必要的文件。

6． 白盒测试的测试案例和白盒单元测试报告。

9.1.2. 程序界面

7． 界面风格

a. 界面风格一致（包括控件的大小、快捷键的命令名称），美观大方。

b. 无错字别字，最好能望文知意。

8． 菜单项问题

a. 各菜单项功能均已实现。

b. 各菜单项快捷键可以使用。

9.1.3. 功能实现

9． 说明书规定的功能或程序员提交的功能说明书的功能均已实现。

10． 基本流程可以走通。

11． 功能的关键检查点(CheckPoint)在单元测试时已经测试，结果正确。

12． 界面上的功能均实现，符合设计文挡规定的功能。

13． 打开界面上的功能，时间在5秒内。

14． 正确实现左右键功能（如果有）

a. 左键拖动功能已实现。

b. 右键功能与菜单项功能对应。

c. 右键的快捷键应与菜单项一致。

15． 提示信息

a. 提示、警告、或错误说明应该清楚、明了、恰当。

b. 非法的输入或操作应有足够的提示说明。

c. 由于误操作得到的反馈信息，应该能够指导用户的下一步操作。

16． 数据库的增删改问题

a. 增删改功能可以实现。

b. 增删改时响应时间不能超过5秒。

17． 数据的查询

a. 能够及时查询所需要的数据。

b. 查询响应时间不能超过5秒。

18． 能被主模块调起或调起子模块。

9.1.4. 系统情况及其他

19． 运行单元程序不能产生多个进程(根据系统设计是否可以重入而定)。

20． 代码覆盖率的要求

a. 代码覆盖率大于80％，对于循环、条件语句的覆盖率要达到100％。

b. 不能有死循环和永远执行不到的语句。

9.2. 附件二：测试停止标准

9.2.1. 概述

1． 目的

本文档的目的是为软件功能测试、系统测试提供停止标准。

2． 范围

本文档适用于软件项目《》的测试活动。

3． 词汇表

缺陷（Defect）

缺陷是对软件产品预期属性的偏离现象

。

覆盖率（Coverage rate）

语句覆盖率、测试案例执行覆盖率，测试需求覆盖率等的总称。

9.2.2. 软件测试停止标准

1． 软件测试暂停、停止标准

1） 软件系统在进行功能、系统测试时，发现一级错误（大于等于1）、二级错误（大于等于2）暂停测试返回开发。

2） 软件系统经过功能、系统测试，分别达到功能、系统测试停止标准。

3） 软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。

4） 软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。

2． 功能测试停止标准

1） 功能测试案例设计已经通过项目组评审确认

2） 按照功能测试计划完成了功能测试

3） 达到了功能测试计划中关于功能测试所规定的覆盖率的要求

4） 系统达到详细设计定义的各项功能，性能

5） 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准

3． 系统测试停止标准

1） 系统测试案例设计已经通过项目组评审确认

2） 按照系统测试计划完成了系统测试

3） 达到了测试计划中关于系统测试所规定的覆盖率的要求

4） 被测试的系统每千行代码必须发现至少1个错误（不含五级错误）

5） 系统满足需求规格说明书的要求

6） 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准

4． 缺陷修复率标准

一、二级错误修复率应达到100%

三、四级错误修复率应达到95%以上

五级错误修复率应达到60%以上

5． 覆盖率标准

语句覆盖率最低不能小于80%（白盒测试时的语句覆盖率）

测试案例执行覆盖率应达到100%（功能测试案例均以执行）

测试需求执行覆盖率应达到100%（业务测试案例均以执行）

9.3. 附件三：错误级别

一级：不能完全满足系统要求，基本功能未完全实现；系统崩溃或挂起等导致系统不能继续运行。

包括以下各种错误：

1） 由于程序所引起的死机,非法退出

2） 死循环

3） 数据库发生死锁

4） 因错误操作导致的程序中断

5） 功能错误

6） 与数据库连接错误

7） 数据通讯错误

二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。

包括以下各种错误：

1） 程序接口错误

2） 因错误操作迫使程序中断

3） 系统可被执行，但操作功能无法执行（含指令）

4） 单项操作功能可被执行，但在此功能中某些小功能（含指令参数的使用）无法被执行（对系统非致命的）

5） 在小功能项的某些项目（选项）使用无效（对系统非致命的）

6） 业务流程不正确

7） 功能实现不完整，如删除时没有考虑数据关联

8） 功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现

9） 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误）

三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。

包括以下各种错误：

1） 操作界面错误（包括数据窗口内列名定义、含义是否一致）

2） 打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误）

3） 简单的输入限制未放在前台进行控制

4） 删除操作未给出提示

5） 已被捕捉的系统崩溃，不影响继续操作

6） 虽然正确性不受影响，但系统性能和响应时间受到影响

7） 不能定位焦点或定位有误，影响功能实现

8） 显示不正确但输出正确

9） 增删改功能，在本界面不能实现，但在另一界面可以补充实现。

四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题

包括以下各种错误：

1） 界面不规范

2） 辅助说明描述不清楚

3） 输入输出不规范

4） 长时间操作未给用户提示

5） 提示窗口文字未采用行业术语

6） 可输入区域和只读区域没有明显的区分标志

7） 必填项与非必填项应加以区别

8） 滚动条无效

9） 键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字段，在不同界面支持不同的快捷方式

10） 界面不能及时刷新，影响功能实现

五级：其他错误。

1） 光标跳转设置不好，鼠标（光标）定位错误

2） 一些建议性问题

9.4. 附件四：测试工作流程

1． 测试工作总体流程

2． 集成/功能/系统测试工作流程

9.5. 附件五：案例编写要点

9.5.1. 目的

确立测试案例编写的要点，以保证使用最有效的测试案例，保证测试质量。

9.5.2. 范围

适用于《》产品的业务流程、功能测试测试案例的编写。

9.5.3. 术语解释

测试分析：对重要业务、重要流程进行测试前的分析。

业务流程测试案例：关于产品业务、重要流程的测试案例。

9.5.4. 业务流程测试案例编写原则

✧ 系统性

对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；

对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；

✧ 连贯性

对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；

对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；

9.5.5. 测试案例设计的方法

5.1 等价类划分法

确定等价类的原则

● 如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

● 如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，此时可确立一个有效等价类和一个无效等价类；

● 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类；

● 如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合；

● 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则）。

● 如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。

测试案例的选择原则

● 为每一个等价类规定一个唯一的编号；

● 设计一个新的测试案例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类都被覆盖过；

● 设计一个新的测试案例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直至所有的无效等价类都被覆盖为止。

5.2 边界值分析法

测试案例的选择原则

● 如果输入了条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个边界范围的值作为测试输入数据；

● 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据；

● 根据规格说明的每个输出条件，使用前面的原则；

● 如果程序的规格说明给出的输入输出域是有序集合，则应选取集合的每一个元素和最后一个元素作为测试用列；

● 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试案例；

● 分析规格说明，找出其他可能的边界条件。

边界条件是指软件计划的操作界限所在的边缘条件。

如果软件测试问题包含确定的边界,那么数据类型可能是：

数值 速度 字符 地址 位置 尺寸数量

同时,考虑这些类型的下述特征：

✧ 第一个/最后一个 最小值/最大值

✧ 开始/完成 超过/在内

✧ 空/满 最短/最长

✧ 最慢/最快 最早/最迟

✧ 最大/最小 最高/最低

✧ 相邻/最远

◆越界测试

✧ 通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:

✧ 第一个减1/最后一个加1

✧ 开始减1/完成加1

✧ 空了再减/满了再加

✧ 慢上加慢/快上加快

✧ 最大数加1/最小数减1

✧ 最小值减1/最大值加1

✧ 刚好超过/刚好在内

✧ 短了再短/长了再长

✧ 早了更早/晚了更晚

✧ 最高加1/最低减1

另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.

9.5.6. 测试案例设计的原则

✧ 6.1 全面性

● 应尽可能覆盖程序的各种路径

● 应考虑存在跨年、跨月的数据

● 大量数据并发测试的准备

✧ 6.2 正确性

● 输入界面后的数据应与测试文档所记录的数据一致

● 预期结果应与测试数据发生的业务吻合

✧ 6.3 符合正常业务惯例

● 测试数据应符合用户实际工作业务流程

● 兼顾各种业务变化的可能

✧ 6.4 仿真性

● 人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。

✧ 6.5 可操作性

● 测试案例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

9.5.7. 测试案例优先级

优先级由需求组根据业务确定

测试案例优先级

描 述

A

重要的模块功能和业务流程

B

比较重要的模块功能和业务流程

C

次重要的模块功能和业务流程

D

不重要的模块功能和业务流程

E

系统小单元、系统容错功能

对于A、B 级应重点考虑

本文来源：https://www.2haoxitong.net/k/doc/687ec864783e0912a2162a52.html

《存储转发机制优化系统测试方案及案例.doc》
将本文的Word文档下载到电脑，方便收藏和打印
推荐度：
点击下载文档

文档为doc格式
相
关
案
例

相关推荐

推荐内容

我看冯仑的《野蛮生长》 《神奇的符号》读后感范文 渤海银行：年收益率14.85% 扶贫路上见初心：驻村干部的暖心故事 渤海银行股份有限公司法人-李伏安投资任职及风险报告 司法部人民调解案例格式 体验乡村生活 龙须树的养殖方法 交通事故办案小结精选 最新-禁毒宣传材料 精品
网站内容来自网络，如有侵权请联系我们，立即删除！ Copyright © 范文写作网京ICP备16605803号