测试用例要写清测试前提、输入数据、操作步骤和预期结果，让另一位测试人员也能按同样条件执行并判断结果。不会写时，可以先照下面的登录示例完成一条，再逐步增加错误和边界情况。已有功能说明时，也可以用墨刀AI生成测试用例初稿，减少重复整理。
用例不是“测试登录功能”这样一句任务，也不是执行后的流水账。预期结果在执行前写明，实际结果在执行后填写；没有运行过的用例应保持未执行，不能因为文档看起来完整就标为通过。
先写一条别人能照着做的登录用例
假设项目支持手机号和验证码登录，测试环境提供未受限的测试账号及有效验证码。这一条只验证正常登录，不同时混入注册、密码修改和退出。具体手机号与验证码应由测试环境分配，不在公开文档中保存真实用户信息。
| 字段 | 示例内容 |
|---|---|
| 用例编号 | LOGIN-001 |
| 用例名称 | 未受限账号使用有效验证码登录 |
| 关联需求 | 登录需求中“有效验证码可登录”的规则 |
| 前置条件 | 测试环境可用；账号未受限；已取得当前有效验证码 |
| 测试数据 | 测试账号、对应验证码、环境与规则版本 |
| 操作步骤 | 打开登录页，输入账号与验证码，提交登录 |
| 预期结果 | 进入约定页面，显示对应账号的登录状态，未出现错误提示 |
| 实际结果与状态 | 执行后填写；当前为未执行 |
如果“约定页面”在PRD里有明确名称，正式用例应直接写该名称；如果会话建立还需接口检查，也应写出相应检查方式。教学表格展示的是字段组织方式，不是所有系统通用的一份测试标准。
前置条件和操作步骤，不要写混
“账号已被限制登录”是前置状态；“连续输入错误验证码直至限制”是建立该状态的一种操作过程。测试不同功能时，应决定是使用准备好的状态，还是把建立过程也作为测试内容，避免每条用例都依赖上一条已经执行成功。
操作步骤应足够明确，例如输入哪个字段、点击哪个按钮、在哪个页面检查。不要只写“正常操作”，也不要把无关的鼠标移动都记录进去。粒度应让执行者能够复现，同时便于维护。
正常登录写完，再补不同原因的失败
登录失败可能来自输入不完整、验证码错误、验证码到期、账号受限或网络问题。每一种情况都应说明不同的前提和结果，不能写成一条“输入各种错误数据，系统提示错误”。
| 场景 | 必须先知道的规则 | 重点检查什么 |
|---|---|---|
| 缺少验证码 | 必填校验和提示方式 | 不能登录，提示位置清楚 |
| 验证码错误 | 错误提示与次数累计策略 | 状态与提示符合已确认规则 |
| 验证码到期 | 有效期起点、终点和时间来源 | 到期后拒绝登录，提供下一步 |
| 账号受限 | 限制条件、持续时间和解除方式 | 限制期内不能绕过规则 |
| 提交时网络失败 | 重试与输入保留策略 | 不误报成功，能够恢复操作 |
如果规则尚未确定，先把问题反馈给产品和研发。测试人员可以提出风险，但不能在用例中悄悄发明业务政策。安全提示是否区分账号状态，也应按团队确认的策略处理。
边界值怎么写，关键在明确阈值
假设验证码发送后不足60秒有效，达到60秒失效，就应考虑59、60、61秒等边界附近的输入。这个数字只是教学例子，实际阈值以项目要求为准。测试时还需有可控制的时间条件，不能仅靠手动等待来获得稳定结果。
等价类则帮助归纳行为相似的数据组，例如有效验证码、错误验证码和空输入。可以参考ISTQB公开测试方法资料理解分类与边界，但方法名称不替代具体规则。
次数与状态相关的用例还要考虑前置数据清理。例如测试第五次错误后的限制，应保证初始错误次数已知；否则同一条用例今天通过、明天失败，可能只是被其他测试污染。
预期结果，怎样从“正常”写到可判断
“登录正常”缺少判断依据。可以具体到页面、账号状态、提示和数据变化；“保存成功”也应说明保存了哪条记录、刷新后是否存在、失败时是否产生半条数据。涉及接口或数据库检查时，应限定到有权限的测试环境。
实际结果则记录发生了什么，包括截图、日志或缺陷编号等必要证据。通过、失败、阻塞和未执行应区分：环境无法访问属于阻塞，不应随意记为功能失败，也不能当作通过。
用AI补初稿时，把未定义事项留下来
在墨刀AI测试相关入口提供需求和格式，要求输出前置条件、步骤、数据、预期结果及关联规则；同时要求实际结果留空，缺失规则单独提问。不要只输入“登录测试”，然后把一份常见场景清单直接交给团队执行。
想跟做完整AI生成过程，可以阅读AI生成测试用例教程。本页侧重用例写法，两者不应混淆为同一份泛泛介绍。
文档写完后，怎样保持可维护
保留需求版本、环境、用例编号和关联规则。需求变更时，先找受影响的条目，再决定修改、增加或废弃哪些用例。不要每次重新生成全部内容，把过去的执行记录与问题关联一起覆盖。
表单、ERP或APP项目都可以采用这一组织方式，但场景与风险需要单独补充。设计阶段可以结合表单原型的状态设计提前找出遗漏，再在真实系统中执行测试。
先写好一条正常路径，再逐条补异常和边界，是开始写测试用例的实用方式。准备好规则后，可以在墨刀AI整理测试用例，把时间更多用在发现规则缺口和真实执行上，而不是重复填写相同字段。
