软件测试入门最尴尬的阶段就是理论背了一堆简历上却写不出一个完整的练手项目。现在市面上面试要求里反复出现“熟悉 pytest 框架”“有接口自动化经验”“能独立设计测试用例”可很多刚转行的朋友连一个像样的项目流程都没完整跑过。这套整理出的 16 个软件测试实战练手项目从功能测试到接口测试从手工用例到自动化框架基本覆盖了测试岗最常问的技能线。我按实际带新人和面试候选人的经验重新梳理了一遍重点不是让你盲目刷项目而是每做完一个都知道它对应简历上的哪个能力点面试被追问时能接得住。1. 先别急着找项目先搞清楚练手项目到底在练什么很多新手看到“实战练手项目”就兴奋觉得只要照着视频点一遍简历就有东西写了。实际上项目本身不值钱值钱的是你在项目里体现出来的判断力。面试官看项目经历看的不是你“用过 Selenium”还是“用过 requests”而是你能不能把一条业务链路测清楚出了问题知道去哪里排查。1.1 为什么学了很久测试简历上还是没东西最常见的原因就是只学了工具没跑过完整项目。比如很多人会用 postman 调接口但不知道接口测试用例该怎么设计边界值会写几个 pytest 用例但没做过数据清理和依赖处理知道要写测试计划但真给一个系统时不知道从哪个模块开始。练手项目的作用就是把“知道”变成“做过”。这个转变最明显的体现就是你描述项目时不再说“我使用了什么工具”而是说“我先梳理了核心业务流程再按模块划分测试范围最后用 pytest 维护了一套可回归的接口用例”。另外很多人误以为项目一定要多大、多复杂才有价值。实际不是。一个开源后台管理系统、一个电商 Demo甚至你自己写的一个待办事项应用只要流程完整、有数据流转、有异常场景就可以作为练手对象。重点在于你能否围绕它形成测试产出物测试计划、用例表、缺陷记录、自动化脚本、测试报告。1.2 16 个项目的完整清单与阶段划分这套项目清单整体上分四个阶段分别对应测试岗位常见的四个能力层级基础测试设计能力、接口测试能力、自动化框架能力和综合项目能力。阶段项目名称核心锻炼点简历对应能力入门注册登录模块功能测试等价类、边界值、用例设计测试用例设计入门购物车与订单流程测试业务流程梳理、状态流转业务链路分析入门文件上传下载模块测试文件类型、大小、并发、权限异常场景覆盖入门移动端 APP 冒烟测试安装、启动、登录、核心流程冒烟测试执行入门开源后台管理系统测试系统测试全流程独立执行测试接口公共 API 接口测试请求方法、参数、状态码接口测试基础接口requests pytest 接口自动化断言、参数化、前置后置接口自动化脚本接口带 Token 和签名接口测试鉴权、加密参数、动态数据鉴权场景验证接口数据驱动接口测试框架数据驱动、配置文件、日志测试框架思维自动化Selenium Web UI 自动化元素定位、等待、常用操作UI 自动化自动化PO 模式自动化框架页面对象封装、分层设计测试框架设计自动化Allure 报告 日志采集报告生成、日志定位测试效能优化自动化Jenkins 持续集成定时构建、自动触发CI 集成能力进阶JMeter/Locust 性能测试压测场景、聚合报告分析性能测试基础进阶全链路业务回归测试多模块协同、数据造数系统工程思维进阶AI 软件测试工具评测工具探索、能力边界评估技术敏感度这个清单不是静态的。你完全可以根据自己的基础跳过一部分也可以把几个项目合并成一个大的综合项目。比如把若依系统作为被测对象既做功能测试又做接口自动化再做 UI 自动化最后挂到 Jenkins 上这就是一个完整度很高的项目集。1.3 怎么判断一个项目“练完了”不要以“能跑起来”作为完成标准。我一般用下面这套判断方式能说明被测系统有哪些核心角色、核心业务和核心数据流。能独立输出一份功能测试用例覆盖正常流和异常流。能说明自动化用例的断言为什么这么写异常数据从哪里来。能演示失败用例的排查路径包括看日志、看请求、看响应、看数据库。能说出如果需求变更哪些用例要改、哪些框架层代码不用动。如果你连“被测系统是给谁用的”都说不清楚项目写进简历基本是送人头。2. 入门阶段的五个项目先把用例设计练扎实进入第一个阶段时不建议碰自动化。功能测试和用例设计是所有测试工作的地基也是面试里最容易考察的点。面试官可能不会让你手写一个 pytest 用例但一定会问“登录功能你会怎么测”。如果你能从页面、接口、数据、安全几个维度列出来而不是只回答“输入正确用户名密码能不能登录”这一关就能过。2.1 登录注册模块测试用例设计的试金石几乎所有测试面试都会聊登录。原因很简单登录模块短小但场景丰富有输入校验、有接口调用、有鉴权逻辑还涉及用户状态和密码规则非常适合考察用例设计能力。练这个项目时第一件事不是打开页面乱点而是画出登录注册的功能规则。比如密码长度限制、是否区分大小写、是否支持特殊字符、错误提示什么时候出现、连续输错是否锁定、注册成功是否自动登录、同一手机号能否重复注册。再根据这些规则用例设计。我的建议是这样的步骤先用 XMind 或 Word 梳理功能清单然后按输入类、交互类、安全类、兼容类分组设计用例。输入类用等价类和边界值比如 6 到 16 位密码要测 5 位、6 位、16 位、17 位交互类包括回车提交、重复点击、断网重试安全类包括弱口令、连续失败、验证码绕过这类常规项。登录项目写进简历时重点不是“研究了登录功能”而是“负责用户认证模块测试设计用例 40 条发现密码规则不统一、验证码过期提示不准确等缺陷推动开发修复”。2.2 订单、上传下载、移动端冒烟覆盖常见业务形态登录练完就要让项目覆盖面更广一些。购物车与订单流程是电商系统最常见的业务链路它的价值在于状态流转非常清晰加购、下单、支付、发货、收货、售后。测试时不能只看单页面要关注数据在多个状态之间是否一致。比如商品下单后库存扣减在什么时间点发生取消订单后库存是否回补支付超时后订单状态怎么变化。文件上传下载模块也很适合练手因为你很容易构造异常场景。文件类型方面可以刻意上传 exe、空文件、超大文件、重名文件、超长文件名权限方面可以区分游客、普通用户、管理员并发方面可以同时多个用户上传或下载空闲目录方面要考虑磁盘满、目录不存在等极端情况。移动端 APP 冒烟测试不用做得太深可以作为功能测试的补充。找一款常见的资讯或工具类 APP设计一张冒烟测试用例表覆盖安装、启动、注册登录、首页加载、列表滑动、详情页打开、分享、退出登录等主流程即可。这个项目在简历上能体现你有移动端测试意识。2.3 开源后台管理系统一个能长期练手的测试对象从第十六个项目倒推回来如果你希望有一个项目能从功能测试一直练到自动化框架我比较推荐直接用若依这类开源后台管理系统作为被测对象。这类系统通常自带用户管理、角色管理、菜单权限、日志管理、部门管理等模块业务规则清晰数据流转完整而且本地能部署起来。用它练功能测试时可以围绕“管理员创建用户并分配角色再验证不同角色看到菜单不同”这类权限模型展开。这里面最大的学习点不是操作本身而是“怎么设计权限关联场景的用例”比如新建用户未分配角色时能否登录删除角色后登录用户是否被强制退出修改菜单后缓存是否同步更新。系统测试练完之后这个项目可以无缝衔接接口测试和自动化测试不会浪费。哪怕最后只是把它作为一个长期测试环境用来练习造数、验证脚本稳定性也非常有价值。3. 接口测试阶段从手工调用到自动化脚本功能测试练得差不多后就要进入接口测试。接口测试是当前测试岗需求最大的一块能力也是简历里最容易出亮点的地方。它不像 UI 自动化那样依赖界面稳定性更容易快速发现底层问题而且自动化维护成本低。3.1 先用本地或公共接口跑通请求接口测试不要一上来就写框架。先用 postman 或 apifox 这类工具把 GET、POST、PUT、DELETE 的基本请求跑明白。建议找一个可以本机部署的项目直接把登录接口、查询列表接口、新增数据接口依次调通。跑接口时重点关注三个部分请求参数怎么传、响应结果怎么解析、状态码和业务码的区别。这个阶段很多人都会忽略业务码。HTTP 状态码是 200不代表接口真的成功也许业务码是 50001 表示“参数错误”。如果接口测试脚本只判断状态码那很多问题都会漏掉。一个合格的接口测试用例至少包含正常参数用例、缺参用例、类型错误用例、边界值用例、鉴权失效用例、重复提交用例。这个阶段练完后你应该能独立说清一个接口的输入、输出、校验规则和异常场景。3.2 用 requests pytest 跑第一条接口自动化工具手工测完再进入脚本阶段。Python 技术栈里最常用的组合就是 requests 加 pytest。requests 负责发送 HTTP 请求pytest 负责用例管理、断言和结果输出。第一条自动化用例不要写得复杂。一个完整的接口测试脚本通常包含四个环节接口请求、状态校验、业务断言、清理数据。很多新手只写前两个环节导致用例跑完以后插入的测试数据堆积在数据库里第二次执行就重复报错。这个问题在面试里经常被问“自动化测试怎么保证用例可以重复执行”答案就是用例结束后清理自己产生的数据或者在用例开头把已知数据状态重置。pytest 框架的价值在这一步会慢慢体现出来。用例怎么写断言fixture 怎么处理登录态conftest.py 怎么统一管理前置操作这些都属于接口自动化的基础工程能力。练到这一步简历里就可以写“基于 requests pytest 实现了登录态自动管理和数据清理接口用例可重复执行”。3.3 带 Token 和签名接口的鉴权测试面试高频点很多项目简单是因为被测接口一调就通不需要身份验证。但真实系统绝大多数接口都带鉴权常见的有 Token、Session、签名、加密参数。面试官最喜欢在这类场景里深挖因为能看出你到底懂不懂业务接口的运行机制。练这个阶段的正确打开方式是先手动获取 Token看它放在请求头还是参数里然后尝试让自动化脚本自动登录并携带 Token 访问业务接口。更进一步可以模拟 Token 过期后重新获取或者不传 Token 直接访问受保护接口验证服务端是否返回统一的 401 状态码。签名接口相对复杂一些比如 MD5、SHA256 这类基础签名方式或者时间戳加随机数防重放。这类接口对测试人员最大的意义不是破解签名而是理解“数据在传输过程中可能被篡改”这个风险点在设计用例时增加签名缺失、签名错误、时间戳过期这三种场景。简历上写这种项目面试官通常会觉得你有真实接口测试经验。4. 自动化框架阶段从“会写脚本”到“搭出体系”能写接口自动化脚本的人不少但能把脚本组织成一个稳定、可维护、可报告体系的并不多。第三个阶段的核心目标就是训练这种框架思维。做自动化测试不是代码炫技而是让团队可以用最低成本维护测试资产。4.1 UI 自动化为什么不能只录脚本很多新手学 Selenium第一步就是录制脚本点两下页面自动生成代码。这种脚本放在面试官面前基本撑不过两分钟因为元素一变化脚本就废而且没有分层思想。UI 自动化的核心不是定位元素而是处理等待问题、环境依赖和用例稳定性。比如登录后跳转页面是使用强制等待、隐式等待还是显式等待页面弹窗偶尔出现时怎么处理测试数据需要依赖前端页面一步步创建时能否改成直接调接口造数。练 Selenium 时我建议选一个相对稳定的网页系统把登录、查询、新增、删除这些常用操作做成一个自动化用例集。你可以刻意把浏览器窗口缩小、网络延迟调大模拟一些非标准环境看脚本是否还能稳定运行。这样练出来的项目才有测试价值而不是演示价值。4.2 PO 模式和数据驱动框架感的来源从“脚本集”走向“框架”最核心的一步是引入页面对象模式也就是 PO 模式。通俗讲就是把页面元素定位和操作行为拆出去一个页面一个类测试用例里只写业务步骤不出现冗长的 find_element 。用登录举例子。如果不用 PO 模式可能会在每个测试函数里写输入框和按钮定位使用 PO 模式后只需要调用 login_page.login(“user”, “passwd”)模块内部去管定位和输入。这样做的好处是页面 UI变动时只需要改一个页面类测试用例几乎不动。在这个阶段还要同步把数据驱动思想加进来。pytest 中用不到参数化测试数据可以从外部 Excel、JSON 或数据库读取。结合之前的文件上传、订单流程项目可以把多条不同状态的订单数据传入同一个测试函数让同一段逻辑执行多次。这就是数据驱动。面试时如果能主动讲清楚“页面层、用例层、数据层为什么分开”基本就达到中级自动化的定位了。4.3 Allure 报告和 Jenkins让项目有交付物框架落到工程层面不能只输出一个 return 0。测试报告和持续集成是自动化测试项目里最容易体现完整度的部分。Allure 可以把 pytest 的执行结果变成图表化报告展示用例数量、通过率、失败原因、步骤日志、缺陷关联情况。Jenkins 则负责做持续集成让代码提交后自动触发测试脚本跑完后把报告发到指定位置。这一步在简历里的价值不只是“会用工具”而是“自动化测试流程跑通了”。比如你可以在项目描述里这样写开发完成后自动触发测试任务测试覆盖 80 个业务接口每日运行时长 15 分钟失败用例自动定位到具体接口和日志。这种表达能体现的不只是技术还有工程化意识。练 Jenkins 时不用单独搭复杂环境本地安装一套即可。重点是理解定时构建和轮询代码仓库的原理然后把之前写好的 pytest 脚本接进去。如果环境允许再增加邮件或企业微信通知跑完立刻收到结果这才算完整闭环。5. 进阶项目性能、全链路回归和 AI 测试前面几个阶段练完后简历已经有功能测试、接口测试、自动化框架三个方向可以写。第四个阶段的任务是让个人技能线更完整也让自己在面对“性能测试有没有做过”“有没有负责过完整项目”这类问题时不至于一句话都接不上。5.1 性能测试脚本重点不是压测而是分析和调优性能测试用 JMeter 或 Locust 都可以新建线程组、设置并发数、配置聚合报告这些操作本身并不难。真正的难点在于怎么判断性能瓶颈到底在哪个环节以及怎么把性能测试结果讲清楚。练这个项目时建议选一个已有接口先定一个低并发目标比如 20 个用户同时查询列表观察响应时间、吞吐量、错误率。然后把并发提到 50、100记录 TPS 和 90% 响应时间的变化趋势。如果响应时间突然飙升就要学会往服务端日志、数据库慢查询、网络带宽这些方向推测原因。简历上写性能测试时要写清楚你测试了什么接口、设置了多少并发、持续多长时间、结果如何、发现问题后怎么定位。这几项信息量化程度越高越有可信度。如果只是写“使用 JMeter 做了压力测试”面试官很难判断你到底掌握多少。5.2 全链路回归测试把单个能力串成一条线单体项目练多了容易养成“只测一个模块”的思维。但真实项目的核心链路往往横跨多个模块比如用户从下单到支付再到查看订单涉及商品模块、订单模块、支付模块、物流模块。全链路回归项目就是为了训练这种“跨模块思考”的能力。建议直接拿一个电商类开源项目或若依后台系统把一条核心用户路径完整走一遍并把它拆解为接口级的回归用例集合。这个过程要处理几个典型问题订单状态依赖前一步操作所以执行顺序很重要支付回调需要模拟所以要用 Mock 或测试环境开关每个用例执行完后要清空数据否则第二次跑用例会被脏数据干扰。完成这个项目后你的简历上就可以写“负责电商核心链路的功能与接口回归覆盖登录到订单完成全流程总结出 30 条可复用回归用例”。这个描述就非常贴近真实工作。5.3 AI 软件测试工具评测适合作为加分项近年来 AI 辅助测试工具越来越多可以用来生成用例、分析缺陷、辅助接口字段补全。这类工具还在快速变化之中不建议当作唯一项目但非常适合作为“技术敏感度”的加分项。练这个方向时可以选一两款常见的 AI 编程或测试辅助工具围绕某个已有练手项目观察它们能否生成可运行的 pytest 用例能否识别登录模块中的边界值漏洞能否根据失败日志定位异常字段。完成评测后写一份简短的对比报告包括工具处理什么场景有效、什么场景容易瞎编、什么人适合使用。这份报告本身就能体现学习能力和判断力放在简历“项目总结”或“技术思考”里都有加分作用。6. 简历怎么写项目描述和面试追问准备项目练完只是第一步怎么把它转化到简历上同样需要刻意练习。很多人“练的时候很熟写的时候很虚”就是因为缺少一套把实践过程结构化的方法。6.1 简历项目描述的四段式结构我比较推荐一段项目经历按四个部分来写项目背景、个人职责、核心技术、量化结果。比如“项目背景公司内部后台系统需要提升回归效率手工执行一次回归需要约 3 小时。个人职责负责核心模块的测试用例设计和自动化框架搭建。核心技术基于 pytest requests 实现接口自动化使用 PO 模式封装前端元素Jenkins 定时触发执行。结果接口自动化覆盖 60 个核心接口回归时长缩短到 30 分钟缺陷发现前置到开发阶段。”这个结构的好处是每一句都能被面试官继续追问。写“手工回归 3 小时”面试官就可能问“手工回归一般做哪些用例”写“接口自动化覆盖 60 个接口”就可能问“60 个接口怎么统计的失败用例怎么处理”。所以简历上的每一句话都要确保自己有真实细节支撑。6.2 不同岗位的侧重点测试岗位并不是只有一种写法。偏功能测试的岗位简历重点写用例设计流程、业务梳理和缺陷管理偏自动化测试的岗位重点写框架选型思路、脚本组织方式、报告与持续集成偏测试开发或工具链方向重点写数据驱动、接口平台化、日志埋点和脚本封装能力。建议针对不同岗位准备两到三个项目描述版本。比如说投功能测试岗时把常用 Assert、PO 模式这些关键词放在次要位置投自动化测试岗时要明确写出框架结构、数据来源、执行方式和结果归集方式。对面试官来说最怕看到“技能列表什么都会”项目描述却什么都说不深。6.3 面试官追问时的高频问题这些练手项目做完后建议提前准备以下常见追问“登录接口用例怎么保证重复执行”“如果某个用例今天通过明天失败你会怎么排查”“pytest 的 fixture 和 conftest 你平时怎么用的”“接口自动化脚本中 Token 过期怎么处理”“UI 自动化遇到动态元素怎么定位”“性能测试发现响应时间慢你会从哪里开始查”这些问题没有一个标准答案但都能在练项目过程中找到真实依据。遇到回答不了的细节老老实实说“这个场景我在项目里还没有碰到但按目前的理解我会先查……”会让面试官觉得你有边界意识比硬编一个答案好很多。7. 练手时最容易踩的坑和统一的排查思路做项目过程中肯定会碰到各种环境、脚本、数据、框架问题。这个部分是我最想提前给你打预防针的地方。不要一报错就怀疑自己不适合学测试很多问题不是你能力不行而是排查顺序不对。7.1 环境部署问题先拆分变量本地起项目失败是最常见的。可能的原因包括 JDK 或 Python 版本与项目要求不一致、数据库没有初始化、端口被占用、配置文件里的 IP 或账号密码不对、依赖包没有安装完整。排查顺序建议是先看启动日志的第一处报错再检查配置文件然后确认数据库和服务是否真正启动最后看依赖版本。这个顺序非常关键。很多人一看到红色报错就开始上网搜“怎么办”其实大部分报错只要往上一翻就能看到具体原因。如果某个依赖包安装失败优先检查是不是 Python 版本和 pip 源的问题。养成“从日志里找答案”的习惯对测试工作来说比任何工具都重要。7.2 测试数据和用例设计问题先理解规则再写用例做接口测试时经常出现“用例失败但接口本身没毛病”的情况。这类问题大部分出在测试数据上。比如一条用例预期新增用户成功结果第二次执行时用户已经存在数据库唯一索引直接报错。这不是被测接口的缺陷而是用例没有做好数据清理。写用例前先把业务规则梳理清楚至少要看明白数据从哪里来、约束条件是什么、执行完应该落在什么状态。如果被测系统有测试数据生成接口优先使用动态数据如果没有可以在步骤里先执行一次新增再用当前生成的 ID 去做之后的查询或更新。7.3 自动化稳定性问题先定位用例还是框架自动化用例不稳定经常会遇到昨天跑得好好的今天突然挂了本地能过Jenkins 上就失败换个浏览器就报错。这类问题不要急着改代码先确认变化了什么。是不是测试环境数据变了是不是页面元素属性更新了是不是等待时间不够是不是运行服务器和本地的用户权限不一样。很多时候失败原因不在代码本身而是环境差异。所以要尽量让脚本不依赖硬编码的测试数据和固定执行顺序。一个用例的执行结果不应该被另一个用例影响也不应该依赖当前页面停留在某个状态。7.4 不要把“跑通”当“完成”最后一个提醒也是最容易忽视的。练手项目真正练出来的不是那几条脚本而是你面对一个不确定问题时能不能一步步把原因缩小、定位、验证并解决。跑通只是起点能稳定执行、能处理异常、能解释设计才算真正完成。我在看简历时更愿意录用的人不是项目最多的而是能把自己做过的项目讲清楚边界的人。这个边界就是我知道这个方案解决了什么问题也知道它在什么场景下可能失效。有了这种意识16 个练手项目就不是任务清单而是一条通往真实测试工作的能力路径。