金证股份的软件测试笔试面试题这几年一直是求职者们讨论比较多的话题。尤其是券商IT类的金融科技公司测试岗位考察的内容和普通互联网不太一样网上流传的题库版本很杂很多人对着刷了一堆题结果笔试照样挂面试被问两句就露馅了。原因很简单没搞懂这家公司要的测试工程师本质上是在测什么东西。这篇文章我会结合我实际带测试团队、也参与过社招校招面试的经历把金证这类金融科技公司软件测试岗位的笔试题型、面试考察点、答题思路完整拆一遍。文章不是让你背答案而是告诉你每一类题背后到底在考察什么以及怎么答才能踩到面试官的点上。1. 面试金证前先把这家公司的测试岗位看明白很多人的错误在于一上来就刷题。先想清楚一个问题金证股份是干什么的它的测试岗位到底在测什么系统这决定了你复习的方向。1.1 金证股份的业务底色金融IT不是普通软件公司金证股份根子在金融IT服务服务的客户以证券公司、基金公司为主也覆盖银行和泛金融机构。核心产品包括证券交易系统、资产管理系统、量化交易平台、登记清算系统这类对实时性、准确性和资金安全要求极高的系统。这对测试岗位意味着什么呢。普通APP测试一个按钮点进去页面卡了提个Bug开发修掉大家下班。金融交易系统里一笔委托报单进来经过合规校验、资金校验、持仓校验最后落到交易所任何一个环节算错一分钱或者并发高的时候丢了一笔委托这都不是体验问题而是生产事故是要赔钱、被监管问责的。所以金证的测试工程师日常接触的是这种高并发、强一致的分布式交易链路测的是撮合引擎、清结算服务、行情推送这些模块。笔试面试里出现的SQL题、接口题、场景设计题全部围绕这类业务展开。你按普通互联网项目的经验去答方向就偏了。1.2 券商IT测试和普通业务系统测试的本质差别一句常被老测试挂在嘴边的话普通软件测试是保证功能符合预期金融系统测试是保证一分钱都不许错一笔单都不许丢。维度普通业务系统券商IT系统核心关注点功能完整、用户体验数据准确性、资金安全、实时性数据特点数据错了可以改数据错了要追责、要走冲正流程并发要求秒杀场景偶尔高并发交易日全天高并发峰值集中在开盘时段监管要求一般无需要满足合规留痕、审计追溯订单处理丢了可以重试丢单会导致客户损失必须有对账机制这个底层差异直接决定了笔试题里为什么反复出现如果客户买入100股实际成交了50股剩余资金怎么算如何验证清算金额正确这类问题。他们招的不是只会点点点的执行者而是能理解业务链路、能从数据层面验证正确性的测试工程师。1.3 投递前如何快速摸底岗位侧重点金证的测试岗位也分多条线功能测试、自动化测试、性能测试、接口测试不同岗位笔试面试的侧重点很不一样。投递前花十分钟去几个地方摸底拉勾、BOSS直聘上搜金证股份 测试工程师看最近两个月的岗位JD里面的关键词就是复习重点。看岗位是偏业务测试还是偏技术测试。偏业务的笔试题里用例设计、流程题多偏技术的自动化脚本、接口测试、性能分析题多。如果岗位描述里写了熟悉证券业务者优先那笔试题里大概率有金融业务的基础概念题比如股票交易规则、交易时间段、账户体系。见过太多人简历投过去笔试挂了还在奇怪为什么自己准备了一堆Selenium题目结果考的是数据库和业务设计。原因就是你连岗位具体要什么人都没搞清楚。2. 笔试环节的题型分布与答题策略金证笔试整体风格偏务实不搞花架子题量大、时间紧。通常包含四类测试基础理论题、SQL题、用例设计题、逻辑题。下面逐个拆。2.1 测试基础理论题的常见问法理论题考得很细集中在测试流程、测试分类、用例设计方法、缺陷管理这些方向。常见题目有黑盒测试和白盒测试的区别各自适合什么阶段。什么是等价类划分法举例说明。什么是边界值分析法为什么它容易发现缺陷。什么是V模型和W模型区别在哪。一条Bug记录应该包含哪些必要字段。如何理解测试覆盖率它是否能衡量测试质量。这类题你光背概念不够没答出为什么用它大概率往下扣分。我建议复习的时候不死背定义而是每个方法都准备一个具体例子。比如等价类划分不要说把输入域划分成有效和无效等价类就结束而是说拿登录功能的用户名输入框举例有效等价类是可以正常登录的合法用户名无效等价类是空值、超长字符串、包含特殊字符的用户名。设计用例时每个等价类至少覆盖一次这样既保证覆盖度又控制用例数量。这种答法说明你真的理解这个方法而不是背了书上的话。另一个高频考点是V模型的测试流程。V模型强调开发和测试的对等关系每个开发阶段都有对应的测试阶段。答题时顺便点一句该模型的问题在于测试介入偏晚实际项目中会结合敏捷模式前置测试能看出你对工程实践有思考。2.2 SQL题目必考的联表查询与统计题金证的SQL题比重非常高原因前面说了金融系统测试中大量场景需要直接查数据库验证数据。笔试题通常会给两张表让你写查询。我记得有一道很典型的题表结构 orders(id, user_id, stock_code, order_type, price, quantity, status, create_time) users(id, user_name, mobile) 需求 1. 查询所有已成交订单的用户姓名和股票代码 2. 统计每个用户的订单数量按订单数倒序排列 3. 查询今天成交金额最高的前5笔订单 4. 找出从未下过单的用户对应的SQL写法先自己动手写一遍再往下看。第一题最简单两表联查SELECT u.user_name, o.stock_code FROM orders o JOIN users u ON o.user_id u.id WHERE o.status 成交;第二题分组统计加排序SELECT u.user_name, COUNT(*) AS order_cnt FROM orders o JOIN users u ON o.user_id u.id GROUP BY u.user_name ORDER BY order_cnt DESC;第三题取最高5笔需要联查股票代码和用户名称按成交金额倒序最后加LIMIT 5SELECT u.user_name, o.stock_code, o.quantity * o.price AS trade_amount FROM orders o JOIN users u ON o.user_id u.id WHERE o.status 成交 ORDER BY trade_amount DESC LIMIT 5;第四题用NOT EXISTS或者LEFT JOIN再过滤空值都可以SELECT u.user_name FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id u.id);这类题丢分点集中在这几个地方忘了考虑状态字段、分组字段和查询字段不一致、关联条件写错。笔试时间紧张时看题先圈出筛选条件和聚合函数再动笔。补充一点金证笔试有时候会让写删除重复数据只保留一条这类SQL属于考察窗口函数或GROUP BY的变体复习时稍微花时间看一眼ROW_NUMBER()的用法性价比很高。2.3 用例设计题从一个登录功能考察全面性用例设计题几乎是所有测试笔试的压轴题。题目形式通常是一道请针对XX功能设计测试用例这个XX可能是登录、转账、下单、买入股票、注册等等。千万别只盯着输入正确的用户名密码能登录这种Happy Path。面试官想通过这道题看两件事第一你有没有系统的用例设计方法论第二你考虑问题是否全面能不能覆盖异常场景和边界场景。我以股票买入委托功能为例拆一下标准答题思路第一步确定输入域。买入委托通常需要输入用户ID、资金账号、股东账号、股票代码、委托价格、委托数量。每个字段都有边界。股票数量上A股一手是100股买入数量必须是100的整数倍科创板最低200股但可以按1股递增这一类业务规则就是边界值分析法的天然素材。第二步按场景设计用例正常场景正常资金买入100股验证持仓和资金变动正确。资金不足场景账户余额只够买100股但用户输入200股的需求系统应该拦截并给出明确提示。买入数量非100倍数的场景输入150股系统是否提示委托数量应为100股的整数倍。买入无权限股票如买入ST股票但未签署风险揭示书。非交易时段委托系统是否支持预埋单还是直接拒绝。股票停牌场景委托提交后是否提示该股票停牌。价格超涨跌幅限制场景买入价超过涨停价系统直接拒单。第三步考虑数据一致性和幂等性快速连续点击两次提交按钮会不会产生两笔重复委托。这个场景真实发生过前端没做防重测试一定要覆盖。你按这个层次去设计用例从功能到业务规则到异常再到数据一致性面试官一眼就能看出你的水平。只写能正常买入、不能买入、余额不足这三条的大概率挂在笔试。2.4 逻辑题与智力题被低估的10分钟金证笔试里逻辑题一般放在最后几道小题看似是智力题实际上考察的是你的逻辑思维和快速反应。比如经典的三个人三天喝三桶水九个人九天喝几桶水或者烧绳子计时这类题。还有一类和工程实际结合的逻辑题一个接口每天调用量很大白天成功率是99.9%为什么到了晚间反而出现超时增多的情况这道题没有标准答案考察你的分析思路。可以这样答先看监控确认超时时段是否集中再排查是不是夜间批量任务和大数据同步任务占了数据库连接池或者看依赖的第三方服务是否有夜间维护窗口。答这类题的关键是展现你有排查思路而不是死等一个完美答案。时间分配上逻辑题不要恋战一道题卡了超过五分钟就先跳过去把前面能拿的分先拿到。3. 面试高频技术问题怎么答才不扣分笔试过了之后是面试一般有两到三轮技术面。这一环节里面试官不再满足于你知道某个知识点而是通过连续追问判断你实际做没做过。3.1 测试流程类的提问V模型不再是标准答案介绍一下你们项目里的测试流程是必问题但也是很多人答得最没区分度的问题。如果你只说需求评审、测试计划、用例设计、用例执行、回归测试、线上验证这条流水线面试官只能判断你干过活判断不了你的思考深度。加分回答方式是结合流程说明你为什么要这样做。比如我们团队用的是敏捷迭代两周一个迭代。我的工作从需求评审就介入了不是等开发做完才测。因为提前了解需求我可以在PRD阶段就抛出一些边界场景问题帮开发避免返工。用例评审和开发对需求理解达成一致后开发提测时我优先验证主流程再安排回归。上线前我们有一个准入准出标准比如核心用例通过率必须100%、遗留Bug不超过两个P2达不到就不允许发布。这段话里包含了敏捷模式、测试左移、准入准出标准三个加分点全是真实团队会做的事。如果被问到V模型和W模型别再机械背定义。可以直接说V模型和W模型本质是强调开发与测试的对应关系但现代项目里测试已经前置单纯套V模型会导致前期缺陷发现太晚。我们实际用的是基于敏捷迭代的测试流程需求分析阶段测试就介入代码评审和单元测试质量也会纳入测试关注范围。这种回答等于把经典题目和现代实践做了结合面试官挑不出毛病。3.2 用例设计方法的追问从等价类到场景法面试官通常会问你平时用什么方法设计用例这时候要展开讲不要只报方法名。有一个通用的答题框架按测试对象来划分功能测试场景用等价类和边界值覆盖输入域用场景法覆盖用户完整操作流程。接口测试场景用参数组合覆盖接口入参的正常、异常、边界三类情况。业务规则复杂场景用判定表梳理条件组合和对应结果。操作流程类场景用正交试验或场景法减少组合数量避免用例冗余。拿转账功能举例子。等价类划分正常转账金额、超出当日限额金额、小于0.01元的金额、小数点超过两位的金额。边界值单笔限额10000元那么9999.99、10000、10000.01这三个值都要测。判定表余额充足且收款人正常、余额充足但收款人异常、余额不足且收款人正常、余额不足且收款人异常这四种组合都要覆盖。能按这个思路答面试官听到的就是这个人不是照着模板写用例而是真正理解每个方法适合解决什么问题。3.3 Linux、数据库、网络相关的考察点技术面里Linux命令、数据库、网络基础是三个常考的硬技能板块尤其在测试岗位因为测试环境维护和线上问题定位都离不开这三块。Linux常见考察方式有# 查看某个服务进程是否在运行 ps -ef | grep java # 实时查看日志文件的最新内容定位接口报错 tail -f /logs/app.log # 从日志文件里筛选出ERROR级别的日志并按出现次数排序统计 grep ERROR app.log | sort | uniq -c | sort -nr # 查看某个端口是否被占用 netstat -tlnp | grep 8080 # 查找上一天修改过的所有日志文件 find /logs -name *.log -mtime -1特别提醒tail和grep是出现频率最高的两个命令。无路可走时就是这两个命令在日志里定位线索。数据库考察不只有笔试里的SQL还有实践类提问比如线上发现一条数据异常你怎么排查。回答思路是先确认异常数据的影响范围再查看这条数据的操作日志或审计日志锁定是哪个接口什么时间写入的再联合开发人员一起看代码逻辑定位根因。网络基础问得多的有HTTP和HTTPS的区别握手过程大致是怎样的。GET和POST的区别什么场景用什么。一个请求从客户端发出到服务端返回经历了哪些环节。TCP三次握手是为了解决什么问题。这类题目看上去基础但容易暴露出只会用不会原理的问题。建议复习时多问自己一句为什么比如TCP握手为什么非得三次这个问题的本质是确认双方的收发能力正常。3.4 自动化测试与工具链的问题金证的测试团队自动化程度不低尤其是交易系统回归测试手工回归到崩溃必须靠自动化。所以自动化相关的问题基本必问。面试官第一个问题通常是你做过哪些自动化。有人上来就说Selenium做Web自动化、Appium做App自动化这等于什么都没说。我的建议是哪怕你只做过一点点接口自动化也要系统讲出来接口自动化在金证的场景下含金量比单纯UI自动化高。一段推荐的回答结构我在上一个项目里负责接口自动化框架的搭建和维护。技术栈是Python加Pytest加Requests数据驱动的方式管理用例。测试数据存在YAML文件里统一从配置文件读取环境信息。因为我们接口数量比较多我设计了基于模块的用例分层公共方法比如登录鉴权、请求封装、断言封装都抽成独立的模块用例只关注业务逻辑。持续集成上接的Jenkins每天晚上自动跑一遍全量回归第二天早上出测试报告跑挂的用例自动发邮件通知到对应负责人。这个回答里包含了框架选型、数据驱动、分层设计、持续集成、自动通知五个关键点哪怕这个回答是模拟的比只说Selenium几个字强出一大截。被问为什么要做接口自动化而不是UI自动化时强调两个逻辑第一接口回归成本低、执行速度快适合高频回归场景。第二券商系统业务逻辑的验证集中在后端接口层面UI自动化只能验证页面展示接口自动化才能直接验证业务处理结果。工具方面Postman、JMeter、Pytest、Selenium、Appium这几个起码得有一个能讲出实际使用细节。比如用JMeter做过什么压测、设置了多少并发、重点关注哪些指标、怎么分析结果。没有凌晨压测调优经历的人讲出来的东西一听就是背的。4. 金融业务测试的独特考点如果你面的就是金证的测试岗业务能力是一道硬门槛。金融行业软件测试和通用软件测试最大的区别就在于不懂业务连测试用例都写不出来。笔试面试里关于证券业务的问题要特别准备。4.1 交易系统测试要关注哪些核心指标券商交易系统核心指标离不开快、准、稳这三个字。落到测试上对应三类测试性能测试、功能测试、稳定性测试。快交易链路时延必须达标。股票交易是强实时场景用户在客户端下单订单要经过中间件、交易网关、报盘机最后到达交易所主机这个链路的耗时直接影响用户体验和交易质量。性能测试中要关注的核心指标包括TPS每秒事务数、平均响应时延、99分位时延、服务器CPU和内存占用。准业务处理不能出错。委托校验、资金计算、持仓更新、订单状态流转每一步的结果都必须精确无误。功能测试重点覆盖这些业务规则。稳系统在连续高负载下不能崩溃故障后要能快速恢复。这就要做稳定性测试一般持续跑7乘24小时或至少一个完整交易日的加压场景观察是否有内存泄漏、连接池耗尽等问题。面试中如果说我们项目里压测的时候关注TPS和响应时间是不够的。直接给出一个例子比如我们模拟了开盘半小时的峰值流量3000并发用户同时报单要求系统TPS不低于500099分位时延小于500毫秒服务器CPU不高于70%持续压测30分钟无错误订单这个回答的颗粒度完全不同。4.2 资金清算与准确性验证的思路资金清算是券商IT测试里最容易出题的部分。因为社会普遍理解的买股票就是下单成交但实际后端流程复杂得多客户买入股票后资金账户被冻结成交后资金扣减持仓增加卖出股票后持仓冻结成交后持仓扣减资金增加。这还只发生在交易日晚上还要做清算结算公司下发清算数据资金和股份才能最终划拨到位。笔试题或面试官极有可能给出一个清算相关的场景题类似某客户账户上有10万元现金当日买入某股票1000股成交价10元/股佣金费率万分之二点五其他费用暂不考虑。请计算客户操作完成后账户的可用资金、冻结资金和总资产分别是多少。计算过程买入成交金额 1000股 × 10元 10000元佣金 10000 × 0.00025 2.5元佣金最低起步一般是5元不足5元按5元收取本次买入总扣款 10000 5 10005元可用资金 100000 - 10005 - 冻结未成交部分的资金持仓市值 1000股 × 10元 10000元总资产 可用资金 持仓市值 100000 - 5 10000约等于等答题关键点不在计算多难而在于你有没有意识到买入成交后股份当天是可用还是不可用T1、资金扣减是否包含佣金等费用、冻结资金怎么解冻这些业务细节才是测试要关注的。准确性的验证思路会问你怎么验证一个清算结果是对的。这种提问的考察点是你是否有数据校对的意识。可以这样回答我会采用源数据对账和公式复核两种方式。源数据对账是把清算结果文件和交易所下发的原始数据做一致性比较比如成交记录是否全部处理、每笔成交的金额和费用是否一致。公式复核是手工用Excel或者脚本把推导逻辑跑一遍从原始成交记录重新计算一遍资金和持仓和清算结果比对如果有差异再回溯。4.3 接口测试和幂等性在金融项目里的意义金融系统接口测试里幂等性三个字是考察重点。所谓幂等性是指同一个请求无论发送多少次对系统产生的影响都和发送一次相同。举个最常见的例子客户端提交一笔委托订单。如果网络抖动导致客户端没有收到服务端的响应用户又点了一下提交结果系统生成了两笔委托这就是非幂等。测试人员遇到这种情况必须发出重复请求验证系统只处理一次。接口测试中如何验证幂等性呢。第一步构造一个请求正常发送记录返回结果。第二步用完全相同的请求参数再次发送观察结果。如果接口是幂等的第二次请求要么返回相同的结果要么不产生新的数据变更。测试中常见的做法是在接口请求参数里加一个唯一订单号服务端根据这个订单号判断是否已经处理过是个简单可靠的幂等方案。顺便说一句面试官问你怎么做接口测试时千万别只说用Postman调接口、看返回结果。更完整的回答是先根据接口文档梳理入参和出参设计覆盖正常、异常、边界三种情况的用例然后用脚本或工具批量执行最后验证数据库落库数据是否正确而不只看接口返回。加上数据库层面的校验才是一个完整的接口测试闭环。5. 项目经验怎么讲才能在面试官这里加分笔试面试里项目经验是最能看出水平差异的环节。九成的候选人都败在项目讲得太平或者讲了大量流水账没有重点。5.1 什么样的测试项目经验更有说服力面试官想听的项目经验不是我测了哪些功能模块而是我在这个项目里解决了什么问题、沉淀了什么能力。举两个候选人的对比。A候选人说我上一份工作是做电商平台的功能测试主要是对下单流程做测试。登录、加购物车、下单、支付这些功能我都测过平时还做一些回归测试。B候选人说我上一份工作是做电商平台的核心交易链路测试。刚接手时下单成功率只有99.8%线上偶发用户下单失败。我主导梳理了下单全链路用日志分析定位到两处异常一是优惠券模块在并发时偶发超发二是支付回调重复处理导致订单状态错乱。推动开发修复后下单成功率提升到99.95%。过程中我还搭建了一套接口自动化用例覆盖了下单主流程的回归场景。同样一年的工作经验B候选人的回答立刻就有区分度。他不是说我做了什么功能而是说我发现了什么问题、怎么定位的、产生了什么影响。所以准备项目经验时我建议拿纸写下来四个问题你负责的测试项目核心业务流程是什么上下游依赖哪些系统和数据。你发现了哪些特别有价值的Bug当时的定位链路是什么。你在测试效率上做过什么改进比如自动化脚本、测试工具、数据构造方法。项目上线后出现过线上问题吗你是如何复盘和补充测试用例的。这四块每一块都要有具体案例支撑面试中被深挖也不慌。5.2 用STAR法则讲清一个缺陷排查案例面试官问讲一个你印象最深的Bug时最适合采用STAR结构。所谓STAR就是情境Situation、任务Task、行动Action、结果Result四个环节但要用测试人员的语言来讲不套模板。我拆一个实际的案例给大家做参考框架。情境在某金融系统做接口测试时发现一笔金额为999.99元的转账请求返回成功但数据库里金额变成了1000.00元差了0.01元。任务定位这0.01元的差异是哪里产生的并评估影响范围。行动第一步复现发现固定金额999.99元必现999.98元正常。第二步用抓包工具确认前端请求还是后端返回的问题结果请求参数就是999.99直接去了后端。第三步查后端代码日志发现金额在转换时用了浮点数数据落库前做四舍五入部分金额数值因为浮点精度问题出现0.01元的误差。第四步和开发确认将所有金额存储改为Decimal类型并在接口层增加金额格式校验。结果修复后回归测试覆盖所有边界金额包括999.99、0.01、9999999.99全部通过同时补充了一条金额精确到分的接口测试用例到自动化回归集。这个案例里的关键是你展示了自己的排查链路而不是跳步直接得到结论。这是面试官最看重的测试思维能力。如果你没有真实案例可以拿一个你处理过的小问题进行加工核心是逻辑要通、细节要具体。5.3 没有金融背景的人如何弥补业务短板老实说金证面试很看重候选人是否了解证券业务。但专业背景不是一票否决项面试官会看你的快速学习能力和业务敏感度。没有金融背景的话面试前至少要补上这三块知识第一块股票交易的基本规则。交易时间、涨跌幅限制、一手多少股、T1制度、ST股票的特别处理规则。这些笔试题里会直接考面试时讲到业务场景也能体现你做过功课。第二块账户体系。证券账户体系相对复杂包含资金账户、股东账户、一码通账户。要知道它们之间的层级关系以及转账、买入、卖出过程中资金和持仓是怎么流转的。第三块交易系统的一个完整流程。从客户端下单到券商柜台系统校验再到交易所撮合成交最后回传确认这个链路里的每一步都对应哪些测试关注点。这块业务知识不用学得多深但要能体现出我理解你们公司的业务场景而不是我在测一个黑盒系统。6. 复盘后的几点实用建议写到这里再分享几条复盘后的体会。都是自己当年踩过坑、或者在面试官视角见过太多人犯过的错误。第一笔试时间分配。金证的笔试时间通常比较紧遇到SQL大题和用例设计题不要磨蹭先把思路框架列出来再填充。比如用例设计题先写功能、界面、异常、兼容性、性能、安全几个大类再往每个类下面填用例这样即使后面时间不够面试官也能看到你的整体思路。第二面试时的项目讲解节奏。控制在三到五分钟先一句话概括项目背景再讲你负责的部分。注意不要讲太久面试官会对感兴趣的点主动追问你留出追问空间反而更好。一句话介绍完项目背景后把重点放在遇到的难点和解决方案上。第三准备两到三个反问问题。面试结束前面试官通常会问你有什么想问我的。这时候不要说没有了也别一上来就问薪资和加班。可以问一些体现你思考深度的问题比如数据精度问题在你们的测试体系里是怎么保障的自动化测试目前覆盖了哪些核心链路这种问题既体现你做过功课也帮你判断这个团队的技术水平。第四对薪资和加班的态度。这类金融科技公司项目紧的时候加班是常态尤其交易系统遇上系统升级、交易测试环境联调工作节奏并不轻松。面试中如果不是特别离谱的要求不建议在这个环节硬刚先把offer拿到手再综合比较。最后分享一个细节。我在面候选人时很喜欢问这样一句如果上线后发现一个线上问题你的第一步是什么很多人张口就是先看日志或者先回滚但真正的第一步是评估影响范围确认这次故障影响多少用户、牵扯多少资金和数据。只有先做到这一点后续的动作才有优先级逻辑。能答出这个顺序的候选人我几乎都会给通过。测试这个岗位看起来门槛不高实际想做好需要的能力很综合。技术、业务、沟通、风险管理一样都不能少。希望这篇拆解能帮你在准备过程中少走一些弯路。说到底公司和候选人之间是一个匹配的过程你把真实的能力和思考展示出来了自然能遇到合适的位置。 金证股份软件测试面试题拆解：金融IT测试岗考察重点与答题思路
金证股份的软件测试笔试面试题这几年一直是求职者们讨论比较多的话题。尤其是券商IT类的金融科技公司测试岗位考察的内容和普通互联网不太一样网上流传的题库版本很杂很多人对着刷了一堆题结果笔试照样挂面试被问两句就露馅了。原因很简单没搞懂这家公司要的测试工程师本质上是在测什么东西。这篇文章我会结合我实际带测试团队、也参与过社招校招面试的经历把金证这类金融科技公司软件测试岗位的笔试题型、面试考察点、答题思路完整拆一遍。文章不是让你背答案而是告诉你每一类题背后到底在考察什么以及怎么答才能踩到面试官的点上。1. 面试金证前先把这家公司的测试岗位看明白很多人的错误在于一上来就刷题。先想清楚一个问题金证股份是干什么的它的测试岗位到底在测什么系统这决定了你复习的方向。1.1 金证股份的业务底色金融IT不是普通软件公司金证股份根子在金融IT服务服务的客户以证券公司、基金公司为主也覆盖银行和泛金融机构。核心产品包括证券交易系统、资产管理系统、量化交易平台、登记清算系统这类对实时性、准确性和资金安全要求极高的系统。这对测试岗位意味着什么呢。普通APP测试一个按钮点进去页面卡了提个Bug开发修掉大家下班。金融交易系统里一笔委托报单进来经过合规校验、资金校验、持仓校验最后落到交易所任何一个环节算错一分钱或者并发高的时候丢了一笔委托这都不是体验问题而是生产事故是要赔钱、被监管问责的。所以金证的测试工程师日常接触的是这种高并发、强一致的分布式交易链路测的是撮合引擎、清结算服务、行情推送这些模块。笔试面试里出现的SQL题、接口题、场景设计题全部围绕这类业务展开。你按普通互联网项目的经验去答方向就偏了。1.2 券商IT测试和普通业务系统测试的本质差别一句常被老测试挂在嘴边的话普通软件测试是保证功能符合预期金融系统测试是保证一分钱都不许错一笔单都不许丢。维度普通业务系统券商IT系统核心关注点功能完整、用户体验数据准确性、资金安全、实时性数据特点数据错了可以改数据错了要追责、要走冲正流程并发要求秒杀场景偶尔高并发交易日全天高并发峰值集中在开盘时段监管要求一般无需要满足合规留痕、审计追溯订单处理丢了可以重试丢单会导致客户损失必须有对账机制这个底层差异直接决定了笔试题里为什么反复出现如果客户买入100股实际成交了50股剩余资金怎么算如何验证清算金额正确这类问题。他们招的不是只会点点点的执行者而是能理解业务链路、能从数据层面验证正确性的测试工程师。1.3 投递前如何快速摸底岗位侧重点金证的测试岗位也分多条线功能测试、自动化测试、性能测试、接口测试不同岗位笔试面试的侧重点很不一样。投递前花十分钟去几个地方摸底拉勾、BOSS直聘上搜金证股份 测试工程师看最近两个月的岗位JD里面的关键词就是复习重点。看岗位是偏业务测试还是偏技术测试。偏业务的笔试题里用例设计、流程题多偏技术的自动化脚本、接口测试、性能分析题多。如果岗位描述里写了熟悉证券业务者优先那笔试题里大概率有金融业务的基础概念题比如股票交易规则、交易时间段、账户体系。见过太多人简历投过去笔试挂了还在奇怪为什么自己准备了一堆Selenium题目结果考的是数据库和业务设计。原因就是你连岗位具体要什么人都没搞清楚。2. 笔试环节的题型分布与答题策略金证笔试整体风格偏务实不搞花架子题量大、时间紧。通常包含四类测试基础理论题、SQL题、用例设计题、逻辑题。下面逐个拆。2.1 测试基础理论题的常见问法理论题考得很细集中在测试流程、测试分类、用例设计方法、缺陷管理这些方向。常见题目有黑盒测试和白盒测试的区别各自适合什么阶段。什么是等价类划分法举例说明。什么是边界值分析法为什么它容易发现缺陷。什么是V模型和W模型区别在哪。一条Bug记录应该包含哪些必要字段。如何理解测试覆盖率它是否能衡量测试质量。这类题你光背概念不够没答出为什么用它大概率往下扣分。我建议复习的时候不死背定义而是每个方法都准备一个具体例子。比如等价类划分不要说把输入域划分成有效和无效等价类就结束而是说拿登录功能的用户名输入框举例有效等价类是可以正常登录的合法用户名无效等价类是空值、超长字符串、包含特殊字符的用户名。设计用例时每个等价类至少覆盖一次这样既保证覆盖度又控制用例数量。这种答法说明你真的理解这个方法而不是背了书上的话。另一个高频考点是V模型的测试流程。V模型强调开发和测试的对等关系每个开发阶段都有对应的测试阶段。答题时顺便点一句该模型的问题在于测试介入偏晚实际项目中会结合敏捷模式前置测试能看出你对工程实践有思考。2.2 SQL题目必考的联表查询与统计题金证的SQL题比重非常高原因前面说了金融系统测试中大量场景需要直接查数据库验证数据。笔试题通常会给两张表让你写查询。我记得有一道很典型的题表结构 orders(id, user_id, stock_code, order_type, price, quantity, status, create_time) users(id, user_name, mobile) 需求 1. 查询所有已成交订单的用户姓名和股票代码 2. 统计每个用户的订单数量按订单数倒序排列 3. 查询今天成交金额最高的前5笔订单 4. 找出从未下过单的用户对应的SQL写法先自己动手写一遍再往下看。第一题最简单两表联查SELECT u.user_name, o.stock_code FROM orders o JOIN users u ON o.user_id u.id WHERE o.status 成交;第二题分组统计加排序SELECT u.user_name, COUNT(*) AS order_cnt FROM orders o JOIN users u ON o.user_id u.id GROUP BY u.user_name ORDER BY order_cnt DESC;第三题取最高5笔需要联查股票代码和用户名称按成交金额倒序最后加LIMIT 5SELECT u.user_name, o.stock_code, o.quantity * o.price AS trade_amount FROM orders o JOIN users u ON o.user_id u.id WHERE o.status 成交 ORDER BY trade_amount DESC LIMIT 5;第四题用NOT EXISTS或者LEFT JOIN再过滤空值都可以SELECT u.user_name FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id u.id);这类题丢分点集中在这几个地方忘了考虑状态字段、分组字段和查询字段不一致、关联条件写错。笔试时间紧张时看题先圈出筛选条件和聚合函数再动笔。补充一点金证笔试有时候会让写删除重复数据只保留一条这类SQL属于考察窗口函数或GROUP BY的变体复习时稍微花时间看一眼ROW_NUMBER()的用法性价比很高。2.3 用例设计题从一个登录功能考察全面性用例设计题几乎是所有测试笔试的压轴题。题目形式通常是一道请针对XX功能设计测试用例这个XX可能是登录、转账、下单、买入股票、注册等等。千万别只盯着输入正确的用户名密码能登录这种Happy Path。面试官想通过这道题看两件事第一你有没有系统的用例设计方法论第二你考虑问题是否全面能不能覆盖异常场景和边界场景。我以股票买入委托功能为例拆一下标准答题思路第一步确定输入域。买入委托通常需要输入用户ID、资金账号、股东账号、股票代码、委托价格、委托数量。每个字段都有边界。股票数量上A股一手是100股买入数量必须是100的整数倍科创板最低200股但可以按1股递增这一类业务规则就是边界值分析法的天然素材。第二步按场景设计用例正常场景正常资金买入100股验证持仓和资金变动正确。资金不足场景账户余额只够买100股但用户输入200股的需求系统应该拦截并给出明确提示。买入数量非100倍数的场景输入150股系统是否提示委托数量应为100股的整数倍。买入无权限股票如买入ST股票但未签署风险揭示书。非交易时段委托系统是否支持预埋单还是直接拒绝。股票停牌场景委托提交后是否提示该股票停牌。价格超涨跌幅限制场景买入价超过涨停价系统直接拒单。第三步考虑数据一致性和幂等性快速连续点击两次提交按钮会不会产生两笔重复委托。这个场景真实发生过前端没做防重测试一定要覆盖。你按这个层次去设计用例从功能到业务规则到异常再到数据一致性面试官一眼就能看出你的水平。只写能正常买入、不能买入、余额不足这三条的大概率挂在笔试。2.4 逻辑题与智力题被低估的10分钟金证笔试里逻辑题一般放在最后几道小题看似是智力题实际上考察的是你的逻辑思维和快速反应。比如经典的三个人三天喝三桶水九个人九天喝几桶水或者烧绳子计时这类题。还有一类和工程实际结合的逻辑题一个接口每天调用量很大白天成功率是99.9%为什么到了晚间反而出现超时增多的情况这道题没有标准答案考察你的分析思路。可以这样答先看监控确认超时时段是否集中再排查是不是夜间批量任务和大数据同步任务占了数据库连接池或者看依赖的第三方服务是否有夜间维护窗口。答这类题的关键是展现你有排查思路而不是死等一个完美答案。时间分配上逻辑题不要恋战一道题卡了超过五分钟就先跳过去把前面能拿的分先拿到。3. 面试高频技术问题怎么答才不扣分笔试过了之后是面试一般有两到三轮技术面。这一环节里面试官不再满足于你知道某个知识点而是通过连续追问判断你实际做没做过。3.1 测试流程类的提问V模型不再是标准答案介绍一下你们项目里的测试流程是必问题但也是很多人答得最没区分度的问题。如果你只说需求评审、测试计划、用例设计、用例执行、回归测试、线上验证这条流水线面试官只能判断你干过活判断不了你的思考深度。加分回答方式是结合流程说明你为什么要这样做。比如我们团队用的是敏捷迭代两周一个迭代。我的工作从需求评审就介入了不是等开发做完才测。因为提前了解需求我可以在PRD阶段就抛出一些边界场景问题帮开发避免返工。用例评审和开发对需求理解达成一致后开发提测时我优先验证主流程再安排回归。上线前我们有一个准入准出标准比如核心用例通过率必须100%、遗留Bug不超过两个P2达不到就不允许发布。这段话里包含了敏捷模式、测试左移、准入准出标准三个加分点全是真实团队会做的事。如果被问到V模型和W模型别再机械背定义。可以直接说V模型和W模型本质是强调开发与测试的对应关系但现代项目里测试已经前置单纯套V模型会导致前期缺陷发现太晚。我们实际用的是基于敏捷迭代的测试流程需求分析阶段测试就介入代码评审和单元测试质量也会纳入测试关注范围。这种回答等于把经典题目和现代实践做了结合面试官挑不出毛病。3.2 用例设计方法的追问从等价类到场景法面试官通常会问你平时用什么方法设计用例这时候要展开讲不要只报方法名。有一个通用的答题框架按测试对象来划分功能测试场景用等价类和边界值覆盖输入域用场景法覆盖用户完整操作流程。接口测试场景用参数组合覆盖接口入参的正常、异常、边界三类情况。业务规则复杂场景用判定表梳理条件组合和对应结果。操作流程类场景用正交试验或场景法减少组合数量避免用例冗余。拿转账功能举例子。等价类划分正常转账金额、超出当日限额金额、小于0.01元的金额、小数点超过两位的金额。边界值单笔限额10000元那么9999.99、10000、10000.01这三个值都要测。判定表余额充足且收款人正常、余额充足但收款人异常、余额不足且收款人正常、余额不足且收款人异常这四种组合都要覆盖。能按这个思路答面试官听到的就是这个人不是照着模板写用例而是真正理解每个方法适合解决什么问题。3.3 Linux、数据库、网络相关的考察点技术面里Linux命令、数据库、网络基础是三个常考的硬技能板块尤其在测试岗位因为测试环境维护和线上问题定位都离不开这三块。Linux常见考察方式有# 查看某个服务进程是否在运行 ps -ef | grep java # 实时查看日志文件的最新内容定位接口报错 tail -f /logs/app.log # 从日志文件里筛选出ERROR级别的日志并按出现次数排序统计 grep ERROR app.log | sort | uniq -c | sort -nr # 查看某个端口是否被占用 netstat -tlnp | grep 8080 # 查找上一天修改过的所有日志文件 find /logs -name *.log -mtime -1特别提醒tail和grep是出现频率最高的两个命令。无路可走时就是这两个命令在日志里定位线索。数据库考察不只有笔试里的SQL还有实践类提问比如线上发现一条数据异常你怎么排查。回答思路是先确认异常数据的影响范围再查看这条数据的操作日志或审计日志锁定是哪个接口什么时间写入的再联合开发人员一起看代码逻辑定位根因。网络基础问得多的有HTTP和HTTPS的区别握手过程大致是怎样的。GET和POST的区别什么场景用什么。一个请求从客户端发出到服务端返回经历了哪些环节。TCP三次握手是为了解决什么问题。这类题目看上去基础但容易暴露出只会用不会原理的问题。建议复习时多问自己一句为什么比如TCP握手为什么非得三次这个问题的本质是确认双方的收发能力正常。3.4 自动化测试与工具链的问题金证的测试团队自动化程度不低尤其是交易系统回归测试手工回归到崩溃必须靠自动化。所以自动化相关的问题基本必问。面试官第一个问题通常是你做过哪些自动化。有人上来就说Selenium做Web自动化、Appium做App自动化这等于什么都没说。我的建议是哪怕你只做过一点点接口自动化也要系统讲出来接口自动化在金证的场景下含金量比单纯UI自动化高。一段推荐的回答结构我在上一个项目里负责接口自动化框架的搭建和维护。技术栈是Python加Pytest加Requests数据驱动的方式管理用例。测试数据存在YAML文件里统一从配置文件读取环境信息。因为我们接口数量比较多我设计了基于模块的用例分层公共方法比如登录鉴权、请求封装、断言封装都抽成独立的模块用例只关注业务逻辑。持续集成上接的Jenkins每天晚上自动跑一遍全量回归第二天早上出测试报告跑挂的用例自动发邮件通知到对应负责人。这个回答里包含了框架选型、数据驱动、分层设计、持续集成、自动通知五个关键点哪怕这个回答是模拟的比只说Selenium几个字强出一大截。被问为什么要做接口自动化而不是UI自动化时强调两个逻辑第一接口回归成本低、执行速度快适合高频回归场景。第二券商系统业务逻辑的验证集中在后端接口层面UI自动化只能验证页面展示接口自动化才能直接验证业务处理结果。工具方面Postman、JMeter、Pytest、Selenium、Appium这几个起码得有一个能讲出实际使用细节。比如用JMeter做过什么压测、设置了多少并发、重点关注哪些指标、怎么分析结果。没有凌晨压测调优经历的人讲出来的东西一听就是背的。4. 金融业务测试的独特考点如果你面的就是金证的测试岗业务能力是一道硬门槛。金融行业软件测试和通用软件测试最大的区别就在于不懂业务连测试用例都写不出来。笔试面试里关于证券业务的问题要特别准备。4.1 交易系统测试要关注哪些核心指标券商交易系统核心指标离不开快、准、稳这三个字。落到测试上对应三类测试性能测试、功能测试、稳定性测试。快交易链路时延必须达标。股票交易是强实时场景用户在客户端下单订单要经过中间件、交易网关、报盘机最后到达交易所主机这个链路的耗时直接影响用户体验和交易质量。性能测试中要关注的核心指标包括TPS每秒事务数、平均响应时延、99分位时延、服务器CPU和内存占用。准业务处理不能出错。委托校验、资金计算、持仓更新、订单状态流转每一步的结果都必须精确无误。功能测试重点覆盖这些业务规则。稳系统在连续高负载下不能崩溃故障后要能快速恢复。这就要做稳定性测试一般持续跑7乘24小时或至少一个完整交易日的加压场景观察是否有内存泄漏、连接池耗尽等问题。面试中如果说我们项目里压测的时候关注TPS和响应时间是不够的。直接给出一个例子比如我们模拟了开盘半小时的峰值流量3000并发用户同时报单要求系统TPS不低于500099分位时延小于500毫秒服务器CPU不高于70%持续压测30分钟无错误订单这个回答的颗粒度完全不同。4.2 资金清算与准确性验证的思路资金清算是券商IT测试里最容易出题的部分。因为社会普遍理解的买股票就是下单成交但实际后端流程复杂得多客户买入股票后资金账户被冻结成交后资金扣减持仓增加卖出股票后持仓冻结成交后持仓扣减资金增加。这还只发生在交易日晚上还要做清算结算公司下发清算数据资金和股份才能最终划拨到位。笔试题或面试官极有可能给出一个清算相关的场景题类似某客户账户上有10万元现金当日买入某股票1000股成交价10元/股佣金费率万分之二点五其他费用暂不考虑。请计算客户操作完成后账户的可用资金、冻结资金和总资产分别是多少。计算过程买入成交金额 1000股 × 10元 10000元佣金 10000 × 0.00025 2.5元佣金最低起步一般是5元不足5元按5元收取本次买入总扣款 10000 5 10005元可用资金 100000 - 10005 - 冻结未成交部分的资金持仓市值 1000股 × 10元 10000元总资产 可用资金 持仓市值 100000 - 5 10000约等于等答题关键点不在计算多难而在于你有没有意识到买入成交后股份当天是可用还是不可用T1、资金扣减是否包含佣金等费用、冻结资金怎么解冻这些业务细节才是测试要关注的。准确性的验证思路会问你怎么验证一个清算结果是对的。这种提问的考察点是你是否有数据校对的意识。可以这样回答我会采用源数据对账和公式复核两种方式。源数据对账是把清算结果文件和交易所下发的原始数据做一致性比较比如成交记录是否全部处理、每笔成交的金额和费用是否一致。公式复核是手工用Excel或者脚本把推导逻辑跑一遍从原始成交记录重新计算一遍资金和持仓和清算结果比对如果有差异再回溯。4.3 接口测试和幂等性在金融项目里的意义金融系统接口测试里幂等性三个字是考察重点。所谓幂等性是指同一个请求无论发送多少次对系统产生的影响都和发送一次相同。举个最常见的例子客户端提交一笔委托订单。如果网络抖动导致客户端没有收到服务端的响应用户又点了一下提交结果系统生成了两笔委托这就是非幂等。测试人员遇到这种情况必须发出重复请求验证系统只处理一次。接口测试中如何验证幂等性呢。第一步构造一个请求正常发送记录返回结果。第二步用完全相同的请求参数再次发送观察结果。如果接口是幂等的第二次请求要么返回相同的结果要么不产生新的数据变更。测试中常见的做法是在接口请求参数里加一个唯一订单号服务端根据这个订单号判断是否已经处理过是个简单可靠的幂等方案。顺便说一句面试官问你怎么做接口测试时千万别只说用Postman调接口、看返回结果。更完整的回答是先根据接口文档梳理入参和出参设计覆盖正常、异常、边界三种情况的用例然后用脚本或工具批量执行最后验证数据库落库数据是否正确而不只看接口返回。加上数据库层面的校验才是一个完整的接口测试闭环。5. 项目经验怎么讲才能在面试官这里加分笔试面试里项目经验是最能看出水平差异的环节。九成的候选人都败在项目讲得太平或者讲了大量流水账没有重点。5.1 什么样的测试项目经验更有说服力面试官想听的项目经验不是我测了哪些功能模块而是我在这个项目里解决了什么问题、沉淀了什么能力。举两个候选人的对比。A候选人说我上一份工作是做电商平台的功能测试主要是对下单流程做测试。登录、加购物车、下单、支付这些功能我都测过平时还做一些回归测试。B候选人说我上一份工作是做电商平台的核心交易链路测试。刚接手时下单成功率只有99.8%线上偶发用户下单失败。我主导梳理了下单全链路用日志分析定位到两处异常一是优惠券模块在并发时偶发超发二是支付回调重复处理导致订单状态错乱。推动开发修复后下单成功率提升到99.95%。过程中我还搭建了一套接口自动化用例覆盖了下单主流程的回归场景。同样一年的工作经验B候选人的回答立刻就有区分度。他不是说我做了什么功能而是说我发现了什么问题、怎么定位的、产生了什么影响。所以准备项目经验时我建议拿纸写下来四个问题你负责的测试项目核心业务流程是什么上下游依赖哪些系统和数据。你发现了哪些特别有价值的Bug当时的定位链路是什么。你在测试效率上做过什么改进比如自动化脚本、测试工具、数据构造方法。项目上线后出现过线上问题吗你是如何复盘和补充测试用例的。这四块每一块都要有具体案例支撑面试中被深挖也不慌。5.2 用STAR法则讲清一个缺陷排查案例面试官问讲一个你印象最深的Bug时最适合采用STAR结构。所谓STAR就是情境Situation、任务Task、行动Action、结果Result四个环节但要用测试人员的语言来讲不套模板。我拆一个实际的案例给大家做参考框架。情境在某金融系统做接口测试时发现一笔金额为999.99元的转账请求返回成功但数据库里金额变成了1000.00元差了0.01元。任务定位这0.01元的差异是哪里产生的并评估影响范围。行动第一步复现发现固定金额999.99元必现999.98元正常。第二步用抓包工具确认前端请求还是后端返回的问题结果请求参数就是999.99直接去了后端。第三步查后端代码日志发现金额在转换时用了浮点数数据落库前做四舍五入部分金额数值因为浮点精度问题出现0.01元的误差。第四步和开发确认将所有金额存储改为Decimal类型并在接口层增加金额格式校验。结果修复后回归测试覆盖所有边界金额包括999.99、0.01、9999999.99全部通过同时补充了一条金额精确到分的接口测试用例到自动化回归集。这个案例里的关键是你展示了自己的排查链路而不是跳步直接得到结论。这是面试官最看重的测试思维能力。如果你没有真实案例可以拿一个你处理过的小问题进行加工核心是逻辑要通、细节要具体。5.3 没有金融背景的人如何弥补业务短板老实说金证面试很看重候选人是否了解证券业务。但专业背景不是一票否决项面试官会看你的快速学习能力和业务敏感度。没有金融背景的话面试前至少要补上这三块知识第一块股票交易的基本规则。交易时间、涨跌幅限制、一手多少股、T1制度、ST股票的特别处理规则。这些笔试题里会直接考面试时讲到业务场景也能体现你做过功课。第二块账户体系。证券账户体系相对复杂包含资金账户、股东账户、一码通账户。要知道它们之间的层级关系以及转账、买入、卖出过程中资金和持仓是怎么流转的。第三块交易系统的一个完整流程。从客户端下单到券商柜台系统校验再到交易所撮合成交最后回传确认这个链路里的每一步都对应哪些测试关注点。这块业务知识不用学得多深但要能体现出我理解你们公司的业务场景而不是我在测一个黑盒系统。6. 复盘后的几点实用建议写到这里再分享几条复盘后的体会。都是自己当年踩过坑、或者在面试官视角见过太多人犯过的错误。第一笔试时间分配。金证的笔试时间通常比较紧遇到SQL大题和用例设计题不要磨蹭先把思路框架列出来再填充。比如用例设计题先写功能、界面、异常、兼容性、性能、安全几个大类再往每个类下面填用例这样即使后面时间不够面试官也能看到你的整体思路。第二面试时的项目讲解节奏。控制在三到五分钟先一句话概括项目背景再讲你负责的部分。注意不要讲太久面试官会对感兴趣的点主动追问你留出追问空间反而更好。一句话介绍完项目背景后把重点放在遇到的难点和解决方案上。第三准备两到三个反问问题。面试结束前面试官通常会问你有什么想问我的。这时候不要说没有了也别一上来就问薪资和加班。可以问一些体现你思考深度的问题比如数据精度问题在你们的测试体系里是怎么保障的自动化测试目前覆盖了哪些核心链路这种问题既体现你做过功课也帮你判断这个团队的技术水平。第四对薪资和加班的态度。这类金融科技公司项目紧的时候加班是常态尤其交易系统遇上系统升级、交易测试环境联调工作节奏并不轻松。面试中如果不是特别离谱的要求不建议在这个环节硬刚先把offer拿到手再综合比较。最后分享一个细节。我在面候选人时很喜欢问这样一句如果上线后发现一个线上问题你的第一步是什么很多人张口就是先看日志或者先回滚但真正的第一步是评估影响范围确认这次故障影响多少用户、牵扯多少资金和数据。只有先做到这一点后续的动作才有优先级逻辑。能答出这个顺序的候选人我几乎都会给通过。测试这个岗位看起来门槛不高实际想做好需要的能力很综合。技术、业务、沟通、风险管理一样都不能少。希望这篇拆解能帮你在准备过程中少走一些弯路。说到底公司和候选人之间是一个匹配的过程你把真实的能力和思考展示出来了自然能遇到合适的位置。