今天翻到了自己2026年4月3日记录的一份学习笔记，标题写着“软测必学清单”。说实话，软件测试这个行当，入门容易，想做好却很难。很多朋友问我，如果从零开始学软测，到底先学什么，哪些是必须掌握的核心内容。这份清单正好可以回答这个问题。它不是那种从网上随便抄来的大纲，而是我这些年做测试、带新人、面试候选人过程中，反复验证过的核心技能集合。今天把它整理出来，结合我个人的踩坑经历和学习思路，跟大家详细聊聊这份软测必学清单背后的门道，希望能给正在学习或准备转行做测试的朋友一些实实在在的参考。
1. 先搞懂测试的底层逻辑，别急着报工具班
很多新手学软测，第一件事就是去买课学Selenium、学JMeter，觉得学会了工具就等于会测试了。这个想法大错特错。工具只是手，测试思维才是大脑。我见过太多只会点工具但是设计不出有效用例的人，也见过不少虽然没用过最新工具，但能一针见血发现严重缺陷的人。所以，软测必学清单的第一个板块，一定是核心测试理论和思维方式。
1.1 测试金字塔与测试分布
测试金字塔是软件测试里最经典的一个模型，最早由Mike Cohn在《Succeeding with Agile》这本书里提出。简单说，它把测试分成了三层：底层是大量的单元测试，中间层是较少的服务或接口测试，顶层是少量的端到端UI测试。为什么这个模型这么重要？因为它直接回答了“测试资源应该怎么分配”这个核心问题。
单元测试是开发人员写的，它验证的是代码里最小的逻辑单元，比如一个函数、一个方法，它的特点是运行速度快、成本低、定位问题精准。接口测试验证的是系统模块之间的数据传递和交互逻辑，相比UI测试它更稳定，而且能够在早期发现大部分集成问题。UI测试是从用户角度去验证整个系统的功能是否正常，但它非常脆弱，页面稍有变动就可能挂掉，而且跑一次全量回归成本很高。
在真实的项目里，我经常看到团队把大量精力花在UI自动化上，试图用UI自动化覆盖所有回归场景，结果就是脚本频繁失效、维护成本爆炸，最后整个自动化项目不了了之。正确的做法应该是把大部分测试下沉到接口层和单元层，UI层只保留核心的核心流程。理解了测试金字塔，你就知道为什么很多团队在推行“测试左移”——把测试活动尽量提前，因为缺陷发现得越早，修复成本越低。在需求评审、设计评审阶段就介入，而不是等开发提测了才开始准备测试用例，这是高阶测试人员和普通功能测试人员最大的区别之一。
1.2 核心测试用例设计方法
设计测试用例是做软测最核心的基本功，也是面试必考的内容。测试用例设计方法比较多，但真正在项目管理中最常用的主要有：等价类划分、边界值分析、场景法、判定表、正交试验等。
等价类划分就是把输入数据按“是否等价”分成若干类，每个类里抽取一个代表值就可以覆盖这一类场景，核心思想是用最少的用例获得最大的覆盖率。边界值分析是与之搭配使用的方法，因为有大量缺陷集中在输入范围的边界附近。举个例子，一个输入框接收1到100的整数，等价类就是有效等价类（1到100）、无效等价类（小于1、大于100、非数字等），边界值要测0、1、100、101这四个点，再配合“空值”这种特殊场景，基本就能覆盖绝大多数情况。
场景法主要用于业务流程测试，从用户操作的角度设计典型场景和备选场景，比如“正常下单支付成功”是基本流，“支付超时后重试”是备选流。判定表适合条件和动作之间关系复杂的场景，比如优惠券叠加规则、订单状态流转判断等。正交试验法适合参数组合特别多的情况，比如搜索筛选条件组合，用正交表可以大幅减少测试用例数量。
很多新手会问，用例设计到什么时候算“足够”？我的经验是，除了覆盖需求描述的功能，还要重点考虑异常场景、并发场景、数据边界场景、权限场景。比如用户Session过期怎么处理？两个用户同时操作同一条数据会怎样？网络超时有没有提示？断开网络再恢复能不能恢复正常流程？这些异常场景往往是上线后才暴露问题的高发区。
1.3 测试流程和研发协作
除了用例设计，你还得搞清楚一个完整的测试流程是什么样的。一般来说，标准流程是：需求评审 → 测试计划 → 测试设计（写用例） → 测试执行 → 缺陷管理 → 测试报告。听起来简单，但每一步都有讲究。
需求评审是非常关键的一步，很多人忽略了这个环节，结果开发做出来的东西和预期不符。测试人员参与需求评审的目的不是“找茬”，而是要站在用户角度、业务角度提出需求中不明确、不完整、不可验证的地方。在评审会上，特别要留意需求的优先级、兼容性要求、性能指标、埋点需求等容易遗漏的内容。
缺陷管理也是必修课。不是说你在项目管理工具里提个Bug就完事了。一个高质量的问题报告应该包含：问题标题（简洁描述现象）、前置条件、复现步骤、实际结果、期望结果、截图或录屏、环境信息、严重程度、优先级、日志信息。我见过太多开发拿到问题单之后跑来问“这个前置条件是什么”“在哪个环境复现”“你是不是清缓存了”，就是因为问题描述太粗糙。一个测试人员的专业度，从写Bug的规范度就能看出来。还有，对于“缺陷是否修复”的回归验证，不要只测开发说修好的点，要仔细思考他的修复可能影响到的相邻功能模块，做相应的回归。
2. 工具链：从接口到UI的必备实操能力
理论是内功，工具是招式。这份清单的第二大板块，是软测常用的工具链。工具不用贪多，但每个类别里都要有一个精通的，而且得能讲清楚选择它的理由。
软件测试的工具生态其实很庞大，但核心可以分为几类：接口测试工具、自动化测试工具、性能测试工具、缺陷管理工具、抓包工具、CI/CD工具。下面我逐个说下我的使用感受和选型建议。
2.1 接口测试工具：从Postman到Apifox
接口测试是软测学习过程中性价比最高的一块技能，因为它在整个测试金字塔里处于中间层，既稳定可靠又贴近业务逻辑，而且学习曲线比UI自动化平滑得多。接口测试工具目前市面上最主流的是Postman和Apifox。
Postman是老牌的接口调试工具，功能强大，生态成熟，支持环境管理、集合管理、脚本编写、Runner批量执行等。我早期做接口测试基本都用它。不过Postman的痛点在于它只解决了“调试和测试”环节，没办法很好地把接口文档和Mock数据和团队共享串联起来，而且它的界面偏英文，对刚入门的朋友来说有一点点学习成本。
后来我逐渐转移到Apifox上。Apifox是一个国产的软件，把接口文档、接口调试、Mock数据、自动化测试整合在了同一个平台里，非常适合团队协作。它还有一个很好用的方式：可以直接导入Postman的集合，迁移成本很低。在Apifox里你可以直接创建接口测试用例，设置断言，比如断言响应状态码是200，断言返回的JSON里某个字段的值符合预期。然后可以组建测试场景，把多个接口串联起来，前一个接口的响应结果提取出来作为后一个接口的输入参数。这个能力在真实项目中非常实用，比如“创建订单”之后再调用“支付接口”，支付需要用到订单号，这个数据就从前一个接口的返回里提取。
很多人问需要不需要学JMeter做接口测试，答案是看你有没有性能测试的需求。如果只是功能层面的接口测试，用Apifox就够了；如果有并发压测的需求，比如测试一个接口支持多少并发用户，那JMeter的线程组模型就很有用。我的建议是，先精通一个接口测试工具，再学JMeter的接口和压测功能，性价比最高。
2.2 Web自动化测试：Selenium还是Playwright
Web UI自动化几乎是软测人必谈的话题。经典方案是Selenium + WebDriver + Python/Java，这也是目前很多公司测试框架的底座。Selenium的好处是资料多、网上踩坑教程也多，兼容性好，支持主流的浏览器。但它的痛点也很明显：运行速度慢、对动态页面的处理能力较弱、需要自己处理大量的等待条件（比如显式等待、隐式等待、强制等待Sleep），写不好就是一堆“不稳定”的自动化用例。
Playwright是后起之秀，由微软出品，这几年发展非常迅猛。它最大的特点是自动等待机制做得好，内置了actionability检查，元素可操作时才执行操作，大幅降低了不必要的Sleep。它还内置了Trace Viewer，脚本失败后可以查看完整的执行录像和网络请求，定位问题非常方便。而且它支持多浏览器、多标签页、移动端模拟，API设计也很人性化。
如果让我给建议，新手学习Web自动化可以从Selenium入手，因为大多数公司老项目还是用Selenium为主，你会Selenium至少能干活。但如果你在做新项目的自动化框架选型，可以优先考虑Playwright，它在长期维护成本上更有优势。无论如何，自动化测试的核心不是“会调用API”而是“如何设计稳定可靠的自动化用例”，怎么处理登录态、怎么处理动态加载、怎么选择稳定的定位器、怎么隔离测试数据，这些才是真正拉开水平差距的地方。
2.3 性能测试与抓包工具
性能测试是软测里比较进阶的板块。常用工具就是JMeter，虽然它界面看上去有点“老气”，但在压测领域依然是实际使用最广的。用JMeter你可以创建线程组（模拟并发用户）、添加HTTP请求、配置参数化（比如随机用户名）、添加断言、添加聚合报告、查看响应时间曲线和错误率。很多时候性能测试不是一定要多大的并发，而是要掌握怎么分析结果。比如你压测发现接口的平均响应时间是2秒，吞吐量是500请求每秒，这到底算不算合格？需要结合业务要求和系统资源使用情况来判断。如果响应时间长，要看是代码慢还是数据库慢还是网络慢，这就需要配合监控工具去看CPU、内存、磁盘IO、慢SQL等。
我再强调一下性能测试不仅是“压就完了”，测试前的场景设计非常关键。要搞清楚性能指标是哪些：并发用户数、TPS（每秒事务数）、响应时间95线、错误率等。然后设计符合业务实际的混合场景，而不是只对一个接口做高并发压测。这些内容在软测必学清单里属于加分项，但如果你想往高级测试或性能测试专家方向走，这部分是绕不过去的。
抓包工具的话，PC端最常用的是Charles和Fiddler，移动端抓包也可以用这两个工具配合手机代理设置。它们的作用是查看客户端与服务器之间的HTTP/HTTPS请求与响应内容，可以帮你debug很多问题，比如前端传参错了还是后端返回错了、线上环境某个请求为什么失败、App里某个接口的返回是否符合预期。特别是做接口测试和排障的时候，抓包工具是效率神器。
3. 编程与底层硬功夫：拉开差距的分水岭
如果说功能和工具决定你能不能入行，那编程和底层知识就决定你能走多远。软测必学清单里，这一部分往往是新人最容易“偷懒”的地方，因为学起来比点工具有难度。但真正做了几年测试你就会发现，那些能写自动化框架的、能定位线上问题根因的、能跟开发有理有据地争论技术方案的测试人员，无一例外都有扎实的编程和底层基础。
3.1 Python还是Java：测试开发的第一语言
对于测试人员来说，主流的选择就是Python和Java。如果偏向业务测试和自动化脚本，Python是首选的，因为语法简洁、上手快、有大量现成的库（比如requests做接口请求、pytest做测试框架、selenium/playwright做UI自动化、pandas做数据处理）。Python的学习曲线相对平缓，能让你快速进入“能写代码解决问题”的阶段。
如果去的是大型互联网公司，特别是以Java技术栈为主的公司，Java的测试开发岗位也非常多。Java的好处在于性能好、类型系统严谨、企业级框架生态庞大，但它的语法相对复杂，学习成本更高。在测试开发岗位的面试中，Java候选人往往会被问到JVM、并发、Spring框架相关的内容，偏向底层。而Python候选人更多是被问脚本能力、pytest框架、自动化测试设计。
我的建议是，如果你还没定技术栈，先学Python，用它来解决测试中的实际问题，等有了一定的代码能力再按需补充Java基础。毕竟测试人员的第一目标不是成为纯开发，而是能用代码提升测试效率。但要注意，学了语法不等于会写测试脚本，你还要了解Python的requests库怎么用、pytest的fixture和参数化怎么用、怎么封装公共方法、怎么读配置文件、怎么输出测试报告，这些才是测试场景中的实战技能。
3.2 SQL与数据库实操要点
测试过程中，你几乎天天要跟数据库打交道。比如验证某个订单状态有没有正确写入；构造测试数据的时候需要往库里插几条记录；排查线上问题的时候需要查一些数据来判断是数据问题还是代码问题。所以SQL是软测必学清单里的硬技能，而且面试一定会问。
SQL需要掌握到哪个程度？基本的增删改查就不多说了，这是底线。实际测试中更实用的是：联表查询（inner join、left join）、聚合函数（count、sum、group by）、子查询、between和in操作符、like模糊查询、order by排序、limit分页。另外，你还需要会看MySQL的执行计划（explain），判断一个慢查询是不是走了索引，这在与开发协作定位性能问题时会非常有帮助。
我在实际工作中经常做的一件事就是：测试环境出了问题，我先查数据库确认数据状态是否正常，再判断是前端问题、接口问题还是数据初始化问题。很多开发定位半天没找到问题，最后发现是环境数据没初始化好。你只要会一条简单的SQL一看便知，这就是效率优势。另外，test data preparation（测试数据准备）也是一门学问，手工插数据容易漏字段，最好能用脚本批量生成，这也依赖SQL功底。
3.3 Linux与网络基础
Linux是测试环境部署和日志排查的基本功。现在的系统基本上都跑在Linux服务器上，测试环境出了问题，你总要会上服务器看看日志、查一下进程、确认服务是否正常。常用的命令包括：cd、ls、tail、grep、ps、kill、top、netstat、curl、vim等。
日志排查是测试人员日常工作的重中之重。当开发说“我本地是好的”，你得学会自己去服务器上看日志，确认请求进来之后发生了什么。用tail -f实时查看日志输出，用grep过滤关键词定位报错信息，用log lavel调整日志级别输出更多细节。这些操作看似简单，但没有Linux基础的人在遇到线上环境问题时基本是寸步难行的。
网络基础也是一块绕不开的内容，特别是HTTP协议。你要清楚一次完整的HTTP请求包含哪些信息：请求行（方法、URL、协议版本）、请求头（Content-Type、Authorization、Cookie等）、请求体；响应状态码的含义（200成功、301/302重定向、400请求错误、401未认证、403禁止访问、404资源不存在、500服务器内部错误、502网关错误、503服务不可用）。接口测试过程中遇到一个504特别常见，它的含义是网关超时，看到这个状态码，你基本可以判断问题是出在网关和服务端，而不是客户端。还有HTTP和HTTPS的区别、TCP三次握手四次挥手的基本过程，这些在面试中出现的频率很高。
4. 实战打怪：从需求分析到自动化测试落地
基础知识和工具都准备了，接下来就是真刀真枪地在项目里滚打。这一部分我想重点聊聊实战中会遇到的几个关键场景，包括怎么把一个功能需求转化为测试方案，怎么把自动化测试真正落地执行，怎么排查线上问题。
4.1 需求文档读不透，测试设计全白搭
很多测试新手在拿到需求文档之后，脑子里没有明确的“测试点”概念，只会对着需求列表按步骤点点点。这也是为什么同样一个功能模块，有些人测试完上线就出问题，有些人测试完却很稳。
读需求文档要带着问题去读：这个功能是给谁用的？用户的真实使用场景是什么？不同角色（比如普通用户和管理员）的操作权限有何不同？成功路径怎么走？失败路径怎么走？有没有并发风险？有没有数据冲突？和已有功能有没有交互影响？尤其要在需求评审会之前，把所有不明确的地方列出来，在会上逐一确认。
举个例子，一个“用户修改个人资料”的功能，简单看起来就是改个手机号、昵称。但你是测试，你要想到：手机号要不要验证码校验？改动手机号之后，登录账号是否要重新认证？昵称的长度限制是多少？能不能包含特殊字符？能不能重复？修改之后，其他业务模块里显示的昵称是否同步生效？这些就是需求文档里不一定写了、但你必须主动确认的点。
我在做测试设计时习惯用“测试矩阵”的方式，把功能点、测试类型（功能、兼容、性能、安全、异常）、测试数据、预期结果放在一个表格里，一目了然。尤其是兼容性测试，你可以考虑的操作系统、浏览器、屏幕分辨率、网络环境等维度组合，结合用户画像来确定优先级，不要盲目追求全覆盖。一个新功能上线，你优先保证主流环境和主流用户路径不出问题，比在边缘环境上消耗大量时间更划算。
4.2 自动化测试的落地路径
自动化测试的价值毋庸置疑，但“自动化测试项目失败”在行业里也是出了名的普遍。失败的最常见原因有三个：一是选择的用例不适合自动化，二是脚本写得太脆弱，三是缺少维护机制。
哪些用例适合自动化？高频率重复执行的功能、核心业务流程的回归测试、数据构造比较复杂的场景、跨天数据可以通过脚本方便生成的场景。哪些不适合自动化？UI频繁变化的功能、需求还在快速迭代中的新功能、需要大量人工判断视觉效果的场景（比如页面美观程度、图片显示效果）。我见过团队在需求还在频繁改的时候就开始写UI自动化，结果今天改文案、明天改布局，自动化脚本天天修，最后整个项目放弃了。正确节奏是：等需求稳定后再投入自动化；初期先做接口自动化，UI自动化放到后期核心链路。
自动化测试框架搭建，重点考虑几点：用例怎么组织、数据怎么管理、报告怎么输出、失败怎么排查、怎么集成到CI流水线。这里我推荐pytest + requests + allure的组合做接口自动化，pytest的fixture机制可以很好地处理测试前后的数据准备和环境切换，allure生成的报告非常直观，能够展示每个请求的请求参数、响应结果、断言结果，开发定位问题也方便。UI自动化推荐Playwright + pytest，稳定性和排查体验都比传统的Selenium方案好很多。CI/CD这边，现在主流是用Jenkins或者GitLab CI，可以把自动化测试接进流水线，每次代码提交自动跑一遍冒烟测试，有问题及时反馈，这个闭环能大大降低回归漏测的概率。
4.3 线上问题定位的实战思路
线上问题定位是测试工作里最考验综合能力的一个场景，也是我刚入行时最怵的一件事。有一次线上用户反馈支付成功但订单状态一直显示“待支付”，当时我第一反应是看看数据库里订单状态到底更新了没有。我登录线上环境查了一下，发现有一个订单的状态字段确实没有变成“已支付”，马上把这个信息反馈给开发。开发查代码后发现是支付回调接口幂等性处理有一个边界条件没有覆盖，后来修复了。这次经历给我的启发是：遇到线上问题，永远不要只看表面现象，也别急着下结论，而是要从用户请求链路出发，一层一层去看数据。
一个完整的排查思路是：明确问题现象和影响范围（用户不能支付？还是部分用户不能支付？什么时间段出现的？） → 复现或收集信息（日志、请求参数、返回数据） → 检查接入层（网关/代理是否有报错、是否有超时） → 检查应用层（服务日志、异常堆栈） → 检查数据层（数据库记录、缓存数据） → 定位根因 → 验证修复。其中，日志是最关键的证据来源，所以测试人员要会看日志、会搜关键词、能看懂日志时间线，这是基本功。
如果项目里接入了链路追踪系统（比如SkyWalking、Zipkin），那排查效率会大幅提升，一个请求从进来开始经过哪些服务、每个服务耗时多少、哪个环节报错，都写得清清楚楚。如果没有这类系统，就靠你手动去各个服务看日志，顺着traceId或者请求ID去串联。所以，即使你是测试工程师，也非常建议了解前端请求是怎么发出去的、后端服务之间是怎么调用的、消息队列和定时任务在系统里承担什么职责，对整个系统架构有认知，排查线上问题才有的放矢。
5. 学习路径规划和避坑建议
最后总结一下软测必学清单的整体学习路径。我按照“由浅入深、逐层打怪”的原则，把它分成几个阶段，每个阶段有明确的学习目标和验收标准，这样比漫无目的地刷视频更有效率。
第一阶段是核心基础，目标是对测试有系统认知，掌握用例设计方法和完整流程，能独立完成一个简单模块的功能测试。验收标准是给一个需求，能写出结构完整、覆盖全面的测试用例。
第二阶段是工具与接口技能，学会使用接口测试工具、抓包工具、数据库SQL、Linux基础命令。验收标准是能独立完成一个接口的测试，理解接口文档，会通过抓包定位前后端问题。
第三阶段是编程与自动化，掌握Python编程基础，学会用pytest搭建接口自动化框架，会用Playwright或Selenium做UI自动化。验收标准是能独立完成一个小项目的自动化测试框架搭建并跑通用例。
第四阶段是进阶方向，比如性能测试、安全测试、测试平台开发，这部分属于职业发展中的“第二曲线”，根据个人兴趣和公司业务方向选择。
在这个过程中，有几点避坑建议想特别说一下。
第一，不要追求工具数量，要追求工具深度。很多人学了一堆工具，每个都只会“点”，遇到问题还是不会排查。与其这样，不如把一个工具用到极致。比如Apifox，真正用熟它的话，你不仅能调试接口，还能做接口自动化、Mock数据管理、接口文档维护，完全可以取代很多零散的插件和脚本。
第二，不要只看理论不去实战。软件测试是实践性非常强的岗位，光看书、看视频，不自己动手在一个实际项目里跑一遍完整流程，很难形成真实的项目手感。你可以自己部署一个开源测试项目或者搭建一个自己的Web应用作为练习环境，把用例设计、接口测试、自动化、缺陷管理整个链条走一遍。
第三，不要让自动化测试成为“花架子”。自动化测试的价值是持续回归、快速反馈、节省人工，而不是用来向上汇报的演示。写自动化用例之前先问自己：这个用例多久会跑一次？跑一次发现问题会怎样？维护成本是多少？如果三个问题都答不上来，这个用例就不该写。做自动化要克制，把有限的成本花在最有价值的地方。
第四，英语阅读能力很重要。很多一手的技术文档、开源项目README、社区讨论都是用英语写的，中文资料虽然越来越多，但很多内容有延后性。能直接读英文文档，你的信息来源和问题解决速度都会比只会搜中文的人高一个层次。这个能力不用专门学，在查问题的过程中刻意多看英文资料，慢慢就练出来了。
这份软测必学清单不是什么官方标准，只是我个人从实际工作中提炼出来的一份学习地图。软件测试这个行业变化很快，新的工具、新的理念不断涌现，但只要核心能力和思维方式扎实，无论工具怎么变，你都能快速适应。希望这份清单能帮你少走一些弯路，在软测这条路上走得更稳。
