在国家信息化发展战略明确确立以信息化促进工业化指导方针的大背景下，国内的信息化产业发展在近10年内取得了显著成效。铁路作为关乎国计民生的重要支柱^[1]，全面信息化发展的必要性更为突出，而财务系统是各铁路单位经营管理的中枢 ^[2]，因此，对于Web端财务系统的可用性、易用性、安全性、兼容性比其他面向企业端和个人端的软件系统有着更高的要求^[3]，在进行系统测试时需要考虑的因素和场景也就更加复杂多样。因此，在包括需求、设计、开发、测试和交付的5个阶段的软件生命周期中，测试工作从需求调研阶段介入，直至测试阶段结束，以达到测试工作的全程覆盖，保障软件工程质量的目的。本文以铁路相关单位研发的Web端财务类系统为例，研究了适用于财务类系统的软件测试方法。

1   财务类系统简介

本文研发的财务类系统在业务层面属于财务共享中心，面向众多下属单位。此类系统的优势在于，各下属的二级、三级单位在进行资金活动时，各级人员无论进行对内的报销、借款，还是进行对外的其他资金活动，当资金审批流程到达财务审批节点时，都会经过隶属于该单位的财务共享中心，进行流转分配。特定的财务人员审核特定的资金业务，通过审核的财务数据最终汇总至财务共享中心的数据库中，实现统一审批管理、提高工作效率、落实全面预算管理、简化报销流程的目的，强化了一级单位对其下属二级、三级单位的资金监管力度。系统采用定制化开发，满足不同类型用户的需求。

2   软件研发相关模型

2.1   瀑布模型简介

当前，在软件研发过程中，传统的瀑布模型依然占主导地位^[4]，软件的生命周期遵循需求、设计、编码、测试和交付5个阶段，如图1所示。

图  1  软件生命周期瀑布模型

下载: 全尺寸图片 幻灯片

（1）需求阶段中，需要对需求方的描述进行定义，并进行可行性研究，通过研讨、评审等方式对需求进行分析，制定适用于软件开发过程的需求规格说明书；

（2）设计阶段中，设计人员开始进行界面设计，开发人员进行代码底层结构、数据库结构设计；

（3）编码阶段中，前端人员对原型设计图稿进行还原，后端人员对业务需求进行代码层面的编写，编码工作结束后，测试人员开始进行测试用例设计；

（4）测试阶段中，测试人员进行测试用例的执行，汇总测试结果并跟进测出的缺陷修改情况，直至发现的所有缺陷都被解决^[5]；

（5）交付阶段中，客户进行验收测试，系统上线部署，工作重心转向对系统的运行维护。

2.2   双V模型简介

传统的瀑布模型迭代开发中，测试人员在编码过程中或编码结束后才介入测试，可能会因对需求理解不够充分，而导致忽视需求中的细节，这对于事关资金的财务类软件无疑是致命的。为保障软件生命周期全过程的质量，测试人员需要从需求阶段就开始介入测试，直到系统测试通过为止。即测试过程在需求阶段进行需求内容调研；在设计阶段进行需求测试和原型测试；在编码阶段进行灰盒测试及集成测试；在测试阶段进行全量系统测试工作，如图2所示。

图  2  软件测试双V模型

下载: 全尺寸图片 幻灯片

双V模型就是基于对瀑布模型过程中需求～测试4个阶段的改进，采用开发过程与测试过程并行的管理模式，以测试驱动开发的管理过程。通过双V模型及健全的质量保障体系，依据测试驱动需求分析，测试驱动概要设计及详细设计，测试驱动编码、集成、实施、交付的一系列措施，可实现对软件生命周期的全过程进行质量管理，有效提升软件产品质量。

3   双V模型在Web端财务类软件测试中的应用

3.1   需求阶段

在软件项目立项初期，项目处于需求收集和市场调研阶段，功能需求尚未明确。大部分技术人员对财务领域的专有名词和业务概念较陌生，导致需求描述不准确，使得后续开发环节中，开发人员对需求造成误解或歧义。因此，测试人员需要站在用户的角度，以第三方视角对需求内容提出改善建议。

针对需求文档，测试人员需结合实际应用场景并参照市面上类似的成熟产品，从文档的可读性、完整性、易用性和逻辑性等方面提出优化建议，完善文字描述中的语序、主谓关系和语句逻辑，使需求文档的可读性提升并反馈至项目负责人，由项目小组及其他项目干系人进行评审。由此即确保需求文档中的文字描述和实际业务相契合，又解决了开发人员及其他项目干系人对文字描述产生歧义的问题。所以该阶段的测试工作可使测试人员深入理解需求，具有降低后期修改和维护成本的效果。

3.2   设计阶段

设计阶段会进行概要设计和详细设计。 Web页面原型的按钮、弹窗、菜单、配色是否足够直观和美观，是否符合需求文档和设计文档的描述是测试人员在这一阶段中需要关注的重点^[6]。

测试人员在需求测试和原型测试时，参照设计文档及需求文档，对原型页面的配色方案、设计规范、业务层级关系、功能入口、交互功能提出建议，跟进并复测直至原型定版，在初版开发版本部署后，参照定版原型进行还原验证，反馈不符合原型和设计规范的地方。财务类型软件的特殊性使其用户界面必须具备直观性、易用性和严谨性。因此，测试人员在设计阶段的介入让产品尽可能符合用户需求，同时也降低了返工的可能。

3.3   编码阶段

在开发人员进行编码的同时，测试人员需要同步开展灰盒测试。灰盒测试既不接触用户界面，又不深入到代码调用逻辑，仅对模块间的数据关系、入参回参进行测试。测试的工具一般采用Fiddler或Charles抓包工具进行接口的抓取，用Postman进行接口请求及结果断言。测试人员需采用Java或Python类型的编程语言编写测试程序脚本，通过代码进行接口请求的模拟及结果断言。

灰盒测试旨在数据流层面发现代码中的缺陷。因财务系统的核心业务是资金流转，资金相关的数据普遍以JSON数据流的形式在模块间传输，用户的ID、资金数字保留位数、额度等是否在传输的过程中发生变化，证件号码是否以加密形式传输，审批或付款是否有回参，执行错误后是否会抛出异常，特定类型的业务是否对应特定类型的请求方式等都是财务类系统灰盒测试的重点，灰盒测试用例不仅要覆盖正向场景，更要尽可能多地覆盖反向场景，绝大多数接口缺陷是在错误的入参情况下产生的，因此，编码阶段的测试工作可显著降低项目上线后生产环境中的软件缺陷。

3.4   测试阶段

系统测试是通过交互界面对软件的全量功能业务进行测试，是软件测试的核心。业务层面功能需经过人为思考介入，才会对各类逻辑的合理性进行判断分析。财务类系统和其他业务系统在用例的设计方面有较大不同，按测试的侧重点可分为单据测试、流程测试、安全测试、压力测试和兼容性测试等。

3.4.1   单据测试

资金业务的载体是单据^[7]，财务领域的业务需求繁多，会产生如核销、转账、付款等业务单据，这些单据在测试过程中的关注要点是相通的，如：输入和输出数据一致性校验，金额、号码等特定类型字段对字符长度、输入类型的校验，字段框对超长字符、空格、特殊字符的限制，下拉框和弹窗类型字段数据展示的正确性，账号号码是否加密显示，特定增、删、改、查执行后的结果提示，SQL注入后是否引发不良后果，是否支持模糊查询或精确查询。测试用例需覆盖每一处存在增、删、改、查的字段，使用等价类划分及边界值分析法实现测试用例对单据内容的全量覆盖。

3.4.2   流程测试

流程是指财务类业务流传的运输通道，不同场景下单据的审批节点较为复杂多变，以出差申请为例，根据单据的出差人的职务级别、出差牵头部门、是否有领导同行、是否住宿、是否乘坐飞机等情况的不同，其对应的各个审批节点均不同，每一项变量都会对总体流程产生影响。在进行测试时，需要对各个场景中变量存在的可能性进行排列组合，并分别进行正向测试和反向测试，杜绝流程缺陷。

3.4.3   安全测试

安全是资金业务平稳运行的根基^[8]，在与资金敏感性相关数据的安全测试中应关注：账号密码对弱口令做卡控限制；各类手机号、身份证号和银行卡号在传输过程中应以加密字符串形式进行传输，在前端页面展示时以星号进行脱敏处理；内网服务不能通过外部互联网挂载代理访问；令牌的有效时长不能超过特定时限；不同权限及不同角色的用户应做到数据间相互隔离等。

3.4.4   压力测试

压力测试关注的参数指标是被测接口的性能瓶颈。以最易产生性能瓶颈的发票推送为例，每张发票都会伴随一张图片类型文件，一旦并发量陡增，对系统的压力将呈线性增涨，因此需要使用Jmeter或loadrunner测试工具，以多终端分布式方法对发票推送接口进行高并发请求，以此模拟高并发对该接口的访问压力，找到系统的性能瓶颈。在单据提交、报表上传、登录这些可能存在高并发的场景中，均可使用上述方法。

3.4.5   兼容性测试

用户端设备的配置、显示分辨率、操作系统不尽相同，且用户行为有不可预知性，因此，开发人员应尽可能做好前端适配工作，测试人员需使用不同的操作系统、浏览器、测试机对界面及功能进行验证，测试覆盖程度越高，出现因兼容性问题而降低用户体验的概率越小。

4   结束语

本文基于财务类系统的软件测试实践，对业务需求、软件研发过程、双V模型进行了详细描述，针对需求阶段、设计阶段、编码阶段和测试阶段的具体情况展开论述。以铁路相关单位研发的Web端财务类系统为例，介绍了适用于财务类系统研发各阶段的测试重点和测试方法。在国家信息化战略路线的推进下，Web类技术的软件应用仍然是企业信息化改革的主要实现方式，今后会在测试工作中对测试方法持续改进。