金融方面测试

1、目前金融软件及产品研发已经认识到测试的重要性，但许多先进的软件测试方法、技术和标准还处于实践 和探索阶段。软件测试的实施既要遵循国内外先进的测试理论，也必须根据实际情况量体裁衣，确定适合 于项目的软件质量目标和测试策略。、项目简介D 系统（如图1 所示）建设的总体目标是资金交易管理信息化。用户可以在统一数据平台和交易平台中实现流程自动化、业务处理规范化、交易管理网络化、辅助决策管理智能化、操作风险控制实时化、报表生成自动化。D系统构建于J2EE平台，采用分层B/S架构提供服务支持的设计思想，对每一层定义明确的功 能接口，同时在层次内实现组件化接口。二、测试总体计划D 系统测试工作的首要任务是制

2、订测试计划。测试计划编写的主要依据是项目组织结构、D 系统需求规格说明书、D 系统开发计划。通过分析项目组织结构，明确测试人员在项目中承担的权利和义务，确立测试工作在整个项目开发中所承担的责任，描述工作流程和沟通方式。需求规格说明书决定测试需求（功能测试、性能测试、安全性测试、容灾性测试等）、测试范围（测试项和测试项特征）、测试优先级等。开发计划决定测试任务及工作量， 测试资源的投入时间。D 系统测试计划还描述了测试方法、关键原则、通过准则、测试环境要求、缺陷分类级别、遗留问题处理、风险与应急等。根据D 系统测试计划，将测试工作划分为5 个阶段，见表1 。在各阶段测试任务实施过程前，收集和分析

3、上一阶段的实施效果，通过建立PDC破进机制，及时对测试计划进行细化和调整。三、测试策略和方法测试的主要困难是不知如何进行有效测试，也不知何时结束测试。D 系统总体测试策略是将系统划分为3个业务层（前、中、后台），按照每个业务层的特点设计测试方案。1. 前台业务页面测试D 系统前台业务的特点是直接和用户交互页面展现层。用户登录系统，根据权限及角色不同，分别加载相 应的功能页面；系统运行的结果通过查询页面和图形报表等方式展现给用户。前台测试是功能测试的重点，贯穿测试工作的各阶段。项目组在单元测试阶段制订 D 系统单元测试规范。规范中既包含页面功能的验证，又结合金融行业特点对页面风格进行统一要求,

4、如数量单位、金额截位、默认值、提示信息、查询样式、报表格式等。执行单元测试时使用的最主要测试手段是代码走查。D 系统前台编码基于较成熟的工作流中间件产品，开发平台为程序员提供各类构件库，同时提交相应的测试报告和使用说明。封装后的构件解决了程序健壮性、系统安全性和效率等问题。代码走查目的是检查开发人员是否选择了正确的构件且正确使用构件。前台业务功能测试用例设计在参考D 系统需求规格说明书和D 系统数据字典的基础上，遵循GUI 软件功能测试标准，主要使用边界值和等价类划分的测试方法。用例设计原则是不仅要测试程序的正确性，还要测试程序的“鲁棒性”（容忍不合法的输入并检测出来，避免给出不合理的结果）。

5、输入数据的设计要求包括小于边界值、等于边界值、大于边界值三种等价类。2. 中台业务流程测试D 系统中台业务的特点是风险控制和流程管理。用户通过前台页面设置各类风险指标信息（信用、 限额等） ；前台交易数据通过中台业务工作流（授权、授信、审批等）传到后台。通过后台风险分析算法，返回风险级别判断结果，决定交易流转方向和审批路径，实现经风险调整的收益率最大化。中台测试重点与难点是流程测试。测试任务执行始于集成测试阶段。流程的灵活配置是D系统的一大特点, 给中台测试带来一定难度。流程测试用例的设计主要使用路径覆盖法。流程验证：确认D 系统中手工配置业务流程图是否与D 系统需求规格说明书一致，逻辑是否正

6、确。流程划分：将系统流程划分为基本流和备选流。基本流是经过用例的最简单路径，用直黑线表示。备选流自基本流开始，每个备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1 和 2），还可能起源于另一个备选流或终止用例而不再重新加入某个流（备选流3 和 4）。场景设计：遍历所有流程分支。例如基本流-> 备选流2-> 备选流3。一旦所有分支被选择完毕，场景设计结束。设计用例：分析分支判断条件，完成测试用例设计。例如测试用例TC004是为验证当交易“结算金额 >账户余额”时，审批流程是否正确。执行测试：用户、 角色和权限信息是分别在系统中灵活配置的，而流程中的环节参与和

7、用户权限密切相关。在流程用例设计时只体现角色（权限的载体）；在用例执行时，参考D系统用户角色信息表。3. 后台业务深度测试D 系统后台业务特点是金融算法分析的核心层，完成模拟试算、风险分析、账务推导、日切批处理等功能。为实现系统兼容性和可扩展性，将复杂计算和金融分析功能进行组件封装，集成于“金融底层”。底层对外（前、中台）有Web Service 接口方式和对象接口方式。后台测试重点是验证计算精准性。测试任务执行始于集成测试阶段。（ 1 ）测试界面后台业务与用户无直接交互，本着尽早测试的原则，项目组通过分析应用层对金融底层的调用需求，开发测试页面，供测试人员进行用例输入和输出结果验证。（ 2）

8、用例设计后台测试用例设计主要采用模拟数据法和历史数据分析法。前者是手工编制业务数据，通过第三方软件汇总计算并生成报表，与D 系统金融底层组件的计算结果比对。后者是向数据库批量导入历史业务数据，生成结果和历史账务报表进行比对。根据金融业对数据精准性和可靠性的要求，在用例执行时加入“大数据量测试”场景设计。验证后台处理 大量业务数据时，批处理效率、容错能力和事务处理机制等。（ 3）集成测试 前、中、后台集成测试阶段采用“先分再合”的方法，虽然增加了测试页面开发的工作量，但既保证了测 试和开发工作的并行，又保证了应用层和金融底层测试工作的并行；同时提高测试的准确性，取得事半功 倍的效果。测试初期：测

9、试用例准备完毕，测试人员分两组。前台测试人员执行页面级测试用例，验证应用层基本功 能是否和需求一致，页面风格是否一致等。后台测试人员通过测试页面，录入测试用例，比对结果，确认 金融底层的正确性。测试中期：中台开发完成，将前、后台联通，开始执行流程测试用例。此时后台功能很可能未完善，必要 时需模拟后台的接口数据，保证流程测试的进度。测试后期：金融底层正式通过WebServices 发布方式和应用层级联，业务在系统中实现前、中、 后台贯通。测试人员重点对系统接口进行测试：通过前台录入交易，中台完成业务流转，将业务数据送入后台，最终系统将结果以查询列表、报表、图形等方式展现给用户。集成测试工作结束后

10、，测试转入系统功能测试阶段，测试人员正式执行测试用例，同时以回归测试验证测试版本的稳定性。四、测试结果总结D 系统的测试实践表明，有效的测试方法能提高测试效率，使项目过程可度量，达到质量过程控制目标。1. 测试工具自动化测试和手工测试不能互相取代。D 系统测试的各阶段使用了质量管理工具和测试工具，提高效率。2. 测试用例本次测试需求用例419 个，测试用例设计对需求覆盖率达到100。功能测试用例设计6368个，其中流程用例 364 个 （包括 36 个基本流，328 个备选流）。性能测试用例覆盖8 个功能模块，涉及 158种事务类型。共 设 计 21 个 测 试 场 景 ， 数 据 存 储 设 计 为 1 万 级 和 10 万 级 。 vusers 设 计 7 种 并 发 级 别 （1g2g5g8g 10g 12g 150） o3. 测试结果D 系统开发过程中，测试工作历时10 个月，通过发现缺陷和修复缺陷的过程，有效提高了软件质量；通过总结测试报告为项目实施提供了有效的度量标准。缺陷率：D 系统测试中累计发现缺陷2605 个，千行代码缺陷率为0.73 ， 小于包含复用代码的应用行业缺陷率（一般为2.0 ），小于新开发代码行业缺陷率（一般为4.1 ）。修复率：除业务验收阶段发现的缺