自学软件测试最尴尬的阶段往往不是看不懂测试理论而是简历上写不出项目经历。很多人背熟了等价类划分、边界值分析、缺陷生命周期到投简历时项目经历一栏却只能写“做过电商系统功能测试”面试官追问测试数据从哪来、用例怎么设计、缺陷怎么跟踪就答不上来。下面这 18 个免费、可自学、可以直接写进简历的软件测试项目按功能测试、接口测试、UI 自动化测试、性能测试、测试平台与脚本五个阶段分组每个项目都会说明练什么技能、怎么做、简历上怎么写。核心目标只有一个让自学测试的人先有项目再谈能力验证。1. 为什么自学软件测试最缺的不是理论而是能写进简历的项目1.1 面试官判断测试能力的第一依据是项目经历软件测试岗位的面试理论和代码都只是基础筛选真正拉开差距的是“你亲手验证过什么”。面试官看到“熟悉测试流程”这类描述无法判断候选人是否独立设计过用例、是否处理过环境问题、是否跟进过缺陷闭环。只有项目经历能承载这些信息被测系统是什么、你测了哪条链路、发现了什么问题、结果如何记录。自学的人没有公司级项目这是客观限制。但个人可以主动搭建被测对象完成一条完整的测试链路需求分析、用例设计、执行、缺陷记录、回归、报告。这份材料虽然不是企业真实业务但工序完整足以证明测试思维和执行力。1.2 练手项目和学习项目的本质区别很多自学者做过“登录页面测试”“计算器测试”这类练习只能算学习项目。它们有几个共同问题只有一个页面、没有状态流转、没有数据依赖、没有缺陷管理做完之后除了熟悉工具按钮几乎没有可迁移的方法。可以作为简历项目的练手项目至少要具备几个特征。被测对象有完整业务链路比如从登录到下单再到支付状态变化。输入数据有业务约束用户名长度、库存数量、日期边界都能触发不同逻辑。测试资产完整包括测试计划、测试用例、缺陷报告、测试总结。结果可复现别人拿到你的环境和资料能跑出相近结果。学完一个知识模块之后用练手项目把它串起来才是投资回报最高的方式。1.3 18 个项目的分组方法和练习顺序18 个项目分为五组本质上是软件测试工程师五层能力递进。分组项目数核心能力练习目标功能测试项目4用例设计、缺陷跟踪建立完整测试流程概念接口测试项目4协议分析、数据断言覆盖后端逻辑验证能力UI 自动化项目4元素定位、脚本开发掌握自动化测试工程化基础性能测试项目3压测设计、指标分析理解系统容量和瓶颈测试平台与脚本项目3框架设计、数据驱动具备独立搭建测试体系能力建议按照分组顺序练习不要一开始就扑向自动化。没有功能测试和接口测试的基础自动化脚本里的断言会出现大量无效校验。每个项目练到能独立回答“怎么设计、怎么执行、怎么证明”三个问题后再进入下一组。2. 练手之前先把工具链和环境准备好2.1 测试工程师常用工具清单工具不需要一次装完但每个阶段涉及的核心工具要提前熟悉。下面是按测试类型整理的工具清单安装最新稳定版即可。测试阶段推荐工具主要学习内容功能测试Chrome、Xmind、Excel、禅道或本地开源缺陷系统用例设计、缺陷生命周期、流程图绘制接口测试Postman、Apifox、Charles、FiddlerHTTP 请求结构、Cookie/Session/Token、断点抓包UI 自动化Selenium、Playwright、Appium、ChromeDriver元素定位、等待机制、浏览器驱动管理性能测试JMeter、Lighthouse线程组、参数化、聚合报告、性能指标脚本与平台Python、pytest、Allure、Faker、Requestsfixture、参数化、报告生成、数据构造辅助工具Git、GitHub、Docker、MySQL、VS Code版本管理、项目发布、环境部署、数据查询建议提前安装 Python 和 Git。Python 用于编写自动化测试脚本Git 用于把项目发布到 GitHub这样简历里的项目地址才有人能点开。2.2 本地环境准备建议自动化测试项目建议使用 Python 虚拟环境避免不同项目依赖互相污染。下面是一个可复用的环境准备流程。python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install -U pip pip install requests pytest allure-pytest selenium playwright faker安装完成后用下面命令确认核心库版本方便后续排错。python --version pytest --version这里要注意Playwright 安装后还需要执行一次浏览器内核安装命令否则运行时会提示找不到浏览器。playwright install如果安装过程遇到超时或网络问题优先检查 Python 源和 pip 镜像配置不要直接跳过。2.3 测试对象从哪里来免费开源系统与公开 API练手项目最缺的是被测系统。有几个免费来源可以优先使用。GitHub 上开源的商城系统、图书管理系统、待办事务应用选择维护时间较长、文档完整的项目文档越齐全越容易本地启动。公开接口服务例如天气查询、IP 归属地查询、一些平台提供的开放 API申请 key 后可以按官方文档测试。使用前要阅读配额说明避免超限导致 key 被停用。自己用 Flask 或 FastAPI 写一个简单后端作为被测试系统。这种方式能完全控制接口行为也方便构造异常场景。无论选择哪种系统都要坚持一个原则测试对象是合法、公开、允许访问的资源。性能压测只针对自己搭建的本地环境或明确允许压测的服务不要对未授权网站发起压力请求。3. 18 个免费项目按五个阶段逐步练手3.1 第一阶段功能测试项目4 个第一个项目开源商城系统的订单全流程功能测试。在本地部署一个开源商城系统梳理从登录、搜索商品、加入购物车、提交订单到支付回调的完整流程。用 Xmind 拆解业务模块再输出测试用例重点覆盖正常路径、反向路径和异常分支。执行过程中把缺陷记录到缺陷管理工具最终写一份包含结论和风险的测试报告。这个项目练的是需求分析和用例设计能力也是面试时最能体现测试思维的项目。第二个项目图书管理系统的借还书状态流转测试。图书管理系统的核心是状态流转可借、已借出、已续借、逾期、归还。不同状态之间的迁移条件很明确适合练习边界值和状态覆盖。需要特别关注两个点还书日期是否扣在法定节假日上、同一本书被并发借出时库存是否变成负数。这类“隐藏边界”才是项目亮点。第三个项目待办事项应用的安装与兼容性测试。选择一个待办事项 App在 Android 模拟器和浏览器中分别执行安装、升级、卸载、横竖屏切换、弱网操作。用抓包工具模拟弱网检查添加待办在弱网下是否出现重复提交或同步失败。这个项目练的是兼容性测试和安装包测试思路不需要太多代码但对问题复现路径要求很高。第四个项目在线问卷系统的表单测试。创建一个问卷填写问卷然后查看结果统计。测试重点放在输入校验和统计一致性上必填项、邮箱格式、手机号格式、最大长度、特殊字符、重复提交。提交后对比答卷明细和统计图表中的数值是否一致。很多表单系统在特殊字符或 XSS 输入上处理不完整这正是稳定产出缺陷的地方。3.2 第二阶段接口测试项目4 个第五个项目用户注册与登录接口测试。对注册、登录、图形验证码、Token 刷新等接口做完整测试。先用 Postman 手工验证正常流程再测试重复用户名、弱密码、过期 Token、缺少必填参数等异常场景。跑通后把关键接口迁移到 pytest 脚本中形成可重复执行的自动化用例。第六个项目商品查询与购物车接口测试。购物车接口之间有很强的数据依赖先查商品列表拿到商品 ID再调加入购物车接口最后修改数量。这个过程非常锻炼接口关联和动态参数提取。断言不能只检查 HTTP 200要校验响应中的价格、库存、商品名称是否与数据库一致。import requests def test_add_to_cart(): payload {product_id: 1001, count: 2} response requests.post(http://localhost:8080/cart/add, jsonpayload) assert response.status_code 200 data response.json() assert data[code] 0 assert data[data][total_quantity] 2这段代码展示了接口测试最基本的断言逻辑状态码、业务状态码、关键字段三部分都要校验。只看code 0还不够还要确认结果确实生效。第七个项目公开地图服务接口测试。在地图开放平台申请一个 key测试地点搜索、逆地理编码、路径规划三个接口。这个项目的价值在于真实业务的复杂参数城市范围、关键词类型、坐标格式、key 的权限范围。测试时把 key 放在配置文件中避免直接写死在脚本里。第八个项目天气查询服务接口测试。用免费天气 API 做参数化测试输入不同城市、不同语言、不同单位检查响应字段是否完整。重点关注两类场景极北或极南城市的夜间时长、非法城市名返回的错误信息是否友好。这个项目适合练 pytest 的参数化能力。import pytest import requests cities [北京, 上海, 广州, 乌鲁木齐] pytest.mark.parametrize(city, cities) def test_weather_by_city(city): response requests.get(https://api.example.com/weather, params{city: city}) assert response.status_code 200 data response.json() assert temperature in data assert humidity in data参数化让用例从“复制粘贴多条”变成“一份逻辑多条数据”这是接口自动化必备能力。3.3 第三阶段UI 自动化测试项目4 个第九个项目用 Selenium 完成登录加下单的端到端自动化。在之前部署的开源商城系统上用 pytest 加 Selenium 写一条冒烟用例打开首页、登录、搜索商品、加入购物车、提交订单。元素定位优先使用稳定的 data 属性和 CSS 选择器少用容易变化的下标。登录失败、下单超时要做失败截图方便排查。from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_login_and_order(): driver webdriver.Chrome() try: driver.get(http://localhost:8080/login) driver.find_element(By.NAME, username).send_keys(tester001) driver.find_element(By.NAME, password).send_keys(123456) driver.find_element(By.ID, login-btn).click() WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CLASS_NAME, user-panel)) ) assert tester001 in driver.page_source finally: driver.quit()这个项目练的核心不是“点按钮”而是元素定位策略和等待机制。很多初学者只用固定time.sleep等页面加载不稳定。显式等待可以等元素出现后立即执行也更容易定位超时问题。第十个项目Playwright 跨浏览器自动化测试。Playwright 可以在一份脚本里配置 Chromium、Firefox、WebKit 三种浏览器还能模拟手机视口。同一个登录用例可以在三个浏览器项目下分别执行用来验证跨浏览器兼容性。项目中还可以使用page.route拦截接口模拟后端返回 500 或超时观察前端页面是否正确提示。from playwright.sync_api import sync_playwright def run(): with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(http://localhost:8080/login) page.fill(input[nameusername], tester001) page.fill(input[namepassword], 123456) page.click(#login-btn) page.wait_for_selector(.user-panel) print(page.title()) browser.close() run()第十一个项目Appium 移动端自动化测试。在 Android 模拟器上安装待办事项 App用 Appium 编写添加待办、滑动删除、断言的用例。移动端元素定位与 Web 不同可能需要用 UIAutomator2 或 Appium Inspector 查看控件树。这个项目的环境配置成本最高模拟器和 Appium Server 版本容易互相影响。如果时间紧可以在掌握原理后放到后期完成不要因为环境卡住影响整体节奏。第十二个项目自动化测试数据准备脚本。用 Faker 生成测试用户通过注册接口批量创建账号必要时直接往数据库写入测试订单数据。关键是提供对应的清理脚本保证测试可以重复执行。from faker import Faker fake Faker(zh_CN) def generate_users(count50): users [] for _ in range(count): user { username: fake.user_name(), phone: fake.phone_number(), email: fake.email(), } users.append(user) return users if __name__ __main__: for u in generate_users(10): print(u)测试数据脚本看着简单实际价值很大。真实项目中测试环境的稳定程度直接决定自动化用例能否反复运行。3.4 第四阶段性能测试项目3 个第十三个项目JMeter 登录接口压力测试。用 JMeter 配置线程组、HTTP 请求、参数化、断言和聚合报告。并发数从 10、50、100 阶梯递增观察登录接口的吞吐量、90% 响应时间、错误率。本地系统如果扛不住就把它记录成性能瓶颈再试着优化中间件参数。jmeter -n -t login.jmx -l result.jtl -e -o report_html这条命令表示以非 GUI 模式运行login.jmx把结果写入result.jtl最后生成 HTML 报告目录report_html。性能测试报告最好包含线程数、总请求数、平均响应时间、90% 响应时间、最大响应时间、TPS、错误率这些核心指标。第十四个项目Web 页面加载性能测试。用 Lighthouse 或 WebPageTest 对本地商城页面做性能测量。关注首屏时间、最大内容绘制、资源请求数量、JS 体积。性能测试不一定只测后端接口前端加载性能同样影响用户体验。发现大体积图片或未压缩脚本后可以在测试报告里给出优化建议。第十五个项目数据库查询性能对比测试。在本地 MySQL 中创建一张订单表插入十万条数据写一条常用查询语句用EXPLAIN查看执行计划和全表扫描情况然后添加索引并重新查询记录两次耗时差异。测试结论要基于自己跑出来的数据不要写“提升了百分之多少”这种没有依据的描述。EXPLAIN SELECT order_no, user_id, amount FROM orders WHERE user_id 10086 AND status 1 ORDER BY create_time DESC;这个项目与其说是测试不如说是测试工程师理解系统性能底座的起点。能看懂执行计划接口性能问题的定位会快很多。3.5 第五阶段测试平台与测试脚本项目3 个第十六个项目搭建 pytest 加 Allure 的自动化测试框架。把前面的接口用例整理成一个可维护的工程目录加入conftest.py管理 fixture使用pytest.mark.parametrize管理测试数据执行后用 Allure 生成 HTML 报告。框架要做到“新人拿到仓库按照 README 就能运行并看到报告”。import allure import pytest import requests allure.title(登录接口-正常用户名密码) pytest.mark.parametrize(username,password,expected, [ (tester001, 123456, 0), (tester002, 654321, 0), ]) def test_login(username, password, expected): response requests.post(http://localhost:8080/login, json{username: username, password: password}) assert response.json()[code] expected这个项目练的是工程化能力而不是单个接口怎么写。报告、日志、失败重试、环境配置才是体现经验的地方。第十七个项目Excel 或 JSON 驱动的用例管理脚本。把接口用例从代码中抽离到 JSON 或 Excel 文件中脚本读取数据后执行。新增用例时不需要改代码只需要维护数据文件。这种方式体现了测试用例与脚本解耦的思想也是数据驱动测试的典型实现。[ { name: 正常注册, method: POST, url: /api/register, headers: {}, body: { username: test_01, password: 123456 }, expected: { code: 0 } } ]第十八个项目轻量级测试报告生成工具。编写一个 Python 脚本解析 pytest 或 JMeter 的 JSON 结果统计通过、失败、跳过数量汇总到 HTML 模板中生成带图表和日志的测试报告。这个项目可以和前面的框架配合解决多项目测试结果汇总的问题。把它写好就具备了测试开发方向的基础能力。4. 把项目写进简历从“测试过”到“搭建测试体系”4.1 一个项目经历的五个必填要素简历上的项目经历不是流水账要让面试官在 20 秒内看懂并愿意追问细节。每个项目至少包含五个要素。要素示例被测对象开源商城系统、图书管理系统、公开天气 API测试类型功能测试、接口测试、UI 自动化、性能测试关键动作设计用例、参数化脚本、失败截图、聚合报告分析可量化结果用例 180 条、缺陷 20 个、接口用例 45 条可验证输出GitHub 仓库地址、报告截图、演示录屏可量化结果必须是自己真实执行出来的不能编造。面试官一旦追查细节数字会被反复盘问。4.2 简历条目对比普通写法与可验证写法同样做了一周功能测试两种写法效果完全不同。普通写法“熟悉软件测试流程能独立完成功能测试掌握 Postman 和 Python。”可验证写法“独立完成开源商城系统订单流程功能测试与接口测试设计测试用例 180 条发现并跟踪缺陷 20 个使用 Postman 完成接口关联与鉴权校验结合 pytest 输出自动化接口用例 45 条项目文档和报告已整理到 GitHub可提供仓库地址。”可验证写法多出来的不是形容词而是对方能核对的证据。项目名称、用例数量、缺陷数量、脚本数量、仓库地址每一项都在降低面试官的验证成本。4.3 面试被追问时如何自证写进简历的项目默认都要经得起追问。面试官可能会问你用的商城系统是从哪部署的登录接口返回什么字段缺陷是怎么复现的并发压测时系统在哪一层最先出现瓶颈自证方式有三条。提前准备一个项目演示录屏从启动被测系统、运行测试脚本、生成报告三个环节录清楚。项目文档要和代码放在一起README 写清楚环境版本、安装命令、运行步骤、报告位置。挑两个项目深挖一个接口自动化项目一个性能测试项目确保能讲出设计取舍和踩过的坑。与其写十个浅项目不如把两三个项目做到能讲 15 分钟。5. 练手过程中最常见的 5 个坑5.1 只跑通一个用例就说熟悉自动化很多初学者把代码能跑通当成掌握自动化。实际上一个登录用例跑通只代表环境能启动。真正需要验证的还有数据驱动、断言有效性、失败后处理、报告生成、多环境切换。出现这种现象的根因是练习目标没有对齐“稳定执行”而不是“成功运行”。解决办法是把自动化用例增加到十条以上并且连续重复运行三次看稳定性。5.2 环境装一半就放弃环境问题通常是自学软件测试最大的流失点。模拟器起不来、浏览器驱动版本不匹配、Python 依赖冲突都会让人想放弃。这类问题不是能力问题而是缺少环境检查顺序。先确认操作系统位数和 Python 版本再确认浏览器版本和 driver 版本最后看 pip 依赖是否装进了当前虚拟环境。建议把安装过程每一步是否需要管理员权限记录下来方便排查。5.3 测试数据没有来源有的简历写“完成用户注册功能测试”但测试时用的是随手输入的假手机号。面试官问数据怎么隔离、重复数据怎么处理就答不上来。可靠的测试数据来源应该是通过 Faker 生成的随机用户、通过注册接口创建的账号、直接写入测试数据库的种子数据同时配套清理脚本。这样用例才能重复执行。5.4 项目太多但没有深度18 个项目是训练清单不是简历清单。简历里堆 18 个项目只会让人觉得每个项目都浅。建议简历只保留 3 到 5 个核心项目而且要能按技术难度排列功能测试证明业务理解接口测试证明协议和代码能力自动化测试证明工程化能力性能测试证明系统分析能力。5.5 简历与实操能力脱节有些人没做过 App 自动化但看教程后觉得自己了解原理就在简历写“熟悉 Appium”。面试官通常会追问 ID 定位、隐式等待和元素不可见问题实操不足很快暴露。简历要只写自己真正从零跑通的技术宁可少写也不能给对方留下“可能造假”的印象。6. 项目沉淀与下一步让练手成果能被人检查6.1 发布到 GitHub 的检查清单项目做完只是第一步能被人有效检查才算真正完成。发布到 GitHub 前按下面清单逐项核对。检查项说明README写清楚项目是什么、用到了哪些工具、如何安装、如何运行、测试结果在哪看requirements.txt固定关键依赖版本避免环境不一致导致无法运行测试用例文件功能测试用例可用 Excel接口用例可用 JSON自动化用例用 pytest 目录测试报告至少保留一份真实输出的 HTML 或 PDF 报告截图或录屏缺陷截图、性能报告截图、演示录屏都可作为证据免责说明说明被测系统为开源项目仅用于学习和测试练习6.2 一个可复现的自动化测试项目结构一个自动化测试项目如果别人拿到后不知道怎么运行可复现性就差。推荐使用下面这种目录结构。testing-project/ ├── README.md ├── requirements.txt ├── config/ │ ├── base_url.py │ └── data.json ├── utils/ │ ├── http_client.py │ └── log.py ├── test_cases/ │ ├── test_login.py │ ├── test_register.py │ └── test_order.py ├── reports/ │ └── 2024-01-01-report.html └── data/ └── users.jsonconfig放环境地址和测试数据utils放公共请求封装test_cases放用例reports放测试结果。运行命令写进 README别人只需要执行pip install -r requirements.txt和pytest -q就能复制结果。6.3 从软件测试项目走向测试体系把这 18 个项目练完之后下一步可以往三个方向扩展。引入 Docker Compose 管理被测系统和测试工具让项目一键启动提升环境部署能力。接入 GitHub Actions 或 Jenkins每次代码变更自动执行接口和 UI 自动化用例这是持续集成的雏形。把多个项目中重复的请求封装、用例管理、报告生成整合成一个轻量级测试平台这就是测试开发方向的第一版成果。对自学软件测试的人来说最快的成长方式不是收集更多资料而是选择一个被测系统做一条完整测试链路把用例、脚本、报告和缺陷记录全部沉淀下来。项目可以免费获得但项目背后的分析思路和复盘过程才是简历里最有说服力的部分。