企业官网建设流程全解析

编写测试用例这件事，说它简单的人，大概率没在迭代压力下真正写过。打开一个需求，试图弄清楚“完成”到底意味着什么，列出步骤，发现漏了三场景，回头再改，等觉得差不多的时候，Sprint 早已远去。每一个达到一定规模的团队，都逃不开这种循环。这便是手工编写测试用例的真实成本，也是 AI 自主生成测试用例应该从源头上解决的问题。

Katalon True Platform 通过内置的Katalon AI Assistant来处理这个难题。它能代替测试人员面对需求无从下笔的那段煎熬：AI 先阅读需求，遇到不明确的地方会主动提问，然后生成一份可供审阅的测试用例。一旦获得批准，它甚至可以自己执行这些测试。

下面，就按照平台当前的工作方式，完整走一遍这个流程。

先看清全局：到底在和什么打交道

Katalon True Platform 远不只是 Studio IDE，它把测试计划、编写、执行和分析串联在了一起。

• Katalon Studio：针对 Web、移动端、API 和桌面的脚本化自动化测试。
• Test Management：用于规划并追踪手工和自动化测试。
• Test Execution Cloud：在无需自建基础设施的情况下，跨浏览器和设备执行测试。
• Reporting and Analytics：提供发布就绪情况和测试趋势的可视化分析。
• True Production Insights (TrueTest)：根据发布后真实用户行为来生成测试。

而Katalon AI Assistant横跨所有这些模块。它并非一个需要在另一个标签页打开的独立产品，而是内嵌在平台中的聊天面板，始终能感知当前所处的页面。

在这套聊天界面背后，有六个专门负责不同工作的AI Agent。使用者虽然不会直接挑选某个 Agent，但了解它们各自的职责，能让整个工作流不再神秘。

开始之前需要满足的两个前提

想要让这一切顺利运转，有两个条件必须由管理员提前配置好。

1. 启用 AI 功能。进入Manage Systems>Configurations>AI Services，确保项目已开启 AI 开关。如果在界面上始终找不到Generate Test Cases按钮，这几乎就是原因所在。
2. 集成 Jira 或 Azure DevOps。AI 会直接从团队的 ALM 中拉取需求。没有这个连接，就没有可供阅读的内容。这是一次性配置步骤，具体文档可以在 Katalon AI Assistant 的相关指南中找到。

第一步：打开一条需求

进入Plans区域，就能看到从 Jira 或 Azure DevOps 导入的 Sprint 和发布。点进某个 Sprint，再点击任意一条需求，打开详情页。这里就是从需求生成 AI 测试用例的起点——AI 会直接针对工单中已经写好的内容进行工作。

AI 会阅读工单的标题和描述。它还能读懂工单中附加的图片，当需求包含流程图或带标注的截图时，这点尤其有用。但 AI 无法读取非图片格式的附件，例如 PDF 或 Word 文档。如果有重要的上下文信息只存在于那些文件里，最好在生成之前，将相关内容复制到需求描述中。

第二步：生成测试用例

在需求详情页的右上角，点击Generate Test Cases按钮。

如果 AI 判定这条需求还不够清晰，或者缺失了某些信息，它会在生成任何东西之前，先展示一个Additional Context Refinement区域。这一步千万别跳过。AI 提出的问题，通常都指向需求中真实的缺口——例如缺失了成功标准，或者未定义的边界场景。在这里补充上下文信息（包括应用 URL 和任何测试数据），会显著提升最终产出的质量。

当 AI 发现需求中存在模糊性，它会在生成前要求补充上下文。认真填写这步非常值得，花不了两分钟。

点击Start Generating并稍作等待。生成出来的测试用例会以紫色高亮显示，方便与系统中原本就存在的用例区分开。

逐条通读这些用例。AI 在覆盖显而易见的主场景方面做得相当不错，但有时也会漏掉只有团队才知道的上下文。所以，请把这些产物当作一份初稿，而非成品。

第三步：生成并审阅测试步骤

点击任意一条生成的测试用例，右侧会弹出一个详情面板。在这里点击Generate Steps，让 AI 为该用例编写出具体的操作步骤。

这些步骤是基于测试用例名称、描述、前置条件和关联需求而生成的。如果得到的结果太过含糊或不对，就点击Regenerate Steps再试一次，也可以直接点击某一步骤进行手动编辑。

当某条测试用例看起来没问题了，就点击Save。如果觉得它毫无用处，就选择Discard。等全部过完一遍之后，再用Save All或Discard All完成这一批次的处理。

保存下来的测试用例，会自动关联回最初的那条需求，因此，从一开始就内建了可追溯性。

第四步：留意 AI 置信度评级（这一点至关重要）

多数人第一次都会忽略它，然后追悔莫及。

创建手工测试运行时，每条测试用例都会获得一个 AI 置信度评级：High、Medium或Low。它反映的是从 AI 的视角来看，测试步骤写得有多清晰。只有当一次运行中的所有测试用例都达到 High 级别，才能使用 Autonomous Test Runner。

如果碰到了 Medium 或 Low 的用例，就得打开它们，把步骤打磨得更明确。像“进入设置页面”这样含糊的指令，得分就会很低。而像“跳转到 https://yourapp.com/settings 并点击 Account Preferences”这样具体的描述，得分就会很高。这听起来像是多了一道工序，但这种精确性对测试本身的益处，甚至会超越 AI 的需求。

不要忽视 Medium 置信度的用例。在截止日期临近时，很容易产生“推上去试试看”的侥幸心理，但通常都行不通。还是得把步骤修正好。

第五步：用 AI 来执行

一旦所有用例都达到了 High 置信度，就可以在测试运行页面上点击Run with AI。Autonomous Test Runner 会接管一切。

它会自主地逐个执行步骤。如果遇到自己处理不了的情况，它会暂停，并发送通知请求人工输入。测试人员给出回应后，它会继续执行。运行结束后，会得到一份完整的报告：每条用例的通过/失败状态、分步执行结果、截图、视频以及 AI 执行日志。

在点击End Run之前，要彻底审查这些结果。只有当结束运行之后，结果才会进入分析和报告模块，过早结束运行会带来不必要的麻烦。

第六步：当测试失败时

打开任何一个失败的结果，点击Analyze。Root Cause Analyzer 会检查整个执行过程，并给出它的判断：是应用出了 Bug，是测试步骤本身有问题，还是这纯粹是一条不稳定的 flaky test。

这一点很重要，因为并非每次失败都是 Bug。为一条写得很差的测试步骤去 Jira 里提单，纯属浪费所有人的时间。先让 AI 做出判断，再来做决定。

如果看起来确实像是真正的缺陷，就可以让 AI 助手去提交工单。它会根据执行日志草拟缺陷报告，并附上截图作为证据。这张工单会出现在 Jira 或 Azure DevOps 中，并关联到失败的测试结果。需要注意的一点是：为每个失败的测试用例单独提交一个 Bug。试图把多个失败合并到一个工单里，只会产出一份让任何人都难以进行分诊的混乱报告。

第七步：审视更宏观的图景

AI 助手还能回答项目级别的问题。打开聊天面板，可以这样问：

• “这次 Sprint 的发布就绪情况如何？”
• “哪些测试用例一直在持续失败？”
• “我们在哪些地方存在覆盖缺口？”

也可以从任何报告或仪表板内部触发这一能力。界面上有一个Insight按钮，点击它就会对当前屏幕上显示的数据发起 AI 分析。如果在某一天看到了一个诡异的失败尖峰，想弄明白原因，这是最快的方法，完全无需手动去翻遍日志。

一些真正有用的实践经验

走完这套流程后，有几条实践会让效率和质量产生质的不同。

• 把应用 URL 写进需求里。AI 需要知道去哪里执行，没有了它，一切很快会变得模糊不清。
• 在生成之前，给需求补充真实的上下文。可以先让 AI 助手检查需求，标记出它认为缺失的点，把这些缺口补上之后再点击Generate Test Cases。这样产出的测试用例会精准得多。
• 不要为了凑数而填充步骤。有的测试用例需要五步，有的需要十五步。AI 置信度评级会自动标记出那些过于单薄的用例。
• 即使截止日期迫在眉睫，也别忽视 Medium 置信度。推进并指望它能正常工作，这种诱惑很大，但通常不会如愿。同样的原则也适用于将 AI 应用于回归测试时——步骤定义的精确度，是区分可靠运行与 flaky 执行的关键。

结语

这项功能坦诚来讲的价值在于：它将测试用例编写中机械且重复的那部分工作剥离了出去，只给测试人员留下确实需要人类判断的部分。仍然需要由人来审阅一切，仍然由人来决定批准哪些内容，但不用每次都面对一张白纸从头开始。如果团队的 Sprint 时间正不成比例地消耗在编写测试用例上，这绝对值得一试。