12 项目实战指南
12 项目实战指南
测开简历最怕项目太虚。只写「熟悉自动化测试」「会使用 JMeter」「了解 AI 测试」,面试官无法判断真实能力。更好的方式是做 2-3 个能跑起来、能讲清楚的项目。
为什么重要
项目是学习路线的「收口」:前面 11 章的知识,只有落进项目才会变成你的能力。四个项目按递进设计,覆盖面试考察面,每个都有明确的验收标准——做到什么程度算合格,做完可以自己对照打分。
选型原则:
- 项目一必做(接口自动化是地基)。
- 项目二、三按目标岗位二选一或都做(UI 方向 / 性能方向)。
- 项目四是差异化加分项(AI 时代叙事)。
项目一:接口自动化测试框架【必做】
选一个真实或半真实系统:电商、博客、在线教育、后台管理。至少覆盖登录、用户、商品、订单、支付回调这类接口。
核心内容:
- 接口文档解析和测试用例设计。
- 请求封装、鉴权、参数化、数据准备和清理。
- 数据库校验,不能只看接口返回。
- Allure / HTML 测试报告。
- GitHub Actions / Jenkins 自动执行。
- 失败日志、请求响应和环境信息留存。
验收标准(合格线):
- 用例数 50+,正常 / 异常路径比例约 7:3。
- 断言至少三层:HTTP 状态与业务码、响应关键字段、数据库状态校验。
- 连续两周定时执行,无非用例本身原因的失败残留(数据清理干净)。
- 任何人 clone 仓库,配好环境变量就能跑通(README 写清启动步骤)。
- 失败用例在报告里能看到完整请求、响应和日志。
进阶方向: 用例分级与冒烟集合、失败自动重试与分类(环境 / 数据 / 代码)、接入测试数据工厂、增量覆盖率。
面试怎么讲: 目录结构怎么设计、Token 怎么管理、测试数据怎么隔离、怎么避免用例互相依赖、怎么接入流水线。每一点都有「为什么」。
项目二:Web UI 自动化或 App 自动化【选做】
Web 方向建议用 Playwright 或 Selenium,App 方向可以用 Appium。
不要做太多页面,先把主流程做扎实:后台管理系统的登录、用户管理、角色权限、文章发布、订单处理。
核心内容:
- Page Object Model 分层。
- 多环境配置。
- 截图、Trace、失败视频或日志。
- 用例标签:冒烟、回归、核心流程。
- 并行执行和失败重试策略。
- CI 定时执行和报告归档。
验收标准(合格线):
- 15-30 条主流程用例,全部 POM 分层,无线性脚本。
- 无固定 sleep(或有充分理由的例外并注释)。
- 连续 7 天 CI 执行,flaky 率低于 5%。
- 失败回放材料齐全:截图 + Trace + 日志三件套。
- 并行执行时长是串行的一半以内。
进阶方向: 视觉回归(截图比对)、多浏览器矩阵、云真机兼容、selector 自愈机制调研。
面试怎么讲: 重点讲稳定性——元素定位怎么选、等待怎么处理、页面变化后怎么低成本维护、怎么判断失败是脚本问题还是业务问题。
项目三:性能测试与问题定位【选做】
选一个接口链路:商品查询、下单、登录、搜索。
核心内容:
- 压测场景设计:单接口容量、混合场景、峰值场景、稳定性场景。
- JMeter、k6 或 Locust 脚本。
- 监控指标采集:CPU、内存、数据库、Redis、应用日志。
- 性能报告:QPS、P95、P99、错误率和瓶颈分析。
- 至少一次优化前后对比:增加索引、调整连接池、减少慢 SQL。
验收标准(合格线):
- 至少完成两类场景(如单接口容量 + 混合场景),有明确压测模型说明。
- 有完整监控证据链(不是只有压测端 QPS 图),瓶颈结论指向具体层(应用 / DB / 配置)。
- 至少一个「定位 → 优化 → 复测对比」闭环故事:优化前后数据齐备。
- 报告包含结论边界(环境、数据规模、假设)。
进阶方向: 全链路压测思想、影子库 / 流量染色概念、稳定性 8 小时长跑、限流降级验证。
面试怎么讲: 这个项目最适合证明定位问题能力——工具执行只是一环,「我怎么从 P99 陡增定位到慢 SQL / 连接池耗尽」的故事才是主角。
项目四:AI 应用质量评测平台【加分项】
想突出 AI 时代的测开能力,做一个轻量评测平台。比如一个 RAG 问答系统评测工具:
核心内容:
- 支持导入 Golden Set:问题、标准答案、期望引用文档。
- 批量调用 RAG 接口,记录答案、引用片段、耗时和 Token 成本。
- 计算召回命中、答案是否包含关键事实、是否引用正确材料。
- 支持人工打分和失败样本标记。
- 输出对比报告:模型 A 和模型 B、Prompt v1 和 v2、不同 TopK 配置的效果差异。
验收标准(合格线):
- 评测集 30+ 条,覆盖正常 / 边界 / 对抗三类。
- 至少两层评测:规则断言 + LLM 评委(或人工打分表)。
- 至少一组对比实验结论(如两个模型或两个 Prompt 版本的分数对比,含维度拆解)。
- 评测跑批可命令行触发,结果落库或落文件可追溯。
- 有一个 bad case 从发现到归因到进评测集的完整记录。
进阶方向: 接入 DeepEval / RAGAS 替换自研指标、评测进 CI 做 Prompt 变更门禁、线上采样回流、安全评测(注入用例集)。
面试怎么讲: 关键是体现你理解 AI 应用的质量评估方式(非确定性、回归、漂移),而不只是「会让模型回答问题」。能讲清「为什么 benchmark 分数不可信、为什么要建自己的评测集」就已经超过大多数候选人。
学习建议与常见误区
- 边学边做,不要学完再做:学到第 06 章就开始搭项目一骨架,后面每章学完往项目里加一块。毕业时项目是「长」出来的,不是临时拼的。
- 项目要「活」在 GitHub 上:README 清晰、有提交历史(三个月每周提交比一天提交 500 行可信)、有 CI 状态徽章。开源本身就是工程素养证明。
- 误区一:demo 拼盘。 把别人教程的三个项目拼一起,面试一问目录结构为什么这样设计就露馅。每个项目从零搭一遍骨架。
- 误区二:只报喜。 报告里只有成功没有失败记录。实际上「我踩过数据污染的坑,后来加了前置清理」比一切顺利更有说服力。
- 误区三:追求技术名词堆砌。 微服务、分布式、中间件全塞进测试项目。测开项目的评价标准是「稳定、可维护、真发现问题」,不是架构复杂度。
自查清单
- 你的每个项目能用一句话讲清「解决了什么问题、用了什么方案、结果如何量化」吗?
- 项目一的断言有几层?随机抽一条失败用例,你能 3 分钟内定位原因吗?
- 项目二的 flaky 率是多少?怎么治理的?
- 项目三的瓶颈结论有什么证据?优化对比数据是多少?
- 项目四的评测集覆盖哪三类问题?最近一次 Prompt 变更的回归结论是什么?
- 别人 clone 你的项目仓库,多久能跑起来?(超过 30 分钟就该补 README)
推荐资源
- 本仓库 docs/roadmap 各章的「推荐资源」:项目所需技术栈都在其中。
- GitHub 搜索 "api-test-framework pytest" / "playwright-pom":参考优秀开源项目的目录设计(注意:参考结构,不要复制代码当自己的项目)。
- macrozheng/mall 等开源业务系统:找练手被测系统的宝藏库。
- AI 测试开发导航 · 教程专栏:体系化项目实战课程,与本章四个项目配套。