银行运行监管系统接口应用测试方案.doc

运行监管系统接口应用测试方案文档信息：版本：V1.0项目：住建部运行监管系统接口应用密级：内部状态：非受控模板版本：V1.0.0修订记录：日期版本修订描述作者2011/3/10V1.0创建接口应用项目组修订内容：版本修订内容目录1. 测试方案文档标识符12. 测试方案名称13. 引言13.1. 目的13.2. 预期读者13.3. 术语表13.4. 参考资料24. 测试项25. 测试环境35.1. 硬件35.2. 软件45.3. 网络45.4. 数据45.5. 其它56. 方法详述56.1. 测试执行方法56.2. 测试类型划分57. 输入说明68. 输出说明109. 特性通过准则179.1. 用例执行179.2. 通过标准1710. 测试步骤1810.1. 准备1810.2. 启动1810.3. 记录1910.4. 处理1910.5. 度量2010.6. 暂停2010.7. 再启动2110.8. 停止2210.9. 清除2210.10. 应急221. 测试方案文档标识符无2. 测试方案名称住建部运行监管系统接口应用测试方案3. 引言3.1. 目的本文档是住建部运行监管系统接口应用的测试方案说明，在本文档中包括测试要点和对测试的安排。对住建部运行监管系统接口应用测试方案的详细描述测试方法，确定测试环境资源，规范测试步骤，制定测试度量，指导测试用例执行。3.2. 预期读者预期读者包括：项目经理项目监理质量经理测试经理，测试人员3.3. 术语表n ABIS农行综合业务系统(Agricultural Bank of China Integrated Banking System)，又称新一代业务系统，是负责帐务处理和数据处理的核心业务系统。自动转账项目的账务核算在ABIS系统实现。n Tulip金融服务平台（Tulip）。分别部署在总行数据中心和分行省域数据中心。总行金融服务平台主要负责处理总行统一开发的全国性金融产品运行。开发人员可以通过金融服务平台提供的开发客户端实现产品逻辑的配置。n 组件完成某种特定功能的一段执行代码，应用服务流程引擎执行的流程由完成不同功能的组件(或者构件)根据交易功能进行有序的组合构成。组件可通过二次开发扩充。根据组件实现方式的不同，组件可以是函数组件和程序组件(CICS下)。其中，函数组件可以用静态或者动态调用的函数实现。组件是金融服务平台的流程的组成要素，是运行环境中的最小功能单元。n C3系统CMS资产风险分类系统，是对纳入CMS管理的各项资产根据其风险程度进行分类操作的业务处理系统，是信贷资产风险管理工作的一项重要内容。3.4. 参考资料4. 测试项被测试项：测试包括如下内容：l 由对端（公积金中心）发起联机交易：一、当日明细查询交易二、历史明细查询交易三、余额查询交易四、放款(支付)备案与留痕交易五、监管客户端系统完成对帐测试与巡检测试l 行内渠道发起交易：一、C3系统调用TULIP交易获电子流交易二、现金管理系统发起动帐通知交易三、柜面发起放款(支付)备案与留痕查询不被测试项：1. 本测试项目涉及平台底层架构支持部分不予测试包括： 金融服务平台总控、组件等。2.因该项目基于成熟开发平台进行开发，故如下列表中依赖于平台的非功能需求也不予测试。功能分类1功能分类2功能非功能需求安全性操作安全数据保存安全数据传输安全系统故障处理能力时间特性联机交易系统外部响应时间并行用户支持数量可维护性可维护性-易分析可移植性可移植性-适应性5. 测试环境5.1. 硬件名称硬件环境主机IBM RISC System/6000IBM RS/6000 Scalable POWERParallel System (SP2) HP9000/800 DELL/IBM PC SERVER内存最少64M，不包括DS。磁盘空间安装与运行CICS需要的磁盘空间，参见CICS安装说明。安装与运行TULIP需要的磁盘空间，依数据量而定，最少1G。5.2. 软件名称软件环境测试环境AIX4.2.1；4.3.x；5.xHP-UXB.10.20；B.11.00CICS及相关产品CICS产品和Sybase Client端产品必须已经安装上，而且必须与应用系统TULIP在同一台物理主机上Sybase数据库服务器相关产品SUSE LINUX 10测试工具IBM 主机通讯软件 、行内ACBS系统配置管理工具Firefly缺陷管理工具Butterfly办公软件Microsoft Office 20035.3. 网络因目前与公积金中心只有一条专线，该专线现已部署在生产区，故此次测试，公积金中心方接入拟采用拨号方式拨入我方内网，同时在我方办公网络部署测试环境，进行系统测试，内网网络带宽为100M。5.4. 数据监控账号数据准备：该部分数据由现金管理系统在测试环境新开立测试账号，交付测试人员进行测试。C3放款(支付)备案留痕查询测试数据准备：该部分数据由公积金中心方提供，由公积金中心发起放款(支付)备案留痕交易记录至我方相应数据库中。5.5. 其它 要求测试人员熟悉本系统业务需求，了解各业务功能关联的交易；具备业务知识和终端操作技能，熟悉ACBS前台操作系统；能够熟练使用版本管理工具firefly和缺陷跟踪工具butterfly等测试软件，具备办公软件（Word、Excel）使用技能。6. 方法详述6.1. 测试执行方法 本次测试的范围是系统功能测试，采用黑盒测试方法，即将被测软件看作一个黑盒，在完全不考虑程序内部结构和内部特性的情况下，站在用户的角度上，通过用户界面（GUI）与应用程序进行交互，通过软件规定的方式，输入在测试用例里面规定的信息，检验软件的输出结果是否符合预期的结果。测试用例的设计主要针对流程的实现和通讯的连接方式，测试方法采用等价类划分法，边界值分析法，场景流分析法，错误推断法和正交分析法等对被测特性进行分析，使得测试范围内的被测特性均有用例覆盖，能够满足用户需求。6.2. 测试类型划分6.2.1对端发起交易类型的测试1、 当日明细查询交易 该交易由监管系统、公积金中心发起，根据输入要素至现金管理系统查询当日指定条件下的明细，输出明确成功失败信息及明细信息至公积金中心。2、 历史明细查询交易 该交易由监管系统、公积金中心发起，根据输入要素至现金管理系统查询历史明细记录，输出明确成功失败信息及明细信息至公积金中心。3、 余额查询交易 该交易由监管系统、公积金中心系统发起，根据输入要素查询指定账户余额，并将余额信息输出至公积金中心，并返回明确成功失败信息。四、放款(支付)备案与留痕交易该交易由监管系统、公积金中心发起放款备案通知，我方收到后回复确认收到的业务功能，同时在我方记录相应数据记录，并返回明确成功失败信息。五、监管客户端系统完成对帐测试与巡检测试 该交易由公积金中心发起，银行方返回明确成功失败信息以及账户历史明细，供公积金中心方进行对账与巡检。6.2.2行内渠道发起的交易类型的测试1、 C3系统调用TULIP交易获电子流交易 该交易由我行C3系统发起，调用放款(支付)备案与留痕查询交易，对已备案数据进行查询，并接收明确成功失败信息。2、 现金管理系统发起动帐通知交易 该交易由现金管理系统发起，将变动账户信息发送至公积金中心监管系统，并接收明确成功失败信息。3、 柜面发起放款(支付)备案与留痕查询 该交易由柜员发起，交易功能同C3系统调用TULIP交易获电子流交易7. 输入说明7.1对端发起交易类型1、 当日明细查询交易输入项：查询账地区代码发生额下限发生额上限开始时间终止时间查询下页标识请求包备用字段1请求包备用字段22、 历史明细查询交易输入项：查询账号起始日期截止日期发生额下限发生额上限查询下页标识请求包备用字段1请求包备用字段23、 余额查询输入项：总笔数请求包备用字段1请求包备用字段2指令顺序号帐号币种请求包备用字段3请求包备用字段44、 放款(支付)备案与留痕交易输入项：借款人名称地址开户银行账号项目名称项目性质金额期限贷款名称客户名称借款合同编号贷款金额资金封闭管理账号支用申请表编号本次支用金额序号渠道签名时间请求备用字段1请求备用字段2五、监管客户端系统完成对帐测试与巡检测试输入项：查询账号起始日期截止日期发生额下限发生额上限查询下页标识请求包备用字段1请求包备用字段2如非必输项无对应数据，则不输入。7.2行内渠道发起的交易类型1、 C3系统调用TULIP交易获电子流交易输入项：借款人名称地址开户银行账号项目名称项目性质金额期限贷款名称客户名称借款合同编号贷款金额资金封闭管理账号支用申请表编号本次支用金额序号渠道签名时间请求备用字段1请求备用字段2如非必输项无对应数据，则不输入。2、 现金管理系统发起动帐通知交易输入项：无三、柜面发起放款(支付)备案与留痕查询借款人名称地址开户银行账号项目名称项目性质金额期限贷款名称客户名称借款合同编号贷款金额资金封闭管理账号支用申请表编号本次支用金额序号渠道签名时间请求备用字段1请求备用字段2如非必输项无对应数据，则不输入。8. 输出说明8.1对端发起交易类型1、 当日明细查询交易账号户名币种地区代码查询下页标识交易条数响应备用字段1响应备用字段2借贷标志凭证号发生额对方行号对方账号对方户名摘要用途附言业务编号业务代码相关业务编号英文备注业务种类凭证种类附加信息时间戳响应备用字段3响应备用字段4输出项中如无数据，则留空。2、 历史明细查询交易输出项：账号户名币种起始日期截止日期发生额下限发生额上限查询下页标识交易条数响应备用字段1响应备用字段2借贷标志凭证号借方发生额贷方发生额余额对方行号对方行名对方账号对方户名摘要用途附言业务代码交易日期时间戳业务编号相关业务编号英文备注业务种类凭证种类附加信息响应备用字段3响应备用字段4输出项中如无数据，则留空。3、 余额查询交易输出项：指令顺序号账号币种钞汇标志账户属性昨日余额当前余额可用余额冻结额度合计查询时间返回码返回描述响应包备用字段3响应包备用字段4输出项中如无数据，则留空。4、 放款(支付)备案与留痕交易输出项：借款人名称地址开户银行账号项目名称项目性质金额期限贷款名称客户名称借款合同编号贷款金额资金封闭管理账号支用申请表编号本次支用金额序号渠道签名时间请求备用字段1请求备用字段2输出项中如无数据，则留空。5、 监管客户端系统完成对帐测试与巡检测试输出项：账号户名币种起始日期截止日期发生额下限发生额上限查询下页标识交易条数响应备用字段1响应备用字段2借贷标志凭证号借方发生额贷方发生额余额对方行号对方行名对方账号对方户名摘要用途附言业务代码交易日期时间戳业务编号相关业务编号英文备注业务种类凭证种类附加信息响应备用字段3响应备用字段48.2行内渠道发起的交易一、C3系统调用TULIP交易获电子流交易输出项：借款人名称地址开户银行账号项目名称项目性质金额期限贷款名称客户名称借款合同编号贷款金额资金封闭管理账号支用申请表编号本次支用金额序号渠道签名时间请求备用字段1请求备用字段2二、现金管理发起动帐通知输出项：明细记录数量响应备用字段1响应备用字段2账号户名币种Swift行号交易序号入账日期入账时间正反交易标志冲正标志借贷标志凭证种类凭证号贷方凭证种类贷方凭证号发生额对方行号对方行名对方账号对方户名对方入账账号对方入账户名对方入账行号外汇统计代码外汇结算方式摘要用途附言业务编号相关业务编号流水号业务代码英文备注附加信息ERP支票号付款批次响应备用字段3响应备用字段4三、放款（支付）备案及留痕查询输出项：借款人名称地址开户银行账号项目名称项目性质金额期限贷款名称客户名称借款合同编号贷款金额资金封闭管理账号支用申请表编号本次支用金额序号渠道签名时间请求备用字段1请求备用字段29. 特性通过准则9.1. 用例执行针对每个可测试特性的不同测试方法，均有测试用例覆盖。每个测试用例均执行，且每个测试用例结果均有记录。9.2. 通过标准对测试的结果主要采取人工比对测试用例执行结果的方法，测试结果是否与测试用例相一致，是否满足特性通过准则的要求，是否符合测试用例通过率，以此来判定测试结果的正确性。最后对测试用例的执行过程和结果按照缺陷严重性定义进行分类，并针对严重程度区分优先级进行测试，功能A类、B类、C类缺陷已经全部解决并通过回归测试；未解决的D类缺陷数量 3%（100个测试用例中，未解决的D类缺陷少于3个）。所有的测试点均执行并通过了测试，且达到了最低程度的测试彻底性。10. 测试步骤10.1. 准备申请测试人员；提交环境申请表至测试环境负责部门；开发部门发布测试版本至测试环境；开发部门检查各子系统及联通性保证环境的真实性；准备测试用例测试数据；10.2. 启动执行本规程必须验证以下几方面内容1、技术环境达到启动标准，软件迁移到测试环境成功； 2、环境验证可用：包括客户端程序、不同级别操作员的权限的有效性（总行、一级分行、二级分行、支行），后台环境，通讯机环境；3、测试数据已经按照规程和用例要求准备完毕，并经过确认可用；4、确认测试，通过执行冒烟测试，验证硬件、软件环境是否可用，是否达到启动标准；5、测试文档；6、测试执行人员准备就绪，任务分配完成；10.3. 记录每天测试完毕提交测试记录，记录包括测试日志和事件报告。用来记录当日测试的执行进程，记录与测试计划规定进度的差异；对每个事件记录记录发生的日期和时间，并记录记录者。日志采用表格方式，包括当日事件报告提交数及解决情况，上一测试工作日遗留的待解决测试事件报告的情况。这些将有助于把握测试进度及跟踪测试事件。专人汇总生成当日项目测试日志上报项目负责人。10.4. 处理1、测试活动正式启动后，测试人员根据测试任务分工表和测试工作进度表对自己测试任务进行合理安排，在规定时间内完成有效测试，并做好测试记录（如有必要可以提交测试记录文档）。2、测试过程中，测试人员发现问题，则须填写问题报告单，将测试所出现的问题完整记录，记录测试现象，以便对问题进行后续分析，并在Butterfly中进行详细描述以便于开发人员定位原因。3、经开发人员分析确认属于缺陷的问题，提交给项目开发经理，由开发经理分配给相应的开发人员进行处理，开发人员对所属的测试缺陷要及时进行处理，并反馈处理情况；如果开发人员认为不是缺陷且与测试人员达成一致共识，则可以将问题单打回给测试提交人员关闭；如有争议的缺陷时，则召开项目组相关各方会议进行讨论，达成共识，确定缺陷处理办法。4、对于缺陷修改情况的处理，要求在下个回归测试版本发布前完成缺陷的修改，如果出现有争议的缺陷或者在下个回归测试版本发布前无法修改完成的缺陷，需要在缺陷跟踪表中进行记录，待之后的版本再进行回归测试。5、按照测试进度，对不通过的测试用例提交缺陷管理后，经开发组修改完善，并在修改后发布的版本进行回归测试，如依然有问题，则回归测试不通过，由开发组继续修改，直至问题解决。当某些缺陷由于其连续执行了各种异常或正常用例，构造了复杂的测试环境，开发组进行缺陷修改时发现问题很难复现时，协助开发组一起构造测试场景，对无法复现的缺陷需要经项目组讨论当作遗留问题记录下来，分析风险并给出规避措施。6、各缺陷提交人员负责对自己所提交缺陷的跟踪情况。整个过程中，由测试人员负责全部测试文档整理、汇总及相关的缺陷统计分析工作。测试人员按照测试用例中的测试用例描述执行测试，记录与预期结果不符的实际结果、系统功能通过情况、缺陷等级、系统版本号和需求版本号。10.5. 度量通过将测试输出结果与测试用例中的预期结果进行比对，来判断测试是否成功。根据测试结果的不同，用例状态可分为：通过，失败，阻塞，忽略，其他。具体分类规则，可参考测试用例说明附件。测试结束后，除度量用例个数，用例覆盖率，用例通过率，缺陷个数等数据之外，还需要对以下数据进行度量：系统测试阶段缺陷率：系统测试阶段缺陷数（个）/ 系统测试阶段产品功能点数（FP）系统测试阶段缺陷平均滞留时间：系统测试阶段缺陷总滞留时间（小时）/ 系统测试阶段缺陷数（个）系统测试阶段测试缺陷严重程度比例：系统测试阶段各严重程度缺陷数（个）/ 系统测试阶段缺陷数（个）系统测试缺陷注入阶段比例：各阶段注入的缺陷数（个）/ 系统测试阶段缺陷总数（个）系统测试阶段测试效率：系统测试阶段用例数（个）/ 系统测试阶段实际测试总工作量（人时）系统测试阶段测试用例效率：系统测试阶段缺陷数（个）/系统测试阶段用例数（个）10.6. 暂停在发生如下情况时，经与项目负责人和业务负责人沟通，确认意见一致后，暂停测试活动：（1）测试中发现的系统缺陷导致后继测试无法进行；（2）测试中发现的系统缺陷导致产品设计的更改，在更改完成前所做测试没有意义。（3）发生其他导致测试暂停的事项。与被测项无关的暂停在测试的过程中，如果由于执行测试的硬件故障、支撑系统（包括操作系统、数据库、中间软件）由于使用不当而发生了不可逆转的损坏以至不能正常工作；被测试系统在测试中频繁出现异常（每小时出现1次以上）时、测试环境被破坏而导致测试无法进行；参加测试的关键人员由于与测试无关的原因不能继续进行测试工作，则需要暂停测试。与被测试项相关的暂停在测试的过程中，如果测试不能进行下去，包括软件不能接收输入、软件进入死循环、在特定的输入下导致被测试软件的崩溃、软件不能产生输出以至影响了后继测试，提交问题很长时间没有得到解决，导致相关联的测试无法进行等。需要暂停测试。10.7. 再启动与被测项无关的暂停再启动对于由于硬件引起的暂停，应在修复、更换硬件后再启动测试；对于由于支撑系统（包括操作系统、数据库、中间软件）引起的暂停，应在重新安装或更换已经安装好的支撑系统后再启动测试；对于由于测试的关键人员引起的暂停，应由测试的组织者进行评估，以确定是换人继续测试或等待该人员恢复可以