XX银行软件测试规程试用版.docx

XX银行软件测试规程试用版.docx

《XX银行软件测试规程试用版.docx》由会员分享，可在线阅读，更多相关《XX银行软件测试规程试用版.docx（63页珍藏版）》请在冰豆网上搜索。

XX银行软件测试规程试用版

XXXX银行

软件测试规程

（试用版）

XXXX银行信息科技部

2007年3月

第一章前言

一、背景

随着xxxx银行业务规模和种类的迅速发展，银行IT系统的数量和种类不断增加，系统的复杂程度和规模也日益增加。

因此，通过必要的技术和管理手段保证IT系统开发的质量，最终保证上线系统的稳定运行，成为IT系统软件开发的重要工作。

软件测试是保证IT系统软件质量的重要手段。

为了规范XXXX银行IT系统开发中软件测试管理工作，确保开发的IT系统充分满足业务需求，提高IT系统开发的质量，根据软件工程学关于测试管理的理论和方法论，结合我行实际，制定本测试规程。

二、术语定义

●软件测试：

是指通过一定的制度、方法、技术、流程和工具对软件测试对象进行检查、验证和分析，根本目的是验证和确认软件测试对象与需求的一致性，最终保证软件系统的质量。

一个IT系统的软件测试分为单元测试、集成测试、系统测试和压力测试四个阶段进行。

每个阶段的测试依次完成四个子阶段的工作：

计划、设计、实现和执行。

●软件测试对象：

软件测试对象包括程序模块、功能模块和软件系统三个层面。

IT系统软件的最小组成单元是程序模块，功能相关联的一组或多组程序模块通过有机的组合构成实现特定系统功能的功能模块，一个或多个功能模块构成最终完整的软件系统。

●软件测试管理：

是指按照预定义的管理办法，通过一定的流程和工具，对软件测试工作进行有效管理，并对软件测试工作进行审计和状态报告的系统方法。

●单元测试：

完成对程序模块的验证工作，以确认每个程序模块的功能与详细设计相符。

单元测试重点是测试程序模块的功能，以及语句与分支的覆盖率，由此来检验程序模块在各种情况下运行结果都是设计这所预定的结果。

●集成测试：

完成对功能模块的验证工作，以确认各功能模块功能以及功能模块之间的交互功能与概要设计相符，最终形成概要设计中描述的完整的IT系统。

集成测试的重点在于各个功能模块之间的各种接口，测试每个接口在各种情况下都正确，并测试一些预定的非正常输入情况下，处理是否合理有效。

●系统测试（功能测试、综合测试）：

是对整个系统的功能测试，以确认系统各种功能和系统的业务需求书一致。

系统测试的重点是从系统的角度证明系统总体功能的正确性、与关联系统的协调性和时序的准确性。

系统测试还应当确认系统其他的需求也都被满足，如：

可恢复性，可移植性，错误恢复，可维护性等。

●压力测试（性能测试）：

是对整个系统的性能测试，以确认系统符合业务需求部门在交易高峰期间对系统处理能力的要求。

压力测试不同于功能测试，软件的正确性并不是它的测试重点。

它所看重的是软件的执行效率，它以软件响应速度为测试目标，尤其是短时间内访问用户数爆炸性增长时软件的响应速度。

●回退测试：

在以上任何阶段测试中发现问题后，要对有关程序进行相应的修改，修改后还要进行回退测试。

回退测试是指对于一个被测对象（可以是程序模块、功能模块或整个软件系统）不仅要用原来发现其错误的测试案例进行测试，看其结果是否有了变化而且符合要求，还要设计新的测试案例来观察其修改后的功能是否完全正确，同时，还要用原有的其他测试案例来看原先没有修改的功能是否仍然正确。

●测试计划：

是各阶段测试的基础，主要是确定测试的对象、范围；评估测试需要的时间和工作量；明确测试队伍的角色分工、工作任务划分和所需的培训；规划测试资源、工具和数据；定义测试完成标准。

测试计划应该在测试工作执行前的较长时间就开始。

最早的测试计划可以在需求规格说明书完成后开始。

●测试设计：

设计测试方案，主要工作包括对测试对象进行深入分析，确定测试策略、测试方法、测试环境和测试工具，并进一步评估测试的工作量。

●测试实现：

将测试设计的结果转化成可以操作和使用的程序、脚本和测试工具，主要工作包括设计测试案例、测试规则；编写测试代码、测试脚本；落实测试工具。

●测试执行：

在测试环境按照测试案例完成测试是，主要工作包括执行测试案例；记录、分析、解决测试过程中发现的错误，并执行回退测试；评估测试结果，提交测试总结报告。

●软件测试环境：

是指满足软件系统测试要求的硬件、网络和系统软件环境，包括主机、存储、网络、外围设备、操作系统软件、数据库、中间件、系统配置参数和测试用业务数据等。

●软件测试标准：

是指判断各个测试阶段是否可以开始、结束和通过的衡量标准。

软件测试标准包括测试阶段入口条件、测试阶段出口条件和测试阶段通过标准三部分。

●软件测试工具：

是指用于软件系统测试的方法、数据和应用软件系统。

第二章单元测试

一、概述

软件系统的单元测试是对系统基本组成单元进行的测试，以确认每个基本单元的功能与详细设计相符。

这里的基本单元可以是一个具体的函数（function或procedure）（C语言）、一个类的方法（method）（C++）、一个菜单或显示界面（4GL）、一组完成基本功能的函数等。

“单元”具有一些基本属性，如：

明确的功能、规格定义、与其它单元明确的接口定义等，可以清晰地与同一程序的其它单元划分开来。

单元测试除了要检测程序代码的错误外，它的重点在于测试基本单元的功能是否和详细设计的要求一致。

单元测试的主要目的有：

●验证程序代码的功能与详细设计相符；

●跟踪系统需求与设计的实现方式；

●发现系统需求分析和设计中存在的错误；

●发现在编码过程中引入的错误。

●单元测试的工作由程序开发员在编码过程中实现。

二、参与人员与职责

1．项目组：

1）项目经理

密切监控项目的进度，及时配置相应的资源；

确保单元测试按照单元测试计划有序进行；

确认并为进行单元测试的程序开发人员提供必要的培训；

定期向总经理室汇报项目进度；

2）程序开发员

●编写单元测试案例；

●编写单元测试代码（如果需要）；

●执行单元测试，记录测试结果；

●记录单元测试错误报告；

●撰写单元测试报告。

3）配置管理员

●对原代码和可执行代码打基线；

●对单元测试记录、错误报告和测试报告进行归档、打基线和变更审计工作。

2．质量管理处：

●对单元测试的合规性（是否符合测试计划和测试规则的要求）进行指导和审计，并提交审计报告；

●根据单元测试报告（主要是测试发现的错误和缺陷情况），对单元测试进行定量分析，并向总经理室提交单元测试是否通过的审核意见。

3．

三、测试流程

1.计划

（1）时间安排

在概要设计完成评审后约一周后开始。

（2）输入

项目开发计划

项目需求规格说明书

概要设计文档

（3）入口条件

●概要设计文档已经通过评审。

（4）活动步骤

●确定单元测试的总体策略，具体包括：

⏹决定采用何种测试方式，包括自顶向下、自底向上和孤立测试三种方式，可以根据被测试系统的具体特点选择其中一种，也可以组合多种方式；

⏹决定是否使用已有的输入、输出或数据源（例如其它项目单元测试使用的测试文档和测试数据发生器等）

●确定被测试对象和测试范围；

●确定单元测试的完整性需求，具体包括：

⏹单元的接口；

⏹单元内的局部数据结构；

⏹单元内部逻辑中的对立路径；

⏹单元的出错处理机制；

⏹单元逻辑中的边界条件；

⏹对单元代码测试覆盖率（包括功能特性、过程、状态、函数、数据特性、指令等）；

⏹系统的特殊需要，包括系统的性能、安全性、保密性等；

●评估单元测试的工作量，需要考虑测试对象的数量、难度，以及测试代码开发的工作量；

●确定测试角色分工，划分工作任务；

●标识出测试的时间进度、任务、约束等条件；

●考虑一定的风险分析及应急计划；

●考虑和准备单元测试需要的测试人员、工具、数据、环境等资源；

●考虑相关培训安排；

●定义测试完成标准。

（5）输出

单元测试计划。

（6）出口条件

单元测试计划通过概要设计阶段的基线评审。

2.设计

（1）时间安排

在详细设计完成评审后约一周后开始。

（2）输入

●项目需求规格说明书

●系统详细设计文档

●单元测试计划

●以往项目的单元测试文档（如果有）

（3）入口条件

●概要设计阶段基线通过评审。

（4）活动步骤

●分析单元测试的策略，据此将被测试单元进行分组，确定测试顺序；

●分析单元测试的完整性需求和被测单元的特征，据此将被测试单元进行分组，制定设计可以复用的测试代码结构；

●分析被测对象的特征，设计测试案例的结构和内容；

●分析以往项目的单元测试文档，选择可以复用的单元测试设计方案、测试案例和测试数据发生器；

●分析单元测试需要的测试工具，并从以往的单元测试工具中选择可以复用的工具；

●分析单元测试的环境和约束条件；

●进一步评估单元测试的工作量，安排单元测试分工。

（5）输出

●单元测试设计方案。

（6）出口条件

●单元测试设计方案通过详细设计阶段的基线评审。

3.实现

（1）时间安排

在编码阶段开始后进行。

（2）输入

●项目需求规格说明书

●系统详细设计文档

●单元测试计划

●单元测试设计方案

●以往项目的单元测试文档（如果有）

（3）入口条件

详细设计阶段基线通过评审。

（4）活动步骤

●将单元测试设计阶段选择出来的以往的单元测试案例与相应的被测单元关联起来；

●编写单元测试案例；

●编写单元测试规则；

●编写单元测试代码（如果需要）；

●编写单元测试脚本（如果需要）；

●选择和落实单元测试工具（如果需要）。

（5）输出

●单元测试案例；

●单元测试规则；

●单元测试代码（如果有）；

●单元测试脚本（如果有）；

●单元测试工具（如果有）。

（6）出口条件

●单元测试案例和测试规则通过编码阶段基线评审。

4.执行

（1）时间安排

单元测试执行子阶段的主要工作通常在系统程序编码工作完成进行，部分比较简单的单元测试工作可以伴随编码过程同时进行。

（2）输入

●项目需求规格说明书；

●系统详细设计文档；

●单元测试计划；

●单元测试设计方案；

●单元测试案例；

●单元测试规则；

●单元测试代码（如果有）；

●单元测试脚本（如果有）；

●单元测试工具（如果有）；

●系统程序代码。

（3）入口条件

●单元测试设计与实现子阶段已经通过基线评审。

（4）活动步骤

●执行单元测试案例；

●对测试过程中发现的错误进行记录、分析、解决，并执行回退测试；

●评估单元测试结果；

●更新所有相关的系统设计文档；

●撰写单元测试记录、测试事件报告和单元测试报告。

（5）输出

●单元测试报告；

●用于单元测试的测试程序源代码、文档和可执行代码；

●更新后的系统程序源代码和可执行代码；

●经过更新的所有相关的系统设计文档；

●经过更新的所有相关的系统计划文档。

（6）出口条件

●单元测试报告和测试文档通过单元测试阶段评审；

●单元测试中发现的问题已经得到解决并获得批准。

四、单元测试评估与审计

1.单元测试开始前举行测试准备情况审核会；

2.单元测试结束前举行测试结束审核会；

3.质量管理处根据通过标准验收清单进行逐项核验工作；

4.质量管理处对整个单元测试过程的合规性进行审计；

5.版本管理员对测试后的系统打基线，并向项目组，总经理室和质量管理处提交系统版本情况报告。

五、测试评估数据

●单元测试中发现的错误/缺陷；

●按照内容对错误/缺陷进行分类；

●按照严重程度对错误/缺陷进行分类；

●按照造成的原因（系统设计错误还是编码错误）对错误/缺陷进行分类；

●单元测试投入的时间和工作量。

六、单元测试完成标准

1．完备性：

●所有的单元测试案例都是按照测试计划确定的完整性需求完成的设计和实现；

●所有的单元测试案例都按照测试计划完成测试；

●关键模块经过充分测试；

●测试中发现的错误得到修改后，都完成回退测试。

2．正确性：

●所有的测试案例都被正常执行，被测试的单元符合详细设计规定的功能；

●被测试的单元符合测试计划确定的完整性需求；

●测试中发现的错误得到修改后，经过回退测试证明修改正确；

3．文档的一致性：

●单元测试的测试计划、设计方案，以及所有测试案例、测试数据记录、测试错误分析、测试错误修改、测试总结报告都以文档的形式按照规定保存；

●单元测试中发现的问题被解决后，系统相关的概要设计、详细设计、代码和单元测试案例都得到相应的修改和归档，保证系统文档内容的一致性。

4．经过正式审核：

单元测试结果和测试报告需要经过项目经理、质量管理处和总经理室三级审批通过。

七、培训

项目经理应当确认将要执行单元测试工作的程序开发人员的培训需求，并尽快协调有关方面落实培训。

比如测试人员不熟悉单元测试工具，需要向他们提供这方面的非正式培训解决。

八、单元测试环境

1.硬件环境

单元测试可以在开发环境或与开发环境隔离的模拟生产环境中进行。

2.操作系统环境

要充分考虑不同机型使用的不同操作系统版本。

对于实际环境可能使用的操作系统环境，尽可能都要测试到。

3.数据库和中间件环境

数据库和中间件的选择要根据实际的需要，确保软件版本与生产版本一致。

4.网络环境

单元测试在局域网内进行，个别需要与行外其它网络连接的测试案例，可以通过仿真程序完成。

九、单元测试工具

1．测试记录表格、错误报告表格；

2．编译器、debugger工具和编辑器；

3．为本次单元测试专门编写的测试程序；

4．以往单元测试使用的可以复用的测试程序；

5．用于单元测试不同方面的商业测试工具软件，如代码静态分析工具、代码检查工具、代码功能测试工具、代码动态覆盖率测试工具、内存泄漏检测工具、回归测试工具等。

集成测试

一、概述

软件系统的集成就是将一系列的软件单元组装在一起，构建一个完整的软件系统。

在构建软件系统的过程中，系统的集成工作存在于不同的层次—程序单元集成为功能模块，功能模块集成为子系统，子系统集成为软件系统。

所以集成测试也存在于这些层次—功能模块，子系统，软件系统。

集成测试，也叫组装测试、联合测试或部件测试，它是通过测试验证组装后不同的功能模块之间的是否能够正常协同工作，从而确认组装起来的软件系统符合总体设计的要求，可以在不导致系统瘫痪的情况下执行系统功能。

集成测试的重点在于各个功能模块之间的各种接口，测试每个接口在各种情况下都正确，并测试一些预定的非正常输入情况下，处理是否合理有效。

应当在不同层次的集成测试引入不同的测试策略和方法。

集成测试的工作由各功能模块的程序开发员通过测试共同实现。

二、参与人员与职责

1．项目组：

4）项目经理

●密切监控项目的进度，及时配置相应的资源；

●确保集成测试按照集成测试计划和方案有序进行；

●确认并为进行集成测试的程序开发人员提供必要的培训；

●定期向总经理室汇报项目进度；

●及时向业务部门通报集成测试的进展（如果需要）。

5）程序开发员

●编写集成测试案例；

●执行集成测试，记录测试结果；

●记录集成测试错误报告；

●撰写集成测试报告。

6）配置管理员

●对原代码和可执行代码打基线；

●对集成测试记录、错误报告和测试报告进行归档、打基线和变更审计工作。

2.质量管理处：

●对集成测试的合规性（是否符合测试计划和测试规则的要求）进行指导和审计，并提交审计报告；

●根据集成测试报告（主要是测试发现的错误和缺陷情况），对集成测试进行定量分析，并向总经理室提交集成测试是否通过的审核意见。

3.

三、测试流程

1.计划

1）时间安排

在概要设计完成评审后约一周后开始。

2）输入

●项目需求规格说明书

●概要设计

3）入口条件

●概要设计文档已经通过评审。

4）活动步骤

●确定被测试对象和测试范围；

●评估集成测试被测试对象的数量、难度，即工作量；

●确定测试角色分工和划分工作任务；

●标识出测试各阶段的时间、任务、约束等条件；

●考虑一定的风险分析及应急计划；

●考虑和准备集成测试需要的测试人员、工具、数据、环境等资源；

●考虑外部技术支援的力度和深度，以及相关培训安排；

●定义测试完成标准。

5）输出

●集成测试计划。

6）出口条件

●集成测试计划通过概要设计阶段的基线评审。

2.设计

1）时间安排

详细设计阶段开始。

2）输入

●项目需求规格说明书

●概要设计

●集成测试计划

3）入口条件

●概要设计阶段基线通过评审。

4）活动步骤

●分析被测对象的结构；

●分析集成测试的功能模块；

●分析集成测试的接口；

●分析集成测试的策略；

●分析集成测试需要的测试工具；

●分析集成测试的环境；

●进一步评估集成测试的工作量，安排集成测试分工。

5）输出

●集成测试设计方案。

6）出口条件

●集成测试设计方案通过详细设计阶段的基线评审。

3.实现

1）时间安排

在编码阶段开始后进行。

2）输入

●项目需求规格说明书

●概要设计

●集成测试计划

●集成测试设计

3）入口条件

●详细设计阶段基线通过评审。

4）活动步骤

●编写集成测试案例；

●编写集成测试规则；

●编写集成测试代码（如果需要）；

●编写集成测试脚本（如果需要）；

●落实集成测试工具（如果需要）。

5）输出

●集成测试案例；

●集成测试规则；

●集成测试代码（如果有）；

●集成测试脚本（如果有）；

●集成测试工具（如果有）。

6）出口条件

●集成测试案例和测试规则通过编码阶段基线评审。

4.执行

1）时间安排

单元测试完成后就可以开始执行集成测试了。

2）输入

●项目需求规格说明书；

●概要设计；

●集成测试计划；

●集成测试设计；

●集成测试案例；

●集成测试规则；

●集成测试代码（如果有）；

●集成测试脚本（如果有）；

●集成测试工具（如果有）；

●系统详细设计；

●系统程序代码；

●单元测试报告。

3）入口条件

●单元测试阶段已经通过基线评审。

4）活动步骤

●执行单元测试案例；

●对测试过程中发现的错误进行记录、分析、解决，并执行回退测试；

●评估集成测试结果；

●撰写集成测试记录、测试事件报告和集成测试报告。

5）输出

●集成测试报告；

●更新并打了基线的系统程序源代码和可执行代码；

●经过更新的所有相关的系统设计文档；

●经过更新的所有相关的系统计划文档；

6）出口条件

一、集成测试报告通过集成测试阶段评审。

四、集成测试评估与审计

1.集成测试开始前举行测试准备情况审核会；

2.集成测试结束前举行测试测试结束审核会；

3.质量管理处进行通过标准验收清单逐项核验工作；

4.质量管理处对整个集成测试过程的合规性进行审计；

5.版本管理员对测试后的系统打基线，并向项目组，总经理室和质量管理处提交系统版本情况报告。

五、测试评估数据

1.集成测试中发现的错误/缺陷；

2.按照内容对错误/缺陷进行分类；

3.按照严重程度对错误/缺陷进行分类；

4.按照造成的原因（系统设计错误还是编码错误）对错误/缺陷进行分类；

5.集成测试投入的时间和工作量。

六、集成测试完成标准

1．完备性：

●集成测试按照一定的层次进行，所有三个层次的集成测试应当全部完成--功能模块，子系统，软件系统；

●所有公共的接口都被测试到，包括软件系统与系统外的其它系统间的接口；

●关键模块经过充分测试；

●所有的集成测试案例都按照测试计划完成测试；

●测试中发现的错误得到修改后，涉及的相关接口都完成回退测试，证明修改正确。

2．正确性：

●在把各个软件单元连接起来时，通过单元接口的数据没有丢失或被更改；

●各个子功能组合起来能够达到概要设计要求的父功能；

●一个软件单元的功能不会对另一个软件单元的功能产生不利影响；

●全局数据结构没有问题，不会被异常修改；

●单个程序单元的误差积累起来，不会出现放大效应，以致达到不可接受的程度，导致整个系统工作异常。

●所有的测试案例实现正常完成，符合概要设计规定的功能，并且在测试过程中整个系统工作正常，不出现宕机、系统资源耗尽、系统效率异常等情况；

3．文档的一致性：

●集成测试的所有测试案例、测试数据记录、测试错误分析、测试错误修改、测试总结报告都以文档的形式按照规定保存；

●集成测试中发现的问题被解决后，系统相关的概要设计、详细设计、代码和集成测试案例都得到相应的修改和归档，保证系统文档内容的一致性。

4．经过正式审核：

集成测试结果和测试报告需要经过项目经理、质量管理处和总经理室三级审批通过。

七、培训

项目经理应当确认将要执行集成测试工作的程序开发人员的培训需求，并尽快协调有关方面落实培训。

比如测试人员不熟悉系统其它部分的代码，需要向他们提供这方面的非正式培训解决。

八、集成测试环境

1.硬件环境

集成测试可以在与开发环境隔离的模拟生产环境中进行。

在搭建模拟生产环境时，需要分析模拟环境与实际环境之间可能存在的设备性能、网络连接、交易产生方式等方面的差异，并尽可能通过编写仿真程序减少这种差异。

2.操作系统环境

要充分考虑不同机型使用的不同操作系统版本。

对于实际环境可能使用的操作系统环境，尽可能都要测试到。

3.数据库和中间件环境

数据库和中间件的选择要根据实际的需要，从性能、版本、容量、我行现有资源等多方面考虑。

4.网络环境

集成测试原则上在局域网内进行，个别需要与行外其它网络连接的测试案例，可以通过仿真程序完成。

九、集成测试工具

●测试记录表格、错误报告表格；

●测试模拟环境；（如果需要）

●测试工具软件。

由于集成测试关注的是模块之间接口的个性化特点，能够直接用于集成测试的商用测试工具并不多，因此，能够有效支持系统集成测试的工具主要以项目组自行开发为主；

●用于单元测试的一些测试工具可以用于集成测试；

●对于一些以界面为主的集成测试或者基于公共协议的集成测试，可以寻找一些商用的测试工具

系统测试

一、概述

系统测试指的是完成对整个系统的功能测试，以确认系统各种功能和系统的业务需求书一致。

系统测试的重点是从系统的角度证明系统总体功能的正确性、与关联系统的协调性和时序的准确性。

系统测试还应当确认系统其他的需求也都被满足，如：

系统安装与恢复，数据备份，运行可维护性等。

系统测试又成为“功能测试”或“综合测试”。

系统测试的目标是：

1.确认软件系统在仿真实际生产环境中，能够无错误地和可重复地实现系统业务需求书要求的功能，以及系统设计的隐性功能。

2.系统没有不正确或遗漏的功能。

3.确定并记录软件系统的性能特征和指标。

4.为压力测试和即将到来的上线投产提供一个功能完整的，文档齐全，运行稳定的系统版本。

在系统测试正式进入到执行测试子阶段前，必须召开一次正式的测试准备情况审核会，以便保证系统测试工作在充分准备并合乎测试要求的情况下进行，保证测试的效率和质量。

审核工作可以通过审核集成测试结果、系统测试方案、以及任何为系统测试开发的支持程序代码等来完成。

在项目组和测试队伍之间应当对系统测试应该完成的程度、测试流程的有效性以及测试结果的理解达成共识。

该部分的工作由提出项目需求的业务部门人员、测试团队和项目组人员在集成测试后合作完成。

二、参与人员与职责

4.提出需求的业务部门

●负责系统测试的组织和实施工作；

●编制系统测试计划；

●协调业务人员、开发项目组和第三方测试人员完成系统测试；

●协调和组织系统测试过程中错误/缺陷的修改和回退测试，并及时修改测试计划以反映实际情况；

5.测试团队（包括项目组测试人员和第三方测试人员）：

●进行系统测试设计；

●编写系统测试案例和测试框架；

●开发测试脚本；

●审核