程序bug導致了天大的損失，要槍斃程序猿嗎?(3)

　　本來，程序修改后必須經過嚴格的回歸測試，來驗證對其他業務流程有沒有影響?？墒遣粌H富士通忽略了這個測試，東京證券交易所在系統驗收測試(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