干了这么多年银行测试被问得最多的一个问题就是核心系统和网上银行到底怎么测这俩系统一个是银行账务的心脏一个是客户天天用的门面中间的链路牵扯到太多东西。很多刚入行的测试同学一上来就懵网银换个手机号、改个限额看着是前端小功能结果一测就牵扯到核心系统的客户信息、签约关系、账户状态好几层。这篇文章就把我从核心账务到网银渠道的测试思路、实操步骤、坑点教训一次说清楚照着往下走至少能让你的测试思路从“点按钮”升级成“通链路”。1. 先搞懂被测对象核心系统和网上银行到底是什么关系1.1 银行核心系统账务的最终裁决者核心系统Core Banking System说白了就是银行的账本所有存款、贷款、汇款、利息、内部账、科目记账最终都要落到这一层。它不像网银那样有花哨的页面更多是跑批、记账、维护账户状态和客户信息。你往网银上看到的那串余额数字并不是网银自己算的而是实时从核心系统查出来的。核心系统的测试有一个突出特点状态机极其复杂。一个账户有正常、冻结、挂失、销户、久悬等多种状态不同状态叠加不同业务类型组合起来就是个巨大的笛卡尔积。比如一个冻结账户能不能收工资挂失账户能不能做转账久悬账户能不能被扣年费这些规则全在核心系统的账务逻辑里网银只是把请求传过去。所以做核心系统测试首先要建立两个概念一是“记账方向”借方贷方、红字蓝字不能错二是“账户状态流”每一步业务操作都把账户从一种状态迁移到另一种状态迁移路径必须闭环。这两个概念搞不通后面测网银的账务联动一定会踩雷。1.2 网银是渠道核心是账务大脑网上银行属于渠道系统跟柜面、手机银行、ATM、第三方支付一样本质上是把客户的交易请求翻译成核心系统能识别的报文再展示核心系统返回的结果。很多测试新人有个误区以为网银就是个增删改查的web系统其实它的核心价值不是页面而是渠道适配和交易组装。一个典型的网银转账页面提交后网银要做的事包括组装交易报文、校验手续费规则、检查限额、做加密签名、调核心接口、等核心返回、再更新自己的交易状态表。这个过程中网银自己也会落一堆表比如交易流水表、预约交易表、收款人管理表。所以网银测试不只要测前端交互还要验证它“翻译报文”是否准确、落库是否一致、状态流转是否跟核心完全对得上。为什么强调这个因为网上银行和核心系统本质上是两套独立的系统由不同的开发团队维护中间走的是ESB或行内总线。测试最关键的就是“两边对了账才算真正通过”不能只看网银页面弹了个“交易成功”就完事。1.3 两者对接的链路长什么样我可以画个链路给你心里有个底用户在网银页面发起交易网银Server接收请求做格式转换后经ESB路由发送到核心系统核心记账并返回应答报文原路返回网银网银更新本地状态后再把结果推给前端。这中间有四个关键的测试观察点请求报文里关键字段是不是正确映射比如账号、金额、对手信息、渠道标志核心返回码是否正确翻译成用户能看懂的提示不能把内部错误码直接怼给客户超时、断网、连接异常时两侧的交易状态是不是最终一致交易流水号和核心记账流水号能不能够串联追溯这四个点只要都通了这条链路才算真正打通。后面所有测试设计本质都是围绕这四个观察点展开的。2. 测试环境搭建与数据准备一半的时间都耗在这2.1 测试环境的几套“江湖规矩”银行测试跟互联网公司很不一样环境极其金贵。大行一般有SIT环境、UAT环境、性能环境、演练环境多套并行每套环境里核心系统、网银、ESB都各有一份部署。测试前第一件事不是写用例而是问清楚当前这轮测试用哪套环境环境里的核心版本和网银版本是不是匹配的。我踩过一个特别蠢的坑在UAT环境测网银结果UAT的核心系统是上周的旧版本没有新增的账户类型导致所有新增业务的联调用例全部失败。后来排查半天发现不是代码问题是环境版本错位。所以正式开工前一定先做三件事确认版本、确认联调通道、确认测试基础数据是否齐全。版本确认尤其要看核心系统和网银的“接口契约版本”。银行内部一般有接口文档或Swagger平台两边接口字段变更必须保持同步。如果网银已经按新接口报文发送核心还是老版本解析最常见的现象就是某个字段被截断、丢失或者解析报错。这种问题在联调阶段特别多。2.2 造数方法论从核心和网银两侧同步准备测试数据是银行测试的重中之重因为各种账户状态不是页面点出来的是数据造出来的。核心系统的数据准备通常有两条路一是通过柜面或内部管理端去开真实业务数据二是直接连数据库插入或更新数据。直接操作数据库是银行测试同学必须掌握的技能。比如要造一个“部分冻结”的账户最快的方式是定位到核心账户表把冻结金额字段更新成一个介于0和余额之间的值再查一下账户状态标志位有没有正确变更。但要切记核心系统的表结构极其复杂客户信息表、账户表、签约表、余额表可能分属不同库造数时一定要多处一起更新否则就会出现“账户状态是冻结但签约关系还在生效”这种脏数据。给一个实操建议造数前先写一遍“数据造数清单”把要修改的表名、字段名、目标值、影响范围列清楚保存到团队共享文档里。这样一方面方便自查另一方面别人接手你的用例时也能快速复现。银行项目里很多测试脏数据问题的根源就是造数过程不透明全在自己脑子里。网银侧的数据准备相对简单但有个坑要注意网银的客户信息往往是缓存的核心改了客户手机号、地址等信息后网银自己的客户表不一定实时同步。所以造完核心数据后一定要去网银管理端或直接在网银库执行同步操作否则前端页面还是显示旧数据很容易造成“明明改了为什么没生效”的假象。2.3 日期、批次与时序的控制核心系统带了大量的批处理任务典型的就是日终跑批包括计提利息、结息、批量扣款、报表生成等。网银很多功能受核心批处理状态影响比如日切前后的交易怎么归属、批量代发的结果怎么回写。所以做网银和核心联调时日期和批次的配合是绕不开的。测试环境一般有“时间窗口”的概念比如SIT环境每天有固定的日切时间。测试人员要学会两个操作一是会查批次跑批的日志和状态表二是会手动触发或重置批次。很多银行的测试环境支持“模拟日切”通过调用内部管理接口指定一个虚拟业务日期不需要真的等墙上时钟到点。但模拟日切有个副作用容易产生日期错位的数据。比如虚拟日期已经切到6月1日但有的交易时间戳还是5月31日跑批逻辑就会把这些交易算到旧账期。这一块建议在用例设计时明确写入预期哪些交易发生在日切前哪些发生在日切后预期归属到哪个账期。数据错位了才能快速定位是谁的问题。3. 核心业务流测试实操从开户到转账的完整链路3.1 开户与客户信息同步开户是很多业务链条的起点也是网银和核心系统联调测试里非常典型的场景。网银开户通常由网银发起开户请求核心系统创建客户信息和账户信息随后回传成功状态网银侧再创建渠道账户和签约关系。测试开户用例重点关注这几个校验点核心创建成功的账户在网银账户列表是否正常可见账户类型、币种、账户状态字段是否从核心正确带出如果开户失败例如证件号重复、黑名单命中网银侧是提示“开户失败”还是显示“核心系统错误”开户成功的客户能否立刻在网银做签约、转账等后续操作还是需要等待某个标志位生效这里特别要提醒一个场景核心开户成功后网络超时导致网银没收到成功应答。这是分布式系统联调里最经典的“半成功”问题。实际工作中我验证过不下十次这个场景核心到底有没有把账户开出来网银能不能通过“查询账户状态”的接口去补偿还是说需要人工介入这类用例的价值远高于那些正常路径测试因为线上真实故障大概率都是这种节点异常。具体的测试方法是在ESB层模拟延迟或超时让核心成功处理但响应报文丢失然后去核心侧确认账户已建立再回到网银侧执行账户同步或查询操作看最终状态是否一致。如果网银逻辑里没有做补偿查询这个bug在被发现时已经算严重缺陷了。3.2 转账交易全链路同步接口与异步冲正转账是银行渠道测试里最核心也最复杂的交易。一个简单的行内转账路径是网银校验户名账号、限额、手续费组装报文发送核心核心做账务处理成功后返回网银展示结果。看起来不复杂但我在实际测试中发现真正容易出问题的是这几个点第一手续费的计算一致性。有的手续费是网银算的有的手续费是核心算的两边一旦口径不一致就会出现网银显示的手续费跟核心实际扣除的金额对不上。测试时务必核对借记账户、贷记账户、手续费科目三个维度的金额变化。第二收付款账户的校验时序。付款账户余额不足的时候到底什么时候报错有的实现是核心先查余额再记账有的是网银先做预校验。如果网银预校验通过了但核心又拒绝页面提示是否能正确对应。第三限额控制的位置。网银转账限额一般分日累计限额、单笔限额这些限额到底是在网银本地控制还是核心也管一份两边都要控制的情况下以哪边为准测试用例里要分别验证网银限额拦截、核心限额拦截两种情况因为线上故障往往是两边限额配置不一致导致的。再说异步冲正。网银发起交易核心处理超时网银发起查询核心返回“处理中”最终核心入了账但没有及时应答。这种情况下网银往往在等待一段时间后主动发起冲正但冲正请求到了核心时核心的原始交易可能已经成功了导致冲正失败形成“单边账”。这类异步场景的测试绝对不建议手工点点点一定要用接口测试工具模拟时序常见做法是用并发工具控制请求顺序分别模拟“原交易成功冲正失败”、“原交易失败冲正成功”、“原交易失败冲正失败”等组合最终通过核对核心账户余额和网银流水状态来判定是否符合预期。3.3 余额查询、流水查询的对账逻辑很多测试同学觉得余额查询简单查出来凑合对就行其实这里面藏着大量细节。余额查询往往走的是实时联机交易核心返回的是账户当前余额、可用余额、冻结金额等多个字段。网银页面上可能只展示可用余额但你要去核对的远不止这一个数。我的习惯是每一项余额类查询都去核心侧查一次账户余额表分别核对“账面余额”、“可用余额”、“冻结金额”。不要只看页面数字对不对而是要看字段映射是否准确。曾经遇到过一个比较隐蔽的bug核心返回的可用余额字段在报文里被网银错误地映射成了账面余额页面展示看起来很正常但客户一旦发起转账就会提示余额不足。流水查询也有类似风险。核心返回的历史流水是按交易日期排序的网银往往还要支持按时间范围、按借贷标志筛选。测试流水查询用例时要特别关注分页逻辑和起止时间边界比如查询“2024年1月1日到1月31日”的流水只返回了1月1日和1月31日两条边界数据时是否完整显示。这个不起眼的边界问题我在至少两个项目中都发现过缺陷。流水查询的对账另一层意思是网银自己维护的本地流水表和核心系统的记账流水两边是否一致。有些网银系统为了展示性能会把交易流水异步同步到自己的库。如果异步同步丢消息就会出现「客户在网银查不到某笔交易但核心已经记账」的问题。联调测试时一定要抽样多笔交易交叉核对两边的流水号、交易金额、交易时间。4. 常见的坑与排查方法真实排障实录4.1 环境漂移与数据污染环境漂移是银行测试里最让人抓狂的问题。你今天上午测好的网银转账用例下午重新跑一遍结果失败了不是代码变了而是核心环境被人重置过或者数据被另一组测试作业改掉了。多套测试环境共用一套核心库的情况在中小银行尤其常见。应对环境漂移没有银弹只能建立规范。我的团队里有个不成文的约定所有测试数据的主键标识统一加前缀比如流水号用“T_姓名缩写_日期_序号”这样可以快速判断这条数据是谁造的、哪一天造的出了问题直接联系对应的人确认是否动过。另外凡是牵涉到账户余额、冻结状态变更的用例跑之前先记录基准值跑完再核对一次避免被其他用例干扰。还有一种隐蔽的环境问题核心库和网银库的数据不同步。前面说过很多测试数据需要两侧同时更新但如果两边跑批或同步任务失败就会出现核心余额表和网银客户表长期不一致。排查这种问题最有效的办法是抽一条客户号出来分别在核心库和网银库查询客户信息和余额比对两侧字段。我在实际项目里用这个办法定位过至少五次“莫名其妙的测试失败”最后都追溯到同步任务中断。4.2 账务不一致类问题怎么定位交易完成后核心余额跟网银展示余额对不上是典型的联调问题。排查思路我一般是自上而下分四步走第一步确认交易流水在网银侧和核心侧都存在。如果核心没有问题大概率在报文传输或ESB路由如果网银没有问题在异步通知或本地落库。第二步比对两侧的交易金额、借贷方向、账户。这个不比对字段永远发现不了问题。我遇到过交易成功但金额被缩小100倍的案例原因就是网银报文里金额字段的单位没转换把“分”当成“元”传给了核心。第三步核对账户余额变动。拉出账户在核心的总账流水看交易前后余额是否连续有没有其他跑批任务在同一时间点扣过钱。第四步检查冲正和补偿逻辑。如果是异步冲正类交易还要去查冲正任务的执行状态表确认冲正请求到底发成功了没有。这套排查流程看起来简单但在实际工作中能节省大量时间。很多人一遇到账务不一致就跑去问开发但开发也要从日志和数据库里找证据。我们测试自己先把数据对比做扎实往往比开发更快给出定位方向。4.3 交易报错码的翻译问题核心系统返回的错误码往往是一串数字比如“5103”、“2081”这些错误码的含义只有核心开发清楚。网银拿到错误码后需要通过错误码映射表转换成用户能看懂的文案比如“账户状态异常请联系柜台”。联调测试里常见的问题是错误码映射表不完整或映射错误导致用户看到提示跟实际原因完全对不上。比如核心返回“账户已销户”网银映射成了“系统繁忙”这种问题虽然不影响资金安全但对用户体验影响极大在银行项目里一般定级为重要缺陷。测试这块没有太多技巧就是把核心侧接口文档里所有的错误码清单拉出来逐个在网银侧触发并核对提示文案。实际操作中有的错误码触发条件很隐蔽比如“账户反洗钱冻结”、“司法冻结”这些不太好造数但也要想办法通过后台管理工具模拟。我的经验是至少要把高频的、资金类的错误码全覆盖低频的可以抽样。5. 性能、安全与回归测试银行测试不能只做功能5.1 联机交易性能怎么测网银系统的性能测试不能只看网银自身服务器的响应时间要拉通整条链路看。核心系统的处理能力、ESB的转发效率、数据库的查询耗时每一个环节都可能成为瓶颈。一个真实的排查案例网银转账平时耗时300毫秒压力测试到100并发时耗时飙到5秒一开始以为是网银应用问题后来定位才发现核心侧某一类账户查询走了全表扫描。做联调性能测试时建议至少采集三个指标单笔交易全链路耗时、核心系统TPS、网银应用服务器的CPU和内存占用。测试过程中要同时监控核心系统的日志观察有没有慢SQL、锁等待这类问题。很多性能问题在单个系统独立压测时发现不了必须在链路压测下才会暴露。另外特别提醒性能测试时段要避开日终跑批。因为在跑批过程中核心系统的资源被大量占用这会影响性能基线的准确性。如果确有需要可以专门设计一批“跑批联机并发”的场景但那属于专项业务连续性测试不能跟普通性能测试混在一起。5.2 资金安全与权限边界测试银行测试里最不能出错的就是资金安全。测试同学除了功能验证一定要建立“资金守恒”的思维。每一笔交易测完都要在核心侧核对借贷金额是否平衡手续费、利息、税费有没有漏记、错记。我习惯在每轮测试结束后导出一份所有交易流水的汇总表按科目做一次借贷平衡校验不平就说明这轮测试里一定有隐藏bug。权限边界也是网银测试的重头戏。典型的场景包括A客户的网银账号能不能查到B客户的账户信息、修改手机号是否经过二次验证、转账是否校验短信验证码、管理员操作是否记录了操作日志。这些边界不光是测试用例更是合规审计的要求。测试权限类用例核心思路是“跨客户、跨角色、越权限”三个维度的组合。比如普通客户去调用管理端接口、柜员角色去执行需要主管授权的操作、已注销客户尝试登录网银这一类异常场景才是权限测试的价值所在。黑盒测试时可能看不到代码权限校验逻辑但通过篡改报文中的用户标识、角色字段往往能快速发现接口层权限缺失。5.3 回归测试策略改一处牵全身银行系统的回归测试范围控制很讲究。核心系统与网银联动场景下一个网银的小改动影响的可能不只是网银而是所有渠道。我的回归策略一般是分级冒烟回归、重点回归、全量回归。冒烟回归只跑主链路登录、余额查询、转账、流水查询。重点回归覆盖改动点相关联的业务比如改的是转账限额校验那就要回归限额边界、超额拦截、限额重置、限额查询等全部相关用例。全量回归则尽量在版本上线前跑一次核心系统与网银的全量联调用例哪怕只能抽样执行也比不跑强。回归测试最怕的是环境没准备好、数据被污染。建议每轮回归前团队先花半小时执行一遍“环境健康检查用例集”包括核心连通性、ESB通道、网银登录、基础数据完整性。通过之后再开始正式回归能节省大量无效执行时间。关于自动化回归我多说一句。银行项目的UI自动化成本高、稳定性差建议不要一上来就搞大而全的UI自动化。先把接口层自动化做起来核心系统和网银的接口用例用脚本串起来每次版本发布前自动跑一遍联通性。这样投入产出比最高也最贴近联调测试的实际需求。6. 给测试新手的一点实操建议这里分享几个我这几年的习惯不一定多高级但确实帮我少踩了很多坑。第一每天都写“测试日志”不用很长记录当天测了什么功能、用了什么数据、发现了什么问题、结果是什么。银行项目周期长你一周前造的数据可能这周就要用没有日志就只能重新造效率差很多。第二遇到账务类问题先自己核对数据再找开发。找开发的时候直接把两侧的数据库查询结果、日志截图摆出来。开发看到的是“明确的差异点”而不是“帮我看看怎么回事”。这既能让问题快速解决也让测试的专业度在团队里立得住。第三重要用例测完以后不要急着清数据等过两天回归时再复跑一次。有些问题不是即时暴露的尤其是批处理影响类问题可能需要一个跑批周期之后才显现。让数据多存活几天相当于给你的测试结果多了一层验证。第四善用线上问题复盘。每次生产环境出故障不要只等着开发给结论。自己去看日志、去查数据想一想如果是自己来测这套用例能不能提前发现这个隐患。这是快速积累银行测试经验最直接的方式。