金融方面测试2.docVIP

目前金融软件及产品研发已经认识到测试的重要性，但许多先进的软件测试方法、技术和标准还处于实践和探索阶段。软件测试的实施既要遵循国内外先进的测试理论，也必须根据实际情况量体裁衣，确定适合于项目的软件质量目标和测试策略。 ? 一、项目简介 ? D系统（如图1所示）建设的总体目标是资金交易管理信息化。用户可以在统一数据平台和交易平台中实现流程自动化、业务处理规范化、交易管理网络化、辅助决策管理智能化、操作风险控制实时化、报表生成自动化。D系统构建于J2EE平台，采用分层B/S架构提供服务支持的设计思想，对每一层定义明确的功能接口，同时在层次内实现组件化接口。 ? 二、测试总体计划 ? D系统测试工作的首要任务是制订测试计划。测试计划编写的主要依据是项目组织结构、《D系统需求规格说明书》、《D系统开发计划》。 通过分析项目组织结构，明确测试人员在项目中承担的权利和义务，确立测试工作在整个项目开发中所承担的责任，描述工作流程和沟通方式。需求规格说明书决定测试需求（功能测试、性能测试、安全性测试、容灾性测试等）、测试范围（测试项和测试项特征）、测试优先级等。开发计划决定测试任务及工作量，测试资源的投入时间。 D系统测试计划还描述了测试方法、关键原则、通过准则、测试环境要求、缺陷分类级别、遗留问题处理、风险与应急等。根据《D系统测试计划》，将测试工作划分为5个阶段，见表1。在各阶段测试任务实施过程前，收集和分析上一阶段的实施效果，通过建立PDCA改进机制，及时对测试计划进行细化和调整。 ? 三、测试策略和方法 ? 测试的主要困难是不知如何进行有效测试，也不知何时结束测试。D系统总体测试策略是将系统划分为3个业务层（前、中、后台），按照每个业务层的特点设计测试方案。 1.前台业务——页面测试D系统前台业务的特点是直接和用户交互页面展现层。用户登录系统，根据权限及角色不同，分别加载相应的功能页面；系统运行的结果通过查询页面和图形报表等方式展现给用户。 前台测试是功能测试的重点，贯穿测试工作的各阶段。项目组在单元测试阶段制订《D系统单元测试规范》。规范中既包含页面功能的验证，又结合金融行业特点对页面风格进行统一要求,如数量单位、金额截位、默认值、提示信息、查询样式、报表格式等。 执行单元测试时使用的最主要测试手段是代码走查。D系统前台编码基于较成熟的工作流中间件产品，开发平台为程序员提供各类构件库，同时提交相应的测试报告和使用说明。封装后的构件解决了程序健壮性、系统安全性和效率等问题。代码走查目的是检查开发人员是否选择了正确的构件且正确使用构件。 前台业务功能测试用例设计在参考《D系统需求规格说明书》和《D系统数据字典》的基础上，遵循GUI软件功能测试标准，主要使用边界值和等价类划分的测试方法。用例设计原则是不仅要测试程序的正确性，还要测试程序的“鲁棒性”（容忍不合法的输入并检测出来，避免给出不合理的结果）。输入数据的设计要求包括小于边界值、等于边界值、大于边界值三种等价类。 2.中台业务——流程测试D系统中台业务的特点是风险控制和流程管理。用户通过前台页面设置各类风险指标信息（信用、限额等）；前台交易数据通过中台业务工作流（授权、授信、审批等）传到后台。通过后台风险分析算法，返回风险级别判断结果，决定交易流转方向和审批路径，实现经风险调整的收益率最大化。 中台测试重点与难点是流程测试。测试任务执行始于集成测试阶段。流程的灵活配置是D系统的一大特点，给中台测试带来一定难度。流程测试用例的设计主要使用路径覆盖法。 流程验证：确认D系统中手工配置业务流程图是否与《D系统需求规格说明书》一致，逻辑是否正确。流程划分：将系统流程划分为基本流和备选流。基本流是经过用例的最简单路径，用直黑线表示。备选流自基本流开始，每个备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1和2），还可能起源于另一个备选流或终止用例而不再重新加入某个流（备选流3和4）。 场景设计：遍历所有流程分支。例如基本流-备选流2-备选流3。一旦所有分支被选择完毕，场景设计结束。设计用例：分析分支判断条件，完成测试用例设计。例如测试用例TC004是为验证当交易“结算金额账户余额”时，审批流程是否正确。 执行测试：用户、角色和权限信息是分别在系统中灵活配置的，而流程中的环节参与和用户权限密切相关。在流程用例设计时只体现角色（权限的载体）；在用例执行时，参考《D系统用户角色信息表》。 3.后台业务——深度测试D系统后台业务特点是金融算法分析的核心层，完成模拟试算、风险分析、账务推导、日切批处理等功能。为实现系统兼容性和可扩展性，将复杂计算和金融分析功能进行组件封装，集成于“金融底层”。底层对外（前、中台）有Web Service接口方式和对