程序bug导致了天大的损失，要枪毙程序猿吗?(3)

　　本来，程序修改后必须经过严格的回归测试，来验证对其他业务流程有没有影响。可是不仅富士通忽略了这个测试，东京证券交易所在系统验收测试(UAT)的时候，也疏忽了这方面的内容。结果，炸弹在这个时间点被引爆了。(下图是包含了bug的cobol代码)

　　围绕着这个事实，第一个争论点是：东证和富士通，应该为瑞穗证券的损失负责吗?

　　起初，东证还想耍赖，把错误全部推在富士通身上。东证主张：就算是交易系统的bug导致了瑞穗证券的损失，那也是富士通的错。因为我的系统需求里面，是明确规定了可以撤单的。富士通开发的程序没有符合我的需求，才导致了这样的结果。

　　对于东证的这个主张，东京地方法院判定：这个系统的主要责任人是东证。富士通只是东证的系统供应商，属于连带责任人。无论是主要责任人还是连带责任人，如果被证明犯有重大过失，都应该做出赔偿。

　　那么，程序的bug算是“重大过失”吗?这很难说。一个系统里有没有隐藏的bug，是没法从理论上证明的。就算是测试再彻底，也会有测不到的bug流出来。所以在法律上，通常不会把所有因为bug导致的损失都归罪给程序开发商。否则的话，世界上最大的bug生产商——微软，早就赔得连内裤都不剩了。

　　这就带出了本案第二个争论焦点：什么样的bug才算是“重大过失”?法院给出了判断的标准——这个bug是不是很容易被发现。

　　于是，控辩双方都找来了由资深程序猿和攻城狮组成的砖家组，在法庭上撕成一团。

　　穗瑞砖家组：卧槽，这个bug简直太明显了好么?连这个都测不粗来，请问贵司人员的编程，都是音乐老师教的吗?

　　富士通砖家组：異議あり!这么复杂的条件组合，你特么能一下子就找出bug来啊!你们败吹牛逼了行不行!

　　双方的砖家团吵来吵去，谁也说服不了谁，干脆，在法官面前开始review起程序代码来了。

　　而此刻的法官，表情是很镇静的......

　　但是在法官的心里，简直有一万匹草泥马奔腾而过啊!

　　争辩到最后，一脸懵逼的法官表示：你们说得好像都挺有道理的......但是意见相反，所以也不能判定成容易发现.......富士通就不用赔了!

　　最终，东京地方法院判定：程序bug并不能算是重大过失，由这部分导致的损失无需赔偿。但是，在瑞穗证券电话联络东证交易所后，东证未能履行中止异常交易的职责，属于重大过错方。另一方面，事情的起因是由于瑞穗证券的乌龙指，所以瑞穗证券也不能完全免责。从电话联络那个时间点以后产生的损失，由东证承担 70%，107亿日元。

　　瑞穗证券和东证都对这个审判结果表示不满，上诉到东京最高法院。2015年9月3日，东京最高法院驳回上诉，维持原判结果。长达10年的诉讼终于尘埃落定。

　　(四)深远影响

　　看到这里，程序猿和攻城狮应该是松了一口气吧，终于不用为自己写的bug而买单了。

　　但是且慢!根据这个判例，“bug是否很容易被检测出来”这一点，将会成为今后类似诉讼的判断基准。一旦被判定成重大过失，程序猿们可真是欲哭无泪了。

　　现在问题来了：身为程序猿，谁也不能保证自己的代码里没有bug。该如何做，才能避免陷入到这种境地中呢?

　　雷子觉得，既然无法从理论上证明程序里所有的bug都被检测出来，那么，一些行业内公认的指标，例如测试时的case密度，bug密度等，很可能会成为测试是否充分的判断依据。(对，就算没有bug我们也要制造出来!)

原文转自：http://www.testwo.com/article/624