救救自己，下次生产测试别再写Test了！

6月1日是一个小朋友的节日也是很多测试人员的“节日”，随着疫情后的第一个正式促销活动618的临近，为了“平峰”（避免大家都在618当天下单导致的大流量冲击，将活动流量分散到这18天）6月1日起已经拉开了促销的序曲，而与此同时各种翻车的场面开始进入了我们的视野，按照我们的老话叫做，你也是个成熟的软件了就不能成熟一点么？

“以下内容极其舒适除了测试”

这个Null空难道不应该出空指针错误么？

好诚实的测试，买了怎么办？

当然这类事情在以前也经常出现，例如：

对于这些还算是小问题，不过是测试数据推送到了客户，但是下面的这些就属于大型翻车现场了，真金白银。

历史上的某一天

拼多多在20日凌晨出现漏洞，用户可以领100元无门槛优惠券。一夜之间，被黑产、羊毛党和闻讯而来的吃瓜群众薅了个底朝天，直到第二天上午9点才将优惠券下架。网上传言这一波损失超过200亿，但拼多多官方很快回应：漏洞确有此事，但损失没这么多，不到千万，已报警，正在追回。

当然盒马，JD都有类似的无门槛优惠券意外流出的情况出现，到底为何会出现这些问题呢？

1. 因为在测试环境上无法模拟所有的情况，而且构建Mock十分复杂，所以必须要通过生产测试来验证。

2. 缺乏对生产测试的隔离能力，灰度发布能力不够，历史技术债导致无法有效的通过白名单机制隔离测试数据和生产数据。

3. 缺乏对业务风险的评估和判断能力，过分乐观和自信（认为半夜更新用户不会访问或者下单）

4. 缺乏对系统高危情况的风控（例如大批量交易，同一账号同一商品的不正常批量成交）

5. 缺乏基本测试应该注意的技巧在这些问题上与历史的“切尔诺贝利”事件颇有几分相像，做个测试想当然，而忽略了可能导致的后果。

那么如果现在要做线上的推送测试，怎么做才能好看呢？

试试看把推送信息“测试test内部测试”这类的文字改成“618全场折扣即将疯狂进行，让你心仪的商品省一点再省一点”，是不是无论是不是翻车，都能达到看到的心花怒放，没看到的也毫无影响呢？

所以下次做生产测试的时候别写“Test”了！

长

按

关

注

TestOps公众号

微信号 : TestOps

新浪微博：@TestOps官方微博

知乎：TestOps-云层