LLM赋能测试活动实现端到端自动化的四个环节八项关键任务

1LLM赋能测试活动实现端到端自动化

1.1愿景： L4/5级的自动驾驶

测试活动主要围绕着测试设计、用例编写、执行、结果分析和补充验证等环节。过往的自动化测试往往只局限于用例执行的自动化，依然需要人工编写自动化用例，更遑论用例执行结果的分析和用例、环境的维护等工作。结合着AI4SE，畅想一下实现整个测试活动端到端的自动化的可行性，形成了如下4个阶段8项关键任务，如下图所示。

笔者建议从 单元测试-接口测试-整个测试活动的自动化，从小达到，按照PDCA的方式，不断扩大自动化环的外延，来逐步实现测试活动的端到端自动化。

2四个阶段八项关键任务的解读

2.1 测试用例编写的自动化

天下武功，唯快不破，通过自动化提供测试质量的快速反馈可以解决绝大部分测试问题。而传统意义上的自动化测试其实是测试用例的自动化执行。此类自动化测试实施失败的一个典型问题就是“来不及写自动化测试”。因为这类的自动化实施，其投入和产出的极限是一种线性关系，也就是投一个人插1天秧，就有一天的成果，投两个人，就有两个人天的成果。甚至随着投入规模的扩大，协同方面的负效应还会拉低这种方式的回报率。通过考虑测试用例在编写方面的自动化程度，才是团队能更快从自动化测试的投资泥潭中脱身，更快迎来Break-even Point, 形成自动化测试的正反馈循环。这也是LLM被首先应用于（自动化）测试用例编写的原因。

【单元测试】目前来讲，这一部分的自动化目前应用较多的还是单元测试用例的自动化生成。按照PDCA理论，这一工作的任务明确、可验证性强，且可快速反馈，是端到端测试自动化的一个缩影。这一部分目前的方案已转向通过多Agent以多轮对话的方式实现测试用例的生成-验证-修复-筛选，以提升生成效果。据说阿里通义灵码即将发布的新版本IDE插件中将提供次方案。当然，笔者团队目前实施下来，该方案虽然对生成效果有帮助，但也拉长了耗时。在IDE中生成单测用例其实是一个时间敏感型的任务，这是后续要解决的核心问题。当然，如何通过各种方式来提升首次生成的成功率，这是一个基本的着力点。

【手工测试用例】也有部分团队，如字节、华为、工行等，等正在探索基于LLM来生成（手工）测试用例。目前对于测试点的生成效果已经达到（外包）中级测试工程师的能力。当然，整个方案的核心还在，将历史PRD与用例pair作为知识库。如果仅仅只将本次被测PRD作为输入，生产上几乎无法使用。

【自动化测试用例】在更高级别的，如接口自动化测试用例生成上，笔者也关注到了华为的团队，也是通过历史（手工）用例步骤-代码脚本pair作为知识库，当测试人员针对某个PRD的测试用例写完测试步骤后，通过LLM自动翻译成对应的测试脚本。由此笔者不禁想到，对于历史上推行了BDD/ATDD等自动化实践的团队来说，其实拥有了很大的一个宝藏。

简单小结一下，就是基于LLM的单元测试用例生成目前方案已经成熟，后续目标是提高速度。而手工测试用例和接口/UI自动化测试用例的生成，非常依赖于知识库的建设，如 需求-用例知识库、手工用例-自动化用例知识库等。一个意外发现是BDD/ATDD的团队很有机会厚积薄发。

2.2测试用例执行自动化

这部分包括用例执行和环境制备这两个部分。

测试环境的自动化程度决定了测试准备的便捷性、环境的一致性和测试的可重复性。环境和数据的管理，是自动化测试能成功实施的关键。当很多人把目光聚焦到测试平台等关于测试用例怎么写、在哪里写等表面问题时，老司机则会去重点抓测试环境和测试数据的基准化、更新维护等水面之下的问题，以确保团队能顺利出海而不是直接触礁。

一个判定成熟度的快速问题是，一次自动化测试用例集的执行，它的起点是什么? 越接近环境的动态申请/初始化以及使用、回收，成熟度越高。

在这个环节不是直接应用LLM，而是说通过LLM pipeline的编排，把测试环境、测试数据的动态获取、测试用例的发起执行等任务通过 LLM tools 模块能进行编排，让其成为整个LLM驱动端到端测试自动化的关键一环。

简单总结一下，这部分与其说这是LLM的应用能力，不如说这是组织在DevOps平台和环境/数据管理能力。

2.3结果收集与分析

在通过测试用例编写的自动化之后，用例的产生不再是瓶颈，团队获得自动化测试用例的成本已经接近于0。在这个情况下，工作量的洪峰来到了测试执行结果的分析上面。跟其它检测类似，自动化测试也存在“误报”和“漏报”的问题。

由于测试用例的巨大数量，即使是小概率的假失败，也会有相当数量的失败用例需要人工排查，然而因为这些是假失败用例，其排查结果必然是一场“死亡行军”，整个过程必然是充满压力，但是只会给团队带来挫败感。因此，这个情况下，团队必然要考虑引入测试结果的自动化分析，并提高对“假失败（误报）”判定结果的确信度。毕竟因为对”假失败“的误判可能会直接带来线上缺陷。

在运维领域，很早就提出了AIOPS的概念，而根因分析(RCA)则是其中一个核心的场景，运维团队通过各种AI算法来试图在运维事件、故障发生后快速、准确地进行根因分析，甚至是实现解决方案的自动推荐/自动实施。来到了LLM时代，不少运维团队也将目光从传统AI算法上转移到了LLM。其实，类似的能力完全可以用于测试用例执行结果的分析上。

在2024年的AIDD/QECON等大会上，来自华为等公司的团队均分享了他们在失败用例根因分析的案例。此类方案其实是在精准测试基础上的一个延伸。如某个（自动化）用例执行过程中，测试平台在收集用例执行结果（pass/fail）之外，还应收集

a)测试用例自身执行的日志

b)测试用例执行过程中在被测应用端产生的日志（需要流量染色+可观测平台）

再结合用例执行失败的根因知识库、历史执行记录等数据，就可以判断本次用例执行成功/失败是否符合预期，是一个缺陷(true positive)，还是一次假失败(false negative)。

另外一方面，通过”需求/调用链/代码行覆盖率“等测试完成指标的判定，提高对”假正确（漏报）“，也就是漏测缺陷的挖掘，进行补充测试。这在基于LLM的单元测试用例生成中已经是一个遴选有效用例的有效方案。

简单总结一下，测试管理者要充分认识到这一部分基建的重要性。

2.4用例报告和补充测试

这属于PDCA中的最后一环。根据分析结果，补充或者修复用例。

LLM生成测试报告是目前最为广泛的一个应用。在此基础上，通过对于预设完成标准（测试退出标准）的判断，找出其差距，然后进行补充测试，也就是进入第二轮次的端到端测试自动化过程，进而逼近该完成标准。这是后续的努力方向。

写在最后，笔者建议从 单元测试-接口自动化-整个测试活动的自动化 各个级别，通过PDCA环的不断变大，来逐步实现测试活动的端到端自动化。