编写测试用例注意事项

1、测试用例的标准：

1）能对穷举场景设计测试点

2）能对限定边界规则设计测试点

3）能对多条件依赖关系设置测试点

4）能对于项目业务涉及测试点

2、解决方法：

1）等价类划分法：

①说明：在所有测试数据中，对具有某种共同特征的数据集合，进行划分。

②分类：
Ⅰ、有效等价类：满足需求的数据集合。（使用的时候取其中一个就行）
Ⅱ、无效等价类：不满足需求的数据集合。

有效等价和单个无效等价各取一个即可。

③步骤：
Ⅰ、明确需求。
Ⅱ、确定有效和无效等价类。
Ⅲ、提取数据编写测试用例。

正向的用例数据一条尽可能覆盖多条，逆向的每一条都是单独用例。

④适应场景：
需要有大量测试数据输入，但是无法进行穷举测试数据。

常见：输入框、下拉列表、单选复选框。

⑤典型代表：
页面的输入框类测试。

案例练习：

需求：验证QQ账号的合法性。
要求：6~10位的自然数。

步骤：
Ⅰ、分析需求，拆分规则： 位数：6~10位。 类型：自然数。
Ⅱ、划分有效等价类：8位自然数合法。划分无效等价类：3位自然数、12位自然数、8位非自然数、空，均不合法。
Ⅲ、提取数据编写测试用例：12345678、123、123456789012、123AXCxc、空。

编写用例：

2）边界值分析法

①说明：使用边界值解决边界位数问题。

②边界值说明：（选取正好等于、刚好大于、刚好小于边界的值作为测试数据）
Ⅰ、上点：边界上的点。（正好等于）
Ⅱ、离点：距离边界最近的点。（刚好大于、刚好小于）
Ⅲ、内点：范围内的点。（区间范围内的数据）

🌂：在未优化的前提下，有关范围限制，最多有7条用例。
🌂：边界值能解决位数限制问题，但不能解决数据类型问题，所以会结合等价类一起使用。

③步骤：
Ⅰ、明确需求。
Ⅱ、确定有效和无效等价。
Ⅲ、确定边界范围点。
Ⅳ、提取数据，编写用例。

④使用场景：
Ⅰ、在等价类的基础上，针对有边界范围的测试数据输入的情况。（重点关注边界）
Ⅱ、常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语。
Ⅲ、典型代表：有边界范围的单个输入框类测试。

🌂案例优化注意事项：
Ⅰ、7个点可以考虑优化为5个点。
Ⅱ、上点必选，此时不考虑区间开闭。
Ⅲ、内点必选，建议考虑范围的中间值。
Ⅳ、开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）。

🌂常用的用例设计方法有哪些？
答：等价类、边界值。

等价类边界值分析法主要关注单个输入类条件的测试。

3）判定表法

①定义：一种以表格形式表达多条件逻辑判断的工具。

②组成：
Ⅰ、条件桩：列出问题中的所有条件，其中列出条件的次序无关紧要。
Ⅱ、动作桩：列出问题中可能采取的操作，其中操作的排列顺序没有约束。
Ⅲ、条件项：列出条件对应的取值，包括所有可能情况下的真假值。
Ⅳ、动作项：列出条件项的、各种取值情况下应该采取的动作结果。

③规则：
Ⅰ、判定表中贯穿条件项和动作项的一列就是一条规则。
Ⅱ、假设有n个条件，每个条件的取值有两个，那么全组合有2的n次方法规则。

④判定表算法设计用例步骤：
Ⅰ、明确需求。
Ⅱ、画出判定表：
1）列出条件桩和动作桩，
2）填写条件项，对条件进行全组合。
3）根据条件项的组合确定动作项。
4）简化、合并相似规则（相同的动作）。
Ⅲ、根据规则编写测试用例。

⑤使用场景：

解决多条件间有依赖关系的测试问题。

Ⅰ、有多个输入条件，多个输出结果，并且输入条件之间是组合关系，输入条件和输出结果之间有依赖（制约）关系。
Ⅱ、一般适用于条件组合数量较少的情况（比如4个条件以下）。

如果条件超过4个，就不适合覆盖所有条件，应采用正交法来解决。

案例：验证“若用户欠费或者关机，则不允许拨号”功能的测试。

判定表：

4）场景法

流程图：使用标准图形和箭头来表达程序或业务的走向。

🌂流程图对测试人员有什么作用？
Ⅰ、能够看懂流程图，设计业务用例。
Ⅱ、当需求文档信息不全时，能根据需求，梳理出流程。

画流程图的工具推荐：
Ⅰ、网页版：https://processon.com/。
Ⅱ、Windows：visio。

🌂覆盖业务测试，需要使用流程图法。
🌂先测试业务，再测试单功能、单模块、单页面。

业务用例是根据流程图来梳理的，需要先了解流程图。

①定义：场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。

②意义：
Ⅰ、用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用。
Ⅱ、测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。

③使用场景：根据实际的应用场景，来测试业务用例。

5）错误推测法

①定义：
通过经验推测系统可能出现的问题。

②思想：
根据经验列出可能出现问题的清单，根据清单分析问题可能的原因，推测发现缺陷。
③场景：

当所以用例都被覆盖，bug也修复完成，离上线只剩几小时，可以使用错误推测法。一般情况下，不推荐。

Ⅰ、时间紧、任务量大时，根据之前的项目类似经验找出易出错的模块重点测试。Ⅱ、时间宽裕的话，通过该方法列出之前出现问题较多的模块。再次测试。

🌂HR：如果时间紧，任务量大，怎么办？
Ⅰ、先和产品经历确定最重要的业务，先覆盖主要业务。
Ⅱ、验证主功能的正逆向，合理安排时间，再覆盖主要模块。
Ⅲ、中间过程会列出相应的测试点，但不会去写用例，后期再补写。
Ⅳ、继续加班完成。