============ 前言： 最近准备要换到一段新的旅程，想趁中间过度休息的时间整理一下目前这份工作得到的一 些经验以及心得。除了作为整理自我沉淀的心得之外，也想分享一下顺便和大家交流交流 。 以下说明本文的一些预设前提： 1. 我大部分的职业生涯都是QA，并没有太多完整Dev的经验 2. 此篇文章适用於产品为软体的产业，硬体以及韧体我并没有太多经验不确定是否适合 3. QA的学经历仍然是本科系(STEM)出身 4. Junior QA：CS知识或coding能力是同等学经历的SDE约3成左右 5. Senior QA：CS知识或coding能力是同等学经历的SDE约6成左右 6. 自动化测试的结果不稳定（伪阳性/伪阴性）我觉得是软体工程的问题而不是使不使用 AI的问题，故不特别讨论 ============ # QA更应该拥抱AI技术，而不是害怕被其取代 在当前的技术讨论中，「AI 写 Code 的能力越来越强，测试人员（QA）会不会最先被取 代？」似乎是一个最被大众讨论且被接受的共识。 但我的观点恰恰相反。我认为在软体开发中，「QA 才是这波 AI 浪潮下最大的受益者」 。 这听起来可能很反直觉，但如果我们观察软体工程以及品质的本质，从风险与回报的角度 来看，你会发现 QA 处於一个极其特殊的「不对称优势」位置。 这篇文章将探讨什麽工程师对 AI 充满顾虑，而 QA 却可以大胆拥抱 AI ，以及各种不同 等级的QA该如何善用这个技术来达成更高的效率。 ## 0 与 100 不同的开发方向 首先，我们需要厘清开发（Dev）与测试（QA）在产品生命周期中的不同责任。 软体开发像是一条光谱： 工程师（Dev）是从 0 到 100 的创造者。他们照着规格从无到有构建产品，每一行程式 码都是像层层往上叠的砖块一样将产品建构完成。 测试人员（QA）是从 100 到 0 的解构者。 我们拿到的是已经被构建好的产品（100）， 然後层层剥开细节，寻找裂缝与逻辑漏洞，试图将它还原成规格文件并验证。 正是这种出发点的极端差异，决定了两者在使用 AI 时面临的「压力」完全不同。 ## 代码的本质：外部产品 vs. 内部产品 为什麽工程师即便拥有能够写出复杂Code的AI，依然不敢放心地让 AI 「全自动」写 Cod e？原因在於「风险」。 工程师产出的程式码是「外部产品（External Product）」。它必须面对真实世界中数以 百万计的未知使用者、千奇百怪的网路环境、以及潜在的恶意攻击。这意味着程式码必须 具备极高的通用性与安全性。如果 AI 生成的程式码在百万分之一的场景下发生一次致命 的逻辑错误（注：最近明日方舟的Paypal事件就是一种），对公司来说就是毁灭级的灾难 。这种「对外交付」的沈重责任，导致工师在使用 AI 时必须支付极高的「信任成本」与 Review 时间。 反观 QA，我们产出的自动化程式码，本质上是「只」服务於公司产品的「内部产品（Int ernal Product）」。 我们的「对象」是明确且单一的——就是眼前的这个产品。 我们不需要让测试脚本相容於全世界所有的软体，只需要它能够测试我们公司的产品就可 以。 「外部产品」追求的是无懈可击的广度；而「内部产品」追求的是解决特定问题的深度。 正因为 QA 的程式码是「受限的」且「目标单一的」，这导致我们使用 AI 生成的Code「 验证是否合法」的成本远低於工程师。只要 AI 写出的 Code 能在这个特定版本、特定环 境下抓出 Bug（或帮助我们工作），它就是有价值的 Code。 这就是 QA 使用AI的「不对称优势」。 所谓不对称优势，是指我们处於一个「下行风险有限，但上行回报无限」的位置： 极低的下行风险： 过去我们常将风险解释为「修复脚本的成本」，但真正的风险应该是「退回手动执行 」 。当 AI 生成的测试脚本失效或无法执行时，我们最坏的情况仅仅是切换回原本的人工测 试模式。重点在於，无论是由 AI 执行还是由人工执行，最终的测试结果是一样的。这意 味着我们的「风险底线」就是现状。 举个例子： 你有一个test acse，内容是做A、B、C三个操作，之後验证状态是否为预期的，并且你本 来就有一份自动化测试在执行这个case了。 现在你们的软体改版，还是一样做A、B、C三个操作验证状态，但是UI改版了，於是你原 本的自动化测试告诉你某个UI找不到了无法执行。 这时候通常会是两种情况： 1.时间不够来不及修脚本所以这次改为人工执行 2.时间还够把脚本修好继续用自动化测试执行。 在这两个选择中，不论是人工执行或是用程式执行得到的结果都是一样的，从品质的角度 来看这两种方式都提供了一样的品质保证，唯一你有可能承担的风险只有「时间不够」（ 例如用程式跑只需要1分钟但是人工需要30分钟），而不是「品质下降」，这就是所谓的 「风险仅是退回手动测试」的意思。 注：当UI改动（或是业务逻辑改动）後本来测试就需要「跟着更新」，这个成本不论是手 动或是自动都要承担的，只是我们都把更新人脑的成本忽略了。但这本质上还是「成本」 而不是「风险」。 极高的上行回报 ： 相对於被锁定的低风险，一旦你接受使用AI来帮助执行测试，获得的却是「指数级的效率 提升」。 我们并非将结果交给 AI来产生，而是将 AI 视为一个「低风险、高回报」的增强外挂： AI 写的脚本不能用？那就退回手动，品质结果不变。 但只要这个脚本能够成功帮助我们执行测试，通常就是十倍速以上的效率跃进回报。 ## 实战落地：AI 赋能的两个层次 理解了优势後，我们该如何落地？许多人对 AI 自动化有个误区，认为必须一步登天，建 立完美的自动化框架。事实上，QA 使用 AI 可以分为至少两个层次： ### 1. 初级使用：繁琐任务 （适合 Junior QA / Manual Testers） 如果你的工作目前依赖大量手动测试，不要一开始就想着「将 Test Case 100% 转为自动 化代码」。你应该关注那些手动测试中「繁琐、重复、低脑力的任务。 举例： Log抓取： 你需要抓取android手机中你们公司产品app的log。但是你不知道adb logcat以及grep两 个指令，所以你以前只能每次都连线进去手机找到log档案复制出来并且ctrl+f一行一行 寻找。 但是如果你把这个问题拿去问AI後就可以得到一个adb + grep的一行组合指令解决你的问 题并且节省了许多时间。 Log 分析： 以前你需要花 5 分钟肉眼过滤 Device Raw Log 找错误代码，现在你可以花 30 秒让 A I 写一个 Shell Script 帮你parse raw log并且直接判断是否有Error。 资料生成： 需要许多笔符合特定格式或是规则的测试资料，以前人工执行的话要一直复制贴上资料并 且修改不同的部分（最大值、最小值、中间值、超出边界…等等），现在把这些规则告诉 AI之後，AI能在很短的时间内产出高品质资料。 为什麽在这个层次 AI 特别有帮助？ 首先是「积少成多的复利效应」。 假设你每天需要分析 20 个失败的 Test Case Log，手动查找原因平均每次耗时 5 分钟 ，这意味着你一天有 100 分钟（近 1.7 小时）消耗在单调的肉眼检查上。 若用 AI 生成的脚本辅助，将分析时间压缩至 1分钟，你每天就凭空多出了80分钟的深度 工作时间，这就是微小进步带来的巨大回报。 其次是「极低的验证成本」。 由於这些任务的 Scope 很小，要验证 AI 写出来的程式码或结果是否正确非常简单。相 比於工程师验证产品的高昂成本，QA 在这些繁琐任务上的试错成本几乎为零，是典型的 「低风险、高回报」投资。 对於这些任务，我们甚至可以抱持着「抛弃式代码」的心态。它们是为了取代当下那 100 % 的手动苦工而存在的。 * 如果它能用了，你赚到了时间。 * 如果它过期了或坏了，就丢掉它，让 AI 重新生成一个，或者暂时退回手动。 这些碎片化工具是通往自动化的「鹰架」。它们帮助手动测试者跨越了「不会写 Code」 的恐惧鸿沟，在一次次与 AI 的协作中，逐渐成长为能驾驭程式码的工程师。 ### 2. 进阶使用：开发自动化测试架构（适合Senior QAE / SDET） 当你以及团队跨过了初级阶段，进入到系统级自动化测试时，AI 的角色就从「写手」变 成了「副驾驶」。 在这个阶段，我们不能再依赖抛弃式代码，而是要建立稳健的架构。这时候，QA 的职责 是定义架构、制定方向、提供规格、设计介面、规范Pattern，然後让 AI 去填充具体的 实作细节。 有人会挑战：「如果内部产品充满了 AI 写的烂 Code，会变成团队的隐形杀手。」 这正是Senior QA或是SDET 的价值所在。AI 的产出效率越高，Code Review 的重要性就 越高。我们必须确保引入的自动化测试程式码符合软体工程标准。 但即便如此，相比於开发正式产品，QA 在建立自动化测试时的 Scope 依然小得多。 为什麽这麽说？ 工程师的产品程式码必须处理高同步、严格的资安标准、以及各种来自现实世界的攻击… 等等的各种极端情况。 而 QA 的测试程式码通常运行在受控的环境中，面对的是可预测的输入与单一的系统状态 。它不需要服务全世界，只需要服务公司产品。 因此，同样的资深工程师使用 AI，撰写自动化测试面临的技术复杂度指数远低於正式产 品，因此能换取指数级高的效率回报。这不再只是节省几分钟，而是能将原本需要「3 天 的手动回归测试周期，透过 AI 加速构建自动化测试，压缩至 2 小时内完成」。这对产 品发布节奏的影响是革命性的。 ## 结语：AI 无法模仿「品味」 最後，可能会有人问：如果 AI 能写 Code 也能写测试，那未来的 QA 价值在哪里？ 这是一个哲学问题。在我看来，工程师和 AI 追求的是「逻辑的正确」，但 QA 追求的是 「体验的品质」。 产品的最终使用者是人类，而只有人类能理解人类的痛点与「品味」。AI 可以帮我们写 出完美的 Assert 语句，但它无法告诉我们这个按钮的触感是否「对劲」，或者这个流程 是否让用户感到「挫折」。 如果我们承认了AI可以想出这些含有人类情感的test case，似乎也就承认了AI拥有了跟 人类一样的情感。至少在2026一月的今天，我觉得AI还没拥有这些能力（如果有的话应该 比取代QA还大条XD）。 总结成最後一句话：AI 负责处理逻辑的 0 与 1，QA 负责守护那不可量化的「人类体验 」。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 42.70.223.81 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1769242057.A.954.html 这是个不错的例子 通常来说，写test plan可以拆解为三个部分 1. 理解设计and规格 2. 发想test case 3. 写出来 我目前的感觉，AI在1跟3可以帮助我非常多，让我花更多的时间在2，因此设计出来的tes t plan品质更高 也因为有AI帮你读文件，所以你还真的不太用去打扰工程师 这个情况很有趣 这个code是你们的公司产品or只是为了测试产品的script? 如果是前者，这应该不是QA的范围XD 如果是後者，我觉得可以把标准放的低一点 我前阵子看到一个讨论很有趣： 有人提出说在用AI产东西来辅助你的时候，都把它当做一次性的东西 意思就是不要太追求一定要用AI产出一个终极无敌通用的东西来帮助你的所有task，把每 件事情都当作一次one-shot task，反正AI产code成本超低，而且对AI来说范围越小它产 出的品质反而越好 所以回到QA这边 有时候QA的task/script都很简单，如果我只是要写一个简单的shell script做批次档案 改名，但是却要经过3次以上的code review + coding style + 复杂度计算…等等的，反 而会让人不想写code来增加自己的效率 最後我想再次强调不是说QA就可以乱写，而是或许我们可以把bar跟scope都放低一点，用 70分的code换300%的效率增加。 如果要求要跟工程师写的公司产品code同样的标准，那这样的CP值感觉很低（成本太高） 抱歉我的确有用AI帮我润饰文章，看来矫枉过正了，我下次会注意 简单来说： QA要积极拥抱AI来帮助增进工作效率，例如用AI帮助你处理手动重复的任务来节省时间。 不要 太担心风险，因为你不是在写公司对外卖的产品，不用写到100分也没关系，坏了顶多改 回手动执行测试就好。 ※ 编辑: gigayaya (42.70.223.81 台湾), 01/26/2026 11:32:37