企业官网建设流程全解析

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

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

阅读本文你将收获：

1.什么是浪费的测试用例？

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

什么是浪费的测试用例？

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

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个测试用例

具体测试用例

1. 支付宝 + 人民币

2. 支付宝 + 美元

3. 支付宝 + 欧元

4. 支付宝 + 日元

5. 微信支付 + 人民币

6. 微信支付 + 美元

7. 微信支付 + 欧元

8. 微信支付 + 日元

9. 银行卡支付 + 人民币

10. 银行卡支付 + 美元

11. 银行卡支付 + 欧元

12. 银行卡支付 + 日元

13. 信用卡支付 + 人民币

14. 信用卡支付 + 美元

15. 信用卡支付 + 欧元

16. 信用卡支付 + 日元

难题

• 测试组合过多：如上所示，即使是简单的4种支付方式和4种币种，就已经有16个测试用例。如果支付方式或币种更多，测试用例数量将呈指数级增长，导致测试工作量极大。

• 测试成本高：每个测试用例都需要进行完整的测试流程，包括环境准备、数据输入、结果验证等，这将消耗大量的时间和资源。

• 测试覆盖不全面：由于测试用例数量过多，可能无法在有限的时间内完成所有测试，导致一些重要的测试场景被遗漏。

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

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

1. 对被测版本足够了解

详细解读产品需求文档，如交互、功能流程、边界、约束等等。充分理解技术实现原理（实现的逻辑原理、架构及对其他平台的依赖、接口等）。

深入理解用户群，分析用户使用场景、可能的使用方法及用户心理，完全从用户角度出发，来设计测试用例，同时对用户体验做出一定的判断。

2. 设计用例优先级

分阶段测试：将测试过程分为单元测试、集成测试、系统测试等阶段，明确每个阶段的测试目标和范围。

优先级排序：根据需求和业务的重要性，为测试用例设置优先级，确保先测试重要的功能和场景。

3. 使用测试用例管理系统

组织用例：在系统中创建测试用例库，按功能模块或业务场景分类组织测试用例。

避免重复：在创建新用例前，检查系统中是否已有相似的用例，避免重复创建。

4. 从粗到细分析需求

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

5. 应用测试设计技术

正交实验设计：使用正交表来减少测试用例的数量，同时确保每个参数组合都被测试到。

等价类划分：将输入数据划分为不同的等价类，并为每个等价类设计一个测试用例。

边界值分析：重点关注输入数据的边界值，因为这些值往往是导致错误的地方。

6. 自动化回归测试

选择自动化场景：对于频繁变更或稳定的模块，编写自动化测试脚本来执行回归测试。

定期执行：在每次迭代或构建后，自动执行回归测试，确保没有引入新的问题。

7. 关注非功能性测试

性能测试：测试产品的响应时间、吞吐量、资源占用等指标。

安全测试：检查产品是否存在安全漏洞，如SQL注入、跨站脚本等。

兼容性测试：测试产品在不同浏览器、操作系统、设备上的兼容性。

8. 利用探索性测试

自由测试：根据测试人员的经验和直觉，进行自由的、非脚本化的测试。

记录发现：记录测试过程中发现的问题和异常，用于后续的缺陷跟踪和修复。

9. 与开发人员紧密合作

及时反馈：在测试过程中发现的问题要及时反馈给开发人员，以便他们及时修复。

共同讨论：与开发人员讨论产品的功能和设计，明确测试的重点和难点。

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

讨论1：平常工作中针对测试用例冗余的情况，一般都是怎么处理的？

讨论2：要写出一份高质量的测试用例，你觉得需要从哪些方面考虑？

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取