企业官网建设流程全解析

做软件测试这一行，最怕面试官问“你做过什么项目”。很多人八股文背得滚瓜烂熟，等价类、边界值、Pytest、Selenium 张口就来，一旦被问到项目细节，就变成“我跟着视频敲了一个接口自动化框架”。这句话一出口，面试官基本就失去了兴趣。项目经历不是简历上的装饰品，它是测试思维、工具熟练度、需求理解能力和问题排查能力的综合证据。与其纠结背多少道面试题，不如认真做几个能讲清楚、能跑出结果、能应对追问的实战项目。

2026 年的软件测试求职，已经不是“会点功能测试就能进”的阶段了。从招聘要求来看，接口测试、自动化测试、性能测试、持续集成正在从“加分项”变成“基础项”。真正有价值的练手项目，不是把代码抄一遍，而是带着“需求分析→测试设计→执行→缺陷提交→回归→总结”的完整流程去走一遍。这篇文章会提供 16 个有梯度的软件测试实战练手项目，覆盖功能测试、接口测试、自动化测试、性能测试和持续集成，并给出每个项目的测试重点、技术栈、简历写法，以及一套可以直接落地的 pytest + requests 接口测试框架示例。

1. 为什么“项目经历”是软件测试求职的胜负手

先纠正一个观念：项目经历的作用不是“证明你敲过代码”，而是“证明你能解决测试问题”。

面试官问项目，通常围绕三个层次展开：

• 做了什么：你参与的项目是什么类型，你负责的模块是什么。
• 怎么做的：你怎么设计用例、怎么执行、用什么工具、发现了什么问题。
• 遇到什么问题、怎么解决的：比如接口返回不稳定、自动化用例偶发失败、环境数据污染、并发问题如何复现等。

第一层是自我介绍，第二层是能力展示，第三层才是面试官真正想听的。很多人的项目经历死就死在第三层：从来没有独立解决过问题，只完成了“照着文档点按钮”这一步。

所以，练手项目的核心价值在于制造“真实的问题场景”。你不需要真的在公司里做项目，但你需要在一个可控的项目里体验完整的测试生命周期：读需求、写用例、找 Bug、提缺陷、跟踪回归、输出报告。这个过程越接近真实工作，你的简历就越有说服力。

如果你想投的是接口测试或自动化测试岗位，项目里必须有代码，有框架结构，有测试报告，有 CI 集成的痕迹。如果只是手工点了几十个页面，那不叫实战项目，那叫演示操作。

2. 16 个实战项目的整体梯度设计

项目不是越多越好，但必须有梯度。太简单的项目没有区分度，太复杂的项目新手根本跑不通。下面这 16 个项目，按“入门—进阶—综合”三个梯队设计：

这个梯度的设计逻辑很清晰：

• 先功能后自动化：不懂业务和用例设计，直接上手自动化是空中楼阁。
• 先单点后全流程：先测登录，再测整个后台系统，最后测一个可部署的完整项目。
• 先手工后工具集成：当用例数量超过人工回归的承受范围时，自然的下一步就是自动化。

下面按梯队逐个拆解。

3. 入门梯队：功能测试与测试用例设计

很多人认为功能测试“没有技术含量”，这是很大的误解。功能测试的核心不是“点按钮”，而是用一套系统的方法找出别人找不到的缺陷。面试官考察应届生或转行者时，最喜欢通过功能测试用例设计来判断“这个人有没有测试思维”。

3.1 用户登录、注册与密码找回模块测试

这是最经典、最适合入门的练手项目。几乎所有系统都有登录注册模块，资料多、参考多、逻辑清晰，非常适合练手。

测试重点包括：

• 等价类划分：用户名长度 6-20 位、密码复杂度、邮箱格式。
• 边界值分析：用户名为 5 位、6 位、20 位、21 位时的校验逻辑。
• 异常场景：密码错误次数达到阈值是否锁定、验证码过期或错误、账号被禁用。
• 安全测试基础：密码是否明文传输、是否存在 SQL 注入风险、登录状态是否可被篡改。
• 状态流转：密码找回时，验证码、邮件链接、重置密码三者之间的状态关系。

一个合格的功能测试项目，产出的不该只是“我测了登录”，而是一张结构化测试用例表和一个缺陷报告。建议你至少设计 30 条登录模块测试用例，并尝试用禅道或飞书表格管理 Bug。

3.2 电商购物车功能测试

购物车是电商系统里业务逻辑比较密集的模块，适合锻炼业务分析能力。

测试重点包括：

• 基础功能：加入购物车、修改数量、删除商品、清空购物车。
• 价格计算：商品单价、数量、优惠券、满减规则之间如何计算，是否存在精度丢失。
• 库存校验：加入购物车时库存充足，下单时库存不足，购物车数量是否会被限制。
• 登录状态：未登录能否加入购物车？登录后购物车是否同步？
• 多端同步：Web 端加购，App 端是否可见。

这个项目的关键难点在于“价格计算”和“库存校验”。你可以尝试用 Excel 维护一组测试数据，比如满 100 减 10、叠加优惠券、VIP 折扣等场景，这是后面接口测试中很好的数据基础。

3.3 学生信息管理系统 CRUD 测试

找一个开源的学生信息管理系统或图书管理系统，练习最基础的增删改查测试。

测试重点包括：

• 新增功能：必填项为空、字段超长、重复数据、特殊字符、日格式校验。
• 查询功能：模糊查询、组合条件查询、分页查询、无数据时的提示。
• 编辑功能：修改后是否能正确保存、修改关键字段是否有确认提示。
• 删除功能：删除不存在的数据、删除后列表刷新、是否有二次确认。
• 数据一致性：新增一条数据后立即查询，是否立刻可见。

这个项目表面简单，但完全可以体现“细心”这个测试人员最重要的品质之一。我建议把测试结果和缺陷截图整理成一个文档，既能证明你做了，也能在面试时展示。

3.4 待办事项应用测试

待办事项应用（Todo App）非常适合练“状态流转”测试。因为待办事项有“待开始、进行中、已完成、已过期”等多个状态，每个状态的转换规则都比较明确。

测试重点包括：

• 创建待办事项时，是否有完成截止时间、提醒时间、优先级等字段。
• 修改截止时间后，状态是否从“待开始”变为“已过期”。
• 勾选完成后再取消完成，状态是否正确回退。
• 清空已完成事项后，列表数量和搜索结果显示是否正常。
• 如果是单页应用（SPA），刷新页面后数据是否持久化。

3.5 搜索、筛选与排序功能测试

查询类功能是许多测试岗位日常工作中最高频的内容。搜索功能看起来简单，但涉及数据库查询逻辑和索引设计，非常容易出 Bug。

测试重点包括：

• 搜索关键词为空、单个字符、全名、部分匹配、大小写混合。
• 筛选条件组合：分类 + 价格区间 + 品牌同时生效时的结果。
• 排序规则：按时间倒序、价格升序、销量降序，以及多次点击后是否稳定。
• 翻页与总数：最后一页是否为空、搜索结果总数是否统计正确。
• 敏感词和特殊字符：搜索<script>或%时系统表现。

4. 进阶梯队：接口测试与自动化框架

接口测试是软件测试求职的“必考科目”。原因很简单：现在的系统几乎都是前后端分离，接口是前后端协作的契约，接口出问题，页面一定出问题。接口测试比功能测试更稳定、更高效，也更容易自动化。

4.1 RuoYi 若依后台管理系统接口测试

RuoYi（若依）是一个基于 Spring Boot 的开源后台管理系统，模块非常完整，包括用户管理、角色管理、菜单管理、部门管理、岗位管理、通知公告、系统监控等。它是最适合做接口测试实战的开源项目之一，原因有三个：

• 有完整的前后端代码和数据库脚本，本地环境容易跑通。
• 接口采用 RESTful 风格，路径清晰，例如/system/user/list。
• 有登录鉴权机制，可以实际练习 token 管理和权限校验。

接口测试重点包括：

• 登录接口：正常登录、错误密码、账号不存在、用户被禁用。
• 鉴权验证：不携带 token 访问用户列表接口，应该被拒绝。
• 用户管理：新增用户、查询用户、修改用户、删除用户、重置密码。
• 角色权限：低权限用户访问高权限接口时，返回码是否正确。
• 参数校验：缺少必填参数、参数类型错误、分页参数为负数、字符串超长。

我强烈建议你用 Postman 先把 RuoYi 的核心接口请求一遍，再决定是否切换到 pytest 自动化。这样可以先理解接口的业务逻辑，再写代码抽象成框架。

4.2 pytest + requests 接口自动化框架搭建

当接口用例数量超过三四十条时，手工执行就很痛苦了。这时候可以搭建一个基于 Python + Requests + Pytest 的轻量级接口自动化框架。

这个框架不需要复杂到像公司级平台，但至少要包含以下几层：

• 配置层：维护环境地址、账号信息。
• 请求封装层：封装 Session、请求头、token 管理。
• 测试用例层：按模块拆分 testcase 文件。
• 断言层：不仅检查 HTTP 状态码，还要检查业务码和关键字段。
• 报告层：接入 pytest-html 或 Allure。

下面第 6 章会给出完整可运行的代码实现，这里先不展开。

4.3 Postman + Newman 接口回归脚本

有人觉得 Postman 只是“手工调接口”的工具，其实它可以做成自动回归脚本。把接口用例保存到 Collection 中，把测试断言写在 Tests 标签里，然后用 Newman 在命令行执行，再接入定时任务，就能实现简单的接口回归。

适合练手的场景包括：

• 把 RuoYi 用户、角色、部门等模块的核心接口整理成 Collection。
• 在 Tests 中编写断言，例如pm.response.to.have.status(200)。
• 设置环境变量存储 token，实现多个接口共享登录状态。
• 使用 Newman 执行并生成 HTML 报告。

这个项目的价值在于“低代码完成接口回归”，即使你的 Python 还不熟练，也可以先用 Newman 流程练一遍接口自动化的思路。

4.4 Selenium Web 端 UI 自动化测试

UI 自动化的成本比接口自动化高很多，因为元素定位脆弱、运行速度慢、维护成本高。但它依然是软件测试技能树里要掌握的一项。

建议选择 RuoYi 或某个开源博客系统，做登录 + 一个核心业务流的 UI 自动化：

• 用 CSS Selector 或 XPath 定位元素。
• 使用 Page Object 模式，把页面元素和操作分离开。
• 结合 pytest 实现用例组织和失败截图。
• 无头浏览器运行，方便在 CI 环境执行。

如果时间有限，优先做接口自动化，UI 自动化可以作为“加分项”。但从简历丰富度来看，两个项目同时写，会更有竞争力。

4.5 JMeter 接口压力测试

性能测试是软件测试进阶的一个重要方向。用 JMeter 对 RuoYi 登录接口做一个简单的并发测试，是性价比很高的练手项目。

测试重点包括：

• 设置线程组、循环次数、聚合报告。
• 添加 HTTP 请求，配置接口路径和参数。
• 使用 CSV 参数化，模拟不同用户名登录。
• 添加监听器，观察 TPS、响应时间、错误率。
• 分析瓶颈：是数据库连接池不够，还是接口本身有慢 SQL。

性能测试最关键的是“分析和结论”，而不是“跑出数字”。你需要能解释：为什么 QPS 上不去？TPS 和响应时间的关系是什么？错误率升高是哪个环节导致的？这些分析能力，面试官很看重。

4.6 App 端功能与弱网测试

如果你目标岗位包含移动端，找一个开源的 App 项目或小程序项目做测试。

测试重点包括：

• 安装卸载：首次安装、覆盖安装、卸载后数据清理。
• 升级兼容：老版本升级到新版本后数据是否保留。
• 弱网测试：用 Charles 或 QNET 模拟 3G / 4G / 高延迟环境，观察页面加载和接口超时。
• 异常中断：网络切换、来电打断、后台杀死 App 后重新打开。
• 设备兼容：不同屏幕尺寸、系统版本下页面布局是否错乱。

5. 综合梯队：模拟真实项目全流程

综合梯队的项目不再只测一个模块，而是要求你从需求、测试计划、用例设计到执行、缺陷管理、回归、报告，完完整整地跑一遍。

5.1 Vue + Spring Boot 前后端分离商城系统全流程测试

找一个开源的商城系统，例如基于 Vue + Spring Boot 的电商项目，做全流程测试。

这个项目的价值在于“业务链路长”，可以从用户注册一直测到下单支付、订单查询、发货售后。你可以这样组织测试：

• 测试计划：明确测试范围、测试策略、风险点、进度安排。
• 测试用例：覆盖前台用户端、后台管理端、接口层。
• 执行记录：在 Excel 或 TestRail 中记录执行结果和 Bug。
• 缺陷报告：每个 Bug 包含复现步骤、预期结果、实际结果、截图和日志。
• 测试报告：统计用例总数、通过率、缺陷分布、遗留风险。

前后端分离项目还有一个好处，就是你可以清晰地区分“前端问题”和“后端问题”。定位 Bug 时，可以通过浏览器 DevTools 的 Network 面板判断是接口返回错误，还是前端渲染错误。这个能力在真实工作中非常实用。

5.2 Docker + Linux 环境部署后的端到端测试

很多测试人员只会“本地起服务”，对 Linux 部署和 Docker 容器完全没有概念。这个短板在求职时会非常致命，因为大部分公司的测试环境都部署在 Linux 服务器上。

建议你至少学会：

• 在 Linux 上安装 JDK、MySQL、Redis。
• 拉取 RuoYi 或商城项目的源码，编译打包。
• 用 Dockerfile 构建后端镜像，用 docker-compose 编排 MySQL、Redis、后端服务。
• 服务启动后，完整跑一遍功能测试和接口测试。
• 部署失败时，通过docker logs、journalctl、应用日志定位原因。

这个项目的价值不仅在于“会测试”，还在于“能搭建测试环境”。这会让你的简历在很多只写过测试用例的候选人中立刻有区分度。

5.3 数据库数据迁移与数据质量校验测试

真实项目里，随着业务升级，经常需要做数据库表结构调整、数据迁移、字段类型变更。这类需求一旦出错，对线上影响极大。数据质量校验测试，是进阶测试人员必备的思维方式。

练手方式可以是：

• 准备一份旧表结构和一份新表结构。
• 编写 SQL 或 Python 脚本完成数据迁移。
• 设计校验规则，比如：旧表记录数是否与新表一致、关键字段是否为空、金额字段精度是否丢失。
• 用 SQL 查询对比迁移前后的数据差异。

不要求你真的自己写迁移工具，只要你能设计出“如何验证数据迁移正确”的方案并写成测试用例，就已经超过了大量只关注页面的测试人员。这个方向在简历里非常有辨识度。

5.4 持续集成自动化测试

当自动化测试用例数量多了以后，靠人手动执行就失去意义了。持续集成的价值在于“代码一变，测试自动跑，结果自动发”。这是中高级测试工程师和高阶测试开发之间很重要的分水岭。

具体做法是：

• 把接口自动化测试项目推送到 GitHub，使用 GitHub Actions 配置 workflow。
• 在 workflow 中安装 Python 依赖，启动被测服务或使用已部署的服务，执行 pytest。
• 生成 Allure 报告，上传到 GitHub Pages 或作为 Action Artifact。
• 配置定时触发或 push 触发。

也可以使用 Jenkins：在服务器上配置 Job，拉取代码、执行测试、发送邮件。两者选其一即可。

5.5 基于 Allure 的可视化报告与测试流程复盘

很多人的自动化测试项目没有报告，只有控制台输出。这不够。Allure 是目前比较流行的测试报告框架，可以展示用例层级、步骤、截图、附件的日志信息。把 Allure 集成到 pytest 项目中，能给简历项目增加很多“工程化细节”。

你可以在 pytest 中通过--alluredir参数输出报告数据，再使用allure generate生成 HTML 报告。测试用例中使用allure.step添加步骤描述，失败时自动添加截图。

有了报告，你的项目才能真正展示给面试官看。即使没有真实线上数据，一个完整的 Allure 报告截图和本地报告链接，已经能说明你的自动化项目是“跑起来了”的。

6. 完整实操：用 pytest 跑通一个接口测试项目

前面的内容偏项目清单和方向分析。这一章直接给出一个可以照做的接口自动化测试框架，以 RuoYi 后台管理系统为例。假设你的本地已经跑起了 RuoYi 后端服务，端口为 8080。如果还没有，也可以把BASE_URL替换成任意一套可用接口服务。

6.1 项目结构

api_test/ ├── conftest.py # pytest fixture 与公共配置 ├── config.py # 环境地址与账号配置 ├── requirements.txt # Python 依赖 ├── utils/ │ └── http_client.py # 请求客户端封装 └── testcases/ ├── test_login.py # 登录相关接口用例 └── test_user.py # 用户管理相关接口用例

6.2 依赖声明

# 文件路径：api_test/requirements.txt requests>=2.31.0 pytest>=8.2.0 pytest-html>=4.1.0

版本号建议以当前 PyPI 实际提供为准。锁版本更利于复现环境，但示例中先用>=方便安装。

6.3 配置与环境信息

# 文件路径：api_test/config.py BASE_URL = "http://localhost:8080" ADMIN_USERNAME = "admin" ADMIN_PASSWORD = "admin123"

这是本地开发或测试环境的配置写法。真实项目中不要将明文密码写死在代码里，可以读取环境变量或使用配置管理工具。

6.4 请求客户端封装

# 文件路径：api_test/utils/http_client.py import requests class ApiClient: def __init__(self, base_url, token=None): self.base_url = base_url self.session = requests.Session() if token: self.set_token(token) def set_token(self, token): self.session.headers.update({ "Authorization": f"Bearer {token}" }) def post(self, path, **kwargs): return self.session.post(self.base_url + path, **kwargs) def get(self, path, **kwargs): return self.session.get(self.base_url + path, **kwargs)

这里的核心点是使用requests.Session()维持连接，并通过统一的base_url拼接路径。后续测试用例不需要关心完整 URL，只需要传接口路径。

6.5 登录 fixture

# 文件路径：api_test/conftest.py import pytest from config import BASE_URL, ADMIN_USERNAME, ADMIN_PASSWORD from utils.http_client import ApiClient @pytest.fixture(scope="session") def client(): api = ApiClient(BASE_URL) payload = { "username": ADMIN_USERNAME, "password": ADMIN_PASSWORD, "code": "", "uuid": "" } resp = api.post("/login", json=payload) assert resp.status_code == 200, resp.text body = resp.json() assert body.get("code") == 200, body api.set_token(body["data"]["token"]) yield api api.session.close()

注意，这里假设 RuoYi 后端关闭了登录验证码。如果开启了验证码，需要先调用/captchaImage接口获取 UUID 和验证码图片，再填写验证码，流程会复杂一些。本文以关闭验证码为例，方便快速跑通。

6.6 登录接口用例

# 文件路径：api_test/testcases/test_login.py from config import ADMIN_USERNAME, ADMIN_PASSWORD class TestLogin: def test_login_success(self, client): """正确账号密码登录成功，并返回 token""" resp = client.post( "/login", json={ "username": ADMIN_USERNAME, "password": ADMIN_PASSWORD, "code": "", "uuid": "" } ) assert resp.status_code == 200 body = resp.json() assert body["code"] == 200 assert "token" in body["data"] def test_login_wrong_password(self, client): """密码错误时返回业务错误码""" resp = client.post( "/login", json={ "username": ADMIN_USERNAME, "password": "wrong_password", "code": "", "uuid": "" } ) body = resp.json() assert body["code"] != 200

这里有两个细节要注意。第一，第二个用例也使用了clientfixture，所以已经拿到了登录态，但是请求体里依然传入了错误密码，因此会被后端拒绝。第二，断言时不要只检查 HTTP 状态码为 200，因为很多后端对业务逻辑错误也会返回 HTTP 200，但code字段不是 200。一定要同时校验业务码。

6.7 用户管理接口用例

# 文件路径：api_test/testcases/test_user.py from config import BASE_URL from utils.http_client import ApiClient def test_get_user_list_with_auth(client): """带登录态查询用户列表""" resp = client.get("/system/user/list", params={ "pageNum": 1, "pageSize": 10 }) assert resp.status_code == 200 body = resp.json() assert body["code"] == 200 assert "rows" in body def test_get_user_list_without_token(): """未携带 token 访问用户列表应被拒绝""" anon = ApiClient(BASE_URL) resp = anon.get("/system/user/list", params={ "pageNum": 1, "pageSize": 10 }) assert resp.status_code in (401, 403)

第二个用例特意去验证“无权限访问”场景。这个用例很有价值，因为在真实面试中，“你测过权限校验吗”是接口测试的高频追问。

6.8 运行测试

在项目根目录执行：

cd api_test pip install -r requirements.txt python -m pytest -v --tb=short

使用python -m pytest而不是直接pytest，可以避免当前目录没有加入PYTHONPATH导致的ModuleNotFoundError。

预期输出类似：

collected 4 items testcases/test_login.py::TestLogin::test_login_success PASSED [ 25%] testcases/test_login.py::TestLogin::test_login_wrong_password PASSED [ 50%] testcases/test_user.py::test_get_user_list_with_auth PASSED [ 75%] testcases/test_user.py::test_get_user_list_without_token PASSED [100%] ================= 4 passed in 3.21s =================

如果全部通过，说明最小接口自动化框架已经跑通了。接下来你可以继续往框架里加模块、加数据驱动、加 Allure 报告。

7. 常见问题与排查思路

在搭建接口自动化测试项目时，新手最容易遇到以下几个问题：

不要小看这些基础问题。很多人在面试时被追问“你的项目遇到过什么难点”，回答的不是框架设计难题，而是这些环境问题。能把环境问题讲清楚、讲出排查过程，本身就是一个合格的测试能力证明。

8. 把练手项目写进简历的正确姿势

练手项目做完了，如果不会写进简历，效果会打一半折扣。

简历项目描述最容易犯的错误是写流水账，比如：“负责登录模块测试，使用 Postman 进行接口测试，发现了一些 Bug，提交给开发修复。”这种描述没有数据、没有技术细节、没有难点，面试官看完毫无印象。

更推荐的写法是：用“项目背景 + 技术栈 + 你的职责 + 量化成果”的格式来组织。

下面是一个可以套用的模板：

项目名称：XX 后台管理系统接口自动化测试 项目时间：2025.XX - 2025.XX 项目描述：基于 RuoYi 开源后台管理系统搭建接口自动化测试框架，覆盖登录鉴权、用户管理、角色管理、部门管理等核心模块。 技术栈：Python、Requests、Pytest、Allure、Git、Jenkins 项目职责： 1. 分析系统业务与接口文档，完成 60+ 条接口测试用例设计，覆盖正常流程、异常输入、鉴权校验与边界场景； 2. 基于 requests 封装统一请求客户端，使用 pytest fixture 管理登录态与用例执行，实现用例数据与业务逻辑分离； 3. 集成 Allure 测试报告，配置 Jenkins 定时任务，实现每日自动执行与结果通知； 4. 累计发现有效缺陷 20+，并配合开发完成定位、修复与回归验证。

需要提醒的是，用例数量和缺陷数量要写你真实跑出来的结果，不要编造。你可以先保守地写“30+ 条接口测试用例”，等实际执行后再更新。

简历里还可以附上项目仓库链接、Allure 报告截图、GitHub Actions 执行记录。这些材料的说服力远大于文字描述。

面试前，你还要准备三个追问：

• 为什么选择 pytest 而不是 unittest？
• 登录 token 过期后，你的自动化用例怎么处理？
• 如果测试环境不稳定，你怎么保证自动化用例的稳定性？

这三个问题分别对应选型能力、设计能力、工程能力。你能答好这几个问题，项目才是真的属于你。

9. 总结与后续学习方向

把 16 个实战项目按优先级排一下：

• 零基础入门：先做 3.1 到 3.5 这五个功能测试项目，重点练测试用例设计和缺陷报告。
• 准备进阶岗位：优先做 RuoYi 接口测试、pytest 接口自动化、Postman + Newman 回归脚本。
• 想冲中高级岗位：把 CI 集成和 Allure 报告做完，再选一个前后端分离商城项目做全流程质量保障。

建议的精简路线是：RuoYi 接口测试 + pytest 自动化框架 + Docker 部署 + GitHub Actions 执行 + Allure 报告。这一条链路做完，你的项目经历已经从“功能测试”跨越到“自动化测试与持续集成”，基本能覆盖大部分测试岗位的简历筛选要求。

完成这些项目后，可以继续深入的方向包括：性能测试分析（尤其是慢 SQL 定位）、安全测试基础（如越权、注入、敏感信息泄露）、测试平台开发（用 Web 框架管理用例和报告）、AIGC 辅助测试脚本生成与用例补全。软件测试的核心竞争力从来不是单一工具，而是快速理解业务并用合适的手段保障质量的能力。项目练手是路径，能讲清楚、能应对追问、能解决新问题，才是终点。