腾讯 WorkBuddy 实战：一份登录需求，带你学会5种测试思路

摘要： 腾讯 WorkBuddy 能理解需求、拆解任务，还能协助生成测试用例。但对软件测试新人来说，真正值得学习的不是让 AI 一次生成多少条用例，而是如何分析需求、设计边界值、发现需求遗漏、评审测试用例，以及判断测试结果。这篇文章用一份登录需求，带你完成5个可以自己动手练习的测试任务。

学软件测试的时候，有个现象挺常见。

等价类、边界值、判定表，老师讲的时候都听懂了，题目也能做对。但真拿到一份登录需求，让你独立设计测试用例，反而不知道从哪儿下手。

是先测手机号，还是先测密码？

需求里没写的规则，要不要自己补？

AI 帮你生成了30条用例，你又该怎么判断有没有遗漏？

现在腾讯正在推广的 WorkBuddy，恰好可以拿来做这样一组练习。

它不只是一个能够回答问题的 AI 工具，还能理解自然语言任务、拆分执行步骤，以及在授权的工作空间里生成文档、表格等文件。

对于测试新人，我们其实不需要一上来就让它搭建自动化框架。

先用它帮我们分析一份简单的登录需求，再反过来检查 AI 的分析有没有问题，反而更容易真正理解软件测试。

今天就用一份登录需求，带你练习5种测试思路。

整个过程不要求你会 Python，也不需要搭建复杂环境。

一、开始之前，先把 WorkBuddy 准备好

腾讯 WorkBuddy 是一款 AI 智能体桌面工作台。

简单理解，普通 AI 聊天工具主要帮你回答问题，而 WorkBuddy 除了提供分析建议，还可以进一步规划任务、调用工具、处理文件，并形成具体的交付结果。

它的工作模式中，有三个比较适合我们今天练习的选项：

• Ask（仅问答）： 用来提问、分析需求、检查思路，不执行文件修改。
• Plan（计划）： 先规划任务和执行步骤，确认之后再执行。
• Agent（默认）： 适合执行任务、整理文档和生成文件。

不同版本的界面文字可能略有差异，具体以客户端显示为准。

第一次练习，建议先用 Ask 模式。

等到需要生成 Excel 测试用例时，再考虑切换到 Agent 模式。

如果要让它处理本地文件，建议先建立一个单独的练习目录，例如：

WorkBuddy-登录测试练习

把练习需求和生成的用例文件都放在里面，方便后面检查。

接下来准备我们的测试需求。

二、练习1：需求分析——先弄清楚到底要测什么

假设某个业务系统有一个手机号密码登录功能。

产品给出了下面四条要求：

登录功能需求（教学示例）

1. 用户输入手机号和密码，点击登录按钮。
2. 密码长度限制为8—20位。
3. 验证通过后进入个人中心页面。
4. 验证失败时，页面显示错误提示。

看起来很简单，很多新人可能已经开始写测试用例了。

比如：

手机号正确，密码正确，登录成功。

手机号错误，密码正确，登录失败。

密码错误，登录失败。

密码为空，登录失败。

这样写当然可以作为初步思路，但如果直接开始设计用例，有些问题很容易被忽略。

例如：

手机号必须是11位数字吗？

密码允许输入空格吗？

密码的长度是在前端校验，还是提交后由服务端校验？

验证失败显示什么错误信息？

连续输入错误密码会发生什么？

这些问题在需求中并没有明确答案。

这就是我们要学的第一种测试思路：需求分析不只是提取功能点，还要找出缺失的业务规则。

现在打开 WorkBuddy 的 Ask 模式，输入下面这段话。

提示词1：需求分析

你是一名软件测试学习助手。

请分析下面这份登录功能需求：

1. 用户输入手机号和密码，点击登录。
2. 密码长度限制为8—20位。
3. 验证通过后进入个人中心。
4. 验证失败时显示错误提示。

请完成：

1. 提取已经明确的业务规则。
2. 找出需求中存在的歧义和遗漏。
3. 整理需要向产品经理确认的问题。
4. 给出初步的功能测试点。

要求：
- 区分已确认规则与待澄清问题。
- 不允许自行编造业务规则。
- 输出尽量使用表格。
- 对不明确的内容标记“待澄清”。

看完 AI 的回答，我们需要重点检查什么？

首先，看看它有没有把手机号必须是11位这样的常见规则，直接当成已经确认的需求。

其次，看看它有没有发现登录失败提示、密码字符范围、账号状态等需要进一步确认的问题。

最后，看看整理出的测试点，有没有同时考虑正常流程和异常流程。

这里要强调一个很容易被忽略的区别：

业务上常见的做法，不等于当前产品已经确定的需求。

比如连续输错5次密码就锁定账号，确实是一些系统采用的机制。

但如果需求没有写，我们不能直接拿它当作测试验收标准。

AI 可以帮你提出建议，却不能代替产品经理确认业务规则。

这就是第一次练习真正需要掌握的知识。

三、练习2：等价类与边界值——为什么不能只测8位和20位？

软件测试新人经常会碰到一道题：

某个输入框要求密码长度为8—20位，应该怎样设计测试用例？

如果只回答8位和20位，其实还不够。

这里需要用到两种经典的黑盒测试方法：等价类划分和边界值分析。

先看等价类。

既然密码长度要求是8—20位，那么从长度这个维度，可以把输入划分为三类：

• 小于8位：无效等价类。
• 8—20位：有效等价类。
• 大于20位：无效等价类。

接下来再看边界值。

因为缺陷经常发生在边界及其附近，所以需要重点选择边界两侧的数据。

比如：

现在把任务交给 WorkBuddy。

提示词2：等价类与边界值设计

请针对登录密码长度8—20位的规则，
使用等价类划分和边界值分析设计测试数据。

要求：

1. 划分有效等价类和无效等价类。
2. 给出典型测试数据和边界值数据。
3. 说明每组数据的设计依据。
4. 输出测试数据表格。
5. 区分“长度符合规则”和“登录成功”。
6. 列出还需要确认的密码规则。

这里有一个需要特别注意的地方。

密码长度符合要求，不代表登录成功。

例如密码为8位，长度符合规则，但是如果密码内容不正确，仍然无法通过身份验证。

所以，我们在评审 WorkBuddy 生成的测试结果时，不能把“密码长度合法”和“成功登录”混为一谈。

另外，实际项目中还需要考虑一些更细的问题。

密码长度按照字符数还是字节数计算？

中文字符是否允许输入？

空格是否参与长度计算？

前端限制和后端校验是否一致？

这些内容并不是要求新人一次全部设计完，而是让大家理解：

测试数据不是随便凑几个数字，而是围绕明确的业务规则，有依据地选择代表性输入。

以后做年龄限制、订单金额、优惠券门槛、文件上传大小等测试，都可以使用类似思路。

四、练习3：需求评审——AI 有没有偷偷帮产品经理做决定？

前面我们已经让 WorkBuddy 分析需求，并设计测试数据。

现在换个角度。

假设产品经理追加了一条需求：

“为了保证账号使用正常，系统需要限制用户连续登录失败的行为。”

这句话听起来没什么问题。

但作为测试人员，你能直接开始写用例吗？

显然还不行。

因为至少有几个规则没有说明：

连续失败多少次才触发限制？

限制的是账号、设备，还是某个来源？

限制持续多久？

成功登录后是否清空失败次数？

限制解除后如何恢复正常登录？

如果 AI 直接给你生成一条用例：

“连续登录失败5次后，账号锁定30分钟。”

你应该怎么处理？

答案是：不能直接采纳。

因为当前需求没有规定5次，也没有规定30分钟。

这时我们可以反过来考考 WorkBuddy。

提示词3：需求歧义检查

请评审以下登录需求：

“为了保证账号使用正常，
系统需要限制用户连续登录失败的行为。”

你需要：

1. 找出影响测试设计的模糊规则。
2. 整理需要向产品经理确认的问题。
3. 区分业务事实、合理建议和未经确认的假设。
4. 不要自行指定连续失败次数和限制时间。
5. 暂时不要输出正式测试用例。

请使用表格输出评审结果。

这一步甚至可以故意追问：

“你能不能直接帮我规定失败5次锁定30分钟？”

如果 AI 给出了明确数值，再问它：

“这条规则来自原始需求的哪一句？”

你就能观察到 AI 是否能够区分建议和事实。

对于测试新人来说，这项能力非常重要。

实际工作中，产品需求不可能永远完整。

很多测试问题不是因为不会写用例，而是需求理解阶段就出现了偏差。

如果把错误的理解继续传递到测试用例、自动化脚本和验收标准里，后面做得再多，也可能是在验证一个错误的目标。

所以第三种测试思路是：

不要只检查功能是否符合需求，还要先判断需求本身是否清楚、是否足以支持测试。

五、练习4：测试用例评审——AI 一次生成30条，就说明覆盖充分吗？

现在我们已经有了一份初步需求分析，也练习了边界值设计。

接下来尝试让 WorkBuddy 生成测试用例。

这可能是很多测试新人最感兴趣的环节。

毕竟，以前需要手动整理的表格，现在可以让 AI 帮忙完成初稿。

我们使用下面这段提示词。

提示词4：生成可评审的测试用例

请基于下面四条登录需求生成测试用例：

1. 手机号密码登录。
2. 密码长度8—20位。
3. 验证成功进入个人中心。
4. 验证失败显示错误提示。

测试用例需要包含：

- 用例ID
- 测试场景
- 前置条件
- 测试数据
- 操作步骤
- 预期结果
- 对应需求
- 需求确认状态

要求：

1. 覆盖正常和异常场景。
2. 使用等价类与边界值方法。
3. 步骤要具体、能够复现。
4. 预期结果必须可验证。
5. 对缺失的业务规则标记“待澄清”。
6. 不得把未经确认的假设当作验收标准。

拿到结果后，我们先不要比较生成了多少条。

而是检查以下四个方面。

第一，前置条件有没有写清楚？

例如正常登录用例，应该明确测试账号已经存在、账号状态满足登录条件，且具有对应的正确密码。

如果前置条件缺失，其他测试人员拿到用例后就可能无法正常执行。

第二，操作步骤能不能复现？

“输入错误密码，验证登录失败。”

这句话并不算一条完整的测试步骤。

至少应该明确使用什么账号、输入什么类型的密码、点击什么按钮，以及观察哪个结果。

第三，预期结果是不是可以判断？

有些 AI 生成的预期结果会写成：

“系统正确提示。”

“页面显示正常。”

“功能符合预期。”

这些描述太模糊。

比如验证失败时，需要确认登录未成功、未进入个人中心，同时检查错误提示是否符合已经确认的需求。

提示文本尚未确定时，也应该标记为待澄清。

第四，需求到底覆盖了多少？

假设 AI 生成了30条用例，其中15条只是更换了不同的手机号数据。

虽然数量不少，但并不代表覆盖充分。

我们需要看的是，有没有覆盖明确的需求规则、关键异常分支和重要边界。

如果使用 WorkBuddy 的 Agent 模式，还可以继续输入：

“请将已确认的测试用例整理成 Excel 文件，待澄清的问题单独放在一个工作表中，文件保存到当前练习工作目录。”

然后打开生成的 Excel，检查表格内容、字段完整性和待澄清项是否正确保留。

文件成功生成，只说明这项文件任务完成了，不代表测试用例已经通过质量评审。

测试用例的价值从来不是数量越多越好，而是能否让测试执行人员准确验证业务。

这也是 AI 时代测试工程师仍然需要掌握的核心能力。

六、练习5：结果验证——接口返回200，测试就通过了吗？

最后一个练习，我们暂时不设计新用例，而是分析一次接口执行记录。

假设系统有一个登录接口。

某次请求获得以下响应：

HTTP 状态码：200

响应体：

{
  "code": 40101,
  "message": "账号或密码错误",
  "data": null
}

现在问你：

这条测试用例通过了吗？

对于刚接触接口测试的新人，可能会有人认为返回200就是成功了。

但实际上，这个结论并不成立。

HTTP 200通常表示这次HTTP请求得到了成功类响应，并不代表登录业务成功。

而响应体中的 40101 也只是教学示例，具体业务含义应以实际接口契约为准。

如果本次测试的目标是“正确账号与正确密码登录成功”，那么这个业务响应很可能与预期不一致。

但如果测试的是“错误密码登录失败”，它就有可能符合预期。

是否通过，还需要检查错误码、错误提示、登录状态等具体规则。

现在让 WorkBuddy 帮我们进行一次分析。

提示词5：测试执行结果判断

我正在学习接口测试结果分析。

某登录接口返回：

HTTP状态码：200

响应体：
{
  "code": 40101,
  "message": "账号或密码错误",
  "data": null
}

请分别分析两种测试场景：

场景A：正确账号、正确密码登录。
场景B：正确账号、错误密码登录。

请回答：

1. HTTP 200代表什么？
2. 能否据此认定登录成功？
3. 两种场景下分别应该如何判断？
4. 还需要什么需求信息或验证证据？
5. 哪些情况下暂时无法判断通过或失败？

请按“预期结果—实际结果—测试结论”
的格式整理。

这次练习最值得观察的，不是 WorkBuddy 能不能解释200和40101。

而是它是否会主动向你确认测试场景、接口规则和验收条件。

如果信息不足，它应该明确指出缺少哪些证据，而不是直接断言通过或者失败。

这也是软件测试和普通问题解答之间的一个重要区别。

测试不是简单判断一个结果看起来是否合理。

我们需要把实际结果与明确的预期进行对比，再根据证据给出结论。

在复杂项目中，还可能需要结合接口日志、数据库记录、页面状态和上下游服务响应进行综合分析。

请求成功，不等于业务成功；业务结果看起来正确，也不等于测试已经完成充分验证。

理解这一点，后面学习接口自动化测试和 AI Agent 测试时，会容易很多。

七、做完5个练习，你真正学到了什么？

回头看一下整个过程。

我们始终围绕同一份登录需求，没有切换复杂的业务场景，也没有让大家搭建庞大的自动化测试系统。

但实际上，你已经接触了软件测试中五种非常重要的思路。

如果还想继续练习，可以把登录场景换成注册、订单取消、优惠券使用，或者购物车商品数量调整。

第一次可以让 WorkBuddy 帮你生成测试点。

第二次建议自己先写，再让它帮忙检查。

第三次可以故意删掉需求中的某些规则，看看它会不会主动发现问题。

这三种练习方式，实际锻炼的是不同的能力。

特别是对于正在准备软件测试面试的同学来说，当面试官让你设计登录功能测试用例时，你不应该只是机械地背出几个场景。

而应该能够解释：

为什么要测这个边界？

为什么要确认这个需求？

为什么这条用例的预期结果还不能确定？

又为什么接口返回200，仍然有可能是业务失败？

当你能解释这些问题，才说明你真正理解了测试方法。

八、AI 能帮你写测试用例，但测试基本功还是要自己掌握

现在越来越多的 AI 工具都能够分析需求、生成代码、整理测试用例。

腾讯 WorkBuddy 也为普通工程师提供了一个相对容易上手的 AI 任务工作台。

对于测试新人，我觉得这是一件好事。

以前学完一个知识点，可能还要到处寻找业务案例才能练习。

现在可以自己准备一份需求，让 AI 协助拆解问题、检查思路、整理结果。

但这里有一个前提：

不要把 AI 的输出当成标准答案。

尤其是刚开始学习软件测试时，更应该关注 AI 为什么这么设计，你是否能够找到它的依据。

会使用 WorkBuddy 生成测试用例，是一种工具使用能力。

理解等价类、边界值、需求评审和验证证据，才是真正的软件测试基本功。

等你以后进一步学习 Python、接口自动化、Pytest，甚至 AI Agent 测试时，这些能力依然用得上。

工具可以帮你提高效率，但能不能判断结果对不对，最终还是取决于你对测试的理解。

如果今天这5个练习能够独立完成，不妨再找一个业务场景重新做一遍。

这比单纯让 AI 帮你生成100条测试用例，更值得花时间。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。