“测试就是点点点”，好吧，来个很简单的需求，看看大家怎样设计用例吧?
产品需求：
【假设】微信支持余额支付时，不足的部分可以信用卡补充一起支付，但针对使用余额支付的部分给予 3% 的优惠（直接用于本次支付中）
打回需求。需求不明确：3% 的优惠是根据什么金额范围来计算的，如果余额支付的部分只有 1 分钱，3% 如何计算？还有优惠是支付时直接抵扣支付金额的还是支付完成后返现的？
1.总金额 1 元 余额支付 0.1 元 信用卡支付 0.9 元 -> 实际付款 余额：0.1*0.97=0.097 信用卡：0.9
默认 CNY 精度为 2 位，0.097 怎么处理？四舍五入还是截尾法？
2.总金额 1 元 余额支付 0.01 元 信用卡支付 0.99 元 -> 实际付款 余额：0.01*0.97=0.0097 信用卡：0.99
默认 CNY 精度为 2 位，0.0097 怎么处理？显示不了啊？
3.总金额 10 元 余额支付 1.5 元 ,信用卡支付 8.5-> 实际付款 余额：1.5*0.97=1.455 信用卡：8.5
1.455 怎么处理？
4.余额不足，余额支付一半的金额后，退出，再次使用余额支付（接了一笔钱）剩余的尾款，还会优惠吗？ ->不优惠
5.信用卡支付过程中退出，换乘余额支付，看看有优惠没-> 没有优惠
6.余额充足，但是只用余额付一半，剩余一半使用信用卡？
7.全部使用余额支付（试试可以使用信用卡付款 0 元不？->全部使用余额支付时，信用卡支付不被拉起，否则会逻辑混乱）
8.全部使用信用卡支付（试试余额可以付款 0 不？）
其实我也赞成楼上直接打回需求
杨超
回复
信用卡额度这么明显的因素不用考虑吗
另外，也赞成拒绝这种垃圾需求，连用户场景都没交代……大约是预设了很多背景条件，但是都没说出来，觉得所有人都默认明白
槽神
回复
这个要是测试能直接打回就好了。。。。。。人家产品才是说了算的人。
这个其实是 1 个现实场景中的缩影，就算那个产品经理已经考虑了这种那种场景，但还是有各种场景坑在里面。
需求如果完善的整理好，就该 1 篇 10 页以上的需求文档了，但目前现实是需求工程师这个岗位已经没有了，只有产品岗：只有我要什么就得做什么，负责的还会给你考虑各种情况，不负责的真得测试或者开发深入后，反向推动产品去完善各种场景。
好了，牢骚发完了，说下正题，这个是个面试题（所以需求比较短，而且背景就是针对就微信扫码支付场景）
一是看看测试人员考虑问题的全面性，是发散式的。这里面涉及等价类、边界值，也涉及页面与后端二次校验、幂等校验等等：直接反映出测试基本能力：你能保证自己的测试足够充分吗（这个可是支付，容错性要求可是极低的）
二是看看测试人员做事方式，是找到一个问题直接撂挑子，还是罗列尽可能多的方式找产品沟通并一一确认。
什么鸟蛋需求，不干了，不测了 😄
【假设】微信支持余额支付时，不足的部分可以信用卡补充一起支付，但针对使用余额支付的部分给予 3% 的优惠（直接用于本次支付中）
1.这个需求有上下文么？
2.支付的场景是？条码主扫？条码被扫？快捷支付？ 小额免密？额度限制？ 里面其实有不同的细节要求。
3.信用卡商户支持问题。哪些商户允许并支持哪种信用卡付款？如何过滤？结合问题 2.
4.信用卡额度。
5.这是端到端场景需求么？各种异常处理的定义是什么？ 比如余额不足 + 信用卡额度不足。比如信用卡支付失败（卡片状态异常、网络超时）
6.优惠 3% 是谁的优惠，扣谁的钱？这部分谁管？是不是只要扣了就行了？还是要管后面的那一大坨，这就可不是几十条用例能搞定的了？（后面一大坨系统和流程可能挂着个复杂的营销系统）
7.一大堆边界值测试。
8.防薅羊毛？
9.退货、退款流程咋搞？（这也是一大坨，想一想，它并不简单）
。。。。
10.这种营销活动怎么推广的？会不会带来扎堆使用从而引发性能问题，系统准备好了么？
用了 5 分钟想到这么多。其实没那么简单是吧？
这里出了问题，就会资损。如果每笔资损较少，后台又没有有效及时的对账，这又是个很范围广的活动，损失个几百万也很常见，这样例子见多了。
功能测试人能防住这个，所以还是有价值。
但是，希望别只是点点点。努力扩展自己的能力边界吧。
JoyMao
回复
好吧，实话说，我前面回复的时候说『预设了很多背景条件』，然后想说就像某些沙雕面试官的出题套路一样，结果觉得太那啥了，又憋回去了，不成想还真是……
补充我想到的：支付方式是只需要一次支付（扫一次码就可以余额和信用卡都扣了）还是两段支付？
优惠部分是算在商家头上还是微信的？
个人收款码是否有效？
其实真正的目的就是 15 楼所说的。
功能测试可不是点点点，不是要求别人尽善尽美，不是学个测试基础理论就能干好，不是预设自己处于理想化的工作环境中。
这个需求看上去很简单，但不同层次的测试人员看到的东西就是不一样：有的只是流于表面的字里行间，有的已经将整个资金体系都纳入考虑范围：这个就是功能测试人的价值——有的已经超越了产品经理的业务广度。
现在很多刚入行的面试时一来就各种技术说的贼溜，但问及点功能测试的内容就支支吾吾，解释说自己是不做功能测试的只做自动化......说的好像功能测试是很受鄙视的（还是太年轻......）
洄汩
回复
因为是面试题，不会给你长篇的规则限制的，所以可以说没有真正的答案的。看的就是你能发散考虑的范围，考虑问题的能力。
所以你的补充也是 OK 的。
其实你的问题再仔细思考需求时，能推测可能的答案：余额为啥要给折扣？
是不是想鼓励人去把钱放到余额吧？
是不是余额是平台自己的，不像信用卡一样需要额外的手续费，或者风控上的风险（信用、拒付等等呢）？
这些受益人是平台，所以折扣由平台出（而不是商户）是不是更合理？那应不应该有上限？
我现在听到 “简单” 就头疼。。。简单意味着你的工作是理所当然的。别人的预期和你的预期相差甚远，做完之后可能存在较大的心理落差。而且测试从来都不会仅仅只考虑功能，从质量特性上看，功能、性能、易用性、可靠性、安全、可维护、兼容性等都要考虑。
【假设】微信支持余额支付时，不足的部分可以信用卡补充一起支付，但针对使用余额支付的部分给予 3% 的优惠（直接用于本次支付中）
单就这一句话的业务来分析，就有相当多的场景维度要考虑：
- 微信版本（海外版\国内版\Android\IOS），
- 微信支付的方式（扫码\被扫），
- 是否有支付优惠（红包\直减），
- 支付状态（超时支付、不支付、支付但金额不足、支付超额），
- 结算货币（人民币、外币、混合），
- 支付同时的临时动作（首次开通微信支付、支付时开通免密、支付时查看消息后再支付等等），
- 不足判定的方式、精度，
- 信用卡种类（VISA\Visa Electron (UK only)\Visa Debit\JCB\Diners\MasterCard\MasterCard Debit）及 3DS 认证设置，
- 信用卡额度限制，
- 3% 优惠的精度，
- 优惠方计算，
- 优惠是否可逆可退可改，
- 报表如何展示
- 交易是否可追溯、可核查
- 交易个人信息加密情况
- 交易如果产生纠纷是否可以被证实且不可否认
以上只是我想的一部分，实际上涉及支付的，业务安全和技术安全应该都是重点要考虑的，如果没有预设的背景，发散性的思考，上述维度多条件组合再加上边界值分析，产生的用例可真就多了去了。。。
15 楼和 21 楼很强，这样的需求应该是完全正常的，国内有很多大型的购物平台采用平台余额优惠 + 微信补款的方式实现。
在流程执行过程中可能还需要测试： 微信支付后的显示状态、 是否有优惠后提醒、怎么进入信用卡补款阶段、如果不进入补款会怎样、信用卡无法支付时如何退款。
还有一点很重要，弱网环境下重复支付以及银行的误操作也要考虑，若在弱网下发起了重复请求（可能客户已输入交易密码），银行扣款 2 次要不要考虑返还客户（当然这个跟银行的系统有很大的关系，国内银行系统没碰到过，但不能排除掉类似的一些重复请求）
刘晓光
回复
哈哈，感谢认可，暂时没有打算。
晓光老师您的每篇文章和帖子的回复我都拜读过，学习到了很多东西！
特别是《聊一聊职业发展》，每年我都会回头看一遍，年年都有新的收获。
作为您的前前前同事（我是分子公司的），您的经历也很传奇，我辈榜样~
无意中，看到了这个帖子：https://testerhome.com/topics/30396
贴子内容很极端，口气像是一个测开对测试推广自己的平台无效后的泄愤，也充斥着对测试的片面的理解。不知道原贴人看到这个帖子后，回答能不能想上面的 15 楼和 21 楼一样好，还是单纯的认为点点就好。
嗯...自己有些想法不吐不快，也算总结吧。
测试除了业务，也要懂技术，除了测试技术、自动化技术，开发技术也要会点：
代码不一定写，但至少要会数据库、了解架构及中间件的作用，各个应用服务的作用以及被测功能实现逻辑及处理流程。
对于开发平台，我也反对重复再重复造轮子做同样的自动化类的平台，因为实在已经太多了，实在是卷的不行。
但不是说测试不要去学技术，学技术写小工具、写自动化可以让测试便捷、测试的边界更大，更能与开发做沟通。
另外测试平台也是需要的，但得结合部门实际的测试工作规范、工作习惯来设计，而不是对测试片面了解的测开自认为 “高屋建瓴” 的搞个出来。大家不用就是说 “我这个很好用，你们不要浪费时间学技术了，你们学不好的，乖乖的用我这个”。
这边也在维护部门的日常测试工具以及一个测试用例平台（2 个功能测试开发的），但我们都是兼顾着在做功能测试的。我们了解功能测试、部门的测试规范及流程，而且需求方就是我们的其他测试人员。这样这个平台我们部门自己用的很舒畅，以致其他部门也一起用了，甚至产品部都想拿来做需求归档了
测试，不是看到需求明面上东西点点就好。这个帖子以微信支付为例，那是微信大家都用，但设想的测试场景就层次不一样，可以预见之和的用例设计、上下游的沟通协作、执行效率也不一样。另外学技术也是必要的，可以提高工作效率，可以测试更内层的内容。
这一行入行简单，但不代表这行的上限低，积累、学习，共勉。
测试点点，同事在字节跳动，45w+，你也会愿意的，哈哈哈哈，其实测试点点点，本质是端到端的评测，是效率和发现问题最好的方法，也是有价值的。
无意中看到了大佬关于功能测试的评论，我表示非常赞同，正如国外从始至终认为的一样，功能测试才是整个测试范围内最有价值的部分，可惜由于国内各种内卷，各种对技术的追捧，对功能测试看不起这种风气的流行，着实对测试的环境真的很不友好。为什么大厂都是招测试开发工程师呢，自动化为啥这个 title 逐渐的就没落了，时代在进步，对测试人员的要求越发的高了，不仅要求测试要有测试思维，测试还得懂技术，熟悉技术特性，对项目的质量做出更好的保障，总的来说功能测试的涵盖面非常广泛，个人的测试思维深度，技术深度，决定了质量保障的深度，恰恰这种价值很难被体现出来，每个测试人员的质量标准很难被量化，非常遗憾。
说实话，本人从业软件测试 11 年啦，虽然也是混日子，也试下
1、余额足够支付情况测试，预期，仅扣余额。
2、余额不足支付，需要扣除信用卡，支付完成后，信用卡和余额均被扣除。
3、账号异常情况考虑：账户被禁用，绑定无效信用卡，信用卡额度不足，信用卡过期，信用卡已注销，用户没有开通信用卡，网络不通，信用卡支付渠道关闭，支付密码输入失败等情况，均不能正确完成交易，扣除金额。
4、余额足够时被扣除边界值校验，0，0.01，0.1，1，10，100，1000，10000，100000，MAX 金额（看业务决定），同时享受了 3% 的优惠。
5、余额不足时，信用卡被扣除边界值校验，0，0.01，0.1，1，10，100，1000，10000，100000，MAX 金额（看业务决定），同时扣除金额不享受优惠。
6、性能测试，并发性能，响应时间，服务器性能情况，容量规划等。
7、安全性测试，分析请求协议，检查服务器是否有漏洞等。
8、订单金额边界值测试，0，0.01，0.1，1，10，100，1000，10000，100000，MAX 金额（看业务决定），均能正确扣除足够的金额。
9、余额足够时优惠边界值计算，0，0.01，0.1，0.99，1，1.99，100，1000，10000，100000，MAX 金额（看业务决定），3% 优惠金额能正确体现。
单纯从用例设计上考虑测试价值还是不够的
所以有句话怎么说来着，好的测试相当于半个产品经理
实际上在面试过程中，很多面试官会问最简单的一个场景，就是全面测试登录。这个场景对于不同经验的功能测试人员来说，答案可是天差地别，有的只会说几句，有的能说上几分钟不停。。。
疑问点全部在这个 3% 的优惠，这种属于需求不明确类型。如果这是真实需求，我会找产品，补充完善这部分的具体优惠细节，如果是考题，那就发散思维了。
666 啊 大佬们真的强
你们不考虑在什么环境下测试吗 不应该先考虑怎么沙盒
我去催饭
回复
的确傲气，工作这么多年，还没怎么遇到过直接打回需求的测试·········一般这样子的同学要么就被边缘化了，要么就没了···如果有这么棒的 ‘地位’，那的确是梦想的地方；·
大佬们有提升测试思维的书籍或者相关帖子推荐吗？谢谢大佬
我随便补充几个场景吧：
1.偏用例设计的：信用卡的数量、使用顺序，是不是还要考虑：0 张？N 张？（比如默认招行，OK，如果招行的被关了，或者接口异常，系统要如何处理），整个接口那边的计算逻辑可能都要考虑下改动大不大，比如应收和实收之类。
2.如果是场景思维：如果把这个算法展示给客户，对的，产品是这么要求的，但是要说明为什么，或者是不是有更好的方案，如果你的目的是想说让客户多往余额里存钱，那就要让更多的客户通过这个设计来更多的存入余额，而不止是说算好这个优惠吧。可能开发也实现了这个功能，逻辑也对了，但是并没有很多人来使用余额，那这时候这个功能设计是不是就不够完善了。
3.我个人认为功能测试从需求分析开始介入，从用例设计可能就有点晚，这是我理解的功能测试人的价值，不是针对那个怎么设计 3% 优惠计算对不对的问题。总的来说就是确保产品出去是有意义的、程序正确的、业务闭环的、还有用户体验。
下田了
回复
这个不用考虑 他就是个假设 考的是思维和经验，这发散范围广的去了。
如果这是一个真实项目的需求，我会把这一张没有写满字的 A4 纸直接甩他脸上，再 Tui 一口唾沫，把他从我的办公室 Cei 出去，然后咆哮一句 “GAY LOSE GUI”。
真的膜拜大佬了，我最佩服的是认准对待问题的几位，
这个主题很好，贴地气
膜拜大佬们 很多时候面试的时候被问到测试用例设计就发挥不出来 还是自己积累不够
价值不是自己给自己评估的，而是别人愿意付出的，不管是戳戳点点，还是指点江山，通常来说，稀缺性才是决定价值的重要因素，但不是全部。当稀缺性不存在的时候，就回归到了价值交换的层面。
今天又是想退休的一天
回复
每天忙于工作，很正常的。“局限在点点点中”，我们能否点得更快，或点出更多 bug 出来呢，这些都需要测试思维的提升。
或者发一个贴，你在点什么，要怎么样才能更快，也是一种思考呢
简11
回复
测试思维没有提升，一直在重复点点点，所以想看点书，搭建一下自己的知识框架和体系，再往这个方向努力。平常有在总结，但由于思维局限，总有我没有考虑到的方面
可以再考虑跨境支付