一、 设计基础

确定根据：严格根据业务需求规格书、用户故事、合同条款、原型设计及合规要求。

建立可追溯性：创建需求可追溯性矩阵，保证每个需求有对应用例，并能双向追踪。

二、 用例组成（每条软件测试用例须包含）

唯一标识符：具唯一性的ID（如 UAT-PAY-001）。

确定标题：采用“证实+[条件]+操作+结--论”句式。

关联需求：注明对应的业务需求或用户故事编号。

优先级：定义高、中、低优先级。

清晰前置条件：列出执行前系统、数据、环境的必备状态。

分步操作步骤：使用主动语态，描述用户原子化操作。

具体测试数据：提供有效、无效及边界值数据。

可观测预期-结-果：描述每个步骤后，-界面、数据、系统状态的具体变化。

后置清理：说明怎样将系统恢复至初始状态。

三、 设计方法

聚焦业务情形：根据用户旅程和端到端业务流程设计，而不是孤立功能。

定义用户角色：针对不同用户角色设计用例，证实权限控制。

平衡正反向测试：

正向：包括所有主流程、典型途径。

反向：包括重点异常、非法输入、错误操作。

包括非功能验收：对性能、安全性、兼容性等确定验收标准并设计证实点。

四、 设计须知

避免技术术语，使用业务和用户语言。

避免过度细节，聚焦用户目的和重点操作。

保持用例独立性，降低耦合。

保证可维护性，便于需求变更时同步更新。

五、 评审

组织正式评审：召集业务、产品、测试、用户代表评审包括度和准确性。

使用检查清单：评审时对照以下清单：

是不是所有需求都有用例包括？

用例是不是代表真实用户视角和操作？

步骤、数据、-预-期结果是不是具体、无歧义？-

预期结果是不是可观测、可证实？

正向和重点异常情形是不是均已包括？

前置条件是不是清晰可达？