创作者 | Shantnu Tiwari

译员 | 核子可乐

方案策划 | 钰莹

本文要跟大伙儿共享的是一个由于编码 / 测试脚本错误而引起严重危害的小故事，与此同时也期待众多研发人员引以为戒，一定要用心测试编码，而且可以是测试脚本也非常值得与一般编码得到一致的关心和高度重视。

文章内容开场，最先注重一句没什么营养成分的空话：一定要写模块测试。

好的，下面就是我的辛酸泪小故事。

可怕脚本盛典

这一段历经产生在周五夜里 17：15。那时候，我正准备下班了共度礼拜天。一位同学忽然发信息跟我说：“是不是你是否还记得昨日写的脚本？它早已取得成功冻结了南美洲好几千部手机，客户早已爆炸了，我们很有可能要丢饭碗。”

內容不长，但我已经觉得恐惧了。肺炎疫情当今，我只是个没有什么确保的业务外包，一旦丢失工作很不便，而眼下最重要的情况是搞清楚这一脚本是怎样冻结好几千部手机的。

我还在一家健康企业的测试自动化技术单位工作中，生产制造的关键设备是一款应用软件，承担协助通信运营商在发觉手机失窃或合同顾客扣费时对机器设备开展冻结。这款应用软件被立即置入在 Android 电脑操作系统以内，因此 客户无法卸载掉。在冻结以后，手机会缺失绝大多数基本作用，包含拔打电话，应用 Wi-Fi 乃至在 Instagram/Facebook 上公布照片……总而言之，只需不续订，手机基本上等同于废了。

这种还算一切正常。大家单位也给通信运营商开发设计了前面，用于查验什么手机将要被冻结。这种方法在室内自然环境运作优良，因为我给自己基本上一己之力担负的这一工程觉得引以为豪。

缺憾的是，一家总公司坐落于韩的手机生产商（这儿大家用化名字其为 K-Pop 企业）尤其喜爱用大家的手机软件，想把这个成效跟她们打马虎眼的 Web 专用工具结合起來。我明白了酬劳，也充足测试过她们给予的测试用例，觉得没有什么难题。

那麼，究竟 是哪里出错了？

早就终究的不幸

大家单位以前刚被风险投资机构回收，她们想尽早让资金投入转现。因此，全部工程的 deadline 都被提早，大家乃至与此同时测试过三款拥有非常不一样规定的商品。

也就是说，大家彻底是在看运气，祷告一切都能成功运作。而后一项测试內容，便是确保在通信运营商根据多部手机提交一个 Csv 文档时，将全部手机与此同时冻结。

我写了一个 Python 脚本，它会转化成一些任意的手机号，登陆至 Web 门户网并冻结手机。以后，脚本登陆至另一门户网并查验結果。如此一来，大家就能用一个脚本测试不计其数的组成，并在这几个钟头以内进行所有测试。

由于大家面临着众多不一样的测试用例 / 情景，因此 这套脚本最后转化成了数十万个任意手机号。

说到这儿，大伙儿需要能够 想起出了什么问题。

因为時间压力大，我没时间也没心情查验脚本品质。编码一写完，我便把他们运作起來。实际上，在按住储存按键的 10 秒以后，脚本就早已在即时生产制造网络服务器上跑开。我实际上 还可以再多测一测，但那般我便得加班加点到深夜。我不愿意加班加点，由于我早已加过许多班，错过了许多礼拜天，我得赶快把事情转手。

因此我运作了脚本，一切正常。顾客方主管确定实际效果与预估相符合，每一个人都很开心。礼拜天一切正常歇息，下周一商品就能发布。

以后我便收到了电子邮件：我们在南美洲不正确地冻结了好几千部手机。

是怎么回事？

以前说过，测试用的手机号是“任意”转化成的；换句话说，这一 Python 脚本会随机生成包括 11 字符的“手机号”。

这种号跟实际中的号码段遇上了！

遭受脚本撰写方法及一些怪异 IMEI 设置（即每部手机的唯一辨别序号）的危害，全部冻结客户都聚集在南美洲。

解决困难

想清晰这一切以后，大家已经下手解决困难。朋友询问道：“你测试时使用过的 Csv 文档还哪里找？”我们可以再度运作脚本，把里边的冻结实际操作改为解封就可以了。

自然……没了！初始脚本被改了，遮盖了，我身上仅有最终一份团本。终究我原以为这就是个一次性的迅速测试，因此 没做准备。

也有另一个解决方案：登陆这个韩 K-Pop 企业并手动式下载列表，但另一方只适用一次免费下载 100 个号，可是我必须免费下载 10000 好几个。

因此，我只有撰写一个脚本专业免费下载手机号，再写另一个脚本清除另一方给予的槽糕 Csv，再用第三个脚本承担再次接入服务器并解封全部受影响的手机。

幸亏朋友伸出援手，因此 大家大概一个小时以上就完成了所有的工作中。到夜里 18：30，大家早已被封了全部手机。一位工程项目经理也确认了工作成效，我松了一口气，并快速逃脱了当场。

学得的经验教训

测试脚本必须像基本编码那般获得关心与维护保养。

不管高管如何考虑到，开发人员都不应该在 deadline/ 髙压下测试重要生产制造编码。（因为我了解，想彻底忽视管理层的命令基本上不太可能；要不照标示干活儿，要不提前准备离开……）

这个 K-Pop 企业权利大——她们的系统软件申请注册全过程非常不舒服，但申请注册以后得到的管理权限却高得吓人，乃至能冻结全世界随意地域的手机。

K-Pop 企业能够 依据 IMEI 序号分辨哪一家营运商“有着”哪部手机，因此 必须担负相对应的法律依据。假如是以 T-Mobile 那里购到的手机，那麼应当仅有 T-Mobile 有权利冻结手机，除非是顾客事后执行完合同义务或是变动营运商。

可是，K-Pop Central 竟然能在了解另一方手机号或 IMEI 的情形下冻结一切机器设备（这两项都不会太难获得，尤其是手机号，终究这也是要公布给予给别人的信息内容）。经验教训便是：好好地做检查，我该查验，K-Pop 更需要查验！

测试应当逐层开展。应当先测试每个部件，而不是立即测试最后系统软件。说起原因，由于大家没那么多時间。

简易测试，换句话说只考虑到“最好状况”的测试还不够。在理想化状况下，大家应当想起也有这些准备故意冻结别人手机的“坏家伙”或是是无赖脚本。这不只是在确保品质，也是在确保安全性。可是大家哪一点都没保证。

大家往往都没保证，是由于大家认为 K-Pop 的手机手机软件会跟大家一样做测试。想不到别人压根不在意，因此 彼此疏忽加起來导致了这场安全事故。

别在工作环境里做测试！实际上 大家有开发设计与上台网络服务器，但都还没连接即时运用（关键遭受時间和员工的限定）。此外，间距商品宣布公布仅有两，三天了，想四平八稳搞测试确实难以。

因此，大家根本沒有汲取一切经验教训。在这里款商品宣布公布以后，大家又重归到槽糕的脚本中，在数据库查询中倾倒垃圾并装作早已“测试”过全部编码。

最后，大家沒有被辞退，这主要是因为大家迅速就解决了难题。

但更关键的是，别的一些工程项目经理和销售经理一直在犯相同的误区——随机生成手机号并冻结真机。自然，她们仅仅手动式实际操作，因此 冻结的只是几部手机；大家用脚本一下子冻结了上一千部。但是最后作用是一样的，大伙儿心知肚明罢了，每一个人都装作这也是个单纯的出现意外。

Reddit/HN 上一部分评价的回应：

我还在 Reddit 和 HN 上见到许多 相近的评价，因此 在这里统一作出回应。

没有错，我明白在测试环境下做测试很蠢。但那时候我必须在三天以后的星期一发布商品，并且沒有一切商量余地。前男友工程项目经理就由于手和脚不足利索被辞退了，全部测试单位都遭遇被裁的风险性。高级副总裁还规定开发人员在每日会议上随时随地汇报全新进展。

我以前也说过，此刻要不按上边的标示作事，要不提前准备卷铺盖走人。要不是新冠肺炎疫情的工作压力，我确实会考虑到换份工作。

为什么不可以在上台 / 开发设计网络服务器上测试？大家没空，也没每人必备让这种网络服务器一切正常见效。早已有多名技术工程师决策辞职，并且公司也意想不到 K-Pop 那样的大企业能冻结这些相隔万里的手机。

针对很多盆友的疑惑：这类实际操作是彻底合理合法的。终究合约机在结清余款以前，手机的使用权实际上 并没有客户那里，公司自然有权利随时随地冻结。iPhone 上就会有内嵌的作用，Android 则必须相互配合外界运用达到一样的实际效果。

尽管如今回忆起来，整件事的确十分愚昧（没有错，自称为技术工程师的我竟然会在生产过程中做测试），但那时候一波又一波的温度令人身心疲惫，压根没空干什么思考或是整体规划。总而言之，这可能是很多人职业发展中史无前例的髙压时时刻刻。

事后升级：在更新了三款商品以后，全部 QA/ 测试单位都被裁掉了。包含我的老板。有意思的是，我由于非常清楚遗留下商品关键点而留了出来。但三，四个星期以往，我一直处在沒有大领导，不清楚该向谁汇报的怪异情况。