测试基础 关于功能测试人的价值

JoyMao · 2021年12月06日 · 最后由 兔子李 回复于 2022年01月13日 · 4880 次阅读
本帖已被设为精华帖!

“测试就是点点点”,好吧,来个很简单的需求,看看大家怎样设计用例吧?
产品需求:
【假设】微信支持余额支付时,不足的部分可以信用卡补充一起支付,但针对使用余额支付的部分给予 3% 的优惠(直接用于本次支付中)

共收到 33 条回复 时间 点赞

打回需求。需求不明确:3% 的优惠是根据什么金额范围来计算的,如果余额支付的部分只有 1 分钱,3% 如何计算?还有优惠是支付时直接抵扣支付金额的还是支付完成后返现的?

我去催饭 回复

上面是产品的定义。
至于你的考虑,只是一种测试需要考虑的场景。

JoyMao 回复

产品的定义不合理描述不清晰不能质疑吗?为什么要测试替他考虑这些东西?

我去催饭 回复

可以质疑啊
但看这个主题的标题啊。

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 页以上的需求文档了,但目前现实是需求工程师这个岗位已经没有了,只有产品岗:只有我要什么就得做什么,负责的还会给你考虑各种情况,不负责的真得测试或者开发深入后,反向推动产品去完善各种场景。

好了,牢骚发完了,说下正题,这个是个面试题(所以需求比较短,而且背景就是针对就微信扫码支付场景)
一是看看测试人员考虑问题的全面性,是发散式的。这里面涉及等价类、边界值,也涉及页面与后端二次校验、幂等校验等等:直接反映出测试基本能力:你能保证自己的测试足够充分吗(这个可是支付,容错性要求可是极低的)
二是看看测试人员做事方式,是找到一个问题直接撂挑子,还是罗列尽可能多的方式找产品沟通并一一确认。

JoyMao 回复

如果面试的公司产品就这水平,那这保姆式测试不干也罢,或者我去当产品好了,写成这个鸟样的产品得舒服成啥样啊😂

JoyMao #11 · 2021年12月06日 Author
我去催饭 回复

傲气👏

JoyMao 回复

跟这样水平的产品共事。。。实际上也待不了多久

什么鸟蛋需求,不干了,不测了 😄

杨超 回复

不错,用来做面试题了。

JoyMao 回复

好吧,实话说,我前面回复的时候说『预设了很多背景条件』,然后想说就像某些沙雕面试官的出题套路一样,结果觉得太那啥了,又憋回去了,不成想还真是……

补充我想到的:支付方式是只需要一次支付(扫一次码就可以余额和信用卡都扣了)还是两段支付?
优惠部分是算在商家头上还是微信的?
个人收款码是否有效?

其实真正的目的就是 15 楼所说的。
功能测试可不是点点点,不是要求别人尽善尽美,不是学个测试基础理论就能干好,不是预设自己处于理想化的工作环境中。
这个需求看上去很简单,但不同层次的测试人员看到的东西就是不一样:有的只是流于表面的字里行间,有的已经将整个资金体系都纳入考虑范围:这个就是功能测试人的价值——有的已经超越了产品经理的业务广度。

现在很多刚入行的面试时一来就各种技术说的贼溜,但问及点功能测试的内容就支支吾吾,解释说自己是不做功能测试的只做自动化......说的好像功能测试是很受鄙视的(还是太年轻......)

刘晓光 回复

厉害厉害 专业

JoyMao #20 · 2021年12月07日 Author
洄汩 回复

因为是面试题,不会给你长篇的规则限制的,所以可以说没有真正的答案的。看的就是你能发散考虑的范围,考虑问题的能力。

所以你的补充也是 OK 的。
其实你的问题再仔细思考需求时,能推测可能的答案:余额为啥要给折扣?
是不是想鼓励人去把钱放到余额吧?
是不是余额是平台自己的,不像信用卡一样需要额外的手续费,或者风控上的风险(信用、拒付等等呢)?
这些受益人是平台,所以折扣由平台出(而不是商户)是不是更合理?那应不应该有上限?

JoyMao #22 · 2021年12月07日 Author
Ouroboros 回复

厉害👏

Ouroboros 回复

有意换换工作么?

15 楼和 21 楼很强,这样的需求应该是完全正常的,国内有很多大型的购物平台采用平台余额优惠 + 微信补款的方式实现。

在流程执行过程中可能还需要测试: 微信支付后的显示状态、 是否有优惠后提醒、怎么进入信用卡补款阶段、如果不进入补款会怎样、信用卡无法支付时如何退款。

还有一点很重要,弱网环境下重复支付以及银行的误操作也要考虑,若在弱网下发起了重复请求(可能客户已输入交易密码),银行扣款 2 次要不要考虑返还客户(当然这个跟银行的系统有很大的关系,国内银行系统没碰到过,但不能排除掉类似的一些重复请求)

刘晓光 回复

哈哈,感谢认可,暂时没有打算。

晓光老师您的每篇文章和帖子的回复我都拜读过,学习到了很多东西!

特别是《聊一聊职业发展》,每年我都会回头看一遍,年年都有新的收获。

作为您的前前前同事(我是分子公司的),您的经历也很传奇,我辈榜样~

JoyMao #27 · 2021年12月09日 Author

无意中,看到了这个帖子:https://testerhome.com/topics/30396
贴子内容很极端,口气像是一个测开对测试推广自己的平台无效后的泄愤,也充斥着对测试的片面的理解。不知道原贴人看到这个帖子后,回答能不能想上面的 15 楼和 21 楼一样好,还是单纯的认为点点就好。

嗯...自己有些想法不吐不快,也算总结吧。

测试除了业务,也要懂技术,除了测试技术、自动化技术,开发技术也要会点:
代码不一定写,但至少要会数据库、了解架构及中间件的作用,各个应用服务的作用以及被测功能实现逻辑及处理流程。

对于开发平台,我也反对重复再重复造轮子做同样的自动化类的平台,因为实在已经太多了,实在是卷的不行。
但不是说测试不要去学技术,学技术写小工具、写自动化可以让测试便捷、测试的边界更大,更能与开发做沟通。
另外测试平台也是需要的,但得结合部门实际的测试工作规范、工作习惯来设计,而不是对测试片面了解的测开自认为 “高屋建瓴” 的搞个出来。大家不用就是说 “我这个很好用,你们不要浪费时间学技术了,你们学不好的,乖乖的用我这个”。
这边也在维护部门的日常测试工具以及一个测试用例平台(2 个功能测试开发的),但我们都是兼顾着在做功能测试的。我们了解功能测试、部门的测试规范及流程,而且需求方就是我们的其他测试人员。这样这个平台我们部门自己用的很舒畅,以致其他部门也一起用了,甚至产品部都想拿来做需求归档了

测试,不是看到需求明面上东西点点就好。这个帖子以微信支付为例,那是微信大家都用,但设想的测试场景就层次不一样,可以预见之和的用例设计、上下游的沟通协作、执行效率也不一样。另外学技术也是必要的,可以提高工作效率,可以测试更内层的内容。

这一行入行简单,但不代表这行的上限低,积累、学习,共勉。

JoyMao 关闭了讨论 12月09日 11:15
陈恒捷 将本帖设为了精华贴 12月09日 11:30
JoyMao 重新开启了讨论 12月09日 11:37

测试点点,同事在字节跳动,45w+,你也会愿意的,哈哈哈哈,其实测试点点点,本质是端到端的评测,是效率和发现问题最好的方法,也是有价值的。

JoyMao #32 · 2021年12月10日 Author
大话性能 回复

过不了 “造火箭” 的面试(很强能力),是去不了字节点点点的

回复内容未通过审核,暂不显示

无意中看到了大佬关于功能测试的评论,我表示非常赞同,正如国外从始至终认为的一样,功能测试才是整个测试范围内最有价值的部分,可惜由于国内各种内卷,各种对技术的追捧,对功能测试看不起这种风气的流行,着实对测试的环境真的很不友好。为什么大厂都是招测试开发工程师呢,自动化为啥这个 title 逐渐的就没落了,时代在进步,对测试人员的要求越发的高了,不仅要求测试要有测试思维,测试还得懂技术,熟悉技术特性,对项目的质量做出更好的保障,总的来说功能测试的涵盖面非常广泛,个人的测试思维深度,技术深度,决定了质量保障的深度,恰恰这种价值很难被体现出来,每个测试人员的质量标准很难被量化,非常遗憾。

赵晨成 关于 TesterHome 中相关帖子的读后感 中提及了此贴 01月06日 10:30

说实话,本人从业软件测试 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% 优惠金额能正确体现。

单纯从用例设计上考虑测试价值还是不够的

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册