从测试自动化到智能质量工程:AI正在重构软件测试

一个复杂软件的新版本上线前,测试团队通常要经历什么?

读需求、设计测试方案、编写成百上千条用例、准备环境、开发和维护自动化脚本、执行测试、分析缺陷,再随着需求不断变化,一轮轮做回归。

对于复杂系统,这个过程持续数周甚至数月并不罕见。

真正困难的还不只是工作量大。需求理解、用例设计、脚本开发、测试执行、缺陷分析和质量评估往往分散在不同人员和工具中。很多经验留在个人手里,历史用例和缺陷数据没有真正变成组织资产。项目做了很多年,测试也做了很多轮,但下一次仍有大量工作需要从头开始。

AI开始进入软件测试之后,这种状况正在发生变化。

它可以阅读需求、辅助分析业务,生成测试思路和用例,编写并执行自动化脚本,也可以结合历史数据分析缺陷和质量趋势。测试工程师则可以把更多时间放到测试策略、复杂边界、风险判断和最终质量确认上。

如果变化只停留在这里,AI仍然只是一个效率更高的测试工具。

东软更关注的是下一步:能不能把AI真正纳入软件质量体系,让测试从局部自动化进一步走向智能质量工程。

近日,在银川举行的第四届电子信息测试产业大会暨软件测试产教融合高质量发展论坛上,东软受邀分享《告别传统测试内卷,AI智能测试新范式来了!》,介绍了AI辅助测试的工程实践与平台化建设,以及东软对智能质量工程的探索。

AI进入测试

正在经历三个阶段

最早使用大模型做测试,通常从Prompt开始。

测试人员把需求交给模型,让它生成测试思路、测试用例、测试数据或者自动化代码。这解决了一部分单点工作的效率问题,也让很多团队第一次直观感受到生成式AI对测试工作的改变。

再往前一步,是智能体。

AI开始能够根据任务自行拆解步骤、调用工具、执行测试并反馈结果。过去需要测试人员在多个工具之间不断切换完成的一组操作,可以由Agent连续执行。

但企业真正大规模使用AI测试,还需要解决第三个问题:工程治理。

AI依据什么知识判断?遵循什么测试规则?哪些工具可以调用?什么结果可以直接采用?什么结果必须由人确认?出现问题后能不能找到完整记录?

这些问题不解决,AI生成得再快,也很难进入关键的软件生产流程。

因此,AI测试的评价标准也在变化。

最开始看的是生成效果,后来关注能不能完成一个完整任务;真正进入生产环境后,更重要的是结果能否验证、过程能否追溯、风险能否控制。

这也是东软所理解的智能质量工程。

QAMOR × Mote

让AI进入测试全流程

基于这一思路,东软构建了QAMOR与Mote协同的AI智能测试体系。

QAMOR是一站式AI测试平台,覆盖质量保证、多智能体协作、测试流程和质量风险分析;Mote提供智能体调度能力,支持多模型接入、本地大模型部署、工具调用、Agent流程编排以及知识关联。

两者结合后,AI可以进入从需求理解、测试分析、方案设计、用例生成,到自动化执行、缺陷管理和质量分析的完整过程。

这也改变了过去测试工作的组织方式。

过去,需求文档、测试用例、自动化脚本、缺陷记录和质量报告往往存在于不同系统中。现在,这些信息可以逐步通过数据、知识和智能体连接起来。

东软在实际应用中仍然坚持一个原则:AI生成,人工审核。

大量资料阅读、批量生成、数据关联和重复执行可以交给AI;测试策略、复杂边界、风险判断以及最终质量结论仍然由测试工程师负责。

AI擅长规模,人负责判断。

三个已经落地的典型场景

目前,这套体系已经应用于多个具体测试场景。

需求与测试设计

平台可以读取需求文档,识别关键业务逻辑,形成带ID关联的需求清单、测试思路和标准化测试用例,再通过AI评审和人工复核进行确认。

这使测试能够更早介入需求阶段,而不是等软件开发完成之后再开始发现问题。

Web自动化测试

AI根据业务特征和测试依赖生成测试用例与Playwright自动化脚本,并通过Docker隔离环境进行多任务并行执行。测试完成后,结果自动回传并统一归档。

对于测试团队来说,过去大量花在编写、执行和维护脚本上的时间,可以被进一步压缩。

质量分析

平台可以汇总项目缺陷数据,结合产品规范、质量评价模型、行业标准和ODC缺陷分类方法,对缺陷原因和质量风险进行分析,形成可以核查和追溯的质量报告。

AI开始从“执行测试”进一步进入质量分析环节。

AI会测试之后

更重要的是能不能信

这是AI测试真正进入企业生产环境后绕不开的问题。

大模型可能出现幻觉,可能错误理解业务规则,也可能在工具调用中产生不可预期的结果。对于涉及核心业务和敏感数据的软件系统,仅仅证明AI“能做”远远不够。

企业还需要知道:它依据什么做、调用了什么、产生了什么结果,以及出现问题后如何追溯。

为此,东软在AI能力之外增加了Harness工程层。

企业知识库、测试规则、标准化用例模板、智能评估器、工具权限和审计日志共同构成AI运行的约束机制。同时,平台支持不同模型切换和本地化部署,以适应企业在安全、性能、成本等方面的不同要求。

这套机制解决的不是AI“聪不聪明”,而是另一个更现实的问题:

如何让一个具有一定自主能力的AI,稳定地进入严谨的软件工程体系。

效率之外

还有一笔更重要的资产

结合现有项目实践与PoC验证,QAMOR × Mote已经在多个环节表现出明显的效率改善。

阶段性数据显示,测试设计效率提升约30%—40%,自动化测试脚本编写工作量缩减50%以上,回归测试效率实现倍数级提升。

具体效果会受到项目规模、系统复杂度、已有测试资产和自动化基础等因素影响。

但东软更看重另一个变化。

过去,一个优秀测试工程师积累多年的能力,很大一部分存在于个人经验里。即使形成文档、用例和脚本,也经常散落在不同项目和系统中。

人员变化之后,一部分经验就会流失。新的项目启动,很多事情还要重新做。

AI和知识工程结合以后,这种积累方式有机会改变。

历史用例、缺陷数据、业务规则、测试规范以及工程师的实践经验,可以逐步进入统一的知识体系,并在新的项目中被AI重新调用和复用。

测试由此不再只是一次项目活动,也开始成为一种可以持续积累的组织能力。

这可能比单纯提高30%或者50%的效率更有价值。

从测试自动化

到智能质量工程

过去二十多年,软件测试一直在推进自动化。

自动化解决的是重复执行问题:原来由人一次次完成的操作,逐渐交给机器。

AI带来的变化更进一步。

机器开始尝试理解需求、设计用例、调用工具、分析缺陷,甚至参与部分质量判断。

人的角色也随之变化。

测试工程师会减少大量重复性的阅读、编写和执行工作,把更多精力投入复杂业务理解、未知风险发现、测试策略制定和最终质量判断。

与此同时,企业真正需要建设的,也不再只是更多自动化脚本,而是一套能够把人、AI、知识、数据和工程规则组织在一起的质量体系。

东软正在沿着知识资产化、智能体协同、质量闭环和平台运营等方向继续推进这项工作。

软件测试不会因为AI而变得不再需要人。

但它很可能因此改变过去长期依赖人力规模和个人经验的生产方式。

从测试自动化走向智能质量工程,改变的不只是测试效率,更是软件质量能力的形成方式。


本文来源于DOIT传媒,文章内容仅供参考,不构成投资建议。

赞 ()

相关推荐

发表回复

评论列表

点击查看更多

    联系我们

    微信:百易小助手

    邮件:contact@doit.com.cn

    工作时间:周一至周五,9:30-18:30,节假日休息

    微信