一级XXXX枢纽
存储转发机制优化系统测试报告
Project Name:
|
| ||
Document Version No:
|
1.0
|
Document Version Date:
|
2005-08-16
|
Prepared By:
|
|
Preparation Date:
|
2005-08-16
|
Reviewed By:
|
|
Review Date:
|
|
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)
Ver. No.
|
Ver. Date
|
Revised By
|
Description
|
Filename
|
1.0
|
2005-08-26
|
黄锡波
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
版 权 说 明
目录
本报告是《一级BOSS系统的存储转发机制优化系统》测试报告,主要描述功能测试和系统测试方面,压力测试作为专题在另外的压力测试报告中描述(详见《压力测试报告(存储转发机制优化系统).doc》)。
编写系统功能测试报告的目的是:把测试的完成的情况写成文档,并对测试结果进行简要分析,为纠正软件的缺陷提供依据,也为软件验收和交付打下基础。
测试阶段
|
测试任务
|
工作量估计
(
人日)
|
人员分配
|
开始时间
|
截止时间
|
完成状态
|
第一阶段
|
方案设计、案例设计
|
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
|
√
| |
测试环境、数据确认
|
1
|
|
2005-08-22
|
2005-08-22
|
√
| |
第二阶段
|
测试:
正常情况(案例8个)
系统测试(案例1个)
压力测试(?)
|
3
|
|
2005-08-23
|
2005-08-25
|
√
|
补充案例/完善案例
|
/
|
|
/
|
/
|
/
| |
补充测试
|
/
|
|
/
|
/
|
/
| |
第三阶段
|
回归测试/完善案例
|
/
|
|
/
|
/
|
/
|
测试内容主要是功能测试和系统测试方面。
从测试切面看,主要有两个切面的测试,一是:参数定义后,在实际运行中的表现,即是不是按照所定义的参数正确运作? 二是:存储转发是否满足三个原则?
系统需要满足的三个原则是:
² 第一个原则是高优先级的先捞先发原则;
² 第二个原则是时间优先原则,同一个优先级的记录是时间优先,即先到先发;
² 第三个原则是落地方的处理承受原则,即可以调整落地方一次可以接收处理saf数据的能力。
功能和系统测试的八个案例就是根据参数定义和三个原则来设计案例的。
三个原则的测试主要有:
² 一次捞saf记录的条数,落地方一次所承受的接收的记录数,按照优先级别从高到低及时间优先的原则发送。
参数测试主要有三个:
² 不同线程的不同扫描间隔时间;
² 线程落地关系表的stopflag标志;
² 落地方与某个线程的对应关系。
测试案例执行的目标是:
服务器操作系统: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
1.6. 参考资料
《存储转发机制优化概要设计_v1.3.doc》
《一级BOSS抗容功能规格说明书》
《存储转发机制优化系统测试方案及案例.doc》
基本测试是采用了单一案例测试,一个功能由一个到多个案例组成。
基本测试案例见下表:
案例代码
|
案例名称
|
简要描述
|
备注
|
SAF_PV0001
|
参数设置
|
下列参数设置后,验证系统是否正确读取参数设置,并按照设定的参数运行。
SAF_DISPATCHERS
(SAF线程定义表)定义数据:INTERVAL=5000ms(间隔时间)
SAF_DISP_PARTIES
(线程-落地方关系定义表):STOP_FLAG=Y/N
SAF_DISP_PARTIES
(线程-落地方关系定义表):HPARTY_ID落地方机构码与某线程对应
|
|
SAF_PV0002
|
优先级
|
验证系统是否按照优先级(从高到低)运行?中心是否按照设定的落地方接收处理能力来发送saf数据?中心一次捞saf数据的记录数是否正确?中心是否按照设定的间隔时间来循环捞saf数据?中心有没有重复发送数据的现象?定义好线程名与落地方的对应关系在实际运行中是否正确?
|
|
SAF_PV0003
|
SAF
线程定义表
|
中心是否按照设定的落地方接收处理能力来发送saf数据?定义好线程名与落地方的对应关系在实际运行中是否正确?
|
|
SAF_PV0004
|
SAF
分发线程组模块
|
验证StartsSAFWorkers是否可以控制重入
验证SAF_Worker是否可以控制重入
|
|
SAF_PV0005
|
WorkStart
日切表现
|
验证日切前、正在日切中、日切完成状态时,WorkStart是否正确
|
|
SAF_PV0006
|
WorkStart
特殊条件处理
|
验证WorkStart在特殊条件下处理:
若发送个数为0,则不取SAF交易,继续循环
若落地方个数为0,则不取SAF交易,继续循环
|
|
SAF_PV0007
|
SAF
监控器
|
验证监控SAW Worker thread线程的死活状态,线程死掉后是否自动重起?
|
|
SAF_PV0008
|
日对帐,月对帐
|
日对帐,月对帐单后是否在SAF中?并是否正确发送?
|
|
案例数量
|
Bug
(Defect)数量
|
错误率
|
质量评估
|
备注
|
8
|
7
|
88%
|
差
|
工业测试标准:
优秀<=30%
良好<=40%
中<=60%
差>60%
|
文档与实现类
错误数量
|
参数类错误数量
|
关键实现类错误数量
|
管理类错误数量
|
质量评估
|
备注
|
2
占总错误数的29%
|
1
占总错误数的14%
|
2
占总错误数的29%
|
2
占总错误数的29%
|
中
|
各类型的错误都有且比较均匀
|
一级错误数量
|
二级错误数量
|
三级错误数量
|
四级错误数量
|
质量评估
|
备注
|
3
占总错误数的43%
|
2
占总错误数的29%
|
2
占总错误数的29%
|
0
|
差
|
工业测试标准:
(
一级错误算)
优秀<=5%
良好<=10%
中<=15%
差>15%
|
错误级别的定义请阅读《存储转发机制优化系统测试方案及案例.doc》
|
0.5
小时内解决错误数量
|
1
小时内解决错误数量
|
半天内解决错误数量
|
1
天内解决错误数量
|
质量评估
|
备注
|
4
占总错误数的80%
|
1
占总错误数的20%
|
0
|
0
|
优秀
|
有2个是文档缺陷不计算在内
|
Bug
代码
|
已经解决并验证
|
已经解决未验证
|
未解决
|
备注
|
87
|
●
|
|
|
|
88
|
|
|
●
|
设计文档修改
|
89
|
●
|
|
|
|
90
|
|
|
●
|
设计文档修改
|
91
|
|
●
|
|
|
92
|
●
|
|
|
|
93
|
●
|
|
|
|
合计: 7
|
4
|
1
|
2
|
|
Bug
代码及其描述请阅读StartTeam
|
(无)
(无)
(无)
经过基本的功能及系统测试案例分析,结合测试执行状况,结论是:功能测试覆盖率是全面的,测试是充分的。
存储转发机制优化系统,经过基本的功能及系统测试,证实该系统构造灵活,反应速度快速,中心存储转发交易的频率很好地适应落地方的处理能力,非常方便地可以为交易设定优先级,使重要交易优先发送。
软件的缺陷率较高(错误率88%),但解决错误的速度非常快(80%是在0.5小时内解决)。
1)
加强设计文档与开发实现的资料同步,避免设计文档版本与开发实现版本脱节现象;
2)
设计团队、开发团队及测试团队充分沟通,协调一致,避免毫无意义的重复开发重复测试工作,提高效率;
3)
加强版本控制;
4)
加强单元测试,开发人员必要时对重要算法、复杂实现事先准备些单元测试案例并落实执行单元测试,必要时也应考虑实行review程序员写的代码。这样可以早点把可能引起大麻烦的事件消杀在萌芽中。
4.1.