很多人第一次听到“软件测试”，软件入门脑子里蹦出来的测试画面是：一个人坐在电脑前，疯狂点按钮，教程看哪里会崩。软件入门说实话，测试我入行前也这么想。教程直到带我的软件入门师傅扔过来一个登录页面，说“你把它测到我认为可以上线为止”，测试我才发现事情没那么简单。教程

那个登录页只有两个输入框和一个按钮。软件入门我点了十分钟就报“没问题”。测试师傅过来，教程输入一个空格当用户名，软件入门密码随便填，测试点登录——页面白屏了。教程再试，用户名填超长字符串，数据库直接报错。又试，密码框里粘贴一段脚本，弹出了 alert。我当时就愣住了：就这么个破页面，能炸出这么多花样？

这就是软件测试的核心：你永远不知道下一个 bug 藏在哪里，但你可以用系统的方法把它逼出来。

先搞清楚测试到底在测什么

软件测试不是“证明软件没问题”，而是“发现软件有问题”。这两句话听起来像绕口令，但心态完全不一样。前者让你随便点两下就说“可以了”，后者让你盯着一个输入框想：如果用户不按套路出牌会怎样？

我刚入行时犯过一个典型错误：只测“正常路径”。输入正确的用户名密码，登录成功，收工。但真实用户不会这么乖。他们会输错密码、会复制粘贴带空格的文本、会在网络卡顿的时候狂点按钮。这些场景才是 bug 的重灾区。

黑盒测试：不关心内部，只看输入输出

最基础的入门方法叫黑盒测试。你不需要懂代码，把软件当成一个黑箱子，给它输入，看它输出什么。常见的手段有几种：

等价类划分——比如年龄输入框，你可以分成“有效年龄”（1-120）和“无效年龄”（负数、0、121、文字）。每个区间挑几个代表值测就行，不用穷举。

边界值分析——bug 最喜欢躲在边界上。输入框限制 1 到 100，你就测 0、1、2、99、100、101。我见过一个分页功能，每页显示 10 条，翻到最后一页正好剩 0 条时，页面直接空白。

错误推测——靠经验和直觉猜哪里容易出问题。比如表单提交按钮，连续快速点五次会怎样？很多人不测这个，结果线上用户手抖一点，订单重复提交了。

白盒测试：打开箱子看代码

黑盒测试够用一阵子，但想深入就得看代码。白盒测试关注程序内部的逻辑分支。比如一个 if-else，你得保证两个分支都跑到。一个循环，你得测循环 0 次、1 次、多次的情况。

我印象很深的一次，代码里有个判断：if (status == 1 || status == 2)。测试时只测了 status 为 1 和 2 的情况，都正常。上线后用户传了个 status=3，直接走进了不该走的逻辑。这就是分支覆盖没做全的代价。

自动化测试：让机器帮你重复点

手动测试做多了会疯。同一个回归用例，每次发版都要点一遍，点到最后人都麻木了。这时候就该上自动化。

入门可以从 Selenium 或 Playwright 开始。写一段脚本，让它自动打开浏览器、输入账号密码、点击登录、检查页面标题。跑一次可能比手动还慢，但跑一百次呢？每次发版前自动跑一遍，十分钟出结果，省下来的时间够你摸鱼了。

不过别迷信自动化。UI 变一下，脚本就挂了。维护成本有时候比手动还高。我的经验是：稳定的核心流程用自动化，频繁变动的界面用手动探索。

入门阶段最该养成的习惯

别急着学工具。先学会写清晰的 bug 报告。我见过太多新人提交的 bug 单就一句话：“登录有问题”。开发看了想打人。合格的报告应该包含：环境、步骤、预期结果、实际结果、截图或日志。把这几样写清楚，沟通成本直接减半。

还有一个习惯：复现问题之前，先想清楚是不是自己操作错了。我有次兴冲冲报了个“严重 bug”，结果是自己浏览器缓存没清。这种乌龙来两次，开发就不信你了。

软件测试入门不难，难的是保持怀疑。每次觉得“应该没问题”的时候，多问自己一句：如果我是用户，我会怎么把它搞崩？