我现在的工作是软件测试，刚刚工作一个月，最近有个需求想向大家请教一下怎么设计和执行。
现在公司有十来种产品，每个产品有 3 种订阅时长、3 种类型，所以说每个产品可以生成 9 种订单（A1-A9）。
现在的需求是这样用户在生成这 9 种订单后不支付，在一定时间内可以在订单列表中点击这些未支付的订单完成支付（这些未支付的订单在这个时间内有个特殊的标志，这些特殊标志只会在一定时间后或完成支付后消失。假设用户完成了订单 A1 的支付，那订单 A1 的特殊标志就会消失，而且 A2-A9 订单也不能支付了，会产生冲突），现在用户对订单 A1 进行支付，如果用户之前保留了 A2-A9 订单生成时的支付二维码，通过这个二维码完成支付（假设为 A2 订单），这时用户点击 A2 订单的特殊标志就会提示用户已经重复支付。
这个需求我现在的难点在于每个产品的 9 种订单如果我都要覆盖点的话，那么我要测试 8*9=72 次，总共是 15 个产品，很难覆盖完全的
每个类型选一种？
不需要吧。在我看来这个业务逻辑在 A1 订单支付完成后，剩下的 A2-A9 的特殊标志（已支付状态）用的应该都是同个已支付校验方法，不需要将每个订单都测试，在产品这一层覆盖完就足够了。
1.看代码，知晓具体实现，设计对应等价类用例
2.自动化
建议还是要从底层设计上了解实现的方案。举个例子，比如说 A1 支付后，A2-A9 的订单会在数据库中的某个字段会进行标识，有这种标识的订单就无法正常支付，A1~A9 其实都是通过这部分的逻辑来处理的，这个时候你就可以把重点放在这块的逻辑上的测试，去仔细核验这部分的逻辑是否正确。当然具体的实现逻辑还是要跟开发沟通确认的。
这种情况一般逻辑上都是一样得 大可不必做那么多得正交测试，每种都测到我觉得，每个种类得基础流程走通，再走几种交叉测试就能确定整体情况，当然不排除极小概率出现问题得，可以写个脚本去试试
可以使用正交表减少。产品、订阅时长、类型
黑盒模式下涉及金钱的功能，建议还是全部覆盖，毕竟用户的场景是未知的。
如何精简的话，最好和前后端开发碰一下吗，确认下共性的地方，然后精简用例数。