北京
测试一个应用，曾经意味着打开它、到处点、输入各种奇怪的值，然后看哪里崩了。QA工程师拿着长长的检查清单逐项过，像流水线上的检验员，全部通过才允许发布。
后来是测试自动化。同样的回归检查不用一遍遍手点，写一次就能在CI里反复跑，Selenium、Cypress、Playwright让这件事成为可能。代价是测试本身也要维护：改一个按钮文案或选择器，流水线立刻变红。
现在AI能帮忙生成测试用例、提示边界情况、造测试数据、排查失败，甚至能判断一次改动之后该跑哪些测试。但问题也随之而来：怎么知道它建议的这些测试，就是真正重要的那些？
三个阶段，谁也替代不了谁
手工测试提供的东西很难被替代：好奇心。人能察觉某个流程"感觉不对"，会质疑一条需求，会尝试意料之外的操作顺序。缺点是每个版本都重复同样的检查太耗时间，人也会累、会漏、会效率下降。
自动化提供的是可重复性。一套可靠的回归测试能在每次改动后检查重要行为，给团队快速反馈。但自动化测试更多，并不自动等于覆盖更好——一个点开页面的测试，常常漏掉页面上其他出错的地方，而为这些地方补测试，又会引出新的遗漏。
AI辅助测试能让这两部分工作都快一些：提出我们没想到的用例、帮忙写测试、总结失败原因。但生成出来的测试仍然只是一个提案，需要有人核对它的假设、断言，以及和产品的相关性。三个阶段不是互相替代的关系，探索式测试仍然需要，可靠的自动化仍然需要，AI只是往这份工作里又加了一件工具。而和所有工具一样，干得怎么样，很大程度上取决于用工具的人。
测试数量不等于信心
一个会话校验的例子很能说明问题：针对有效会话、过期会话、无效签名写的测试可以全部通过，而应用依然接受一个已被吊销的会话。测试套件全绿，只说明我们写的检查通过了，不说明我们忘了检查什么。
如果把生成测试的数量当成质量指标，AI会让这个缺口更大。它能从一份不完整的需求里产出大量看似合理的用例，其中不乏重复同一断言、或漏掉用户真正依赖的行为的。
《Google SRE》书里也表达过类似观点：测试通过不一定证明系统可靠。测试只说明它覆盖的那些场景，说明不了我们没想到的场景。
设想一个结账流程：折扣只应生效一次。AI可能生成好几个有效和无效优惠码的测试，这有用。但如果客户提交了不止一张优惠券呢？这本来就该被允许吗？如果支付失败，优惠券要不要标记为"已使用"？那样做会不会让对面的用户恼火？这里需要人来补的是决策所需的上下文。这类场景不那么显眼，出错代价却更高——测试写得再多，只要测的不是正确的行为，织出来的就是一张满是窟窿的安全网。
所以问题不只是"这个能不能测"，而是"哪些行为最值得测"。
AI适合当第二双眼睛
AI在这里最有价值的角色，是第二双眼睛，而不是决定"测完了"的那个人。把改动、相关需求和约束交给它，让它提出边界、负向用例和隐含假设，再拿这些建议对照真实产品逐条核对。
测试跑红的时候它也能帮上忙：把失败日志给它，它可以指出哪些失败可能同源、该先查哪里。但究竟是产品缺陷、不稳定的测试还是环境问题，仍然要人来判断。Google的测试团队指出过，一次不稳定的失败甚至可能是产品本身存在非确定性的信号。有用的建议是起点，不是诊断结论。
还有几件事仍然归我们负责：
- 按风险排优先级。支付失败和错别字不需要同等覆盖，要考虑业务影响、发生概率，以及问题多快会被发现。
- 检查断言。测试应该验证有意义的行为，而不只是页面加载了、按钮点到了。
- 让回归测试可维护。优先用稳定的选择器、清晰的失败信息，一套因为无关UI改动就红的测试，最终只会变成噪音。
- 核验AI的输出。检查生成的数据、预期结果和假设；需求含糊时去问懂业务的人，而不是把模型的回答当成规格说明。
AI在QA里真正让人兴奋的地方，不是几秒钟能产出40个测试用例，而是少花时间面对空白页，多花时间问更好的问题：我们假设了什么？哪种失败对用户伤害最大？这个测试会漏掉什么？
工具会一直变。搞清楚自己到底在发布什么，这份责任始终在我们这边。如果盲目相信AI的输出，那就等于用AI把自己替换掉了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
