1. 常见的测试用例设计方法
1.1 等价类划分法
有这样一条测试基本原则：**穷尽测试是不可能的。**即使是看起来规模很小的软件产品，其输入数据的组合或逻辑路径也几乎是无穷的，也就是说，想对测试对象进行完全的检查和覆盖，基本上是不可能的。
那我们可以依照数据的特性，将所有的测试数据分为若干个类，每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误A，这一等价类中的其他例子也能发现这个错误A；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。这种划分数据的方法被称为**等价类划分方法，**划分等价类时遵循以下3个标准：
- 完备性：划分的子集合的并集是整个集合;
- 无冗余性：子集互不相交;
- 等价性：属于同一等价类的测试数据，映射到”相同的执行路径"。
举个🌰：UC登录界面要求用户输入工号登录，工号由6位数字组成
| 输入等价类 | 有效等价类 | 无效等价类 |
| 输入的类型和长度 | 1. 6位数字字符 | 2. 存在英文等非法字符 3. 输入小于6位数字字符 4. 输入大于6位数字字符 |
设计测试用例，覆盖所有的有效等价类和无效等价类：
| 等价类类型 | 测试数据 | 期望结果 | 覆盖的等价类 |
| 有效等价类 | 815525 | 输入有效 | 1 |
| 无效等价类 | 8A5525 | 输入无效 | 2 |
| 无效等价类 | 81552 | 输入无效 | 3 |
| 无效等价类 | 8155255 | 输入无效 | 4 |
1.2 边界值
主要通过测试输入域的边界值和附近的值，以检测程序在输入域的边界情况下是否能正常工作，包括边界值本身和边界值附近的值。在设计该方法的测试用例时需要遵循以下几个规则：
- 边界值：对于输入域的最小值和最大值，设计测试用例，包括最小值、最大值和最小值与最大值之间的值
- 非法值：测试输入域之外的非法值，包括小于最小值和大于最大值的值
- 边界值的中间值：设计测试用例覆盖边界值的中间值，以确保程序在边界值附近的情况下仍然可以正常工作
举个🌰：测试任务单据标题
输入数据：
- 输入值为1-150个字符，测试输入值范围内的有效值
- 输入值为空，测试输入框为空的情况
- 输入值为151个字符，测试超过输入值范围的非法值
- 输入值为150个字符，测试输入框的边界值
- 输入值为75个字符，测试输入框的中间值
输出结果：
- 正常创建数据
- 提示输入标题
- 无法输入最大字符数以外的字符
- 正常创建数据
- 正常创建数据
总结：以上5个测试用列，基本上覆盖了输入框输入范围内的有效值、输入框为空、超出输入值范围的非法值，以及边界值和中间值的情况，测试用例的数量相对较少，同时又可以覆盖输入框输入值的各种情况。使用边界值分析法可以大大提高测试效率，但也需要注意输入框的特殊情况，如特殊字符、行末空格等，需要综合其他测试方法和经验进行测试。
1.3场景法/流程分析法
上面介绍的这两种方法对于单点测试是十分有效的，但实际测试过程中，单点测试只是其中一个步骤，用户还可能在其步骤后还会有一系列的其他步骤来完成一个功能点的闭环。
根据场景来设计测试用例的方法我们称之为场景法，也称为流程分析法。使用场景法的第一步自然是画出业务流程图，通常我们能从BA/UX处获取到流程图，如果没有，那就需要自己去梳理了。场景法一般包含基本流、备用流和异常流，基本流表示通过业务流程时输入都正确，能达到目标；备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到能达到目标；异常流是指通过业务流程时输入错误（或者操作错误）产生异常终止流程 。
画流程图可以先从基本流开始，也就是先确定Happy Path，然后补充备选流，最后还要考虑异常场景来确定异常流。
举个🌰：创建事务单据
- 基本流程：
场景：创建任务
- 打开事务池。
- 点击“创建”按钮，进入新建任务页面。
- 在新建任务页面中，填写必填项，包括事务标题、事务归属、截止时间等。
- 点击“完成”按钮，任务保存成功。
- 备用流程：
场景：创建任务
- 打开事务池。
- 点击“创建”按钮，进入新建任务页面。
- 在新建任务页面中，不填写必填项，直接点击“保存”按钮。
- 系统提示必填项不能为空，要求用户填写必填项。
- 用户填写完必填项后，再次点击“完成”按钮，任务保存成功。
- 备用流程2：
场景：创建任务
- 打开事务池。
- 点击“创建”按钮，进入新建任务页面。
- 在新建任务页面中，填写必填项，但截止时间填写错误，已经过期。
- 点击“保存”按钮，系统提示截止日期已经过期，要求用户修改截止日期。
- 用户修改截止日期后，再次点击“完成”按钮，任务保存成功。
- 异常流
场景：创建任务
- 打开事务池。
- 点击“创建”按钮，进入新建任务页面。
- 在新建任务页面中，填写必填项，输入正确的截止日志。
- 点击“保存”按钮，弱网导致一直提交中状态。
- 超时结束
如图
1.4 错误推断法
该方法通过分析已知的错误和错误产生的原因，推断可能存在的新错误，并设计测试用例以检测这些错误。该方法通常适用于系统中存在已知错误和历史错误记录的情况下，可以更高效地发现潜在的错误。
举个🌰：事务池搜索
- 收集已知的程序错误和错误模式：收集已知的程序错误和错误模式，包括程序代码、文档和用户反馈等，以分析错误的原因和规律。例如：搜索空格时部分类型数据加载异常。
- 分析错误原因和模式：我们需要对已知的错误进行分析，找出它们的共性、相似点和错误产生的原因，以便预测可能存在的新错误。例如：搜索结果空格不准确的原因可能是服务端处理空格字符不统一，或者前端在处理空格字符时不统一的造成的。
- 推断新的错误：基于已知错误和错误模式，推断可能存在的新错误，并设计测试用例以检测这些错误。例如：搜索条件和搜索结果未能用蓝色字体进行匹配。
- 设计测试用例以覆盖错误推断的情况，包括输入值、边界值、异常值、特殊值等。例如，搜索一个长字符串、搜索一个短字符串、搜索一个空字符串、搜索一个特殊字符等。
- 执行测试用例：根据测试用例执行测试，检测是否发现新的错误和已知的错误是否已被解决。例如，搜索一个长字符串时，检查搜索结果是否正确；搜索一个特殊字符串时，检查是否会出现未能匹配的情况。
2. 如何避免漏测,提高测试效率
2.1 制定详细的测试计划和测试用例
制定详细的测试计划和测试用例需要覆盖各种场景和业务流程，并在测试执行过程中按照计划进行测试。具体步骤如下：
- 确定测试目标和测试范围，了解需求和设计，确定测试重点和测试方案。
- 根据测试目标和测试范围，设计测试用例，并覆盖各种场景和业务流程。测试用例应该包括测试目的、测试步骤、预期结果和实际结果。
- 对测试用例进行评审，由团队成员一起检查测试用例，确保测试用例的完整性和正确性。
- 将测试用例组织成测试套件，提高测试效率。
举个🌰：事务池创建单据
-
确定测试目标和测试范围
测试目标：测试任务单据的正确性、完整性和稳定性
测试范围：任务的创建、编辑、状态更新、查看等功能
-
设计测试用例
根据测试目标和测试范围，我们可以设计一些测试用例，如下所示：
2.1 创建任务
- 打开创建任务弹窗
- 输入任务任务标题、事务说明、执行人、截止时间等必填信息
- 点击完成按钮
预期结果：成功创建任务单据。
2.2 编辑任务
- 用户打开任务编辑弹窗
- 用户修改任务信息
预期结果：成功更新任务信息
2.3 查看任务
- 用户打开个人事务池界面
- 选择要查看的任务
- 点击打开任务详情弹窗
预期结果：弹窗显示任务填写的对应的任务信息
2.4 更新任务状态
- 执行人打开任务详情弹窗
- 点击完成/暂停/转交/延期等修改任务状态按钮
预期结果：向单据创建者发送任务状态更新申请的任务通知（如果创建者和执行者时同一人无需申请直接修改状态，否则需要创建者者同意申请后修改状态）
2.5 异常情况测试
- 用户未填写必填项，保存任务时系统给出必填提示信息
- 用户填写的截止时间已经过期，保存任务时系统给出截止时间过期的信息
预期结果：系统能够正确处理异常情况，并给出正确的提示信息
3. 进行测试用例评审
对测试用例进行评审，由全链路成员（BA/UX/UI/开发/测试）一起检查测试用例，确保测试用例的完整性和正确性。评审步骤如下：
3.1 确定评审的范围和目标：评审的范围是该测试用例，目标是确保测试用例的正确性、全面性和有效性。
3.2 组织评审人员和评审会议：评审人员包括测试人员、开发人员、产品经理等，评审会议需要在测试开始前召开。
3.3 准备评审材料和工具：评审材料包括测试用例、需求规格说明书、测试计划等，评审工具包括评审表格、评审软件等。
3.4 进行评审和记录：评审人员根据评审材料和工具对测试用例进行审核和检查，记录测试用例的缺陷和问题，并提出改进和优化的建议。例如，评审人员发现该测试用例中缺少对于任务单据创建过程中输入的信息是否正确的验证，提出应该增加该部分测试用例的建议。
3.5 总结评审结果和输出评审报告：评审结果需要总结和归纳，输出评审报告并将其分发给相关人员。例如，评审报告中包括了测试用例的缺陷和问题、改进和优化的建议等。
4. 将测试用例组织成测试套件
将测试用例组织成测试套件可以更好地管理和执行测试用例，提高测试的效率和准确性。以下是一些组织测试用例成测试套件的方法：
4.1 按照功能模块组织 将测试用例按照不同的功能模块组织，如创建、编辑、状态更新、详情等模块，这样可以方便针对不同的模块进行测试，同时也方便维护和管理测试用例。
4.2 按照测试类型组织 将测试用例按照不同的测试类型进行组织，如功能测试、性能测试、安全测试、兼容性测试等，这样可以方便区分不同类型的测试用例，同时也方便对系统进行不同类型的测试。
4.3 按照测试优先级组织 将测试用例按照测试优先级进行组织，如高优先级、中优先级、低优先级等，这样可以方便在测试的时候优先进行高优先级的测试，以提高测试效率。
4.4 按照业务场景组织 将测试用例按照不同的业务场景进行组织，如正常场景、异常场景、边界场景等，这样可以方便在测试的时候针对不同的场景进行测试，同时也方便测试人员进行全面的测试。
4.5 按照执行顺序组织 将测试用例按照执行顺序进行组织，如按照测试步骤的先后顺序、按照测试覆盖率的高低顺序等，这样可以方便测试人员进行有序的测试，同时也方便测试人员对测试结果进行分析和比对。
2.2 使用自动化测试工具
使用自动化测试工具，对重复性测试进行自动化，减少手动测试的工作量和时间，同时提高测试的效率和准确性。
可参考公司产品ulog。
2.3 引入测试缺陷跟踪工具
引入测试缺陷跟踪工具，记录和跟踪测试过程中发现的缺陷，以便及时解决。
可参考公司产品pms。
2.4 业务需求文档记录
业务需求文档记录从产品的策划到最新的迭代，都能有需求文档记录，方便后续人员接手时快速理解需求和设计，以及更准确地进行测试。
