XX银行核心系统UAT报告

编号密级XX银行核心系统UAT测试报告（V1.1）XX银行XXXX2011-07-04目录目录 2文档修订记录 7文档评审记录 8文档导读 9第1章 前言 11编写目的 11项目简介 11文档特性 11参考资料 11术语解释 12第2章 测试概要 13测试范围 132.1.1 功能测试 132.1.2 核心相关接口测试 132.1.3 外围系统测试 142.1.4 用户权限测试 142.1.5 数据移植测试 142.1.6 自动化测试 142.1.7 回归测试 152.1.8 报表测试 15测试策略 152.1.9 功能测试 152.1.10 测试范围及测试需求确认 162.1.11 跑批计划 172.1.12 版本部署 172.1.13 参数设置 172.1.14 测试数据 172.1.15 测试执行 182.1.16 UAT环境管理 182.1.17 核心相关接口测试 182.1.18 外围系统测试 192.1.19 报表测试 192.1.20 用户权限测试 202.1.21 数据移植测试 202.1.22 自动化测试 212.1.23 回归测试 212.1.24 参数测试 21UAT结束条件 22测试周期 22测试资源 232.1.25 人力资源 232.1.26 环境资源 26交易执行清单 27版本信息 27第3章 测试结果 29准出评估 29测试覆盖率明细 30案例通过率明细 31交易通过率明细 31历史存量数据使用情况 32缺陷总体情况 33缺陷分类 34缺陷率分析 34遗留缺陷严重级分布 35遗留缺陷业务分布 36遗留缺陷状态分布 37遗留问题 37第4章 测试过程分析 42交易送测记录 424.1.1 公共 424.1.2 支付 434.1.3 中间业务 434.1.4 国际业务 444.1.5 负债 454.1.6 资产－信贷 464.1.7 资产－个贷 47UAT第一轮 484.1.8 概要情况 484.1.9 案例可执行率 494.1.10 案例执行率 504.1.11 用例执行趋势图 504.1.12 案例通过率 514.1.13 交易覆盖度&交易通过趋势 524.1.14 交易通过率 524.1.15 缺陷状态分布 534.1.16 缺陷有效性 534.1.17 缺陷修复率 544.1.18 缺陷严重级分布 544.1.19 缺陷增长趋势 554.1.20 缺陷生命周期 564.1.21 重大问题列表 57UAT第二轮 594.1.22 概要情况 594.1.23 案例执行率 604.1.24 用例执行趋势图 614.1.25 工作量分析 614.1.26 人均执行案例数明细 624.1.27 案例通过率 624.1.28 交易通过率 634.1.29 缺陷状态分布 644.1.30 缺陷有效性 654.1.31 缺陷修复率 654.1.32 缺陷严重级分布 664.1.33 缺陷增长趋势 674.1.34 缺陷生命周期 684.1.35 重大问题列表 69UAT第三轮 704.1.36 概要情况 704.1.37 案例执行率 714.1.38 用例执行趋势图 724.1.39 工作量分析 734.1.40 人均执行案例数明细 744.1.41 案例通过率 754.1.42 交易通过率 764.1.43 缺陷状态分布 764.1.44 缺陷有效性 774.1.45 缺陷修复率 784.1.46 缺陷严重级分布 784.1.47 缺陷增长趋势 794.1.48 缺陷生命周期 804.1.49 重大问题列表 81UAT第四轮 824.1.50 概要情况 824.1.51 案例执行率 834.1.52 用例执行趋势图 834.1.53 工作量分析 854.1.54 人均执行案例数明细 864.1.55 案例通过率 864.1.56 交易通过率 874.1.57 缺陷状态分布 884.1.58 缺陷有效性 884.1.59 缺陷修复率 894.1.60 缺陷严重级分布 904.1.61 缺陷增长趋势 914.1.62 缺陷生命周期 914.1.63 重大问题列表 92回归测试 93第5章 T+1报表测试情况 935.1.1 T+1报表测试策略 945.1.2 T+1报表总体测试情况 945.1.3 缺陷情况汇总 955.1.4 T+1遗留报表清单 955.1.5 T+1相关缺陷分析 975.1.6 T+1重大问题 97第6章 外围系统测试情况 986.1 送测变更记录 986.2 总体测试结果 996.2.1 总体交易通过率 996.2.2 重要交易通过率 1016.2.3 外围子系统通过情况 1016.2.4 缺陷情况 1026.3 重大问题历史 1046.4 遗留问题汇总 105第7章 批处理情况 106批处理流程 106批处理概要 1067.1.1 跑批的频率 1067.1.2 批处理的平均时间 1077.1.3 批处理问题解决的时间 108问题历史 1117.1.4 批处理问题增长趋势 1117.1.5 批处理问题严重级分布 1117.1.6 批处理问题列表 1127.1.7 批处理问题解决过程 112第8章 自动化测试情况 113自动化实施目的 113自动化实施方案概要 1138.1.1 自动化实施架构 1138.1.2 自动化实施过程 114自动化实施目标 115自动化实施周期 115自动化实施难点 115自动化实施结果 1168.1.3 交易完成情况 1168.1.4 测试场景完成情况 1188.1.5 用例完成情况 119第9章 总结 121总结 1219.1.1 外部因素 1219.1.2 内部因素 123建议 1239.1.3 实施建议 1239.1.4 管理建议 124第10章 附录 124数据源与计算公式 12410.1.1 测试结果 12410.1.2 测试过程 12510.1.3 批处理情况 126附件列表 126工具列表 127

文档修订记录编号版本号修订内容简述修订日期作者1V0.6初稿2011-6-12武飞2V0.7更新2.1.4用户权限表2011-6-30梁国成3V0.8增加第四轮测试结果2011-7-1唐敏4V0.9增加报表测试结果2011-7-4吴颖莹5V1.0更新测试数据2011-7-5唐敏6V1.1评审结果修订2011-7-8费志明

文档评审记录编号文档版本号评审内容简述评审日期评审结果附件1V0.62011-6-14修改补充后继续评审文档导读目录导读一级目录二级目录第一章前言描述本文档的特性和背景信息，帮助读者建立一个阅读理解的基础编写目的描述本文档的编写目的项目简介简洁介绍XX银行UAT的项目背景文档特性描述本文档的适应性和预期读者范围参考资料罗列本文档使用到的参考资料，以及统计数据来源第二章测试概要描述UAT测试的总体情况概要，包括策略，资源，时间等方面的信息测试范围描述UAT测试预期覆盖的范围测试策略描述UAT测试过程所使用的策略UAT结束条件定义UAT的结束条件测试周期描述整个UAT的测试时间周期测试资源描述整个UAT的资源使用情况，包括人力以及环境交易执行清单罗列所有交易的执行人员清单版本信息罗列整个UAT发布的所有核心系统版本列表第三章测试结果统计和分析UAT最终测试结果，为测试准出评估提供参考数据准出评估统计UAT准出度量指标值，分析是否达到准出条件测试覆盖率明细UAT最终测试覆盖率的明细数据分析案例通过率明细UAT最终案例通过率的明细数据分析交易通过率明细UAT最终交易通过率的明细数据分析缺陷总体情况UAT最终缺陷的总体情况，已关闭的数量和遗留缺陷的数量缺陷有效率整个UAT提交的缺陷中，有效缺陷的比率缺陷率统计缺陷发生率，包括交易平均缺陷率，用例平均缺陷率等遗留缺陷严重级分布分析UAT最终遗留的缺陷的严重级的分布情况遗留缺陷业务分布分析UAT最终遗留的缺陷的业务分布情况遗留缺陷状态分布分析UAT最终遗留的缺陷的状态分布情况遗留风险分析以UAT当前的质量上线，会存在什么样的风险第四章测试过程分析统计和分析UAT整个过程，总结和评估测试组的工作，报表和外围系统在独立章节单独描述交易送测记录详细描述核心系统交易送测的时间点和趋势UAT第一轮详细描述UAT第一轮的测试情况UAT第二轮详细描述UAT第二轮的测试情况UAT第三轮详细描述UAT第三轮的测试情况UAT第四轮详细描述UAT第四轮的测试情况回归测试详细描述最终回归测试的测试情况第五章T+1报表测试详情总结和分析T+1报表的测试详情第六章外围测试详情总结和分析外围系统的测试详情第七章批处理情况统计和分析批处理的执行情况批处理流程描述批处理的执行步骤和相关责任人批处理概要抽取5月上半月的批处理日志数据，统计和分析批处理的执行情况问题历史列举和分析批UAT的批处理执行过程中曾遇到的重大问题第八章自动化测试情况总结和分析自动化的实施情况自动化实施目的描述自动化实施的目的自动化实施方案概要简述自动化一期的实施方案自动化实施目标描述自动化实施的目标自动化实施周期描述自动化一期的实施周期自动化实施难点记录自动化一期实施过程中面临的困难自动化实施结果描述自动化一期实施的成果第九章总结以测试的专业角度进行全局总结并给出改进建议总结以测试的专业角度总结成都核心UAT的测试情况建议以测试的专业角度给出改进建议第十章附录本文正文信息以外的一些额外说明和明细文档数据源与计算公式列举本文中的统计数据来源以及各种度量数据的计算公式附件列表附上与本文有关的可查阅资料工具列表罗列编写本文使用到的工具

前言编写目的本文档总结了XX银行核心系统的UAT活动以及测试结果，旨在从整体上分析项目的质量情况，为项目验收提供参考数据。项目简介为了快速适应日新月异的市场变革、达到优化业务流程和人力资源配置、提升客户服务水平、提高业务处理效率、快速创新金融产品、加强风险控制能力、支持管理决策系统，支撑未来业务规模扩张和跨区域发展，XX银行决定全面投入新一代核心业务系统的建设，应对未来发展的需要。新一代核心系统，主要采用神州数码公司的核心业务系统产品Ensemble为基础，根据XX银行的实际业务需求进行客户化开发。其主要过程包括：差异化分析、设计、客户化开发、外围系统开发和联调、测试、上线等工作。新一代核心系统，既要保证提供完整强壮的业务功能，又需要满足系统的性能和稳定性要求。为此，XX银行需要对新一代核心系统组织有效、系统化、全面的测试。测试内容上包括系统原有业务功能和差异化业务功能的验收测试、回归测试和自动化测试；测试过程上需要涵盖测试计划和需求分析、测试设计、测试执行、测试总结和交付等阶段。通过新一代核心系统用户验收测试项目，XX银行要求服务商制定完整、规范、实用的测试组织、流程和标准体系，来进一步规范和加强XX银行的测试和质量管理体系。文档特性适应性：本文档适用于XX银行核心系统UAT第一期的总体分析。最终测试结果数据来自CDBankSymbols_UAT_BL04_Patch041版本（核心以及数据平台），以及截至到2011年6月30日当日的外围系统版本。文档使用者范围：XX银行行方领导，XX银行各业务部门，XXXX项目团队参考资料《XX银行核心业务UAT测试方案V2.2》《UAT准入准出条件》《XX银行核心业务UAT测试执行方案V1.1》《外围系统UAT方案》《自动化测试方案V1.5》《UAT第一轮测试日报汇总》《UAT第二轮测试日报汇总》《UAT第三轮测试日报汇总》《UAT第四轮测试日报汇总》《XX银行核心系统自动化测试工作汇报》QC的统计图表Change的统计图表《交易质量表》《重大问题跟踪列表》《冒烟测试结果记录》《版本部署列表》《UAT批处理日志》术语解释SIT：SystemIntegrationTest，系统集成测试UAT：UserAccessibleTest，用户验收测试冒烟测试：在测试版本发布到测试环境中后，进行简单验证确保测试版本的制作和部署是有效的，可测的。回归测试：执行已经执行过的测试内容，目的是验证缺陷的修复情况，以及测试版本的更新对原有的系统功能所带来的影响。FS：FunctionSpecification，需求规格说明书BRD：BusinessRequirementDescription，业务需求说明书（原始需求）QC：QualityCenter，HP-MI的过程管理工具Change：TelelogicChange，缺陷管理工具

测试概要测试范围功能测试UAT测试团队将根据以下经核心系统项目组确认过后的功能列表进行用户验收测试。测试范围依据：核心系统开发组提供的全功能列表（由于全功能列表在项目周期中一直处于变更状态，因此整个项目周期中将分若干次对“BOCD-交易汇总”表进行更新，以下交易汇总表是来自《XX银行核心业务UAT测试方案V2.2》的最新数据。）(功能范围以XX银行新核心系统第一期上线后将涵盖的业务范围为主，其余新核心系统现有功能如在上线后不使用，则不在此次UAT的测试范围内)核心系统功能分析列表集：UAT测试团队将在测试需求阶段完成功能列表的分析及梳理，并通过业务及技术组评审。核心系统功能分析列表集，将在测试需求阶段完成V1.0版本，在整个测试周期中若存在变更的要求，则需通过UAT测试组组长对变更进行评审，评审通过后提交UAT测试项目组报备。核心系统功能分析列表集清晰、详细地记录了每个交易功能点的业务需求，该文档集内容庞大，在本篇报告中不附加实体文件，详细内容请参见UAT测试的交付物。核心相关接口测试接口测试主要关注“核心系统”相关的接口，接口分为对内部系统，对外部系统，凡“核心系统”交易流程所涉及的系统，应该被纳入到“核心系统”相关接口测试范围内。内部接口测试外部接口测试使用行内现有外围系统进行联机测试（由环境组提供）使用外围系统模拟器进行测试，由环境、项目组提供通过实时联机进行测试（如央行，银联等）根据功能说明书模拟发送/接收的报文接口测试的需求点已经整理进了每个业务子系统的核心系统功能分析列表中，接口相关的测试将渗透在各个业务测试组的执行过程中。外围系统测试外围系统本身对接口报文处理的功能测试属于XX银行UAT测试项目组管理范围内，承担测试任务和提供测试结论的主要是各外围系统的业务管理部门，UAT测试项目组为外围系统的测试提供技术支持、统筹安排、和方法指导等工作。用户权限测试UAT测试团队将根据以下经业务部门确认过后的用户权限列表设计测试用例进行用户验收测试，详见下表：数据移植测试数据移植测试不包含在UAT主要测试范围内。在UAT测试的中后期会在测试用例的执行过程中使用历史存量数据。自动化测试UAT测试团队将在UAT项目结束后，分阶段把可覆盖的测试用例转换成自动化脚本。预期在UAT第一期结束前实现首批测试用例的的自动化，覆盖约20%的交易。自动化测试主要应用于系统稳定后的回归测试，冒烟测试，系统移植测试，数据迁移测试等。回归测试UAT测试团队将会进行必要的回归测试，保证系统质量。部分回归测试将由自动化测试工具进行。报表测试UAT测试团队将对核心涉及的T+0、T+1报表进行验证，保证报表正确。全量报表清单详见下表，核心业务测试组负责测试的范围见下表：对历史数据中心相关的报表，需要历史数据中心项目小组完成此报表的验证工作。测试策略功能测试阶段划分：整个UAT测试划分为四个正式执行阶段：阶段说明准UAT测试UAT测试准备阶段，UAT团队根据SIT在12月份提交的部分交易进行测试，同时达到测试演练的目的UAT测试第一轮对送测的交易正式进行测试UAT测试第二轮对全量交易进行全业务流程测试UAT测试第三轮导入历史存量数据，对全量交易进行全业务流程测试，回归验证缺陷UAT测试第四轮全量回归测试提交测试的版本首先通过SIT环境的测试验证，随后经过UAT项目组评审（正常情况下，一周两次）通过后发布版本到UAT环境中，进行回归测试。对于紧急程度高、影响范围大的缺陷，将第一时间通过联络（接口）人进行及时沟通，并将在《UAT测试日报》中汇总这些问题，及时尽快的解决这些问题，并发布紧急版本修复并安排回归测试。第一轮测试为预测试，该阶段主要通过对测试人员的培训、实践，帮助其掌握测试知识，了解测试流程，提高测试能力；同时为测试流程的顺利开展提供预演练、优化的机会；同时考虑到开发组在此阶段的工作量比较繁重，因此，本轮的测试主要对缺陷等进行记录、但不上报，因此，也就不存在缺陷的回归测试；此阶段计划进行0.5到1个月，完成后对测试情况进行总结。第二轮测试为首轮正式测试，经过对项目缺陷率的评估，得出的缺陷率为每3-5个用例产生1个缺陷，考虑到该阶段部分缺陷与SIT提出的缺陷存在重复现象，UAT既定的每人每天完成其测试用例25%的回归测试（该值为整个一轮测试的平均值）；第三轮测试中预计将数据转换组的工作成果，部分（or全部）纳入到UAT测试环境中，供UAT组进行更贴近实际生产环境的测试工作，预计本阶段的缺陷率会控制在每5个用例产生1个缺陷的比率，因此安排每人每天完成的用例回归比率为20%；该阶段可能会在测试过程中遇到与数据转换组相关的缺陷，原则上UAT组的测试重点不是数据转换的结果，而是通过这些数据，对系统进行全面验证。第四轮（假设此轮为最后一轮），需要对所有的缺陷进行跟踪回归，确保各个缺陷被及时修复，此轮测试开始之前，需要对系统历史缺陷的总体情况进行回顾，制定本轮的测试重点和执行计划，以确保此轮有充分的时间和关注点，保障系统的质量。关键节点：UAT测试是以SIT准出为基点，各期的具体计划将受到SIT进度的影响。测试范围及测试需求确认UAT测试团队在测试需求分析阶段，与业务团队和开发团队合作，明确各个阶段的测试范围,形成的文档作为将来测试范围的依据。需要业务部门为主导，根据XX银行实际业务需求、业务功能列表等资料，指导各测试小组成员，完成测试需求分析：小组划分：国际业务、负债业务、资产业务、支付业务、公共业务、中间业务；业务部门成员组成：国际业务、公司业务、个金部、风管部、计财部、会计部；需要开发团队提供支持，由UAT测试团队与开发团队协调，每天安排至少1次讨论，回答由业务团队及UAT测试团队共同提出的与系统相关的问题。讨论可按业务分组，分别进行；需要业务团队及开发团队对测试范围及测试需求进行评审及确认；跑批计划UAT测试团队将根据实际测试用例设计的情况，向开发团队和业务团队提交跑批计划。跑批计划中的业务日期将覆盖普通工作日、结息日、月中、月底、季度底、半年底及全年底（结算与报表）。由于新核心系统月初，月末，结息日前两天必须跑批，初步计划在第一期测试执行开始后，每天2次跑批。在测试用例设计结束后，调整跑批次数，提交最后的跑批计划。测试执行过程中，按每轮次的不同策略，调整跑批计划。版本部署常规的部署时间窗口如下：每周一，三，五12：00-14：00如果需要紧急部署，则要得到UAT测试团队书面或者邮件同意才能进行。根据项目进度，可以调整部署次数。参数设置新核心项目组参数管理委员会负责。参数管理委员会负责向UAT提供测试使用的参数。因为SIT,UAT并行进行，如果SIT或UAT对参数进行变更，需要SIT和UAT沟通，评审参数变更对SIT和UAT测试的影响。UAT测试组需遵守项目组的参数管理流程，在项目过程中（尤其是测试执行过程中），需对参数配置进行验证，如参数配置存在缺陷，需提交参数缺陷。参数缺陷管理流程：缺陷提出UAT组接口人与参数组确认缺陷，参数组统筹对参数缺陷的管理->参数修改，或交由项目组修改程序->UAT组接口人确认修改情况及回归版本->缺陷提出方针对回归测试版本进行回归测试。测试数据UAT测试团队将在测试用例设计阶段，提交测试数据列表，包含三部分：UAT测试团队可以准备的数据（基础预埋数据、用例中使用数据）参数组帮助准备数据并配置参数，数据以真实环境为基准需要开发团队帮助准备的数据，如可测试交易清单等开发团队根据列表准时提供相应的测试数据，以协助UAT测试团队完成验收测试。测试执行UAT测试团队将要求核心业务部门派出至少一名部门代表共同参与测试执行和项目组共同完成如下工作：业务知识提供，业务人员在UAT执行阶段对业务知识进行必要的指导；需要在测试执行后代表业务部门确认测试结果从业务角度发现问题，保证业务上没有重大缺陷提早帮助用户熟悉核心系统，完成知识转移确认UAT测试团队与开发团队有争议的缺陷UAT测试团队将安排行内多名人员负责、参与测试执行工作；这些人员需要在测试执行期前完成相关技能的培训；负担相关案例的测试工作、缺陷发现提交工作、回归测试工作；测试执行将根据项目实际要求进行迭代的回归测试，回归测试的轮次需按照项目周期、人力资源情况、SIT准出质量进行合理调整；UAT环境管理UAT测试组将安排专职配置管理人员进行UAT环境管理，技术组需要提供技术支持，可不能改动UAT环境，UAT执行码和参数，参数修改需走参数修改流程，统一由参数组进行修改。核心相关接口测试内部接口测试内部接口指核心业务系统各模块、交易所用接口，将会在端到端的功能测试用例中进行覆盖。外部接口测试外部接口主要非为两类：“行内系统外部接口”，主要是指XX银行行内的系统与核心相关接口（如：信贷系统）；“行外系统外部接口”，主要是指XX银行行外的系统与核心相关的接口（如：银联）两类主要接口的测试策略略有不同：“行内系统外部接口”优先使用“行内搭建的测试系统”进行交易级别的收发测试；若无法满足“行内搭建”的要求，则选择挡板或系统模拟器进行报文级别的收发测试；若无法满足“模拟器、挡板”的要求，则需要采用实连的方式，进行交易级别的收发测试；“行外系统外部接口”前期，优先使用“搭建真实测试模拟器”（真实测试模拟器指“行外机构”认定的，官方版本的测试模拟器）进行交易级别的收发测试；前期，备选使用“搭建挡板、模拟器”进行交易级别的收发测试；中后期，优先使用“行外真实系统”进行交易级别的收发测试；中后期，备选使用“搭建挡板、模拟器”进行交易级别的收发测试；外围系统测试XX银行与此次“核心相关”的外围系统共有48个（因统计归纳范围不同，各口径略有出入），与12个业务部门有关。针对这些外围系统，统一采用：UAT管理团队统筹、协调、管理；“核心系统”UAT测试团队提供体系方法、模板工具、技术支持；各业务部门牵头负责各自管辖的外围系统，安排人员、资源进行业务的梳理、测试用例的编写、测试用例的执行。报表测试T+0报表按查询交易的方式，实时联机进行测试，保证报表正确。T+0报表的测试工作，将按照普通案例的测试流程，在日常测试中，将T+0报表的测试融入到其中。T+0报表的正确性，应该有UAT测试人员根据测试案例的情况进行确认，如部分报表无法得到确认，需将此情况上报UAT项目组，由UAT项目组协调业务部门进行确认。T+1报表UAT组根据业务组提供的报表样式、数据说明、表头表尾说明等，从报表生成、报表样式、数据提取统计及报表输出进行验证，保证报表生成、表样及输出数据项的正确。T+1报表的测试，需要对机构、柜员进行区分；跑批计划也受到T+1报表的限制；机构与柜员的分配、跑批计划的制定，需要与T+1报表的案例需求相结合，完成T+1报表的测试工作。T+1报表中的数据输出，其正确性，先应该有UAT测试人员进行初步判断；针对其数据、内容的正确性，需要经过业务部门的签字确认。针对此情况，提供两种解决方案：1）测试人员在测试T+1报表时，记录测试用相关数据，跑批后触发T+1报表，将“测试用相关数据”与“触发的T+1报表”一起提供给报表的需求部门，有需求部门确认报表的正确性；2）将T+1报表的测试周期尽量集中在一个时间段，业务部门现场指导UAT测试执行人员，由UAT测试执行人员完成测试工作，有业务部门现场对T+1报表进行确认。“历史数据中心”相关报表历史数据中心主要包含有T+0、T+1两类报表，并且分布在数据分析前、数据分析后。按照此历史数据中心的开发进度、需求发起部门的实际情况，相关的报表需要按照历史数据中心的开发情况订立测试策略、测试周期、测试资源。UAT测试项目组需要共享项目中的体系、方法论，为历史数据中心测试提供参考依据。用户权限测试UAT测试团队将根据实际生产环境，定义用户组及相关权限，在功能测试中，测试用例设计及测试执行过程中将使用相关用户组中的用户。用户权限作为参数的一部分，将统一提交项目参数管理人员。用户权限测试在UAT阶段，策略上分为两个阶段，第一阶段将结合“超级权限用户”与“受限权限用户”相结合的方法进行测试，此阶段主要针对系统功能上的测试，不严格对用户权限的设置合理性进行验证；第二阶段，将按照参数组给予的符合生产环境（或参数组给出的与生产环境等价）的用户权限，并遵照此权限进行功能性测试，通过功能性测试，验证用户权限设置的合理性（用户权限设置的合理性性的依据为：《XX银行用户权限、授权规则》，《测试用例》）。用户权限设置如违背以上两准则，需要将此缺陷提交公共组统一汇总，由公共组确认后提交缺陷。参数组针对缺陷进行评审及修复意见，通过权限定义脚本、系统修复等形式修复此缺陷，提交UAT组进行回归验证。数据移植测试移植数据的准确性由数据移植团队负责，保证移植数据符合老核心系统、新核心系统的要求，并保证移植数据符合新核心系统的数据结构要求。在数据一致、等价测试通过后，（按照数据移植组确认的移植完成日期安排加载计划），结合UAT功能测试计划，通过加载移植数据组的工作成果，来模拟UAT在真实数据中的测试情况。移植数据的对数据移植后，新核心系统使用数据，需要保障：1）原有核心系统的数据完全导入（除需要清理的数据）；2）原有核心系统的数据在新核心系统内均可见，且可被新核心业务覆盖、操作；3）保障新老核心对数据操作的结果一致；UAT核心系统测试团队，在数据迁入UAT环境后，主要以核心系统交易为基准，通过交易来验证核心系统功能的完备性，是否对XX银行已有的历史数据提供了良好的兼容性，在已转换的数据上，交易是否存在缺陷。。UAT核心系统测试团队，在数据迁入UAT环境后的测试中，如发现可能与数据移植有关的缺陷，将提交UAT核心系统测试团队统一审核，审核通过后，将对此类缺陷统一提交数据移植组，由数据移植组进行验证并统一回覆。自动化测试UAT测试团队将使用自动化测试工具ATF，分阶段把50%的测试用例转换成自动化脚本。预期在UAT第一期结束前实现首批测试用例的的自动化，覆盖约20%的交易。第一期自动化测试以辅助测试为主，用于数据准备及把基础交易的测试用例转换成自动化脚本。第二期将着重实现高覆盖率的自动化测试。回归测试被修复并通过SIT验证的缺陷随着补丁版本提交到UAT测试环境中，测试组在收到每个版本的更新清单后，立即安排已修复缺陷的回归测试计划。理论上，每个全量版本的发布都需要进行测试用例的全量回归。在测试后期，可以适当减少全量回归的范围，将某些在前几轮测试中都通过的，已确认稳定的功能点移出回归的测试范围。参数测试在核心测试过程中，参数测试渗透在各种测试用例的检查点中，对于SmartPM的参数配置功能以及参数在核心系统中的正确性都有一定程度的覆盖，发现的参数问题作为缺陷提交到Change中进行跟踪。参数功能作为各个业务子系统的附属功能一并计算在交易通过率之中。UAT结束条件如果UAT退出时间点已到，但以下UAT执行阶段的准出标准没有达到，需要提交PMO决定是否结束UAT测试执行。UAT阶段100%测试用例执行率（包括UAT测试执行阶段增补的测试用例，预计测试用例将大于16000）UAT阶段97%测试用例通过UAT阶段交易通过率为95%批量接口、数据接口的稳定性达到95%（稳定性的度量标准参见下文的报表准出条件）UAT阶段没有尚未修复的严重等级为A，B，的缺陷UAT阶段遗留C，D，E类缺陷占UAT发现缺陷5%以内，且不影响系统正常上线UAT尚未修复的缺陷通过业务团队及开发团队确认是否影响上线及确定修复计划在第一期自动化测试以辅助测试为主，用于数据准备及把基础交易的测试用例转换成自动化脚本自动化测试脚本可以正确运行测试执行结果经过业务团队评审确认，经过PMO确认报表的准出条件，其唯一标称值：报表稳定性，针对此标称值，做以下定义：以每张报表全量数据域数量为100%；以每张报表数值正确的数据域与全量数据域做比率计算，得出此张报表正确率（需业务部门签字确认）；当某一具体报表正确率达到100%，则视为该报表本轮测试正确；当某一报表连续五次跑批，出报表均为正确，则视为该报表稳定；所有报表均达到稳定后，则视为本测试工作的准出条件（所有报表需业务部门签字确认）；测试周期测试阶段计划周期实际周期时间偏差阶段目标实际结果目标偏差偏差原因备注UAT第一轮2011/1/10至2011/2/12

26天2011/1/10至2011/2/12

26天无全量执行14243条用例有效执行3188条用例88%未执行开发非全量提交，送测的功能点中可执行的用例只占用例总数的37%，同时极低的缺陷修复率导致阻碍测试进度的缺陷不能及时修复，因此测试执行率只有60%，两个情况结合起来，真正被有效执行的用例只有22%。第一轮还有预执行和大量的案例修改工作UAT第二轮2011/2/14至2011/3/18

23天2011/2/14至2011/3/31

46天延期13天1.执行除信贷和T+1的14528条用例2.按批次执行报表用例有效执行13852条用例5%未执行测试组在原计划时间点上完成了95%的执行覆盖率，但是由于缺陷修复率低，测试用例通过率达不到准出条件，所以延长了两周。延期两周后案例通过率才达到84%。信贷提交的功能太少，因此不在第二轮的主要执行目标内。T+1报表不分轮次，所以单独统计，进度42%UAT第三轮2011/4/1至2011/4/23

23天2011/4/1至2011/5/13

43天延期20天1.执行除个贷和T+1的12333条用例2.按批次执行报表用例有效执行11931条用例3%未执行测试组在原计划时间点上完成了97%的执行覆盖率，但是由于缺陷的影响，交易通过率只有72%，达不到准出条件。所以延长了两周半，到5月12日交易通过率达到90%左右，准入UAT第四轮。因为第三轮期间，个贷进行了比较大的需求变更，因此不在第三轮的主要执行目标内。T+1报表不分轮次单独统计,进度68%UAT第四轮2011/5/16至2011/6/2

18天2011/5/18至2011/6/2033天启动延期2天延期18天1.执行除T+1的10868条用例2.按批次执行报表用例有效执行10852条用例0.1%未执行测试组在原计划时间点上完成了96%的执行覆盖率，但是由于缺陷的影响，交易通过率只有83%，达不到准出条件。所以延长了两周半，到6月20日交易通过率达到96.7%左右，达到第四轮准出标准。为保证质量，增加用户验收阶段。T+1报表不分轮次单独统计，用户已确认64张报表，21张待确认，7张报表测试中。用户验收按部门进行，测试情况单独说明。用户部门验收2011/6/21至2011/6/30

10天2011/6/21至2011/6/30

10天无各业务部门共执行10942条用例有效执行10761条用例1.7%未执行验收部门在计划时间内基本完成用户验收工作，部分案例因批量、环境等因素受阻，未能完成测试。至6月30日，交易通过率达到97%，准入到在回归阶段。为了保证系统符合个部门提出的原始需求，增加了该阶段用户部门验收测试工作。测试资源人力资源测试轮次协调人数执行人数编制总人数工作日总计人日备注第一轮125971211491按照轮次结束时的编制统计，非实际出勤第二轮145872392808按照轮次结束时的编制统计，非实际出勤第三轮1456.570.5342397按照轮次结束时的编制统计，非实际出勤第四轮1457.571.5322288按照轮次结束时的编制统计，非实际出勤用户验收19110129101290按照轮次结束时的编制统计，非实际出勤合计7334141413610274用户验收阶段，含各部门的验收人员第二轮使用的人力资源最多，第一轮测试周期最短，人力资源最少。整个UAT共136个工作日，共用10274个人日。协调人数执行人数编制总人数平均每轮13.557.7571.25平均每轮测试组编制人数为72人，约每4个执行人员配备1个协调人员。测试组第一轮第二轮第三轮第四轮平均支付1413121212.75公共1076.56.57.5负债13.512.5111212.25中间业务15.515.5131314.25资产1111131312外币业务76666.25报表7998.33总和717270.571.5中间业务的人力资源最多，支付，负债，资产组其次，公共，国业，报表组的人员相对较少。环境资源测试环境UAT使用了两套环境，这两套环境的分工是：UAT1（增量、核心测试）

（570--核心；PCSERVER--国结、网银、个贷、信管…；小机--大前置）核心系统测试部分外围T+1报表测试外围系统测试（交易类、渠道类）外围系统测试（1104、数据大集中等--前期）历史数据中心测试--前期UAT2（增量交易报表类测试）

（570--核心；PCSERVER--国结、网银、个贷、信管…；小机--大前置）T+1报表测试电子国债、凭证式国债自动化测试脚本开发（第四轮迁移到UAT1）测试工具UAT使用以下工具进行测试过程跟踪和执行管理：QC：全称QualityCenter，是HP-MI公司的测试过程管理工具。测试组使用QC进行测试用例的维护与执行，测试用例执行率的数据都来自QC的统计。另外，外围的缺陷以及一些不涉及神州数码的缺陷都登录在QC中进行跟踪。CHANGE：全称TelelogicChange，是神州数码公司购买的缺陷管理工具。UAT测试过程中核心的缺陷都登录在CHANGE中。可以说整个UAT的大部分缺陷都记录在CHANGE中。本文中的各项缺陷统计也来自于CHANGE的数据。ATF和QTP：ATF全称AutoTestFrame，是文思自主研发的自动化测试平台。QTP全称QuickTestProfessional，是HP-MI公司的自动化测试工具。文思自动化团队使用ATF组合QTP的方案，实现自动化的集成运行环境，将自动化过程变得易实现，易维护，易分析。交易执行清单交易的执行者以及执行明细请参见：版本信息测试轮次版本号版本类型发布日期备注第一轮CDBankSymbols_UAT_BL01全量版本2011-1-10提交的功能点只覆盖测试范围的30%CDBankSymbols_UAT_BL01_Pach001～004补丁版本在第一轮不定期发布4个补丁版本第二轮CDBankSymbols_UAT_BL02全量版本2011-2-14提交的功能点覆盖测试范围约90%CDBankSymbols_UAT_BL01_Pach001～031补丁版本在第二轮基本每个工作日发布一个版本31个补丁版本第三轮CDBankSymbols_UAT_BL03全量版本2011-4-1个贷系统因为修改功能架构而没有送测CDBankSymbols_UAT_BL01_Pach001～032补丁版本在第三轮基本每个工作日发布一个版本32个补丁版本第四轮（含用户验收）CDBankSymbols_UAT_BL04全量版本2011-5-16因数据错误，数据在5月17日进行回退CDBankSymbols_UAT_BL04_Pach001～041补丁版本在第四轮基本每个工作日发布一个版本，用户验收阶段基本每两天发布一个版本41个补丁版本注：以上版本号包含内容：核心系统、数据平台等此次核心系统承建方所开发系统；中信、高伟达前置系统。其他外围系统版本按照日期作为版本号。

测试结果准出评估（本文以第四轮完成为节点，回归测试结果另见）以下统计数据来自版本CDBankSymbols_UAT_BL04_Patch035（截至到用户部门验收阶段前）统计项统计值度量指标准出值实际值是否满足准出备注用例总数10868测试覆盖率100%99.9%是少量案例因批量周期过长未覆盖执行覆盖数10852执行案例数10852案例通过率>97%99%是遗留案例计划在用户验证验证通过案例数10741交易总数886交易通过率>95%96.7%是除去无法在第四轮完成的9个交易，通过率为97.7%通过交易数857重要交易数480重要交易通过率100%96.5%否在用户验收阶段解决重要交易通过数463报表总数92报表稳定率>95%92.4%否报表稳定数*85以下统计数据来自版本CDBankSymbols_UAT_BL04_Patch041（截至到用户部门验收阶段）统计项统计值度量指标准出值实际值是否满足准出备注用例总数10942测试覆盖率100%98.3%执行覆盖数10761执行案例数10651案例通过率>97%99．5%通过案例数10602交易总数1321交易通过率>95%97%通过交易数1281重要交易数800重要交易通过率100%96.5%重要交易通过数737报表总数92报表稳定率>95%92%报表稳定数*85遗留致命缺陷数0是否遗留A级缺陷否遗留严重缺陷数18是否遗留B级缺陷否缺陷总数38是否遗留C,D,E级别缺陷小于总数的5%遗留一般，建议，轻微级别缺陷数200遗留缺陷是否通过评审是批量程序稳定（连续一个季度的批量不出现严重问题）截至到回归测试前：15个批次，出现7个问题（一个季度需要完成15个批次）*注：报表稳定的评估条件参见本文2.3章节。测试覆盖率明细注：报表测试不分轮次进行测试。未完全覆盖测试交易列表：（已在后期完成覆盖）小组交易备注公共机构扎帐单（RB929）送测时间晚，涉及交易多负债白金卡钻石卡当前状态查询批量周期较长，安排独立环境进行测试白金卡钻石卡历史状态查询批量周期较长，安排独立环境进行测试白金卡钻石卡收费统计批量周期较长，安排独立环境进行测试案例通过率明细交易通过率明细版本稳定性分析第三、四轮都未测试通过交易列表业务小组业务模块交易备注公共T+0报表库存凭证登记簿#8035（多次修复不成功）机构扎帐单（RB929）送测时间晚，涉及业务范围广柜员扎账单（CM025）送测时间晚，涉及业务范围广负债T+0报表白金卡钻石卡当前状态查询白金卡钻石卡历史状态查询白金卡钻石卡收费统计卡白金卡钻石卡收费资产信贷基准利率变更缺陷（907）需翻年批量，未验证完历史存量数据使用情况按照UAT组对历史存量数据的测试计划：要求项目提供了可用的历史存量数据（其中有部分数据受到历史存量数据的限制，无法使用）分别按照每次历史存量数据的导入进行历史存量数据的测试。其中经历了三次主要的数据提供过程。历史存量数据在UAT组总共经过了第三轮、第四轮、用户部门验收测试这三个周期的测试，结合数转组自身的测试特点，UAT组分别在不同阶段制定了不同的测试策略：根据测试用例，预估该案例是否可使用历史存量数据进行测试，并在历史存量数据中筛选符合条件的数据进行测试数据面比较广；优先筛选历史存量数据（区分业务维度），根据筛选出的历史存量数据，选择可用于该数据的所有测试用例，进行测试业务覆盖面广；根据测试用例，筛选、指定历史存量数据，并执行测试工作加深测试深度；原计划UAT组交易特性，筛选出约7000条历史存量数据相关的案例对历史存量数据进行测试覆盖，按照实际系统可提供历史存量数据，共覆盖约5441个历史存量数据相关的用例。模块组总交易数量使用历史存量数据的交易数交易覆盖率相关案例数量数据类缺陷数量资产221672.70%17419负债1529059.21%93336支付25814455.81%144111公共1519764.23%97722中间业务28119067.61%191624遗留问题解决情况：业务小组交易名称备注公共单证重打在部门验收期间，测试通过交易日志查询打印在部门验收期间，测试通过详细客户信息维护在部门验收期间，测试通过库存凭证登记簿缺陷号：#8035库存现金登记簿在部门验收期间，测试通过机构扎帐单（RB929）测试中，涉及多个交易，将统一提交缺陷柜员扎账单（CM025）缺陷号：#7822年终结转缺陷号：#8045支付汇票状态查询在部门验收期间，测试通过银行本票状态查询在部门验收期间，测试通过普通借记往账录入在部门验收期间，测试通过普通借记往账维护在部门验收期间，测试通过定期借记业务往账复核在部门验收期间，测试通过手工组包在部门验收期间，测试通过中间业务理财产品兑付在部门验收期间，测试通过社保子账户打印缺陷号：#7884（需重新导数据进行验证）金康联名卡开立(非记名卡单笔发卡)在部门验收期间，测试通过金康联名卡特殊交易（凭证挂失/解挂、补换卡发卡）在部门验收期间，测试通过华夏保险投保在部门验收期间，测试通过合众保险投保在部门验收期间，测试通过负债凭证挂失期满补发在部门验收期间，测试通过卡AIO账户明细查询(RB7YA)在部门验收期间，测试通过卡账户销户（一卡通销户）缺陷号：958（QC）卡折分离在部门验收期间，测试通过白金卡钻石卡当前状态查询在部门验收期间继续测试白金卡钻石卡历史状态查询在部门验收期间继续测试白金卡钻石卡收费统计缺陷号：#7638处理未收手续费在部门验收期间，测试通过账户批量手续费收取在部门验收期间，测试通过个贷利率变更在非结息日生效在部门验收期间，测试通过基准利率调整在部门验收期间，测试通过罚息和复利计算缺陷号：#7976信贷基准利率变更缺陷号：907（QC）展期在部门验收期间，测试通过缺陷总体情况缺陷分类第一轮第二轮第三轮第四轮合计审核未通过20444100645拒绝1285815735081790重复441136332252被修复缺陷数484228216158915272总数8603417225114317959缺陷率分析UAT测试四轮，平均每几个用例会发现一个缺陷：轮次执行案例数被修复缺陷数用例总数/被修复缺陷数第一轮31884846.59第二轮1385222826.07第三轮1193116157.39第四轮1085289112.18合计3982352727.55UAT测试四轮，平均每个交易会发现几个缺陷：轮次覆盖执行交易数被修复缺陷数被修复缺陷数/覆盖执行交易数第一轮1784842.72第二轮87422822.61第三轮86616151.86第四轮8868911.01合计280452721.88遗留缺陷严重级分布遗留缺陷业务分布EOD批处理ESB中间业务数据平台数据移植核心公共核心负债Totals一般缺陷521024620严重缺陷1010100618Total留缺陷状态分布审核不通过已修复已提交已验证Totals一般缺陷2131420严重缺陷2101518Totals4232938遗留问题需关注、可控未完成交易列表：交易模块解决方案预计完成完成情况白金钻石卡模块（4个交易）已经落实单独测试环境，对其发现缺陷的修复和验证工作，预计能够在用户部门验收阶段完成6/30日跑批并测试中（预计7/5完成）身份核查模块（1个交易）预计本周、下周安排实测环境6月25日完成单证重打（凭证管理）专人跟踪，用户验收阶段解决6/30日完成交易日志查询打印（审计管理）专人跟踪，用户验收阶段解决6/30日完成柜员扎账单（T+0报表）专人跟踪，用户验收阶段解决6/30日持续修复持续验证机构扎帐单（T+0报表）专人跟踪，用户验收阶段解决6/30日持续修复持续验证未通过交易跟踪表：业务小组业务模块交易名称技术人员测试人员预计时间是否完成公共额度管理机构现金尾箱限额维护许源继严仙萍6/30是凭证管理单证重打许源继黄新6/30是审计管理交易日志查询打印许源继黄新6/30是授权日志查询打印许源继黄新6/30是现金管理交易送测记录），许多交易流程不完整，以及测试用例的前置条件不足，导致仅有37%左右的用例可以执行（共5328条用例），即用例全量的三分之一的覆盖率左右。在这三分之一的可执行用例中，被有效执行的案例仅有约60%，执行率有40%的偏差（实际有效执行3188条用例）。造成这么大偏差的原因为环境问题，参数问题，跑批问题以及致命缺陷引起的40%的用例处于未完整执行（Notcomplete）、阻碍（Block）、未执行（NoRun）的状态。而在这些被有效执行的用例中，测试通过率为78%（通过2487个用例）。第一轮测试组共提交234个有效缺陷，其中只有2个缺陷在第一轮结束前被关闭。缺陷修复率约为0(项目组约定，优先修复SIT缺陷)。除了测试执行工作，第一轮为了增强测试人员对测试用例与新核心系统的熟悉度，提升缺陷有效性和执行效率，采取了预测试方案。对于提交可测的测试用例，预测试在正式执行之前进行，即3188个可以有效执行的用例都会执行两遍，先一遍预执行，再一次正式执行。对于未提交可测的用例，测试人员也会去尝试执行，目的是熟悉测试用例的检查点，以及新系统界面，为下一轮测试的执行效率打下基础。在第一轮结束前，基本完成了所有用例（14243个）的预执行。在第一轮的用例执行过程中，因为界面和功能点与FS描述有差异，所以伴随有大量的用例修改工作，每个业务组平均有1.5人在第一轮测试中全职修改用例。案例可执行率大部分功能点在UAT第一轮末期才随增量版本提交测试，因此在UAT第一轮的整个测试期间，大量的功能点未提交导致案例总体可执行率仅为37%，是用例全量的三分之一。图中是每个业务子系统的用例可执行率明细。案例执行率第一轮案例的总体执行率是60%，与预期结果100%有40%的偏差，主要是由功能提交不全，致命缺陷，环境因素，跑批问题导致。其中资产的执行率最低，只有16%，因为资产的功能点的验证时间跨度长，大多检查点在跑批后的数据中，第一轮跑批问题很多，所以资产受到跑批影响很大。用例执行趋势图下图是UAT第一轮整个测试周期的每日用例执行情况。图中的曲线上升平缓，说明测试进度缓慢。其中不通过，受阻，执行中这三条曲线呈持续的增长趋势，说明系统暴露的问题逐渐增多，问题解决的效率跟不上问题发生的频率。系统一直处于不稳定状态，离准出条件越来越远。案例通过率UAT第一轮案例总体通过率为78%，其中公共模块的案例通过率最高，达到90%，资产、中间业务、负债三个业务子系统的通过率都比较低，存在较多的缺陷。交易覆盖度&交易通过趋势交易通过率业务子系统交易通过率支付1%公共41.57%负债2%中间业务2.55%资产0外币业务38.98%总体36.85%UAT第一轮的交易通过率非常低，由于功能点提交不全以及致命问题的阻碍，能够执行完整的交易很少。缺陷状态分布已新建已提交已修复已拒绝已关闭总共29540887142860以上是第一轮结束时，CHANGE中的所有缺陷的状态分布。UAT第一轮在change中总共提交了860个缺陷，截止第一轮结束，有142个缺陷被关闭，缺陷关闭率为17%，有83%（718个缺陷）的缺陷遗留。在遗留缺陷中有408个已提交状态的缺陷需要开发组进行分配，占缺陷总比47%。有295个已新建状态的缺陷需要测试组组长审核，占缺陷总比34%。8个已修复状态的缺陷需要开发组在SIT环境中验证占缺陷总比1%。7个已拒绝状态的缺陷需要测试组回顾，占缺陷总比1%。缺陷有效性审核未通过204拒绝128重复44被修复缺陷数484缺陷总数860第一轮共提交860个缺陷，以上是UAT第一轮测试过程中提交的缺陷的有效性情况。在第一轮提交的缺陷中，有效缺陷比例为56%，47%无效缺陷中审核未通过24%，开发组拒绝15%，缺陷重复提交5%。缺陷有效率比较低的主要原因是在第一轮测试中，测试人员对各种测试工具以及新系统的使用生疏和需求理解的差异性导致。在484个有效缺陷中，234个缺陷是在第一轮测试周期内提交给开发组，有150个有效缺陷没有被业务测试组长及时审核，而遗留到了第二轮提交。缺陷修复率在UAT第一轮的已提交的234个有效缺陷中，只有2个缺陷被修复并通过UAT验证，所以缺陷修复率几乎为0。所有致命和严重的缺陷都没有得到解决。缺陷严重级分布缺陷严重级缺陷数量致命缺陷32严重缺陷133一般缺陷417微小缺陷57建议缺陷17总计656（该数据不包含审核不通过的缺陷）UAT第一轮中存在不少致命和严重缺陷，并且在第一轮结束时也没有任何修复。这对第一轮测试执行率造成很大影响。缺陷增长趋势UAT第一轮中，各个等级的缺陷持续增长，曲线持续上扬。致命和严重的缺陷不断被暴露出来。缺陷生命周期生命周期微小缺陷建议缺陷一般缺陷严重缺陷致命缺陷总计三天内306312280一周内202710544两周内10181121三周内21338246一个月个月内38122639721431三个月内33766088大于三个月104005第一轮的缺陷的生命周期（从新建到被关闭）大多在一个月到两个月左右，第一轮UAT的周期为26天，因此可知，第一轮提交的大部分缺陷都是在UAT第二轮的第一个月内被验证和关闭。导致缺陷生命周期这么长的主要原因是极低的缺陷修复效率和开发组分配缺陷不及时。重大问题列表编号问题类型问题描述发生时间影响范围解决方案1版本问题开发组无法按原有计划送测交易。导致大量测试用例无法有效执行2011-1-8UAT第一轮测试覆盖率和执行率与预期产生很大偏差随着开发组发布增量版本送测交易，测试组不断地调整测试计划2环境问题Change未能定制好流程及添加UAT的用户，导致无法在Change中提交缺陷。后来又发生了无法修改缺陷2011-1-11UAT的缺陷无法跟踪开发组修改Change的配置方案3功能问题行名行号不能回显，却又是必输项，导致交易大量交易无法提交2011-1-11大量交易无法执行发布紧急版本修复4环境问题仿真器问题导致所有来帐交易都不能做2011-1-11导致支付组大量测试用例在当天都无法执行，影响6人日第二天傍晚解决5功能问题个贷管理系统利率档次与TELLER不符等问题，导致资产组案例无法执行2011-1-11个贷管理系统的问题导致3天工作量的延迟（约合15人日）该问题1月12日上午解决，但由于个贷管理系统本身存在缺陷，导致无法开立贷款，影响资产组无法做出正确有效的贷款数据，因资产业务的特殊性，这影响到资产的测试用例都无法执行（需要先开立贷款，再通过跑批后验证结果来核对功能处理是是否正确）6功能问题个贷“无法开立贷款”2011-1-13影响资产组无法做出正确有效的贷款数据，无法执行其所有业务流程案例，测试进度严重受阻，同时由于影响batchplan的执行，对中间业务组和公共组均有影响。1月18日中午发紧急版本，仍存在问题，紧急处理后，19：00正常，贷款流程可以跑通。1/17：SIT测试版本验证通过，已经同步，但目前还是不能测1/13：紧急召开会议，并决定：协调开发人员解决，于当天晚上11点发布版本到SIT环境，SIT组留人验证无误后，再于次日确认是否同步到UAT环境1/12:导致资产组全组的测试进度受影响，同时由于影响batchplan的执行，对中间业务组和公共组均有影响，UAT组需要确切的指导此问题的可解决时间，以调整计划、评估影响7环境问题<中间业务>公务卡还款交易依赖金财网系统(大前置)发起公务卡还款交易到核心，目前负责公务卡系统的公司方不给予支持，导致没有环境测试（中间业务组多数交易依赖外围系统，一是需要提供外围系统的挡板程序，二是增加外围系统的配合）2011-1-17与挡板相关的系统均有此风险领导层沟通，与公司方协商解决8功能问题<中间业务>代收费、合众保险、批量代扣三个模块下的交易在涉及与外围系统连接的步骤时（如提交、查询步骤）提示888883调用远程服务连接失败，导致交易无法进行，该问题在1月14日曾出现，是因为服务未启动。现经环境配置组启动服务后，问题仍存在，经排查，是由于核心系统发送报文延迟2011-1-17代收费、合众保险、批量代扣三个模块下的交易发紧急版本修复9环境问题UAT环境未部署数据平台，无T+1报表测试环境2011-1-19影响11张T+1报表；数据平台跑批后，个贷管理系统才能跑批，现测试组已经因贷款受阻而未能执行批量计划，对需要批量后验证的测试用例都有影响1月24日，19点完成个贷管理系统及数据平台的批量，可以继续执行案例10数据问题各组在使用尾箱、凭证遇到许多问题，导致尾箱、凭证无法正常使用，各组在测试过程中，经常需要用到凭证，影响测试进度2011-2-91、尾箱无法交易正常交接，导致柜员无尾箱可用；2、柜员无法正式签退，机构无法正常关门，跑批时，通过改库强制关门才能执行批量；3、本票无法签发，后端交易无法操作。安排专人跟踪这些问题11环境问题电子国债能够测试开销户交易，其它交易因无国债系统数据，需银联通公司配合准备数据2011-2-11电子国债多数交易无法测试，影响260个案例李海协调银联通公司来人协助测试12功能问题贷款缺陷（贷款自动回收失败，缺陷号HU_BOCD#794），和开发组协调后发现，部分业务逻辑需要修改；为避免前期贷款流程类案例的预埋数据失效，需要对此缺陷进行紧急修复，再进行继续执行批量。2011-2-12资产组全组无法验证案例，批量暂停2月12日，两次发布紧急版本到SIT，验证未通过UAT第二轮概要情况测试组UAT测试第二轮案例总体执行情况（2011/2/14至2011/3/31）计划执行已执行通过未通过执行中受阻执行案例执行通过率案例执行覆盖率支付32703137289717664392%96%公共211620411760235463186%96%负债402437412815779147675%93%中间业务302528982603273228090%96%资产-个贷1076103780922083778%96%外币业务101799872525419073%98%总和145281385211609193730615784%95%资产-信贷800202122216806%25%报表11694884372427090%42%第二轮测试的目标是全业务覆盖测试。其中约90%的功能点在2月17日的全量版本中提交测试（送测情况参见本文5.1章节HYPERLINK交易送测记录），剩余的未送测交易在第二轮期间以增量版本方式逐渐提交测试（但是实际上，在整个第二轮的测试周期中，只有17个支付交易随增量版本送测，只有支付在第二轮中完成了100%的送测，其他业务子系统都是在第三轮才完成全量送测。），预期是覆盖除T+1报表和信贷的所有业务功能，共14528个测试用例。第二轮的信贷功能点提交得很少，因此信贷没有纳入第二轮的进度统计范围。T+1报表的测试不分轮次，按跑批批次跨整个UAT的测试过程，在UAT第二轮报表测试覆盖率达到42%。在第二轮的计划准出时间点3月18日，测试组已经完成了95%的用例执行覆盖率。但是由于开发组的缺陷修复率低（66%，参见5.3.6章节HYPERLINK缺陷修复率）导致用例通过率（72%，该数据来自3月18日测试日报）达不到准出条件，所以第二轮延期两周来增加缺陷修复率，最后在3月底用例通过率达到84%。在这延期的两周内，测试组除了回归开发组修复的缺陷，同时还筛选了10388个涉及重要交易的用例进行额外的回归，最后完成了7473个用例的执行。个贷在第二轮测试中发现了功能架构的致命问题，经过评审后决定立即修改个贷的功能架构，所以在第三轮中个贷处于开发状态，没有提交测试。案例执行率第二轮案例的总体执行率是95%，5%的执行偏差在可接受范围内，原因是由于缺陷引起的测试用例执行受阻。信贷在第二轮延期阶段送测了部分交易，由于时间不够，所以测试组执行了25％的交易。T+1报表在第二轮延期结束时，案例执行率为42%。用例执行趋势图延期开始延期开始图中整个过程的日均案例执行数为1034。测试组的每日执行量与计划基本一致。工作量分析执行分类用例数量说明目标用例量14528第二轮计划执行用例总数缺陷回归量（估算）4123第二轮的缺陷总数（4277）-上一轮已关闭的缺陷数（154）延期阶段额外回归量7473延期阶段测试组额外筛选的重要用例回归冗余工作量（估算）14205由缺陷的反复，需求理解的差异，以及严重和致命缺陷的阻碍导致的测试用例的非计划性，非有效的反复执行第二轮执行总量40329第二轮测试用例执行总量在第二轮，冗余工作量占据了约三分之一，各种阻碍测试的异常原因耗损了测试组三分之一的工作量。人均执行案例数明细延期开始延期开始图中，除了报表的其他六个业务组的人均执行案例数都在20个/日左右，符合预期结果。其中资产组在3月5日调休，负债组在3月19日调休，所以图中在这两天各有一个低谷。报表组的人均执行案例数在6个/日左右，符合预期。注：图中数据从2月23日开始统计。案例通过率UAT第二轮在延期前的案例总体通过率为72%，不符合准出条件。经过两周的延期后，案例总体通过率达到84%，基本达到准出条件（85%）。注：延期前的通过率数据来自2011年3月18日的测试日报交易通过率业务子系统交易通过率延期前延期后支付35%84%公共42%70%负债27%64%中间业务42%73%资产0%50%外币业务37%42%总体36%71%报表0%16%在第二轮延期期间开发组的缺陷修复率有很大的提升，延期两周后交易总体通过率有了比较大的提升，从36%到71%，虽然交易通过率仍然没有达到准出条件（95%），但是为了不影响测试全局进度，综合考虑后UAT第二轮准出。缺陷状态分布已新建已提交已分配已修复已拒绝已挂起已关闭SIT已验证总计12538333320273959424277以上时UAT第二轮延期结束时，CHANGE中所有缺陷的的状态分布情况。UAT第二轮延期结束时，92%的缺陷已关闭。有8%（318个）的缺陷遗留到UAT第三轮。缺陷有效性审核未通过441拒绝581重复113被修复缺陷数2282总数3417第二轮测试组共提交3417个缺陷，以上是缺陷的有效性分布情况。UAT第二轮的缺陷有效率是67%，比第一轮有了一些提升，但是仍有不少审核未通过和拒绝的缺陷。审核未通过的缺陷是测试人员业务操作习惯与新系统的差异和测试工具使用不够规范等问题导致，被拒绝的缺陷主要是测试人员对业务需求的理解与系统功能实现上的差异导致，这些被拒绝的缺陷中包含了很多业务需求上的让步，很多系统实现与需求描述中不相符的缺陷被拒绝掉了。缺陷修复率第二轮延期前的需要修改的缺陷总数为2148个（上一轮遗留的有效缺陷加上本轮提交的有效缺陷），被修复并通过UAT验证的有1412个（在本轮内修复并通过UAT验证的有效缺陷）。缺陷修复率为66%。第二轮延期后的需要修改的总数为2578，其中在第二轮被修复并通过UAT验证的有2336个。缺陷修复率为91%。这是延期两周后的修复率。缺陷严重级分布缺陷严重级缺陷数量致命缺陷105严重缺陷808一般缺陷2522微小缺陷163建议缺陷34总计3632（该数据不包含审核不通过的缺陷）UAT第二轮的致命缺陷和严重缺陷数量很多，有105个致命缺陷和808个严重缺陷。说明送测的系统质量情况很差，通过SIT测试的系统不应该存在那么多的致命和严重缺陷，SIT的测试质量存在问题。致命和严重的缺陷往往会阻碍多个测试用例的执行以及交易的通过，因此测试的进度也受到很大影响。缺陷增长趋势UAT第二轮中，各个等级的缺陷持续增长，曲线始终保持上扬趋势，说明系统功能一直都没有稳定下来。严重缺陷在第二轮新增了675个。致命缺陷在第二轮新增了73个。缺陷生命周期生命周期微小缺陷建议缺陷一般缺陷严重缺陷致命缺陷总计三天内31151515313713一周内17248216429694两周内24654717317767三周内30348112315652一个月内38745410321623两个月内451445314223677三个月内33100260132大于三个月2098019在第二轮结束时，CHANGE中共有4277个缺陷，这些缺陷的生命周期从三天到三个月均匀分布。其中大量的致命和严重缺陷生命周期超过一周，被这些缺陷阻碍执行的测试用例也会因此而无法完成有效执行，这是测试进度受阻的重要因素之一。缺陷生命周期过长的原因主要是在第二轮测试期间缺陷修复率太低，在第二轮的计划准出时间点（3月18日）的缺陷修复率只有66%，在第二轮的延期阶段开发才加速缺陷修复效率，大量的缺陷在该阶段被修复，所以缺陷的生命周期会普遍很长。重大问题列表编号重大问题概要（详情请参见附件）附件列表1在第二轮测试中资产组出现了多个重大功能问题，以及测试环境问题，测试资源不足和设备问题2在第二轮测试中，中间业务组遇到了信用卡，财税库银、金康卡测试问题，合众保险，代收费，维修资金的测试问题，主要为环境问题3在第二轮测试中支付组遇到了信管系统送测不及时，凭证打印问题，T+0报表测试问题，报表打印问题，大小额网银查询接口问题4在第二轮测试中国业组遇到了汇率问题，支付密码器问题，证实书问题，ABOQ报表数据仍达不到规范，国业提交的变更迟迟未实施，结售汇分录和计算方法问题，历史存量数据基本无法使用等等问题5在第二轮测试中公共组遇到了T+0菜单显示问题，机构拆未送测问题，T+0报表查询问题6在第二轮测试中负债组遇到了T+0报表问题，管理端--卡参数--交易参数管理问题，存款证明交易授权问题，存单转入转出一卡通一本通界面，定期存单开户凭证号问题，白名单维护问题，凭证碰库问题，缺陷反复等问题7在第二轮测试中报表组遇到测试资源不足，系统版本问题，行内机构策略问题，受到外围系统质量影响，核心系统质量问题，历史数据问题，缺陷审核问题，跑批错误影响，致命缺陷处理不及时问题，凭证入库问题，卡交易测试问题，网银系统有问题导致跑批不成功问题，本机上传文件到Teller出错问题，密码开关问题，外围系统跑批问题，会计分录查询问题，仿真机问题等等UAT第三轮概要情况测试组UAT测试第三轮案例总体执行情况（2011/4/1至2011/5/13）计划执行已执行通过未通过执行中受阻执行案例执行通过率案例执行覆盖率支付2704263825327729096%98%公共19071807168710416093%95%负债348534352787425223081%99%中间业务26272505239710081696%95%资产-信贷757697505861065872%92%外币业务853849762798090%100%总和1233311931106708713907489%97%资产-个贷63851911927373223%81%报表14409778608136088%68%由于第二轮测试中发现了个贷的致命功能架构问题，需要立即修改，所以第三轮个贷没有交易送测（在延期阶段发布的版本中送测了11个交易，但是这不在原先第三轮的执行计划内，并且延期阶段也不足以覆盖个贷的所有测试用例），因此个贷的测试数据不纳入第三轮的总体情况中。信贷在第三轮开始送测了19个交易，是信贷交易全量的82%，之后在第三轮延期时的版本中送测了4个交易，至此信贷才完成100%的送测。公共和中间业务在第三轮的末期随增量版本陆续送测了8个交易。其他业务子系统在第三轮开始时完成了全量送测。到第三轮的延期开始（5月1日），核心系统才完成100%的交易送测。（送测情况参见本文5.1章节HYPERLINK交易送测记录）第三轮的目标是覆盖除了个贷的12333个用例，以及按跑批计划执行T+1报表测试。在第三轮，撤销了用例库中