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

在软件测试领域，“测试用例“一直是“老生常谈”的话题。在历史的分享中，我们有分享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：要写出一份高质量的测试用例，你觉得需要从哪些方面考虑？

文末了：

      可以到我的个人号：atstudy-js，可以免费领取一份10G软件测试工程师面试宝典文档资料。同时我邀请你进入我们的软件测试学习交流平台，大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，了解测试行业的最新趋势，助你快速进阶Python自动化测试/测试开发，稳住当前职位同时走向高薪之路。