工行个人消费信贷项目软件测试计划的相关参考范文，工行个人消费信贷项目软件测试计划本文关键词：工行，消费信贷，测试，计划，项目工行个人消费信贷项目软件测试计划本文简介：工行个贷项目工行个贷项目系统测试计划系统测试计划((文档编号文......
工行个人消费信贷项目软件测试计划 本文关键词：工行，消费信贷，测试，计划，项目
工行个人消费信贷项目软件测试计划 本文简介：工行个贷项目工行个贷项目系统测试计划系统测试计划((文档编号文档编号: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．其他性错误：造成用户不便且不影响功能的错误。
八、八、
各个测试项的详细说明各个测试项的详细说明
参见系统测试报告
九、九、
局限性局限性
系统测试仅仅是在尽可能真实的环境下进行的测试，而且测试的内容只局限于功能性的测试，对系统的性能并未做任何测试。