2020年1月7日，京东由于优惠券设置错误，导致大量产品以0元或者超低价成交，并且发货。网传小家电被薅24万件，损失损失金额高达7000多万。很多网友表示收到货了，在网上晒出到货截图。下面为购买截图：
之后，京东做出关于此事件的说明，将拦截订单，召回发货商品。
网上更是传出京东负责小家电的项目组全体被开除，年终奖金补偿没有，甚至可能还会被京东法务起诉，被问责的消息！
很多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“事故”，有什么感想呢？欢迎留言~