陈祉伊 · 弘成科技（ChinaEdu）实习测试工程师
定制面试手册

分三层说：行业是干什么的 → 弘成在这条链路的哪个位置 → 这对测试意味着什么。不要背公司简介，要落到「所以对测试有什么要求」。

不要编造弘成的具体客户名、营收、上市板块。不确定就说「我了解到的是……可能不全面，您能不能补充一下」，反而显得诚实。

按「人 → 事 → 数据」三条线讲，能画出来最好（面试时可以在纸上画）。

角色：学生（学员）、教师（主讲/辅导）、教务管理员、院校管理员、学习中心/招生老师、平台运营、系统管理员。

主流程模块：

• 招生报名：注册、实名认证、报读层次/专业、缴费、审核、学籍注册
• 教学：课程资源、直播/录播、学习计划、课件上传与转码、学习进度记录
• 学习：看课、计时、作业提交、讨论答疑、互评
• 考试：题库、组卷、预约考试、在线答题、交卷、判分（客观自动/主观人工）、成绩发布
• 教务：排课、选课、学分认定、成绩管理、毕业审核、证书发放
• 支撑：消息通知、支付、短信、文件存储、统计报表、权限与日志

四个区别，能说出三个就算过关：

这道题考的是「结构化思维」，用固定的六维框架答，条理立刻出来。

1. 业务流程维度：报名→缴费→学籍→选课→学习→作业→考试→成绩→学分→毕业，逐段验证主流程能走通。
2. 角色权限维度：做权限矩阵，重点测越权与数据隔离。
3. 规则算法维度：学时统计、成绩计算、学分认定、毕业判定，用判定表 + 边界值。
4. 数据维度：字段校验、精度（成绩保留几位）、一致性（前端/接口/库三处对齐）、历史数据兼容。
5. 异常与容错维度：断网、弱网、重复提交、超时、并发、断电中断续考、文件过大。
6. 非功能维度：性能（选课/交卷峰值）、兼容性（浏览器 + 安卓/iOS + 分辨率）、安全（越权、SQL 注入、敏感信息脱敏）、易用性。

准备 5 个，每个都能说到「难在哪 + 怎么测」。

被追问「你压测过吗」——不要硬吹。答：没独立做过，只用 JMeter 跟着教程跑过简单脚本，思路清楚但没实战，这是我实习期最想补的。

把「标准」拆成 5 个可交付物，说得出具体内容，就比 90% 的候选人强。

1. 流程标准：需求评审 → 测试方案 → 用例评审 → 执行 → 缺陷管理 → 回归 → 测试报告 → 上线检查，每一步的输入输出和责任人。
2. 用例标准：用例模板（前置条件/步骤/预期/优先级/关联需求）、用例分级（P0 主流程 / P1 重要 / P2 一般）、公共用例库（登录、权限、导入导出、分页、文件上传这些可复用场景）。
3. 缺陷标准：缺陷分级定义（P0 阻塞/P1 严重/P2 一般/P3 建议）+ 缺陷单必填要素 + 什么情况必须挂起/打回。
4. 准入准出标准：提测准入（冒烟通过率 100%、无 P0/P1 遗留）、上线准出（P0/P1 清零、用例执行率、回归通过率）。
5. 测评与报告标准：按质量特性（功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性、可移植性）逐项给结论，附环境、用例、问题清单、结论与建议。

认证测评 = 依据某个标准/规范，对软件逐项验证并出具结论。核心是「有依据、有过程、有证据、有结论」。

报告结构：

1. 测评概述：被测系统、版本、委托方、测评目的与依据（引用的标准号和条款）
2. 测评环境：服务器配置、客户端环境、网络、数据量、工具
3. 测评内容与方法：按质量特性分项，说明每项用什么方法（功能验证/压力测试/兼容性矩阵）
4. 测评结果：逐项「符合 / 部分符合 / 不符合」，附用例执行记录和截图、日志作为证据
5. 问题清单：编号、描述、复现步骤、严重程度、影响
6. 结论与建议：总体是否通过，遗留问题与风险，改进建议

软件质量模型 GB/T 25000.51（对应国际 ISO/IEC 25051）是测评类工作最常引用的标准之一；教育领域还有教育管理信息化系列标准、JY/T 系列教育行业标准。说得出「25000 的八大质量特性」，会让人明显感觉你做过功课。

• 等级保护 2.0：教育类系统一般要过等保测评，涉及身份鉴别、访问控制、安全审计、数据完整性与保密性、备份恢复。
• 个人信息保护法 / 数据安全法：学生姓名、身份证、手机号、成绩属个人信息，需最小必要收集、明确授权、加密存储、脱敏展示。
• 未成年人保护：涉及未成年学员时，信息处理有更严格要求。
• 数据留痕与不可篡改：成绩修改、学籍变更要有操作日志（谁、什么时候、改前改后）。

先讲方法（判定表 + 边界值 + 状态迁移），再讲要注意的坑。

第一步，把规则问清楚：学时怎么算（只看有效播放？拖动进度算不算？倍速算不算？后台挂机算不算？）；学分怎么给（学时达标 + 作业完成 + 考试及格，三者关系是「且」还是「或」）。

第二步，列判定表：条件（学时分 达标/不达标、作业 已交/未交、成绩 及格/不及格、是否退课）→ 动作（给学分/不给/待定）。

第三步，打边界：要求 30 学时 → 测 29:59、30:00、30:01；成绩 60 分及格 → 测 59、59.5、60；累计学时跨天、跨设备、断点续看是否重复计时。

第四步，测状态回退：退课、重修、成绩复议后，学分和学时要不要回退？已发的证书怎么办？

为什么难：Excel 模板字段多、格式杂（日期、数字、身份证前导零、合并单元格），用户不会按模板填；数据量大时超时；部分成功部分失败的提示不清；重复导入造成脏数据。

测试点：

• 模板正确时正常导入；字段缺失/多列/顺序打乱
• 类型错误（日期写成文本、成绩写成中文）、超长、空值、特殊字符
• 身份证号、学号前导零是否被 Excel 吃掉
• 重复数据（同学号二次导入）是覆盖还是报错
• 大数据量（1 万条）耗时与超时提示
• 部分失败时：成功的入库了没有？失败原因能不能定位到第几行？能否下载错误清单？
• 导出：字段是否脱敏、导出条数上限、文件名与编码（中文乱码）、大数据量是否异步

1. 需求评审：读需求文档/原型，提问澄清，输出「需求疑点清单」，同时开始想测试点。
2. 测试计划/方案：范围、策略、资源、环境、排期、风险。
3. 用例设计：按模块拆测试点 → 用等价类/边界值/场景法写用例 → 用例评审（开发、产品一起过）。
4. 提测与冒烟：开发提测先跑冒烟，主流程不通直接打回。
5. 执行测试：按优先级执行，发现问题提缺陷单，跟踪修复。
6. 回归测试：验证已修复缺陷 + 跑核心用例集防止引入新问题。
7. 测试报告与上线：统计用例执行率、通过率、缺陷分布，给出是否可上线的结论；上线后跟进线上问题。

八要素：用例编号、所属模块/关联需求、用例标题、优先级、前置条件、测试步骤、测试数据、预期结果（+ 实际结果、执行状态）。

好的标准：

• 可执行：换个人照着做也能跑，不依赖写用例的人的记忆
• 可判定：预期结果明确，不是「正常显示」而是「显示『提交成功』toast，列表新增一条记录，状态为待审核」
• 独立：一条用例验证一个目的，不要一条用例里塞 10 个检查点
• 可复用：公共场景（登录、分页、上传）抽成公共用例

差：「测试登录功能是否正常」。
好：「输入正确手机号和验证码，点击登录 → 跳转首页，右上角显示用户昵称，token 写入本地，数据库 last_login_time 更新」。

等价类：把输入划分成若干区间，每个区间取一个代表值，用最少的用例覆盖最多的场景。分有效等价类（合法输入）和无效等价类（非法输入）。

边界值：bug 最容易出在边界上，所以专门取边界的值（等于、略大于、略小于）。

先把业务流程画成流程图（节点 + 判断），再从中提取两条线：

• 基本流：一条路走到底的正常路径（借书成功）
• 备选流：每个判断点的异常分支（库存不足、超期未还、被冻结、余额不够罚款）

然后把基本流和各个备选流组合，得到完整场景集。

基本流：登录 → 检索图书 → 点击借阅 → 校验库存/借阅上限/账户状态 → 扣库存 → 生成借阅记录 → 提示成功。
备选流：库存为 0、已达借阅上限（比如 5 本）、有超期未还、账户被冻结、并发同时借同一本、提交中断网。

当多个输入条件组合起来决定输出时用，典型就是「规则类」需求：报名资格、优惠、学分认定、毕业审核。

判定表四部分：条件桩（有哪些条件）、条件项（每个条件取真/假）、动作桩（有哪些结果）、动作项（每个组合对应的结果）。

条件：学历符合？ / 年龄满 18？ / 已缴费？ / 材料齐全？ → 动作：审核通过 / 驳回并提示原因 / 待补充材料。
4 个条件 2⁴=16 种组合，去掉不可能的（未缴费但材料齐全仍可待缴），剩下的逐一验证提示是否准确。

基于经验直接猜哪里容易错，比如：空值、超长、特殊字符、0、负数、重复提交、并发、越权、断网、返回后退、刷新、跨时区、大小写、emoji。

新建（New）→ 指派（Assigned）→ 开发确认/修复中 → 已解决（Resolved）→ 测试验证 → 关闭（Closed）。
分支：打回/重新打开（Reopen）（没修好或复现）、延期（Deferred）、不予修复（Won't fix）、重复（Duplicate）、非缺陷（Not a bug/By design）。

1. 标题：模块 + 条件 + 现象（「图书借阅-已借满 5 本时仍可继续借阅」），一眼能看懂
2. 环境：系统/版本/浏览器或机型/账号/数据
3. 前置条件：比如账号已借 5 本
4. 复现步骤：编号、可重复、不夹带推测
5. 预期结果 / 实际结果：分开写，别混在一起
6. 严重程度 + 优先级
7. 附件：截图/录屏/日志/接口请求响应

注意：「严重程度」看影响面，「优先级」看修复急迫性，两者可以不一致——比如首页错别字影响所有人（优先级高）但严重程度低。

1. 先确认事实：翻需求文档/原型/接口文档，看有没有明确说明。有依据就摆依据，别争论。
2. 没依据就升级判断标准：从「用户会不会被误导/数据会不会错」的角度讲影响，而不是「我觉得不合理」。
3. 拉产品定：产品和开发、测试三方确认，结论写进需求或缺陷单备注，留痕。
4. 接受结论但要留记录：如果最终不改，把风险写进测试报告，注明「已知问题，产品确认为设计如此」。

• 冒烟：新版本提测时先跑核心主流程，快速判断「这个版本值不值得测」，不通就打回。
• 回归：修改缺陷或加新功能后，重跑相关用例 + 核心用例集，确认没引入新问题。分全量回归和选择性回归。
• 验收：由用户/业务方按需求确认「做的是不是他要的」，偏业务验收；也有正式验收测试（如第三方测评）。
• α 测试：开发环境内、由内部人员模拟用户使用。β 测试：真实用户在真实环境使用，收集反馈。

测试计划：测试目标与范围（含不测什么）、测试策略与方法、模块划分与人力排期、环境与数据准备、准入准出标准、风险与应对。

测试报告：版本与环境、测试范围、用例执行情况（总数/执行/通过/失败/阻塞）、缺陷统计（按模块/等级/状态分布）、遗留问题与风险评估、结论（建议上线/有条件上线/不建议上线）、附件（缺陷清单）。

报告不是流水账，核心是「结论 + 支撑结论的数据 + 遗留风险」。面试官问这个，是在看你有没有「对结论负责」的意识。

准入（能不能开始测）：需求/设计文档已评审、开发自测完成、冒烟用例 100% 通过、测试环境与数据就绪、提测说明（改动点/影响范围）齐全。

准出（能不能上线）：P0/P1 缺陷清零、P2 有明确处理计划、用例执行率 100%（未执行需说明原因）、核心用例通过率 100%、回归通过、性能与兼容性达标、测试报告已出。

• V 模型：开发一侧从需求→概设→详设→编码逐层下降，测试一侧从单元→集成→系统→验收逐层上升，需求与验收对应、概设与系统测试对应、详设与集成测试对应。强调测试阶段与开发阶段一一对应。
• W 模型（双 V）：在需求、设计阶段就同步开展测试准备（需求分析→测试方案，设计→用例），把测试提前，本质是测试左移。
• 敏捷测试：迭代内持续测，强调自动化、持续集成、全员质量、快速反馈，用例轻文档、重沟通。

左移：把质量活动提前到需求和设计阶段——参与需求评审、做需求可测性分析、写用例前置、代码评审、单元测试、静态检查。目的是「缺陷发现得越早，修复成本越低」。

右移：把质量活动延伸到上线之后——灰度发布、线上监控告警、日志分析、用户反馈跟踪、线上问题复盘。目的是「线上才是真实的测试环境」。

三个层次：

• 需求覆盖：做需求-用例追踪矩阵（RTM），每条需求至少对应一条用例，评审时逐条核对，防止漏测功能。
• 场景覆盖：主流程 + 分支流程 + 异常流程，用流程图检查每个判断点是否都有对应用例。
• 代码覆盖（更高阶）：语句覆盖、分支覆盖、条件覆盖，通常配合单元测试和工具统计，实习层面了解概念即可。

S 背景：校园生活 APP，面向在校学生，有注册登录、消息通知、校园服务、个人中心四个核心模块，我在项目里负责测试。

T 任务：功能、接口、兼容性三个维度都要覆盖，还要保证缺陷能闭环。

A 行动：
① 功能上，按模块拆测试点写用例，覆盖正常流程、异常输入、边界值；执行完到 MySQL 查库核对页面和数据库是否一致。
② 接口上，用 Postman 测登录和消息推送接口，重点试了鉴权相关的场景，发现未登录状态访问消息接口仍然返回数据。
③ 兼容性上，在不同安卓机型上跑，发现部分机型页面布局错乱和闪退。
④ 缺陷全部走禅道，按严重程度分级，跟到回归关闭。

R 结果：累计提交 12+ 个缺陷，按严重/普通/优化分类，全部完成回归验证；那个未登录越权的问题修复后，我把同类接口都回归了一遍。

不要一上来就说「技术栈是 Postman、MySQL、禅道」——那是工具清单，不是项目。工具要嵌在行动里说。

① 怎么想到：写登录用例时我在列「未登录状态下各接口应该返回什么」，就把消息接口也列进去了。因为消息是私人数据，未登录肯定不该拿到。

② 怎么验证：在 Postman 里不带 token（或把 token 删掉、改成过期 token、改成别人的 token）直接请求消息列表接口，返回 200 而且带真实数据；再换另一个用户 ID 请求，也能拿到别人的消息。

③ 怎么定级：这是越权 + 敏感数据泄露，我定的是致命/严重级别（P0-P1），因为不登录就能拿到别人消息，属于安全问题，不是体验问题。

④ 怎么复测：开发加完鉴权后，我回归了三类：无 token、过期 token、他人 token，都返回 401；同时把其他需要登录的接口（个人中心、校园服务）也扫了一遍，确认没有同类问题。

这类问题属于越权访问：横向越权（同级别用户互相访问数据，改 userId）、纵向越权（低权限访问高权限接口，改 role）。防御靠服务端鉴权 + 数据归属校验，不能只靠前端隐藏入口。

1. 先确认现象可复现：固定条件（同一本书、同一账号、同样操作）重复操作，看是否稳定超时，排除偶发。
2. 用 Fiddler 抓包看请求本身：请求参数对不对、有没有重复请求、请求发出到收到响应各花了多久（Fiddler 的 Timelines 能看出是卡在等待响应还是传输）。
3. 用 Postman 单独打接口：绕过页面直接请求同一接口，如果还是超时，说明不是前端问题；再换简单参数（比如借一本库存充足的书）对比，缩小到具体条件。
4. 看服务端线索：请后端看日志和慢查询——最后定位到借阅时联表查询库存和借阅记录，数据量上来后 SQL 慢。
5. 修复后复测：同样条件连续操作，记录响应时间；再补大数据量场景（比如某本书借阅记录很多）验证。

-- 1. 看这个用户当前的借阅记录（未归还的）
SELECT COUNT(*) FROM borrow_record
WHERE user_id = 1001 AND status = 'BORROWED';

-- 2. 看图书库存是否被正确扣减
SELECT book_id, stock, total FROM book WHERE book_id = 2001;

-- 3. 联表核对：借阅记录里的书，库存和状态是否对得上
SELECT b.book_id, b.title, b.stock, COUNT(r.id) AS borrowing
FROM book b LEFT JOIN borrow_record r
  ON r.book_id = b.book_id AND r.status = 'BORROWED'
GROUP BY b.book_id, b.title, b.stock;

如果被问「你会写多复杂的 SQL」——如实说：单表、多表关联、分组统计、子查询都能写，窗口函数和复杂优化还在学。

建议这样归类回答：功能类（约 6 个：登录验证码、消息未读数、头像上传、页面跳转、表单校验、列表分页）、接口/安全类（1-2 个：未登录越权）、兼容性类（2-3 个：机型布局错乱、闪退）、体验类（2-3 个：文案、loading、空状态）。

印象最深的：用 Q27 的越权问题回答，因为它体现「靠设计场景而不是靠乱点」。

选机原则：覆盖主流品牌 × 不同安卓版本 × 不同屏幕分辨率 × 高中低端配置，不追求数量追求覆盖度。

典型组合：华为/荣耀（鸿蒙或高版本安卓）、小米/红米（中低端走量机型）、OPPO/vivo、三星（海外）、再加一台低配老机型测性能。

测什么：安装卸载升级、启动速度、页面布局（刘海屏/长屏/字体放大）、图片视频显示、权限弹窗、后台切换、弱网、闪退与崩溃日志。

可说三件事：① 用例库按模块重新归类，统一了用例标题和步骤的写法；② 维护缺陷列表/回归清单，每次版本更新同步；③ 整理测试小结，记录本轮范围、缺陷数、遗留问题。

① 承认，不含糊：「对，自动化和性能我目前只是了解概念，没有实战。」

② 给替代价值：我这个岗位现阶段要做的是业务测试和测评，核心竞争力是懂业务、拆得细、文档规范、缺陷说得清，这三样我是有实战的；而且我有真实的缺陷闭环经验，不是只会做课程作业。

③ 给路径：我了解自动化是 Python + requests/pytest 做接口自动化，性能是 JMeter 做脚本、加压、看 TPS 和响应时间分布；如果实习有这块，我愿意在下班后补，先从接口自动化开始，因为接口自动化投入产出比最高。

这个「失误」答得好，因为它证明你会复盘，而不是「我最大的缺点是太追求完美」。

inner join：只返回两表都匹配上的行。left join：以左表为主，左表全部保留，右表没匹配到的字段为 NULL。

-- 场景：查所有学生及其选课情况，没选课的也要列出来
SELECT s.id, s.name, c.course_name
FROM student s
LEFT JOIN course_selection cs ON cs.student_id = s.id
LEFT JOIN course c ON c.id = cs.course_id;

-- 如果换成 INNER JOIN，没选课的学生就查不出来了

SELECT course_id,
       COUNT(*) AS 总人数,
       ROUND(AVG(score), 2) AS 平均分,
       ROUND(SUM(CASE WHEN score >= 60 THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS 及格率
FROM score
GROUP BY course_id
HAVING COUNT(*) >= 10;   -- 只统计人数≥10 的课程

考点：group by 分组、聚合函数、CASE WHEN 做条件计数、HAVING 过滤分组结果（where 过滤行，having 过滤组）。

where 在分组前过滤行，不能使用聚合函数；having 在分组后过滤组，可以用聚合函数。执行顺序：from → where → group by → having → select → order by → limit。

写法一：NOT IN
SELECT * FROM student
WHERE id NOT IN (SELECT student_id FROM course_selection WHERE student_id IS NOT NULL);

写法二：LEFT JOIN + IS NULL（大表时性能更好）
SELECT s.* FROM student s
LEFT JOIN course_selection cs ON cs.student_id = s.id
WHERE cs.student_id IS NULL;

NOT IN 的子查询里如果有 NULL，整个结果会变成空——这是很经典的陷阱，测试时如果发现「查不到数据」，先怀疑这个。

索引像书的目录，能让查询不用全表扫描。MySQL InnoDB 默认用 B+ 树。

常见失效场景：

• 在索引列上做运算或函数：where date(create_time) = '2026-10-01'
• 隐式类型转换：字段是 varchar，查询传了数字
• like '%关键字' 前置模糊匹配
• 复合索引不满足最左前缀原则
• 用 or 连接了没有索引的列
• 查询结果占全表比例很大时，优化器可能直接选全表扫描

ACID：原子性（要么全成功要么全回滚）、一致性（约束不被破坏）、隔离性（并发互不干扰）、持久性（提交后不丢）。

四种隔离级别：

delete 是 DML，逐行删、可加 where、可回滚、触发触发器；truncate 是 DDL，清空整表、不能带 where、不可回滚、自增重置、速度快；drop 删表结构和数据。

student(id PK, name, student_no UNIQUE, class_id, status)
course(id PK, course_name, credit, teacher_id, capacity)
score(id PK, student_id FK, course_id FK, score DECIMAL(5,1), exam_type, create_time)
   UNIQUE KEY(student_id, course_id, exam_type)  -- 防重复录入

要测的数据层问题：主键唯一、外键约束、成绩字段精度（DECIMAL 才能存 59.5，FLOAT 会精度丢失）、重复录入被唯一索引拦住、学号唯一、删除学生时成绩怎么处理（级联还是禁删）。

1. 库：直接查库，数据本身对不对？不对 → 写入逻辑/事务问题。
2. 接口：用 Postman/Fiddler 看接口返回，是不是返回了正确数据？返回就对但页面不对 → 前端渲染/缓存/字段映射问题。
3. 前端：清缓存、换浏览器、强刷，排除本地缓存和旧版本。
4. 时机：是不是异步同步延迟（比如统计表定时任务还没跑）？隔一段时间再看。

== 比较的是引用地址（基本类型比较值）；equals 是方法，默认也是比较地址，但 String、Integer 等重写了，比较的是内容。

String 不可变：内部 char/byte 数组被 final 修饰且不对外暴露，任何修改都会生成新对象。好处：可以安全地做常量池复用、hashCode 稳定适合做 Map 的 key、多线程天然安全。

String a = "abc";
String b = "abc";
String c = new String("abc");
a == b        // true  （常量池同一个对象）
a == c        // false （new 出来的新对象）
a.equals(c)   // true  （比较内容）

List 有序可重复、按索引访问；Map 是键值对、key 唯一。ArrayList 底层数组，查询快、中间插入删除慢；LinkedList 双向链表，插入删除快、查询慢。HashMap 用数组 + 链表/红黑树，JDK8 后链表长度超过 8 转红黑树。

list 可变、用 []；tuple 不可变、用 ()，可作为 dict 的 key。可变对象（list/dict/set）做函数参数时会被原地修改，这是常见 bug 来源。

# 一个测试里常用的小脚本：判断用例是否全部通过
cases = [{"name":"登录","pass":True},{"name":"借阅","pass":False}]
failed = [c["name"] for c in cases if not c["pass"]]
print(f"共 {len(cases)} 条，失败 {len(failed)} 条：{failed}")

1. 正常场景：必填参数正确，返回 200 且业务 code 正确、字段值正确、数据库落库正确。
2. 参数校验：必填缺失、类型错误、超长、特殊字符、边界值、多余字段。
3. 业务异常：重复提交（幂等）、状态不合法（已交卷再提交）、越权（他人数据）。
4. 鉴权：无 token、过期 token、伪造 token、低权限访问高权限接口。
5. 异常与容错：超时、下游服务不可用、返回值格式异常时的提示。
6. 性能与安全：响应时间、并发、SQL 注入、敏感字段是否明文返回。

易错点：401 是「你是谁不知道」，403 是「知道你是谁但不让你进」。答反了很扣分。

Cookie 存在客户端；Session 存在服务端，靠 Cookie 里的 sessionId 关联；Token（如 JWT）是把身份信息签名后放客户端，服务端不用存，适合分布式和前后端分离。

测试关注点：token 过期时间、退出登录后 token 是否失效、多点登录策略、token 能否被篡改（改了签名是否校验）、token 是否出现在 URL 里（有泄露风险）。

GET 参数在 URL、有长度限制、可被缓存和收藏、幂等；POST 参数在 body、无长度限制（受服务端配置影响）、不缓存、非幂等。语义上 GET 用于查询，POST 用于提交/修改。

• 抓包看请求：请求头、参数、响应体、耗时，确认前端到底发了什么
• 改包：改参数/改响应，模拟异常返回、绕过前端校验测后端（Composer / AutoResponder）
• 弱网模拟：限速，测加载慢、超时提示
• 定位问题归属：接口返回对但页面不对 → 前端；接口本身错 → 后端

顺序：① 看请求参数是否传对（抓包）→ ② 看返回结构里业务 code 和 message（可能是业务失败但 HTTP 200）→ ③ 查库确认数据源 → ④ 换账号/换数据对比，判断是数据问题还是逻辑问题 → ⑤ 看是否有缓存（同一请求两次结果不同）→ ⑥ 给开发提供请求 ID 和日志。

1. 功能正常：账号密码正确 → 登录成功跳转、显示用户信息、生成会话
2. 账号密码异常：账号不存在、密码错误、密码为空、账号为空、大小写、前后空格是否 trim
3. 输入校验：长度边界（最短/最长/超长）、特殊字符、emoji、SQL 注入串 ' or 1=1 --、XSS 串 <script>
4. 验证码：正确/错误/过期/复用/不填；图形验证码刷新；短信验证码频率限制（60 秒）、错误次数上限
5. 安全与状态：连续错误 5 次是否锁定、密码是否明文传输（https）、是否记住登录、退出后 token 失效、多点登录、越权（改 userId 看别人信息）
6. 兼容与体验：不同浏览器/机型、弱网、断网提示、键盘弹起遮挡、loading 与重复点击

• 正常：答完手动交卷 → 提示确认 → 提交成功 → 显示成绩或待判分 → 数据库答案与试卷状态正确
• 自动交卷：倒计时到 0 自动提交，未答题按空处理；剩余 1 秒时点击提交（边界）
• 中断：提交过程中断网/关浏览器/断电 → 重进是否能续考、已答内容是否保留、剩余时间是否继续走
• 重复提交：连点两次提交、提交成功后退回再提交 → 应幂等，不能生成两份答卷
• 并发：考试结束瞬间大量学生同时交卷 → 不丢卷、响应时间可接受
• 规则：迟到 15 分钟禁止进入、提前交卷限制、切屏次数超限强制交卷、主观题未答能否提交
• 判分：客观题自动判分正确、多选题漏选/错选规则、主观题待人工、成绩精度
• 权限：交卷后不能再改答案、不能看答案、教师端能否看到答卷

• 正常：有名额、未选过、时间在开放区间内 → 选课成功、容量 -1、生成记录
• 规则限制：容量为 0、已达选课上限（如 6 门）、时间未开始/已结束、先修课未通过、专业/年级不符、时间冲突（同一时段两门课）
• 重复：已选过再选、退课后重选、并发点击
• 并发：最后一个名额两人同时抢 → 只能一人成功，容量不能为负（超卖）
• 状态回退：退课是否释放名额、退课后记录是删除还是置为已退、已选人数统计是否同步
• 数据：容量字段与已选人数是否一致、选课记录唯一性

• 正常：jpg/png/pdf 正常上传，大小在限制内，回显正确，可预览可下载
• 格式：不支持的类型（exe、txt 改名成 jpg 的假图片）、大小写后缀、无后缀
• 大小边界：0 字节、刚好限值、超 1KB、超大文件（如 100MB）
• 文件名：中文、空格、特殊字符 #&%、超长、同名文件重复上传（覆盖还是并存）
• 异常：上传中断网、取消上传、上传中关闭页面、多文件同时上传、重复点击上传
• 安全：能否上传脚本文件、上传后能否直接执行、路径穿越（../../）、存储是否可公开访问
• 结果：文件存储路径与数据库记录是否一致、缩略图是否生成、并发上传是否串文件

三层验证：① 界面层——菜单/按钮有没有隐藏；② 接口层——直接调接口有没有被拦（这才是关键，前端隐藏不等于安全）；③ 数据层——改 ID / 改班级参数能不能看到别人的数据。

• 触发：什么事件推（交作业、成绩发布、考试提醒）、推给谁（全班/指定人）、条件是否准确
• 到达：在线 App 内推送、离线推送、已读未读状态、红点数量
• 内容：标题长度、正文超长截断、变量替换（姓名、课程名）是否正确、特殊字符/emoji
• 频次：重复推送、免打扰时段、批量推送（一次推 1 万人）耗时
• 跳转：点通知是否进到对应详情页、登录态失效时跳哪
• 异常：推送服务不可用时业务是否受影响（不能因为推送失败导致交作业失败）

数据（无数据 / 1 条 / 满页 / 多页）、分页（首末页、跳页、每页条数切换、越界页码）、排序（各字段升降序、空值排哪、多字段）、筛选（单条件/组合/清空/筛选后翻页条件是否保留）、搜索（模糊/精确、空结果、特殊字符、超长）、刷新后状态、导出与列表数据是否一致、权限（只看到自己的数据）、性能（万级数据加载）。

先选主流程上、用的人最多、出错代价最大的模块——在教育系统里通常是登录 + 学习/交卷，因为这两个断了整个产品就废了。

怎么测：① 半小时跑冒烟确认主链路通；② 用 P0 用例覆盖核心正向流程；③ 重点补高危场景（权限、重复提交、数据落库）；④ 记录未覆盖范围，写在报告里说明风险。

① 总量：5 万在读学生，假设 80% 参加本次考试 = 4 万人。

② 时间分布：考试窗口假设 3 天，每天 3 场，共 9 场，每场约 4400 人。但实际情况是大家爱赶最后一场，所以按「最后一场占 40%」估，约 1.6 万人。

③ 瞬时：每场 90 分钟，开考后 10 分钟内集中进入，1.6 万人 / 600 秒 ≈ 27 人/秒；交卷更集中，最后 10 分钟交卷 ≈ 27 人/秒，且交卷请求比进入更重（写答案、判分、写日志）。

④ 结论：峰值按 30～50 QPS 量级估，交卷接口是瓶颈；如果系统还带自动保存（每 30 秒存一次答案），那答案保存接口的压力是交卷的十几倍，要先压这个。

1. 影响面：涉及多少用户、是不是主流程
2. 出错代价：错了是体验问题还是要重考/退费/投诉
3. 变更风险：改动大、动了公共模块、动了老逻辑的优先
4. 依赖关系：被别人依赖的先测（不然下游全堵住）
5. 可回退性：出问题能不能快速回滚，不能回滚的优先

然后给结论并说明遗留风险：先测 A，B 做冒烟，C 明确不测并写进报告。

1. 先定结构：按「模块 → 子功能 → 场景」三级组织，用例编号规则统一（如 LOGIN-001），保证能检索、能追溯需求。
2. 再定模板：统一字段（前置条件/步骤/预期/优先级/关联需求/是否自动化），固定写法避免「同一件事三种描述」。
3. 抽公共用例：登录、权限、分页、导入导出、上传、消息这些每个模块都要测的，抽成公共库，避免重复写。
4. 分级：P0 冒烟集（几十条，每次提测必跑）、P1 核心集（回归用）、P2 全量（版本大回归用）。
5. 建立维护机制：需求变更同步更新用例、每次线上问题反补一条用例、定期清理失效用例。

可讲的三个真实素材（挑一个讲）：

1. 用例重排：原来用例按时间顺序堆着，找一条要翻很久 → 我按模块+场景重新编号归类，加了「核心回归」标记 → 后来回归时直接筛标记跑，省了找用例的时间。
2. bug 描述模板：早期 bug 被打回两次 → 我给自己定了个固定格式（环境/前置/步骤/预期/实际/附件）→ 后面基本没有被退回说复现不了。
3. 巡检表：自管会查寝原来凭印象记 → 我做了个固定检查项的表，一条条打勾 → 汇总上报的时候不会漏，也有据可查。

五步（5Why 思路）：

1. 止损：先修数据、先止血（回滚/修正数据/公告），别急着追责。
2. 还原：时间线、影响范围（多少学生、哪些课程）、触发条件。
3. 追因（连问为什么）：为什么显示错 → 统计口径改了 → 为什么没测出来 → 用例里没有这个口径的校验 → 为什么没有 → 需求变更没同步到测试 → 为什么没同步 → 变更流程里没有「影响测试范围」这一环。
4. 改进：流程上补（变更必须通知测试）、用例上补（把这条加进回归集）、监控上补（成绩分布异常告警）。
5. 沉淀：写成案例，团队过一遍。

我会列出必须澄清的问题，去找产品确认：

• 进度怎么算：按视频观看时长？按章节完成数？按课件页数？
• 拖动进度条算不算？倍速播算不算？后台挂着算不算？
• 同一节课看两遍算 100% 还是 200%？
• 换设备/换浏览器，进度是否同步？
• 进度 100% 的判定是等于还是大于等于？差 1 秒怎么办？
• 课程更新加了新章节，已 100% 的学员进度怎么处理？

不要说「我开发学得不好」，也不要说「测试轻松」。要给一个「能力匹配 + 有正向体验」的理由。

① 行业：教育系统的业务复杂度高（多角色、强规则、跟政策挂钩），对测试的严谨度要求比一般 C 端产品高，我想在这种环境里练基本功，而不是只做界面点点点。

② 公司：弘成做的是学历继续教育和院校信息化，是 To B + To C 的模式，客户是院校，交付质量直接关系到学校的教学秩序；而且 JD 里提到标准建设和认证测评，说明这个团队是在建体系，不是纯人力外包式执行，这对新人成长更有利。

③ 岗位：JD 要求的三件事——研究业务、参与标准、做测评——正好是我愿意沉下去做的方向，我更喜欢把一件事拆明白、写成文档，而不是每天点页面。

优点（给证据，别只给形容词）：细 + 有条理。细体现在按标准逐项核对（查寝、查库核对数据）；有条理体现在拆业务会先分层再展开。

缺点（真实、可改进、不影响岗位核心）：① 技术深度不够（自动化、性能没实战）；② 有时候太纠结细节，会在一个不影响用户的问题上花太久，现在会先判断严重程度再决定要不要深挖。

这题决定成败，提前算清楚自己的课表，给出明确答案，不要含糊说「看情况」。

如果实际只能每周 3 天，就诚实说 3 天并说明稳定性；虚报后被拆穿更难堪，而且实习岗最怕的是「来了两周就走」。

是党员：直接说入党时间 + 一句「组织生活让我习惯了按规矩办事、事情有记录」，别展开讲政治。

不是党员（大概率情况）：不解释、不辩护，一句话带过，然后转回能力。

不要说「我准备入党」「我觉得党员不重要」这类话。淡处理，转到「做事有规矩、有记录」，这是测试岗真正在意的。

这个答法比单纯说「能接受」有分寸，显得你有判断力，不是只会说好。

实习岗不要报高价，也不要报「都可以」。给一个区间 + 一句「按公司标准」。

（如果在其他城市，把区间换成当地水平；不确定就说「按公司实习标准，我没有特殊要求」。）

1. 「这个实习岗进来之后，主要会负责哪一类系统的测试？是偏向院校平台，还是偏向测评认证那块？」——显示你认真读了 JD。
2. 「团队现在测试用例和规范这块是已经有体系了，还是正在建？如果我进来，能参与到哪部分？」——对上 JD 的「标准建设」，也显得你想干活。
3. 「如果我这个实习做得不错，团队对实习生的成长路径大概是怎样的？」——表达长期意愿，不油腻。

不要第一轮就问薪资、转正比例、加不加班、能不能远程。也不要问「公司是做什么的」——官网上有的东西别问。