功能测试价值精华贴
来个很简单的需求，看看大家怎样设计用例吧?产品需求：
【假设】微信支持余额支付时，不足的部分可以信用卡补充一起支付，但针对使用余额支付的部分给予 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 不？）
其实我也赞成楼上直接打回需求
简单意味着你的工作是理所当然的。别人的预期和你的预期相差甚远，做完之后可能存在较大的心理落差。而且测试从来都不会仅仅只考虑功能，从质量特性上看，功能、性能、易用性、可靠性、安全、可维护、兼容性等都要考虑。
【假设】微信支持余额支付时，不足的部分可以信用卡补充一起支付，但针对使用余额支付的部分给予 3% 的优惠（直接用于本次支付中）单就这一句话的业务来分析，就有相当多的场景维度要考虑：
微信版本（海外版\国内版\Android\IOS），
微信支付的方式（扫码\被扫），
是否有支付优惠（红包\直减），
支付状态（超时支付、不支付、支付但金额不足、支付超额），
结算货币（人民币、外币、混合），
支付同时的临时动作（首次开通微信支付、支付时开通免密、支付时查看消息后再支付等等），
不足判定的方式、精度，信用卡种类（VISA\Visa Electron (UK only)\Visa Debit\JCB\Diners\MasterCard\MasterCard Debit）及 3DS 认证设置，
信用卡额度限制，
3% 优惠的精度，
优惠方计算，
优惠是否可逆可退可改，报表如何展示交易是否可追溯、可核查交易个人信息加密情况交易如果产生纠纷是否可以被证实且不可否认以上只是我想的一部分，实际上涉及支付的，业务安全和技术安全应该都是重点要考虑的，如果没有预设的背景，发散性的思考，上述维度多条件组合再加上边界值分析，产生的用例可真就多了去了。。。
测试除了业务，也要懂技术，除了测试技术、自动化技术，开发技术也要会点：
代码不一定写，但至少要会数据库、了解架构及中间件的作用，各个应用服务的作用以及被测功能实现逻辑及处理流程。
对于开发平台，我也反对重复再重复造轮子做同样的自动化类的平台，因为实在已经太多了，实在是卷的不行。
但不是说测试不要去学技术，学技术写小工具、写自动化可以让测试便捷、测试的边界更大，更能与开发做沟通。
另外测试平台也是需要的，但得结合部门实际的测试工作规范、工作习惯来设计，而不是对测试片面了解的测开自认为 “高屋建瓴” 的搞个出来。大家不用就是说 “我这个很好用，你们不要浪费时间学技术了，你们学不好的，乖乖的用我这个”。
这边也在维护部门的日常测试工具以及一个测试用例平台（2 个功能测试开发的），但我们都是兼顾着在做功能测试的。我们了解功能测试、部门的测试规范及流程，而且需求方就是我们的其他测试人员。这样这个平台我们部门自己用的很舒畅，以致其他部门也一起用了，甚至产品部都想拿来做需求归档了
测试，不是看到需求明面上东西点点就好。这个帖子以微信支付为例，那是微信大家都用，但设想的测试场景就层次不一样，可以预见之和的用例设计、上下游的沟通协作、执行效率也不一样。另外学技术也是必要的，可以提高工作效率，可以测试更内层的内容。
这一行入行简单，但不代表这行的上限低，积累、学习，共勉。
