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

JoyMao · 2021年12月06日 · 最后由 今天又是想退休的一天 回复于 2022年09月19日 · 28783 次阅读
本帖已被设为精华帖!

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

共收到 55 条回复 时间 点赞
我去催饭 回复

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

JoyMao 回复

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

我去催饭 回复

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

杨超 回复

是编不下去了吗😂

杨超 回复

信用卡额度这么明显的因素不用考虑吗
另外,也赞成拒绝这种垃圾需求,连用户场景都没交代……大约是预设了很多背景条件,但是都没说出来,觉得所有人都默认明白

是啊 兄弟,信用卡额度这个没编出来

槽神 回复

这个要是测试能直接打回就好了。。。。。。人家产品才是说了算的人。
这个其实是 1 个现实场景中的缩影,就算那个产品经理已经考虑了这种那种场景,但还是有各种场景坑在里面。
需求如果完善的整理好,就该 1 篇 10 页以上的需求文档了,但目前现实是需求工程师这个岗位已经没有了,只有产品岗:只有我要什么就得做什么,负责的还会给你考虑各种情况,不负责的真得测试或者开发深入后,反向推动产品去完善各种场景。

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

JoyMao 回复

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

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

傲气👏

JoyMao 回复

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

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

杨超 回复

不错,用来做面试题了。

JoyMao 回复

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

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

刘晓光 回复

厉害厉害 专业

洄汩 回复

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

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

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

厉害👏

Ouroboros 回复

有意换换工作么?

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

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

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

刘晓光 回复

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

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

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

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

无意中,看到了这个帖子: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
大话性能 回复

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

33楼 已删除

无意中看到了大佬关于功能测试的评论,我表示非常赞同,正如国外从始至终认为的一样,功能测试才是整个测试范围内最有价值的部分,可惜由于国内各种内卷,各种对技术的追捧,对功能测试看不起这种风气的流行,着实对测试的环境真的很不友好。为什么大厂都是招测试开发工程师呢,自动化为啥这个 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 啊 大佬们真的强

你们不考虑在什么环境下测试吗 不应该先考虑怎么沙盒

我去催饭 回复

的确傲气,工作这么多年,还没怎么遇到过直接打回需求的测试·········一般这样子的同学要么就被边缘化了,要么就没了···如果有这么棒的 ‘地位’,那的确是梦想的地方;·

兔子🐰 2022 第一季度 社区活跃用户获奖名单 中提及了此贴 04月11日 17:39

大佬们有提升测试思维的书籍或者相关帖子推荐吗?谢谢大佬

我随便补充几个场景吧:
1.偏用例设计的:信用卡的数量、使用顺序,是不是还要考虑:0 张?N 张?(比如默认招行,OK,如果招行的被关了,或者接口异常,系统要如何处理),整个接口那边的计算逻辑可能都要考虑下改动大不大,比如应收和实收之类。
2.如果是场景思维:如果把这个算法展示给客户,对的,产品是这么要求的,但是要说明为什么,或者是不是有更好的方案,如果你的目的是想说让客户多往余额里存钱,那就要让更多的客户通过这个设计来更多的存入余额,而不止是说算好这个优惠吧。可能开发也实现了这个功能,逻辑也对了,但是并没有很多人来使用余额,那这时候这个功能设计是不是就不够完善了。
3.我个人认为功能测试从需求分析开始介入,从用例设计可能就有点晚,这是我理解的功能测试人的价值,不是针对那个怎么设计 3% 优惠计算对不对的问题。总的来说就是确保产品出去是有意义的、程序正确的、业务闭环的、还有用户体验。

我去催饭 回复

老油条 领教了

杨超 回复

还有如果是扫码支付 多人扫码打开了支付页面 去付款
如果是待付页面 主任再付款 代付人也在付款

JoyMao 回复

门槛低 但是天花板太高了

四海 回复

现在测试都要决定活谁来干了。

liu 回复

这个不用考虑 他就是个假设 考的是思维和经验,这发散范围广的去了。
如果这是一个真实项目的需求,我会把这一张没有写满字的 A4 纸直接甩他脸上,再 Tui 一口唾沫,把他从我的办公室 Cei 出去,然后咆哮一句 “GAY LOSE GUI”。

真的膜拜大佬了,我最佩服的是认准对待问题的几位,👍 👍 👍

这个主题很好,贴地气

膜拜大佬们 很多时候面试的时候被问到测试用例设计就发挥不出来 还是自己积累不够

55楼 已删除

价值不是自己给自己评估的,而是别人愿意付出的,不管是戳戳点点,还是指点江山,通常来说,稀缺性才是决定价值的重要因素,但不是全部。当稀缺性不存在的时候,就回归到了价值交换的层面。

+1 测试新人每天忙于工作,收获甚少,局限在点点点中,整体的测试思维却没有提升,焦虑 ing

每天忙于工作,很正常的。“局限在点点点中”,我们能否点得更快,或点出更多 bug 出来呢,这些都需要测试思维的提升。
或者发一个贴,你在点什么,要怎么样才能更快,也是一种思考呢

简11 回复

平常点点点是为了业务的熟练,思维的提升还是需要自己单独总结的

简11 回复

测试思维没有提升,一直在重复点点点,所以想看点书,搭建一下自己的知识框架和体系,再往这个方向努力。平常有在总结,但由于思维局限,总有我没有考虑到的方面😅

关于测试思维的提升,建议看下《软测之魂》第 2 章,找 Bug 的核心思维与境界,微信读书上有电子书。

简11 回复

Thanks♪(・ω・) ノ❤

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