今天翻到了自己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还是PlaywrightWeb 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、社区讨论都是用英语写的中文资料虽然越来越多但很多内容有延后性。能直接读英文文档你的信息来源和问题解决速度都会比只会搜中文的人高一个层次。这个能力不用专门学在查问题的过程中刻意多看英文资料慢慢就练出来了。这份软测必学清单不是什么官方标准只是我个人从实际工作中提炼出来的一份学习地图。软件测试这个行业变化很快新的工具、新的理念不断涌现但只要核心能力和思维方式扎实无论工具怎么变你都能快速适应。希望这份清单能帮你少走一些弯路在软测这条路上走得更稳。