如何编写测试用例
项目测试的流程应该是什么样的？
flowchart TD
A[需求评审] --> B[测试策略制定]
B --> C{测试类型}
C --> D[单元测试]
C --> E[接口测试]
C --> F[UI测试]
C --> G[性能测试]
D & E & F & G --> H[持续集成]
H --> I[缺陷管理]
I --> J[回归测试]
J --> K[质量报告]
K --> L[上线决策]测试用例的编写是软件测试的核心工作，需要系统化的方法保证完整性和有效性。以下从用例结构、设计方法和实践模式三个维度进行系统阐述：
一、测试用例结构化框架
flowchart TB
start[需求分析] --> define[确定测试目标]
define --> design{选择测试方法}
design --> |功能测试| EQ[等价类划分]
design --> |异常测试| BV[边界值分析]
design --> |流程测试| ST[状态转换法]
design --> |接口测试| CT[组合测试法]
design --> |性能测试| SP[场景分析法]
style define fill:#f9ddff,stroke:#333
style design fill:#cbe4f9,stroke:#333
EQ --> generate[生成用例]
BV --> generate
ST --> generate
CT --> generate
SP --> generate
generate --> validate[验证标准]
validate --> |是| output[输出用例]
validate --> |否| refine[重新设计]二、用例组成要素
classDiagram
class TestCase {
+String 用例ID
+String 模块路径
+Enum 测试类型
+String 前置条件
+TestStep[] 操作步骤
+String 预期结果
+Enum 优先级
+String 数据准备
+String 关联需求
+String 实际结果
+Attach 附件信息
}
class TestStep {
+int 步骤序号
+String 操作描述
+String 输入数据
+String 检查点
}
TestCase "1" *-- "1..*" TestStep三、典型用例模板
TC-APP-LOGIN-001
所属模块：用户认证/登录功能
测试类型：功能性测试
前置条件：已注册用户且账号未锁定
| 步骤 | 操作描述 | 输入数据 | 预期结果 |
|---|---|---|---|
| 1 | 打开登录页面 | - | 显示用户名和密码输入框 |
| 2 | 输入合法用户名 | [email protected] | 输入框显示明文 |
| 3 | 输入正确密码 | P@ssw0rd! | 密码显示为密文 |
| 4 | 点击登录按钮 | - | 跳转至用户仪表盘页面 |
四、进阶用例设计
1. 参数化用例（适用于数据驱动测试）
pie
title 登录失败场景分布
"错误密码" : 38
"无效账号" : 24
"格式错误" : 18
"空输入" : 15
"验证码错误" : 52. 状态迁移用例设计
stateDiagram-v2
[*] --> 初始态
初始态 --> 输入态 : 点击输入框
输入态 --> 验证态 : 提交表单
验证态 --> 成功态 : 验证通过
验证态 --> 失败态 : 验证失败
失败态 --> 锁定态 : 连续5次失败
锁定态 --> 初始态 : 超时30分钟
note right of 失败态
对应测试用例：
1. TC-LOGIN-ATTEMPT-004
2. TC-LOGIN-LOCK-001
end note五、用例编写实践原则
| 原则分类 | 实施要点 |
|---|---|
| 可追溯性 | 每个用例需关联需求ID，建议使用traceability matrix |
| 原子性 | 单个用例验证单一功能点，禁止出现”And”型复合条件 |
| 可自动化性 | 步骤描述需符合机器可读规范（如使用CSS Selector/XPath标识元素） |
| 异常覆盖 | 确保正向路径与负向路径用例比例达到1:3 |
| 数据独立性 | 测试数据与用例解耦，单独维护在测试数据池中 |
六、用例管理策略
gantt
title 用例生命周期管理
dateFormat YYYY-MM-DD
section 需求分析
用例设计 :a1, 2024-03-01, 7d
评审完善 :a2, after a1, 3d
section 测试执行
基线化发布 :a3, 2024-03-11, 1d
按需执行 :a4, 2024-03-12, 14d
结果分析 :a5, 2024-03-26, 3d
section 维护优化
失败用例修复 :a6, after a5, 5d
回归验证 :a7, after a6, 5d
版本归档 :a8, after a7, 2d七、智能用例生成（AI辅助）
graph LR
A[原始需求] --> B{需求解析引擎}
B --> C[功能点拆解]
B --> D[业务规则提取]
C --> E[生成基础用例]
D --> F[生成异常用例]
E --> G[用例优化器]
F --> G
G --> H((完整用例集))
style H fill:#90EE90,stroke:#228B22建议：
- 对支付功能验证可结合以下维度：
mindmap
root(支付验证)
正常流
余额充足
第三方支付成功
异常流
余额不足
支付超时
重复支付
容错处理
断网恢复续付
支付金额篡改检测
对账异常处理多条件规则的测试设计
以”跨店满减+店铺券+品类折扣”叠加场景为例：
业务规则描述
- 满减规则: 订单满200减50（可跨店累计）
- 店铺券: 满150减30（限当前店铺商品）
- 品类折扣: 美妆类商品额外9折
- 叠加规则:
- 店铺券与满减可叠加
- 品类折扣优先于其他优惠
- 最终结算金额不低于商品成本价（100元）
测试设计可视化
flowchart TB
A[商品分组] --> B{符合满减条件?}
B -->|是| C[计算满减]
B -->|否| D[跳过满减]
C --> E{使用店铺券?}
D --> E
E -->|是| F[计算店铺券]
E -->|否| G[跳过店铺券]
F --> H{含美妆商品?}
G --> H
H -->|是| I[应用品类折扣]
H -->|否| J[保持原价]
I --> K[校验成本价]
J --> K
K --> L{价格≥100?}
L -->|是| M[确认支付]
L -->|否| N[触发异常]关键测试用例示例
场景1：完美叠加
测试数据：
- 跨店商品总额：210元（含美妆商品150元）
- 当前店铺商品：80元
- 使用店铺券：是
执行路径：
graph LR
A[满210元] --> B[减50满减]
B --> C[减30店铺券]
C --> D[美妆150元打9折=135元]
D --> E[总金额=135+80-50-30=135]
E --> F[135>100 ✔]场景2：互斥条件
测试数据：
- 跨店总额：180元（含美妆商品50元）
- 当前店铺商品：20元
- 强制使用店铺券
执行路径：
graph LR
A[总额200元?] --> B{否}
B --> C[无法使用满减]
C --> D[尝试用店铺券]
D --> E{店铺商品不足150}
E --> F[拒绝使用店铺券]
F --> G[总金额=50*0.9+20+130=199]
G --> H[199>100 ✔]场景3：价格保护
测试数据：
- 美妆商品成本价100元，促销价95元
- 强制应用品类折扣
执行路径：
graph LR
A[95元打9折=85.5] --> B{低于成本价?}
B -->|是| C[触发价格保护]
C --> D[自动恢复为100元]测试点设计速查表
| 测试类型 | 测试点示例 | 预期结果 |
|---|---|---|
| 正向流程 | 同时满足满减+店铺券+品类折扣 | 叠加后价格正确 |
| 边界条件 | 订单总额199/200/201元 | 触发/不触发满减 |
| 异常场景 | 券后价格<成本价 | 触发价格保护机制 |
| 互斥验证 | 美妆商品不使用品类折扣 | 仅享受满减+店铺券 |
| 极端组合 | 10件美妆品+其他店铺商品 | 正确分级计算折扣 |
简化设计步骤
组合优先级：
- 第一优先级：满减触发边界（199/200/201）
- 第二优先级：店铺券与满减的叠加计算
- 第三优先级：品类折扣的特殊处理
必须覆盖的特殊值：
- 商品金额正好等于成本价
- 多优惠叠加后四舍五入
- 优惠券使用顺序错误时容错
用判定表（决策表）能更清晰地展现多条件组合与结果的对应关系。我们基于之前的电商活动案例构建简化判定表：
判定表设计步骤演示（满减+折扣+店铺券）
条件桩定义：
| 条件名称 | 取值说明 |
|---|---|
| C1: 订单总金额 | >=200 / <200 |
| C2: 使用店铺券 | 是 / 否 |
| C3: 含美妆商品 | 是 / 否 |
动作桩定义：
| 动作名称 | 触发条件 |
|---|---|
| A1: 应用满减 | C1=True |
| A2: 应用店铺券 | C2=True 且店铺商品>=150 |
| A3: 应用折扣 | C3=True |
| A4: 价格修正 | 结算价<成本价时触发 |
精炼后判定表：
flowchart LR
subgraph 条件组合
C1[总金额>=200]
C2[使用店铺券]
C3[含美妆商品]
end
subgraph 动作结果
A1[满减-50]
A2[店铺券-30]
A3[折扣9折]
A4[价格保护]
end
条件组合 --组合规则--> 动作结果完整判定矩阵：
| 用例 | C1 | C2 | C3 | 触发动作 | 金额计算示例 | 测试要点 |
|---|---|---|---|---|---|---|
| 1 | T | T | T | A1+A2+A3->A4 | (300×0.9-50-30)=190 >100 ✔️ | 多重优惠叠加 |
| 2 | T | T | F | A1+A2 | (250-50-30)=170 ✔️ | 跨品类组合 |
| 3 | T | F | T | A1+A3 | (220×0.9-50)=148 >100 ✔️ | 仅基础优惠 |
| 4 | T | F | F | A1 | (200-50)=150 ✔️ | 最低满减条件 |
| 5 | F | T | T | A2(+检查失败→A3) | (180×0.9)=162，券不可用 ❌→162 ✔️ | 店铺券使用限制 |
| 6 | F | F | T | A3 | (150×0.9)=135 ✔️ | 纯品类优惠 |
| 7 | F | F | F | 无优惠 | 原价支付 | 无优惠场景 |
| 8 | T | T | T | (极端值)A1+A2+A3触发A4 | (120×0.9-50-30)=88 →修正为100 ✔️ | 价格保护机制 |
精减后的核心测试用例：
| 用例 | 名称 | 验证重点 | 预期结果 |
|---|---|---|---|
| T1 | 三重优惠叠加 | 检查满减+店铺券+折扣计算顺序 | 最终价=原价×0.9-50-30 |
| T2 | 临界满减200 | 验证满减触发边界 | 200→150，199→原价 |
| T3 | 无效券使用 | 店铺商品<150时强制用券 | 提示”不符合用券条件” |
| T4 | 价格保护触发 | 优惠后95→打折后85.5→触发保护 | 自动修正为100元 |
| T5 | 纯美妆订单 | 仅应用品类折扣 | 原价×90% |
异常场景补充：
stateDiagram-v2
[*] --> 正常流程
正常流程 --> 异常1 : 重复叠加优惠券
正常流程 --> 异常2 : 优惠后负金额
异常1 --> 处理1 : 报错"优惠不可重复使用"
异常2 --> 处理2 : 修正为成本价100元
处理1 --> [*]
处理2 --> [*]用例执行
一、执行流程标准化（流程图）
flowchart TD
A[执行准备] --> B[环境检查]
B --> C{环境正常?}
C -->|是| D[按优先级执行用例]
C -->|否| E[终止并报障]
D --> F[详细记录结果]
F --> G{发现缺陷?}
G -->|是| H[提交缺陷报告]
G -->|否| I[标记用例状态]
H --> J[跟踪缺陷修复]
J --> K[回归测试]
I --> L[生成报告]
K --> L二、关键环节规范说明
必须文档化：
- 环境信息表（含数据库/IP/账户）
- 数据准备清单（测试账号+测试订单ID示例）
- 紧急回滚方案（遇到严重问题时的处置流程）
2. 执行过程控制
stateDiagram-v2
用例状态 --> 未执行
未执行 --> 执行中: 开始测试
执行中 --> 通过: 结果符合预期
执行中 --> 失败: 结果不符
执行中 --> 阻塞: 环境问题
失败 --> 已修复: 开发修复
已修复 --> 待验证
阻塞 --> 待处理执行记录表示例：
| 用例ID | 执行人 | 执行时间 | 实际结果 | 附件证据 | 状态 | 关联缺陷ID |
|---|---|---|---|---|---|---|
| TC_101 | 张三 | 2023-08-01 | 错误提示”优惠码过期” | 截图 | 失败 | BUG_0045 |
| TC_102 | 李四 | 2023-08-01 | 成功减价50元 | 无 | 通过 | / |
3. 缺陷管理规范
sequenceDiagram
测试人员->>缺陷系统: 提交新建缺陷
缺陷系统->>开发人员: 自动分配责任人
开发人员->>缺陷系统: 标记"修复中"
开发人员->>缺陷系统: 标记"已修复"
测试人员->>缺陷系统: 执行验证
alt 验证通过
测试人员->>缺陷系统: 关闭缺陷
else 验证失败
测试人员->>缺陷系统: 重新激活缺陷
end优质缺陷报告要素：
mindmap
root((缺陷报告))
必填项
标题
严重等级
复现步骤
预期结果
实际结果
增强项
环境信息
日志片段
网络抓包
前后端版本
关联测试用例三、执行效率技巧
1. 智能执行策略
gantt
title 测试执行排期优化
dateFormat YYYY-MM-DD
section 核心路径
冒烟测试 :done, des1, 2023-08-01, 1d
关键功能验证 :active, des2, 2023-08-02, 2d
section 次要路径
兼容性测试 : des3, 2023-08-04, 3d
异常场景覆盖 : des4, 2023-08-07, 2d2. 证据留存标准
graph LR
基本证据 --> 截图
基本证据 --> 日志
进阶证据 --> 视频录制
进阶证据 --> 接口响应
特殊证据 --> 数据库快照
特殊证据 --> 网络抓包四、执行后闭环动作
质量分析报告
xychart-beta
title "执行结果分布"
x-axis ["通过", "失败", "阻塞"]
y-axis "数量" 0 --> 40
bar [35, 8, 2]缺陷跟踪流程
一、核心流程框架（状态机视图）
stateDiagram-v2
[*] --> 新建 : 测试提Bug
新建 --> 已确认 : 开发初审
已确认 --> 已分配 : 指定责任人
已分配 --> 修复中 : 开始编码
修复中 --> 已修复 : 提交代码
已修复 --> 已验证 : 测试验证
已验证 --> 已关闭 : 确认通过
已验证 --> 重新打开 : 验证失败
已关闭 --> 重新打开 : 复现问题
新建 --> 驳回 : 无效报告
已分配 --> 挂起 : 暂不处理
挂起 --> 已分配 : 恢复处理二、分阶段规范说明
1. 提交阶段
mindmap
root((缺陷提交))
必填字段
标题
严重等级
优先级
复现步骤
预期结果
实际结果
增强信息
环境快照
错误日志
测试数据
关联用例
重现频率示例提交规范：
flowchart LR
低优先级 --1天内响应--> 开发
中优先级 --4小时内响应--> 开发主管
高优先级 --立即响应--> 技术总监2. 分析分配
sequenceDiagram
测试人员->>缺陷系统: 提交缺陷
缺陷系统->>开发主管: 提醒邮件
开发主管->>缺陷系统: 指派责任人
开发主管->>测试人员: 询问补充信息
测试人员->>缺陷系统: 更新详情3. 修复阶段
gantt
title 缺陷修复时间线
dateFormat YYYY-MM-DD
section 严重缺陷
需求理解 :done, des1, 2023-08-01, 1d
代码修改 :active, des2, 2023-08-02, 2d
unit test : des3, after des2, 1d
section 普通缺陷
代码调整 : des4, 2023-08-03, 3d4. 验证阶段
pie
title 验证失败原因
"修复不完整" : 45
"引入新缺陷" : 30
"环境差异" : 15
"误判问题" : 10三、关键控制机制
graph TD
deploy[版本发布] --> check{致命缺陷=0?}
check -->|是| next1{严重缺陷≤2?}
check -->|否| stop1[禁止发布]
next1 -->|是| next2{普通缺陷≤5?}
next1 -->|否| stop2[需审批]
next2 -->|是| pass[允许发布]
next2 -->|否| stop3[走加急流程]四、特殊场景处理
1. 争议处理流程
sequenceDiagram
测试->>产品: 争议提审
产品->>三方会议: 召集会议
三方会议->>结论: 判断是否缺陷
结论->>缺陷系统: 更新状态2. 暂挂缺陷管理
erDiagram
DEFECT ||--o{ HOLD_REASON : has
DEFECT {
string id
string title
date hold_date
}
HOLD_REASON {
string defect_id
enum reason_type
string description
}五、持续改进
1. 根因分析
graph TD
现象 --> 直接原因
直接原因 --> 系统原因
系统原因 --> 流程缺陷
流程缺陷 --> 管理改进2. 知识沉淀
gitGraph
commit id: "典型缺陷入库"
commit id: "编写避坑指南"
branch fix-process
commit id: "优化验证脚本"
checkout main
merge fix-process本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 听故事的人！
相关推荐
2025-04-12
有效的提取测试点
在软件测试中，高效提取测试点是保障测试质量的关键。以下是结合多种测试设计方法的系统性解决方案，通过流程框架、分类模型和典型案例进行说明： 一、结构化提取流程框架flowchart TB subgraph 需求分析 A[分解用户需求] --> B[识别业务规则] B --> C[明确输入输出] C --> D[确定功能边界] end subgraph 测试设计 D --> E{选择设计方法} E --> F[等价类划分] E --> G[边界值分析] E --> H[场景分析法] E --> I[状态转换法] E --> J[组合测试法] end subgraph 测试点形成 K[关键特征筛选] L[测试变量关联] M[异常路径挖掘] end subgraph...
2025-04-11
软件测试入门
软件测试是通过执行系统或组件来评估软件质量的过程，旨在发现软件中的缺陷(错误或bugs)，验证其是否符合需求规范，并评估其是否满足最终用户的需求。 mindmap root((软件测试)) 定义 验证软件质量 发现缺陷 验证需求符合性 目的 提高质量 降低风险 提供质量信息 重要性 确保可靠性 提升用户体验 降低维护成本 软件测试的主要类型flowchart TD A[软件测试类型] --> B[按测试层次] A --> C[按测试方法] A --> D[按测试阶段] B --> B1[单元测试] B --> B2[集成测试] B --> B3[系统测试] B --> B4[验收测试] C --> C1[黑盒测试] C --> C2[白盒测试] C --> C3[灰盒测试] D --> D1[功能测试] D -->...
2025-04-12
质量模型
软件质量模型详解质量模型是描述和评估软件产品质量特性的框架，它系统化地定义了软件质量的构成要素和评价标准。以下是质量模型的全面解析： 主要质量模型图示mindmap root((软件质量模型)) ISO 25010 功能性 可靠性 易用性 效率 可维护性 可移植性 McCall模型 产品运行 产品修正 产品转移 Boehm模型 基础特性 可用性 可维护性 1. ISO 25010质量模型（最新国际标准）flowchart TD A[ISO 25010] --> B[功能性] A --> C[性能效率] A --> D[兼容性] A --> E[易用性] A --> F[可靠性] A --> G[安全性] A --> H[可维护性] A --> I[可移植性] B -->...
2024-01-30
使用deepseek设计一个计数器
介绍这是一个使用纯html+css+javascript实现的简单符合直觉的计数器，所有的功能都有直观的表达。你可以用于类似于记分的操作，它可以单个账号进行删除操作，同时也可以一键重置得分/删除账号数据，同时最后会有总计数，同时通过 localStorage 实现数据持久化。 地址https://github.com/FXnadu/PocketTools/tree/main/日考核计数器 使用v3.0.0 使用：通过头部的输入框进行添加文本内容，然后点击添加账号的按钮，进行添加账号（名字）即可通过+-按钮进行记分，同时所有的删除为了防止误删会有弹窗确认，最后一键清除所有数据的敏感操作不可逆，添加了输入当天日期的校验。 截图
2023-07-23
从LLM训练的方法中总结大语言模型的提问方法
为了更好的使用LLM的对话模型,我们最好是可以从理解LLM是如何训练的角度去作出我们的提问,但是本文只作为一个如何更好的与ChatGPT等AI交流所写的文章记录,因此不多赘述 . 文章给出的方法主要分为两大原则: 第一个原则是写清楚具体的说明，第二个原则是给模型时间思考。 第一个原则：给模型明确而具体的指示第一个原则，非常明确和具体的说明。通过提供尽可能清晰和具体的说明来表达您希望模型做什么。这将引导模型达到所需的输出，并减少您获得不相关或不正确响应的情况。 不要将编写明确提示与编写简短提示混淆，许多情况下，较长的提示实际上为模型提供了更多的清晰度和上下文，这实际上可以导致更详细和相关的输出。 分隔符使用分隔符可以避免提示词冲突。如果用户在提示中添加某些输入，你可能给出与你想要的任务不符的指令, 可能会给模型一些相互冲突的指令，这可能导致模型得出的不是你想要的指令 , 所以使用分隔符非常有必要。 分隔符可以是任何将特定文本片段与提示的其余部分分开的清晰标点符号。可以使用引号，XML...