2023年秋招那段时间我一直在牛客和招聘官网之间来回刷测试岗机会看到途虎养车放出2023秋招测试笔试试卷A的时候我第一时间就投了。整套题做完最大的感受是它和纯互联网大厂的数理题、性格测试完全不是一回事途虎的笔试卷是带着业务基因的——你能明显感觉到它要招的不是一个只会写用例、点点点的测试而是能理解汽车后市场O2O链路、能扛住移动端和门店系统双重质量压力的测试工程师。这篇文章我按记忆梳理一下试卷A的整体面貌包括命题逻辑、题型分布、高频考点、自动化工具题怎么答、用例设计题怎么拆以及最后给我的复盘和复习建议。如果你正准备投途虎测试岗这篇可以帮你少走不少弯路如果你只是对汽车后市场这类垂直行业的测试感兴趣也能从里面看到这类公司到底在笔试环节筛选什么样的人。1. 试卷A到底在考什么从途虎的业务版图反推命题逻辑1.1 途虎测试岗要解决的不只是一个App而是一整条O2O链路做笔试题之前我习惯先花两分钟想清楚一件事这家公司靠什么赚钱测试的边界在哪里命题人会优先关心什么。途虎养车不是纯互联网平台也不是单纯的门店连锁它的核心模式是汽车后市场的线上线下一体化——用户在App或小程序上选轮胎、买保养套餐、预约到店时间然后去线下门店完成安装和维修中间还夹着供应链、仓储、物流、订单、支付、核销、评价一整条链路。这意味着途虎的测试对象覆盖得很杂用户端途虎养车AppiOS / Android、微信小程序、H5页面门店端门店管理后台、技师使用的接单/核销工具甚至还有扫码枪、PDA这类桌面或移动设备服务端订单中心、支付中心、库存中心、优惠券/营销系统、会员体系数据与风控活动防刷、异常订单识别、评价内容审核硬件与车载相关胎压监测设备、车辆检测设备以及和车联网、智能座舱相关的合作项目所以试卷A的命题逻辑其实很清晰它希望候选人既有通用测试功底又能看懂业务场景并且能把这些场景转化成测试用例。很多候选人笔试挂掉不是死在理论题上而是死在不理解“为什么途虎要考这种业务场景”。1.2 试卷A的三条主线通用测试功底、移动端质量、业务场景分析整套卷子在我脑海里可以大致归成三条主线。第一条是通用测试功底。用例设计方法、测试流程、缺陷管理、V模型、冒烟测试和回归测试的概念这类题目无论哪家测试笔试都会出现途虎也不例外。它是用来筛选“有没有基本测试思维”的底层题。第二条是移动端质量保障。途虎App是整个C端业务的核心入口用户从浏览商品到下单支付全都在移动端完成所以移动端测试、Appium自动化、弱网、兼容性这些相关概念在试卷里占比不低。第三条是业务理解和场景分析这是最拉分的一块。同样一个“下单”功能你能不能想到多门店、库存不足、支付回调延迟、定位超出门店服务范围、退款逆向流程这些真实场景试卷A的简答题和综合场景题基本都在验证这种能力。这三条主线不是割裂的而是互相穿插的。比如一道用例设计题表面考你是不会用等价类和边界值实际上还考你能不能把途虎的业务规则套进去。后面我会拿一道典型的题目拆开讲。2. 题型结构与时间分配拿到试卷A后我这样安排答题节奏2.1 常见题型分布与分值印象试卷A我印象里是60到90分钟的限时笔试整体题量适中但题与题之间的分值差距很大。我根据记忆整理了一份大致的题型分布不一定精确但结构上可以给后面的人一个参考题型大致题量分值占比考查重点单选题 / 多选题 / 判断题15-25题20%-30%测试理论、Linux命令、网络、数据库、自动化基础概念简答题3-5题20%-25%冒烟测试理解、V模型流程、接口测试与UI测试区别用例设计题1-2题25%-35%结合业务场景设计测试用例等价类、边界值、场景法代码 / 脚本题0-2题10%-15%简单SQL、Python脚本、自动化用例片段补全综合场景题1题10%-15%线上问题排查、缺陷分析、测试计划制定思路这套结构最大的特点是选择题只是门槛真正的分值集中在用例设计和综合场景题上。很多人在选择题上过于纠结结果到用例设计题时只剩十几分钟这是笔试的大忌。2.2 做题顺序和时间控制我的建议是拿到试卷先看一遍简答题、用例设计题和综合场景题做到心里有数再决定怎么分配时间。如果时间紧张优先级应该是用例设计题 综合场景题 简答题 选择题 代码题。为什么这么排因为用例设计题和综合场景题是按得分点给分的你写出一个有效测试点就有一个点的分哪怕最后结论不够完美也能拿一部分分。而选择题只有对和错不会就是不会再花时间也蒙不出来。我当时给自己定的节奏是这样的选择题15分钟简答题15分钟用例设计和综合场景题35分钟剩下5到10分钟检查。如果某道选择题卡了超过1分钟直接标记跳过等回头有时间再补。这套节奏在后面的秋招里也帮我稳住了不少笔试。3. 高频考点逐个击破从测试理论到汽车后市场业务3.1 用例设计方法等价类、边界值、场景法的答题姿势用例设计是测试笔试的必修课试卷A里不可能没有。考法通常是给一个功能描述要求“设计测试用例”或者“写出至少8-10个测试点”然后看你有没有用到等价类、边界值、场景法这些方法。很多新人的错误是把用例设计写成操作步骤比如“点击登录按钮输入账号密码点击确认”这只能算操作流程不是测试用例。正确的答法是先划分测试对象的状态和维度再逐条列出“前置条件 操作步骤 预期结果”。举个例子如果题目是“途虎养车App的注册登录功能”我会从这些维度拆输入校验手机号格式、验证码长度、密码复杂度、重复手机号异常场景验证码错误、验证码过期、网络中断、多次点击发送验证码状态流转未注册手机号自动注册、已注册手机号直接登录、第三方账号绑定安全与权限登录态失效、异地登录提醒、隐私协议确认兼容性不同品牌手机、不同分辨率、不同系统版本这样写出来的用例不仅量够而且覆盖了功能、异常、安全、兼容多个层面面试官一眼就能看出你有测试思维。笔试里如果能用等价类把输入范围分组再用边界值把“刚好通过”和“刚好不通过”的临界值补上这道题基本就稳了。3.2 测试流程与模型V模型、冒烟测试、回归测试怎么考试卷A里关于测试流程的题一般不会太难但特别容易踩概念坑。比如简答题问“请简述冒烟测试和回归测试的区别”大部分人能说上两句但要说得准确必须抓住本质。冒烟测试的对象是“新版本的核心功能”它的目的是在正式测试开始之前快速验证主流程能不能跑通。如果冒烟都过不了说明这个版本质量差到没有继续测的必要直接打回给开发。回归测试的对象是“之前已经测试过的老功能”它的目的是确认本次代码改动没有破坏原有功能。通俗地说冒烟测试是“新版本能不能开机”回归测试是“改动之后旧功能有没有坏”。V模型在试卷里的考法也很有意思不是让你背“需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试”这条链而是让你说出“测试为什么要尽早介入”。我看到这道题的时候第一反应是引用V模型里测试阶段和开发阶段的对应关系然后补一句需求阶段的缺陷如果拖到系统测试才发现修复成本会呈指数级上升。这种回答比单纯背流程要有血有肉得多。3.3 途虎App业务链路状态机、支付回调、线下履约这部分算是试卷A真正的分水岭。同样是“下单”功能纯互联网公司的测试用例关注的是购物流程是否顺畅、优惠是否计算正确而途虎这种O2O模式下测试用例还多了一条线下履约链路。我印象里试卷A里有相当一部分业务场景题都是围绕“订单”和“门店”展开的。比如用户从App下单购买轮胎选择门店并预约安装时间支付成功后到店核销技师完成安装后订单状态变化用户评价后整个流程闭环。这里面最值得提前准备的是订单状态机。订单状态可能会拆成这些节点未支付 → 已支付 → 已预约 → 服务中 → 已完成 → 已评价中间还挂着取消、退款、售后的分支。测试时不能只测这条主链路还要测异常分支未支付订单超时自动关闭、支付成功后回调迟迟没返回、门店临时闭店导致预约失败、用户到店但技师排期已满、配件库存不足触发退款。还有一个高频考点是支付回调的幂等性。用户付了钱但支付网关的回调消息因为网络原因发了好几次如果服务端处理逻辑没有做好幂等用户账户可能被重复扣款订单也可能被重复置为已支付。笔试里遇到这类题不管题目怎么包装核心答案就一句话服务端要保证同一笔订单同一笔支付结果无论回调多少次最终的业务状态只有一次变更。线下履约环节还经常会和定位、权限关联起来。用户选择门店时App会申请定位权限这时要考虑用户拒绝授权怎么办、GPS信号弱怎么办、门店服务范围和用户实际位置不符怎么办。这些细节在有线下场景的公司里都是真实会出现的Bug写在试卷上就是很好的加分项。3.4 车载与智能座舱相关没有车联网经验该怎么答热搜词里大量出现了车载测试、智能座舱测试、汽车电子测试这也符合途虎所在行业的大背景。即便2023秋招试卷A里车载相关题目占的比重不算特别大但完全不准备也会吃亏尤其是简答题里如果出现“智能座舱测试和手机App测试有什么不同”很多人会卡壳。我当时是从测试思维迁移的角度来答的。不管是手机App还是智能座舱功能测试、性能测试、兼容性测试、稳定性测试这些底层逻辑没有变变的只是被测对象和场景差异。智能座舱多了语音交互、多屏联动、车载地图、倒车影像、蓝牙连接、驾驶员监控这些车载特有功能稳定性要求更高因为车机系统在高温、震动、强光环境下要持续稳定运行安全要求更严格因为任何误触或系统卡死都可能影响行车安全。如果你没有车载背景至少要把“稳定性测试”“长时运行老化测试”这个概念理解透。试卷A或者面试中一旦出现“设备老化测试全自动执行脚本”这类题它本质上考的是你怎么设计自动化脚本去模拟设备长时间运行、监控内存和CPU泄漏、在异常发生后自动恢复并记录日志。这类题的答题框架我放在后面自动化章节里讲。3.5 安全与性能渗透测试、连接数、老化测试这些延伸考点安全测试和性能测试在试卷A里属于“不做重点但必须知道”的考点。选择题里可能会出现SQL注入、XSS跨站脚本、越权访问、验证码安全问题简答题里可能会问“接口测试时如何保证安全性”。对途虎这类有支付和用户资产的平台支付接口的签名校验和越权防护是安全测试的重中之重。笔试里出现“支付订单金额被篡改”“用户A通过改接口参数查看用户B订单”这类题考察的就是你有没有越权测试的概念。我的答法是先说明越权分水平越权和垂直越权再给两条验证思路水平越权是同一角色去访问其他同级别用户的数据垂直越权是低权限用户去访问高权限接口。然后补一句“在接口测试用例里必须覆盖不同角色、不同用户的ID替换场景”这道题就能拿个不错的分数。性能方面结合途虎的业务场景最值得答的是大促和预约高峰。每年双十一、618或者平台大促节点瞬间涌进来大量用户抢优惠券、下单、预约门店这时候服务端能不能扛住并发连接数接口响应时间会不会明显变长数据库会不会出现连接池打满这些都是性能测试要关注的点。试卷里如果问“线上出现大量用户下单后订单状态长时间不更新你作为测试怎么排查”不要只答功能Bug要从服务端日志、数据库慢查询、消息队列积压、支付回调延迟多个维度去拆。4. 自动化与工具链考点Appium、pytest、接口自动化框架怎么考4.1 Appium移动端自动化最容易考的几个点2023年的测试笔试自动化工具早就不只是选择题里的名词解释了试卷A里已经出现“给一段Appium配置让你判断哪里写错”这类题。Appium的核心是基于WebDriver协议通过iOS的XCUITest和Android的UIAutomator2驱动原生应用所以跨平台是它最大的卖点。笔试里Appium的高频考点主要有这几个Desired Capabilities配置platformName、platformVersion、deviceName、appPackage、appActivity必须配对appPackage填错直接导致session创建失败。元素定位优先使用resource-id、accessibility id、content-desc少用xpath。xpath在Appium里不是不能用而是解析成本高、页面结构一变就容易挂笔试如果问“为什么定位不稳定”答案基本都落在这一条。等待机制显式等待、隐式等待、强制sleep三者之间的区别。最不该用的就是强制sleep固定等几秒既浪费时间又容易因为设备卡顿产生误报显式等待配合ExpectedConditions去做元素出现判断才是稳定性的保证。我当时在笔试里遇到一道题问“Appium脚本在低配手机上跑经常失败你怎么排查”。我的思路是先看是不是等待时间不够导致元素未出现再看是不是网络或页面加载慢最后看设备是否开启了GPU渲染必要时改用更稳定的定位策略并增加重试机制。这种题没有标准答案但逻辑完整就能得分。4.2 pytest从fixture到参数化别只背概念pytest在热搜词里排得很靠前试卷A里的代码题如果出现Python大概率绕不开pytest。笔试题型通常是补全一段测试用例或者让你看一段有Bug的fixture代码找错。准备pytest我建议把下面这几个点彻底弄明白fixture的作用它是测试前置条件的复用机制比如初始化数据库连接、构造测试数据、启动被测服务。fixture的scope参数function、class、module、session决定了它的生命周期。conftest.py公共fixture放在这个文件里同一目录和子目录下的测试用例都能自动引入不用每个文件重复import。参数化pytest.mark.parametrize用来做数据驱动一组参数跑一遍用例。比如登录接口传入不同账号密码组合一个用例函数就能覆盖正常、密码错误、账号不存在多条场景。断言机制直接用assert关键字pytest会自动收集断言失败信息不需要像unittest那样调用self.assertEqual。很多候选人会背pytest的概念但一到写代码就露怯。我建议准备笔试的时候至少能手写一个简单的fixture加参数化用例不需要多高深但语法要规范。我当时背下来的一个最小模板是import pytest pytest.fixture def user_token(): # 模拟登录后获取token return test_token pytest.mark.parametrize(order_id, expected_code, [ (1001, 200), (1002, 404), ]) def test_order_query(user_token, order_id, expected_code): # 这里是调用接口的简化逻辑 assert query_order(user_token, order_id) expected_code这个模板虽然简单但已经覆盖了fixture、parametrize、assert三个核心考点。笔试里遇到pytest相关的题基本都能往这个框架上靠。4.3 Java接口自动化与数据驱动框架分层怎么答热搜词里“java接口自动化测试框架”出现了多次试卷A如果考服务端测试简答题很可能会问“你如何设计一个接口自动化测试框架”。这类题不要一上来就堆工具名TestNG、RestAssured、Allure、Maven、Jenkins而是要讲清楚框架的分层思想。我常用的答法是四层结构数据层测试数据用Excel、YAML或者JSON管理执行用例时动态读取。接口层封装每一个业务接口的请求方法、请求头、鉴权逻辑用例不直接操作HTTP请求。用例层用TestNG或JUnit组织用例通过数据驱动把数据层的数据灌进接口层。报告层用Allure生成测试报告配合Jenkins定时构建失败用例能自动截图和记录请求响应。另外还要提两个工程化细节。一是接口依赖处理登录接口返回的token要自动提取并传给后续业务接口可以用TestNG的dependsOnMethods或把token存放在上下文变量里。二是断言设计不仅要断言HTTP状态码还要断言业务状态码和关键字段比如创建一个订单后返回的orderId不能为空订单金额要和入参一致。这个框架本身不难难的是把“为什么这么设计”说清楚。笔试里你只要把“数据驱动”“用例分层”“依赖处理”“可读报告”这四个关键词讲透面试官就知道你真做过而不是只会背概念。4.4 Linux、数据库与网络基础送分题也不能丢这部分通常是试卷A里性价比最高的题难度不大但涵盖范围广。Linux面试题测试在热搜词里排得很靠前说明确实有大量候选人会在基础题上翻车。Linux必背命令清单查看进程ps -ef、top查看日志tail -f、grep查看端口和连接数netstat -an、ss -lntp查看内存free -m、vmstat磁盘df -hadb相关adb devices、adb logcat、adb shell dumpsys数据库题最常考的是SQL查询和事务概念。结合途虎的业务订单表 门店表的关联查询是高频场景。比如“统计每个门店的订单量”就需要用GROUP BY和COUNT再加一个JOIN把门店名称带出来。还有一类题考索引和事务比如索引为什么能加快查询、事务的ACID特性、事务隔离级别、脏读不可重复读幻读的区别。这些基础概念我建议提前过一遍笔试时别花时间现场推。网络协议部分HTTP状态码是必考项。200、301、302、400、401、403、404、500、502、504每一个都要知道代表什么。接口题里经常会问GET和POST的区别别只说“GET是查、POST是增”要从幂等性、参数位置、缓存机制几个角度去答。弱网测试一般会提到Charles或Network Link Conditioner核心是模拟弱网环境下客户端的行为看有没有合理的超时提示和重试机制。5. 两道高性价比题型的完整拆解5.1 “订单下了但没收到核销码”线上问题排查类场景题试卷A的综合场景题里有一类特别典型线上用户报障“下单成功但是没收到短信核销码”让你作为测试工程师给出排查思路。这类题目不是让你马上定位Bug而是考察你有没有完整的排查链路意识。我当时是这样拆的第一层确认问题范围。先判断是单个用户问题还是大面积问题。如果只有零星几个用户反馈优先怀疑用户手机号拦截、短信服务商下发失败如果大量用户同时反馈就要优先怀疑短信网关挂了、订单系统或消息队列出问题。第二层从订单状态入手。去订单中心查这单的实际状态是已经支付但短信没发还是支付状态本身没更新。很多情况下短信不是“发了但没到”而是订单状态卡在“未支付”根本不会触发发短信动作。这一层能直接区分是支付链路问题还是短信链路问题。第三层查日志和接口调用链。看App下单请求是否成功、支付回调是否正常到达服务端、短信服务有没有收到下发请求、第三方短信网关返回的状态码是什么。每一步打通就能定位到具体卡点。第四层考虑逆向场景。用户是不是在支付后很快关闭了App导致前端状态没刷新或者用户换了手机号短信发到旧手机号去了甚至可能是用户把短信App拦截了。这些都是现实中很常见的案例。这套思路放在答案里得分点在于“先确认范围、再查状态、再查链路、最后看逆向场景”这四步的逻辑顺序。很多候选人一上来就说“让开发查日志”完全体现不出测试的价值。5.2 “在线预约保养功能”的测试用例设计一个可以直接套用的答题模板试卷A里很可能出现类似这样一道用例设计题“针对途虎养车App在线预约保养功能请设计测试用例。”这类题开放性很强拿满分不容易但要拿大部分分数是有一套固定套路的。我常用的答题框架是五层拆解第一层业务规则校验。预约必须选择门店、服务项目、到店时间到店时间不能早于当前时间同一辆车同一时间段不能重复预约保养套餐和车型要匹配。第二层功能流程校验。正常预约流程能走通预约成功后能收到通知用户能修改预约时间用户能取消预约取消后库存和技师排期要释放。第三层异常与边界校验。选择不存在的门店ID到店时间填昨天车辆VIN码格式错误优惠券使用条件不满足网络中断后重试。第四层状态与后端一致性。预约成功后订单状态变为“已预约”取消成功后状态变为“已取消”支付环节如果有定金在回调成功前不能改变预约状态门店端能看到用户预约单并完成接单。第五层非功能测试。弱网下页面加载和提交响应门店列表分页加载性能高并发预约时会不会出现同一时段被超卖。这个模板的好处是维度全、逻辑清晰不管遇到什么业务功能把业务规则、功能流程、异常边界、状态一致性、非功能测试这五层套上去都能写出像模像样的答案。当然具体测试点要结合题目给的业务细节调整不能照搬名词但框架是可以通用的。6. 复盘后的避坑清单与复习建议6.1 笔试中最常见的五个失分点结合我自己做试卷A和后来帮朋友辅导的经验测试笔试的失分点高度集中在这里统一列出来。第一个失分点是审题不清。题目要求“写出测试点”很多人洋洋洒洒写了操作步骤结果没得分。操作步骤是“怎么操作”测试点是“验证什么”两者有本质区别。答题前一定要看清题目问的是测试用例、测试点还是排查思路。第二个失分点是术语不严谨。把缺陷状态说成“没改好”把严重程度和优先级混为一谈把“回归测试”说成“重新测一遍”。这些问题在笔试里会显得非常不专业。建议把缺陷生命周期、严重程度致命/严重/一般/轻微、优先级紧急/高/中/低这些概念提前吃透。第三个失分点是自动化停留在背概念。笔试里让你手写一段pytest或Appium脚本时很多人一句都写不出来。自动化不是背熟名词就行的必须真在本地装环境、跑过脚本、踩过坑才能在笔试和面试里说得有底气。第四个失分点是业务理解不足。一个功能给你你只写得出“正向流程能用”却想不到库存、支付、退款、状态一致性、门店排期这些异常场景。尤其投途虎这种有线下业务的平台业务理解几乎是必考题。平时可以多体验一下产品把自己代入真实用户、门店技师、平台运营三种角色去拆解。第五个失分点是时间分配不当。选择题和简答题纠结太久导致全程最值钱的用例设计题草草应付。笔试不是考试时间越久分越高而是要把时间花在得分密度最高的题目上。6.2 针对后续候选人的复习建议如果你还有一到两周才笔试我的建议是分三步走。第一步花一天时间过测试基础理论重点是等价类、边界值、场景法、因果图、错误推测法以及V模型、冒烟测试、回归测试、探索性测试这些概念。第二步花三到四天过工具链Python和pytest必须能写简单脚本Appium只要理解核心配置和定位方式就行Java接口自动化框架至少能画出分层图SQL查订单表语句要熟练。第三步也是很多人忽略的一步花半天时间专门研究途虎App。把App从头到尾走一遍从注册登录、选择服务、预约门店、下单支付、到店核销、评价晒单每一步都问问自己“如果这里出问题可能是什么原因”。做完这一步再去看笔试里的业务题你会发现题目突然没那么抽象了。我做完试卷A最大的感受是这类垂直行业的测试笔试越来越不吃“死背书”那一套了。它考的不只是你会不会测而是你能不能站在业务的角度理解这个系统是怎么运转的。掌握正确的分析方法永远比多背几个名词有用。
2023年秋招那段时间我一直在牛客和招聘官网之间来回刷测试岗机会看到途虎养车放出2023秋招测试笔试试卷A的时候我第一时间就投了。整套题做完最大的感受是它和纯互联网大厂的数理题、性格测试完全不是一回事途虎的笔试卷是带着业务基因的——你能明显感觉到它要招的不是一个只会写用例、点点点的测试而是能理解汽车后市场O2O链路、能扛住移动端和门店系统双重质量压力的测试工程师。这篇文章我按记忆梳理一下试卷A的整体面貌包括命题逻辑、题型分布、高频考点、自动化工具题怎么答、用例设计题怎么拆以及最后给我的复盘和复习建议。如果你正准备投途虎测试岗这篇可以帮你少走不少弯路如果你只是对汽车后市场这类垂直行业的测试感兴趣也能从里面看到这类公司到底在笔试环节筛选什么样的人。1. 试卷A到底在考什么从途虎的业务版图反推命题逻辑1.1 途虎测试岗要解决的不只是一个App而是一整条O2O链路做笔试题之前我习惯先花两分钟想清楚一件事这家公司靠什么赚钱测试的边界在哪里命题人会优先关心什么。途虎养车不是纯互联网平台也不是单纯的门店连锁它的核心模式是汽车后市场的线上线下一体化——用户在App或小程序上选轮胎、买保养套餐、预约到店时间然后去线下门店完成安装和维修中间还夹着供应链、仓储、物流、订单、支付、核销、评价一整条链路。这意味着途虎的测试对象覆盖得很杂用户端途虎养车AppiOS / Android、微信小程序、H5页面门店端门店管理后台、技师使用的接单/核销工具甚至还有扫码枪、PDA这类桌面或移动设备服务端订单中心、支付中心、库存中心、优惠券/营销系统、会员体系数据与风控活动防刷、异常订单识别、评价内容审核硬件与车载相关胎压监测设备、车辆检测设备以及和车联网、智能座舱相关的合作项目所以试卷A的命题逻辑其实很清晰它希望候选人既有通用测试功底又能看懂业务场景并且能把这些场景转化成测试用例。很多候选人笔试挂掉不是死在理论题上而是死在不理解“为什么途虎要考这种业务场景”。1.2 试卷A的三条主线通用测试功底、移动端质量、业务场景分析整套卷子在我脑海里可以大致归成三条主线。第一条是通用测试功底。用例设计方法、测试流程、缺陷管理、V模型、冒烟测试和回归测试的概念这类题目无论哪家测试笔试都会出现途虎也不例外。它是用来筛选“有没有基本测试思维”的底层题。第二条是移动端质量保障。途虎App是整个C端业务的核心入口用户从浏览商品到下单支付全都在移动端完成所以移动端测试、Appium自动化、弱网、兼容性这些相关概念在试卷里占比不低。第三条是业务理解和场景分析这是最拉分的一块。同样一个“下单”功能你能不能想到多门店、库存不足、支付回调延迟、定位超出门店服务范围、退款逆向流程这些真实场景试卷A的简答题和综合场景题基本都在验证这种能力。这三条主线不是割裂的而是互相穿插的。比如一道用例设计题表面考你是不会用等价类和边界值实际上还考你能不能把途虎的业务规则套进去。后面我会拿一道典型的题目拆开讲。2. 题型结构与时间分配拿到试卷A后我这样安排答题节奏2.1 常见题型分布与分值印象试卷A我印象里是60到90分钟的限时笔试整体题量适中但题与题之间的分值差距很大。我根据记忆整理了一份大致的题型分布不一定精确但结构上可以给后面的人一个参考题型大致题量分值占比考查重点单选题 / 多选题 / 判断题15-25题20%-30%测试理论、Linux命令、网络、数据库、自动化基础概念简答题3-5题20%-25%冒烟测试理解、V模型流程、接口测试与UI测试区别用例设计题1-2题25%-35%结合业务场景设计测试用例等价类、边界值、场景法代码 / 脚本题0-2题10%-15%简单SQL、Python脚本、自动化用例片段补全综合场景题1题10%-15%线上问题排查、缺陷分析、测试计划制定思路这套结构最大的特点是选择题只是门槛真正的分值集中在用例设计和综合场景题上。很多人在选择题上过于纠结结果到用例设计题时只剩十几分钟这是笔试的大忌。2.2 做题顺序和时间控制我的建议是拿到试卷先看一遍简答题、用例设计题和综合场景题做到心里有数再决定怎么分配时间。如果时间紧张优先级应该是用例设计题 综合场景题 简答题 选择题 代码题。为什么这么排因为用例设计题和综合场景题是按得分点给分的你写出一个有效测试点就有一个点的分哪怕最后结论不够完美也能拿一部分分。而选择题只有对和错不会就是不会再花时间也蒙不出来。我当时给自己定的节奏是这样的选择题15分钟简答题15分钟用例设计和综合场景题35分钟剩下5到10分钟检查。如果某道选择题卡了超过1分钟直接标记跳过等回头有时间再补。这套节奏在后面的秋招里也帮我稳住了不少笔试。3. 高频考点逐个击破从测试理论到汽车后市场业务3.1 用例设计方法等价类、边界值、场景法的答题姿势用例设计是测试笔试的必修课试卷A里不可能没有。考法通常是给一个功能描述要求“设计测试用例”或者“写出至少8-10个测试点”然后看你有没有用到等价类、边界值、场景法这些方法。很多新人的错误是把用例设计写成操作步骤比如“点击登录按钮输入账号密码点击确认”这只能算操作流程不是测试用例。正确的答法是先划分测试对象的状态和维度再逐条列出“前置条件 操作步骤 预期结果”。举个例子如果题目是“途虎养车App的注册登录功能”我会从这些维度拆输入校验手机号格式、验证码长度、密码复杂度、重复手机号异常场景验证码错误、验证码过期、网络中断、多次点击发送验证码状态流转未注册手机号自动注册、已注册手机号直接登录、第三方账号绑定安全与权限登录态失效、异地登录提醒、隐私协议确认兼容性不同品牌手机、不同分辨率、不同系统版本这样写出来的用例不仅量够而且覆盖了功能、异常、安全、兼容多个层面面试官一眼就能看出你有测试思维。笔试里如果能用等价类把输入范围分组再用边界值把“刚好通过”和“刚好不通过”的临界值补上这道题基本就稳了。3.2 测试流程与模型V模型、冒烟测试、回归测试怎么考试卷A里关于测试流程的题一般不会太难但特别容易踩概念坑。比如简答题问“请简述冒烟测试和回归测试的区别”大部分人能说上两句但要说得准确必须抓住本质。冒烟测试的对象是“新版本的核心功能”它的目的是在正式测试开始之前快速验证主流程能不能跑通。如果冒烟都过不了说明这个版本质量差到没有继续测的必要直接打回给开发。回归测试的对象是“之前已经测试过的老功能”它的目的是确认本次代码改动没有破坏原有功能。通俗地说冒烟测试是“新版本能不能开机”回归测试是“改动之后旧功能有没有坏”。V模型在试卷里的考法也很有意思不是让你背“需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试”这条链而是让你说出“测试为什么要尽早介入”。我看到这道题的时候第一反应是引用V模型里测试阶段和开发阶段的对应关系然后补一句需求阶段的缺陷如果拖到系统测试才发现修复成本会呈指数级上升。这种回答比单纯背流程要有血有肉得多。3.3 途虎App业务链路状态机、支付回调、线下履约这部分算是试卷A真正的分水岭。同样是“下单”功能纯互联网公司的测试用例关注的是购物流程是否顺畅、优惠是否计算正确而途虎这种O2O模式下测试用例还多了一条线下履约链路。我印象里试卷A里有相当一部分业务场景题都是围绕“订单”和“门店”展开的。比如用户从App下单购买轮胎选择门店并预约安装时间支付成功后到店核销技师完成安装后订单状态变化用户评价后整个流程闭环。这里面最值得提前准备的是订单状态机。订单状态可能会拆成这些节点未支付 → 已支付 → 已预约 → 服务中 → 已完成 → 已评价中间还挂着取消、退款、售后的分支。测试时不能只测这条主链路还要测异常分支未支付订单超时自动关闭、支付成功后回调迟迟没返回、门店临时闭店导致预约失败、用户到店但技师排期已满、配件库存不足触发退款。还有一个高频考点是支付回调的幂等性。用户付了钱但支付网关的回调消息因为网络原因发了好几次如果服务端处理逻辑没有做好幂等用户账户可能被重复扣款订单也可能被重复置为已支付。笔试里遇到这类题不管题目怎么包装核心答案就一句话服务端要保证同一笔订单同一笔支付结果无论回调多少次最终的业务状态只有一次变更。线下履约环节还经常会和定位、权限关联起来。用户选择门店时App会申请定位权限这时要考虑用户拒绝授权怎么办、GPS信号弱怎么办、门店服务范围和用户实际位置不符怎么办。这些细节在有线下场景的公司里都是真实会出现的Bug写在试卷上就是很好的加分项。3.4 车载与智能座舱相关没有车联网经验该怎么答热搜词里大量出现了车载测试、智能座舱测试、汽车电子测试这也符合途虎所在行业的大背景。即便2023秋招试卷A里车载相关题目占的比重不算特别大但完全不准备也会吃亏尤其是简答题里如果出现“智能座舱测试和手机App测试有什么不同”很多人会卡壳。我当时是从测试思维迁移的角度来答的。不管是手机App还是智能座舱功能测试、性能测试、兼容性测试、稳定性测试这些底层逻辑没有变变的只是被测对象和场景差异。智能座舱多了语音交互、多屏联动、车载地图、倒车影像、蓝牙连接、驾驶员监控这些车载特有功能稳定性要求更高因为车机系统在高温、震动、强光环境下要持续稳定运行安全要求更严格因为任何误触或系统卡死都可能影响行车安全。如果你没有车载背景至少要把“稳定性测试”“长时运行老化测试”这个概念理解透。试卷A或者面试中一旦出现“设备老化测试全自动执行脚本”这类题它本质上考的是你怎么设计自动化脚本去模拟设备长时间运行、监控内存和CPU泄漏、在异常发生后自动恢复并记录日志。这类题的答题框架我放在后面自动化章节里讲。3.5 安全与性能渗透测试、连接数、老化测试这些延伸考点安全测试和性能测试在试卷A里属于“不做重点但必须知道”的考点。选择题里可能会出现SQL注入、XSS跨站脚本、越权访问、验证码安全问题简答题里可能会问“接口测试时如何保证安全性”。对途虎这类有支付和用户资产的平台支付接口的签名校验和越权防护是安全测试的重中之重。笔试里出现“支付订单金额被篡改”“用户A通过改接口参数查看用户B订单”这类题考察的就是你有没有越权测试的概念。我的答法是先说明越权分水平越权和垂直越权再给两条验证思路水平越权是同一角色去访问其他同级别用户的数据垂直越权是低权限用户去访问高权限接口。然后补一句“在接口测试用例里必须覆盖不同角色、不同用户的ID替换场景”这道题就能拿个不错的分数。性能方面结合途虎的业务场景最值得答的是大促和预约高峰。每年双十一、618或者平台大促节点瞬间涌进来大量用户抢优惠券、下单、预约门店这时候服务端能不能扛住并发连接数接口响应时间会不会明显变长数据库会不会出现连接池打满这些都是性能测试要关注的点。试卷里如果问“线上出现大量用户下单后订单状态长时间不更新你作为测试怎么排查”不要只答功能Bug要从服务端日志、数据库慢查询、消息队列积压、支付回调延迟多个维度去拆。4. 自动化与工具链考点Appium、pytest、接口自动化框架怎么考4.1 Appium移动端自动化最容易考的几个点2023年的测试笔试自动化工具早就不只是选择题里的名词解释了试卷A里已经出现“给一段Appium配置让你判断哪里写错”这类题。Appium的核心是基于WebDriver协议通过iOS的XCUITest和Android的UIAutomator2驱动原生应用所以跨平台是它最大的卖点。笔试里Appium的高频考点主要有这几个Desired Capabilities配置platformName、platformVersion、deviceName、appPackage、appActivity必须配对appPackage填错直接导致session创建失败。元素定位优先使用resource-id、accessibility id、content-desc少用xpath。xpath在Appium里不是不能用而是解析成本高、页面结构一变就容易挂笔试如果问“为什么定位不稳定”答案基本都落在这一条。等待机制显式等待、隐式等待、强制sleep三者之间的区别。最不该用的就是强制sleep固定等几秒既浪费时间又容易因为设备卡顿产生误报显式等待配合ExpectedConditions去做元素出现判断才是稳定性的保证。我当时在笔试里遇到一道题问“Appium脚本在低配手机上跑经常失败你怎么排查”。我的思路是先看是不是等待时间不够导致元素未出现再看是不是网络或页面加载慢最后看设备是否开启了GPU渲染必要时改用更稳定的定位策略并增加重试机制。这种题没有标准答案但逻辑完整就能得分。4.2 pytest从fixture到参数化别只背概念pytest在热搜词里排得很靠前试卷A里的代码题如果出现Python大概率绕不开pytest。笔试题型通常是补全一段测试用例或者让你看一段有Bug的fixture代码找错。准备pytest我建议把下面这几个点彻底弄明白fixture的作用它是测试前置条件的复用机制比如初始化数据库连接、构造测试数据、启动被测服务。fixture的scope参数function、class、module、session决定了它的生命周期。conftest.py公共fixture放在这个文件里同一目录和子目录下的测试用例都能自动引入不用每个文件重复import。参数化pytest.mark.parametrize用来做数据驱动一组参数跑一遍用例。比如登录接口传入不同账号密码组合一个用例函数就能覆盖正常、密码错误、账号不存在多条场景。断言机制直接用assert关键字pytest会自动收集断言失败信息不需要像unittest那样调用self.assertEqual。很多候选人会背pytest的概念但一到写代码就露怯。我建议准备笔试的时候至少能手写一个简单的fixture加参数化用例不需要多高深但语法要规范。我当时背下来的一个最小模板是import pytest pytest.fixture def user_token(): # 模拟登录后获取token return test_token pytest.mark.parametrize(order_id, expected_code, [ (1001, 200), (1002, 404), ]) def test_order_query(user_token, order_id, expected_code): # 这里是调用接口的简化逻辑 assert query_order(user_token, order_id) expected_code这个模板虽然简单但已经覆盖了fixture、parametrize、assert三个核心考点。笔试里遇到pytest相关的题基本都能往这个框架上靠。4.3 Java接口自动化与数据驱动框架分层怎么答热搜词里“java接口自动化测试框架”出现了多次试卷A如果考服务端测试简答题很可能会问“你如何设计一个接口自动化测试框架”。这类题不要一上来就堆工具名TestNG、RestAssured、Allure、Maven、Jenkins而是要讲清楚框架的分层思想。我常用的答法是四层结构数据层测试数据用Excel、YAML或者JSON管理执行用例时动态读取。接口层封装每一个业务接口的请求方法、请求头、鉴权逻辑用例不直接操作HTTP请求。用例层用TestNG或JUnit组织用例通过数据驱动把数据层的数据灌进接口层。报告层用Allure生成测试报告配合Jenkins定时构建失败用例能自动截图和记录请求响应。另外还要提两个工程化细节。一是接口依赖处理登录接口返回的token要自动提取并传给后续业务接口可以用TestNG的dependsOnMethods或把token存放在上下文变量里。二是断言设计不仅要断言HTTP状态码还要断言业务状态码和关键字段比如创建一个订单后返回的orderId不能为空订单金额要和入参一致。这个框架本身不难难的是把“为什么这么设计”说清楚。笔试里你只要把“数据驱动”“用例分层”“依赖处理”“可读报告”这四个关键词讲透面试官就知道你真做过而不是只会背概念。4.4 Linux、数据库与网络基础送分题也不能丢这部分通常是试卷A里性价比最高的题难度不大但涵盖范围广。Linux面试题测试在热搜词里排得很靠前说明确实有大量候选人会在基础题上翻车。Linux必背命令清单查看进程ps -ef、top查看日志tail -f、grep查看端口和连接数netstat -an、ss -lntp查看内存free -m、vmstat磁盘df -hadb相关adb devices、adb logcat、adb shell dumpsys数据库题最常考的是SQL查询和事务概念。结合途虎的业务订单表 门店表的关联查询是高频场景。比如“统计每个门店的订单量”就需要用GROUP BY和COUNT再加一个JOIN把门店名称带出来。还有一类题考索引和事务比如索引为什么能加快查询、事务的ACID特性、事务隔离级别、脏读不可重复读幻读的区别。这些基础概念我建议提前过一遍笔试时别花时间现场推。网络协议部分HTTP状态码是必考项。200、301、302、400、401、403、404、500、502、504每一个都要知道代表什么。接口题里经常会问GET和POST的区别别只说“GET是查、POST是增”要从幂等性、参数位置、缓存机制几个角度去答。弱网测试一般会提到Charles或Network Link Conditioner核心是模拟弱网环境下客户端的行为看有没有合理的超时提示和重试机制。5. 两道高性价比题型的完整拆解5.1 “订单下了但没收到核销码”线上问题排查类场景题试卷A的综合场景题里有一类特别典型线上用户报障“下单成功但是没收到短信核销码”让你作为测试工程师给出排查思路。这类题目不是让你马上定位Bug而是考察你有没有完整的排查链路意识。我当时是这样拆的第一层确认问题范围。先判断是单个用户问题还是大面积问题。如果只有零星几个用户反馈优先怀疑用户手机号拦截、短信服务商下发失败如果大量用户同时反馈就要优先怀疑短信网关挂了、订单系统或消息队列出问题。第二层从订单状态入手。去订单中心查这单的实际状态是已经支付但短信没发还是支付状态本身没更新。很多情况下短信不是“发了但没到”而是订单状态卡在“未支付”根本不会触发发短信动作。这一层能直接区分是支付链路问题还是短信链路问题。第三层查日志和接口调用链。看App下单请求是否成功、支付回调是否正常到达服务端、短信服务有没有收到下发请求、第三方短信网关返回的状态码是什么。每一步打通就能定位到具体卡点。第四层考虑逆向场景。用户是不是在支付后很快关闭了App导致前端状态没刷新或者用户换了手机号短信发到旧手机号去了甚至可能是用户把短信App拦截了。这些都是现实中很常见的案例。这套思路放在答案里得分点在于“先确认范围、再查状态、再查链路、最后看逆向场景”这四步的逻辑顺序。很多候选人一上来就说“让开发查日志”完全体现不出测试的价值。5.2 “在线预约保养功能”的测试用例设计一个可以直接套用的答题模板试卷A里很可能出现类似这样一道用例设计题“针对途虎养车App在线预约保养功能请设计测试用例。”这类题开放性很强拿满分不容易但要拿大部分分数是有一套固定套路的。我常用的答题框架是五层拆解第一层业务规则校验。预约必须选择门店、服务项目、到店时间到店时间不能早于当前时间同一辆车同一时间段不能重复预约保养套餐和车型要匹配。第二层功能流程校验。正常预约流程能走通预约成功后能收到通知用户能修改预约时间用户能取消预约取消后库存和技师排期要释放。第三层异常与边界校验。选择不存在的门店ID到店时间填昨天车辆VIN码格式错误优惠券使用条件不满足网络中断后重试。第四层状态与后端一致性。预约成功后订单状态变为“已预约”取消成功后状态变为“已取消”支付环节如果有定金在回调成功前不能改变预约状态门店端能看到用户预约单并完成接单。第五层非功能测试。弱网下页面加载和提交响应门店列表分页加载性能高并发预约时会不会出现同一时段被超卖。这个模板的好处是维度全、逻辑清晰不管遇到什么业务功能把业务规则、功能流程、异常边界、状态一致性、非功能测试这五层套上去都能写出像模像样的答案。当然具体测试点要结合题目给的业务细节调整不能照搬名词但框架是可以通用的。6. 复盘后的避坑清单与复习建议6.1 笔试中最常见的五个失分点结合我自己做试卷A和后来帮朋友辅导的经验测试笔试的失分点高度集中在这里统一列出来。第一个失分点是审题不清。题目要求“写出测试点”很多人洋洋洒洒写了操作步骤结果没得分。操作步骤是“怎么操作”测试点是“验证什么”两者有本质区别。答题前一定要看清题目问的是测试用例、测试点还是排查思路。第二个失分点是术语不严谨。把缺陷状态说成“没改好”把严重程度和优先级混为一谈把“回归测试”说成“重新测一遍”。这些问题在笔试里会显得非常不专业。建议把缺陷生命周期、严重程度致命/严重/一般/轻微、优先级紧急/高/中/低这些概念提前吃透。第三个失分点是自动化停留在背概念。笔试里让你手写一段pytest或Appium脚本时很多人一句都写不出来。自动化不是背熟名词就行的必须真在本地装环境、跑过脚本、踩过坑才能在笔试和面试里说得有底气。第四个失分点是业务理解不足。一个功能给你你只写得出“正向流程能用”却想不到库存、支付、退款、状态一致性、门店排期这些异常场景。尤其投途虎这种有线下业务的平台业务理解几乎是必考题。平时可以多体验一下产品把自己代入真实用户、门店技师、平台运营三种角色去拆解。第五个失分点是时间分配不当。选择题和简答题纠结太久导致全程最值钱的用例设计题草草应付。笔试不是考试时间越久分越高而是要把时间花在得分密度最高的题目上。6.2 针对后续候选人的复习建议如果你还有一到两周才笔试我的建议是分三步走。第一步花一天时间过测试基础理论重点是等价类、边界值、场景法、因果图、错误推测法以及V模型、冒烟测试、回归测试、探索性测试这些概念。第二步花三到四天过工具链Python和pytest必须能写简单脚本Appium只要理解核心配置和定位方式就行Java接口自动化框架至少能画出分层图SQL查订单表语句要熟练。第三步也是很多人忽略的一步花半天时间专门研究途虎App。把App从头到尾走一遍从注册登录、选择服务、预约门店、下单支付、到店核销、评价晒单每一步都问问自己“如果这里出问题可能是什么原因”。做完这一步再去看笔试里的业务题你会发现题目突然没那么抽象了。我做完试卷A最大的感受是这类垂直行业的测试笔试越来越不吃“死背书”那一套了。它考的不只是你会不会测而是你能不能站在业务的角度理解这个系统是怎么运转的。掌握正确的分析方法永远比多背几个名词有用。
