内容提要
- 《Humans vs Computers》其中包含一系列故事,其中有的很有趣,也有的很可怕,这些故事都是人们在软件缺陷和二进制逻辑中能够遇到的
- 现代软件交付是持续努力的过程,它将现实世界中的某些部分进行抽象、简化,并且将其建模成为一个自动化流程。然而,缺乏专业领域的知识、迫于时间的压力以及不完善的信息常常会使我们过度简化现实世界,因此边缘问题就会在这些漏洞中涌现出来
- 鉴于现在有许多软件正在成为我们生活中的一部分,看起来很小的错误也有可能对人们造成严重的影响
- 现在许多软件开发团队似乎与用户端“绝缘”了,以至于他们很难想象到一个很小的错误也会造成严重影响,例如一个小数点显示错误有可能会将用户送进医院
- 希望这本书能够帮助读者同那些遭受我们软件错误的用户进行换位思考,毕竟最后总是用户在付出代价
软件开发者、作家、思想领袖 Gojko Adzic 继《Impact Mapping》和《Specification by Example》两书之后又出版了一本新书《Humans vs Computers》。在这本书中他以讲故事的形式阐述了软件缺陷和软件错误对于人们现实生活的影响,并且提出了一些建议来帮助软件开发者避免这些错误。
这本书的主题可以被概括如下:
我们的生活正越来越多地被软件进行跟踪和监控。在这个美好的新世界里,人们很难应对信息超载的问题。政府和公司正在依靠计算机自动检测欺诈行为、预测各种行为以及进行行政执法。但是,有一些不灵活的自动化程序,往往不会比冰箱聪明多少,它们正在做着能够改变我们生活的决定。计算机会根据指示作出决定,但是这些指示是人制定的,是有缺陷的!结果可能是意想不到的、灾难性的,也可能非常非常有趣。
本书的样章可以点击这里进行下载,并且可以点击这里进行购买(InfoQ 读者在2017 年10 月11 日前购买会有30% 的折扣)。
纸质版书籍可以点击这里进行购买。
Gojko 和 InfoQ 谈了关于这本书的背景,他为什么要写这本书,以及这本书是写给谁的。
InfoQ:是什么促使你写了这本书,你想要通过它解决什么问题呢?
《Humans vs Computers》其中包含一系列故事,其中有的很有趣,也有的很可怕,这些故事都是人们在软件缺陷和二进制逻辑中能够遇到的。有这样一件事,有一个人的个性化车牌给他带来了一个月 2000 次的停车罚款,他也因此而入狱,而他又被自动化假释审查系统提前三年释放。这些警示性故事有望帮助人们预防、避免和减少此类问题在他们自己的工作中所产生的影响。
现代软件交付是持续努力的过程,它将现实世界中的某些部分进行抽象、简化,并且将其建模成为一个自动化流程。然而,缺乏专业领域的知识、迫于时间的压力以及不完善的信息常常会使我们过度简化现实世界,因此边缘问题就会在这些漏洞中涌现出来。例如,围绕微服务构建起来的复杂分布式系统通常需要某种生产监控,用于通过测试数据处理端对端事务,并且在成功检测后删掉这些测试用例。我们很难想象到这样的事情可能会造成严重的损害,有一个例子是,由于负责处理转机航班的航空公司未留任何痕迹地将一名叫 Jeff Sample 的旅客机票删除了,导致了 Jeff Sample【译注 1】被滞留在布宜诺斯艾利斯机场。
回顾整件事,很容易看出这是有人愚蠢地疏忽了一个有效的名字,但这并不能真正帮助一个不得不花几个小时在电话上与旅行社、卡片处理公司和航空公司代表争论的人,以便他能够继续他的旅程。
鉴于现在有许多软件正在成为我们生活中的一部分,看起来很小的错误也有可能对人们造成严重的影响。现在许多软件开发团队似乎与用户端“绝缘”了,以至于他们很难想象到一个很小的错误也会造成严重影响,例如一个小数点显示错误有可能会将用户送进医院。
我想要提高人们对这些问题的认识,并帮助人们通过预防常见的错误来构建更好的软件。
InfoQ:这本书的受众是谁?读者能从中获得什么?
这本书的受众是每一个参与软件交付的人,不论他在其中的角色是什么。参与需求和产品管理的人员将会得到一些关于如何避免典型分析盲点的好主意。参与架构、设计和开发的人可以从中学到常见的过度简化的问题并且能够学会在讨论实现细节的时候提出更有价值的问题。参与测试和质量改进的人能够得到一些可以用于尝试的优秀示例和启发,并且可以了解到一些特定问题的根本原因,以便他们能够在问题出现的初期就解决掉它们。
我所写到的这些问题是完全可预测的,而且是可以避免的,并且现在真的没有理由还出现这些类型的 bug 了。虽然这些问题被编纂到各种软件测试书籍中,但是往往被分类为启发类的书籍,人们常常想不起来去读它。通常情况下,只有测试人员会阅读那些书,鲜有开发者会去关注它们。当然了,囿于时间紧迫人们也不会立刻就能回想起那些分类里的书籍,因此人们总是不断地犯着同样类型的错误。
这就是为什么我想用令人难忘的故事来说明这些问题的原因,无论你在软件交付中扮演什么角色,都将对这本书产生兴趣。故事使得想法始终存在于我们的大脑中。你可能想不起来有哪几种方法会在监控系统时搞砸测试数据,但是你可以记住 Jeff 的示例,这将使你想得更多,并且防止类似的问题再次发生。
希望这本书也能帮助读者从错误中找到更多的共鸣,因为最终我们总是为各种错误付出代价。这本书可以帮你不需要记住任何一种特定的技术就能交付更好的软件。
InfoQ:你将这本书分成了不同的章节讨论了各种类型有关软件的问题,都有哪些分类呢?还有你为什么这样分章节呢?
这本书的第一部分是“人工,但不智能(Artificial, but not intelligence)”,它处理的是决策算法中典型的错误,这是由于过度简化了现实世界造成的。这部分有一些很好的故事,它们解释了双胞胎是如何破坏生物特征检测的,时区混乱是如何造成交通混乱的,以及地理位置 IP 地址映射是如何导致人们被错误地指责为严重犯罪的。
第二部分叫做“世界上不可思议的事实(The surprising facts about our world)”,这一部分讲述了一些奇怪而又奇妙的边缘案例,这些案例打破了看似合理的验证规则,比如有人的名字只有一个字符,或者名字中有太多的字符导致不符合驾照的要求。
第三部分叫做“算法快如食物(Algorithms as fast as food)”,这一部分涵盖了工序自动化中典型的疏忽和问题。这其中包括,算法陷入自我强化的循环,导致股市崩盘;一家 T 恤公司在设计软件初期鼓吹对女性的暴力行为;以及由于银行软件故障,一个澳大利亚男人意外获得了无限的信贷。
第四部分叫做“狂之又狂的技术(Wild, wild tech)”,这一部分讨论了现实世界中的概念,如时间、金钱和数量与计算机中的数字之间的映射存在的问题。这其中就包括了一些故事,比如关于小数四舍五入的误差如何改变了一场选举结果的故事;一个 107 岁的妇女为了上学是如何与当地议会抗争的;以及一张折扣券是如何引发了数百人的摔跤比赛的。
InfoQ:这本书中你最喜欢的故事是哪个?为什么呢?
如果非要我选一个的话,那可能是关于来自洛杉矶的 Robert Barbour 的故事,他想要为他的汽车定制一个车牌。最上边的两个定制文字的选项是 BOATING 和 SAILING,但是 Barbour 两个都不想要,但是计算机表单有三个表单域(第三个可以自己填),并且都是强制要填的。于是,他就在第三个表单中填了“no plate(意思是前两个都不想要)”。之后他的车牌就是按照他所填的选项(no plate)通过审核的。虽然车牌看起来很奇怪,但是 Barbour 决定不去抱怨了。一个月后,他开始收到来自加州各地逾期停车罚款的通知。当一辆违章停车的车辆没有牌照的时候,警官们仍然要开罚单,计算机不会不作反应【译注 2】。官员们需要找一个变通的方案,但是人毕竟是人,有许多人会有和 Barbour 一样的想法。截止到目前,Barbour 每月至少收到 2000 张罚单,他的遭遇已经广受媒体关注。他有几次甚至不得不在法庭露面,解释相关情况。问题变得颇具政治意味,因为所有相关的系统都无法迅速更新,相关部门就发布了一项指导方针,记录没有牌照的汽车为“MISSING”。但是,由于有人的车牌已经是“MISSING”了,同样的问题依旧在上演。
当然了,很容易就能找到原因。用户体验设计人员创建了这些不灵活的表单,需求分析人员没有涵盖没有牌照的汽车的情况,开发人员编写的查询语句将缺失的数据匹配给了有效的条目,而测试人员没有发现这个 bug。回顾整件事,总会有人感到内疚。但更有趣的问题是,为什么会出现这样的问题。
我喜欢这个故事的原因是,它很好地说明了当人们向计算机提供了一段不可用或根本不存在的信息时,会发生什么,所以用户会从中找到其他解决方法。真正的有趣的是,当几个系统需要交换信息,并且它们都使用不同的解决方法的时候。一个系统中的占位符和标记会成为另一个系统中的有效数据,并且错误地进行复制和传播。数据标记的问题可以在很长一段时间内保持休眠状态,不会被人们发现。一旦这些记录开始与有效的信息联系起来,比如某人得到了一个“no plate”的车牌,混乱就开始了。
如果涉及到软件交付的人能够考虑多一下,就能完全避免这种情况的发生。强制放入数据不一定能保持正确性,有时恰恰相反。我经常在打印书籍的时候遇到问题,因为常常需要手机号码才能发送订单,然而我很少填写这类信息。我输入了我的电话号码。但是,在半夜我接到了来自世界各地搞错了的快递员的电话。
InfoQ:最后一章讲的是“逆向猴子规则(Inverse Monkey Rule)”,这是什么?技术人员从这部分的内容中获得哪些建议呢?
我打算用这本书来阐述一些典型的、常见的、令人难忘的故事。然而,我不只是给读者提供一些在喝酒的时候可以讲的有趣故事,我还想给读者留下明确的可操作的建议。这本书的最后一部分结合了所有的故事,提供了一些很好的建议和技巧,并且提供了对计算机系统进行分析、开发和测试的启发。
最后一章的名字来源于Émile Borel 于 1913 年提出的著名的无限猴子定理(infinite monkey theorem)。Borel 提出,如果有无限的时间和无限的尝试次数,猴子们会创作出莎士比亚的作品。Borel 的定理是统计学和微积分的一个很好的例子,但在实际情况下,其中事件发生的概率是无限小的。另一方面,对主题和结果的放大能够给我们一些更有实践意义的东西,在本书中用最少的时间涵盖了尽可能多的问题。“再聪明的人,通过电脑键盘有意识地打字,不出几个月也会敲出像猴子敲出的一样的垃圾内容。”我把这个定理命名为“逆向猴子定理”。
最后一部分绝不是一个完整的测试用例列表或者是一个完整的测试策略,它只是帮你快速消化理解书中的故事。我的目的是让大家在使用其它工具的时候把这本书当做一个检查列表,并且希望能够激发你的灵感想出更多想法。
关于作者
Gojko Adzic是 Neuri Consulting LLP 的成员。他也是 2016 年欧洲软件测试杰出成就奖的获奖者,同时,他还是 2011 年最具影响力的敏捷测试专家奖的获奖者。Gojko 所著书籍《Specification by Example》获得了 2012 年 Jolt 最佳图书奖,他的博客也获得了 2010 年英国敏捷奖中的最佳在线出版物奖。Gojko 是重要软件开发会议的主要发言人,也是 MindMup 和 Claudia.js 的作者之一。作为一名顾问,Gojko 帮助世界各地的许多公司改善了他们的软件交付,其中包括一些最大的金融机构到小型创新的初创公司。Gojko 专注于敏捷和精益的质量改进,尤其是通过实例和行为驱动开发来影响数据映射、敏捷测试和开发规范。
译注 1:由于旅客姓名中含有 Sample(样本)这一单词,所以误被认作测试样本而被删除。
译注 2:当违章停车的车辆没有车牌的时候,计算机会标注为“no plate”,正因为 Barbour 的车牌是“no plate”,所以他会收到那些违章罚款。
评论