我最近参与了几场测试岗面试，有一幕印象特别深。候选人简历上写着熟悉自动化测试、接口测试、性能测试，看起来准备得很充分。结果我问了一句“你觉得测试核心是什么”，对方愣了几秒，然后说：“测试就是找bug，尽量多找一些。”这个回答不能算错，但在面试官这里，基本就拿不到offer了。因为“测试核心”不是一道名词解释题，而是一道考察测试思维的开放题。你如果说不清自己到底在验证什么、用什么方法验证、验证完怎么判断质量，那后面聊再多的工具和框架，都是悬空的。
这篇文章不吐槽候选人，也不列什么标准答案。我想把“测试核心”这件事拆开讲清楚：面试官到底在问什么，候选人怎么回答能加分，以及真正想入行或进阶的人，该按什么顺序补齐能力。不管你是刚准备面测试岗，还是已经在测试行业里做了两年想跳槽，下面这些内容都可以对照着自查一遍。
1. 面试官说的“测试核心”，到底在问什么
1.1 不是让你背定义，而是看你的第一反应
“测试核心”这个问题，经常出现在面试开场，或者聊完简历之后突然抛出来。它看起来像一道理论题，实际上是一个压力测试。
面试官想看的，不是你背过哪本书的定义，而是你在没有准备的情况下，怎么拆解一个抽象问题。你如果第一反应是“找bug”，说明你的测试认知还停留在“执行”层面；如果第一反应是“保证质量”，也有点空；如果第一反应是“用户需求、质量风险、测试策略、用例设计、缺陷闭环、上线判断”，那面试官基本会愿意继续往下聊。
我后来复盘过这类面试。很多候选人不是不懂测试，而是从来没有把测试当成一个完整的工程流程。他们会写用例，会提bug，也会跑回归，但你要他跳出单个任务，站在整个项目角度讲测试，他就讲不清楚了。这就像一个人会熟练地切菜、炒菜，但你问他“一家餐馆的后厨核心是什么”，他可能只回答“把菜做熟”，却忘了还有备菜流程、成本控制、食品安全、出餐节奏和顾客口味管理。
所以面试官问“测试核心”，真正想听的是：你怎样理解测试在研发流程中的位置，怎样把测试目标拆成可执行的动作，又怎么用测试结果支持上线决策。这不是一个标准答案，而是一套思考框架。
1.2 测试核心可以拆成五层
我一般会建议候选人把“测试核心”理解成五层。每一层都能对应到具体工作，而不是一个空泛口号。
第一层是质量目标。需求要解决什么问题，用户最不能接受什么。比如一个登录功能，用户不能接受的是账号密码正确却登不进去，也不能接受密码泄漏。质量目标不同，测试重点完全不同。如果目标是“让用户快速进入系统”，那性能测试和弱网测试就要跟上；如果目标是“保证账号安全”，那安全测试和权限验证就不能少。
第二层是测试策略。根据质量目标和风险，决定先测什么、用什么方式测、测到什么程度。风险高的功能多投入，稳定模块做回归，核心链路必须自动化。这一步最能体现测试人员的经验，因为策略不是写死在用例模板里的，而是每次都不一样。
第三层是用例设计。把测试目标转成具体的输入、操作、预期结果和数据准备。这里不是把所有情况都列一遍，而是用等价类、边界值、场景法等方法选出最有代表性的用例。比如一个搜索框，你不可能把所有关键词都试一遍，但你可以把输入分成正常词、空词、超长词、特殊字符、相同词频繁搜索等几类。
第四层是缺陷闭环。发现缺陷之后，要能清晰描述、跟踪、回归，并推动开发修复。缺陷不是提完就结束，关闭之前要确认真的修好，并且没有引入新的问题。这个环节如果做不好，测试的价值就会大打折扣。
第五层是质量结论。测试执行完之后，要能给项目组一个判断：可不可以上线，还存在哪些遗留风险，哪些问题可以接受，哪些必须解决。这一层才是测试核心中的核心。
这五层是一层套一层的。面试时讲到其中任何一层，都要能举出一个自己亲手做过的例子。比如你说自己懂测试策略，就要能回答：上一个项目里，你是怎么判断哪个模块最重要的。
2. 测试用例设计：一道登录题就能看出水平
2.1 最容易翻车的答法
测试用例设计是测试岗面试绕不开的基础题。最常见的一道是：给你一个登录框，你会怎么测。
很多候选人会这样答：输入正确的账号密码，能登录成功；输入错误的账号密码，提示失败；不输入的时候，提示必填。如果只答到这里，面试官基本就知道，你平时做测试可能偏重于“手工点一遍”。
问题不在于答得少，而在于没有优先级，没有数据准备，没有考虑异常和边界。登录框虽然简单，但它背后涉及输入校验、会话管理、接口调用、数据库查询、安全防护、前端交互，每一个环节都可能出错。你只答“正确能登录，错误提示”，说明你只看到了用户界面，没有看到整个系统。
更麻烦的是，很多候选人会陷入“我说得越多越好”的状态，把自己能想到的几十条用例一口气全背出来。结果面试官问一句“如果时间只有半天，你优先测哪几条”，他又答不上来。这说明他只是在背测试点，没有做排序和取舍。测试用例设计的能力，从来不是数量堆出来的，而是你能不能把有限的测试资源放在最关键的地方。
2.2 一个能拿分的作答框架
我会建议候选人按下面的顺序组织回答，一边讲一边露出思考过程。
先说核心功能：正确的账号和密码，点击登录，进入首页。这是最基础的一条，必须保证。
再说异常输入：账号为空、密码为空、账号不存在、密码错误、密码连续输错多次。每条都要说清楚预期提示是什么，连续输错有没有锁定或验证码策略。这些不是随便想出来的，而是在还原用户常见操作路径。
接着是边界：密码最短几位、最长几位，只差一个字符时能不能登录，账号是否区分大小写，输入前后带空格怎么处理。边界值是测试用例设计里最容易被忽略的一块，但面试官很喜欢在这里追问。你如果能主动提到“密码长度为8到20位，那我至少要测8位、20位、7位、21位”，面试官会立刻觉得你有基本功。
然后说安全：输入框是否支持粘贴、是否对特殊字符做处理，前端有没有明文展示密码，接口是否限制频率。这里不需要讲具体攻击方法，只需要表达“我知道登录涉及安全验证”。你还可以提一句：如果密码通过加密传输，我需要在接口层确认字段没有暴露明文。
最后说体验和兼容：不同浏览器、不同操作系统的表现，按钮loading状态，网络断开时的提示，登录成功后跳转是否正常。兼容性和体验不是功能的核心，但作为测试人员，不能完全忽略它们。
这样下来，一道登录题就能答出四五个维度。面试官要的并不是你背出所有用例，而是考察你有没有一套结构化的思考顺序：先核心，再异常，再边界，再安全，再兼容。
2.3 从登录题到一般需求
登录题答完之后，面试官往往会换成另一个功能，比如“测一个文件上传”“测一个搜索框”“测一个购物车”。很多人就卡住了，因为他在背登录题的答案。
正确的做法是把同一个框架迁移过去。不管什么功能，都可以先问：用户要完成的核心动作是什么，失败会怎样，边界有哪些，数据从哪来，结果存到哪去，会不会有多人同时操作，依赖的外部服务是否稳定。
以文件上传为例，核心动作是选择文件、上传、显示成功；异常动作是文件过大、格式不支持、上传中断、重复上传；边界是允许的最大文件、最小文件、空文件；数据层面要去检查上传后文件是否落库、路径是否正确、大小是否匹配；并发层面要考虑多人同时上传会不会慢；体验层面要看上传进度条和取消按钮是否正常。
这套迁移能力，比记住某个功能的用例重要得多。面试官听到你能把“登录”的思路迁移到“上传文件”，就会认为你具备测试设计能力，而不是只做过某个模块。
3. 自动化测试：会跑脚本不等于会测试
3.1 先回答“为什么要自动化”
测试岗面试基本都会问自动化。很多人一上来就说：我会用Selenium，会用Appium，会用Postman，会用Pytest。这些工具名堆出来，听起来挺丰富，但面试官只要追问一句“你为什么要用自动化”，很多人就答不上来了。
自动化不是测试的目的，而是手段。它适合解决回归测试、重复性操作、大数据量执行、跨平台执行这类场景。缺点是开发和维护成本高，需求频繁变化时脚本很容易挂。如果你面对一个页面结构每天都在变、需求三天两头改的项目，一上来就铺自动化，最后很可能是每个人都在维护脚本，而不是在测功能。
面试时正确的打开方式是：先讲清楚你面对的任务是什么，为什么需要自动化，再用工具名做补充。比如，“我们项目每周发版，核心流程如果每轮手工回归需要两小时，所以我把登录、下单、支付主流程做成了自动化冒烟脚本，跑一次只要十分钟。”这样工具就不是在裸奔。
3.2 一个最小自动化流程要说清楚什么
自动化测试的面试，不需要你现场写完整代码，但你要能讲清楚一个最小流程：准备数据、执行操作、断言结果、生成报告。
我这里给一个非常简化的伪代码示例，用来表达思路。
def test_login(): # 准备测试数据 username = "valid_user" password = "valid_pass" # 执行登录操作 login_page.input_username(username) login_page.input_password(password) login_page.click_login() # 断言结果 assert home_page.is_visible() == True这段代码简单，但面试时要能解释每个部分背后的考虑。准备数据要独立，不能依赖别人手工造数据；执行操作要加等待条件，不能固定sleep三秒；断言要断言用户真正关心的结果，比如页面跳转、接口返回、数据库状态，而不是只看按钮变了个颜色。
我在实际项目里见过很多自动化用例，明明功能是好的，脚本却经常挂。最后查下来，问题基本都出在三块：元素定位写得太死板，页面稍微改个class就挂；数据没有清理，上一次执行留下的脏数据影响了这一次；断言太弱，只断言“没有报错”，但功能实际没生效。面试时如果能提前想到这些，并且主动讲出来，说明你是真的跑过自动化，不是只跟着教程做了一个demo。
工具只是为了实现这些步骤。面试官更在意你有没有想过：元素定位不到怎么办，测试数据怎么清理，失败后怎么定位是环境还是脚本问题。
3.3 工具可以不用全知道，但不能不知道边界
Appium做移动端自动化，Selenium做Web自动化，Pytest做测试框架，JMeter做接口和性能测试，Fiddler用来抓包和模拟弱网。这些工具都是面试高频词，但不需要你全部精通。面试官考察的是你有没有对工具的边界认知。
比如Appium适合做跨平台的移动端UI自动化，但它对Native和WebView的兼容性不一样；Selenium适合Web界面操作，但对JS渲染页面有时需要额外等待；Pytest是一个测试执行框架，它本身不能帮你做页面操作，需要配合其他工具；JMeter可以做接口压测，但复杂业务协议的模拟能力有限；Fiddler能做弱网模拟，但模拟出来的网络模型和真实弱网环境还是有差距。
面试官更会看你面对一个未知工具时的反应。比如问你“RTMP测试地址是什么”“鼠标回报率测试怎么测”，如果你完全没有接触过，也不用慌。你先猜一下这个测试的对象是什么，输入是什么，输出是什么，用什么方式验证。这种分析能力比“会不会某个工具”更重要。
在真实项目里，工具选择取决于团队技术栈和项目类型。你只要能说清楚自己用过的工具解决了什么问题，以及它的边界在哪里，就已经超过很多背题库的人了。
4. 常见测试方向：功能之外的考察范围
4.1 接口、性能、安全、兼容怎么讲
测试岗面试不会只停留在功能测试，还会问接口、性能、安全、兼容这些方向。不需要你每个方向都是专家，但每个方向至少要有基本认知。
接口测试：关心请求参数、响应结构、异常码、接口鉴权、依赖服务的可用性。很多人只测界面，不知道接口层才是很多问题的根源。面试可以举一个例子：前端把某个字段限制成必填，但接口层没校验，绕过前端就能提交空值。这种问题只有接口测试才能发现。
性能测试：关心并发数、响应时间、吞吐量、资源占用。提到内存测试、连接数测试时，不要只说“压一下”，还要说清楚监控什么指标、多大的压力、多长时间、失败标准是什么。比如连接数测试，要看达到上限后新请求是排队还是直接拒绝，系统有没有重试和降级机制。
安全测试：常规思路是权限验证、越权操作、敏感信息加密、输入校验。渗透测试是更专业的方向，如果面试官问到，你可以表达理解，但不需要深入攻击细节。关键是知道“安全测试不是上线前随便扫一下，而是要从设计阶段就开始考虑”。
兼容测试：硬件、操作系统、浏览器、分辨率、网络环境。面试时讲一个具体项目即可，比如视频播放功能在不同机型上的卡顿和画质差异。不要只说“我们测了安卓和iOS”，要能说清楚具体覆盖了哪些版本、哪些分辨率、遇到哪些典型问题。
4.2 弱网测试和资源测试的常见切入点
现在很多项目是移动端和视频端，弱网测试几乎是必问方向。Fiddler就是常见工具，它可以模拟延迟、丢包、限速。
弱网测试的重点不是“慢一点”，而是看产品在弱网下的表现：有没有超时提示，能不能重试，数据会不会丢失，界面会不会一直转圈。比如直播或视频播放场景，网络波动时应该提示缓冲状态，而不是直接黑屏；恢复网络后，播放进度和缓存应该保持一致。
资源测试也很常见，尤其是长时间运行的项目。设备老化测试全自动执行脚本，这类工作我理解是：设计一批高频场景，定时循环执行，同时监控内存、CPU、温度、电量，发现问题后自动记录日志和截图。面试时如果聊到这类测试，不要只说自己会写脚本，还要说清“跑多久算老化”“哪些指标异常算失败”“结果如何归档”。
内存测试的切入点，一般是长时间操作后，内存占用是否持续上升。你可以说：先跑一个基准用例，记录初始内存；然后重复执行某个功能100次，每10次记录一次；如果内存回收后仍然持续上涨，就要怀疑有内存泄漏。这个思路在App测试里很常见。
网速测试、RTMP测试地址这类词，在视频类项目里会出现。如果面试官问，你至少能想到：测试一个直播地址，要关注首屏时间、延迟、卡顿次数、音画同步、断线重连。有这样的思路，即使没接触过具体工具，也能答出方向。
4.3 结合一个具体功能综合设计测试方案
面试加分项，是能把多个测试方向串起来。比如让你“设计一个视频播放功能的测试方案”，你不要只列播放成功/失败。
我会这样拆：功能层面，验证视频加载、播放、暂停、拖动进度、音量、全屏、清晰度切换；异常层面，验证网络断开、弱网、播放地址过期、视频文件损坏；兼容层面，覆盖不同浏览器、不同手机系统、不同分辨率；性能层面，关注播放启动时间、内存占用、长时间播放是否卡顿；接口层面，验证视频地址获取接口、上报播放日志接口、登录鉴权。
最后还要给一个结论：哪些场景是发布前必须测的，哪些可以放到线上监控。比如核心播放链路必须发布前测完，而某种边缘设备只能覆盖基本场景，剩下靠线上监控和用户反馈。这样答下来，面试官看到的不是一个只会点按钮的测试，而是一个能管理测试范围和风险的人。
5. 缺陷管理和质量判断：真正的核心能力
5.1 缺陷报告怎么写才不会被开发打回
测试执行之外，最容易被低估的是缺陷管理。很多候选人以为提bug就是把现象写一下，结果被开发反复打回，不是“无法复现”，就是“环境问题”。
一份合格的缺陷报告至少要有这些元素：标题写清楚模块、现象和触发条件；环境写清楚版本、系统、设备、网络；步骤要能一步步复现；预期结果和实际结果分开写；日志、截图、视频作为证据；最后标明优先级和出现频率。
我一般会建议，提bug之前自己先复现两遍。如果第二次没复现，也要写清楚“偶现，大概两到三次出现一次”。开发最怕的不是bug多，而是说不清触发条件的bug。你如果能主动把复现步骤精简到最短路径，开发定位起来会快很多，你的bug处理速度也会快很多。
缺陷还有生命周期。从提交、确认、修复、回归到关闭，每一步都要有记录。回归测试时，不仅要验证这个bug本身是否修复，还要看它旁边的功能有没有被影响。比如登录密码错误次数过多，开发改了锁定的逻辑，你不仅要验证锁定是否生效，还要验证正确密码在锁定期内是否也被拒绝，以及解锁时间是否准确。
5.2 开发不认Bug时不只靠吵
面试里经常问：开发说这不是bug，你怎么办。这个问题考察的是沟通能力和验证思路。
你先不要争，回到测试日志和复现步骤里找证据。确认是不是数据问题、环境配置问题、浏览器缓存问题，然后再跟开发对齐。很多时候，开发说“我本地是好的”，并不代表问题不存在，只是他的环境和你的环境不一样。这时候你要把环境差异列出来：版本号、系统配置、数据库数据、账号权限。
如果开发还是不认，可以拉上产品经理一起判断：这个行为是否符合需求预期。如果需求本身就没写清楚，那不是谁对谁错，而是需求缺陷。测试人员的价值就是在这种模糊地带推动决策，而不是自己硬扛。
5.3 决定能不能上线，才是测试核心价值
再回到“测试核心”这个问题。很多人来面试，讲了很久怎么测，但最后没有回答一个问题：你测完以后，怎么判断这个版本能不能上线。
这才是测试区别于“点工”的核心价值。测试要能汇总所有信息：功能通过率、遗留缺陷数量、风险模块、性能数据、兼容范围，最后给出一个明确的结论：建议上线、有条件上线、不建议上线。
有条件上线是什么意思？常见缺陷都修了，个别低概率问题可以接受，但需要线上监控和快速回滚方案。这种判断需要经验，也需要对业务的理解。比如一个下载功能在Windows上有偶现失败，但用户可以通过重试恢复，且影响范围只有1%，那可以带着监控上线；如果崩溃导致数据丢失，就不能接受。
面试时如果你能主动讲一次上线评审会上的判断过程，面试官对你的印象会明显不一样。因为这证明你不是一个只会执行用例的测试，而是真的有质量判断力。
6. 面试现场：怎么回答才像有测试思维
6.1 用“目标-方法-结果”组织回答
面试官问任何测试问题，都可以用“目标-方法-结果”来组织。
先说目标：这个问题要验证的核心价值是什么。再说方法：你准备用哪些测试类型、哪些工具、哪些数据来验证。最后说结果：你怎么判断测试通过，怎么输出结论。
比如问“你怎么测搜索功能”。你不要一上来就列用例。你可以先说，搜索功能的核心目标，是让用户快速找到想要的内容；风险点集中在输入、排序、结果空态、接口性能和异常网络。然后说，我会先用等价类和边界值设计输入用例，再检查搜索接口的返回结果和埋点，再模拟弱网和并发。最后给结论：主路径通过，排序和空态有遗留问题，但影响可控。
这样回答，面试官会认为你有章法。如果没有章法，聊到一半他打断你，你很容易丢掉思路。
6.2 遇到没接触过的测试方向怎么不慌
面试官经常会从项目背景或团队需要里挑一些你没接触过的方向来问。比如“车载测试”“芯片测试”“鼠标回报率测试”“EMC测试”“双脉冲测试”。遇到这些词，最重要的是不要慌。
你先拆对象：被测的是一个软件、一个硬件接口，还是一个网络协议？再拆输入和输出：谁来触发，操作会产生什么结果？然后再拆风险点：哪些环节最容易出问题？最后提出验证方法：用什么工具或流程可以观察、记录、判断。
举个例子，听到“鼠标回报率测试”，哪怕你没测过，也可以推：这是测鼠标向电脑发送数据的频率，回报率越高越跟手。测试时可能需要专门的驱动或软件，查看鼠标在快速移动时的数据上报频率是否稳定。能说出这个推理过程，面试官就知道你有分析未知领域的能力。
遇到专业测试类型，不要假装自己会，要承认没做过，但给出自己的分析思路。面试官更看重诚实和方法论。
6.3 面试官追问时最想看到什么
面试官后面通常会追问，目的是筛掉背题的人。
比如你答“登录成功”之后，他追问“你怎么验证登录成功”。你说“看到页面跳转就行”，这只能算前端断言。更完整的回答是：除了页面跳转，还要看服务端返回的token或session是否生成，数据库中的用户状态是否更新，接口响应时间是否正常。
再比如你说“我做了自动化”，他追问“脚本跑挂了怎么办”。你不能只说“看报错”，要能说：先看日志定位是元素定位失败、网络超时还是服务异常；如果环境问题，跳过并重跑；如果代码问题，修复后回归。
这个环节没有标准答案，但有标准方向：能不能从界面表象，走到数据、日志、接口、服务这些真实证据里去。面试官追得越细，越能看出你平时遇到问题时是怎么思考的。
7. 想补齐测试核心能力，按这个顺序练
7.1 先把功能测试做扎实
如果你是准备入行，或者最近几次面试都被挂了，不要急着去学一堆工具。先把功能测试做扎实。
具体来说，找一款常见软件，比如电商App或视频网站，把注册、登录、搜索、下单、支付、订单查询完整测一遍。每轮都要先拆需求，再写测试用例，然后执行，提bug，最后写一个简单的测试报告。
这个过程会逼你熟悉完整的测试流程。不要觉得简单，很多功能测试做两年的人，也不一定能写清楚一份缺陷报告。你甚至可以拿一个真实App，自己给自己出一份“测试报告”，把环境、范围、用例数、通过率、遗留风险写出来。然后拿给有经验的人看，让他提意见。这个动作比背二十套面试题有效得多。
7.2 再补接口、自动化、环境工具
功能测试熟练以后，再补接口和自动化。
先学抓包工具，学会看请求和响应，理解前端和后端是怎么交互的。再学Linux基础命令和日志查看，因为很多线上问题需要到服务器上看日志。接着学接口测试，会构造请求、断言返回值、处理鉴权。最后再考虑自动化框架，从Pytest或Selenium起步都可以，但一定要写真实项目脚本，不要跟着教程跑demo。
这里有个经验：不要一下子学完所有工具。面试不是工具数量比赛，而是看你能不能把一个工具用明白。如果你能把抓包工具用得很熟，能看到别人看不到的请求字段，这已经是一个很好的亮点。反过来，你每个工具都只是“了解”，面试官问深一点就投降，反而会拉低印象。
7.3 最后再谈性能、安全和测试平台
性能、安全、测试平台这些方向，适合有一定经验后再深入。如果你刚入行，可以把它们放在学习清单的最后，先保证功能和接口测试能独立完成。
性能测试要会用工具，更要会看监控数据。压测的时候，不仅要看TPS和响应时间，还要看CPU、内存、磁盘、网络连接数。安全测试要先理解权限和越权的概念，而不是一上来就学攻击工具。测试平台或自动化平台，更多是效率工程，不是测试核心。
如果你在面试里把每个方向都说得差不多，但细问就露馅，面试官反而会觉得你不够踏实。不如挑一两个方向说深。比如你做过视频测试，就把视频播放、弱网、直播延迟、兼容性这些话说透。
8. 给候选人和面试官的共同建议
8.1 候选人：别只背题，要会拆解问题
现在网上搜“测试面试题”，能搜出几万条。“linux面试题测试”“appium测试”“pytest测试框架”之类的内容非常多。背题当然有短期价值，但如果只背题，面试官换一个问法，你就容易卡住。
更好的准备方式是：拿一个真实功能，从质量目标、测试策略、用例设计、缺陷闭环、上线判断五个角度完整写一遍。写完之后，再想一下如果面试官追问，你会在哪里露怯，然后补哪块知识。
比如你在准备“自动化测试”时，不要只记“Appium是移动端自动化工具”，要想一想：如果测试半天找不到元素，你会怎么处理；如果一台设备上执行通过，另一台却失败，你如何排查。这些才是能代表测试能力的细节。
8.2 面试官：用追问区分“背题”和“理解”
如果你也是一个面试官，看到候选人回答很流利，不要急着给高分。多问两句：你上一段经历里，最有价值的一个bug是什么？当时怎么定位的？上线前最后一个版本你是怎么判断可以发布的？
这些问题没有标准答案，但能很快看出候选人有没有真实做过测试。测试核心不是背出来的，是做出来的。如果候选人只会说“我们用了什么框架”，但讲不出一次具体的排错过程，那简历上的“精通”和“熟悉”就要打个问号。
另外，面试官也可以通过场景题来考察。不要只问“什么是等价类”，而是给一个具体需求：“现在有一个设备老化测试全自动执行脚本，你会怎么设计？”能接住这种问题的人，通常才是真的测试思维在起作用。
8.3 写在最后：测试核心是质量风险
回到开头那个场景。候选人说“测试就是找bug”，为什么面试官不想给offer？因为找bug只是测试过程中的一个环节，不是核心。
测试核心，是在有限的时间和资源里，识别出质量风险，设计合理的验证方法，执行之后给出能支撑上线决策的结论。工具可以换，流程可以调，但这个核心不会变。
如果你正在准备测试岗面试，与其背一晚上测试题，不如拿一个真实功能，从目标、用例、缺陷、风险四个角度写一遍。能写清楚，面试时自然会表现出来。
