【读书活动感悟】—等价边界读书组—《软件测试的艺术》第4章 测试用例的设计
发表于 2025-11-11 10:02:46
作为一名软件测试工作者，我们经常遇到一个问题，那就是测试时认为覆盖了全部场景，但是发布上线后发现还是存在一些问题遗漏到生产，原因就是书中第二章提到的：完全的测试是不可能的，因为我们不可能设计出全部的测试用例来对软件进行测试，因为测试用例的枚举是无穷的，那我们怎么才能在海量的测试用例中，找出可能发现最多错误的那个用例子集。
《软件测试的艺术》第四章系统讲述了一系列经典测试方法：黑盒测试：涵盖等价类划分法、边界值分析、因果图分析与错误猜测；白盒测试：包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖及多重条件覆盖。这些方法并非互斥而是互补关系，某类方法遗漏的缺陷，往往能通过其他方法发现。
通过本章的学习，结合日常测试工作经验，我总结了一套测试用例设计方法，不一定都对，个人总结，供大家参考：
1. 当需求文档中明确包含输入条件组合时，优先采用因果分析法。
比如测试退款单线上转线下对接审批流业务，设计用例时就用到了因果分析法，需求明确特来电的退款单线上转线下时对接审批流，其他情况仍走单独的审核记账流程。分析退款单线上转线下对接审批流需满足一下条件：1.必须是特来电的退款单；2.退款失败；3.进行线上转线下操作。设计用例时就要考虑这些条件有哪些组合场景：1.特来电退款单&退款失败&线上转线下→对接审批流；2.特来电退款单&退款失败&重试退款→不对接审批流;3……，将各种条件组合场景全部覆盖。
2. 任何情况下设计用例都应该考虑边界值分析法。
2. 任何情况下设计用例都应该考虑边界值分析法。
比如，平时测试订单支付，正常场景充电订单金额大于0，支付正常。那如果订单金额是0呢，支付状态能否正常流转？
3. 必要时使用等价类法对已确定的测试用例进行补充，避免同类场景遗漏，同时也可以避免重复场景测试，提高测试效率。
4. 结合测试经验、历史缺陷等信息，增加额外的测试场景，覆盖正常场景无法触发的潜在问题。
3. 必要时使用等价类法对已确定的测试用例进行补充，避免同类场景遗漏，同时也可以避免重复场景测试，提高测试效率。
4. 结合测试经验、历史缺陷等信息，增加额外的测试场景，覆盖正常场景无法触发的潜在问题。
例如：像上面提到的订单支付场景，如果是异常订单，程序存在错误导致订单金额是负数。去支付时会出现什么情况？另外，设计用例时还要考虑，依赖的服务异常、超时，接口会如何返回结果？提供的接口被调用方重复调用，是否会产生重复数据？这些场景在日常测试订单支付、收退款相关业务时尤为重要，可以避免用户重复支付，重复退款造成资损等严重问题。通过异常分析，补充异常场景测试用例，进一步完善测试用例集。
156
0
评论
登录 | 注册