做测试岗面试官这几年我面过不少候选人有一个现象特别突出简历上写着“熟悉软件测试流程”“掌握自动化测试”但一问到“你觉得软件测试的核心是什么”很多人就卡住了。有人回答“就是找Bug”有人说是“点点点”也有人把测试流程背了一遍但明显不理解为什么要有这些流程。说真的不是候选人能力不行而是很多人在准备面试时把精力全放在了工具上——学了 Selenium、Appium、Postman、JMeter却忽略了测试最底层的思维体系和知识框架。这篇文章我结合面试中高频出现的核心问题把软件测试必备的知识体系完整梳理一遍。内容包括测试的核心定义与原则、测试分类、测试流程、用例设计方法、缺陷管理、接口测试与自动化测试入门以及常见面试题的回答思路。不管你是准备校招、跳槽还是刚转行做测试这份内容都值得收藏下来反复看。1. 软件测试的核心一切要从“价值”说起1.1 测试的定义到底是什么先看一个经典定义软件测试是指在规定的条件下对程序进行操作以发现程序错误、衡量软件质量并对其是否能满足设计要求进行评估的过程。很多人在面试时把这个定义背得很熟但被追问“那测试和调试有什么区别”就答不上来了。这其实是两个完全不同的概念对比项软件测试调试 Debug目的发现缺陷评估质量定位缺陷修复缺陷阶段贯穿整个开发周期主要在缺陷被确认后执行者测试工程师开发工程师为主输出缺陷报告、测试报告修复后的代码在这个定义背后还有一个容易被忽略的核心要点测试并不仅仅是“找Bug”。当一个软件经过充分测试但发现很少缺陷时这本身也是一种有价值的测试结果——它说明软件质量是可靠的可以评估是否达到上线标准。1.2 面试官问“测试核心”时真正想听什么如果面试官问“软件测试的核心是什么”建议从三个层面回答第一层质量保障。测试不是单纯为了找Bug而找Bug而是为了评估软件质量为发布决策提供数据支撑。第二层风险控制。通过测试提前暴露需求理解偏差、设计缺陷、编码错误、环境兼容性问题降低线上故障风险。第三层持续反馈。测试是连接开发、产品、运维的枢纽。测试结果可以反向推动需求澄清、代码优化、架构改进。如果能把这个逻辑讲清楚说明你对测试岗位的理解已经超过“点点点”的层面了这就是面试官想看到的“测试思维”。1.3 软件测试的七大原则这七大原则是 ISTQB国际软件测试认证委员会体系中的基础内容也是面试中非常喜欢考的知识点测试显示缺陷的存在测试可以证明缺陷存在但不能证明软件没有缺陷。穷尽测试是不可能的输入域太大不可能覆盖所有组合需要风险驱动优先测试核心功能。尽早介入测试缺陷越早发现修复成本越低。所以测试要从需求评审阶段就开始介入而不是等开发完成后再“点点点”。缺陷集群性少数模块往往集中了大部分缺陷这就是 Pareto 原则在测试中的体现——80%的问题通常集中在20%的模块中。杀虫剂悖论同一组测试用例反复执行发现新缺陷的能力会越来越弱所以需要不断更新测试用例。测试依赖于上下文不同业务场景下测试策略不同金融系统的安全测试和电商大促的性能测试优先级完全不一样。不存在缺陷谬论没有发现缺陷不等于软件没有问题可能只是测试覆盖不够。这七条看似简单但它们本身就是测试工作的决策依据。比如“尽早介入测试”直接影响测试流程的设计而“缺陷集群性”直接影响测试资源的分配。2. 测试分类体系从不同维度理解测试很多候选人能说出“功能测试”“性能测试”“自动化测试”但问到它们之间的关系就乱了。测试分类其实可以从多个维度来看。2.1 按开发阶段划分这是最经典的分类方式对应的是 V 模型阶段测试类型执行者说明需求分析阶段需求测试测试产品验证需求是否合理、可测、无歧义概要设计阶段集成测试规划测试验证模块之间的接口关系详细设计阶段单元测试设计开发验证单个函数/方法的正确性编码阶段单元测试执行开发常用 JUnit、pytest、TestNG集成阶段集成测试测试验证模块间交互、接口调用系统阶段系统测试测试验证整个系统是否满足需求验收阶段验收测试用户/测试验证软件是否满足业务需求这个结构对应了 V 模型的核心思想开发和测试的每一层都是一一对应的。后面会单独讲 V 模型在面试中怎么答。2.2 按是否查看代码划分黑盒测试不看内部实现只验证输入输出是否符合预期。功能测试、UI 测试都属于黑盒测试。白盒测试需要阅读代码逻辑验证分支、条件、路径是否覆盖充分单元测试多属于白盒测试。灰盒测试介于两者之间既关注外部功能也关注内部关键逻辑接口测试通常属于灰盒测试。面试时最容易犯的错是把“黑盒”等同于“手工点点点”。其实黑盒测试一样可以用自动化来做也可以通过等价类、边界值等方法系统化设计。2.3 按测试目的划分这是面试中最常涉及的分类每类都需要能说出它的目标、常用工具和适用场景类型目标常用工具/方法功能测试验证功能是否符合需求手工测试、自动化脚本性能测试验证响应时间、吞吐量、资源占用JMeter、LoadRunner、Gatling压力测试找出系统的崩溃点和瓶颈JMeter、wrk、locust安全测试发现漏洞和安全隐患Burp Suite、OWASP ZAP、SQLMap兼容性测试验证跨浏览器、跨设备、跨系统BrowserStack、Selenium Grid冒烟测试验证主流程是否可用能否进入正式测试手工或自动化脚本回归测试验证修改代码后原有功能没有被破坏自动化测试优先2.4 自动化测试与手工测试的关系很多人把“自动化测试”和“手工测试”对立起来其实两者是互补关系。适合自动化的场景回归测试每次发版都需要执行的核心用例接口测试输入输出明确适合脚本验证性能测试需要模拟大量并发手工无法完成数据驱动型任务如不同数据组合下的批量校验不适合自动化的场景探索性测试需要测试人员基于经验和直觉去发现未知问题易用性测试需要真实用户体验和主观判断视觉/交互类测试自动化很难评判“是否好看”“是否好用”一次性验证任务自动化脚本开发成本远高于手工执行成本面试时如果能说出“自动化率不是越高越好而是要看 ROI”面试官会对你有很好的印象。3. 测试流程从需求到发布测试做什么3.1 一个标准测试流程包含哪几个阶段我之前在文章里写过测试流程不是一个“等开发完成后开始测试”的线性流程而是一个贯穿整个研发周期的闭环。标准流程如下需求分析测试人员参与需求评审理解业务逻辑识别需求中的模糊点和不可测点。测试计划评估工作量确定测试范围、测试策略、资源安排、风险评估。测试设计编写测试用例准备测试数据搭建测试环境。测试执行按计划执行用例记录结果提交缺陷。缺陷跟踪跟进缺陷生命周期验证修复结果进行回归测试。测试报告汇总测试数据分析质量情况给出上线建议。上线验证线上环境进行冒烟验证确保核心链路可用。3.2 测试计划里都有什么测试计划不是走流程文档它是整个测试工作的作战地图。面试时如果答出下面这些要素会比较加分测试范围哪些功能在范围内哪些不在这是最重要的避免测试遗漏或无限扩大测试策略功能测试、接口测试、自动化测试、性能测试分别怎么做资源安排谁负责哪个模块需要哪些测试环境、测试设备时间节点什么时候用例评审什么时候执行什么时候出报告风险分析哪些模块风险高需要重点测试哪些需求可能变更影响计划3.3 V 模型与敏捷测试的区别V 模型是传统瀑布开发模式下的测试流程模型强调测试与开发阶段的一一对应关系。而敏捷开发模式下测试是持续进行的每个 Sprint 都要保证交付质量。对比项V 模型敏捷测试介入时机从需求阶段开始贯穿每个迭代执行频率按阶段执行持续集成、持续测试文档要求文档齐全轻文档、重沟通测试角色独立测试团队测试与开发紧密协作回归测试一次性回归每次迭代都要回归现在很多公司采用敏捷模式但考试和面试中 V 模型仍然是常考知识点因为它代表了测试流程设计的基础思维方式。面试时间紧张的话优先把 V 模型和敏捷测试的基本区别讲清楚就行。4. 测试用例设计面试必考的核心方法论4.1 什么是好的测试用例测试用例是测试执行的最小单位它描述了一组输入、执行条件和预期结果。一份完整的测试用例至少包含以下要素用例编号TC_LOGIN_001 所属模块用户登录 用例标题输入正确的用户名和密码验证登录成功 前置条件用户已注册账号状态正常 测试步骤 1. 打开登录页面 2. 输入正确的用户名 3. 输入正确的密码 4. 点击登录按钮 测试数据用户名admin密码123456 预期结果登录成功跳转到首页显示用户昵称 优先级P0面试时经常让候选人当场写测试用例很多初学者只会写“输入正确账号密码登录成功”这一条。真正好的用例设计需要用系统化的方法覆盖各种场景这就是下面要讲的用例设计方法。4.2 等价类划分法核心思想把输入域划分成若干等价类每个等价类中的数据对测试结果来说是等价的。只要从每个等价类中取一个代表值就能覆盖这一类场景。有效等价类满足需求的输入无效等价类不满足需求的输入示例手机号输入框要求 11 位数字。等价类示例值预期结果有效11位数字13800138000校验通过无效少于11位1380013800提示“手机号格式不正确”无效多于11位138001380000提示“手机号格式不正确”无效包含非数字1380013800a提示“手机号格式不正确”无效为空空提示“手机号不能为空”4.3 边界值分析法核心思想大量的缺陷往往出现在输入域的边界附近而不是在中间范围。所以测试时重点覆盖边界上、边界内、边界外的值。示例密码长度要求 6~16 位。边界场景密码长度预期结果最小值-15位校验不通过最小值6位校验通过最小值17位校验通过最大值-115位校验通过最大值16位校验通过最大值117位校验不通过4.4 场景法核心思想从用户实际使用场景出发把“基本流”和“备选流”组合起来设计用例。比如“购物下单”这个场景基本流登录 → 选择商品 → 加入购物车 → 结算 → 支付 → 生成订单备选流 1购物车为空时直接结算备选流 2支付超时备选流 3库存不足备选流 4支付成功后回调失败备选流 5下单过程中网络中断场景法的价值在于它把用户视角带入测试设计保证覆盖的不是孤立的输入输出而是完整的业务链路。4.5 判定表法和因果图法当输入条件多、组合逻辑复杂时用判定表可以保证组合覆盖的完整性。示例优惠券使用规则。条件/动作规则1规则2规则3规则4金额≥100YYNN用户是会员YNYN使用优惠券YNNN判定表法适合输入条件少3-5个但组合逻辑复杂的场景。如果条件太多组合数会爆炸这时候就要考虑用正交实验法来减少用例数量。4.6 面试高频题一个登录框怎么设计测试用例这道题几乎是测试面试必考题它考察的不是“你会不会用某个工具”而是你有没有测试思维。从几个维度来回答功能测试输入正确的用户名和密码登录成功输入错误的密码提示“用户名或密码错误”用户名为空、密码为空分别校验用户名不存在、密码错误、账号被锁定密码输入是否隐藏登录成功后跳转是否正确记住密码功能是否生效界面测试界面布局是否合理提示文案是否清晰无歧义键盘弹出是否遮挡输入框兼容性测试不同浏览器Chrome、Firefox、Safari、Edge不同分辨率不同操作系统移动端和 PC 端性能测试同时大量用户登录响应时间是否达标弱网环境下能否正常登录安全测试密码是否加密传输是否存在 SQL 注入风险登录接口是否被暴力破解登录凭证是否安全存储这样的回答方式比“我测一下用户名密码对不对”要完整得多也能直接体现测试思维的系统性。5. 缺陷管理从发现 Bug 到闭环5.1 缺陷的生命周期缺陷管理是测试工程师最日常的工作也是面试中常考的知识点。一个缺陷从发现到关闭通常经历以下状态新建New→ 打开/确认Open/Confirmed→ 修复Fixed→ 待回归Verified→ 关闭Closed如果某个环节有问题还会有中间状态拒绝Rejected开发认为不是 Bug比如需求就是这么设计的延迟Deferred当前版本不修复但后续版本要处理重新打开Reopened开发修复后测试验证发现没有修好或者引入了新问题5.2 优秀缺陷报告的标准一份好的缺陷报告应该让开发同学不需要跑来问你就能复现问题。关键要素如下要素说明缺陷标题简洁清晰地描述问题现象例如“登录页输入正确密码点击登录无响应”所属模块明确是哪个功能模块环境信息操作系统、浏览器、App版本、设备型号优先级P0-P4P0为最紧急严重程度致命、严重、一般、轻微复现步骤完整、可操作的步骤预期结果按需求应该是什么样的实际结果实际观察到的现象附件截图、录屏、日志这里有一个工程效率的关键点缺陷描述中一定要区分“预期结果”和“实际结果”并尽量附上日志或抓包信息。很多同事在提缺陷时只写“页面报错”开发根本不知道报的什么错、在什么条件下报错来回沟通成本极高。5.3 如何做好回归测试缺陷修复后不能只验证“这个问题没了”就完事还要验证“修改影响的其他功能是否正常”。回归测试通常分两种定向回归只验证被修复功能及其相关模块全量回归在发版前把核心用例全部执行一遍实际的工程做法是先把发现缺陷时的原始用例跑一遍确认修复有效再跑和这个模块关联度高的用例确认没有引入回归最后在发版前做全量回归。这也是为什么要推行自动化测试在回归阶段的落地——纯手工做全量回归一旦业务复杂、用例数量大执行成本会非常高。6. 接口测试与自动化测试进阶必备技能6.1 接口测试的核心概念接口测试是当前测试岗位的必备技能。它的核心是验证系统之间或模块之间的数据交互是否正确。接口测试和 UI 测试的核心区别对比项UI 测试接口测试测试层面用户操作界面后端服务接口发现问题的时机较晚必须开发完页面才能测较早后端接口开发完就能测执行稳定性受前端影响稳定性差稳定不受界面变化影响测试效率执行速度慢执行速度快能发现的问题界面问题、交互问题逻辑问题、数据问题、安全漏洞接口测试常被归为灰盒测试因为测试人员需要了解接口的请求参数、返回结构但不需要关注内部实现细节。6.2 Python requests 接口测试示例下面是一个最简单的接口测试示例用的是 Python 的 requests 库# 文件路径test_api_demo.py import requests import json def test_login(): 测试登录接口 # 接口地址示例环境实际以项目为准 url https://api.example.com/auth/login # 请求参数 payload { username: admin, password: 123456 } # 发送请求 response requests.post(url, jsonpayload) # 打印响应内容便于排查问题 print(状态码:, response.status_code) print(响应体:, response.text) # 断言状态码必须是 200 assert response.status_code 200, 登录接口状态码异常 # 解析 JSON 响应 body response.json() assert body.get(code) 0, f登录失败: {body.get(message)} assert body.get(data, {}).get(token), 响应中没有返回 token print(登录接口测试通过)这个例子虽然简单但它包含了接口测试的三步核心构造请求、发送请求、断言响应。如果要在项目里做完整的接口自动化测试建议使用 pytest 框架来组织用例利用 fixture 管理公共数据利用参数化实现多组数据驱动。6.3 Pytest 自动化测试入门示例# 文件路径test_order_api.py import pytest import requests BASE_URL https://api.example.com pytest.fixture def auth_token(): 登录获取 token供其他测试用例使用 resp requests.post( f{BASE_URL}/auth/login, json{username: admin, password: 123456} ) assert resp.status_code 200 return resp.json()[data][token] def test_create_order(auth_token): 测试创建订单接口 headers {Authorization: fBearer {auth_token}} resp requests.post( f{BASE_URL}/order/create, headersheaders, json{product_id: 1001, quantity: 2} ) assert resp.status_code 200 body resp.json() assert body[code] 0 assert body[data][order_id] is not None pytest.mark.parametrize(product_id,quantity,expected_code, [ (1001, 2, 0), # 正常场景 (1001, 0, 40001), # 数量不能为 0 (99999, 1, 40002), # 商品不存在 (1001, -1, 40001), # 数量不能为负数 ]) def test_create_order_parametrize(auth_token, product_id, quantity, expected_code): 参数化测试用多组数据覆盖不同场景 headers {Authorization: fBearer {auth_token}} resp requests.post( f{BASE_URL}/order/create, headersheaders, json{product_id: product_id, quantity: quantity} ) assert resp.status_code 200 assert resp.json()[code] expected_code运行方式# 执行所有用例 pytest -v # 执行指定文件 pytest test_order_api.py -v # 执行指定用例并输出详细日志 pytest test_order_api.py::test_create_order -v -s这里要提醒一下示例中的接口地址和参数名是演示用的实际项目中要按照后端接口文档调整请求路径、参数名和断言逻辑。接口自动化测试的难点不只是写脚本更重要的是测试数据准备、环境切换、断言设计、失败定位以及持续集成集成。6.4 Appium 移动端自动化测试Appium 是目前最主流的移动端自动化测试框架它支持 Android 和 iOS并且支持多种语言Java、Python、Ruby 等。Appium 的核心架构是客户端-服务器模式测试脚本Python/Java→ Appium Server → 手机设备/模拟器 → 返回执行结果Appium 自动化测试的基础步骤安装 Appium Server 和对应的平台驱动准备 Android SDK / Xcode 环境配置 Desired Capabilities设备名、平台版本、App路径、包名等编写脚本定位元素、执行操作、添加断言运行脚本并生成报告一个基础的 Appium 脚本示例# 文件路径test_appium_demo.py from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy # 设备配置需要根据实际环境修改 desired_caps { platformName: Android, platformVersion: 12.0, deviceName: Android Emulator, appPackage: com.example.app, appActivity: .MainActivity, noReset: True } # 连接 Appium Server driver webdriver.Remote(http://localhost:4723/wd/hub, desired_caps) try: # 通过资源 ID 定位元素 login_button driver.find_element(AppiumBy.ID, com.example.app:id/btn_login) login_button.click() # 输入用户名和密码 username_input driver.find_element(AppiumBy.ID, com.example.app:id/edt_username) username_input.send_keys(admin) password_input driver.find_element(AppiumBy.ID, com.example.app:id/edt_password) password_input.send_keys(123456) # 点击登录 driver.find_element(AppiumBy.ID, com.example.app:id/btn_login_submit).click() # 断言登录成功页面出现 assert driver.find_element(AppiumBy.ID, com.example.app:id/tv_welcome).is_displayed() print(Appium 自动化测试通过) finally: driver.quit()Appium 定位元素的方式有很多种ID、XPath、ClassName、AccessibilityId、UIAutomator 等。实际项目中优先使用稳定的 ID 定位XPath 容易受页面结构变化影响。6.5 安全测试与性能测试入门热搜词里出现了不少安全测试相关的内容比如渗透测试、Pikachu 漏洞测试平台、SQLMap 等。这里简单梳理一下测试工程师需要的安全测试基础安全测试的目标发现系统在认证、授权、数据加密、输入校验、会话管理等方面的漏洞。常见漏洞类型SQL 注入、XSS跨站脚本攻击、CSRF跨站请求伪造、越权访问、文件上传漏洞、敏感信息泄露。常用工具Burp Suite 抓包改包、OWASP ZAP 漏洞扫描、SQLMap 探测 SQL 注入。Pikachu 平台是一个开源的漏洞测试靶场包含常见的 Web 安全漏洞场景非常适合初学者练习。性能测试也是高阶测试工程师必备能力。核心指标包括指标说明响应时间从发请求到收到响应的时间吞吐量单位时间内处理的请求数并发用户数同时在线操作的用户数量错误率失败请求占总请求的比例TPS/QPS每秒事务数/每秒查询数资源利用率CPU、内存、磁盘、网络的使用情况性能测试需要先明确性能需求目标值然后设计场景基准测试、负载测试、压力测试、稳定性测试执行测试后分析瓶颈输出性能测试报告。7. 常见测试面试题整理与回答思路7.1 测试基础类面试题回答要点什么是软件测试在规定条件下操作程序、发现缺陷、评估质量的过程测试的核心是什么质量保障、风险控制、持续反馈测试和调试的区别测试发现问题调试定位并修复问题什么是冒烟测试验证主流程可用决定是否进入正式测试什么是回归测试修改后验证原有功能是否受影响黑盒和白盒的区别是否查看内部代码逻辑软件测试的原则有哪些七大原则重点说尽早测试、缺陷集群性7.2 用例设计类面试题回答要点如何设计测试用例等价类、边界值、场景法、判定表、错误推测法一个登录框怎么测功能、界面、兼容性、性能、安全五个维度如何保证测试覆盖率需求覆盖、代码覆盖、接口覆盖、风险覆盖测试用例的核心要素编号、标题、前置条件、步骤、数据、预期结果7.3 自动化与接口类面试题回答要点什么项目适合自动化回归测试、接口测试、大量重复执行的用例自动化测试的优缺点优效率高、可重复缺开发成本高、UI变化敏感接口测试和UI测试的区别发现问题时机、稳定性、执行效率Appium 的原理客户端通过 Appium Server 驱动手机执行操作如何做接口测试构造请求、发送请求、断言响应、数据管理、结果生成7.4 场景类面试题回答要点上线前发现严重Bug怎么办评估影响范围与开发、产品确认修复方案评估上线风险必要时延后发布开发说“这不是Bug”怎么办看需求文档确认预期和产品经理对齐保留证据截图/日志时间不够怎么保证测试质量风险驱动优先测核心链路和高风险模块回归测试用自动化兜底如何测试一个水杯功能、外观、材质、容量、温度、耐摔、场景等维度这里想特别提醒场景类面试题没有标准答案面试官考察的是你的思维方式是否系统、是否有边界意识、是否能分清优先级。哪怕和面试官预设的答案不同只要逻辑自洽都会有不错的分数。8. 测试工程师的成长路线与核心能力8.1 从功能测试到测试开发的路径测试岗位的成长路线大致可以分为四个阶段功能测试工程师熟悉测试流程、会写用例、能独立完成测试任务。自动化测试工程师掌握接口自动化、UI自动化能搭建自动化框架提升回归测试效率。测试开发工程师能做测试平台开发、测试工具开发、持续集成建设对代码能力要求高。测试专家/质量架构师能够从全局视角建立质量保障体系推动研发流程改进。8.2 测试工程师需要掌握哪些技能很多初入行的同学有一个误区认为做测试不需要会写代码。虽然部分手工测试岗位确实可以不依赖代码但如果想在测试职业路径上有发展空间代码能力是避不开的。建议优先掌握编程语言Python 或 Java二选一作为主语言操作系统Linux 基础命令、日志查看、环境部署数据库SQL 增删改查、数据准备与校验接口测试HTTP 协议、Postman、requests、pytest自动化测试Selenium、Appium、Pytest性能测试JMeter 基础使用、性能指标分析CI/CD 基础Jenkins、Git了解持续集成流程还有一个重要的软技能沟通能力。测试是开发、产品、运维之间的桥梁如何清楚地描述一个Bug、如何推动一个阻塞问题解决、如何在质量与时间之间做出判断这些能力在面试中很难量化但工作中非常重要。8.3 测试与全栈边界在哪里热搜词里出现了“前端和后端”“测试与全栈”这类词这说明很多同学在思考测试岗位和开发岗位的关系。测试和开发的核心目标本身就不同——开发是“构建软件”测试是“评估软件”。两者可以互相学习技能但思维模式有差异。开发思维关注“怎么把功能实现出来”测试思维关注“什么条件下功能会挂掉”。测试工程师没有必要去追求成为全栈开发但有必要理解前端和后端的基本工作原理。比如做接口测试要理解后端如何接收请求、如何返回响应做 UI 自动化要理解前端如何渲染页面、DOM 如何变更。这种“理解”不需要达到开发水平但足以帮助你更高效地设计和执行测试。9. 写在最后回顾开头那个面试场景候选人为什么连“测试核心”都答不出来不是因为他不努力也不是因为他不会用工具而是他在准备面试时只学了“怎么测”没有深入思考“为什么测”和“测的意义是什么”。软件测试的核心从来不是“找Bug”而是通过系统化的质量评估手段为产品交付提供信心。围绕这个核心延伸出的测试原则、测试流程、用例设计方法、缺陷管理、自动化测试体系才是测试工程师真正的知识框架。如果你正在准备测试岗位面试建议按照本文的章节顺序把每个模块都过一遍。重点不是死记硬背概念而是能用自己的话把“为什么这样做”讲清楚。如果你已经是正式测试工程师希望这篇文章能帮你查漏补缺。面试别人时这些内容经常会被问到带新人时这些内容也是最基础的培训材料。如果这篇文章对你有帮助可以收藏备用。后续我还会继续整理测试面试题详解、接口自动化框架搭建、性能测试实战等内容欢迎持续关注。
做测试岗面试官这几年我面过不少候选人有一个现象特别突出简历上写着“熟悉软件测试流程”“掌握自动化测试”但一问到“你觉得软件测试的核心是什么”很多人就卡住了。有人回答“就是找Bug”有人说是“点点点”也有人把测试流程背了一遍但明显不理解为什么要有这些流程。说真的不是候选人能力不行而是很多人在准备面试时把精力全放在了工具上——学了 Selenium、Appium、Postman、JMeter却忽略了测试最底层的思维体系和知识框架。这篇文章我结合面试中高频出现的核心问题把软件测试必备的知识体系完整梳理一遍。内容包括测试的核心定义与原则、测试分类、测试流程、用例设计方法、缺陷管理、接口测试与自动化测试入门以及常见面试题的回答思路。不管你是准备校招、跳槽还是刚转行做测试这份内容都值得收藏下来反复看。1. 软件测试的核心一切要从“价值”说起1.1 测试的定义到底是什么先看一个经典定义软件测试是指在规定的条件下对程序进行操作以发现程序错误、衡量软件质量并对其是否能满足设计要求进行评估的过程。很多人在面试时把这个定义背得很熟但被追问“那测试和调试有什么区别”就答不上来了。这其实是两个完全不同的概念对比项软件测试调试 Debug目的发现缺陷评估质量定位缺陷修复缺陷阶段贯穿整个开发周期主要在缺陷被确认后执行者测试工程师开发工程师为主输出缺陷报告、测试报告修复后的代码在这个定义背后还有一个容易被忽略的核心要点测试并不仅仅是“找Bug”。当一个软件经过充分测试但发现很少缺陷时这本身也是一种有价值的测试结果——它说明软件质量是可靠的可以评估是否达到上线标准。1.2 面试官问“测试核心”时真正想听什么如果面试官问“软件测试的核心是什么”建议从三个层面回答第一层质量保障。测试不是单纯为了找Bug而找Bug而是为了评估软件质量为发布决策提供数据支撑。第二层风险控制。通过测试提前暴露需求理解偏差、设计缺陷、编码错误、环境兼容性问题降低线上故障风险。第三层持续反馈。测试是连接开发、产品、运维的枢纽。测试结果可以反向推动需求澄清、代码优化、架构改进。如果能把这个逻辑讲清楚说明你对测试岗位的理解已经超过“点点点”的层面了这就是面试官想看到的“测试思维”。1.3 软件测试的七大原则这七大原则是 ISTQB国际软件测试认证委员会体系中的基础内容也是面试中非常喜欢考的知识点测试显示缺陷的存在测试可以证明缺陷存在但不能证明软件没有缺陷。穷尽测试是不可能的输入域太大不可能覆盖所有组合需要风险驱动优先测试核心功能。尽早介入测试缺陷越早发现修复成本越低。所以测试要从需求评审阶段就开始介入而不是等开发完成后再“点点点”。缺陷集群性少数模块往往集中了大部分缺陷这就是 Pareto 原则在测试中的体现——80%的问题通常集中在20%的模块中。杀虫剂悖论同一组测试用例反复执行发现新缺陷的能力会越来越弱所以需要不断更新测试用例。测试依赖于上下文不同业务场景下测试策略不同金融系统的安全测试和电商大促的性能测试优先级完全不一样。不存在缺陷谬论没有发现缺陷不等于软件没有问题可能只是测试覆盖不够。这七条看似简单但它们本身就是测试工作的决策依据。比如“尽早介入测试”直接影响测试流程的设计而“缺陷集群性”直接影响测试资源的分配。2. 测试分类体系从不同维度理解测试很多候选人能说出“功能测试”“性能测试”“自动化测试”但问到它们之间的关系就乱了。测试分类其实可以从多个维度来看。2.1 按开发阶段划分这是最经典的分类方式对应的是 V 模型阶段测试类型执行者说明需求分析阶段需求测试测试产品验证需求是否合理、可测、无歧义概要设计阶段集成测试规划测试验证模块之间的接口关系详细设计阶段单元测试设计开发验证单个函数/方法的正确性编码阶段单元测试执行开发常用 JUnit、pytest、TestNG集成阶段集成测试测试验证模块间交互、接口调用系统阶段系统测试测试验证整个系统是否满足需求验收阶段验收测试用户/测试验证软件是否满足业务需求这个结构对应了 V 模型的核心思想开发和测试的每一层都是一一对应的。后面会单独讲 V 模型在面试中怎么答。2.2 按是否查看代码划分黑盒测试不看内部实现只验证输入输出是否符合预期。功能测试、UI 测试都属于黑盒测试。白盒测试需要阅读代码逻辑验证分支、条件、路径是否覆盖充分单元测试多属于白盒测试。灰盒测试介于两者之间既关注外部功能也关注内部关键逻辑接口测试通常属于灰盒测试。面试时最容易犯的错是把“黑盒”等同于“手工点点点”。其实黑盒测试一样可以用自动化来做也可以通过等价类、边界值等方法系统化设计。2.3 按测试目的划分这是面试中最常涉及的分类每类都需要能说出它的目标、常用工具和适用场景类型目标常用工具/方法功能测试验证功能是否符合需求手工测试、自动化脚本性能测试验证响应时间、吞吐量、资源占用JMeter、LoadRunner、Gatling压力测试找出系统的崩溃点和瓶颈JMeter、wrk、locust安全测试发现漏洞和安全隐患Burp Suite、OWASP ZAP、SQLMap兼容性测试验证跨浏览器、跨设备、跨系统BrowserStack、Selenium Grid冒烟测试验证主流程是否可用能否进入正式测试手工或自动化脚本回归测试验证修改代码后原有功能没有被破坏自动化测试优先2.4 自动化测试与手工测试的关系很多人把“自动化测试”和“手工测试”对立起来其实两者是互补关系。适合自动化的场景回归测试每次发版都需要执行的核心用例接口测试输入输出明确适合脚本验证性能测试需要模拟大量并发手工无法完成数据驱动型任务如不同数据组合下的批量校验不适合自动化的场景探索性测试需要测试人员基于经验和直觉去发现未知问题易用性测试需要真实用户体验和主观判断视觉/交互类测试自动化很难评判“是否好看”“是否好用”一次性验证任务自动化脚本开发成本远高于手工执行成本面试时如果能说出“自动化率不是越高越好而是要看 ROI”面试官会对你有很好的印象。3. 测试流程从需求到发布测试做什么3.1 一个标准测试流程包含哪几个阶段我之前在文章里写过测试流程不是一个“等开发完成后开始测试”的线性流程而是一个贯穿整个研发周期的闭环。标准流程如下需求分析测试人员参与需求评审理解业务逻辑识别需求中的模糊点和不可测点。测试计划评估工作量确定测试范围、测试策略、资源安排、风险评估。测试设计编写测试用例准备测试数据搭建测试环境。测试执行按计划执行用例记录结果提交缺陷。缺陷跟踪跟进缺陷生命周期验证修复结果进行回归测试。测试报告汇总测试数据分析质量情况给出上线建议。上线验证线上环境进行冒烟验证确保核心链路可用。3.2 测试计划里都有什么测试计划不是走流程文档它是整个测试工作的作战地图。面试时如果答出下面这些要素会比较加分测试范围哪些功能在范围内哪些不在这是最重要的避免测试遗漏或无限扩大测试策略功能测试、接口测试、自动化测试、性能测试分别怎么做资源安排谁负责哪个模块需要哪些测试环境、测试设备时间节点什么时候用例评审什么时候执行什么时候出报告风险分析哪些模块风险高需要重点测试哪些需求可能变更影响计划3.3 V 模型与敏捷测试的区别V 模型是传统瀑布开发模式下的测试流程模型强调测试与开发阶段的一一对应关系。而敏捷开发模式下测试是持续进行的每个 Sprint 都要保证交付质量。对比项V 模型敏捷测试介入时机从需求阶段开始贯穿每个迭代执行频率按阶段执行持续集成、持续测试文档要求文档齐全轻文档、重沟通测试角色独立测试团队测试与开发紧密协作回归测试一次性回归每次迭代都要回归现在很多公司采用敏捷模式但考试和面试中 V 模型仍然是常考知识点因为它代表了测试流程设计的基础思维方式。面试时间紧张的话优先把 V 模型和敏捷测试的基本区别讲清楚就行。4. 测试用例设计面试必考的核心方法论4.1 什么是好的测试用例测试用例是测试执行的最小单位它描述了一组输入、执行条件和预期结果。一份完整的测试用例至少包含以下要素用例编号TC_LOGIN_001 所属模块用户登录 用例标题输入正确的用户名和密码验证登录成功 前置条件用户已注册账号状态正常 测试步骤 1. 打开登录页面 2. 输入正确的用户名 3. 输入正确的密码 4. 点击登录按钮 测试数据用户名admin密码123456 预期结果登录成功跳转到首页显示用户昵称 优先级P0面试时经常让候选人当场写测试用例很多初学者只会写“输入正确账号密码登录成功”这一条。真正好的用例设计需要用系统化的方法覆盖各种场景这就是下面要讲的用例设计方法。4.2 等价类划分法核心思想把输入域划分成若干等价类每个等价类中的数据对测试结果来说是等价的。只要从每个等价类中取一个代表值就能覆盖这一类场景。有效等价类满足需求的输入无效等价类不满足需求的输入示例手机号输入框要求 11 位数字。等价类示例值预期结果有效11位数字13800138000校验通过无效少于11位1380013800提示“手机号格式不正确”无效多于11位138001380000提示“手机号格式不正确”无效包含非数字1380013800a提示“手机号格式不正确”无效为空空提示“手机号不能为空”4.3 边界值分析法核心思想大量的缺陷往往出现在输入域的边界附近而不是在中间范围。所以测试时重点覆盖边界上、边界内、边界外的值。示例密码长度要求 6~16 位。边界场景密码长度预期结果最小值-15位校验不通过最小值6位校验通过最小值17位校验通过最大值-115位校验通过最大值16位校验通过最大值117位校验不通过4.4 场景法核心思想从用户实际使用场景出发把“基本流”和“备选流”组合起来设计用例。比如“购物下单”这个场景基本流登录 → 选择商品 → 加入购物车 → 结算 → 支付 → 生成订单备选流 1购物车为空时直接结算备选流 2支付超时备选流 3库存不足备选流 4支付成功后回调失败备选流 5下单过程中网络中断场景法的价值在于它把用户视角带入测试设计保证覆盖的不是孤立的输入输出而是完整的业务链路。4.5 判定表法和因果图法当输入条件多、组合逻辑复杂时用判定表可以保证组合覆盖的完整性。示例优惠券使用规则。条件/动作规则1规则2规则3规则4金额≥100YYNN用户是会员YNYN使用优惠券YNNN判定表法适合输入条件少3-5个但组合逻辑复杂的场景。如果条件太多组合数会爆炸这时候就要考虑用正交实验法来减少用例数量。4.6 面试高频题一个登录框怎么设计测试用例这道题几乎是测试面试必考题它考察的不是“你会不会用某个工具”而是你有没有测试思维。从几个维度来回答功能测试输入正确的用户名和密码登录成功输入错误的密码提示“用户名或密码错误”用户名为空、密码为空分别校验用户名不存在、密码错误、账号被锁定密码输入是否隐藏登录成功后跳转是否正确记住密码功能是否生效界面测试界面布局是否合理提示文案是否清晰无歧义键盘弹出是否遮挡输入框兼容性测试不同浏览器Chrome、Firefox、Safari、Edge不同分辨率不同操作系统移动端和 PC 端性能测试同时大量用户登录响应时间是否达标弱网环境下能否正常登录安全测试密码是否加密传输是否存在 SQL 注入风险登录接口是否被暴力破解登录凭证是否安全存储这样的回答方式比“我测一下用户名密码对不对”要完整得多也能直接体现测试思维的系统性。5. 缺陷管理从发现 Bug 到闭环5.1 缺陷的生命周期缺陷管理是测试工程师最日常的工作也是面试中常考的知识点。一个缺陷从发现到关闭通常经历以下状态新建New→ 打开/确认Open/Confirmed→ 修复Fixed→ 待回归Verified→ 关闭Closed如果某个环节有问题还会有中间状态拒绝Rejected开发认为不是 Bug比如需求就是这么设计的延迟Deferred当前版本不修复但后续版本要处理重新打开Reopened开发修复后测试验证发现没有修好或者引入了新问题5.2 优秀缺陷报告的标准一份好的缺陷报告应该让开发同学不需要跑来问你就能复现问题。关键要素如下要素说明缺陷标题简洁清晰地描述问题现象例如“登录页输入正确密码点击登录无响应”所属模块明确是哪个功能模块环境信息操作系统、浏览器、App版本、设备型号优先级P0-P4P0为最紧急严重程度致命、严重、一般、轻微复现步骤完整、可操作的步骤预期结果按需求应该是什么样的实际结果实际观察到的现象附件截图、录屏、日志这里有一个工程效率的关键点缺陷描述中一定要区分“预期结果”和“实际结果”并尽量附上日志或抓包信息。很多同事在提缺陷时只写“页面报错”开发根本不知道报的什么错、在什么条件下报错来回沟通成本极高。5.3 如何做好回归测试缺陷修复后不能只验证“这个问题没了”就完事还要验证“修改影响的其他功能是否正常”。回归测试通常分两种定向回归只验证被修复功能及其相关模块全量回归在发版前把核心用例全部执行一遍实际的工程做法是先把发现缺陷时的原始用例跑一遍确认修复有效再跑和这个模块关联度高的用例确认没有引入回归最后在发版前做全量回归。这也是为什么要推行自动化测试在回归阶段的落地——纯手工做全量回归一旦业务复杂、用例数量大执行成本会非常高。6. 接口测试与自动化测试进阶必备技能6.1 接口测试的核心概念接口测试是当前测试岗位的必备技能。它的核心是验证系统之间或模块之间的数据交互是否正确。接口测试和 UI 测试的核心区别对比项UI 测试接口测试测试层面用户操作界面后端服务接口发现问题的时机较晚必须开发完页面才能测较早后端接口开发完就能测执行稳定性受前端影响稳定性差稳定不受界面变化影响测试效率执行速度慢执行速度快能发现的问题界面问题、交互问题逻辑问题、数据问题、安全漏洞接口测试常被归为灰盒测试因为测试人员需要了解接口的请求参数、返回结构但不需要关注内部实现细节。6.2 Python requests 接口测试示例下面是一个最简单的接口测试示例用的是 Python 的 requests 库# 文件路径test_api_demo.py import requests import json def test_login(): 测试登录接口 # 接口地址示例环境实际以项目为准 url https://api.example.com/auth/login # 请求参数 payload { username: admin, password: 123456 } # 发送请求 response requests.post(url, jsonpayload) # 打印响应内容便于排查问题 print(状态码:, response.status_code) print(响应体:, response.text) # 断言状态码必须是 200 assert response.status_code 200, 登录接口状态码异常 # 解析 JSON 响应 body response.json() assert body.get(code) 0, f登录失败: {body.get(message)} assert body.get(data, {}).get(token), 响应中没有返回 token print(登录接口测试通过)这个例子虽然简单但它包含了接口测试的三步核心构造请求、发送请求、断言响应。如果要在项目里做完整的接口自动化测试建议使用 pytest 框架来组织用例利用 fixture 管理公共数据利用参数化实现多组数据驱动。6.3 Pytest 自动化测试入门示例# 文件路径test_order_api.py import pytest import requests BASE_URL https://api.example.com pytest.fixture def auth_token(): 登录获取 token供其他测试用例使用 resp requests.post( f{BASE_URL}/auth/login, json{username: admin, password: 123456} ) assert resp.status_code 200 return resp.json()[data][token] def test_create_order(auth_token): 测试创建订单接口 headers {Authorization: fBearer {auth_token}} resp requests.post( f{BASE_URL}/order/create, headersheaders, json{product_id: 1001, quantity: 2} ) assert resp.status_code 200 body resp.json() assert body[code] 0 assert body[data][order_id] is not None pytest.mark.parametrize(product_id,quantity,expected_code, [ (1001, 2, 0), # 正常场景 (1001, 0, 40001), # 数量不能为 0 (99999, 1, 40002), # 商品不存在 (1001, -1, 40001), # 数量不能为负数 ]) def test_create_order_parametrize(auth_token, product_id, quantity, expected_code): 参数化测试用多组数据覆盖不同场景 headers {Authorization: fBearer {auth_token}} resp requests.post( f{BASE_URL}/order/create, headersheaders, json{product_id: product_id, quantity: quantity} ) assert resp.status_code 200 assert resp.json()[code] expected_code运行方式# 执行所有用例 pytest -v # 执行指定文件 pytest test_order_api.py -v # 执行指定用例并输出详细日志 pytest test_order_api.py::test_create_order -v -s这里要提醒一下示例中的接口地址和参数名是演示用的实际项目中要按照后端接口文档调整请求路径、参数名和断言逻辑。接口自动化测试的难点不只是写脚本更重要的是测试数据准备、环境切换、断言设计、失败定位以及持续集成集成。6.4 Appium 移动端自动化测试Appium 是目前最主流的移动端自动化测试框架它支持 Android 和 iOS并且支持多种语言Java、Python、Ruby 等。Appium 的核心架构是客户端-服务器模式测试脚本Python/Java→ Appium Server → 手机设备/模拟器 → 返回执行结果Appium 自动化测试的基础步骤安装 Appium Server 和对应的平台驱动准备 Android SDK / Xcode 环境配置 Desired Capabilities设备名、平台版本、App路径、包名等编写脚本定位元素、执行操作、添加断言运行脚本并生成报告一个基础的 Appium 脚本示例# 文件路径test_appium_demo.py from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy # 设备配置需要根据实际环境修改 desired_caps { platformName: Android, platformVersion: 12.0, deviceName: Android Emulator, appPackage: com.example.app, appActivity: .MainActivity, noReset: True } # 连接 Appium Server driver webdriver.Remote(http://localhost:4723/wd/hub, desired_caps) try: # 通过资源 ID 定位元素 login_button driver.find_element(AppiumBy.ID, com.example.app:id/btn_login) login_button.click() # 输入用户名和密码 username_input driver.find_element(AppiumBy.ID, com.example.app:id/edt_username) username_input.send_keys(admin) password_input driver.find_element(AppiumBy.ID, com.example.app:id/edt_password) password_input.send_keys(123456) # 点击登录 driver.find_element(AppiumBy.ID, com.example.app:id/btn_login_submit).click() # 断言登录成功页面出现 assert driver.find_element(AppiumBy.ID, com.example.app:id/tv_welcome).is_displayed() print(Appium 自动化测试通过) finally: driver.quit()Appium 定位元素的方式有很多种ID、XPath、ClassName、AccessibilityId、UIAutomator 等。实际项目中优先使用稳定的 ID 定位XPath 容易受页面结构变化影响。6.5 安全测试与性能测试入门热搜词里出现了不少安全测试相关的内容比如渗透测试、Pikachu 漏洞测试平台、SQLMap 等。这里简单梳理一下测试工程师需要的安全测试基础安全测试的目标发现系统在认证、授权、数据加密、输入校验、会话管理等方面的漏洞。常见漏洞类型SQL 注入、XSS跨站脚本攻击、CSRF跨站请求伪造、越权访问、文件上传漏洞、敏感信息泄露。常用工具Burp Suite 抓包改包、OWASP ZAP 漏洞扫描、SQLMap 探测 SQL 注入。Pikachu 平台是一个开源的漏洞测试靶场包含常见的 Web 安全漏洞场景非常适合初学者练习。性能测试也是高阶测试工程师必备能力。核心指标包括指标说明响应时间从发请求到收到响应的时间吞吐量单位时间内处理的请求数并发用户数同时在线操作的用户数量错误率失败请求占总请求的比例TPS/QPS每秒事务数/每秒查询数资源利用率CPU、内存、磁盘、网络的使用情况性能测试需要先明确性能需求目标值然后设计场景基准测试、负载测试、压力测试、稳定性测试执行测试后分析瓶颈输出性能测试报告。7. 常见测试面试题整理与回答思路7.1 测试基础类面试题回答要点什么是软件测试在规定条件下操作程序、发现缺陷、评估质量的过程测试的核心是什么质量保障、风险控制、持续反馈测试和调试的区别测试发现问题调试定位并修复问题什么是冒烟测试验证主流程可用决定是否进入正式测试什么是回归测试修改后验证原有功能是否受影响黑盒和白盒的区别是否查看内部代码逻辑软件测试的原则有哪些七大原则重点说尽早测试、缺陷集群性7.2 用例设计类面试题回答要点如何设计测试用例等价类、边界值、场景法、判定表、错误推测法一个登录框怎么测功能、界面、兼容性、性能、安全五个维度如何保证测试覆盖率需求覆盖、代码覆盖、接口覆盖、风险覆盖测试用例的核心要素编号、标题、前置条件、步骤、数据、预期结果7.3 自动化与接口类面试题回答要点什么项目适合自动化回归测试、接口测试、大量重复执行的用例自动化测试的优缺点优效率高、可重复缺开发成本高、UI变化敏感接口测试和UI测试的区别发现问题时机、稳定性、执行效率Appium 的原理客户端通过 Appium Server 驱动手机执行操作如何做接口测试构造请求、发送请求、断言响应、数据管理、结果生成7.4 场景类面试题回答要点上线前发现严重Bug怎么办评估影响范围与开发、产品确认修复方案评估上线风险必要时延后发布开发说“这不是Bug”怎么办看需求文档确认预期和产品经理对齐保留证据截图/日志时间不够怎么保证测试质量风险驱动优先测核心链路和高风险模块回归测试用自动化兜底如何测试一个水杯功能、外观、材质、容量、温度、耐摔、场景等维度这里想特别提醒场景类面试题没有标准答案面试官考察的是你的思维方式是否系统、是否有边界意识、是否能分清优先级。哪怕和面试官预设的答案不同只要逻辑自洽都会有不错的分数。8. 测试工程师的成长路线与核心能力8.1 从功能测试到测试开发的路径测试岗位的成长路线大致可以分为四个阶段功能测试工程师熟悉测试流程、会写用例、能独立完成测试任务。自动化测试工程师掌握接口自动化、UI自动化能搭建自动化框架提升回归测试效率。测试开发工程师能做测试平台开发、测试工具开发、持续集成建设对代码能力要求高。测试专家/质量架构师能够从全局视角建立质量保障体系推动研发流程改进。8.2 测试工程师需要掌握哪些技能很多初入行的同学有一个误区认为做测试不需要会写代码。虽然部分手工测试岗位确实可以不依赖代码但如果想在测试职业路径上有发展空间代码能力是避不开的。建议优先掌握编程语言Python 或 Java二选一作为主语言操作系统Linux 基础命令、日志查看、环境部署数据库SQL 增删改查、数据准备与校验接口测试HTTP 协议、Postman、requests、pytest自动化测试Selenium、Appium、Pytest性能测试JMeter 基础使用、性能指标分析CI/CD 基础Jenkins、Git了解持续集成流程还有一个重要的软技能沟通能力。测试是开发、产品、运维之间的桥梁如何清楚地描述一个Bug、如何推动一个阻塞问题解决、如何在质量与时间之间做出判断这些能力在面试中很难量化但工作中非常重要。8.3 测试与全栈边界在哪里热搜词里出现了“前端和后端”“测试与全栈”这类词这说明很多同学在思考测试岗位和开发岗位的关系。测试和开发的核心目标本身就不同——开发是“构建软件”测试是“评估软件”。两者可以互相学习技能但思维模式有差异。开发思维关注“怎么把功能实现出来”测试思维关注“什么条件下功能会挂掉”。测试工程师没有必要去追求成为全栈开发但有必要理解前端和后端的基本工作原理。比如做接口测试要理解后端如何接收请求、如何返回响应做 UI 自动化要理解前端如何渲染页面、DOM 如何变更。这种“理解”不需要达到开发水平但足以帮助你更高效地设计和执行测试。9. 写在最后回顾开头那个面试场景候选人为什么连“测试核心”都答不出来不是因为他不努力也不是因为他不会用工具而是他在准备面试时只学了“怎么测”没有深入思考“为什么测”和“测的意义是什么”。软件测试的核心从来不是“找Bug”而是通过系统化的质量评估手段为产品交付提供信心。围绕这个核心延伸出的测试原则、测试流程、用例设计方法、缺陷管理、自动化测试体系才是测试工程师真正的知识框架。如果你正在准备测试岗位面试建议按照本文的章节顺序把每个模块都过一遍。重点不是死记硬背概念而是能用自己的话把“为什么这样做”讲清楚。如果你已经是正式测试工程师希望这篇文章能帮你查漏补缺。面试别人时这些内容经常会被问到带新人时这些内容也是最基础的培训材料。如果这篇文章对你有帮助可以收藏备用。后续我还会继续整理测试面试题详解、接口自动化框架搭建、性能测试实战等内容欢迎持续关注。
