测试用例的编写：让测试用例的编写条理起来

测试用例的概念

主观理解

当我们进行买回来一台电视，我们通常会进行简单的测试，看看电视是否存在问题

观察是否可以进行开机

切换电视频道是否正常

电视屏幕的分辨率是否清晰

电视外观是否存在磕碰

.............

上述这一条一条的表述其实就是测试用例。

软件涉及的特性是非常非常多的，仅仅通过一次头脑风暴是无法进行完成一次完整的测试的，需要通过编写测试用例进行罗列并发散思维。

测试用例的定义

测试用例就是为了实施测试而向被测试方提供的一组集合，这组集合包括测试环境、操作步骤、测试数据和预期结果等要素。

通过概念就对应着编写测试用例的原则1：

测试用例中的一个必须的部分是对测试的预期结果或者输出进行定义，如下面表格所示

使用excel表格进行编写测试用例 

使用思维导图的方式进行编写测试用例 

注：

在进行编写测试用例的时候通常由两种形式，分别是通过excel进行管理和思维导图管理用例（分别对应着笔试和面试）。

测试用例设计的万能思路

常规思考+逆向思维+发散性思维

在进行设计测试用例时的原则二

我们在进行设计测试用例时不能仅仅考虑 是否未做应该做的 ，更要进行考虑 是否做了不应该做的。

以上是常规思考+逆向思维

发散性思维往往是最难想的，通过下面这个万能公式能够起到引导作用。

功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试

对于这个万能公式的理解

举个栗子 

通过对水杯进行测试的例子进一步进行理解

 除了万能公式以外，弱网测试和安装卸载才是也是常用的类型

弱网测试

弱网测试主要是为了进行增加用户体验，关注的关键点主要包括：

页面响应的时间是否可以接收，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间、首屏时间等等。

页面呈现是否完全一致。

超时文案是否定义、异常信息是否正确。

是否有超时重连。

安全角度：是否发生dns挟持、登录IP频繁切换等。

大流量事件风险：是否在弱网条件下更新apk包、下载文件等大流量动作。

我们长使用 fiddler、或者 charles 进行弱网测试。

使用fiddler 进行弱网测试的步骤如下

安装卸载测试

针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载

安装：未下载的用户是否可以进行安装，进行安装的用户是否可以进行重复安装、卸载后还是否可以进行安装。

卸载：安装后是否可以进行卸载、卸载过程中中断是否可以继续进行卸载、卸载后再次安装是否可以进行卸载。

设计测试用例的方法

基于需求的设计方法 

基于需求的设计方法也是总的设计测试用例的方法，在工作中，我们需要参考需求⽂档/产品规格说明 书来设计测试用例。

测试⼈员接到需求之后，要对需求进行分析和验证，从合理的需求中进⼀步分析细化需求，从细化的 需求中找出测试点，根据这些测试点再去设计测试用例。

以该注册邮箱账号需求为例，我们来设计测试用例。

1、首先进行明确需求的功能点

账号注册，账号登录

2、然后进行结合万能公式进行测试

上面叫做根据需求文档进行设计初步的测试用例，但是部分用例还需要进行细化，进行细化的时候的情况都是非常多的，但是我们无法将每种情况进行一一列举出来，这时候就需要通过下面的具体方法进行尽可能的覆盖到所有的情况。 

具体的设计方法

等价类

当我们进行对注册的姓名进行测试观察是否进行符合要求时，进行注册时对姓名的要求：姓名必填，6~15位的字符类型

我们在进行设计测试用例的时候，如果采用穷举法来进行测试，非常耗时耗力，如何对穷举法进行优化测试？

等价类的思想

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出⼀个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。 

等价类的分类

设计测试用例时我们不仅仅要进行考虑测试用例是否做了应该做的，也要进行考虑做了其不应该做的，因此等价类又进行分成有效等价类和无效等价类。

• 有效等价类：对于程序的规格说明书是否合理、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明书中所规定的功能和性能。
• 无效等价类：根据需求说明书，不满足需求的集合。

利用等价类进行设计测试用例的一般步骤

1. 确定有效等价类和无效等价类：有效等价类6~15位（例如选取6位进行测试），无效等价类（小于六位或者大于15位分别进行选取一个）。
2. 编写测试用例，设计具体的测试数据

这种方式能够极大的进行用较少的情况去覆盖几大部分测试用例，但是缺点也很明显：等价类只考虑输⼊域的分类，没有考虑输⼊域的组合，需要其他的设计⽅法和补充。

边界值法

边界值分析法就是对输入或输出的边界值进行测试的⼀种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界值 = 边界值 + 次边界值

关于次边界值的选择问题

• 如果边界值是有效的，次边界值就要进行选择无效的
• 如果边界值是无效的，次边界值就要进行选择有效的

场景法

现在的软件几乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的触发顺序和处理结果就形成事件流。

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的⼀种方法。用例场景来测试需求是指模拟特定场景边界发⽣的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。

场景法⼀般包含基本流和备用流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

基本流程（蓝色虚线）

1. 用户逛街 → 进入服装店 → 选择衣服 → 购买衣服

   • 场景描述：
     这是一个标准的操作路径，用户从逛街开始，进入服装店，选购并购买衣服。这个场景是最理想的路径，没有出现任何问题。

   • 测试点：

     • 确保服装店内商品信息准确，并且能够成功完成购买流程。

     • 测试用户可以顺利完成购买而没有任何障碍。

备选流程

1. 可能出现情况：无法按计划逛街 → 重新规划逛街时间

   • 场景描述：
     这条路径说明，用户可能在逛街过程中因为其他因素（如突发情况）无法按原计划继续前行，于是需要重新规划逛街的时间。

   • 测试点：

     • 确保系统能够提供时间调整选项，并能顺利安排新时间。

2. 选择了衣服但没有合适 → 继续寻找合适衣服

   • 场景描述：
     如果用户选择的衣服不合适（可能是尺寸或款式问题），系统需要提供一个替代方案，继续让用户寻找满足需求的衣服。

   • 测试点：

     • 确保系统能够推荐其他衣服，并且展示符合用户需求的选项。

3. 遇到价格不合适或不满意 → 重新寻找符合要求的衣服

   • 场景描述：
     用户可能对所选衣服的价格或款式不满意，选择继续寻找其他价格更合适的衣服。

   • 测试点：

     • 测试价格过滤和搜索功能是否足够灵活，能够帮助用户找到心仪的商品。

异常流程

1. 用户进入服装店后，发现店内商品不符合需求 → 找到其他服装店继续寻找

   • 场景描述：
     用户在当前服装店内没有找到合适的衣服，决定去其他服装店继续寻找。这条路径模拟了用户遇到购物障碍时的应对方式。

   • 测试点：

     • 测试用户能够顺利跳转到其他服装店页面，继续购物。

2. 价格过高或衣服不合适，用户放弃购买

   • 场景描述：
     如果衣服的价格不合适，或者用户对其他方面不满意，可能会放弃购买。这是一个常见的购物决策，反映了用户可能放弃某一目标的情况。

   • 测试点：

     • 确保系统能够适当提示用户并鼓励他们继续寻找更符合预期的商品。

通过注册的栗子进行加强理解

根据场景法确定基本流和备用流，从而进行编写测试用例

• 基本流：点击注册入口并同意协议，输入正确信息，输入正确信息，点击注册，同意注册。
• 备用流：点击注册入口不同意协议，重新点击注册入口并同意协议，输入正确信息，点击注册，同意注册。
• 备用流：点击注册入口不同意协议，重新点击注册入口并同意协议，输入错误信息，重新进行输入正确信息，点击注册，同意注册。

正交表法

通过等价类和边界值⽅法我们完成了部分⽤例的补充 当前还剩下⼀个场景的用例未补充完成，“只填写部分选项”，这⾥到底要设计多少测试⽤例呢？ 通常来说，为了保证系统的测试覆盖率，我们⾸先能够想到的就是排列组合。 假如当前有两个选项A和B，可以设计出都填写、都不填写、填写A、填写B四个测试⽤例（2²）。假如当前有三个选项A、B、C，通过设计可以得到8个测试⽤例（2³）当前可选的选项是5个，分别是，姓名、电⼦邮箱、密码、确认密码、验证码。按照排列组合设计出 来的⽤例是32个.....

✅ 正交法的⽬的是为了减少⽤例数⽬（用数学中概率最大的几种情况）。⽤尽量少的⽤例覆盖输⼊的两两组合。

上述正交表可以进行表示成  ：如下图所示

正交表的性质：

• 每一列中，不同的数字出现的次数是相等的。
• 任意两列中的数字的排列方式齐全而均衡。、

正交表的两个性质体现了  核心思想：均衡覆盖 + 两两独立

正交表的设计

由于正交表的两个性质，想要进行手动的设计出正交表是十分困难的，所以说我们通常是借助 allparis 工具进行正交表的设计。

正交表设计的一般步骤

1、根据需求找出因素和水平

2、将因素和水平填写到 excel 表中 （不需要进行保存）

3、在allparis.exe 同级文件夹下进行创建一个txt文件，将 excel 表格中的内容进行复制到txt文件中，使用allparis.exe工具对 txt 文件进行生成正交表文件。

注：若不使用excel而是直接在txt中进行手动编写因素和水平，使用命令进行生成正交表时会出现校验错误的情况，allparis 工具对格式的要求非常的严格。

4、根据生成好的正交表文件来进行编写测试用例，继续将重要的测试用例进行补全 

判定表法

通过具体的⽅法能够将测试⽤例设计的更加完整和规范。

需求中会存在各种各样的场景，现在我们把需求改成如下的要求：

用户输⼊的账号中包含admin字符，或者通过内部链接进⼊注册页面，提交注册按钮成为管理员⾝ 份；反之⽆管理员⾝份。

通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法⽆法解决这样的问题。⽽ 正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。

但是通过判定表就比较容易进行设计测试用例。

判定表是⼀种表达逻辑判断的⼯具，形如：

使用判定表法的一般步骤： 

1、确认输入条件和输出条件

• 输入：账户中是否存在admin 字符，是否通过内部链接进入的注册页面，提交注册按钮。
• 输出：管理员/非管理员

2、找出输入条件和输出条件之间的关系

3、画判定表

4、根据判定表进行编写测试用例

• a. 账号包含admin，⾮内部注册链接，点击注册按钮，为管理员⾝份
• b. 账号包含admin，内部注册链接，不点击注册按钮，⾮管理员⾝份
• c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员⾝份
• d. 账号包含admin，内部注册链接，点击注册按钮，为管理员⾝份
• e. 账号包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
• f. 账号不包含admin，⾮内部注册链接，点击注册按钮，⾮管理员⾝份
• g. 账号不包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份

错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从⽽ 针对性地设计测试⽤例的⽅法。 这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。 

错误推测法和⽬前流⾏的“探索式测试⽅法”的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产 出⽐很⾼，被⼴泛应⽤于测试。