登录免费注册



如何做好测试用例设计？

首页  思维导图  详情



如何做好测试用例设计？

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）

检查测试用例场景是否符合业务需求

站在客户角度给测试用例提供建议

评审后

发送和归档评审纪要

根据评审建议更新测试用例

 Collect

Get Started

测试用例模版

 Collect

Get Started

如何写出漂亮的测试用例

 Collect

Get Started

直播测试用例

 Collect

Get Started

接口测试用例设计













评论

0 条评论

下一页



图形选择

思维导图

主题

补充说明

AI生成





修改AI描述

去编辑

重新生成

提示 

关闭后当前内容将不会保存，是否继续？

取消

确定

Document