工行个人消费信贷项目软件配置项计划清单 本文关键词：工行，清单，消费信贷，配置，计划
工行个人消费信贷项目软件配置项计划清单 本文简介：中富证券项目软件配置项计划清单中富证券项目软件配置项计划清单（文档编号：DW-HYZQ-27-03-001）方正奥德计算机系统有限公司二00二年七月2文档管理信息表主题：软件配置项计划清单版本：1.0.0内容：软件配置项计划清单----详细内容关键字参考文档：提交时间：2002年10月10日创建人：
工行个人消费信贷项目软件配置项计划清单 本文内容：
中富证券项目软件配置项计划清单
中富证券项目
软件配置项计划清单
（文档编号：DW-HYZQ-27-03-001）
方正奥德计算机系统有限公司
二00二年七月
2
文档管理信息表
主题：
软件配置项计划清单
版本：
1.0.0
内容：
软件配置项计划清单----详细内容
关键字
参考文档：
提交时间：
2002年10月10日
创建人：
杜
磊
文档修改记录表
修改人
修改时间
修改内容
软件配置项计划清单
时
间：
2002/10
编
号：
001
配置项名称
标
识
计划进入基线库的情况
时
间
开发者
软件开发计划
DW-HYZQ-19-01-001
2002年09月07
杜磊
软件开发质量计划
DW-HYZQ-20-01-001
2002年09月10
杜磊
软件开发计划评审表
DW-HYZQ-32-02-001
2002年09月12
杜磊
软件开发质量计划评审表
DW-HYZQ-32-02-002
2002年09月13
杜磊
软件需求分析说明书Version1.0
DW-HYZQ-21-01-001
2002年09月20日
杜磊
软件需求说明书评审表
DW-HYZQ-32-02-003
2002年9月22日
杜磊
软件设计说明书
DW-HYZQ-22-02-001
2002年09月25日
杜磊
软件设计说明书评审表
DW-HYZQ-32-02-004
2002年09月30日
杜磊
软件配置管理计划
DW-HYZQ-27-02-001
2002年09月15日
杜磊
软件配置管理计划评审表
DW-HYZQ-32-02-009
2002年10月20日
杜磊
软件配置项计划清单
DW-HYZQ-27-03-001
2002年10月25日
杜磊
软件配置项实际清单
DW-HYZQ-27-04-001
2002年11月16日
杜磊
软件编码计划
DW-HYZQ-23-01-001
2002年11月16日
杜磊
编码工作计划评审表
DW-HYZQ-32-02-005
2002年11月16日
杜磊
代码抽查验证表
DW-HYZQ-23-02-001
2002年11月20日
杜磊
代码完成情况表
DW-HYZQ-23-03-001
2002年11月10日
杜磊
软件测试计划
DW-HYZQ-24-01-001
2002年11月25日
杜磊
软件测试计划审核表
DW-HYZQ-32-02-006
2002年11月26日
杜磊
软件测试大纲
DW-HYZQ-24-02-001
2002年11月26日
杜磊
软件测试大纲审核表
DW-HYZQ-32-02-007
2002年11月26日
杜磊
软件测试记录表
DW-HYZQ-24-03-001
2002年11月26日
杜磊
软件测试问题纪录表
DW-HYZQ-24-04-001
2002年11月26日
杜磊
软件模块测试记录表
DW-HYZQ-24-05-001
2002年11月27
杜磊、项目成员
软件模块测试报告
DW-HYZQ-24-06-001
2002年11月28
杜磊、项目成员
软件系统测试报告
DW-HYZQ-24-07-001
2002年11月28
杜磊、项目成员
模块测试通过标准
DW-HYZQ-24-06-001
2002年11月28
杜磊、项目成员
系统测试通过标准
DW-HYZQ-24-09-001
2002年11月28
杜磊、项目成员
软件过程度量报告
DW-HYZQ-29-02-001
2002年11月28
杜磊、项目成员
项目进展周报汇总
DW-HYZQ-19-02-001
2002年11月29日
杜磊
工具软件选用申请表
DW-HYZQ-31-01-001
2002年11月28
杜磊、项目成员
工具软件使用纪录
DW-HYZQ-31-02-001
2002年11月28
杜磊、项目成员
工具技术评价表
DW-HYZQ-31-03-001
2002年11月28
杜磊、项目成员
用户手册验证评审表
DW-HYZQ-32-02-006
2002年11月28
杜磊、项目成员
编码规范评审表
DW-HYZQ-32-02-005
2002年11月28
杜磊、项目成员
数据库服务器
Oracle
8.05
银行提供
中间件服务器
WEBSPHERE
3.5
银行提供
程序编辑器
UltraEdit-32
银行提供
压力测试工具
E_TEST
银行提供
Java程序编译包
Java1.3.1
银行提供
模块程序开发
详见“项目进度”计划进度表。
篇2：工行个人消费信贷项目软件开发质量计划
工行个人消费信贷项目软件开发质量计划 本文关键词：工行，消费信贷，质量，计划，项目
工行个人消费信贷项目软件开发质量计划 本文简介：软件质量计划软件质量计划（文档编号：（文档编号：DW-ZFZQ-01-001DW-ZFZQ-01-001））方正奥德计算机系统有限公司方正奥德计算机系统有限公司20022002年年99月月软件质量计划I文档管理信息表文档管理信息表主题：主题：质量计划版本：版本：1．0.0内容：内容：关于个贷总行移植
工行个人消费信贷项目软件开发质量计划 本文内容：
软件质量计划软件质量计划
（文档编号：（文档编号：DW-ZFZQ-01-001DW-ZFZQ-01-001））
方正奥德计算机系统有限公司方正奥德计算机系统有限公司
20022002
年年
9
9
月月
软件质量计划
I
文档管理信息表文档管理信息表
主题：主题：质量计划
版本：版本：1．0.0
内容：内容：关于个贷总行移植质量的计划
关键字关键字
参考文档：参考文档：
提交时间：提交时间：2002
年
11
月
29
日
创建人：创建人：刘军伟
文档修改记录表文档修改记录表
修改人修改人修改时间修改时间修改内容修改内容
软件质量计划
I
目目
录录
1
1、、
产品的质量目标产品的质量目标1
2
2、、
质量保证措施质量保证措施1
2.1、设计过程质量保证措施
1
2.1.1、实际和开发的策划1
2.1.2、组织和技术接口设计1
2.1.3、设计输入和输出及验收准则2
2.1.4、设计评审3
2.1.5、设计验证4
2.1.6、设计确认4
2.1.7、设计更改4
2.1.8、病毒防治4
2.2、测试过程质量保证措施
5
2.2.1、测试阶段5
2.2.2、测试规范5
2.2.3、测试要求5
2.2.4、质量记录5
2.2.5、其它5
2.3、维护过程质量保证措施
5
2.3.1、维护要求5
2.3.2、质量记录6
3
3、、
风险控制风险控制6
4
4、、
质量保证活动的职责和权限质量保证活动的职责和权限9
软件质量计划
1
1
1、、
产品的质量目标产品的质量目标
系统的接收标准为用户接收的
UAT
测试报告，
系统测试报告和模块测试报
告。产品的质量目标为：
1.UAT
测试中，
系统的功能要求和效率要求满足合同要求和需求规格说明
书要求。
2.在模块测试和系统测试中，没有影响系统运行的严重
BUG,属于实现形式、
操作形式上的
BUG
应该低于
1
个/千行；
3.已发现
BUG
的修改率为
95%；
4.系统的接收时间与合同时间的差异小于
1
个月。
2
2、、
质量保证措施质量保证措施
按照公司的质量管理体系以及部门的质量管理规范，在需求分析、软件设
计、软件实现、软件测试和售后服务等各个阶段，应有严格的质量保证措施。
具体划分为如下阶段：
2.12.1、、设计过程质量保证措施设计过程质量保证措施
2.1.12.1.1、、
实际和开发的策划实际和开发的策划
在《开发计划》中对需求分析、软件设计、软件实现、软件测试和测试状
态及软件发布等几个开发阶段进行了策划，并将各个阶段的活动配备了相应的
资源，保证落实到有资格的开发人员，而且开发人员基本上划分了相应的职责。
2.1.22.1.2、、
组织和技术接口设计组织和技术接口设计
开发实施过程遵循公司质量体系规范,在开发实施每个阶段由项目经理提交
软件质量计划
2
阶段性成果记录,部门秘书向相关部门传递成果记录,由相关部门进行评审。组
织接口有：项目推进部（提供项目建议书、合同、立项报告；接收并审核开发
计划）
；商务管理部（接收并审核开发计划、质量计划、需求分析、设计分析、
测试计划等程序文件要求商务管理部审核的阶段性控制资料）
；总裁办公室（发
版审核等）
。
2.1.32.1.3、、
设计输入和输出及验收准则设计输入和输出及验收准则
开发阶段阶段输入阶段输出验收准则进入
下一
阶段
要求
需求分析项目合同书（要求评审）
、软
件开发计划（要求评审）
、软
件质量计划（要求评审）
、
《经营性网站备案登记管理
暂行办法》
、
《合同评审记录
表》
需求分析说明
书（要求评审）
功能范围描述全面无
落漏；
功能描述做到明确无
歧义；
满足输入条件。
通过
验收
准则
通过
评审
软件设计需求分析说明书（要求评审）
软件质量计划（要求评审）
、
软件开发计划（要求评审）
软件设计说明
书（要求评审
代码模块划分及输入
输出关系明确；算法
明确；符合需求说明
书的功能、性能要求；
满足输入条件。
通过
验收
准则
通过
评审
编码实现软件质量计划、软件设计说
明书
系统代码（要
求评审）
、
软件测试计划
（要求评审）
、
代码抽查验证
表（要求评审）
编码严格遵守详细设
计，
必要的调整必
须写入备忘录；遵守
编码规范；满足输入
条件。
通过
验收
准则
通过
评审
软件测试
和测试状
态
系统编码、软件测试计划、
软件质量计划、测试大纲、
模块测试通过标准、系统测
试通过标准
模块测试报告
（要求审批）
、
系统测试报告
（要求审批）
功能实现测试，
需
求说明中的功能全部
实现；性能测试满足
预期用户的访问效率
要求；满足输入条件。
通过
验收
准则
通过
评审
软件发布
确认
需求分析说明书、软件设计
说明书、用户手册、测试大
纲、测试报告、软件原码、
软件母盘
用户接受报告UAT
测试报告满足
用户确认系统功能和
性能满足需求；满足
输入条件。
通过
验收
准则
通过
评审
软件质量计划
3
软件质量计划
4
2.1.42.1.4、、
设计评审设计评审
开发阶段时间会议内容人员
软件需求分析评审
2002/9/1
讨论需求分析设
计情况，
审查
需求分析说明书；
用户签字；
总控组;
项目经理;
客户代表;
系统设计总结2002/9/20总结软件设计情
况，审查设计说
明书
总控组;
项目经理;
编码实现总结2002/9/25总结编码实现情
况，
审查编码
计划，
代码抽
查验证表，代码
完成情况表
总控组;
项目经理;
开发人员;
软件测试总结2002/11/5总结模块测试,系
统测试情况。审
查模块测试报告，
系统测试报告
总控组;
项目经理;
开发人员;
测试人员;
系统发布准备2002/12/6讨论系统发布的
准备工作；审查
发布有关文档，
包括：需求分析
说明书、设计说
明书，
开发计
划，
发布母盘，
用户手册，
测
试报告。
总控组;
项目经理;
开发人员;
测试人员;
系统发布总结2002/12/14反馈系统发布后
情况。审查用户
反馈意见，
用
户问题提出表。
总控组;
项目经理;
开发人员;
测试人员;
（会议记录记录入《评审会议记录》
）
2.1.52.1.5、、
设计验证设计验证
验证包括：需求分析验证、软件设计验证、软件实现验证和软件测试验证
软件质量计划
5
四个部分。
（验证记录记录入《评审会议记录表》和相关审批表）
2.1.62.1.6、、
设计确认设计确认
通过验证之后即可确认。
（确认结果记录入《评审会议记录》
）
2.1.72.1.7、、
设计更改设计更改
所有更改需要经过授权人员确认，并且记录入设计更改文档。注意：不能
在原有文档基础上直接更改。
2.1.82.1.8、、
病毒防治病毒防治
在开发过程中,要做好病毒防治措施,具体有：
1）
开发环境不允许进行网络数据下载；
2）
开发中使用的磁盘媒体要求为未格式化的软盘，
格式化后由项目经理统一
管理使用；
3）
采用正版工具；
4）定期进行系统查毒。
2.22.2、、测试过程质量保证措施测试过程质量保证措施
2.2.12.2.1、、
测试阶段测试阶段
测试包括单元测试、模块测试、系统测试、压力测试和
UAT
测试四个
阶段。
软件质量计划
6
2.2.22.2.2、、
测试规范测试规范
测试规范可以参见《软件测试大纲》
。
2.2.32.2.3、、
测试要求测试要求
测试过程中应合理运用各种测试方法，通过黑盒测试，验证模块接口
和功能的实现；通过白盒测试，验证关键算法的实现科学性。
测试遵循典型性和覆盖性原则。
2.2.42.2.4、、
质量记录质量记录
记录入《测试大纲》
、
《测试报告》和相应审批表中。
2.2.52.2.5、、
其它其它
有关策划、评审、验证、确认等部分的内容可以参见
“设计过程质量保证
措施”
。
2.32.3、、维护过程质量保证措施维护过程质量保证措施
2.3.12.3.1、、
维护要求维护要求
维护过程要在与客户方达成一致的基础上，保持对服务的实施、验证
和报告的形成文件的程序。
2.3.22.3.2、、
质量记录质量记录
在项目过程中形成质量记录文件包括：
《DW-ZFZQ-28-03-001
质量记录清单.doc》
《DW-ZFZQ-31-01-001
工具软件选用申请表.doc》
软件质量计划
7
《DW-ZFZQ-31-02-001
工具软件使用纪录.doc》等。
3
3、、
风险控制风险控制
系统面临的主要风险和控制策略有：
1技术风险
在技术方案中存在如下的技术问题:
1)系统中对加密和数字签名技术的使用目前为初次使用,需要对加密
和数字签名技术在系统实现中的位置和使用方法作更加慎重考虑和
方案分析。
控制策略：郑武林负责分析整个网站应用系统中加密、数字签名的
应用分析，
决定实现策略，
并结合公司在安全方面人才对安全策
略和实现方法进行重点分析评价。保证安全和加密方案可行、可实
现性好。
风险指数：*****，
该项风险影响系统的可用性。
2)对
WLCS
中各种元素的配置优化。
尽管公司有人员参与了
Weblogic
的培训，
但是在
WLCS
上没有应
用经验，
对
WLCS
提供的调用接口没有很好的应用实践，对可用
资源没有很好的了解,将影响系统开发的复杂性、高效性和可维护性。
控制策略：由刘军伟、刘波、梁伦发、马建军、战乃国对
WLCS
的
调用接口和元素，
参照技术手册和技术支持，
进一步分析，
提
出商业逻辑开发可供依赖的平台支持接口。
风险指数：****，
该项风险影响系统的开发周期和系统可维护性
和高效性。
3）数据库
ORACLE
的使用
在开发梯队中，
对
ORACLE
应用缺少具有成熟经验的数据库系统
设计分析人员，
如何设计高效合理的数据库对系统效率和系统的可维护性有重
要意义。
软件质量计划
8
控制策略：由电子商务部中
ORACLE
熟悉的人员对系统数据库的设
计进行质疑和咨询，
特别是从数据效率、数据一致性、数据冗余、数据挖掘和
分析等方面。
风险指数：**
，
该项风险涉及到系统的效率、可维护性、可实现
性。
4）JAVA
编程技术
在开发梯队大多数开发人员的
JAVA
开发经验并不是很长。在开发队伍
中，
不可避免地存在一些编码设计繁杂等问题。
控制策略：开发人员对于复杂和效率相关的代码，必须进行适当注释，
便于检查；在开发初期，
增加代码抽查的次数，
便于及时发现问题。
风险指数：**
，
该项风险影响到系统的可靠性、高效性。
2需求风险
需求风险是该项目的最大风险之一。其主要原因是：
（1）用户需求不是很成熟。
用户需求中存在若干不成熟的业务思想。
控制策略：用户需求提出代表要严格要求。
（2）用户界面复杂，
需求难于一致。
所有功能的实现方法和实现形式，
不同的需求主题有不同的要求。
例如论坛、聊天室、采编对权限管理的需求。
控制策略：用户需求提出人员经过授权应该确定，
不应变化。
（3）业务关系较复杂，
业务关系需要跨模块进行考虑。
需求关系在各个系统之间由交叉。业务需求需要跨系统进行考虑。
控制策略：需要在各个系统之外，
安排需求分析人员对系统之间
的交叉需求进行分析。
并且，
为了保证需求的准确、全面和系统化，
应该组织多次的会议交
流和讨论，
及时发现需求分析中的偏差。
该项风险指数：*****
该项风险影响到系统实现工期、项目成本。
软件质量计划
9
3设计风险
设计中存在的风险主要有：
（1）由于系统总体方案中结构不合理，
如数据库分布形式，
各个系统之
间的关系。该种风险将影响到系统的可实现性、系统的安全性和可维
护性。
控制策略：
对整体方案的总体结构进行深入分析和讨论。
（2）代码单元的接口设计和代码共享
控制策略：代码单元的接口设计明确，
代码单元功能复杂性适度，
在各个系统之间、系统内部之间建立代码共享，该项控制策略能够有
效减少系统实现的复杂性。
风险指数：**
该项能够有效减少系统实现复杂度，
减少系统实现
工期，
提高系统可维护性。
4进度控制风险
及时检查模块进度与出现的问题，与客户积极协商，保证项目进展
顺利。如果用户需求更改需要及时调整项目实施时间。
4
4、、
质量保证活动的职责和权限质量保证活动的职责和权限
人员职责权限
杜磊项目经理负责项目总体设计、组织、协调、控制和支持。
徐加星技术经理，质控经理负责系统设计及质量监控指导。
王俊山软件工程师负责程序开发
倪勇飙软件工程师负责程序开发
篇3：工行个人消费信贷项目软件测试计划
工行个人消费信贷项目软件测试计划 本文关键词：工行，消费信贷，测试，计划，项目
工行个人消费信贷项目软件测试计划 本文简介：工行个贷项目工行个贷项目系统测试计划系统测试计划((文档编号文档编号:FO-HYZQ-24-01-001):FO-HYZQ-24-01-001)方正奥德计算机系统有限公司方正奥德计算机系统有限公司20022002年年1111月月文档管理信息表文档管理信息表主题：主题：系统测试计划版本：版本：1．0.
工行个人消费信贷项目软件测试计划 本文内容：
工行个贷项目工行个贷项目
系统测试计划系统测试计划
(
(文档编号文档编号:FO-HYZQ-24-01-001):FO-HYZQ-24-01-001)
方正奥德计算机系统有限公司方正奥德计算机系统有限公司
20022002
年年
1111
月月
文档管理信息表文档管理信息表
主题：主题：系统测试计划
版本：版本：1．0.0
内容：内容：工行个贷系统测试计划
关键字：关键字：
参考文档：参考文档：
提交时间：提交时间：2002
年
11
月
29
日
创建人：创建人：倪勇飚
文档修改记录表文档修改记录表
修改人修改人修改时间修改时间修改内容修改内容
I
宏源证券项目系统测试计划
目目
录录
一、一、
概述概述1
二、二、
引言引言3
1、编制目的
3
2、术语说明
3
三、三、
测试环境测试环境3
四、四、
测试人员组织测试人员组织4
五、五、
项目描述项目描述4
六、六、
测试功能（业务）列表测试功能（业务）列表8
七、七、
开始测试标准开始测试标准9
八、八、
结束测试标准（项目提交标准）结束测试标准（项目提交标准）9
九、九、
各个测试项的详细说明各个测试项的详细说明10
十、十、局限性局限性.10
1
宏源证券项目系统测试计划
一、一、
概述概述
规定测试活动中的任务、测试方法、进度、资源和人员职责等。
1
1、、
测试方法测试方法
可以以瀑布型描述软件工程过程，为了说明软件测试测策略，可以把软件工程的过程表达成一个螺旋形。首先，系统工程为软件
开发规定了任务，从而把他和硬件要完成的工作分开。接着便是进行软件需求分析，决定被开发软件的信息域、功能、性能、限制条
件并确定该软件项目完成后的确认准则。沿着螺旋形向内旋转，将进入软件设计和代码编写阶段。从而使得软件开发工作从抽象逐步
走向具体化。
C
U
I
V
ST
D
R
S
软件需求
分析
系统工程
软件设计
代码编写
系统测试
确认测试
组装测试
单元测试
2
宏源证券项目系统测试计划
软件测试工作也可以从这一螺旋线上体现出来。在螺线的核心点针对每个单元的源代码，进行单元测试。在各单元测试完成之后，
沿螺线向外前进，开始针对软件整体构造和设计的组装测试。然后是检验软件需求是否得到满足的确认测试，最后，来到螺线的最外
层，把软件和系统的其它部分协调起来，当作一个整体完成系统测试。这样，沿着螺旋线，从内向外，逐步扩展了测试的范围。
以上用螺旋线表明的测试过程，按四个步骤进行，即单元测试、组装测试、确认测试和系统测试。
确认
的软
件
集成
的软
件
设计
信息
模块
单元
测试
模块
单元
测试
模块
单元
测试
模块
单元
测试
组装测试确认测试系统测试
软件
需求
其它
系统
元素
已测
模块
3
宏源证券项目系统测试计划
开始分别完成每个单元的测试任务，以确保每个模块能正常工作。单元测试大量采用了白盒测试方法。尽可能发现模块内部的程
序查错。然后，把已测试的模块组装起来，进行组装测试。其目的在于检测与软件设计相关的程序结构问题。这时较多地采用黑盒方
法来设计测试用例。完成组装测试之后，要对开发工作初期制定的确认准则进行检验。确认测试是使所开发的软件能否满足所有功能
和性能需求的最后保证手段，通常采用黑盒测试方法。完成确认测试之后，给出的应该是合格的软件产品，但为检验它能否与系统的
其它部分（如硬件、网络环境、数据库及操作人员）协调工作，需要进行系统测试。
单元测试（Unit
Testing）也称模块测试，这是针对软件测试的最小单位——模块进行正确性检验的测试工作。其目的在于发现各
模块内部可能出现的各种差错。单元测试需要从程序的内部结构出发设计测试用例，即采用所谓白盒测试方法。多个模块可以平行地
独立进行单元测试：
单元测试需要解决的问题
单元测试是要针对每个模块的程序，解决以下五个方面的问题
模块接口——对被测试的模块，信息能否正常无误地流入和流出。
局部数据结构——在模块工作过程中，其内部的数据是否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
边界条件——在为限制数据加工而设置的边界处，模块是否能正常工作。
覆盖条件——模块的运行是否能达到特定的逻辑覆盖。
出错处理——模块工作中发生了错误，其中的出错处理实施是否有效。
4
宏源证券项目系统测试计划
模快与其周围环境的接口有无差错应首先得到检验，否则内部的各种测试工作都是徒劳的。Myers
提供的模块接口验证表是很有
用的以下简要地列出：
模块接受的输入参数个数与模块的变元个数是否一致？
参数与变元的属性是否匹配？
参数与变元所使用的单位是否一致？
传送给另一个被调用模块的变元个数与参数的个数是否相同？
传送给另一个被调用模块的变元属性与参数的属性是否匹配？
传送给另一个被调用模块的变元，其单位是否与参数的单位一致？
调用内部函数时，变元的个数、属性和次序是否正确？
在模块有多个入口的情况下，是否有引用与当前入口无关的参数？
是否会修改只是作为输入值的变元？
出现全程变量时，这些变量是否在所有引用它们的模块中都有相同的定义？
有没有把常数当作变量来传送？
当模块执行了外部的输入、输出时，Myers
提出还需要考虑：
5
宏源证券项目系统测试计划
文件的属性是否正确？
OPEN
语句是否正确？
格式说明与输入、输出语句给出的信息是否一致？
缓冲区的大小是否与记录的大小匹配？
是否所有的文件在使用前均已打开了？
对文件的结束条件的判断和处理是否正确？
对输入、输出错误的处理是否正确？
有没有输出信息的正文错误？
对于局部数据结构应该在单元测试中注意发现以下几类错误：
不正确的或者不相容的说明。
不正确的初始化或者缺省值。
错误的变量名，如拼写错或者缩写错。
不相容的数据类型。
6
宏源证券项目系统测试计划
下溢、上溢或是地址错误。
除局部的数据结构之外，在单元测试中还应该弄清楚全程数据对模块的影响。
如何设计测试用例，使得模块测试能够高效率地发现其中的错误，这是非常关键的问题。无论考虑何种逻辑覆盖都应该注意发现
以下一些典型的计算错误：
对运算优先性的错误理解，或者是错误的处理。
运算方式（mode）未加区分，发生了混合运算的情况。
初始化错误
计算精确度不够。
表达式中符号表示的错误。比较和控制流常常是彼此密切相关的，比较的错误势必导致控制流的错误。
需要特别注意发现的错误包括：
不同的数据类型进行比较
逻辑运算或其优先级用错
本应该相等的数据，由于精确度原因不相等。
变量本省或时比较有错。
7
宏源证券项目系统测试计划
循环终止不正确，或循环不已
在遇到发散的循环时不能摆脱出来。
循环控制变量修改有错。
程序运行中出现了异常现象并不奇怪，良好的设计应预先估计到，将来投入运行后可能发生什么出错的情况，并给出相应的处理
措施，使得用户不至于发生了这样的情况束手无策。检验程序中处理这一问题解决得怎样，可能出现的情况有：
对运行发生的错误描述得难于理解。
指明的错误并非实际遇到的错误。
出错后，尚未进行出错处理便引入系统干预
意外处理不当
提供的错误信息不足，以致无法找到出错的原因。
边界测试通常是单元测试的最后一步，是不容忽视的。实践表明，软件常常在边界地区发生问题。例如，处理
N
维数组的第
N
个元素时很容易出错，循环到最后一次执行循环体时可能出错。这可以利用边值分析方法来设计测试用例，以便发生这类程序错误。
单元测试的步骤
单元测试常常被当作代码编写的附属步骤，也有人把代码编写和单元测试作为一个开发阶段考虑。显然在程序编写完毕了、经过
8
宏源证券项目系统测试计划
复查、确认没有语法错误以后，针对每个程序模块单独进行的测试工作。
由于每个模块在整个软件中并不是孤立的，我们在每个模块进行单元测试时，也不能完全忽视它们和周围模块的相互联系。为模
拟这一联系，在进行单元测试时，需要设置若干辅助测试模块。辅助模块有两种，一种是驱动模块（Driver）,用以模拟被测模块的上
级模块；另一种桩模块（Stub）
，用以模拟被测模块中所调用的模块。
自然驱动模块和桩模块对测试人员来说是一种额外的负担，就是说，虽在单元测试中必须编写这些辅助模块的程序，但却并不作
为最终的软件产品提供给用户。好在这些模块的结构十分简单，模块间接口的全面检验可在组装测试中进行。
组装测试
在每个模块完成单元测试之后，需要按照设计时作出的结构图，把它们联系起来，进行组装测试(Integrated
Testing)。经验不多的
人可能会提出，既然单元测试时已经对所有模块的工作是否正常进行了检验，为什么还要联起来再次进行测试呢？实践表明，一些模
块能够单独地正常工作，并不能保证联结起来也能正常工作，程序在某些局部反应不出来的问题，在全局上很可能暴露出来，影响功
能的发挥。
怎样合理地组织组装测试，这里提供两种不同的方法，即非增式测试和赠式测试。
非增式测试方法是这样进行的：在装配辅助模块的条件下，对所有模块进行个别的单元测试。然后在此基础之上，按程序结构图
将各模块联合起来，把联合后的程序当作一个整体进行测试。
增式测试的做法与非增式测试有所不同。它的集成是逐步实现的，组装测试也是逐步完成的。也可以说它把单元测试和组装测试
9
宏源证券项目系统测试计划
结合起来，一道进行，增式组装测试可按不同的次序实施。因而可以有两种：
自顶向下增式测试是按结构图上自上而下进行的。
自底向上增式测试表示逐步集成和逐步测试的工作是按结构图上自下而上进行的。非增式测试的做法是先分散测试，再集中起来
一次完成组装测试。
2
2、、
测试任务测试任务
测试工作分为单元测试、集成测试和系统测试三个步骤，各阶段测试处理内容如下：
名名
称称处处
理理
内内
容容
单元测试函数级正确性测试
集成测试将各小组的所有模块按照设计要求组装成一个可以独立使用的系统，并对其进
行功能测试
系统测试将所有程序合并成一个完整的系统，并在尽可能接近实际运行环境的测试条件
下，对系统进行功能及性能测试。
《系统测试计划》是针对系统测试阶段的测试方案。
二、二、
测试目标测试目标
本次测试计划书是在个贷移行改造项目组各开发小组经历了源代码编写、测试、嵌入
JSP
工作，基本完成系统编码工作之后，制
10
宏源证券项目系统测试计划
定的对整个系统的两周测试计划。为个贷系统在
12
月
14
日成功上线对整个系统做最后的测试修改。
系统测试分两个阶段：
开发环境中的系统测试。
用户环境中的测试。
开发测试环境尽量模拟系统生产时的真实环境，对系统进行单元测试，组合测试和系统测试。受开发环境的限制，系统硬件环境
和网络环境是同最终系统的运行环境是不一致的。主要完成系统的单元边界测试，功能测试，可用性测试。
并在测试阶段对代码进行
用户测试环境尽量模拟系统生产时的真实环境，对系统进行系统测试。由于整个系统是构建在邮政综合网的广域网基础之上，用
户方提供的测试环境在网络结构上同系统生产环境是不一致的。系统的压力测试，UAT
测试，整体性能测试要在系统最终上线之后
才能实现。
三、三、
测试环境测试环境
1.开发环境中应用软件系统测试环境如下：
?硬件环境：
IBM
44P(16.54.13.96)服务器，充当应用服务器，
11
宏源证券项目系统测试计划
IBM
P670(16.54.13.93)数据库服务器。
?网络环境：100M
局域网的网络环境；
?操作系统环境：
AIX4.03
版；
?测试客户端系统软件：WIN2000，WINDOWS98，InternetExploer5.0,InternetExploer5.5，InternetExploer6.0
?数据库环境：ORACLE
8.1.6
for
Aix；
?应用程序环境：WebSphere
3.5；
?应用数据：测试人员建立的测试数据；
?测试客户端系统软件：WIN2000，WINDOWS98，WINDOWSME，InternetExploer5.0,InternetExploer5.5
2.测试环境中应用软件系统测试环境如下：
44P(16.54.13.96)服务器，充当应用服务器，
670(16.54.13.93)数据库服务器。
?网络环境：100M
局域网的网络环境；
?操作系统环境：
AIX4.03
版；
12
宏源证券项目系统测试计划
?测试客户端系统软件：WIN2000，WINDOWS98，InternetExploer5.0,InternetExploer5.5，InternetExploer6.0
?数据库环境：ORACLE
8.1.6
for
Aix；
?应用程序环境：WebSphere
3.5；
?应用数据：测试人员建立的测试数据；
?测试客户端系统软件：WIN2000，WINDOWS98，WINDOWSME，InternetExploer5.0,InternetExploer5.5
四、四、
测试人员组织测试人员组织
1.测试负责人：杜磊
1)编制系统测试计划，系统测试大纲，制定系统测试通过标准，整理模块测试记录，整理系统测试记录
2)编制系统测试案例
3)参与各系统单元测试、组合测试和系统测试。审核组合测试和系统测试结果。
2.各系统测试组长：杜磊
1)编制本系统中模块单元测试通过标准，协助测试负责人完成系统测试大纲。
13
宏源证券项目系统测试计划
2)编制本系统测试案例
3)参与本系统单元测试、组合测试和系统测试。审核本系统组合测试和系统测试结果。
4)完成本人参与编程部分的软件测试记录文档，审核本系统开发人员单元测试结果。
3.测试组成员：杜磊，徐加星，倪勇飚
1)编制单元测试案例
2)参与本人负责开发的单元测试、以及包括该单元的组合测试和系统测试。
3)完成本人参与编程部分的软件测试记录文档，模块测试记录文档。
1、编码人员测试工作
（1）
准备测试案例
（2）
按测试案例测试程序代码
（3）
形成测试纪录表和问题纪录表
2、非编码人员的工作
（1）
检查测试案例是否充足，是否满足测试需要？
（2）
协助编码人员完成测试案例的准备。
（3）
同编码人员一起完成测试。
14
宏源证券项目系统测试计划
（4）
分工：
3、提醒的问题。
由于工期较紧，若功能单元中未实现的或者欠缺的部分，需要编制针对这些问题的测试案例写入测试案例表中，将问题纪录
到测试问题记录表中。
五、五、
测试日程和测试内容测试日程和测试内容
1.测试进度测试进度：
系统测试计划如下：
开始日期开始日期结束日期结束日期测试内容测试内容
2002/11/212002/11/23开发环境单元测试
2002/11/262002/11/27开发环境组合测试
2002/11/282002/11/29开发环境系统测试
15
宏源证券项目系统测试计划
2.测试内容列表：测试内容列表：
1)单元测试：
业务业务
编号编号
测试内容测试内容测试日期测试日期测试人员测试人员测试起点测试起点测试终点测试终点期望的测试结果期望的测试结果
1客户贷款申请11．21倪勇飚输入客户基本
信息
建立客户贷款申
请书
正常显示
2客户贷款审批11．22倪勇飚申贷员检查客
户贷款申请书
最终审批员审批正常显示
2)组合及系统测试：
业务编业务编
号号
测试内容测试内容测试日期测试日期测试人员测试人员测试起点测试起点测试终点测试终点
2002/11/202002/11/30用户方测试环境组合测试及系统测试，同时进
行测试中出现问题的修改。
16
宏源证券项目系统测试计划
业务编业务编
号号
测试内容测试内容测试日期测试日期测试人员测试人员测试起点测试起点测试终点测试终点
1客户贷款申请11．28杜磊输入客户基本信息
建立客户贷款申请书
2客户贷款审批11．28杜磊申贷员检查客户贷
款申请书
最终审批员审批
17
宏源证券项目系统测试计划
注：详细内容见
系统测试报告
六、六、
开始测试标准开始测试标准
?一般性以上（含一般性）模块已全部完成；
?内部单元（模块）调试已完成
90%；
?系统连接已完成。
七、七、
结束测试标准（项目提交标准）结束测试标准（项目提交标准）
?计划测试案例必须全部完成；
?无已发现的
1，2，3
类错误；
?已发现的
4，5
类错误在各相关部门的允许范围内；
?在规定的时间范围，经过规定的测试后，不出现
1，2，3
类错误；
18
宏源证券项目系统测试计划
错误分类原则说明错误分类原则说明
1．灾难性错误：导致操作系统、数据库系统崩溃；
2．应用系统错误：导致应用系统无法运行；coredump，通讯异常；
3．核心功能错误：导致某种核心功能无法进行；帐务处理，密码校验；
4．一般功能错误：一般性功能出现不频繁的错误；
5．其他性错误：造成用户不便且不影响功能的错误。
八、八、
各个测试项的详细说明各个测试项的详细说明
参见系统测试报告
九、九、
局限性局限性
系统测试仅仅是在尽可能真实的环境下进行的测试，而且测试的内容只局限于功能性的测试，对系统的性能并未做任何测试。