测试用例大减负：9大技巧告别冗余与低效

测试用例大减负：9大技巧告别冗余与低效

引用

CSDN

1.

https://m.blog.csdn.net/deerxiaoluaa/article/details/145564839

在软件测试领域，“测试用例“一直是“老生常谈”的话题。在历史的分享中，我们有分享AI生成测试用例、测试用例书写技巧等文章，但如何设计和管理测试用例以保证效率和质量，是一个令人深思的问题。

我们常常会面对一大堆测试用例，有的重复、有的冗余，难免浪费了大量时间却难以发现真正的bug。本文将探讨如何识别和减少浪费的测试用例，以提高测试的有效性。

什么是浪费的测试用例？

在测试执行过程中，浪费的测试用例主要表现为以下几种形式：

1. 冗余步骤

测试用例中的冗余步骤是指那些在测试过程中，对于验证测试用例的目标没有实际意义，可以被省略而不会影响测试结果准确性的步骤。

冗余步骤的产生常表现在以下几个方面：

1.1 重复的操作步骤

示例：测试一个网页表单的提交功能，测试用例步骤如下：

1. 打开浏览器。
2. 输入网址，进入网页表单页面。
3. 填写表单信息。
4. 点击“提交”按钮。
5. 再次点击“提交”按钮。
6. 验证表单是否成功提交。

在这个例子中，步骤5是冗余的。因为对于大多数正常的表单提交功能测试来说，只需要点击一次“提交”按钮，然后验证结果即可。

1.2 与测试目标无关的步骤

示例：测试一个手机应用中的图片浏览功能，测试用例步骤如下：

1. 打开手机应用。
2. 登录账号（该功能与图片浏览功能无直接关联）。
3. 进入图片浏览页面。
4. 点击图片，查看图片是否能正常放大。
5. 验证图片放大后的清晰度。

在这里，步骤2是冗余的。如果测试目标仅仅是验证图片浏览功能中的放大功能，那么登录账号这一步骤是不必要的，除非图片浏览功能有权限限制，需要登录后才能查看。

1.3 多余的验证步骤

示例：测试一个软件的文件保存功能，测试用例步骤如下：

1. 打开软件。
2. 创建一个新的文档。
3. 输入内容。
4. 点击“保存”按钮。
5. 验证文件是否在指定位置保存。
6. 重新打开软件。
7. 打开刚才保存的文件。
8. 验证文件内容是否完整。
9. 再次验证文件格式是否正确。

步骤8和步骤9可以合并。在打开文件后，同时验证文件内容完整性和格式正确性即可，没有必要分开进行两次验证，这样可以简化测试步骤，提高测试效率。

2. 等价类难题

对于复杂的测试场景，如支付场景中的多币种、多渠道测试，测试组合过多，代价极高。

示例：支付场景中的多币种和多渠道测试

假设我们有一个电商平台，支持以下支付方式和币种：

• 支付方式：支付宝、微信支付、银行卡支付、信用卡支付
• 币种：人民币（CNY）、美元（USD）、欧元（EUR）、日元（JPY）

等价类划分

支付方式：

• 有效等价类：支付宝、微信支付、银行卡支付、信用卡支付
• 无效等价类：不支持的支付方式（如PayPal）

币种：

• 有效等价类：人民币（CNY）、美元（USD）、欧元（EUR）、日元（JPY）
• 无效等价类：不支持的币种（如英镑GBP）

测试用例组合

如果我们要测试所有可能的支付方式和币种组合，测试用例的数量将是支付方式数量乘以币种数量：

• 支付方式：4种
• 币种：4种
• 测试用例数量 = 4（支付方式）× 4（币种）= 16个测试用例

具体测试用例

• 支付宝 + 人民币
• 支付宝 + 美元
• 支付宝 + 欧元
• 支付宝 + 日元
• 微信支付 + 人民币
• 微信支付 + 美元
• 微信支付 + 欧元
• 微信支付 + 日元
• 银行卡支付 + 人民币
• 银行卡支付 + 美元
• 银行卡支付 + 欧元
• 银行卡支付 + 日元
• 信用卡支付 + 人民币
• 信用卡支付 + 美元
• 信用卡支付 + 欧元
• 信用卡支付 + 日元

难题

• 测试组合过多：如上所示，即使是简单的4种支付方式和4种币种，就已经有16个测试用例。如果支付方式或币种更多，测试用例数量将呈指数级增长，导致测试工作量极大。
• 测试成本高：每个测试用例都需要进行完整的测试流程，包括环境准备、数据输入、结果验证等，这将消耗大量的时间和资源。
• 测试覆盖不全面：由于测试用例数量过多，可能无法在有限的时间内完成所有测试，导致一些重要的测试场景被遗漏。

避免测试用例冗余的9大方法

那如何做到精简测试用例呢？以下方法总结希望对你有所帮助：

1. 对被测版本足够了解
   详细解读产品需求文档，如交互、功能流程、边界、约束等等。充分理解技术实现原理（实现的逻辑原理、架构及对其他平台的依赖、接口等）。
   深入理解用户群，分析用户使用场景、可能的使用方法及用户心理，完全从用户角度出发，来设计测试用例，同时对用户体验做出一定的判断。

2. 设计用例优先级
   分阶段测试：将测试过程分为单元测试、集成测试、系统测试等阶段，明确每个阶段的测试目标和范围。
   优先级排序：根据需求和业务的重要性，为测试用例设置优先级，确保先测试重要的功能和场景。

3. 使用测试用例管理系统
   组织用例：在系统中创建测试用例库，按功能模块或业务场景分类组织测试用例。
   避免重复：在创建新用例前，检查系统中是否已有相似的用例，避免重复创建。

4. 从粗到细分析需求
   可以使用工具辅助，第一遍需求分析时，粗略画出测试需求框架；第二遍分析需求时，开始延伸每个出子测试点；细化测试点时，可参考或引用写好的公共用例， 也要考虑到被测版本中该功能的特性。另外需要考虑的就是测试点的颗粒度要把握好。

5. 应用测试设计技术
   正交实验设计：使用正交表来减少测试用例的数量，同时确保每个参数组合都被测试到。
   等价类划分：将输入数据划分为不同的等价类，并为每个等价类设计一个测试用例。
   边界值分析：重点关注输入数据的边界值，因为这些值往往是导致错误的地方。

6. 自动化回归测试
   选择自动化场景：对于频繁变更或稳定的模块，编写自动化测试脚本来执行回归测试。
   定期执行：在每次迭代或构建后，自动执行回归测试，确保没有引入新的问题。

7. 关注非功能性测试
   性能测试：测试产品的响应时间、吞吐量、资源占用等指标。
   安全测试：检查产品是否存在安全漏洞，如SQL注入、跨站脚本等。
   兼容性测试：测试产品在不同浏览器、操作系统、设备上的兼容性。

8. 利用探索性测试
   自由测试：根据测试人员的经验和直觉，进行自由的、非脚本化的测试。
   记录发现：记录测试过程中发现的问题和异常，用于后续的缺陷跟踪和修复。

9. 与开发人员紧密合作
   及时反馈：在测试过程中发现的问题要及时反馈给开发人员，以便他们及时修复。
   共同讨论：与开发人员讨论产品的功能和设计，明确测试的重点和难点。

今天的分享就到这里了，那么：

讨论1：平常工作中针对测试用例冗余的情况，一般都是怎么处理的？
讨论2：要写出一份高质量的测试用例，你觉得需要从哪些方面考虑？

本文原文来自CSDN