如何做好测试用例设计？
2022-01-14 08:58:45 3 举报AI智能生成
如何做好测试用例设计
作者其他创作
大纲/内容
测试用例设计
确定测试范围
必须有完整的需求文档
需求已经组织评审和澄清
必须有完整的功能列表
用例设计原则
遵循“边界值”全覆盖原则
遵循”等价类划分场景全覆盖原则”
遵循”测试用例路径唯一“原则
遵循“单条用例覆盖最小化”原则<br>
遵循“测试用例与测试用例之间最低耦合度”原则
用例设计维度<br>
功能
正向（正常）场景<br>
逆向（异常）场景
非功能<br>
性能
单品（模块）性能
整体性能
网络传输性能
可靠（稳定）性
时间维度
负载稳定性
健壮性
看门狗
异常掉电
反复重启
易用性
安装易用性
运维易用性
功能操作易用性
客户体验
安全性
数据存储安全
网络传输安全
测试用例编写
测试用例编写前提
测试范围已经确定
测试点已经梳理完成
用例转换路径：业务需求-功能需求-测试需求-测试点-测试用例
用例标题
语言简洁，阐明本条用例是干什么
一句完整的话
遵循“条件/动作"规则
用例级别分布
Lve 1 ：基本(～10%)
Lve 2：重要（～20%）
Lve 3：一般（～60%）<br>
Lve 4：生僻（～10%）
预置条件
执行测试用例关键必备条件<br>
让用例的执行者更加明确系统当前状态
预置条件不能阻塞测试用例的执行
操作步骤
需要明确“测试输入”的数据
操作路径唯一，不唯一则多条用例覆盖
以“面向过程”的形式编写
预期结果
每一步操作都有对应的预期结果
预期结果一定是客观的、可判定的
预期结果一定是符合需求的
预期结果一定是确定的
测试用例评审
评审前
让评审对象提前熟悉测试用例
反串讲需求
阐明最终测试范围
评审中
测试
测试用例讲解
再一次对需求做深入理解
开发
站在开发编码角度，检查测试用例是否有遗漏
站在代码实现的角度，提供模块内部关联逻辑建议
产品经理（BU）
检查测试用例场景是否符合业务需求
站在客户角度给测试用例提供建议
评审后
发送和归档评审纪要
根据评审建议更新测试用例
0 条评论
下一页
![[Model] 测试用例模板](https://www.processon.com/chart_image/template/thumb/6138769b76213116a088930f.png?tid=60d93bd30e3e742d29d4c069)
