价值400亿的Bug为什么会发生？
事件背景
日本公司J-Com在首次公开上市的日子就爆炸式地损失了超过400亿日元的天价损失，虽然日元那面额画得跟冥币似的，400亿日元也还是相当值些银子滴(按照当时的汇率，约为人民币27亿元)。
事件的大致经过是由于一位操作员在离开盘还有几分钟的时候接到了一位客户“以61万日元的价格，卖出1股J-Com的股票”的委托，而田中君在接到委托后在交易终端上错误地输入了“以每股1日元的价格，卖出61万股”。
至此，大家可想而知，事件继续发展下去会是怎样的灾难。但是，幸运的是在2分钟后，田中君发现了这个错误，他立即试图通过交易软件撤销这笔卖单，而不幸的是，由于交易系统的bug，田中连续三次的撤单指令都被拒绝，而此时盘口交易已经开始，此刻市场内当然是一片打乱，而最后，当然便是以瑞穗证券
遭受的超过400亿日元的天价损失收场。
事后，J-Com将交易软件的开发商----富士通告上法庭，而通过漫长的诉讼加上控辩双方找来资深程序员和工程师进行撕逼大战，最终因为对Bug检测程度的深浅没有一个明确的评判标准，所以富士通并不需要去赔偿J-Com的损失。
事件到这里暂告一段落，虽然这次事件是由一个操作员的乌龙指引发的，本来此次事件可以有一个更好结果，但是由于多方面的因素，导致J-Com并没有挽回一丁点儿的损失，在唏嘘的背后，到底是什么吞走了这“400亿”巨款呢？
首先，在业内没有企业敢保证自己开发的应用不存在任何的Bug，因为Bug在理论上是测不完的，任何应用都可能存在或多或少的Bug，同时，在Bug出现之前，也没有人能够去准确地判断其可能带来的损失，它是不能被评估的。虽然不能将Bug完全排查，但是我们也应该去建立一个Bug检测是否充分的标准，旨在尽可能地去检索排查应用中可能存在的Bug，在最大程度上减少损失。
再加上整个应用开发的过程中，传统测试流程带来的高成本，低效率也让众多企业不愿意花过多的精力放在这上面，他们还是希望自己的应用快速上线，从而获得收益。
其次，从这次事件中可以发现，在法律层面，对于Bug是否是重大过失的这个判断标准并没有被明确化，纵使专家组进去控辩双方进行争论，对于法官来说依然是懵圈儿的，因为它本身就无依可循，无章可据。
因此，在这类事件发生后，根本没有人能够去做出一个明确的判断，而往往事件发生后就控辩双方就会被揉作一团，责任的划分便是模糊不清，最终提供应用的企业几乎不会去赔偿由于Bug而造成的损失，那么就是经历了伴随漫长的上诉过程，其实对最终结果并没有多少太大的影响。
由于这些空隙的存在，才会让众多企业有机可乘，钻这些空子。毕竟对于企业来说，盈利才是最主要的目的，而且就算因为自家应用的Bug给用户带来了损失，企业也可以很轻松地去规避一些惩罚，逃脱一些责任，这让许多企业更是肆无忌惮地忽视Bug的检测，从而遗留了许多隐患，这些无穷后患就可能造成下一个“400亿”损失。
而除了Bug检测标准的模糊化，企业本身对于用户负责任的态度也是非常欠缺的，其实具备这种负责真诚的创业态度，才是让企业走得更远的基础。
再往深了分析，致使这些发生的根源笔者觉得其实很简单，就是行业内没有一个对于Bug是否测试充分的标准，一旦这样的标准被建立起来并且作为一个最主要的责任判断依据，那么再次出现此类事件，下一个J-Com就很可能获得赔偿，并且在法律因此能够设置有一个明确的裁定标准之后，各开发企业也将不会继续肆无忌惮地去忽视应用中Bug 的探索检测，因为他们很可能为自己一时放纵而遗留的无穷后患买单。
同时，这种标准的建立也实质上是一种业内的规范与约束，在这种约束下，我们虽然不能保证Bug的完全消除，但是可以尽量地去规避Bug可能带来的损失，同时企业的责任感也会被慢慢建立。
说了那么多，那这种标准的建立应该如何进行？笔者不谈妄谈，因为这需要全行业的努力，但是，有一点必须要明确，这个标准的建立必须由一个公正中立的第三方机构进行，譬如说政府、行业协会，或者就是一个技术水平领先、测试经验丰富并且等到业内公认的第三方公司。
虽然对于产品质量的重视程度也在随着行业的不断成熟在不断增强，然而目前大多数企业都把重心放在产品的研发和运营上面，测试（或者说质量管控）的地位始终比较边缘，造成了移动互联网行业中没有一个专业的针对测试技术及人员的行业协会组织存在，更不用提政府这个层级规范和要求了。
任何一个行业，一套标准的建立往往是在第三方产配套产业随着行业的发展也不断成熟后才会出现，且需要整个行业进行配合与支持。
目前移动互联网产业已经陆续出现了多家成规模成体系的第三方测试服务公司，譬如国内的TestBird，国外的Testdroid等等，建议这些公司完全可以牵头建立这套体系，利己也利于整个行业。
从目前来看，条件也是成熟的，一则如前说述，第三方服务已经成熟，二则从2015年开始，移动互联网产品在经过百家争鸣后现在也愈发成熟并重视产品质量，三则第三方公司的技术实力和经验已经有相当体量的积累。
譬如TestBird就曾在其2014年的手游白皮书中第一次明确定义测试问题的类型及名词解释，可能是限于当时的特殊情况，令人遗憾的没有更深入一步，确定“好产品”的标准。虽然如此，但有这种标准建立意识就是一个很好的指向，只是可惜整个行业响应不大。
其实，无论企业将测试视为多么微小的环节，它依然是整个行业链中的一环，若是希望整个行业能够发展得更成熟，那么一环一扣都应该施以足够的重视，何况Bug的测试是可能带来巨大损失的环节。
因此，笔者呼吁那个第三方企业能够站出来，同时业内给出积极的响应，最后再由政府给予大力的支持，共同做出努力去规范这个环节，尽可能地去规避这“400亿”的损失。
近期热文
邀请你加入程序员微信群。
添加小编拉你入群，微信：szweican（请备注：职业，如 java）
请长按二维码添加小源微信。