例如，每次点击某个节点按钮时，都应该导航到某个特定的表单，每次填写表单并点击提交按钮时，这些数据应该通过某个API调用发送到后端，返回状态代码201。它只是根据你提供的上下文预测最可能出现的下一个单词——就像一个超级先进的自动补全系统，背后有大量知识。当我们测试AI驱动的应用（LLM）时，我们面对的是概率系统，输出可能会有所不同。我们今天测试的系统是不可预测的。模型“理解”（基于以往的模式）雨通常

在测试领域，这意味着：当AI能够覆盖所有预见的场景时，人类测试工程师的核心价值转向发现那些无法预见的场景——那些边缘情况、那些业务逻辑的灰色地带、那些只有在真实使用中才会暴露的体验问题。传统的软件测试模式中，执行测试计划，设计测试用例，报告缺陷。发现这个问题的不是自动化脚本，而是一位有十年经验的测试工程师——他凭借对用户行为的深刻理解和对系统复杂性的敬畏，设计了一系列看似“不合逻辑”但反映真实用户

当然，以上的这些都是一些比喻，真实的工作情况肯定要复杂的多，所以在CI/CD的环境下，在业务逻辑复杂度适当的情况下，mabl代替某些自动化测试框架的实战场景，其中的性价比高低显然不言而喻，毕竟与其苦哈哈的花大时间用在调整自己的测试框架，还不如用专业的测试saas服务商提供的成熟测试平台？这里需要注意的是，如果你的本地自动化测试环境与CI/CD中的不一样，前几期文章中提到的mabl的对应测试程序环境

人力资源：标注技能（图像/文本/语音）、测试专长（功能/性能/安全/伦理测试）、AI知识水平（机器学习基础、模型理解能力）、工具熟练度（Python、TensorFlow、测试框架）对测试负责人而言，资源管理是“质量保障”的前提——只有提前锁定足够的GPU算力、高质量的标注数据、专业的测试人才，才能确保测试覆盖度，不用天天为“找资源”发愁。对AI项目团队而言，资源管理是“效率提升”的关键——合理分