金融软件测试从入门到实践

版权信息

书名：金融软件测试从入门到实践

ISBN：978-7-115-62502-1

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版　　权

著    中电金信质量安全团队

责任编辑 胡俊英

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

内 容 提 要

随着社会的不断进步，各行各业都在拥抱数字化转型，软件的应用规模不断扩大，普及率呈现大幅度上升的趋势。软件测试是保障软件质量的重要环节，金融软件测试更是金融业务与测试技术融合的重要领域。

本书通过9章内容，深入浅出地介绍了金融软件测试的基础知识、常用工具、相关标准、项目管理知识、用例设计方法、执行方法、报告编写等内容，并通过银行国际业务测试项目实战带领读者全面复盘所学知识和相关技巧。

本书围绕金融软件测试进行讲解，帮助读者理解基础知识，掌握实践技能。本书适合金融软件测试领域的从业者、软件测试专业的师生以及想了解或进入该行业的相关人员阅读。

编 委 会

主  编：王　壮　杨亚静　王永恒

编 写 组：黄　明　姚琴琴　李程斐　王春娥　宫　磊　冯　昊　王　瑀

     孙清晨　管珊珊　沈丽军　高　能

审 定 组：王　悦

顾 问 组：王永强　张国志　邓　楠　刘媛媛　段德浩　赵向军　王昌滨

     蔡越明

前  言

随着互联网的快速发展，软件的应用规模不断扩大，其复杂度大幅提升，各行各业在加快数字化转型步伐的同时，对于软件研发项目标准化建设愈加重视，投入力度越来越大。软件测试是软件研发项目全生命周期中用于保障软件质量的重要环节，金融软件测试更是金融业务与测试技术融合的重要领域。

随着IT在金融行业的广泛应用，金融行业的业务量不断增加，交易模式也在不断变化，金融机构对信息化的要求也越来越高，软件测试已经成为支撑金融机构转型发展、保障产品和服务质量、提升客户满意度、控制金融风险的重要手段。在金融IT发展的进程中，金融软件测试的价值将进一步得到体现，成为促进金融业务发展的新动能。

目前市面上已经出版了一些软件测试相关的优质图书，但与金融软件测试相关的图书却比较少见。金融软件测试在传统软件测试的基础上增加了金融行业属性，因此对软件测试有更加细致的要求。金融业务领域较为广泛，包括银行、保险、信托、证券、基金、互联网金融等。由于金融业务系统以及相关联的系统通常比较复杂，因此对金融软件测试人员的业务能力和技术能力的要求也相对较高。鉴于此，我们着力编写了这本金融业务知识与金融软件测试相结合的书。希望读者能通过本书学习到金融软件测试的基础知识和必要的实践技能，成为优秀的金融软件测试工程师。

本书的读者对象

本书特别注重理论与实践相结合，期望读者既能领会金融软件测试的知识和方法，又能将这些知识和方法应用到实际工作中去。本书适用于以下类型的读者：

● 有意将金融软件测试作为其全职工作的人员或金融软件测试爱好者；

● 计算机应用、计算机软件、软件工程、软件测试等专业的师生；

● 想要改变职业赛道，转入金融软件测试领域的人员；

● 希望增强金融软件测试领域知识的人员，包括软件测试人员、开发人员、项目经理、软件开发团队的其他人员等。

本书的组织方式

本书将金融软件测试的相关知识分9章展开，具体介绍如下。

第1章，“金融软件测试概述”，介绍软件测试的发展历程、软件测试的分类、软件测试常见模型，并进一步聚焦金融软件测试，介绍其发展历程、测试类型及人才培养思路等。通过本章的学习，读者会对金融软件测试有初步的了解和认识。

第2章，“金融软件测试基础知识”，介绍金融软件功能测试、金融软件非功能测试和互联网金融软件测试的基础知识。通过本章的学习，读者会了解金融软件功能测试、非功能测试的流程和方法，并加深对传统金融软件测试和互联网金融软件测试的认识。

第3章，“常用软件测试工具”，重点介绍中电金信软件有限公司自研的4类金融软件测试工具。通过本章的学习，读者会了解到相关工具在金融软件测试中的使用方法。

第4章，“测试准入准出标准”，介绍什么情况下可以开始当前版本的测试工作，什么情况下可以结束当前版本的测试工作。通过本章的学习，读者会了解到金融软件功能测试和非功能测试的准入准出标准。

第5章，“金融软件测试项目管理”，介绍金融软件测试项目管理方法、软件测试流程、项目评审流程、需求变更流程、缺陷管理流程、测试轮次管理、测试参数管理、测试数据管理等项目管理知识。通过本章的学习，读者会对金融软件测试项目管理的方法论有初步的了解和认识。

第6章，“金融软件测试用例设计方法”，介绍金融软件测试用例要素、常规功能测试用例设计方法、功能测试和非功能测试用例设计。通过本章的学习，再结合实际的金融软件测试案例，读者可以对每种测试用例设计方法和测试用例设计场景有更深的理解。

第7章，“金融软件测试执行”，介绍金融软件测试项目中功能测试执行和非功能测试执行的具体流程和操作方法，测试执行是测试过程中的核心环节。

第8章，“金融软件测试报告编写”，介绍如何编写测试报告，如何在测试报告中进行缺陷统计等。通过本章的学习，读者可以了解测试报告的主要内容以及如何编写一份规范的测试报告。

第9章，“银行国际业务测试项目实战”，通过实际的金融软件测试项目将前面章节的知识串联起来。通过本章的学习，读者可以深入了解金融软件项目的整个测试过程。

每章的开篇都设计了导读部分，使读者能够在较短的时间内对整章的内容有概括性的了解。本书还提供了一些有针对性的思考和练习题（配套答案可通过异步社区获取），能帮助读者更加全面和深入地掌握相关章节的内容。

本书用到的测试工具

本书用到的测试工具为中电金信软件有限公司（以下简称“中电金信”）的自研产品，分别是测试质量管理工具、自动化测试工具、性能测试工具和测试数据管理工具。

对于以上测试工具的使用，中电金信提供了公有云按需租用、产品购买&线下部署、测试人力服务、项目合作&定制化开发4种合作模式：

● 公有云按需租用是指客户可根据项目需求，评估所需服务器体量、设备数量等，租用相关工具；

● 产品购买&线下部署是指客户可购买产品（使用许可），然后由中电金信提供线下部署、维护和升级服务；

● 测试人力服务是指客户将测试业务和需求提交给中电金信，由中电金信提供专业测试人员及测试工具，并按时测试交付；

● 项目合作&定制化开发是指中电金信根据客户提出的定制化需求向其提供定制开发服务。

如您需要任何咨询或合作，可通过邮件联系我们，邮箱地址为dehao.duan@gientech.com；也可拨打我们的咨询热线4000209900。

致谢

非常感谢人民邮电出版社的相关工作人员，他们为本书的出版做了大量的工作。

本书的编写和整理工作由中电金信完成，编委会的全体人员在近一年的编写过程中付出了辛勤的劳动，在此一并表示衷心的感谢。

在写作过程中，本书参考了相关的图书、网络技术资料、文章及同行的心得，在此向这些内容的贡献者表示感谢！

资源与支持

资源获取

本书提供如下资源：

● 本书思维导图；

● 各章思考和练习题的答案；

● 配套彩图文件；

● 异步社区7天VIP会员。

要获得以上资源，您可以扫描下方二维码，根据指引领取。

提交勘误

作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。

当您发现错误时，请登录异步社区（https://www.epubit.com/），按书名搜索，进入本书页面，单击“发表勘误”，输入勘误信息，单击“提交勘误”按钮即可（见右图）。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。

与我们联系

我们的联系邮箱是contact@epubit.com.cn。

如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。

如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们。

如果您所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。

如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。

关于异步社区和异步图书

“异步社区”是由人民邮电出版社创办的IT专业图书社区，于2015年8月上线运营，致力于优质内容的出版和分享，为读者提供高品质的学习内容，为作译者提供专业的出版服务，实现作者与读者在线交流互动，以及传统出版与数字出版的融合发展。

“异步图书”是异步社区策划出版的精品IT图书的品牌，依托于人民邮电出版社在计算机图书领域的发展与积淀。异步图书面向IT行业以及各行业使用IT的用户。

第1章　金融软件测试概述

本章导读

本章主要介绍软件测试发展、软件测试分类、软件测试模型以及金融软件测试发展、金融软件测试类型等内容。通过对本章知识的学习，您应该能够对金融软件测试有初步的了解和认识，为后续学习做好准备。

1.1　软件测试概述

1.1.1　软件测试发展

随着互联网的快速发展，软件的规模不断扩大，复杂程度大幅度提升，用户对软件质量的要求也越来越高。除了基本的功能需求，用户对软件的性能以及数据安全性等方面的要求也越来越高。在软件的整个研发过程中，开发人员的开发工作非常重要，测试人员的测试工作更是保证软件质量的关键。

软件测试是伴随着软件开发而产生的。软件测试发展到现在大致经历了5个重要的时期，在每个时期，人们对软件测试都有着不同的认识和理解，对软件测试的定义也有所不同。

1.1.1.1　第一个时期（1957年之前）：调试为主

20世纪50年代，那时候软件自身的规模很小、复杂度低，通常由开发人员自己承担需求分析、设计、开发和测试等工作。软件开发的过程混乱无序、相当随意，还没有明确的测试概念。开发人员误以为测试等同于调试，目的都是纠正软件中已经知道的故障，常常自己完成这部分工作，但实际上这部分工作不能算是真正的软件测试。这个时期对测试的投入极少，测试介入得比较晚，常常是等到形成代码，产品已经基本定型时才进行测试。

1.1.1.2　第二个时期（1957～1978年）：证明为主

1957年，Charles L. Baker在《软件测试发展》一书中对调试和测试进行了区分：调试是确保程序做了程序员想让它做的事情；测试是确保程序解决了它该解决的问题。这是软件测试史上一个重要的里程碑，它标志着测试终于自立门户了。这个时期计算机应用的数量、成本和复杂性都大幅度提升，测试的重要性也大大增强，这个时期测试的主要目的就是证明软件是满足要求的，也就是说“做了该做的事情”。

1.1.1.3　第三个时期（1979～1982年）：破坏为主

1979年，Glenford J. Myers在测试界的经典之作《软件测试的艺术》（The Art of Software Testing）一书中对测试重新进行了定义：“测试是为发现错误而执行程序的过程”。因此不要只是为了证明程序能够正确运行而去测试软件；相反，应该一开始就假设软件中隐藏着错误，然后去测试程序，发现尽可能多的错误。这个观点较之前以证明为主的观点，有很大的进步，也被称为“证伪”。它暗示了软件测试是一个具有破坏性的过程，这意味着我们不仅要证明软件做了该做的事情，也要证明它没做不该做的事情，这样才会使软件测试更加全面，更容易发现问题。这个时期的测试目的主要是找出软件中潜在的错误，所以说它是以破坏为主的。这也使得软件测试和软件开发独立开来，测试需要更为专业的人员进行。

1.1.1.4　第四个时期（1983～1987年）：评估为主

1983年，Bill Hetzel在《软件测试完全指南》（The Complete Guide of Software Testing）一书中指出，“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量”。软件测试的定义又发生了改变，测试不单纯是一个发现错误的过程，还作为软件质量保证（Software Quality Assurance，SQA）的主要职能，包含软件质量评价的内容。

在这个时期，软件规模逐渐扩大、复杂度越来越高，人们开始为软件开发设计各种流程和管理方法，并提出了在软件生命周期中通过分析、评审、测试来评估产品的理论，软件测试工程在这个时期得到了快速的发展，并且形成了行业标准（IEEE/ANSI）。1983年IEEE在软件工程术语中给软件测试赋予了新的定义，即“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出软件测试的目的是检验软件系统是否满足需求。软件测试不再只是开发后期的活动，而与整个开发流程融合成一体。

1.1.1.5　第五个时期（1988年至今）：预防为主

在这个时期，人们已经开始意识到，软件测试不应该仅是事后用来证明软件是对的或是不对的，而应该走向前端，进行缺陷预防。Dave Gelperin和Bill Hetzel在1988年发表的一篇名为《软件测试的发展》（“The Growth of Software Testing”）的文章中提到：预防为主是当下软件测试的主流思想之一。STEP（Systematic Test and Evaluation Process，系统化测试和评估过程）是最早以预防为主的生命周期模型，STEP 认为测试与开发是并行的，整个测试的生命周期是由计划、分析、设计、开发、执行和维护组成的。也就是说，软件测试不是在开发完成后才开始介入，而是贯穿于整个软件生命周期。我们都知道，没有 100%完美的软件，零缺陷是不可能的，所以我们要做的是尽量早地介入，尽量早地发现明显的或隐藏的缺陷，发现得越早，缺陷修复的成本就越低，产生的风险也越小。

1.1.2　软件测试分类

软件测试是一项复杂的工程，软件测试方法种类繁多，有白盒测试、黑盒测试、静态测试、动态测试、集成测试、功能测试等。从不同的角度考虑可以有不同的划分方法，对软件测试进行分类是为了更好地明确软件测试的过程，了解软件测试究竟要完成哪些工作，尽量做到全面测试。本书也从不同的角度对软件测试进行了划分，详情可参见表1-1。

表1-1　软件测试分类

接下来针对表1-1中的软件测试分类，分别做相应的介绍。

（1）按照测试设计方法进行分类，软件测试主要分为以下3种。

● 黑盒测试：又称数据驱动的测试或输入输出驱动的测试。它把测试对象当成一个看不见的黑盒子，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范，确定测试用例和推断测试结果的正确性。它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。黑盒测试注重于测试软件的功能性需求，着眼于程序外部结构，不考虑内部逻辑结构。

● 白盒测试：又称结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。测试者可以看到软件系统的内部结构，清楚盒子内部的东西以及内部是如何运作的，可以使用软件的内部结构和知识来指导测试数据及测试方法的选择。

● 灰盒测试：是介于黑盒测试与白盒测试之间的一种综合测试方法，是基于程序运行时的外部表现，同时结合程序内部逻辑结构来设计测试用例、执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。

（2）按照测试阶段进行分类，软件测试主要分为以下4种。

● 单元测试：又称模块测试，是针对软件设计的最小单元（程序模块或函数等）进行正确性检验的测试工作。目的在于检验程序模块或函数等是否存在各种差错，是否能正确地实现其功能。

● 集成测试：又称组装测试或联合测试，其在单元测试的基础上，将所有已经通过单元测试的模块按照设计要求组装成子系统或系统进行测试。集成测试主要用来检查各个单元模块结合到一起能否系统性地配合并正常运行。

● 系统测试：是将整个软件系统看作一个整体进行的测试，需要对功能、性能，以及软件所运行的软件和硬件环境等进行测试。系统测试的主要依据是“系统需求规格说明书”。

● 验收测试：是在系统测试之后进行的测试，以用户测试为主，或由质量保障人员共同参与，是软件正式交给用户使用前的最后一道工序。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

（3）按照是否手工执行进行分类，软件测试主要分为以下两种。

● 手工测试：不使用任何测试工具，由测试人员逐个执行事先设计好的测试用例，通过键盘、鼠标等输入一些参数来测试系统各功能模块，对比软件返回的实际结果是否与测试用例中的预期结果一致。在手工测试中，每个需要测试/验证的功能点都需要人为地逐个验证。当软件经过版本迭代后需要进行回归测试时，使用手工测试效率相对较低，但目前手工测试仍然是无法被替代的一种测试方法。

● 自动化测试：把手工执行的测试过程，转变成机器自动执行的测试过程。通常我们所说的自动化测试是指功能自动化测试，即通过自动化测试工具或其他手段，按照测试人员的测试计划进行自动化测试。相对于手工测试而言，自动化测试主要体现在自动化测试工具，通过编写代码模拟人工操作，这样就可以通过重复执行程序来进行重复的测试。如果软件有一小部分发生改变，只需要修改一小部分代码，就可以重复对软件进行自动化测试，这样可以减少手工测试的工作量，提高测试效率和软件质量。

（4）按照测试方向进行分类，软件测试主要分为以下3种。

● 功能测试：检查软件系统各个功能模块的实际功能是否符合用户的需求。测试的大部分工作主要围绕软件的功能进行。功能测试又可以细分为界面测试、易用性测试、安装测试、兼容性测试等。

● 性能测试：验证软件系统的性能是否满足需求规格说明书中给定的指标要求。性能测试主要是通过性能测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

● 安全测试：对软件产品进行测试以确保产品符合安全需求定义和产品质量标准。

（5）按照测试状态进行分类，软件测试主要分为以下两种。

● 静态测试：指不实际运行被测软件程序，只是通过代码检查、文档评审、程序分析等手段对被测软件进行检测的技术。

● 动态测试：指通过运行和使用被测软件程序，输入相应的测试数据来检查实际运行结果和预期结果是否一致的技术。动态测试是目前企业实施项目测试的主要方式。

除了以上几种分类中所涉及的测试类型以外，在实际测试中我们还会遇到诸如冒烟测试（指正式测试前的测试，目的是检查软件是否具备可测试性，确保软件的基本功能正常）和回归测试（指修改旧代码后，重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误）等其他测试。每一种测试都有各自的特点和适用场景，通过对本节的学习，读者可以结合平时所测项目对本节内容加以理解和应用。

1.1.3　软件测试模型

软件测试在软件的生命周期中占有重要地位，它能发现程序中的错误、降低代码出错风险、保证代码质量。在传统的瀑布模型中，软件测试只是其阶段性工作的一部分——进行代码的测试。而在现代化软件工程中，软件测试是贯穿整个软件生命周期，保证软件质量的重要手段之一，是软件工程化非常重要的一个环节。

在软件开发的实践过程中，人们总结出很多软件开发生命周期模型，这些模型都有其独特的阶段，都给特定的软件开发项目或团队带来了有利和不利的影响，比较典型的软件开发生命周期模型有边做边改模型、瀑布模型、快速原型模型、螺旋模型、增量模型、演化模型、喷泉模型、智能模型、混合模型、RAD（Rapid Application Development，快速应用开发）模型以及基于网络、面向对象的RUP（Rational Unified Process，统一软件开发过程）模型。但这些软件开发生命周期模型没有给予测试足够的重视和诠释，所以才会有软件测试模型的诞生。这些软件测试模型兼顾了软件开发过程，对开发和测试做了很好的融合。这些软件测试模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。本节主要介绍以下几种软件测试模型，分别为瀑布模型、V模型、W模型、H模型和敏捷模型。

1.1.3.1　瀑布模型

瀑布模型由瀑布开发模型演变而来，是面向过程的软件测试模型。在软件项目的整个阶段，图1-1所示的瀑布模型分为制订可行性计划、需求分析、系统设计、软件编码、软件测试和运维6个基本阶段。其过程是将上一阶段接收的工作对象作为输入，当该阶段完成后会输出该阶段的工作成果，并将该阶段的工作成果作为下一阶段的输入。该模型规定这6个基本阶段自上而下、相互衔接，如同瀑布流水，逐级下落。从本质上讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从需求分析直到产品发布和维护。如果在其中某个阶段有信息未被覆盖或有问题，就要返回到上一阶段，并对该阶段进行适当的修改才能进入下一阶段。这样每个阶段都会产生循环反馈，开发过程从一个阶段“流动”到下一阶段，这也是瀑布模型名称的由来。

图1-1　瀑布模型

瀑布模型强调阶段的划分和各阶段工作及其文档的完备性，并要求每个阶段都有相应的检查点，当前阶段完成后，方可进入下一阶段。对于用户需求非常明确，并且在开发过程中没有或很少有变化的项目来说，正确使用瀑布模型可以提高效率、节省时间和降低成本。但在实际的项目开发过程中，项目的需求可能会经常变更，针对这种情况，采用瀑布模型有些不切实际。在瀑布模型中，由于每个阶段严格按照线性方式来执行，用户只有在整个阶段的后期才能见到开发的成果，而且在需求分析或系统设计中出现的错误也只能在项目后期的软件测试中才能够被发现，在无形中增加了项目开发的风险，从而导致后期修复成本的增加和更为严重的后果出现。

1.1.3.2　V模型

V模型是瀑布模型的变种，最早是由已故的Paul Rook在20世纪80年代后期提出的，目的在于提高软件开发的效率，改善软件开发的效果。它不再把软件测试看作一个事后的弥补行为，而是将其作为一个与开发同等重要的过程，反映了软件测试与分析、设计、编码的紧密关系。在图1-2所示的V模型中，从左至右分别描述了基本的软件开发过程和测试过程，左边是开发过程的各个阶段，右边是测试过程的各个阶段。图 1-2 中明确地标注了测试过程中存在的不同类型的测试及其与相应开发阶段的对应关系，将测试过程加在开发过程的后半部分，每一个开发阶段都对应一种类型的测试，使每一个开发阶段都能够被检测到。

图1-2　V模型

V模型常常忽视了软件测试对需求分析、概要设计等阶段的验证和确认。由于软件测试介入较晚，只能在软件开发结束之后才开始，没有涉及需求分析、概要设计、详细设计等前期工作，因此不能发现这些前期工作产生的缺陷，这些缺陷往往在后期的系统测试和验收测试中才能被发现，从而导致软件修复的代价增加。

V模型在测试模型中的地位，如同瀑布模型在开发生命周期模型中的地位，是一种最基础的测试模型，其他测试模型都是从V模型演化而来的。

1.1.3.3　W模型

W模型是V模型的扩展，相对于V模型，W模型更加科学。W模型在V模型的基础上增加了软件各开发阶段应同步进行的测试，强调测试伴随着整个软件开发生命周期，而且测试的对象不仅仅是软件，需求、功能和设计同样需要测试。从图1-3中可以看到，W模型由两个V模型组成，也称双V模型，开发是一个“V”，测试是与开发并行的“V”。W模型与V模型的不同之处在于，W模型中的测试是从需求分析开始的，软件测试人员在需求分析阶段就参与项目测试，而不是等到软件编码完成后才开始测试，这样可以尽早地发现需求分析阶段的缺陷。而且测试阶段划分得更加详细和清楚，不仅包含后期的单元测试、集成测试、系统测试和验收测试等，还包含前期的测试计划和测试方案设计等内容。在W模型中，测试与开发是同步进行的，有利于尽早地发现问题。

图1-3　W模型

W模型也存在局限性，W模型和V模型都把软件的开发视为需求分析、设计、编码等一系列串行的活动，同时测试过程和开发过程保持着一种线性的前后关系，上一阶段完全结束，才可以开始下一阶段的工作，无法支持迭代、自发性以及变更调整。面对当前软件开发复杂多变的情况，W模型仍无法解决测试管理所面临的一些问题。

1.1.3.4　H模型

H模型将测试从开发流程中分离出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地展现出来。H模型认为软件测试是一个独立的流程，贯穿于产品的整个生命周期，与其他流程并发进行，所以在H模型中并没有关于开发的流程，只有关于测试的流程，测试的流程并没有像V模型和W模型那样进行明确的区分。

图1-4所示的H模型中的流程仅仅演示了在整个生命周期中某个层次上的一次测试“微循环”。当测试条件准备完成，进入测试就绪状态后，H模型中就有一个测试就绪点，即测试的一个准入标准。图1-4所示的H模型中的其他流程可以是任意开发流程（如开发阶段的一些设计流程等）。当测试条件成熟了，并且测试准备活动已经完成，进入测试就绪点，测试就可以执行了。

图1-4　H模型

H模型与V模型和W模型的不同之处在于，H模型的核心是将软件测试过程独立出来，并贯穿产品的整个生命周期，与开发流程并行进行，无须等到程序全部开发完成后才开始执行测试，这充分体现了软件测试要“尽早准备，尽早执行”的原则。H模型强调测试是独立的，只要测试准备完成，就可以执行，而且测试可以根据被测对象的不同而分层次、分阶段、分次序地执行，测试还是可以被迭代的，若一次测试工作完成后，产品质量无法达到要求，可以反复进行多次测试。

虽然 H 模型足够灵活，但这也造就了它难以驾驭的特点，实际使用中也有一定的局限性。该模型太过于模型化，对管理者要求比较高，需要其清晰地定义规则和管理制度；如果管理者没有足够的经验就实施 H 模型，测试过程将很难管理和控制，可能导致事倍功半，测试活动的成本收益比会比较低。H模型对测试工程师的技能要求也比较高，要求其能够很好地定义每个迭代的规模，不能太大也不能太小；软件测试人员能够准确管理测试活动和判断测试就绪点。如果不知道测试准备到什么时候是合适的，测试就绪点在哪里，就绪标准是什么，会为后续的测试执行启动带来很大的困难。H模型对整个项目团队的协作要求也比较高，如果其中一个迭代无法有效完成，那么整个项目就会受到很大的影响。

1.1.3.5　敏捷模型

在业务快速变换的环境下，人们往往无法在软件开发之前收集到完整而详尽的软件需求。没有完整而详尽的软件需求，传统的软件开发生命周期模型就难以展开工作。敏捷模型就是为了解决此类问题，在互联网的快节奏下应运而生的一种软件测试模型。在敏捷模型中，软件项目在构建初期被拆分为多个相互联系而又独立运行的子项目，然后迭代完成各个子项目，在开发过程中，各个子项目都要经过软件测试。当客户有需求变更时，敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。在这个过程中，软件一直处于可使用状态。在敏捷模型中，软件开发不再是线性的，开发的同时会进行测试工作，甚至可以提前写好测试代码，因此敏捷模型有“开发未动，测试先行”的说法。

敏捷模型的具体流程如图1-5所示，分为如下步骤。

图1-5　敏捷模型的具体流程

（1）根据用户的产品需求进行需求分析，并形成需求文档。

（2）对需求文档进行需求评审，参与评审的人员有产品经理、开发人员、测试人员、QA人员。

（3）需求评审结束之后，开发人员根据需求文档编写开发计划，同时测试人员也要介入项目中编写测试计划。

（4）开发人员根据开发计划进行产品开发，同时测试人员根据测试计划开始着手重复测试用例的编写。测试用例编写完成后，由产品经理、开发人员、测试人员、QA人员等评审。

（5）开发计划和测试用例通过评审之后，开发人员开始编写代码。

（6）开发人员编写完成代码并提交后，由运维人员部署测试环境，测试人员根据测试用例开始进行测试。

（7）测试人员在执行测试的过程中，如果出现bug，将出现的bug进行汇总，交由开发人员进行修复。

（8）重复（6）、（7）步骤，修复后进行回归测试，等全部测试用例通过测试不再出现bug后，进行下一步操作。

（9）编写测试完成报告。

（10）输出测试完成报告后产品经理进行项目验收。

（11）验收通过后发布上线。

相对于传统测试模型，敏捷模型不再有明显的阶段性，测试人员可以更早地加入项目团队，根据项目制订测试计划，和开发团队一起参与讨论，进行需求评审、计划编写、测试用例编写、决策制定等。在敏捷模型中，测试人员需要全程参与整个项目开发活动，当客户需求变更、计划调整时，能更快地应对。

1.1.4　软件测试阶段

软件测试按照测试阶段通常可分为单元测试、集成测试、系统测试和验收测试4个阶段，如图1-6所示。

图1-6　软件测试阶段

1.1.4.1　单元测试

单元测试是对开发人员编写完成的一个个程序单元进行测试，软件测试的对象是软件设计的最小单元——通常是模块、类或函数。通过对每个程序单元内部进行测试，以便发现程序单元内部的错误，从而检验软件基本组成单元的正确性。

单元测试是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节，是唯一能够保证代码覆盖率达到100%的测试，是整个软件测试过程的基础和前提。程序员在编程过程中，每写100行代码大约会犯150个错误；编写与编译、运行结束后，每100行代码中残留1～3个缺陷。而寻找与修改程序缺陷的代价占总体开发投资的40%～80%。缺陷在整个开发流程中被发现得越早，修改的代价就越低，所以单元测试可以防止开发的后期因缺陷过多而失控，单元测试的性价比是最高的。

据统计，大约有80%的软件缺陷是在软件设计阶段引入的，并且修正一个软件缺陷的成本将随着软件生命周期的进展而上升。缺陷发现得越晚，修复它的费用就越高，而且呈指数级增长的趋势。

1.1.4.2　集成测试

集成测试是在单元测试的基础上，将所有已经通过单元测试的模块按照设计要求组装成子系统或系统进行测试，目的是确保这些不同的软件模块之间通信和交互的正确性。在进行集成测试之前，需要确保单元测试已经完成。如果没有经过单元测试，那么集成测试的效果会受到很大的影响，并且会大幅增加软件单元代码纠错的代价。

既然单元测试已经通过了，为什么还需要进行集成测试？因为很多时候一些模块单独运行可以正常工作，但是不能保证把这些模块连接起来以后也能正常工作，由于各种原因，系统中可能仍旧存在缺陷，如下所示。

● 在实际的项目开发中，会涉及很多的功能模块，每个模块可能会由不同的软件开发人员进行开发和设计，每个开发人员对模块的理解和编程逻辑也会有所不同，通过进行集成测试，可以验证软件模块是否可以统一工作。

● 有些时候，当数据从一个模块传递到另外一个模块时，数据的结构会发生变化。程序中对于系统异常情况考虑得不充分有可能会导致问题的出现。

● 在项目模块开发时，客户可能会频繁更改需求，往往会导致新的需求没有进行单元测试，此时集成测试就显得非常重要。

● 有些模块会与第三方工具或API进行交互，要确保第三方工具或API接收的数据是正确的，就需要进行集成测试。

集成测试通常采用黑盒测试和白盒测试相结合的测试技术，关于黑盒测试用例的设计方法，第6章将给出详细的介绍，读者可对这部分内容进行学习；白盒测试通常由开发人员来完成，本书暂未涉及。

1.1.4.3　系统测试

系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合，在实际运行环境下对计算机系统进行一系列严格、有效的测试，以发现软件潜在的问题，保证系统的正常运行。系统测试的对象不仅包括需要测试的软件，还包括软件所依赖的硬件、外设，甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在实际运行环境下进行测试。

系统测试的目标是通过对照系统需求规格说明书，检查软件是否存在与系统需求规格说明书不符合或矛盾的地方，从而验证软件的功能和性能等是否满足需求规格说明书所制定的要求。

系统测试是基于需求规格说明书的黑盒测试，以功能测试为主，还包括性能测试、安全测试、可靠性测试、稳定性测试等。下面简单介绍在金融软件测试中常见的几种系统测试。

（1）功能测试是系统测试中最基本的测试，它不考虑软件内部的实现逻辑，主要根据软件的需求规格说明书和测试需求列表，验证软件的功能实现是否符合软件的需求规格说明书。功能测试主要是为了发现以下几类错误。

● 软件中是否有不正确或遗漏的功能？

● 功能实现是否满足用户需求和系统设计的隐藏需求？

● 软件是否有明确的数据接收输入？数据接收输入是否有正确的数据输出结果？

（2）性能测试是指测试软件在集成系统中的运行性能，目标是度量软件的实际性能和预先定义的目标有多大差距。一种典型的性能测试是压力测试，即当系统同时接收极大数量的用户访问和用户请求时，测试系统的应对能力。性能测试要有工具的支持，当然也不是所有场景都可以被性能测试工具覆盖，面对一些特殊需求，还是需要测试人员自己设计测试脚本或测试用例来完成。

（3）安全测试是指验证系统的保护机制是否能够抵御入侵者的攻击。保护测试是安全测试中一种常见的测试，主要用于测试系统的信息保护机制。

有关功能测试和性能测试相关的内容，在本书后续章节中会进行详细介绍。

1.1.4.4　验收测试

验收测试是测试的最后一个阶段，是在软件产品正式投入运行前所要进行的测试。由于测试人员不可能完全模拟用户的实际使用情况，所以软件是否真正满足最终用户的需求，应由用户进行一系列的验收测试。验收测试的目的是确保软件准备就绪，向用户展示所开发的软件能够满足合同或用户所规定的需求，验证软件实际工作的有效性和可靠性，确保最终用户能用该软件顺利地实现既定功能和执行既定任务。

验收测试可以是有计划、系统的正式测试，也可以是非正式的测试。正式验收测试一般称为用户验收测试（User Acceptance Test，UAT），通常由熟悉业务流程的用户或独立的测试人员来完成，通过使用已经完成系统测试后的应用程序，根据测试计划和执行结果来验证需求是否被有效地传达和执行。非正式验收测试又分为Alpha测试（α测试）和Beta测试（β测试）。Alpha测试是指软件开发公司组织内部人员通过模拟各类用户行为对即将上市的软件产品（称为Alpha版本）进行测试，试图发现错误并修正，通常是由用户、测试人员、开发人员等共同参与的内部测试（内测）。Alpha测试的关键在于尽可能逼真地模拟系统实际运行环境和用户对软件产品的操作，并尽最大努力涵盖用户所有可能的操作方式。而Beta测试指的是内测后的公测，即软件完全交给最终用户测试，经过Alpha测试调整的软件称为Beta版本。软件开发公司组织各领域的典型用户在日常生活中实际使用Beta版本，并要求用户报告异常情况、提出批评意见，软件开发公司对Beta版本进行修正和完善后，再将软件产品交付给用户使用。

1.1.5　本节小结

本节主要介绍了软件测试发展的不同时期对软件测试的不同理解和定义，通过对软件测试进行不同角度的分类以及进行软件测试模型的介绍，方便读者了解每一种测试都有各自的特点和适用场景。读者需要理解每种测试的方式和意义，并结合后续章节的介绍将相应测试技术在实际测试工作中加以运用。

1.2　金融软件测试概述

金融软件测试在传统软件测试的基础上增加了行业属性，金融行业包含银行业、保险业、信托业、证券业和租赁业等。金融软件测试依然在软件测试的范畴中，依据自身的行业属性与特点，在某些软件测试的分类中有更加细节化的测试要求。本节首先通过介绍金融行业IT发展的历史，从软件测试领域出发，阐述不同时期金融软件测试工作的变化，并根据软件测试在金融行业多年的发展历程，介绍金融软件测试人员的能力要求及发展方向；最后结合金融行业的业务特性，介绍金融软件测试方法和应用。

1.2.1　金融软件测试发展

在金融的发展历程中，12世纪出现了银行的雏形，16世纪中期出现了股票，18世纪保险业开始出现。20世纪60年代，银行、证券、保险业纷纷引入IT系统来逐渐代替手工作业，这标志着金融业务信息化历程的开始^[1]。而软件测试所扮演的岗位、角色、职责变化离不开整体金融IT架构的发展。针对不同时期金融IT架构的升级换代，本书将金融软件测试的发展历程分为5个时期。

[1]　邬德云. 中国金融IT的发展研究[J]. 上海金融学院国际金融研究院, 2010-09-27.

1.2.1.1　第一个时期（脱机业务的处理）：隶属于开发团队的测试人员

20世纪70年代，首家大型国有银行引进了第一套理光-8（RICOH-8）型主机系统进行金融业务的运营，揭开了我国金融电子化发展的序幕。将银行的部分手工业务由计算机来进行处理，实现了对公业务、储蓄业务、联行对账业务、编制会计报表等日常业务的自动化处理，大大提高了银行业务处理的效率。而此时的IT系统仅在银行内部使用，主要用于实现从人工处理到机器处理的转变，还不涉及联网的工作。此时，测试人员隶属于开发团队，测试团队由开发团队统一管理。由于对技术要求不高又缺少对专业测试人员的重视，大多数开发团队甚至没有专业的测试人员，系统的软件测试工作由开发人员、售后人员、项目经理或者业务人员来完成。

1.2.1.2　第二个时期（联机业务的处理）：独立的测试人员

随着IBM公司的SAFEII系统的引入，我国金融行业开启了IT发展之路。借助于一个完整的商业应用，SAFEII落地大型银行并做定制化的改造。随着银行的业务规模不断扩大，对于系统开发人员和测试人员的需求不断加大。我国金融行业内的信息化之路也让独立测试人员的专业性和必要性逐渐凸显出来。1991年4月1日，中国人民银行的中国金融卫星通信网络系统上电子联行正式运行，这标志着我国银行信息系统进入全面网络化阶段。除此之外，各大银行在一些大中城市还建立了各种形式的自动化的同城票据交换系统。随着系统规模的扩大，专业的测试人员投入各个系统上线前的紧张测试工作中。他们具备丰富的金融行业业务知识和IT测试知识，保证了各个软硬件系统在拓展过程中的稳定运行。

1.2.1.3　第三个时期（中国加入WTO，金融体制改革）：独立的测试团队

随着中国加入WTO以及互联网时代的到来，金融体制改革、股份制改造等一系列金融行业重大改革接踵而至。银行业一马当先，一方面积极把握历史机遇，另一方面准备做数据大集中和业务流程重组。这个时期银行业的主要目标是全国范围内的银行计算机处理联网、互联互通、支付清算、业务管理及办公逐步实现计算机处理等。金融公司之间、金融行业的系统与外部系统之间的互联互通，决定了要有独立的测试团队才能确保金融业务网络运行的稳定性。这个时期的软件测试工作由测试经理统一管理，测试经理和开发经理在管理权限上是平级的，测试经理有权根据系统项目的测试结果进行整体风险评估，来决定是否允许被测系统上线运行。

1.2.1.4　第四个时期（经营决策的信息化）：质量管理体系建立（测试中心成立）

互联网金融的高速发展使金融科技真正渗入金融行业最核心的业务，并且根据互联网的特点，衍生出一系列风险评估的新方式。新时代下的新技术、新思维影响着金融行业经营决策的方向，金融机构纷纷进行技术转型。为提高IT资源利用率、降低运行成本，各家银行纷纷全面部署服务器虚拟化。IT 系统架构的变革催生了质量管理体系，金融 IT 发展领域中的“头部”企业纷纷成立了各自的测试中心。功能测试、性能测试、自动化测试、需求分析、产品验收、质量评估与管理等专业职能，在软件测试工作领域内部明确划分出具体的职责岗位，形成了由专业的测试模块组成的职能完整的测试中心。同时，IT系统架构经过多年的发展，不断完善的质量管理体系促使测试中心采用数据化的指标来评估系统风险，精细化管理系统质量，产出的测试数据也可用来评估软件的运行风险，测试的地位获得了进一步的提升。IT已经成为金融行业未来创新发展的最佳驱动力。

1.2.1.5　第五个时期（金融科技FinTech时期）：运维部署、配置管理、版本管理与软件测试融合的趋势

2016年，金融稳定理事会（Financial Stability Board，FSB）对金融科技提出了明确定义：金融科技是技术驱动的金融创新，旨在运用现代科技成果改造或创新金融产品、经营模式、业务流程等，推动金融发展提质增效^[2]。目前全球（金融科技领域）对这一定义已达成共识。多家机构纷纷成立名下的金融科技子公司，基于云架构来构建分布式应用，并结合云计算、大数据等新技术手段进行智能化决策。这一时期的测试工作，已经将环境运维部署、配置管理、版本管理纳入测试中心的常规工作，从制度流程上保证质量整体管控措施的落地。同时，在实践中真正将软件测试工作在系统开发的生命周期中前置，使测试参与到需求和产品的定制中来。在金融业务或新增功能开发项目启动的早期，测试人员的介入可以定位到软件中可能出现的缺陷，同时排除整体系统上线流程中各个节点可能存在的程序以外的问题。随着对软件测试重视程度的加深，软件测试的效率有了很大提升，从系统需求提出到软件开发上线的时间也被大大缩短^[3]。

[2]　银发〔2019〕209号. 金融科技（FinTech）发展规划（2019—2021年），中国人民银行网站，2019-09-06.

[3]　冯文亮，曹栋. 金融科技时代银行业软件测试的思考与实践[J]. 中国金融电脑，2016(11):20-24.

1.2.2　金融软件测试类型

金融业务领域较为广泛，包括银行、保险、证券、基金、互联网金融等，由于金融业务系统以及相关联的系统一般比较复杂，所以对金融软件测试人员的业务能力和技术能力的要求也相对比较高。我们要保证软件产品质量，就需要遵循软件测试行业标准，无论是V模型，还是W模型，通常按照测试阶段可依次分为单元测试、集成测试、系统测试和验收测试等；按照测试设计方法可分为黑盒测试、白盒测试和灰盒测试等；按照测试方向又可分为功能测试、性能测试、自动化测试、安全测试、兼容性测试、用户体验测试、接口测试和文档评审等。

针对金融软件测试的特点，我们将从功能测试、性能测试、自动化测试、安全测试、兼容性测试、用户体验测试、接口测试和文档评审等方面来对金融软件测试加以介绍（详细内容参见表1-2）。

表1-2　金融软件测试类型

1.2.2.1　金融软件功能测试

功能测试主要是针对软件系统的功能进行验证，验证软件系统各个功能是否按照软件的《需求规格说明书》《软件概要设计》《软件详细设计》和《需求变更》等文档要求进行设计。金融行业的软件功能测试，同样需要根据软件的《需求规格说明书》等需求文档来验证金融业务系统是否满足系统设计需求。例如，软件系统功能模块是否能够正常工作；系统的输入和输出是否正确；系统是否能够完整地模拟用户的使用场景，是否能够满足用户的业务需求；系统是否符合正常业务流程，是否具有合理的业务逻辑等。

在金融软件功能测试过程中，功能界面测试、业务流程测试、业务场景测试、业务规则测试几个方面既要分层又要相互结合，系统业务流程节点的规则变化会导致流程分支变化，系统界面要素不同的数据输入产生的输出数据也会流向不同的流程节点，最后数据流向不同的业务流程分支，我们在测试过程中，需要充分考虑，不要出现遗漏。

1．功能界面测试

金融软件功能界面测试也是金融软件功能测试的主要测试点和关注点之一。金融软件功能界面通常包括客户的操作界面，以及面向系统后台管理者的维护、预警和统计界面等。

金融软件功能界面测试用例的设计是功能测试用例设计中最容易上手的部分，也是最容易遗漏的部分。因为在金融软件系统中功能界面是最直观的，测试人员在系统原型图或系统界面中可以直接看到功能界面，其中的输入框、选项框和功能按钮等一目了然。测试用例设计相对比较简单，但由于功能界面输入项比较多，涉及输入项的字段类型和字符长度等限制，在测试过程中如何把这些输入项的各种情况结合起来，又不发生遗漏，是对测试人员的测试分析和用例设计的挑战。

2．业务流程测试

金融软件业务流程测试的首要目的是保证系统业务流程及功能符合实际金融业务的使用场景，业务流程首先要符合金融背景下的业务工作流程，并且保证业务流程处理的结果准确无误。金融软件测试通常通过事件触发来控制业务流程，事件不同和触发的时机不同，会进入不同的流程场景。

金融软件业务流程的正确性和完整性在测试过程中需要重点关注，业务流程上相应的功能点需要测试人员进行严谨的测试与验证。业务流程处理过程中可能会涉及业务规则判断、数据异常处理、判断任务状态是否有效等情况，这些业务场景组成了金融业务的主流程和备选流程，我们在测试过程中需要遍历所有的业务流程。

3．业务场景测试

金融业务一般情况下会以各种金融业务场景来体现，我们通常会把相关联的业务流程串起来，结合各种业务状态和业务流程，形成一个个金融业务场景。我们在金融业务场景测试过程中需要重点关注数据和业务流向的正确性和完整性。

4．业务规则测试

金融业务规则是指对金融业务的定义和约束的描述，用于维持金融业务结构或控制和影响金融业务的行为。例如，手机银行的注册功能中，用户和游客就要走不同分支的业务流程。再如，银行Ⅰ、Ⅱ、Ⅲ类结算账户在受到银行业务规则的单笔限额、日累计限额和年累计限额控制的同时，也会受到用户个人自定义限额的控制。

金融软件业务规则测试是金融软件功能测试主要的测试点和关注点之一。我们在金融软件系统的业务规则测试过程中，一定要对业务规则进行重点分析和测试，它不仅影响业务走向，也影响金融业务的合规性。我们在设计业务规则测试用例时，一般采用等价类分析法和边界值分析法等测试用例设计方法。

1.2.2.2　金融软件性能测试

金融软件系统由于其交易属性，对于系统自身的稳定性、健壮性、传输效率的要求较高，同时由于行业属性的限制，只有提前定义好业务模型和测试指标才能做到有效的性能测试。金融软件性能测试所包含的测试类型较为全面，常见的测试场景均有涉及，具体包含基准测试场景、单交易负载测试场景、混合交易负载测试场景、峰值测试场景、容量测试场景、稳定性测试场景等。为了降低金融软件系统由于性能原因可能带来的商业损失，保证在大压力情况下业务系统的正常运行是每一个性能测试工程师应该关注的重点，更是保证软件质量的关键。

一般的性能测试需要借助工具来进行，常见的工具有LoadRunner、JMeter、JAPT等。

通常性能测试过程中需要关注系统的性能指标包括但不限于以下8项。

（1）事务响应时间。

（2）每秒事务数。

（3）系统最大和最佳并发数/在线数。

（4）服务器资源使用情况。

（5）系统长时间运行的稳定性。

（6）系统在峰值期间的处理能力。

（7）系统资源释放情况。

（8）系统响应错误数。

在金融软件性能测试过程中，我们需要对以上性能指标数据进行实时记录和统计。如果在性能测试过程中发现性能问题，需要结合对操作系统、数据库、存储、网络、中间件和金融系统等的监控来进一步分析和定位性能问题，找到影响系统性能的瓶颈。

1.2.2.3　金融软件自动化测试

由于金融软件系统前期功能界面元素变动比较大，自动化测试脚本维护成本比较高，所以往往会在系统稳定后再进行自动化测试，这样可以提升软件测试的精确率和测试效率，同时可以降低人员成本。自动化测试可以高效地完成金融软件系统稳定业务模块的回归测试，以及以数据为驱动的、验证多个枚举值的组合场景测试。金融软件自动化测试需要测试人员有一定的自动化脚本开发和维护能力，一般构建自动化测试的步骤包括：搭建自动化框架、录制和开发自动化脚本、调试脚本、脚本试运行、自动化测试执行和生成测试报告等。

1.2.2.4　金融软件安全测试

安全测试是对软件产品进行测试以确保产品符合安全需求定义和产品质量标准。金融行业的数据有着非常高的敏感性，金融业务系统在网络、数据、运维、认证和软硬件等方面都有很高的安全要求。我国的银行、保险和证券等金融机构都有着很高的安全防控和管理水平。但是由于金融行业的发展，金融软件系统需要不停地更新来满足用户需求，系统可能存在安全漏洞，这时候金融软件安全测试就显得尤为重要了。金融行业的企业一般会定期进行金融安全防控演练，有效地保证它们应对突发安全事件的处理能力。

常见的金融软件安全测试有静态代码安全测试、动态渗透测试和程序数据扫描等，测试内容一般覆盖如下安全验证点。

（1）操作系统安全：补丁升级、配置和安全加固。

（2）数据库安全：补丁升级、配置和安全加固。

（3）网络安全：补丁升级、配置和安全加固。

（4）Web安全：身份验证、验证码获取、会话管理、权限管理、敏感信息传输、安全审计、信息泄露、上传下载、异常处理等。

（5）应用软件安全：借助于安全工具进行扫描。

（6）敏感数据保护：密码、客户信息、商业机密等。

常用的安全测试工具有IBM AppScan、Burp Suite、Metasploit和Nmap等，借助于安全测试工具，我们可以部署一些较为复杂的安全测试场景，以保证信息系统的安全性。

1.2.2.5　金融软件兼容性测试

金融软件兼容性测试主要验证金融软件系统在不同硬件、不同操作系统和版本、不同浏览器和版本、不同分辨率和不同系统配置等组合的情况下的系统兼容情况，保证金融软件系统能在不同用户环境下正常使用，提高用户使用满意度。

金融软件兼容性测试可以从两个部分进行阐述，首先是Web端的兼容性测试，近几年来，国产自主化改造在金融行业的试点工作逐渐展开，金融软件系统兼容性测试的任务规模也在不断扩大，例如金融软件系统在国产底层硬件服务器、数据库、中间件和操作系统上的兼容性测试。

其次是App端的兼容性测试，随着互联网和智能手机的普及，金融软件系统越来越多地直接面向金融移动端客户，各大证券公司、银行、保险公司均在金融科技FinTech时期推出了自己的移动端业务的金融服务产品，如果说金融软件系统Web端兼容性测试还带有自己的特殊行业特点，那么App端的兼容性测试就更加符合互联网的标准。在2.3.2节中，有关于互联网金融手机端App测试的详细描述。

1.2.2.6　金融软件用户体验测试

金融软件系统最开始主要面向金融行业的内部业务人员使用，因此在用户体验上要求并不高。随着金融行业的快速发展，金融软件系统需要面向更多的外部用户群体，随着用户群体的不断扩大和同业之间的竞争日趋激烈，用户体验测试也逐渐被重视起来。金融软件系统的界面设计是否友好、功能是否齐全、流程是否简洁、操作是否流畅以及是否符合用户使用习惯等都成了用户体验测试的重点。一款友好的和受欢迎的金融软件系统，本质上也是对金融公司的一种宣传，能提高用户黏性和同业市场竞争力。

用户体验测试更加注重用户的使用感受，需要测试人员充分发挥主观评价，提出更多的优化意见，促进金融软件系统的不断完善。

1.2.2.7　金融软件接口测试

金融软件接口测试包含内部接口测试与外部接口测试。内部接口测试一般针对多系统对接的情况，基于统一的规范，通过接口报文的形式实现数据的传输。如果有Web页面，接口测试可以通过系统的前端界面直接进行；如果被测系统只是一段处理程序，就需要借助于Postman、SoapUI等接口测试工具通过不同的接口请求方式来进行。外部接口测试则由于系统间采用的数据库、网络服务协议和字段命名标准等不一定相同，需要通过接口进行数据的转义才可实现业务的流转，大部分需要用接口测试工具来进行验证。

一般情况下，金融软件系统业务种类较多、系统结构复杂，有时还会存在多系统共同开发、开发进度不一致的情况。为了保证先开发完的系统能够顺利完成功能流程工作，需要通过模拟接口的方式发送和接收报文，通过接口测试的方式优先完成该系统功能测试中数据验证的测试工作。

接口测试通常包含获取接口地址、根据接口规范编写报文、通过工具发送和接收报文、查看数据库中的数据状态和查看系统后台执行日志等步骤。接口测试执行过程除了验证本系统的功能外，有时候还可以通过对方返回的响应报文发现对接系统的缺陷。由于接口测试涉及操作系统和数据库等技术，所以需要接口测试人员具备一定的操作系统和数据库等方面的知识。

1.2.2.8　金融软件文档评审

金融行业有着较为专业和标准的系统开发、测试和运维等工作流程，大部分金融机构在第四个时期成立了自己的测试中心，实现了精细化的质量管理。测试人员在金融软件系统的开发早期就开始介入，凭借自身丰富的金融业务知识和技术经验，参加需求文档、安装文档、设计文档和变更文档等的评审工作，关注业务逻辑隐性的风险点，同时对项目各文档显性的风险点进行评估，如：文档内容是否完整、文档描述是否前后一致、文档内容是否符合相关标准，保证最终交付文档的专业性和标准性。

金融软件系统的功能实现必须与需求相关文档保持一致，如果测试人员在项目早期介入项目，就有可能更早地发现需求相关文档潜在的问题，可以有效地降低整体研发成本，缺陷发现得越早，解决该缺陷的成本就越低。在实际项目研发工作中，可能存在需求变更的情况，需求变更文档也需要进行评审，这是测试的范畴。具体内容可以通过5.1.4节进行了解，文档评审可以有效地减少无效开发和重复测试，提高整体项目研发工作效率，并且使研发过程更加严谨和规范，文档评审广泛地应用于金融软件系统的研发工作中。

1.2.3　本节小结

本节介绍了金融软件测试的几个发展时期，还介绍了几种常见的金融软件测试类型，提出了适用于金融行业软件测试的具体方案及实用技术。随着新的设计模式及开发方法的不断涌现，现有的测试理论及技术必须做出相应的改进，才能满足不断变化的系统优化需求。我们需要在工作中不断积累经验，在已有经验的基础上持续创新，调整思维模式，以此拥抱金融发展的未来。

1.3　金融软件测试人才发展与自我培养路径

本节从人才生命周期理论视角出发，分析金融软件测试人才在引入期、发展期、成熟期和持续发展期或衰退期自我培养的关键任务，目的是使读者能够遵循人才发展的一般规律，结合自身职业发展规划，实现在金融行业的长足发展。北京立言金融与发展研究院发布的《中国金融科技人才培养与发展问卷调研（2021）》显示，96.8%的参与调研机构认为金融科技专业人才存在缺口。究其原因，金融科技人才的短缺并不在于专业从业人员绝对数量的短缺，而在于人才发展情况与企业期待之间的不对称。值得注意的是，这种不对称指向的并不是人才质量的不理想，而是指向人才对于企业岗位设置所要求的胜任力满足程度不够。因此，从人才生命周期理论视角出发，了解企业在不同阶段对于人才发展的期待，有利于帮助个体明确自我培养的关键任务，更加科学有效地设计自身的职业发展规划，并最终实现长远的职业发展目标。

1.3.1　引入期：充分准备，顺利入场

对于应届毕业的求职者或者更换职业赛道的行业新人来说，此时正处于人才发展的起始阶段。作为宝贵的“新鲜血液”，引入期的高质量人才对于企业来说是实现可持续发展的强大动力，也是体现企业影响力的重要标志。在这一阶段，企业关心的是人才是否具备良好的专业基础，是否认同企业的文化价值，是否具备持续的学习能力等，以此确认人才的培养价值。因此，引入期人才的关键任务是充分做好信息准备、技能准备和心理准备，顺利地拿到职业生涯的“入场券”。

1．信息准备——锁定目标，潜心了解，准确判断

对于金融软件测试人才来说，职业的目标行业和领域已经非常明确，那么在进入职场之前，应当进一步确定目标公司和目标岗位。这一动作有利于求职者了解有关目标公司的发展背景、企业文化，以及目标岗位的职责和胜任力要求等相关信息，便于自己更好地进行有针对性的准备。在这一过程中需要注意的是，面对大量的信息获取渠道和海量的大数据资源，求职者应当选取准确的资讯来源，审慎对待所获得的信息，并且保持自己的理性判断，尽可能为自己的职业决策提供有价值的参考。

2．技能准备——踏实学习，用心实践，有效输出

技能是个人职业发展的核心竞争力，它不仅包括技术能力，还包括软实力。Michael Page（中国）发布的《2021人才趋势报告》中指出，技能与经验是中国科技公司招聘过程中比重高达82%的考察因素。为了保证自身的整体能力更加符合企业的用人要求，人才应当在信息准备确切的基础上，以目标企业的目标岗位的胜任力要求为参照，有目的性地踏实学习，提升自己的专业技术水平和综合能力。不仅如此，理论知识的学习不能脱离实践，所以应当积极获取并珍惜专业实践机会，例如企业实习或专业竞赛，在实操过程中补充和强化所学，保证在之后的工作中能够有效输出。

3．心理准备——转变角色，虚心融入，快速适应

心理准备也是引入期人才自我培养的重要任务。对于职场新人来说，新的公司和工作岗位意味着新的成长环境，也意味着新的发展要求。以学校和企业的差别为例，对于在校学生来说，首要任务是在完成学习任务的过程中提升个人综合能力并塑造个人核心价值观，为之后的人生发展打下坚实的基础。对于企业员工来说，首要任务是在完成工作任务的同时提高自己的职业技能和素养，协调与统一个人目标与组织目标，谋求长期的职业发展。因此，只有积极地转变角色，虚心地在新的环境中不断学习，才能够更快地适应企业的工作节奏，顺利开启职业生涯的第一步。

1.3.2　发展期：找准方向，耕耘积累

经过初步的适应和磨合，人才开始进入职业成长的发展期。在这一时期，企业对于人才的考察重点从潜能的预判变为实际的工作表现，并期待人才能够在履行岗位职责的前提下成为企业发展的中坚力量。所以对于发展期的人才来说，选择明确且适合自己的职业发展方向显得尤为重要。金融软件测试领域的从业者可以选择成为专家型人才，或者成为管理型人才，抑或二者兼具的复合型人才，明确自己的成长目标并为之勤勉耕耘，认真积累，实现从“专业”到“专家”和从“执行”到“管理”的转变。

1．专家型人才

专家型人才又可以分为业务专家和技术专家。

业务专家具备扎实的业务专业知识和丰富的项目经验，能够在需求分析和解决方案设计层面给予用户前瞻性和实操性的建议。因此，以业务专家作为发展目标，要求从业者在职业发展过程中，学习金融软件和泛金融领域的专业知识，充分了解和参与项目开展的各个环节，紧密关注前沿技术突破和行业动态，更重要的是要积累丰富的与终端用户以及高层次业务管理决策者打交道的经历。

技术专家在专业测试技术领域具备全面的技术覆盖面，以及在精通的技术专长领域能够带领团队实现技术攻坚，保证产品功能的理想表现，同时形成技术竞争优势。因此，以技术专家作为发展目标，要求从业者在职业发展的过程中，对于金融测试专业领域涉及的技术具有全局性的了解并有所擅长，对于技术实现的过程和技术难点的突破具有丰富的项目经验，对于专业领域新兴的技术成果具备持续学习的能力。其特别强调培养从业者在纵深领域的研究方向，如自动化测试对自动化框架体系以及框架设计搭建的适应性要求等。

2．管理型人才

管理型人才相较于专家型人才来说需要具备更加综合的专业能力。管理型人才不仅要熟悉业务原理，掌握技术知识，还要具备与企业、员工价值主张一致的领导魅力。首先，管理型人才需要实现向内管理，即人员管理与项目管理。人员管理要求管理者能够有效地进行团队分工，同时保证团队的敬业度和满意度，在紧密和谐的氛围中实现工作目标。项目管理要求管理者能够根据项目的生命周期进行合理的规划，监控过程质量和结果质量，把控项目成本，保证效益产出。另外，管理型人才还需要实现向外管理，即资源协调和危机处理。资源协调要求管理者具备获取资源和协调资源的能力，能够为团队提供实现目标所需的必要资源和额外的资源，这点尤为重要。危机处理则要求管理者在面对突发情况时，能够有足够的能力应对危机，甚至将危机转化为机遇，推进工作顺利进行。

3．复合型人才

复合型人才是兼具专家型人才和管理型人才特质的人才类型，显然其对从业者的能力要求更高，既要能够在业务或技术领域有所专长，又要能够担任领导角色，履行管理职责。所以，成为复合型人才并不是一蹴而就的，而是需要在成为专业型人才或管理型人才的基础上继续成长，从而实现更加全面、综合的人才转型，这种人才转型的实现途径就是我们通常在企业内部提及的轮岗。

1.3.3　成熟期：敬业专注，提升影响

在人才发展期，个人以专家型人才和管理型人才作为自身职业发展的目标，在持续不断的努力下会迎来发展的成熟期。成熟期意味着人才已经有能力担任企业中的领军者角色，对企业发展目标的设定和发展规划的实现起到关键作用，是真正影响企业未来的核心成员。对于成熟期的人才，企业的期待除了良好的工作表现之外，还更加看重人才的敬业度以及影响力。敬业度决定了人才是否能够保持对企业的长期认同和忠诚，影响力决定了人才是否能够以自己的专长推动所在团队，甚至是企业的成长。那么，个人应该如何保证自身的敬业度和影响力呢？

1．敬业度——全面审视，理性取舍

相较于引入期和发展期，成熟期的人才经过一段时间的职业性探索和社会性成长之后，对于专业领域和个人追求都有了更加深入的了解。换言之，成熟期的从业者更加明白自己在专业上的长处是什么，在职业上的追求是什么，在工作上获得的价值感来源是什么，因此更加能够对自己当前的情况进行全面审视，并通过合理的价值排序和利弊分析来调整接下来的发展规划。但是在这个过程中，盲目地更换赛道或跳槽是不可取的，个人需要理性的头脑来帮助自己进行关键决策，提升对于组织的敬业度，保证自身长期发展的稳定性。

2．影响力——知识输出，专业发声

成熟期的人才不仅能够在自己的工作领域取得卓越的表现，更能够以自身的影响力推动团队和组织，甚至是行业的发展。影响力的实现需要必要的载体，可以以专著的形式传递专业知识，可以以培训的形式分享技术经验，可以以峰会参与的形式贡献创新思想。总之，人才需要明确面向对象并选择合理有效的媒介，依据自己扎实的积累和丰富的实践，获得专业话语权，促进更高层次职业价值的实现。

1.3.4　持续发展期或衰退期：抓住机遇，适时调整

人才发展到成熟期并不意味着成长的停滞。面对日新月异的技术进步和迅猛的行业发展，以及来势汹汹的“后浪”追赶，人才应当保有不断进取的危机感，从而步入持续发展期。持续发展期同发展期一样，人才需要按照自身的职业规划，在取得阶段性成果的基础上继续向更高的台阶迈进。关于成功的法则有非常多的界定和解释，广为人知的便是“成功=1%的天赋+99%的努力”。但笔者认为，职业发展的成功法则可以定义为“成功=1%的专长+ 98%的努力+1%的幸运”。其中，专长代表的是个人能够精准剖析自身优势，并确定专业发展方向；努力代表的是个人能够在确定专业发展方向后持续努力，精益求精，实现从量变到质变的飞跃；而幸运指的是人才在职业发展过程中发现并抓住机遇，实现“火箭式超越”。机遇是不可掌控的随机变量，我们不能控制它发生的时机和停留的时间，但是我们能够控制的是抓住机遇的能力。抓住机遇需要人才在发展期踏实稳健地自我培养，使得自身具备敏锐的眼光、丰富的资源、清晰的头脑以及实践的拳脚，这样才能在机遇出现的时候牢牢把握，充分利用。

职业的发展并不总是水到渠成的，也有可能需要面对衰退期。首先，个人要能够对发展的衰退期保持敏感性，也就是说，个人需要对这种负面情况有所察觉。其次，个人要能够对发展的衰退期保持客观性，即能够理性、客观地分析自己目前遇到的瓶颈或困难，积极地制定实际的解决方案以寻找突破口。再次，如果经过理性分析之后发现确实没有行之有效的方法来改变现状，那么不妨勇于放弃，这并不意味着失败，而是及时止损，让自身能够尽快寻找到更加适合自己的发展方向。最后，个人在面对衰退期时应当注意心态的调整，保持热情与乐观的态度才能力挽狂澜、柳暗花明。

1.3.5　国内金融软件测试人员能力要求

1．基础软件测试技能

如果要从事金融软件测试工作，我们需要具备基础软件测试技能，基础软件测试技能贯穿整个软件测试生命周期。软件测试生命周期一般分为测试准备阶段、测试执行阶段和测试报告阶段。测试准备阶段的基础软件测试技能包括业务需求分析能力、测试计划执行能力、测试方案编写能力、测试环境部署能力、测试数据准备能力、测试用例设计能力等；测试执行阶段的基础软件测试技能包括测试用例执行能力、缺陷跟踪能力和日报/周报编写能力等；测试报告阶段的基础软件测试技能包括测试数据统计分析能力和测试报告编写能力等。

2．金融软件业务知识

金融软件测试工作是为金融业务系统的稳定运行服务的，只有具备了金融软件业务知识，才能更好地在测试中发现系统设计问题和系统逻辑问题。比如，某金融公司新增或修改一种业务功能，一方面，我们需要对该金融系统的业务功能、业务规则和业务逻辑有足够的了解；另一方面，我们还需要了解该系统哪些代码会调用新增的业务功能代码，或者新增的业务功能代码会调用哪些原有的业务功能代码，原有的业务功能是否需要同步改造等，如果新增或修改的业务功能涉及其他业务，其他业务功能是否需要进行同步改造等。测试人员根据这些信息才能准确评估出新增业务可能涉及的测试范围和测试工作量。同时，具备丰富金融软件业务知识的测试人员可以在项目业务需求分析阶段介入，在系统设计阶段指出业务流程、业务规则和业务逻辑上存在的问题，从而更早地定位缺陷，系统缺陷发现得越早，修复该缺陷的成本就越低。

3．技术能力

金融软件测试人员需要了解操作系统、数据库、网络、存储、中间件和开发语言等技术知识，在项目业务需求分析阶段需要对系统涉及的相关技术进行调研。例如，需要了解该系统采用的开发语言、数据库、存储和中间件等；该系统部署的操作系统，以及操作系统版本信息、服务器硬件信息和负载均衡策略等；该系统部署的网络环境等。金融软件测试人员拥有相关技术能力，可方便之后测试工作的开展。例如，通过数据库查询语句验证前台页面的查询结果显示是否和实际结果相一致，通过执行脚本的方式批量生成测试数据来提高测试效率，查看操作系统中的系统日志来定位系统问题等。

4．工具使用能力

在整体系统测试过程中，根据测试类型和工作内容的不同，会涉及不同的工具，好的工具可以大幅度简化测试流程和提高测试效率，使得整体测试过程更加标准化和流程化。常用工具分类可以参考表1-3。

表1-3　常用工具分类

5．测试人员的软技能

测试人员的软技能包括沟通表达能力、文档编写能力和团队协作能力等。测试人员在测试工作中需要与领导、同事、开发人员、业务人员、运维人员保持良好的沟通，良好的沟通表达能力能够有效降低人员沟通成本，从而促使测试项目顺利完成。文档编写能力贯穿整个系统测试生命周期，测试准备阶段的测试方案、测试用例，测试执行阶段的日报和周报，测试报告阶段的测试报告等，都需要测试人员有比较好的文档编写能力。由于金融系统测试的特殊性，各部门之间人员协作是必不可少的，团队协作能力也是测试人员必备的软技能之一。

1.3.6　本节小结

本节从人才生命周期理论视角出发，分析金融软件测试人才在引入期、发展期、成熟期和持续发展期或衰退期4个阶段自我培养的关键任务，同时介绍了国内金融软件测试人员的能力要求。本节的目的是使读者能够遵循人才发展的一般规律，结合自身职业发展规划，实现在金融行业的长足发展。

1.4　本章思考和练习题

1．软件测试中的V模型有何优点？

2．软件测试中的瀑布模型有哪些不足？

3．软件测试按测试阶段可以分为哪几种，请简要说明。

4．什么是Alpha测试？什么是Beta测试？

5．金融软件测试有几个发展阶段？

6．金融软件测试的一般分类都有哪些？

7．如果您想从事金融软件测试相关工作，应从哪些方面培养自己的能力？