1、测试用例设计

1.1、确定测试范围

1.2、用例设计原则

1.3、用例设计维度

2、测试用例编写

2.1、测试用例编写前提

2.2、用例标题

2.3、用例级别分布

2.4、预置条件

2.5、操作步骤

2.6、预期结果

3、测试用例评审

3.1、评审前

3.2、评审中

3.3、评审后

1、测试用例设计

1.1、确定测试范围

1、必须有完整的需求文档

2、需求已经组织评审和澄清

3、必须有完整的功能列表

1.2、用例设计原则

1、遵循“边界值”全覆盖原则

2、遵循”等价类划分场景“全覆盖原则

3、遵循”测试用例路径唯一“原则

当出现多个路径时，需要新建用例去覆盖。一条用例仅覆盖一个测试点。降低漏测风险。

4、遵循“单条用例覆盖最小化”原则

假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，下面两种方法来设计测试用例：

方法1：用一个测试用例覆盖三个子功能 - TestA1A2A3

方法2：用三个单独的用例分别来覆盖三个子功能 - TestA1，TestA2，TestA3

方法2则遵循了“单条用例覆盖最小化”原则，好处，当用例执行失败时，降低复现/定位复杂度

5、遵循“测试用例与测试用例之间最低耦合度”原则

（1）严谨使用上一条测试用例的结果，做为下一条测试用例的输入。

（2）每一条测试用例，应该都是完整独立的。

这样做的好处便于测试用例拉取、复用、可维护、减少后续投入成本。

1.3、用例设计维度

1、功能

（1）正向（正常）场景

（2）逆向（异常）场景

2、非功能

（1）性能

性能测试，首先需要有具体的、明确的性能指标需求。

性能关注指标：CPU、Memory、IO、网络传输速率等。

a.单品（模块）性能，比如SDK、算法、单独性能要求

b.整体性能，系统集成后的性能要求

c.网络传输性能

（2）可靠（稳定）性

a.时间维度

b.负载稳定性

（3）健壮性

a.看门狗

b.异常掉电

c.反复重启

（4）易用性

a.安装易用性

b.运维易用性

c.功能操作易用性

（5）客户体验

比如视频播放效果、操作是否顺手、开机时间等等。

（6）安全性

a.数据存储安全

b.网络传输安全

2、测试用例编写

2.1、测试用例编写前提

1、测试范围已经确定

2、测试点已经梳理完成

3、用例转换路径：业务需求-功能需求-测试需求-测试点-测试用例

2.2、用例标题

概述测试用例的主要内容，明确用例测试意图

1、语言简洁，阐明本条用例是干什么

2、一句完整的话

3、遵循“条件/动作"规则

2.3、用例级别分布

1、Lve 1：基本（～10%）

系统基本功能用例，可用于版本提交时的冒烟测试，可作为版本是否转测试通过和业务验收的依据。

划分依据：该用例执行的失败会导致多处重要功能无法运行的。

例如：开关机、升级等。

2、Lve 2：重要（～20%）

系统中的重要功能用例。

划分依据：主要包括一些功能交互相关、各种应用场景、客户使用频率较高的正常功能测试用例。

例如：设备上报、录像回放效果、预览等功能。

3、Lve 3：一般（～60%）

系统的一般功能。

划分依据：一般功能用例，包括异常路径的测试用例；使用频率低于2级用例。

例如：表单输入边界值、特殊字符的校验等。

4、Lve 4：生僻（～10%）

该级别用例一般比较少。主要是一些使用频率非常少的功能等。如果用例执行不通过，不会对系统和业务造成太大的伤害的测试用例。

划分依据：该用例对应较生僻的预置条件和数据设置。

例如：日志记录错误等。

2.4、预置条件

1、执行测试用例关键必备条件

2、让用例的执行者更加明确系统当前状态

3、预置条件不能阻塞测试用例的执行

2.5、操作步骤

1、需要明确“测试关键输入”数据

2、操作路径唯一，不唯一则多条用例覆盖（降低耦合）

3、以“面向过程”的形式编写

（1）过程描述准确、无歧义。

（2）上下文必须衔接一致。

好处：降低执行成本、降低后续维护成本

2.6、预期结果

1、每一步操作都有对应的预期结果

2、预期结果一定是客观的、可判定的

（1）即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

（2）期望结果禁止使用正确，正常，错误之类的含糊主观的字眼。

3、预期结果一定是符合需求的

4、预期结果一定是确定的

即对同样的测试用例，系统的执行结果应当是相同的、确定的。

3、测试用例评审

3.1、评审前

1、让评审对象提前熟悉测试用例

2、反串讲需求

3、阐明最终测试范围

3.2、评审中

1、测试

（1）测试用例讲解。

（2）再一次对需求做深入理解。

2、开发

（1）站在开发编码角度，检查测试用例是否有遗漏。

（2）站在代码实现的角度，提供模块内部关联逻辑建议。

3、产品经理

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

（2）站在客户角度给测试用例提供建议。

3.3、评审后

1、发送和归档评审纪要

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

精彩推荐

面试笔试系列

思维导图系列

Linux常用命令壁纸

接口Requests系列

测试框架pytest系列

Jmeter快速上手之接口测试

自动化测试框架结构图

移动安全框架（MobSF）

如何做好测试用例设计相关推荐

如何做好测试用例的设计
明确参考输入第一,做好测试用例设计,需要首先明确它有哪些参考输入.以我为例,我是做系统测试的,因此测试对象的需求规格说明是最主要的测试设计参考.但是实际面临的问题是需求常常不完善,因此纯粹依赖于需求 ...
移动APP测试用例设计实践经验分享
我请大家先思考如下2个问题: 第一,我们为什么要做好测试用例设计? 第二,好的测试用例设计有什么共性? 深入思考这两个问题的答案是一件很有意义的事情,作为移动互联网时代的产品质量守卫军,我们必须提升自 ...
移动APP测试用例设计实践经验（转载）
前言杂谈在聊移动APP测试用例设计之前,我请大家先思考如下2个问题: 第一,我们为什么要做好测试用例设计?--why? 第二,好的测试用例设计有什么共性? --what? 深入思考这2个问题的答案是 ...
移动APP测试用例设计实践经验
前言杂谈在聊移动APP测试用例设计之前,我请大家先思考如下2个问题: 第一,我们为什么要做好测试用例设计?--why? 第二,好的测试用例设计有什么共性? --what? 深入思考这2个问题的答案是 ...
蓝牙耳机测试用例_移动端测试用例设计总结，这些你得懂！
一.前言作为移动互联网产品最后一公里的守护者,我们必须要清楚的知道自己该做什么.怎么做.但从版本迭代速度.需求量级.测试人员不断变动等方面综合来看,我们很多人都没有做好充分的准备.测试方法落后.测试 ...
移动端测试用例设计总结-笔记
此文来源于公开课笔记!!! 一.前言作为移动互联网产品『最后一公里的守护者』,我们必须要清楚的知道自己该做什么.怎么做.但从版本迭代速度.需求量级.测试人员不断变动等方面综合来看,我们很多人都没有做 ...
后端Coder如何做好代码设计?
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取来源:r6d.cn/C5Ja 说明:生鲜电商属于一个软件的产品,那么如何做 ...
移动端软件测试要点,移动端测试用例设计总结
一.前言作为移动互联网产品『最后一公里的守护者』,我们必须要清楚的知道自己该做什么.怎么做.但从版本迭代速度.需求量级.测试人员不断变动等方面综合来看,我们很多人都没有做好充分的准备.测试方法落后. ...
软件测试接口测试用例设计
接口测试用例设计随着测试分析和分层测试的深化,"接口测试"出现在我们视野的频次越来越高.那么接口测的用例设计常用哪些方法呢?本文将详细描述. 接口测试 1.1 接口测试接口: ...
测试基础：测试用例设计方法
测试用例用例属性: 功能测试.性能测试.兼容测试.安全性测试编写测试用例包括的内容: (禅道.excel) 编号.标题.前置条件.操作步骤.预期结果.优先级.一级二级分类.测试人员.测试结果.备注 ...

如何做好测试用例设计

1、测试用例设计

1.1、确定测试范围

1.2、用例设计原则

1.3、用例设计维度

2、测试用例编写

2.1、测试用例编写前提

2.2、用例标题

2.3、用例级别分布

2.4、预置条件

2.5、操作步骤

2.6、预期结果

3、测试用例评审

3.1、评审前

3.2、评审中

3.3、评审后

如何做好测试用例设计相关推荐

最新文章

热门文章