关注 霍格沃兹软件测试开发 公众号,回复「资料」, 领取人工智能测试开发技术合集
大模型正在重构软件研发流程。
过去写需求、写代码、写测试用例、写自动化脚本,都需要人一点点拆解、设计和实现。
现在,大模型几分钟就能生成一批测试点,十几分钟就能写出自动化脚本,甚至可以根据需求文档直接输出测试方案。
看起来,测试效率被大幅提升了。
但很多团队真正落地之后,会发现一个更棘手的问题:
大模型生成的测试内容,看起来很完整,但到底靠不靠谱?
它有没有漏掉关键边界?
它有没有覆盖异常路径?
它生成的测试结论能不能被复核?
如果业务出现问题,我们能不能说清楚:为什么当时认为这个版本是可以发布的?
这才是大模型时代软件测试真正的核心矛盾。
不是“AI 能不能生成测试内容”,而是“AI 生成的测试内容能不能被相信,测试结论能不能自证”。
在本届TID质量竞争大会上,正元智晟科技 CEO 杨长春将带来主题分享:
《大模型时代,软件测试如何做到可证可信?》
这场分享不只是讨论 AI 如何生成测试用例,而是进一步回答一个更关键的问题:
当 AI 开始参与软件研发和质量保障,我们如何证明测试过程可信、测试结论可信、质量决策可信?
一、为什么 TID质量竞争大会 要讨论“可证可信”?
TID质量竞争大会一直关注软件质量、工程效能、测试技术和企业级质量体系建设。
过去几年,测试行业的关键词更多是:
自动化测试
测试平台
持续集成
DevOps
质量左移
精准测试
智能化测试
但到了大模型时代,质量领域正在出现一个新的问题:
效率提升之后,可信度怎么保证?
AI 可以帮我们生成需求分析、测试用例、自动化脚本和测试报告。
但生成得快,不等于生成得准。
看起来完整,不等于真的覆盖。
语言表达专业,不等于结论可信。
这也是为什么在 TID质量竞争大会 这样关注质量竞争力和工程实践的场合,“可证可信”会成为一个非常值得讨论的话题。
因为企业真正需要的,不只是“AI 帮我写了一堆测试内容”,而是:
测试依据能不能追溯?
测试设计能不能解释?
测试覆盖能不能证明?
测试执行能不能留证?
测试结论能不能复核?
质量风险能不能被提前识别?
这背后,其实是软件测试从“效率工具”走向“可信工程”的关键转折。
二、大模型不是测试银弹,它更像一个强大的“生成引擎”
很多团队刚开始做 AI 测试时,都会从一个很直接的场景切入:
输入需求文档,让大模型生成测试用例。
这个方向当然有价值。
因为过去测试人员写用例,确实需要大量时间做需求理解、场景拆解、边界分析和用例编写。
大模型可以明显提升这部分效率。
但问题也出在这里。
如果我们把测试理解成“把需求改写成用例”,那么大模型确实很强。
但如果我们把测试理解成“发现风险、验证规则、支撑质量决策”,那么纯大模型方案就远远不够。
真正高质量的测试设计,至少需要三类能力。
第一类,是全面解。
也就是从业务流程、角色权限、数据状态、系统交互等多个维度,尽可能完整地覆盖正常路径和核心场景。
第二类,是边界解。
也就是识别输入边界、状态边界、权限边界、时间边界、容量边界和流程边界,找到最容易出问题的位置。
第三类,是反向解。
也就是不只是证明系统“能工作”,还要验证系统在异常输入、非法操作、冲突状态、失败依赖、极端条件下是否仍然可控。
而大模型天然更擅长的是生成“常规解”。
它可以根据已有语义,快速推断出一批高频、常见、合理的测试内容。
但对于深层边界、复杂约束、跨系统状态、领域规则冲突,大模型并不天然可靠。
这就决定了一个现实:
AI 可以提升测试生产效率,但不能单独承担可信测试的全部责任。
三、大模型时代,测试的核心矛盾变了
过去测试团队最关注的问题,往往是资源不够、时间不够、执行不够快。
所以大家持续建设自动化测试、测试平台、持续集成、质量门禁,本质上都是为了提高效率和覆盖率。
但大模型进入研发流程之后,矛盾开始变化了。
因为“生成内容”这件事正在变得越来越容易。
难的是生成之后怎么办。
比如:
AI 生成的测试用例,谁来判断是否完整?
AI 生成的测试脚本,谁来判断是否可靠?
AI 总结的测试报告,谁来判断是否真实?
AI 给出的质量结论,谁来承担最终责任?
如果线上出问题,能不能反推出当时测试为什么放行?
这也是杨长春在本次 TID质量竞争大会 分享中想要重点讨论的问题:
大模型时代,测试不能只追求“自动生成”,更要追求“可追溯、可解释、可复核”。
否则,AI 测试很容易从“提效工具”变成“风险放大器”。
它可能让我们更快地产出大量测试内容,但同时也可能让团队更难判断这些内容到底靠不靠谱。
四、可信测试需要从“内容生成”走向“证据闭环”
如果把大模型用于测试,只停留在生成用例、生成脚本、生成报告,价值仍然是有限的。
真正面向企业级复杂系统的测试能力,需要形成一个完整闭环:
这个闭环的关键,不是让 AI “多生成一点内容”,而是让每一个测试结论都有来源、有依据、有过程、有证据。
也就是说,测试不再只是输出一份报告,而是要能回答:
这个结论基于哪些需求?
这些需求对应哪些业务规则?
规则被映射成了哪些测试模型?
模型生成了哪些用例?
用例是否被真实执行?
执行结果是否有证据留存?
失败、跳过、异常是否可以被复核?
当测试过程可以被追溯、被解释、被复核,测试结论才真正具备可信基础。
这也是“可证可信测试”和普通 AI 生成测试之间最大的区别。
普通 AI 生成测试,更关注“生成了什么”。
可证可信测试,更关注“为什么这样测、是否真的测过、结论是否站得住”。
五、“大模型 + 知识图谱 + 模型驱动测试 + 神经符号验证”为什么重要?
在本次 TID质量竞争大会 的分享中,杨长春将介绍一种更适合企业级复杂系统的融合路径:
大模型 + 知识图谱 + 模型驱动测试 + 神经符号验证。
这套方法并不是简单地把所有问题都交给大模型,而是让不同技术承担不同角色。
大模型负责理解与生成。
知识图谱负责沉淀业务实体、关系、规则和上下文。
模型驱动测试负责把业务流程、状态变化和规则约束转化为可执行、可推导、可验证的测试设计。
神经符号验证则进一步补足大模型在严谨性、约束推理和结论校验上的不足。
可以简单理解为:
能力模块 | 主要作用 | 解决的问题 |
|---|---|---|
大模型 | 需求理解、内容生成、用例补全、报告辅助 | 提升生产效率 |
知识图谱 | 业务实体、关系、规则、上下文沉淀 | 避免只靠文本语义理解 |
模型驱动测试 | 流程建模、状态建模、路径生成 | 系统性覆盖正常、异常、边界场景 |
神经符号验证 | 规则约束、逻辑校验、结论复核 | 提升测试结论可信度 |
人类专家 | 风险判断、业务裁决、质量责任确认 | 处理复杂决策与最终责任 |
这套方法的价值在于,它没有把所有问题都简单丢给大模型,而是把不同技术放在更合适的位置上。
大模型解决效率问题。
知识图谱解决业务认知问题。
模型驱动测试解决覆盖系统性问题。
神经符号验证解决逻辑可信问题。
人类专家解决复杂判断和责任边界问题。
这比单纯喊“AI 自动生成测试用例”更接近企业真实落地。
六、为什么复杂系统更需要“可证可信”?
在简单业务里,AI 生成测试用例可能已经能解决不少效率问题。
但在复杂业务系统里,情况完全不同。
比如通信系统,往往涉及大量状态流转、协议约束、链路依赖和异常恢复。
金融系统,往往涉及账户、资金、风控、权限、审计和合规。
能源系统,往往涉及设备状态、调度逻辑、安全阈值和生产连续性。
这些系统的共同特点是:
业务链路长
规则约束多
异常场景复杂
数据状态变化频繁
系统之间强依赖
出错后的影响范围大
在这类场景里,测试不只是验证功能按钮能不能点通,而是要验证整个系统在复杂规则下是否稳定、可靠、可控。
如果测试依赖纯大模型生成,很容易出现三个问题。
第一,覆盖不完整。
大模型可能生成了常见场景,却漏掉低频但高风险的边界条件。
第二,规则不严谨。
业务规则之间可能存在隐含约束,大模型不一定能稳定识别。
第三,结论不可追溯。
当测试报告只是由 AI 总结出来,但缺少模型、规则、执行证据支撑时,很难经得起复核。
所以越是复杂系统,越不能只追求“生成得快”,而是要追求“验证得准、过程可追、结论可信”。
这也是 TID质量竞争大会 讨论这类议题的价值所在:
它不是停留在工具层面的“AI 测试用例生成”,而是进一步回到企业级质量工程的底层问题。
七、人的角色不会消失,但会被重新定义
大模型进入测试领域之后,一个常见问题是:
测试人员会不会被 AI 替代?
如果只是做重复性的测试内容编写、简单脚本生成、基础报告整理,这些工作确实会被快速自动化。
但在可信测试体系里,人的价值反而会更加突出。
因为 AI 可以帮助生成内容,但不能天然承担质量责任。
人的角色会从“手工执行者”,逐步转向:
业务风险识别者
测试模型设计者
规则体系建设者
测试结论复核者
质量可信体系负责人
也就是说,测试人员未来的核心竞争力,不再只是“会不会写用例、会不会点系统、会不会写脚本”,而是能不能把业务规则、风险模型、测试策略和工程工具组织起来,形成一套可持续运行的质量保障体系。
这也是测试能力向更广义复杂系统验证能力演进的重要方向。
八、这场 TID质量竞争大会 分享适合哪些人听?
如果你正在关注 AI 测试、智能化测试平台、企业级质量工程、模型驱动测试、测试可信度建设,这场分享非常值得关注。
尤其适合以下几类人:
测试负责人、质量负责人、测试架构师
测试开发工程师、自动化测试工程师
正在建设 AI 测试平台的技术团队
关注大模型落地质量风险的研发管理者
从传统测试向 AI 测试、智能化测试转型的从业者
通信、金融、能源、政企等复杂业务系统质量保障团队
这场分享不是简单介绍一个 AI 工具,也不是停留在“AI 生成用例”的浅层应用,而是会进一步讨论:
AI 生成的测试内容如何可信?
测试过程如何留证?
测试结论如何复核?
复杂系统如何构建可追溯、可解释、可验证的质量闭环?
测试人员在 AI 时代如何重新定位自己的价值?
对于正在做质量平台、智能化测试、测试开发转型的团队来说,这类议题会非常有启发。
九、讲师介绍
杨长春,北京正元智晟科技有限公司 CEO。
曾任 HPE(慧与)中国高级系统架构师,长期从事企业级软件架构、低代码平台、自动化测试与工程效能平台建设,拥有相关技术专利及社区分享经历。
他曾担任多个大型项目负责人或首席架构师,包括中国移动低代码开发平台总集首席架构师、HPE BBOSS 项目首席架构师等,并在通信、金融、能源等行业积累了丰富的架构设计与项目实践经验。
代表项目包括中信银行 IT 战略咨询等。
当前,杨长春重点关注大模型时代的软件质量可信问题,长期研究测试能力如何从传统功能验证,进一步走向复杂系统的可信验证。
十、真正的 AI 测试,不是让 AI 替你“写一堆用例”
很多团队今天谈 AI 测试,还停留在“输入需求,生成用例”的阶段。
这当然有价值,但远远不够。
因为测试的本质不是生产文档,而是发现风险、验证规则、支撑决策。
大模型可以让测试内容生产更快,但如果没有规则、模型、证据和复核机制,再漂亮的测试报告也可能只是“看起来很完整”。
大模型时代,软件测试真正要解决的问题,是让测试结论经得起追问:
为什么这么测?
依据是什么?
有没有覆盖关键风险?
执行证据在哪里?
结论能不能被复核?
这才是“可证可信”背后的真正价值。
当 AI 编码、AI 生成、AI 自动化越来越普及,软件质量保障也必须从“经验驱动”走向“模型驱动”,从“结果汇报”走向“证据闭环”,从“测试执行”走向“可信验证”。
这可能也是未来几年,测试从业者最值得关注的一条主线。
而这次 TID质量竞争大会 上关于“大模型时代,软件测试如何做到可证可信”的分享,正好把这个问题摆到了台前:
AI 可以让测试更快,但真正决定质量竞争力的,是测试结论能不能被证明可信。
重磅福利:购票即赠VIP课程!
为回馈广大参会者,凡从霍格沃兹测试开发学社渠道,购买TiD2026质量竞争力大会门票,即可免费获得学社人工智能测试开发训练营VIP课程录播!
体系化学习AI测试开发、大模型评测、智能体测试等前沿内容,让大会的每一分钟都持续增值!