拼多多软件测试开发,拼多多事件对我们业务测试的启发-CSDN博客

前几天的拼多多事件大家应该都知道了吧，不知道也没关系，自行搜索关键字「拼多多事件」先回顾一下。

网上已经有很多人从自己的角度去分析这个事件，有人问是不是真的亏了那么多？有人问领的券咋没了？有人猜测这是不是bug营销？当然也有很多人在归纳总结正确的做法。

作为测试人，其实并不想凑热闹，因为很多人说这不是测试的锅，但是想想我们业务其实也时刻存在着类似的风险，所以就基于我们当前业务说说我的思考吧。

一

一定要避免经验主义。

经验主义主要指的是凭经验办事，结论的依据都是个人的经验(如果是龙叔级别的大神，请绕行)。

比如我作为产品角色时，在一个系统的设计中把时间的显示格式设计为 20190122-0101 这种，一方面可以让时间显示的长度变短，另一方面可以避免空格等特殊字符，结果，在系统使用过程中，有不少同学觉得不习惯，因为这只是从我自己的经验出发的设计，教训就是，对于一些大家已经习惯的格式，最好还是从实际用户那获取真实调研信息后再做调整，避免个人经验主义。

比如我作为开发角色时，会给其他人提供一些小工具，有一次因为一个需求变化，要修改一个很长时间没有改动的逻辑，这个工具代码我是很熟悉的，最初实现后也是自测很充分的，所以这次修改就十分的有把握，以至于修改后都没有自测就发给别人用了，尴尬的是，拿过去冒烟就失败了，当时我真是恨不得抽自己几巴掌，作为测试人员在担当开发角色时竟然也犯同样的错，这都是经验主义闹的。

再比如我作为本职的测试角色时，总是在频繁回归或者系统覆盖时，需要不停的去压抑住内心那个「这个用例我已经跑过了，没问题」的想法，因为这些用例确实是在其他的环境中跑过了的没问题的，我特别害怕有一天自己一个不小心就放出了内心中那个经验主义的魔鬼，所以我会经常性的考虑使用工具来代替手工的重复操作。

总结几条个人经验主义需要关注的点：

之前没出过问题，不代表没问题。

有人愿意承担责任，不代表他能承担的起。

尽量不要基于个人经验做出全局的判断。

存在不确定性的情况下，一定要在可控的情况下进行逐步验证。

二

任何涉及到钱的问题都要无比慎重。

很早就有人说过「金钱乃万恶之源」，所以涉及到钱的问题，只有你想不到，没有别人办不到的。

比如我曾经弄过支付宝口令红包的活动，50 个共 50 块的口令红包还不到 5 分钟就被抢完，预期的目标用户只有 2 个人领到，其他的全被薅羊毛了，吓尿了，等我再补上 100 个共 20 块的口令红包后，同样在 30 分钟内被瓜分了，我回查了一下红包领取的数据，发现有好几批都是在同一秒钟被领取的，毫无疑问，都是被薅羊毛的搞走了，佩服。

再比如我有个朋友的一个业务，做任务送现金红包，因为目标群体庞大，所以红包金额一般都是几分钱，都说羊毛党很厉害，所以后台做了一些反羊毛的设定，比如限制次数，限制时间间隔，限制操作来源等等，最后还做了一个万无一失的设定---金额达到 10 元以上才可以提现，因为大家测算了一下，要攒够 10 元得好几年才行，结果你猜怎么着，竟然真的有人还没到一年就攒够 10 块，唉，看来规则妥妥的是有漏洞的了。

所以说，有钱的地方就有人惦记，上面这个说的只是 10 块钱，都能有人来薅，那要是 100 块，甚至 200 亿，就可想而知了。

关于钱方面的风控，这篇文章讲的很清楚了，大家可以点击了解下：

《拼多多给羊毛党发年终奖背后的那些事》

三

必要的流程必不可少。

对于拼多多事件，大家在复盘时也都发现了他流程中的问题，于是有人提出说关键节点应该依赖自动化进行保证，同时也有人说「自动化效率有多高，出事的速度就有多快」，嗯，这个观点有意思。

没出事之前，大家的理解都是利用自动化来提高效率，因为自动化可以准确无误的快速执行指令，那么现在的问题是，如果这是一个错误指令怎么办？

类比下我们的交通工具，飞机飞的快吧，出事概率也很低，但是一旦出事就是大事。

类比下终结者中的天网，人类为了规避人类的弱点，让机器来取代，结果机器不仅想取代人指令的部分，还想完全取代人类。

所以自动化应该是辅助的角色，一些关键的操作还是应该依赖人，比如涉及钱的操作、比如涉及人身和财产安全的操作、比如涉及对其他多数人有重大影响的操作等等。

其实我一直有在推动我们业务流程的自动化，有一次在商量能否优化掉一个审批环节时，碰到一个阻力，他们给的理由是「多一个审核，还是有一定震慑作用的」，听的我一脸懵逼，当时竟无言以对。

现在想想，似乎有那么些道理。