软件测试各过程的意义

海辉软件应用测试部门在长期的行业测试经验中，在软件测试过程模型方面总结出了如下图所示的改进W模型：

业务需求V&V验收测试设计试运行/部署验证用户验收测试(UAT)上线版本验证系统集成测试(SIT)需求分析V&V系统测试设计系统构建验证系统测试测试组测试概要设计V&V集成测试设计模块集成验证集成测试详细设计V&V单元测试设计内部集成验证单元测试开发组测试编码实现软件测试改进W模型

相对于传统V模型，W模型更科学，由一个开发的“V”和一个与之并行的测试“V”组成，体现了“尽早地和不断地进行软件测试” 的软件测试基本原则，强调的是测试伴随着整个软件开发周期，测试与开发是同步进行的，而且测试的对象不仅仅是程序代码，需求、设计同样要进行测试（图中的“V&V”即表示对需求文档、设计文档的验证Verification和确认Validation）。

根据金融行业应用系统IT架构复杂、应用系统间关联度高的特点，在单一应用系统系统测试完成后，应进一步在具备其他应用系统的测试环境中执行“系统集成测试”（System Integration Testing，SIT），以验证各应用系统间数据传递正确、业务功能正常完成。

鉴于金融行业对应用系统准确性、稳定性、安全性要求高及应用系统失败将造成巨大损失的特点，为保证万无一失，在用户验收测试完成后、系统正式上线前，一般还会在准生成环境中进行“上线版本验证”测试，再次验证系统功能性能是否满足要求，系统在使用过程中是否会出错等

等。

按照当前金融行业开发测试现状，一般情况下，单元测试、集成测试由开发项目组执行，系统测试、系统集成测试、用户验收测试、上线版本验证测试由测试部门执行或参与（用户验收测试由业务部门组织执行，测试部门提供测试工具支持和测试环境支持等）。

第一章 测试阶段说明

根据海辉测试W模型，测试按阶段划分可分为：单元测试、集成测试、系统测试和用户验收测试（UAT），在系统测试完成后，根据被测系统具体情况可选择实施系统集成测试（SIT）和上线版本检验测试。

测试在不同阶段涉及到的部分测试内容如下表所示：

阶 段 单元测试 静态测试 动态测试 集成测试 接口测试 功能测试 功能测试 测 试 内 容 备 注 代码走查、交叉检查、内开发方测试 部评审、静态扫描 动态执行检查 接口符合性测试 功能测试（GUI、业务、健壮性等） 自动化回归测试 性能测试 可靠性/可恢复性测试 安装配置测试 安全性测试 开发方测试 开发方测试 数据流转、处理逻辑测试 开发方测试 第三方测试 第三方测试 第三方测试 第三方测试 第三方测试 第三方测试 对开发方提供的需求说明书、详细设计说明书、数据库安装手册等文档的检查和测试 第三方测试 支持平台的兼容性 第三方测试 与其它生产系统的联通测试 业务用户测试 系统用户的代表进行测试 第三方测试或业务用户测试 第三方测试或业务用户测试 可以有针对性地选择部分业务 系统测试 非功能测试 （技术测试） 文档测试 系统集成测试(SIT) 兼容性 互联测试 自动化回归测试 用户验收功能和业务测试(UAT) 流程测试 上线版本检验测试 业务流程 业务流程测试 1.1 单元测试

单元测试是测试的基础级别。单元测试着眼于程序或系统的较小构建模块，是执行每个模块以证实其履行了指定功能的过程。单元测试由开发人员完成。

单元测试过程是根据详细设计文档和编码规范的要求，对系统中程序单元并行进行测试。单元测试阶段形成的文档包括：《单元测试计划》、《单元测试案例》、《单元测试报告》、《代码审查表》等。

1.1.1 测试方法

单元测试的方法主要采用静态测试方法和动态测试方法。  静态测试

静态测试方法能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷。静态测试方法的依据是项目的程序设计文档、程序的源代码清单、编码规范和代码审查表等。静态测试中最常用的手段是代码审查。

审查是一种正式的评估方法，将由非制作者本人的个人或小组详细检查阶段成果，以查明是否有错误、是否违反开发标准及是否存在其他问题。代码审查可以发现违背编码规范的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。执行代码审查前，各个项目组需制定适用于本项目的《代码审查表》，覆盖以下几类问题，并对每类问题进行细化和补充：

 Comment：注释没写，或者格式不对，或者毫无意义  Coding Standard：没遵守编码规范

 Existing Wheel：重复现成的代码，或者是开源项目，或者其他

项目已有代码

 Performance bottle and Improvement：性能问题  Code Logic Error：代码逻辑错误  Business Logic Error：业务逻辑错误

 动态测试

针对代码只进行静态测试是不完整的。动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。动态测试的必要手段是设计和执行单元测试案例，其覆盖标准有：

 语句覆盖：每条语句至少执行一次

 判定覆盖：每个判定的每个分支至少执行一次  条件覆盖：每个判定的每个条件应取到各种可能的值  判定/条件覆盖：同时满足判定覆盖条件覆盖

 条件组合覆盖：每个判定中各条件的每一种组合至少出现一次  路径覆盖：使程序中每一条可能的路径至少执行一次。 要达到较强的覆盖程度，需要付出案例设计和编写的工作量。动态测试案例的设计一般和代码重构并行完成，可以采用以下方法进行补充和完善：

 基本路径法：在程序控制流图的基础上，通过分析控制构造的环

路复杂性，导出基本可执行路径集合，从而设计测试案例的方法。设计出的测试案例要保证在测试中程序的每个可执行语句至少执行一次。

 边界值分析法：合理的输入条件与不合理的输入条件。  错误推测法：列举出程序中所有可能的错误和容易发生错误的特

殊情况，根据它们选择测试案例。

1.1.2 测试流程

单元测试对应开发过程中的编码阶段，其流程包括测试计划、测试设计、测试执行、测试总结、测试过程审计等环节。

开始制定单元测试计划（评审测试计划）单元测试计划代码审查设计代码审查表(评审代码审查表)代码审查表（检查项）动态测试设计测试案例（评审测试案例）单元测试案例单元测试报告检查表执行测试案例（缺陷管理流程）测试缺陷记录表审计记录汇总单元测试案例检查表单元测试计划检查表审计单元测试活动执行代码审查代码审查表（执行记录）审查结果汇总执行结果汇总编写单元测试报告（评审测试报告）单元测试报告结束单元测试流程图

在单元测试过程中体现了静态测试（代码审查）和动态测试相结合的方法。代码审查一般在动态测试之前启动，并允许交错或同步进行。

1.2 集成测试

集成测试，也叫组装测试或联合测试，是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。集成测试的目的是检验软件单元之间、软件单元和已集成的软件系统之间的接口关系，并验证已集成软件系统是否符合设计要求。

集成测试的重要依据是《概要设计说明书》及相关设计文档。集成测试阶段形成的文档包括：《集成测试计划》、《集成测试案例》、《集成测试报告》等。

1.2.1 测试方法

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露

出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

以下介绍了几种常用的集成测试方法和策略：自顶向下、自底向上、核心先行集成、高频度集成等。在实践中通常会采用几种集成策略相结合的测试方法，例如：复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行；而传统瀑布式开发模式的软件项目集成过程中较常用自底向上的集成测试方案。

 自顶向下集成

自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法：结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。

 先深度：按照结构，用一条主控制路径将所有模块组合起来；  先宽度：逐层组合所有下属模块，在每一层水平地沿着移动。  自底向上集成

自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其它集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。

 核心集成测试

核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。

核心集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。

 高频集成测试

高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。

该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。

1.2.2 测试流程

集成测试对应开发过程中的概要设计阶段，其流程包括测试计划、测试设计、测试执行、测试总结、测试过程审查等环节。

开始制定集成测试计划（评审测试计划）集成测试计划审查集成测试活动设计集成测试（评审测试案例）集成测试案例审查记录汇总集成测试报告检查表集成测试案例检查表集成测试计划检查表执行集成测试（缺陷管理流程）缺陷记录表编写集成测试报告（评审测试报告）集成测试报告结束集成测试流程图

集成测试阶段的测试活动首先应该根据项目所选的集成方式制定测试策略。同时，应该充分依据上一测试阶段（单元测试）的成果物，进行参考、复用和补充。

1.3 系统测试

系统测试是在特定环境下对系统进行全面测试的过程。系统测试执行一组测试，以验证软件质量保证计划中的各种质量属性。系统测试的对象是完整的、集成的计算机系统。这里不仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际（或模拟）的运行环境下来进行测试。系统测试由的测试团队完成，应避免由开发方主导的系统测试。

系统测试的重要依据是《需求规格说明书》及相关设计文档。系统测试阶段形成的文档包括：《系统测试计划》、《系统测试需求》、《系统测试案例》、《系统测试报告》等。

1.3.1 测试方法

系统测试主要采用黑盒测试的方法，说明如下：

 功能分解：功能分解法是将需求规格说明中每一个功能加以分解，

确保各个功能被全面的测试。

 等价类划分：等价类划分是在分析需求规格说明的基础上，把程

序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。

 边界值分析：边界值分析法是对边界值进行测试，使用等于、小

于或大于边界值的数据对程序进行测试。

 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动

作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。  因果图：因果图分析法是通过画因果图，把用自然语言描述的功

能说明转换为判定表，然后为判定表的每一列设计一个测试案例。  随机测试：随机测试输入的数据是在所有可能输入值中随机选取

的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。  猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错

和易错情况表，写出测试案例的方法。

 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表

性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。

在系统测试的实践中，多采用几种测试方法相结合的方式进行。

1.3.2 测试流程

系统测试对应开发过程中的需求分析阶段，其流程包括测试计划、测

试需求分析、测试设计、测试执行、测试总结、测试过程审查等环节。

开始制定系统测试计划（评审测试计划）系统测试计划分析系统测试需求（评审测试需求）系统测试需求审查系统测试活动设计系统测试案例（评审测试案例）系统测试案例审查记录汇总系统测试报告检查表系统测试案例检查表系统测试需求检查表执行系统测试（缺陷管理流程）缺陷记录表系统测试计划检查表编写系统测试报告（评审测试报告）系统测试报告结束系统测试流程图

系统测试阶段的测试活动应该是专门的测试团队完成的测试。同时，应该充分依据上一测试阶段（集成测试）的成果物，进行参考、复用和补充。

1.4 系统集成测试

系统集成测试也可称为兼容性测试，目的是验证被测系统与其它已经上线的生产系统之间交互操作的正确性和可靠性。系统集成测试可以由测试团队或者测试与开发协作完成。

系统集成测试阶段形成的文档包括：《系统集成测试计划》、《系统集成测试需求》、《系统集成测试案例》、《系统集成测试报告》等。

1.4.1 测试方法

系统集成测试主要采用黑盒测试的方法，说明如下：

 功能分解：功能分解法是将需求规格说明中每一个功能加以分解，

确保各个功能被全面的测试。

 等价类划分：等价类划分是在分析需求规格说明的基础上，把程

序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。

 边界值分析：边界值分析法是对边界值进行测试，使用等于、小

于或大于边界值的数据对程序进行测试。

 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动

作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。  因果图：因果图分析法是通过画因果图，把用自然语言描述的功

能说明转换为判定表，然后为判定表的每一列设计一个测试案例。  随机测试：随机测试输入的数据是在所有可能输入值中随机选取

的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。  猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错

和易错情况表，写出测试案例的方法。

 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表

性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。

在系统集成测试的实践中，多采用几种测试方法相结合的方式进行。

1.4.2 测试流程

系统集成测试对应开发过程中的需求分析阶段，其流程包括测试计

划、测试需求分析、测试设计、测试执行、测试总结、测试过程审查等环节。

开始制定SIT计划（评审测试计划）SIT计划分析SIT需求（评审测试需求）SIT需求设计SIT案例（评审测试案例）SIT案例审查SIT活动SIT报告检查表执行SIT（缺陷管理流程）缺陷记录表审查记录汇总SIT案例检查表SIT需求检查表SIT计划检查表编写SIT报告（评审测试报告）SIT报告结束SIT流程图

系统集成测试阶段的测试活动是测试团队完成或测试与开发协作完成的测试。同时，应该充分依据上一测试阶段的成果物，进行参考、复用和补充。

1.5 用户验收测试

验收测试是最终用户执行的测试，使用黑盒测试技术对照系统规约对其进行测试。最终用户负责确保所有相关功能都被测试到。验收测试由用户在测试人员的指导下进行。

用户验收测试的内容主要包括：适合性、准确性、互操作性、安全保密性、成熟性、容错性、易恢复性、易理解性、易学性、易操作性、吸引

性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依赖性方法进行选择，确定测试内容。对具体的软件系统，可根据合同（或业务需求）的要求对测试内容进行裁剪。

用户验收测试的重要依据是《业务需求说明书》、《需求规格说明书》及相关需求文档。用户验收测试阶段形成的文档包括：《用户验收测试计划》、《用户验收测试案例》、《用户验收测试报告》等。

1.5.1 测试方法

用户验收测试一般采用黑盒测试方法，如：

 功能分解：功能分解法是将需求规格说明中每一个功能加以分解，

确保各个功能被全面的测试。

 等价类划分：等价类划分是在分析需求规格说明的基础上，把程

序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。

 边界值分析：边界值分析法是对边界值进行测试，使用等于、小

于或大于边界值的数据对程序进行测试。

 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动

作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。  因果图：因果图分析法是通过画因果图，把用自然语言描述的功

能说明转换为判定表，然后为判定表的每一列设计一个测试案例。  随机测试：随机测试输入的数据是在所有可能输入值中随机选取

的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。  猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错

和易错情况表，写出测试案例的方法。

 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表

性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。

在实践中，用户验收测试多采用几种测试方法相结合的方式进行。

1.5.2 测试流程

用户验收测试对应开发过程中的业务需求分析阶段，其流程应包括：测试计划、设计测试、执行测试、总结测试等环节。

开始计划测试（评审测试计划）设计测试（评审测试案例）修复完成提交缺陷待开发人员修复执行测试测试失败执行案例是否通过测试通过 该部分流程可选补充，更新UAT案例执行UAT案例测试失败提交缺陷待开发人员修复修复完成确认失败执行案例是否通过测试通过可接受确认确认成功总结测试(评审测试报告)结束

用户验收测试流程图

用户验收测试应该以用户（通常是业务人员）为主体，由业务人员完成该阶段的测试活动。业务人员可以参考前一测试阶段（系统测试）的交付物，即：《系统测试需求》《系统测试案例》、《系统测试报告》等。

第二章 测试阶段意义

从上一章中已经了解了测试应该做那些测试，如果做这些测试，但是为什么要做这些测试，做这些测试有什么好处，不做这些测试会存在哪些问题或隐患，下面将介绍各测试阶段的实施的意义以及不实施这些阶段的问题。

2.1 单元测试

2.1.1 单元测试的意义

为了很好的完成软件系统的测试任务，我们采用了分层测试的方式，从整体来说做UAT测试的时候我们假设软件系统是一个出厂的产品，最基本的功能都已经实现，这种假设我们通过系统测试来完成，但在做系统测试时，就要假设整个系统的集成运行已经没有问题了，在运行测试或性能测试时，我将不再考虑“系统无法正常运行”这种场景。那么如何保证集成运行没问题呢?我们用集成测试来检验。但是在做集成测试的时候，我们同样要基于一个假定，就是各个模块的功能都能够如期正常工作。而这一点，又是通过模块自身的功能测试来完成的。„„这样一层层往下推，每个层次就假设它所依赖的层次没有问题，这样就可以减少很多场景以及由这些场景引出的额外的分支。将原先一个几何级数的测试用例分解成可以接受的若干层次的算术级数的用例。这样一来我们就可以很好的完成测试任务。

而单元测试，正是这些测试的最低层次——保证每个函数/方法，或者说最小功能模块的正确性的一种测试。

2.1.2 无单元测试阶段的问题

如果不进行单元测试，开发人员开发完成代码后，顶多是从他实现功能的角度上进行一些验证，但这种验证是不全面，无法保证可能会出现的

产生无法走通的分支、无法走出的循环以及产生内容泄露的问题，这些问题如果在在单元测试阶段发现的话，很容易查找并修改完成，但是如果在后期系统测试或者是上线以后发现就会产生很大的问题，首先上线后可能会产生生产的事故，其次如果没上线，在大量的代码中去查找分析和修改这些代码会产生很多的成本，甚至发现这样的问题都因为影响非常大而无法修改。

2.2 集成测试

2.2.1 集成测试的意义

集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。

集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。

集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。

所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模

式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。一般来说，集成测试需要花费的时间远远超过单元测试，直接从单元测试过渡到系统测试是极不妥当的做法。

集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

2.2.2 无集成测试阶段的问题

集成测试是在单元测试的基础上进行的组装测试，就像积木一样的将各个单元组合成我们所需要的功能，如果不进行集成测试，可能会出现两个功能之间的数据格式不一致、功能无法联通等等一系列的问题，例如：如果有两个功能A和B，A输出的数据是1时表示的是“YES”，输入是2时表示的是”NO”,而B接收后解析缺正好相反，这就产生了问题，这是一个简单的例子，但是又一些集成的问题在后期发现的话，会因为无法集成而需要推翻之前的代码重新编写，就像房子快盖好了发现中间一块钢材有裂缝，必须推倒重新盖一样，需要花费大量的人力和物力。

2.3 系统测试

2.3.1 系统测试的意义

系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。

系统测试的任务是尽可能彻底地检查出程序中的错误，提高软件系统

的可靠性，其目的是检验系统\"做得怎样？\"。这个阶段的测试包含内容较多，除了对于功能的测试外，还包含对系统的性能测试、安全性测试、可靠性测试等非功能测试的内容，是针对整个软件系统是否满足用户功能和性能要求的测试。该阶段结束应交付测试报告，说明测试数据的选择，测试用例以及测试结果是否符合预期结果。测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

2.3.2 无系统测试阶段的问题

系统测试很明显是开发完成后再进行的一系列的测试，在这个阶段中系统已经基本成型，但是这个成型只是表面上的成型，这个成型的“东西”的东西是否可以使用，满足使用的需求，很明显无法保证，因此才进行这系统测试，如果不进行系统测试，那么系统的存在的很多问题都只能放到用户验收的时候才能发现很解决，但是这很不现实的，用户在很多情况下只是会根据自己的需求来验收产品，但是很少会全面的去验证这个产品的所有功能，将这样的产品拿来上线，所承担的风险可想而知，可以举个例子，2008北京奥运会官方提出“先到先得”的销售刺激公众踊跃提交购票申请，这时，在线网站瞬间访问数据量急剧上升，技术系统应对不畅，官方售票系统叫停。原因是超负荷，官方售票系统的访问流量每小时达100万次，而那一天瞬时每小时达到800万次，1个小时处理15万张，而一启动瞬间达到20万张，从而出现网络堵塞。从这个例子看，网站的性能也隐含潜在危机。这是因为缺乏性能测试，在现实中有很多这样的例子。

系统测试的目的和用户验收测试的目的是完全不同，系统测试除了要验证系统满足业务需求，还需要验证各种情况下系统的处理能力，保证系统在各种情况下不会出现问题，特别是一些特殊的处理，反常规的操作，性能的要求等等，这些情况甚至会产生让系统完全瘫痪的问题。

2.4 系统集成测试

2.4.1 系统集成的意义

系统集成测试在金融业内使用较多，由于金融行业的系统复杂度很高，对某个系统的系统测试完成后，只能保证本系统的功能没有问题，但是金融行业系统关联性非常强，针对这种情况，我们就需要进行系统的测试，保证各个关联系统之间的处理可以畅通，并不会出现系统之间处理出错的问题。

系统集成测试只是针对各种系统错综复杂的系统才需要的一种测试阶段，大多是针对系统之间的串行的功能进行验证，保证系统的功能实现的正确。

2.4.2 无系统集成测试阶段的问题

针对金融行业这种复杂的系统，如果不进行系统集成测试系统之间的功能将无法保证，会出现这个系统处理完成的工作，而后续的系统根本没有收到，这样会就产生生产的事故了，例如：银行的系统中，在信贷审批系统中进行一笔对公贷款的审批，审批成功后，应到核心系统进行发放这笔贷款，可是由于系统之间的处理产生问题，核心没有收到这笔贷款的信息，那这笔贷款就发放不出，而且就算是后期对账都不会出现问题，如果客户在等待使用这笔贷款来做一笔生意，因为时间原因错失的话，这将产生重大的生产事故，当然这只是来举例，但是这样的事情还是会有发生的。

2.5 用户验收测试

2.5.1 用户验收测试的意义

用户验收测试也就是我们常说的UAT测试，用户验收也就是使用者在提出产品需求后，验证产品是否满足用户需求的一种测试，一般来说是由客户的业务人员来完成的，大多还会有测试公司进行支持，用户验收测试就相当于我们在需要做一件事情有了需求，提出需求后去做或买一些工具

来实现需求，举例说：我们想将墙上的钉子拔出来，这是我们的需求，我们提出拔钉子的需求后，为了满足需求，我们去买钳子来实现这个需求，那买来的钳子是否可以用，有没有牙口，有没有手把，并且一般我们在买的时候还会打开试用一下，这个试用的过程在软件测试上就是用户验收测试，而做验收测试的目的除了试用外，还要防止买回来的不是小钳子无法拔出钉子，甚至买回来的不是钳子而是羊角锤，虽然能拔出钉子，但不是我们真正的需求。

2.5.2 无用户验收测试阶段的问题

如果不进行用户验收测试，这个很容易理解了，刚才上面举得例子中提到，无法拔出钉子的小钳子、羊角锤、没有牙口的钳子，都可能到你手上，对软件来说就是会满足不了你的需求，无法完成业务上的功能，耽误你的工作，甚至产生生产的事故。这都是因为只有最终用户，才知道自己要需要什么。