软件测试实战：16个从功能到自动化的练手项目

软件测试入门最尴尬的阶段，就是理论背了一堆，简历上却写不出一个完整的练手项目。现在市面上面试要求里反复出现“熟悉 pytest 框架”“有接口自动化经验”“能独立设计测试用例”，可很多刚转行的朋友连一个像样的项目流程都没完整跑过。这套整理出的 16 个软件测试实战练手项目，从功能测试到接口测试，从手工用例到自动化框架，基本覆盖了测试岗最常问的技能线。我按实际带新人和面试候选人的经验重新梳理了一遍，重点不是让你盲目刷项目，而是每做完一个都知道它对应简历上的哪个能力点，面试被追问时能接得住。

1. 先别急着找项目，先搞清楚练手项目到底在练什么

很多新手看到“实战练手项目”就兴奋，觉得只要照着视频点一遍，简历就有东西写了。实际上项目本身不值钱，值钱的是你在项目里体现出来的判断力。面试官看项目经历，看的不是你“用过 Selenium”还是“用过 requests”，而是你能不能把一条业务链路测清楚，出了问题知道去哪里排查。

1.1 为什么学了很久测试，简历上还是没东西

最常见的原因就是：只学了工具，没跑过完整项目。比如很多人会用 postman 调接口，但不知道接口测试用例该怎么设计边界值；会写几个 pytest 用例，但没做过数据清理和依赖处理；知道要写测试计划，但真给一个系统时不知道从哪个模块开始。

练手项目的作用，就是把“知道”变成“做过”。这个转变最明显的体现，就是你描述项目时不再说“我使用了什么工具”，而是说“我先梳理了核心业务流程，再按模块划分测试范围，最后用 pytest 维护了一套可回归的接口用例”。

另外很多人误以为项目一定要多大、多复杂才有价值。实际不是。一个开源后台管理系统、一个电商 Demo，甚至你自己写的一个待办事项应用，只要流程完整、有数据流转、有异常场景，就可以作为练手对象。重点在于你能否围绕它形成测试产出物：测试计划、用例表、缺陷记录、自动化脚本、测试报告。

1.2 16 个项目的完整清单与阶段划分

这套项目清单整体上分四个阶段，分别对应测试岗位常见的四个能力层级：基础测试设计能力、接口测试能力、自动化框架能力和综合项目能力。

这个清单不是静态的。你完全可以根据自己的基础跳过一部分，也可以把几个项目合并成一个大的综合项目。比如把若依系统作为被测对象，既做功能测试，又做接口自动化，再做 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 个练手项目就不是任务清单，而是一条通往真实测试工作的能力路径。