正在经历三个阶段

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

再往前一步，是智能体。

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

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

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

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

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

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

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

让AI进入测试全流程

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

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

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

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

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

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

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

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

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

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

更重要的是能不能信

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

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

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

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

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

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

还有一笔更重要的资产

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

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

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

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

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

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

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

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

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

到智能质量工程

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

AI带来的变化更进一步。

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

人的角色也随之变化。

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

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

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

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

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

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