同样是测试，为什么有人被AI抢饭碗，有人用AI抢别人饭碗？|代码|测试|用例|计算机|调用

在AI技术日益渗透到各行各业的今天，软件测试领域也不例外。上回《别再做“点点点”测试了！AI时代测试工程师的隐形技能树，你点亮了几个？》提到测试人员也该学门语言、懂点代码，这话题在圈里激起千层浪，反响强烈。

之所以用“争议”形容，是因为不少小伙伴觉得测试人员学代码，要么难如登天，要么性价比太低。非计算机专业出身的，压根没接触过；计算机专业但没深造好的，基础薄弱；从开发转行测试的，隔行如隔山，时间一长也都忘得差不多了。

今天，我就专门针对这个争议点，和大家好好聊聊。

先说说我自己的经历。我在测试领域摸爬滚打快10年了，是从硬件行业跨界过来的。刚入行时，我对数据库、Linux这些概念一窍不通，是个彻头彻尾的小白。可如今，我不仅精通多个核心系统的业务，还能熟练搞定数据库调优、服务器监控这些技术活。

最开始，我做测试就是打开界面，这儿点点，那儿戳戳，发现个问题就像捡到宝一样兴奋，赶紧记下BUG。后来，我学会了通过日志定位问题。再到现在，面对新业务或迭代更新，我的第一反应是打开GIT，查看程序的变动，仔细review代码的修改是否全面、能否真正解决问题。

很多时候，我会结合自己对系统整体代码的理解，对比研发人员的修改思路和我的预期，分析哪种更优，是否存在被忽视的漏洞。如果review代码时发现明显问题，我会直接找开发讨论；要是有疑问，就会在后续的功能测试中重点留意。

这种基于代码review的测试方式，目前是我最常用的。当然，我知道这未必适合所有人，但我坚信，透过代码洞察本质，开展更接近白盒测试的测试工作，绝对是未来测试行业的一大发展方向。尤其是在AI技术的辅助下，测试人员通过代码分析可以更快速地识别潜在问题，利用机器学习模型预测软件缺陷，甚至自动化生成测试用例。

所以，我坚定地站在正方阵营，认为测试人员看懂代码不仅重要，更是十分必要。接下来，我就从几个关键点，详细说说看懂代码的必要性。

一、生产问题复现

作为一名测试人员，经常要和生产环境中的问题打交道，很多时候需要第一时间去排查。这些问题大多是通过客服或者运维人员反馈过来的，但客户提供的信息往往并不完整，这就给问题的重现带来了很大的困难。比如：

有一天，客服团队向测试组反馈了一个客户投诉：客户在下单过程中，支付成功后发现除了有一笔付款成功的订单外，还出现了一笔待支付的订单。客户担心可能会被重复扣款，所以进行了投诉。

针对这样的投诉，测试人员首先尝试在灰度环境进行复现。下单并支付成功后，查看订单情况，发现只有一笔付款成功的订单，复现失败。

由于客户反馈的情况比较特殊，测试人员决定从代码逻辑入手进行分析。通过查看代码，可以确定客户调用的是购买接口。顺着代码的执行路径进行跟踪，发现了一个潜在的问题：如果第一次扣款操作超时或者失败，客户换卡重新支付时，由于幂等校验逻辑存在缺陷，系统可能会重新创建一笔订单并发起支付。这样一来，之前的订单就会一直处于待支付状态。

基于这一发现，测试人员通过客服与客户进一步沟通确认，得知客户第一次选择的银行卡余额不足，因此换卡支付时出现了上述问题。

由此可见，如果测试人员能够读懂代码，就可以更快地定位问题，而不是像无头苍蝇一样盲目地重复测试。即使你具备出色的探索式测试技能，在这种情况下也可能会浪费大量的时间。在AI的帮助下，测试人员可以利用自然语言处理技术分析客户反馈，快速定位问题代码段，从而提高问题复现的效率。

二、提升测试效率

在测试工作中，最让人头疼的莫过于频繁的返工。开发可能只修改了一小部分代码，但对测试来说，每次回归测试都意味着巨大的工作量。

如果能在开发提交修改后，第一时间通过代码变化来评估修改的完整性，那效率提升可不是一星半点。这也是我经常先读代码的原因之一。

除了review代码，阅读代码还能帮助我们完善测试用例。很多时候，我们可能会因为不熟悉开发的组件而忽略一些潜在的错误。比如我们系统的设计思路是这样的：如果支付调用银行超时，就会通过消息队列异步发送异常信息，同时有监听程序实时监控队列，一旦发现超时消息就重新调用，成功就继续后续业务，继续超时就再推回队列。

针对这种基于队列设计的异常情况，我们可能会因为不了解而漏掉相关的测试用例。这时候通过代码review，就能更好地发现这些关键点，从而完善用例中对消息异步推送的验证，更好地保证系统稳定运行。

更重要的是，在阅读代码的过程中，我们会带着对代码设计的不确定性和疑问，这使得我们在测试时更有针对性。根据我个人的经验，这种方式在测试中发现问题的概率也会更高。

AI技术，如代码分析工具和机器学习模型，可以帮助测试人员更快速地识别代码中的变化，预测可能引入的缺陷，从而提前准备测试用例，进一步提升测试效率。