内容摘要：软件测试课程的课程标准，核心就一条：让学生学会“找茬”，但找得专业，找得有价值。 我见过太多测试课程，把大半时间花在讲工具上。点开一个录制好的页面，按步骤录脚本，回放，生成报告。学生玩得开心，以为这就

软件测试课程的软件课程标准，核心就一条：让学生学会“找茬”，测试但找得专业，课程找得有价值。标准

我见过太多测试课程，软件把大半时间花在讲工具上。测试点开一个录制好的课程页面，按步骤录脚本，标准回放，软件生成报告。测试学生玩得开心，课程以为这就是标准测试。到了真实项目里，软件面对一个没文档、测试没需求、课程界面还丑的系统，他们傻了。第一步该干什么？不知道。这不能怪学生，课程标准就没告诉他们，测试的起点不是工具，是思考。

所以我的课程标准里，第一模块不是工具安装，是“如何拆解一个功能”。拿一个真实的登录框，不急着写用例，先问：用户名规则是什么？密码错了提示什么？连续输错五次会锁吗？锁了是锁IP还是锁账号？这些问题列出来，学生才明白，测试用例不是写出来的，是问出来的。

第二模块才是工具，但只给半天。半天够学Selenium基础了，够录制回放了。剩下的时间，全砸在“怎么设计异常场景”上。比如支付功能，正常流程谁都会测，但你要测余额不足、网络中断、重复提交、服务器超时。这些场景怎么构造？用什么数据？预期结果是什么？——这些才是测试的核心能力。工具只是手，脑子才是那个干活的人。

我见过最糟糕的课程考核，是期末让学生交一份测试报告。报告写得规规矩矩，缺陷等级、复现步骤、截图一应俱全。但仔细一看，测的全是主流程，边界值一个没碰，异常路径全跳过了。这种报告，交给开发，开发能怼回来：这bug我早知道了，你倒是测点我不知道的啊。所以我的考核改了——每个学生随机分一个真实的、带暗病的软件，不告诉bug在哪，限时两小时，看谁找得多、找得深。找得深比找得多重要。发现一个隐藏很深的逻辑漏洞，比报十个按钮错位有价值。

还有一点，课堂里必须吵起来。测试和开发天然对立，课程里就要让学生体会这种对抗。我安排角色扮演：一半人写代码，一半人测。测试提bug，开发说“这不是bug，是特性”，测试就得拿出证据反驳。吵完再互换角色。这么折腾几轮，学生自然明白，测试报告里“预期结果”和“实际结果”为什么必须写得毫无歧义——因为那是吵架的依据。

课程标准写到最后，我加了一条所有人都觉得多余的：每周必须玩一个小时新软件。游戏、工具、App都行，但得写玩后感——这个软件的哪个功能让你觉得别扭？哪个流程让你想骂人？这就是最原始的测试直觉。很多学生写着写着，突然开窍了：原来测试不是找茬，是替用户说出那些“不舒服”。

工具会过时，框架会淘汰，但拆解功能的能力、设计异常场景的思维、替用户着想的敏感度，这些才是测试课程的魂。课程标准守住的，就是这些不变的东西。