测试用例的概念
概念:测试用例是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境,操作步骤,测试数据,预期结果
核心要素:
1、用例编号:唯一标识,便于管理
2、用例标题:简明描述测试目的
3、所属模块:功能模块归属
4、前置条件:执行前必须满足的条件
5、测试步骤:详细的操作步骤
6、测试数据:具体的输入值
7、预期结果:明确的正确输出
8、优先级:执行重要程度
测试中遇到问题:
• 不知道是否较全⾯的测试了所有功能
• 测试的覆盖率⽆法衡量
• 对新版本的重复测试很难实施(即回归测试⽆法仅通过⼈⼯测试的⽅式进⾏历史功能的回归)
• 存在⼤量冗余测试影响测试效率
测试用例的万能思路
常规思考+逆向思维+发散性思维
1.测试⽤例的编写不仅应当根据有效和预料到的输⼊情况,⽽且也应该根据⽆效和未预料到的输⼊情 况。
2.检查程序是否"未做其应该做的"仅是成功的⼀半,测试的另⼀半是检查程序是否"做了其不应该 做的"。(是上⼀条原则的必然结果)
3.计划测试⼯作时不应默许假定不会发现错误。
测试用例的设计并不是越多越好,而是能够达到更大的功能覆盖率则更好
万能公式
功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试
功能测试:从产品功能的角度出发,验证功能是否正确
界面测试:肉眼可以看到的部分都成为界面,界面的所有元素都需要测试
性能测试:性能测试和功能测试的区别是:功能测试检查软件是否做了,⽽性能测试测试软件做的好不好。
兼容性测试:不同版本(软件、系统),浏览器的兼容性,不同浏览器
易用性测试:具备简单易上手的属性
安全测试:是否具备危险材质,气味,接口响应数据也要考虑到用户的数据安全,数据存储用户隐私数据是否加密,SQL注入
弱网测试
弱网测试的目的是尽可能保证用户体验
• ⻚⾯响应时间是否可以接受,关注包括热启动、冷启动时间、⻚⾯切换、前后台切换、⾸字时间, ⾸屏时间等。
• ⻚⾯呈现是否完成⼀致。
• 超时⽂案是否符合定义,异常信息是否显⽰正常。
• 是否有超时重连。
• 安全⻆度:是否会发⽣dns劫持、登陆ip更换频繁、单点登陆异常等。
• ⼤流量事件⻛险:是否会在弱⽹下进⾏更新apk包、下载⽂件等⼤流量动作。
安装卸载测试
安装:安装包是否可以安装,卸载后是否可以继续安装,重复安装,软件更新后是否可以安装成功
卸载;卸载一次后继续安装继续卸载,卸载一般停止后是否可以继续卸载
测试用例的方法
基于需求的设计方法
基于需求的设计⽅法也是总的设计测试⽤例的⽅法,在⼯作中,我们需要参考需求⽂档/产品规格说明 书来设计测试⽤例。
测试⼈员接到需求之后,要对需求进⾏分析和验证,从合理的需求中进⼀步分析细化需求,从细化的 需求中找出测试点,根据这些测试点再去设计测试⽤例。
具体设计方法
等价类
等价类划分(Equivalence Class Partitioning)是一种经典的黑盒测试设计方法 ,通过将输入数据划分为若干等价类,从每个类中选取代表性数据作为测试用例,从而用较少的测试数据达到较大的覆盖效果。
核心思想
同一等价类中的数据,对于揭露程序错误的作用是等价的。
-
如果等价类中一个数据能发现缺陷,类内其他数据也能发现
-
如果等价类中一个数据不能发现缺陷,类内其他数据也不能发现
目标:避免冗余测试,提高测试效率。
有效等价类:符合规格说明的合理输入
无效等价类:不符合规格说明的不合理输入
示例:
用户名注册(6-20位,字母/数字/下划线)
有效等价类: 6-20位 无效等价类:<6位 >20位 空
有效等价类: 字母/数字/下划线 无效等价类:含特殊字符(如@#) 纯空格 中文
适用场景
-
✅ 输入条件明确、有范围限制的功能
-
✅ 表单验证、参数校验、配置项测试
-
✅ 需要快速生成大量测试数据的场景
-
❌ 复杂业务流程、多条件组合逻辑(需配合判定表/场景法)
等价类划分是最基础、最高效的测试设计技术,掌握它能显著提升测试覆盖率和效率。
边界值
边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对 等价类划分法的补充,这种情况下,其测试⽤例来⾃等价类的边界。
边界值包含:边界值和次边界值
-
输⼊框⻓度为1-11,取边界值为:1、11、12、0
-
运动员的参赛项⽬为1-3项,取边界值为:0项、1项、3项、4项
-
查询⾯⻚⾯有999⾏,每50⾏为⼀⻚,取边界值为:输出0⾏、1⾏、50⾏、51⾏、999⾏

场景法
场景法(Scenario Testing)是通过模拟用户实际业务操作流程来设计测试用例的方法。它关注用户如何与系统交互完成特定目标,而非孤立测试单个功能。
核心要素
基本流:最正常的业务流程,没有任何异常
备选流:因条件不同而产生的分支异常
异常流:错误处理和异常工作的流程

案例:根据邮箱账号注册的案例,根据场景法来设计测试⽤例TODO
根据场景法设计测试⽤例的步骤
1.确定基本流
2.确定备选流
3.根据备选流补充测试⽤例
4.编写测试⽤例

编写测试⽤例:
1.输⼊正确的账号密码,点击注册后系统发出确认邮件并在24H内确认,注册成功。
2.不输⼊账号密码,点击注册,提⽰重新输⼊
3.只输⼊账号,不输⼊密码,点击注册,提⽰重新输⼊
✅ 应该做的
-
从用户视角出发 - 思考"用户想完成什么目标"
-
覆盖主要业务路径 - 确保核心流程100%覆盖
-
识别关键决策点 - 分支条件、异常处理点
-
组合有意义的场景 - 避免无意义的排列组合
-
包含负面场景 - 断网、超时、数据异常等
❌ 避免的错误
-
场景过于细碎,失去业务意义
-
只测基本流,忽略备选流
-
用例之间高度重复
-
忽视业务优先级(核心流程vs边缘功能)
正交法
正交法是从全面试验中挑选出有代表性的组合 进行测试,用较少的用例覆盖最大的因素组合空间。它源于数学中的"正交表",确保每个因素的每个水平与其他因素的每个水平都至少搭配一次。
|-----|-----------|-------------------|
| 术语 | 说明 | 示例 |
| 因素 | 影响结果的变量 | 浏览器,操作系统,网络 |
| 水平 | 因素的取值 | 浏览器 |
| 正交表 | 预定的实验操作符号 | L₉(3⁴) 表示9行4因素3水平 |
符号:Lₙ(mᵏ)
n = 试验次数(行数/用例数)
m = 水平数(每个因素取值个数)
k = 因素数(列数)
常见正交表:
┌───────────┬─────────────┬─────────────────┐
│ 正交表 │ 用例数 │ 适用场景 │
├───────────┼─────────────┼─────────────────┤
│ L₄(2³) │ 4条用例 │ 3因素2水平 │
│ L₉(3⁴) │ 9条用例 │ 4因素3水平 │
│ L₈(2⁷) │ 8条用例 │ 7因素2水平 │
│ L₁₆(4⁵) │ 16条用例 │ 5因素4水平 │
│ L₁₈(3⁷) │ 18条用例 │ 7因素3水平 │
└───────────┴─────────────┴─────────────────┘
设计步骤
1:识别因素和水平
2:选择适合的正交表
3:将因素映射到正交表列
4:生成测试用例
5:补充重要组合
利用allparis生成正交表


正交表的性质:
• 每⼀列中,不同的数字出现的次数相等。
• 任意两列中数字的排列⽅式⻬全⽽且均衡
✅ 推荐使用
-
因素数 3-7个 ,水平数 2-4个
-
因素间独立 或弱关联
-
需要快速覆盖大量组合时
-
配置类测试(兼容性、硬件、环境)
⚠️ 注意事项
-
不要机械照搬 - 关键组合(如所有因素都是极端值)需手动补充
-
因素要独立 - 若因素间有强依赖,正交法可能产生无效组合
-
水平要等权重 - 避免把高频操作和罕见错误设为同一水平
-
结合等价类 - 先用等价类确定水平,再用正交法组合
判定表法
判定表法是将多个条件(输入) 的所有可能取值与对应的**动作(输出)**以表格形式系统化呈现,确保每个条件组合都被覆盖,避免遗漏或冗余。
┌─────────────────────────────────────────────────────┐
│ 判定表结构 │
├───────────┬──────────┬────────┬────────┬───────────┤
│ │ 规则1 │ 规则2 │ 规则3 │ ... │
├───────────┼──────────┼────────┼────────┼───────────┤
│ 条件桩 │ 条件项 │ 条件项 │ 条件项 │ │
│ (输入) │ Y │ N │ Y │ │
├───────────┼──────────┼────────┼────────┼───────────┤
│ 动作桩 │ 动作项 │ 动作项 │ 动作项 │ │
│ (输出) │ ✓ │ × │ ✓ │ │
└───────────┴──────────┴────────┴────────┴───────────┘
根据判定表法设计测试⽤例的步骤:
-
确认需求中输条件和输出条件
-
找出输⼊条件和输出条件之间的关系
-
画判定表
-
根据判定表编写测试⽤例
-
确认需求中输⼊条件和输出条件 输⼊条件:
账号包含admin字符(a)、内部注册链接(b)、点击注册按钮(c) 输出条件:
管理员1)、⽆管理员2)
- 找出输⼊条件和输出条件之间的关系 1 2 输⼊条件:
ac ab bc abc a b c ⾮ abc
对应结果: 1 2 1 1 2 2 2 2 3.
画判定表

- 根据判定表编写测试⽤例
a. 账号包含admin,⾮内部注册链接,点击注册按钮,为管理员⾝份
b. 账号包含admin,内部注册链接,不点击注册按钮,⾮管理员⾝份
c. 账号不包含admin,内部注册链接,点击注册按钮,为管理员⾝份
d. 账号包含admin,内部注册链接,点击注册按钮,为管理员⾝份
e. 账号包含admin,⾮内部注册链接,不点击注册按钮,⾮管理员⾝份
f. 账号不包含admin,⾮内部注册链接,点击注册按钮,⾮管理员⾝份
g. 账号不包含admin,⾮内部注册链接,不点击注册按钮,⾮管理员⾝份