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