亲宝软件园·资讯

展开

一个由"2020年1月7日 京东出现的重大 Bug 漏洞"引起的思考...

豆姐姐 人气:2

2020年1月7日,京东由于优惠券设置错误,导致大量产品以0元或者超低价成交,并且发货。网传小家电被薅24万件,损失损失金额高达7000多万。很多网友表示收到货了,在网上晒出到货截图。下面为购买截图:

之后,京东做出关于此事件的说明,将拦截订单,召回发货商品。

《关于2020-1-7,大量0元单活动说明》

尊敬的京东用户大家好,因为1月7日优惠券设置错误原因,导致大量产品以0元或者超低价的情况下成交,并且发货。

目前对此京东已经做出处理方案。

1,针对未发货的订单,京东已经做拦截处理,并且后续不会发货。

2,针对已经发货的产品,京东已经做出拦截处理,商品将会召回。

3,针对部分已签收的订单,如果您满意手中的产品,可以按照原价的8折购买,如果不满意请直接取消,取消后配送员将在24小时内上门取回商品,感谢您的配合。

因为这次错误给您带来的抱歉,京东深感歉意,所有被召回或者拦截的订单,处理成功后系统会自动为您发放一个20元的无门槛优惠券,作为赔偿。

感谢您对京东的支持,提前祝福各位新年快乐。

 

网上更是传出京东负责小家电的项目组全体被开除,年终奖金补偿没有,甚至可能还会被京东法务起诉,被问责的消息!

很多IT从业者表示职业高危性,因为一个“不小心”,就天降“重大bug”,公司遭受重大损失,个人面临赔偿甚至坐牢的风险。

 

 

这里不由得让我想起去年1月20号凌晨“拼多多薅羊毛事件”,同样是优惠券的bug,用户可以直接领取一个无门槛的100元优惠券,全场通用(特殊商品除外),有效期一年。羊毛党半夜被同伴叫醒开始疯狂薅羊毛。

之后,拼多多于20号上午9点左右把100元无门槛优惠券全部下架,之前领到未使用的优惠券也全部下架。并官方回应称,此事系黑灰产团伙利用平台漏洞进行不正当牟利,公司已第一时间修复漏洞并向公安机关报案。网传这起薅羊毛事件导致拼多多预计损失200亿。

 

 

时间再往前回到17年,有网友爆料支付宝存在一个漏洞,陌生人有1/5的机会登录你的支付宝,而熟人则可能100%登录你的支付宝。

方法是这样的:登录手机账号——忘记密码——手机不在身边——淘宝买过的东西9张图片选1个——好友验证9个好友图片选1个——重置密码——登录成功。

登录成功后拥有支付宝的全部功能。支持免密支付。甚至直接扫二维码付款不用密码。

从支付宝改密码的步骤,像通过熟人、最近购买过的商品验证,就存在很大的不安全性。对于熟人、甚至只是微信好友中的陌生人,获取这些信息很容易!!

之后支付宝针对此事做出回应:

后面有网友做出尝试,发现依据网传方式确实已经无法找回登录密码了。也就是说支付宝已经升级系统,修复了这个漏洞。

 

启示

以上的bug“事故”也只是因为一场热搜,被广大网友所熟知。实际软件出现的bug“事故”要多得多,有些被及时修复未被暴露到公众视野,有些暴露了只是未引起重大反响。回顾以上的这些软件“事故”,无论是运营事故,还是测试事故。在实际工作中,关于责任归属,相干利益,开发/测试/运营/风控可能都跑不脱。那作为专业的软件测试工程师,如何更有效地避免各个环节出漏子,于是有了以下思考:

  • 具备过硬的专业技能,让测试工作“无可挑剔”

作为一名专业的软件测试工程师,不能因为测试技能不到位导致bug“事故”。我们首先要保证的是本职工作的严谨及无可挑剔,因此需要具备:

软件测试技能:测试流程、bug管理流程、计划/用例/报告编写、linux、数据库、相关测试工具使用;计算机网络知识、定位问题及分析等;

编程能力:例如java、Python;尽可能了解开发代码的实现逻辑,代码设计及结构、数据库结构;

产品的业务知识及行业背景:除了业务本身之外,多了解整个行业背景,竞品分析;依据不同的业务采取不同的测试策略及方法

  • 跳脱传统岗位职责,多立于产品设计思考

像以上的支付宝bug,并不能说开发实现逻辑或测试覆盖上存在纰漏。而更多可能是安全等级设计上的不完善。

我们90%以上的测试工程师一切以产品为尊,完全按照产品需求进行测试。这样错了么?貌似没错。但“测试相当于半个产品经理”不能只为一句空话,要多立于产品设计本身去思考,去怀疑!

用户权限需要多层控制吗?这样设计会不会暴露安全性问题?操作步骤对于小白用户来说是否太繁琐?敏感信息是否需要加密处理?毕竟产品经理或是开发人员并不是什么都能想到,且面面俱到的。

  • 提前预见“手残”行为,提升安全风险意识

像京东的bug,也许可能只是运营的一次“手残”行为,优惠券设置错误了。但因为损失过大,作为测试的我们也难辞其咎。作为一名专业的软件测试工程师,尤其是涉及钱的产品,我们可以尽量去预见下可能出现的”手残“行为,然后多考虑如果”手残“了,咱们的系统是否具备应对”手残“结果的处理能力。

比如像这次的优惠券bug,是否设定无门槛金额提醒?是否设定界面自动化巡检功能?是否对数据异常进行监控并设定报警机制,同时是否具备及时撤销功能...

  • 基于用户行为,加强α、β测试

像很多问题,是需要特定的用户场景才会出现。当专业的测试团队在测试时,会受到一定的用户使用场景的限制。测试人员局限于用户个体,自然不会预想到所有用户出现的真实场景。

这个时候,α、β测试可以让大量真实用户参与其中,通过“人海战术”人为地遍历更多真实用户使用场景,并实时反馈真实场景中出现的bug。

这样当产品正式发布后,可以提前规避掉很多用户可能会碰到的问题。但这种测试方法,要基于产品本身数据安全性去做把控,不一定适用。

 

大家通过这次的bug“事故”,有什么感想呢?欢迎留言~

加载全部内容

相关教程
猜你喜欢
用户评论