目录
- 一.什么是测试用例?
- 二.总体设计测试用例的万能公式.
-
- [2.1 功能+性能+界面+兼容+易用+安全](#2.1 功能+性能+界面+兼容+易用+安全)
- [2.2 弱网测试](#2.2 弱网测试)
- [2.3 安装卸载测试.](#2.3 安装卸载测试.)
- [三. 常用设计具体测试用例的方法](#三. 常用设计具体测试用例的方法)
-
- [3.1 等价类](#3.1 等价类)
- [3.2 边界值](#3.2 边界值)
- [3.3 正交法](#3.3 正交法)
-
- [3.3.1 正交表](#3.3.1 正交表)
- [3.3.2 如何设计正交表,并根据正交表编写测试用例](#3.3.2 如何设计正交表,并根据正交表编写测试用例)
- [3.4 判定表法](#3.4 判定表法)
-
- [3.4.1 根据判定表法编写测试用例的步骤](#3.4.1 根据判定表法编写测试用例的步骤)
- [3.5 场景法](#3.5 场景法)
- [3.6 错误猜测法](#3.6 错误猜测法)
- 四.总结.
一.什么是测试用例?
- 测试用例（Test Case）是软件测试中的基本概念，它是指为了测试某个程序、系统或软件功能而设计的一组测试输入、执行条件以及预期结果的集合 。这组集合包括: 测试环境 , 操作步骤 , 测试数据 ,预期结果等内容. 测试用例的主要目的是确定应用程序是否按照需求规格说明书正常工作，同时帮助识别程序中的缺陷（bugs）、错误或遗漏。
- 举个例子:
- 为什么需要测试用例, 如果没有测试用例,可能会面临很多的问题:
- 不知道是否较全面的测试了所有的功能,
- 测试的覆盖率无发衡量
- 对新版本的重复测试将很难实施.
- 存在大量的冗余测试影响测试效率.
二.总体设计测试用例的万能公式.
- 当你面对一款产品的时候,该从哪里入手来设计测试用例, 比如现在给你一个水杯, 你该如何设计测试用例. 下面我将告诉你解决这个问题通用的方法.
2.1 功能+性能+界面+兼容+易用+安全
-
设计测试用例的万能公式: 功能测试 + 界面测试 + 性能测试 +兼容性测试 + 易用性测试 + 安全测试 .
-
功能测试 （Functional Testing）: 是软件测试中的一种基本类型，它主要关注于验证软件应用程序的功能是否按照需求规格说明书（Requirements Specification）中的描述正确执行。
-
界面测试（简称UI测试）: 是确保软件用户界面（UI）符合设计需求、用户习惯及功能要求的重要环节。它涵盖了多个方面，旨在提升用户体验和软件的可用性。
-
性能测试: 是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。其目的是发现软件在高负载条件下的瓶颈和问题，为优化和改进提供依据。
-
兼容性测试 : 检查软件之间能否正确地进行交互和共享信息，以及软件与硬件、操作系统等环境之间的兼容性。它涉及在不同的硬件平台、操作系统、网络环境中，测试软件是否能正确运行，并确保软件在各种条件下都能保持稳定的性能。
-
易用性测试 : 通过模拟用户使用软件的过程，评估软件在易用性方面的表现。它关注软件是否易于理解、学习、使用和吸引用户 ，以及软件在使用过程中是否给用户带来舒适和高效的体验。
-
安全测试 : 安全测试是在软件产品的生命周期中，特别是在产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。其目的在于提升软件产品的安全质量，尽量在发布前找到并修补安全问题，从而降低成本并增强系统的防护能力。
-
此时我们再根据万能公式来设计水杯的测试用例:
2.2 弱网测试
- 除了上述常见的设计测试用例的总体方向, 我们在日常的测试过程中,还有一个比较常见的测试类型就是弱网测试.
- ** 弱网测试**: 弱网测试是在网络环境不佳的情况下，对应用软件或系统进行的测试 ，目的是验证软件在这种不稳定网络环境中的性能、稳定性和可靠性。
- 弱网测试关注的关键点可能包括:
- 在弱网的情况下, 页面响应的时间是否可以接受, 关注包括热/冷启动时间 , 页面切换, 首字时间, 首屏时间等
- 弱网情况下与正常情况下呈现的页面是否完全相同.
- 在网络超时的时候, 是否定义超时时要展示的HTML界面,.
- 是否具有超时重连.
- 是否存在安全隐患, 比如发生dns劫持, 登录ip更换频繁, 单点登录异常.
- 大流量事件风险, 比如是否会在弱网下进行更新apk包, 下载文件等大流量动作.
- 软网测试工具Fiddler Classic
- 使用步骤:
-
打开弱网设置选项
-
打开设置弱网的脚本
-
2.3 安装卸载测试.
- 除了上述的测试类型, 还有一个是我们必须要关注到的测试类型---->安装卸载测试, 它主要包含在软件安装卸载的过程中出现的一些突发情况.
三. 常用设计具体测试用例的方法
- 现有注册用户邮箱账号的需求
3.1 等价类
-
针对上述的需求-->姓名必填且必须是6~15位的字符类型. 该如何设计测试用例?
-
测试的时候通过穷举法来测试6位、7位、8位...14位，15位是否测试通过，这样的方法能够满足测试的要求吗？若此时把范围从6 ~ 15位 改成6 ~ 150位呢"？试想一下这样一个简单的测试点需要测试多久呢，显然是不符合企业测试要求的。而等价类法的出现就解决了穷举法不能解决的问题
-
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
-
等价类分类：
- 有效等价类 : 对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能.
- 无效等价类 : 根据需求说明书，不满足需求的集合。
-
依据等价类的方法来设计测试用例的步骤:
- 确定有效等价类和无效等价类
- 编写测试用例, 设计具体测试数据
-
根据等价类思想设计测试用例的例子:
3.2 边界值
- 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法 。通常边界值分析法是作为对
等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 - 边界值法来设计测试用例包含两种情况: 边界值和次边界值.
- 根据边界值思想设计测试用例的例子:
3.3 正交法
通过等价类和边界值方法我们完成了部分用例的补充.
当前还剩下一个场景的用例未补充完成，"只填写部分选项"，这里到底要设计多少测试⽤例呢？
通常来说，为了保证系统的测试覆盖率，我们首先能够想到的就是排列组合。
假如当前有两个选项A和B，可以设计出都填写、都不填写、填写A、填写B四个测试⽤例（2²）。
假如当前有三个选项A、B、C，通过设计可以得到8个测试⽤例（2³）
...
当前可选的选项是5个，分别是，姓名、电⼦邮箱、密码、确认密码、验证码。按照排列组合设计出
来的用例是32个...
- 正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的⼀种设计方法，它是根据正交
性，由试验因素的全部水平组合中挑选出部分有代表性的点进⾏试验，通过对这部分试验结果的分析
了解全面试验的情况，找出最优的水平组合 。正交试验设计是⼀种基于正交表的、⾼效率、快速、经
济的试验。
3.3.1 正交表
- 正交表是一种特制的表格，用于多因素实验设计研究 。它通过均衡分散和整齐可比的特性，在尽可能少的试验次数下确定各个因素对结果的影响。正交表通常表示为L_{行数}~(水平数~^{因素数})，其中L表示正交表，行数表示需要进行的实验次数，因素数代表实验中变量的个数，水平数代表每个因素的不同取值。
- 因素 （Factors）：在正交实验中，因素是指那些可能影响实验结果的变量或条件。这些因素通常是实验中需要考察的主要参数，比如在邮箱注册的需求当中, 姓名,电子邮箱等信息是必填的, 也可以有相关的信息, 例如家庭住址等非必填的信息, 这些信息的填写可能会影响注册结果, 故这些信息就是因素.
- 水平 （Levels）：水平则是指==每个因素在实验中所取的不同数值或状态。==如何在邮箱注册当中姓名可以是必填的, 也可以是非必填的, 此处的必填和非必填就是该正交表的水平.
- 正交表的性质:
- 每一列中, 不同数字出现的次数相等.
- 任意两列中数字的排列方式齐全且均衡.
3.3.2 如何设计正交表,并根据正交表编写测试用例
- 根据需求找出因素和水平.
- 用allparis工具生成正交表
-
将因素和水平写入到Excel表格当中.
- -
在allpairs.exe同级文件夹下创建一个test01.txt文件, 将Excel表格中的内容复制到test01.txt文件之中,并且不要有其他的任何操作(保证格式的正确性). 使用allparis命令生成正交表：
allparis.exe test01.txt>zhengjiao.txt.
-
- 根据正交表编写测试用例.
- 全部填写(姓名,电子邮箱,密码,确认密码,验证码)
- 填写姓名, 不填写电子邮箱,密码,确认密码,验证码
- 填写电子邮箱,确认密码, 不填写姓名,密码,验证码.
- 填写密码,验证码, 不填写姓名,电子邮箱,确认密码
- 填写姓名, 电子邮箱,密码,不填写确认密码, 验证码
- 填写姓名, 确认密码,验证码, 不填写电子邮箱,密码.
-
- 补充遗漏的重要测试用例.
- 全部填写(姓名,电子邮箱,密码,确认密码,验证码)
- 填写姓名, 不填写电子邮箱,密码,确认密码,验证码
- 填写电子邮箱,确认密码, 不填写姓名,密码,验证码.
- 填写密码,验证码, 不填写姓名,电子邮箱,确认密码
- 填写姓名, 电子邮箱,密码,不填写确认密码, 验证码
- 填写姓名, 确认密码,验证码, 不填写电子邮箱,密码.
- 全部不填写(姓名电子邮箱,密码,确认密码, 验证码)
-
3.4 判定表法
现有如下需求:
用户输入的字符当中包含admin字符, 或者通过内部链接进入注册界面的, 提交注册按钮, 则其身份为管理员; 反之则为普通用户.
- 通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法无法解决这样的问题。而正交法能够解决需要考虑输入之间的组合关系对应不同结果的场景。
3.4.1 根据判定表法编写测试用例的步骤
- 确认需求当中的输入条件和输出条件
- 输入条件: 账户中包含admin字符, 内部链接进入注册页面, 提交注册按钮
- 输出条件: 管理员/普通用户
- 找出输入条件和输出条件之间的关系.
- 输入条件: 账户中包含admin字符, 内部链接进入注册页面, 提交注册按钮,分别设为时间a,b,c
- 输出条件: 1/0
| 输入条件的组合 | 对应的输出结果 |
|---|---|
| a c | 1 |
| b c | 1 |
| a b | 0 |
| a b c | 1 |
| 非a b c | 0 |
| a | o |
| b | o |
| c | 0 |
- 制作判定表
- 根据判定表编写测试用例
a. 账号包含admin，非内部注册链接，点击注册按钮，为管理员身份
b. 账号包含admin，内部注册链接，不点击注册按钮，非管理员身份
c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员身份
d. 账号包含admin，内部注册链接，点击注册按钮，为管理员身份
e. 账号包含admin，非内部注册链接，不点击注册按钮，非管理员身份
f. 账号不包含admin，非内部注册链接，点击注册按钮，非管理员身份
g. 账号不包含admin，非内部注册链接，不点击注册按钮，非管理员身份
3.5 场景法
场景法是一种通过模拟用户操作软件时的各种情景来设计测试用例的方法。这种方法不仅能够全面覆盖软件的功能点和业务流程，还能有效发现潜在问题，提高用户体验和软件稳定性。
以下是场景法设计测试用例的具体步骤和要点：
-
确定基本流和备选流 ：基本流是指用户正确的业务操作流程，而备选流则是用户在操作过程中可能遇到的错误或异常情况[^2^]。例如，在一个在线购物系统中，基本流可以是用户成功登录、选择商品、支付并生成订单的完整流程，备选流则包括账号不存在、密码错误、无选购书籍等情况[^1^]。
-
生成不同的场景 ：根据基本流和备选流，生成不同的测试场景。每个场景代表一个具体的用户使用情况，可以是一个成功的操作流程，也可以是一个包含错误的操作流程[^3^]。例如，在在线购物系统中，可以生成"购物成功"、"账号不存在"、"账号错误"、"密码错误"等不同场景[^1^]。
-
设计相应的测试用例 ：针对每个生成的场景，设计相应的测试用例。测试用例应包含测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果[^1^]。例如，在在线购物系统的例子中，可以为每个场景编写详细的测试用例，如"购物成功"的测试用例可以包括有效的账号信息、正确的密码、已选购的书籍等[^1^]。
-
复审和确定测试用例 ：对生成的所有测试用例进行复审，去掉多余的测试用例，确保每个测试用例都有明确的目标和预期结果[^1^]。然后，为每个测试用例确定实际的数据值，以便在测试实施时使用[^2^]。
-
考虑业务层面和技术层面 ：场景法要求测试人员从业务层面和技术层面两个角度去理解被测软件。业务层面需要熟悉所测软件的业务逻辑，技术层面则需要了解如何模拟用户正确的业务操作流程和错误的操作流程[^4^]。
-
适用场合 ：场景法适用于解决业务流程清晰和业务比较复杂的系统或功能。它能够帮助测试人员建立整体业务感觉，避免陷入功能细节忽视业务流程要点的错误倾向[^2^]。
- 举个例子:女生去买衣服
- 基本事件流 :
- 逛街---->服装店---->选衣服---->买衣服
- 备选事件流 :
- 逛街---->处理突发情况---->逛街---->服装店---->选衣服---->买衣服
- 逛街---->服装店---->和朋友吃饭---->选衣服---->买衣服
- ...
3.6 错误猜测法
错误猜测法是一种基于经验和直觉推测系统中可能存在的各种错误，从而有针对性地设计测试用例的方法。
以下是对这种方法的具体介绍：
- 基本概念
- 定义：错误猜测法是基于测试人员对以往项目测试中曾经发现的缺陷、故障或失效数据，在导致软件错误原因分析的基础上设计测试用例，用于预测错误、缺陷和失效发生的技术。
- 基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例。
- 优缺点
- 优点：充分发挥人的直觉和经验，快速切入高风险区域，提高测试效率。
- 缺点：难以准确评估测试用例的覆盖率，可能丢失大量未知的区域，带有主观性且难以复制。
- 错误猜测法更多的是需要测试人员具有测试的经验, 遇到某个业务场景能够凭借错误猜测的经验来设计测试用例
四.总结.
-
知道什么是测试用例.
-
从整体出发设计测试用例,用到设计测试用例的万能公式: 功能测试+性能测试+界面测试+兼容性测试+易用性测试+安全测试
-
掌握常见其他常见测试类型: 弱网测试(在网络信号不好的时候,会不会出现bug) 安装卸载测试(在安装卸载的过程中是否会出现问题)
-
总体上设计测试用例的思路已经有了, 下面就是设计具体的测试用例, 掌握设计测试用例常用的方法:等价类, 边界值,正交表,判定表,场景法, 错误猜测法
-
区分正交表发和判定表发的使用场景, 正交表法侧重于通过最小化测试次数来覆盖尽可能多的因素组合，适用于控件多、组合复杂的情况；而判定表法则侧重于明确列出所有可能的条件组合及其对应的操作结果，适用于条件判断复杂、结果多样的情况。
-
上述介绍的设计具体测试用例的方法并不是要求我们在设计测试用例的时候都用上, 而是掌握设计测试用例的思想, 锻炼自己的思维能力.