软件测试技能栈|60 个必备 skill,一次性整理完毕

CONTENTS

01这 60 个是怎么选的

02一、设计与用例（01–10）

03二、接口与协议（11–18）

04三、数据与 SQL（19–25）

05四、Linux 与排查（26–33）

06五、自动化（34–42）

07六、性能与稳定（43–49）

08七、工程化与协作（50–56）

09八、AI 相关（57–60）

10只补 12 个的话

市面上讲测试技能的文章，多数在讲名词：要懂 Linux、要会自动化、要有业务思维。听完还是不知道明天该学什么。

我换了个筛法：只收那些能直接影响一次交付质量的动作，并且必须能被验证——学没学会，做一件事就能看出来。

60 个分成八组，编号连续，你可以按编号在团队里做能力盘点：让每个人勾一遍，缺哪几个一目了然。

这一组决定你写出来的东西值不值得执行。前六个是方法，后四个是判断。

功能测试会做之后，分水岭在这一组。它决定你能不能脱离页面定位问题。

不会查库的测试，只能相信页面显示的东西。这一组是「自己去看真相」的能力。

线上问题不会给你一个页面。这一组是你在没有界面时还能干活的本钱。

这一组最容易学歪：把脚本写完当成目标。真正的目标是让失败信息能定位。

不用很精，但必须知道自己在测什么，否则压出来的数字没法解释。

到这一组，你的产出开始影响别人的效率，而不只是自己的任务。

这一组不是新学科，是把前面几组的能力用在新的输入端上。

如果时间有限，先补这 12 个：01、02、07、08、09、11、12、20、26、33、34、39。

理由很直接：它们覆盖了「写得出、查得清、跑得动」三件事。剩下的 48 个，多数是在这 12 个之上做加法，顺序反了会学得很痛苦。

勾完这张表，你会发现真正缺的往往不是第 60 个，而是第 7 个——缺陷写不清楚的人，学再多工具也难被信任。