网友点击排行程序bug致损失400亿，判程序员坐牢？ 搞笑我们是认真的 - CSDN博客
程序bug致损失400亿，判程序员坐牢？ 搞笑我们是认真的
号外！号外！走过，路过，不要错过！日本 IT 业的狗血八卦继续独家放送啦！！2015 年 9 月 3 日，随着东京最高法院驳回瑞穗证券的上诉，维持二审的原判结果，一个长达 10 年的诉讼终于画下了句号。这个判例将对 IT 行业产生深远的影响：如果程序的 bug 导致了巨大的经济损失，应该由谁来承担？用户？运营商？还是系统开发商？&Bug：计算机程序里的错误今天故事的主角是，瑞穗(みずほ)证券，东京证券交易所(下文简称东证)，和富士通。各位富士通的同学，雷子真的不是富士通黑啊。你们公司行业内第一，项目多，所以卦点就多啊！要是又一次伤害了你们的感情，看下图能原谅我不……嗯，该说的也都说过了，下面正式开始。（一）瑞穗证券的乌龙指事件如果时光能够倒流，让瑞穗证券的交易员田中君(化名)穿越回&2005 年 12 月 8 日东证开盘前的那几分钟，田中君会不会选择把自己那根乌龙指给掰断呢？乌龙指(fat finger)：是指股票交易员、操盘手、股民在交易的时候，不小心敲错了价格、数量、买卖方向等。正是由于田中君的一次错误输入，让他所在的瑞穗证券遭受了超过 400 亿日元的天价损失。虽然日元那面额画得跟冥币似的，400 亿日元也还是相当值些银子滴(按照当时的汇率，约为人民币 27 亿元)。这天，是日本公司J-Com 首次公开上市(IPO)的日子。上午9:27，距离开盘还有几分钟。田中君接到一位客户的委托：“以 61 万日元的价格，卖出 1 股J-Com 的股票”。田中君接到委托后，在瑞穗证券的交易终端上，错误地输入了“以每股 1 日元的价格，卖出 61 万股”。指令发出后，瑞穗证券的交易软件检查到这是一个异常的交易订单，给出了一个警告的对话框。可是，像瑞穗证券交易员这种级别的操盘手，玩的就是不按套路出牌，每天这种警告对话框见得太多了好么。田中君甚至都没有好好读一下对话框里的内容，就按下了确定按钮。于是，这个巨大的卖单就挂在了东证的交易盘口上。2 分钟后，田中君发现了这个错误，赶紧试图通过交易软件撤销这笔卖单。可是连续输入 3 次撤单指令，都被东证的交易系统拒绝了(后来查明是由于交易系统的 bug 所致)。田中君又迅速给交易所的负责人打电话，要求将这个卖单撤下。交易所的人表示：“我们无权操作，这个问题只能你们自己想办法”。这时盘口交易已经开始。这个巨大的卖单首先将开盘价定在了 67.2 万日元，然后又依次将所有买单成交，最终将J-Com 的股价钉死在跌停价 57.2 万日元上。（与天朝不同，日本的涨跌停价并不是严格的按照 10% 来计算，而是根据开盘价确定出一个整数的价格范围）此刻市场内一片大乱。散户们被这个巨大空单吓得惊慌失措，以为J-Com 公司出了什么问题，纷纷跟风抛售。而一些机构和大户已经猜到是出了乌龙指，迅速在跌停价买进。一些有节操的机构，例如德意志证券，买了几手后觉得实在是太不厚道，自觉停止了抢购。而大部分机构纷纷表示：节操才多少钱一斤，有便宜不占王八蛋啊！抢得不亦乐乎。可能有同学不太懂股票交易，大概就是下面这种赶脚。本来，客户的委托是下面这样的……然而，手残的田中君把数字输入错了……但是，股票价格有涨跌幅限制。所以页面发布以后，系统又自动把价格改成了下面这样……就算是 57 万，也是非常便宜了好么！大妈，不，大户们迅速围观，争相爆买……在股市这个游戏规则里，只要你卖出的股票有人接了，那成交后就必须把货交给买家才行。可是，J-Com 的股票一共才发行了 14000 多股，大部分还由公司高管持有，真正在市场上流通的也就 3000 多股。61 万股，让瑞穗上哪里去弄？总不能自己在家里画啊！没有办法，瑞穗证券只好发出了反向买入的决定，开始和其他人一起抢购筹码。这样一来，J-Com 的股价又被拉高到涨停价 77.2 万日元，一直持续到当天的交易结束。在当天的交易中，瑞穗证券一共损失了约 270 亿日元。受到影响的不仅仅是J-Com 的股价。瑞穗证券直到当天收盘后，才向外界披露了这一乌龙指事件。而在当天的交易过程中，市场上已经有传闻，一家证券公司搞出了乌龙指，将有重大亏损。由于不知道是哪家券商出了问题，所有券商股票都惨遭抛售。这下证券公司都哭了，纷纷发表声明：股东老爷们，真的和我没关系啊……然并卵。其中最惨的是J-Com 上市的主要发行商——日兴证券，股价一度狂跌了8%。而这股不安情绪也影响了所有投资者。当天收盘时，日经指数大跌了 301 点。（二）事后收场首先是成交单的交割问题。不存在的股票怎么交割啊？虽然瑞穗证券通过回购，抢回了大部分的卖单，但还是有 9 万多股被其他机构和散户买走了。根据规则，瑞穗必须在 3 天之内交货(日本的交割日是T+3)。前面说过，市场上一共才流通了 3000 多股J-Com 的股票，这 9 万多股真是逼死瑞穗证券也拿不出来啊。&最后经过协商，买卖双方同意用现金来结算。清算的价格定在了每股 91 万日元——这是瑞穗证券敲下乌龙指前一刻的股票价格。这次现金交割又让瑞穗证券雪上加霜，损失扩大到 400 多亿。至于当事人田中君，似乎并没有受到太严厉的惩罚。瑞穗证券至今也没有公布当事人的真实姓名，只知道是一名男性证券经纪人。事件发生时，正赶上日本公司要发年终奖。就因为田中君的一个错误操作，一下子把公司一整年的利润都给干掉了，让瑞穗证券所有员工的年终奖都泡了汤。有传闻，田中君成了瑞穗证券里“最讨厌的人排行榜”的 No.1。那些趁火打劫的机构大户也受到了指责。事后查明，共有 22&家机构在此次乌龙指事件中获利。其中瑞士银行，摩根斯坦利，日兴证券，雷曼兄弟，瑞士信贷，野村证券这六家机构，从这次事件中一共瓜分了 168 亿，占瑞穗证券损失的 40% 还多。尽管这钱来的不太光彩，可毕竟是按照市场规则赚来的，所以金融监管部门只能从道德层面对这些公司进行谴责而已。有人提议，让这些公司把赚到的钱吐出来。这些公司表示：这样做，等于把公司的利润白白送给别人，没法向自己的股东交代啊。后来在各方的调节下，一部分获利的证券公司同意把钱拿出来，成立一个保护投资者利益的基金，这是后话了。在这次事件中，东证交易所受到了最多的质疑。首先瑞穗证券在意识到错误挂单后，曾经多次发出取消的指令，但都被交易所的系统所拒绝，这显然不符合系统的交易规则。其次，在瑞穗证券与东证负责人取得了联系的情况下，东证方面仍然放任这笔卖单继续执行，有监管不力之嫌。事后，东证社长鶴島琢夫引咎辞职。瑞穗证券方面认为，正是由于东证的过错，才让自己蒙受了 400 亿日元的损失。这个错误理应由东证来买单。东证的观点是：你自己乌龙指敲错了指令，凭啥赖在我身上？对此，瑞穗证券回击：取消交易指令发出之前的那段时间，产生的损失自己认了。但是还没成交的卖单为啥不让人家撤销？两个公司之间扯来扯去，也没把这个问题谈拢。于是，2006 年 9 月，瑞穗一纸诉状，把东证以及交易系统的开发商——富士通告上法庭。就这样，漫长的诉讼开始了。（三）法庭诉讼对于这个案件，事实已经很清楚了：由于交易所的系统 bug，在特定的条件下，会发生不能撤单的现象。经过详查得知，这个 bug 是富士通的技术人员在 2000 年某次程序修改时，不小心埋进去的。本来，程序修改后必须经过严格的回归测试，来验证对其他业务流程有没有影响。可是不仅富士通忽略了这个测试，东京证券交易所在系统验收测试(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 我们也要制造出来！）此外，bug 对应得是否充分，也会成为判断的重要基准。一个 bug 被发现后，有没有进行深刻的挖掘也是很重要的，即所谓的“横展開”。看到这个词，估计很多同行会做噩梦吧！这个话题很大，雷子今后另起文章和各位同行探讨。还有一点不要忘记，无论是测试结果也好，还是 bug 的对应结果也好，　　要留证据！　　要留证据！　　要留证据！　　重要的事情说三遍。&本案也让东证认识到，旧交易系统的老朽化以及 bug 过多等缺陷。随着近年来程序化交易的盛行，旧系统已经越来越无法满足现代证券交易的需要。比起伦敦和纽约等地的证券交易所来，当时东证系统的响应时间要慢 100&倍啊。以瑞穗证券乌龙指事件为契机，导出了 2010 年金融行业的重大项目——东证次世代的交易系统“arrowhead”的构建。这个新系统，依然由富士通负责开发。法庭上撕得面（ji）红（chi）耳（bai）赤（lian），回过头来该干啥干啥——东证和富士通，还真是一对好基友啊！
本文已收录于以下专栏：
相关文章推荐
号外！号外！走过，路过，不要错过！日本 IT 业的狗血八卦继续独家放送啦！！
2015 年 9 月 3 日，随着东京最高法院驳回瑞穗证券的上诉，维持二审的原判结果，一个长达 10 年的诉讼终于画...
传说中的《程序猿装B指南》，程序员童鞋们请认真学习
一、准备工作
“工欲善其事必先利其器。”
1.电脑不一定要配置高，但是双屏是必须的，越大越好，能一个横屏一个竖屏更好。一个用来查资...
这几周《非诚勿扰》来了不少IT男，而且来自硅谷，这触发了大家对程序员的好奇心，其中主持人孟非读的一首诗堪称经典，我载下来，大家来吐吐槽！
       举头望明月，低头写程序。   &#...
我收集了很多编程语录，基本上都跟程序员的生活有关。这些语录涉及软件开发，代码维护，调试纠错，软件bug，系统设计、文档，代码质量，测试和软件开发团队管理等方面。下面的这59条语录虽然很搞笑，但却真实无...
程序源代码中的注释经常是一个卧虎藏龙的地方，来看看这一辑国外某公司产品中的注释。注意：看的时候严禁喝水或进食。亲爱的代码维护人员：当您尝试优化这段代码但发现这是一个极端错误的决定的时候，请修改下面的计...
我收集了很多编程语录，基本上都跟程序员的生活有关。这些语录涉及软件开发，代码维护，调试纠错，软件bug，系统设计、文档，代码质量，测试和软 件开发团队管理等方面。下面的这59条语录虽然很搞笑，但却真实...
某些公司， 偶尔会故意出一些刁钻的没有任何意义的笔试题目来为难大家， 我们就不要生气了， 也来搞笑一下吧,
笑一笑， 十年少。
       程序如下：
int main...
获奖作品：我对你的爱是一个没有条件限制的“爱”这个自定义类的集合，集合里的每个元素都是你的专有属性：你的微笑，你的习惯，你的任性，你的幼稚，你的勇敢，你的乐观等等。集合将永不间断地接受着从你那数据库传...
勤劳的花心龟日复一日的经营着自己的农场，投注了自己毕生的心血。但是让他心碎的是最近暴雨连连，农场也受到波及，很多区域都被淹没了。
       已知农场可以用MXN的矩阵表示(1
     ...
他的最新文章
讲师：何宇健
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)一个bug引发证券业400亿天价损失,程序员都懵哔了
编辑：周建平
[导读]今天事件的程序猿哥哥呢我们先叫他凌八哥好了凌八哥是一个苦逼的富士通程序员整天帮公司给甲方开发一些
一个bug引发证券业400亿天价损失,程序员都懵哔了
今天事件的程序猿哥哥呢
我们先叫他凌八哥好了
凌八哥是一个苦逼的富士通程序员
整天帮公司给甲方开发一些
没什么新意的软件
有一天他接到了一封起诉书
哎哟我天，
长这么大连情书都没收过！
竟然收到起诉书！
然而凌八哥就是这么倒霉
偏偏就贪上了大事了
用这个软件的人
是日本瑞穗证券的一个交易员
我们先叫他寿参君好了
是J-COM公司上市的日子
寿参君接到一位客户的委托：
&请以61万日元的价格，
卖出1股J-Com的股票&
这种本来很基础的操作
结果寿参君硬是在系统上输成了
&以每股1日元的价格，
卖出61万股&
你说你怪谁？
发生这种事你还能怪谁？
大家有没有遇到过这种事
跟微信发红包有点像
有时候你想发61个1块钱的红包
您觉得这篇文章：
相关阅读：
[责任编辑：周建平]
吉和网版权及免责声明：
①凡本网注明来源：“吉和网”或“东亚经贸新闻”的所有作品，版权均属于吉和网或东亚经贸新闻，未经吉和网或东亚经贸新闻协议授权不得转载、链接、转帖或以其他方式发表，已经吉和网或东亚经贸新闻授权的媒体、网站，在使用时必须注明来源“吉和网”或“东亚经贸新闻”。
②如本网转载稿涉及版权等问题，请作者来电或来函与吉和网联系，我们将及时处理解决。联系方式：
Copyright (C)
长春羿尧网络股份有限公司版权所有
吉ICP备号-2 吉B-2-4- E-mail：400亿：一个Bug引发的血泪史 谁来负责？
查看: 3914|
评论: |原作者: 鲁畅|来自: ZOL
摘要: 每一个程序员的一生都会面临无数个Bug。这些程序员们痛心疾首错误，可能会造成多大的损失？又有多少程序员的上班时间都花在找Bug上面？不管花了多少时间，和下面这个真实案例相比，你花在找Bug上面的时间，都不算长 ...
每一个程序员的一生都会面临无数个Bug。这些程序员们痛心疾首错误，可能会造成多大的损失？又有多少程序员的上班时间都花在找Bug上面？不管花了多少时间，和下面这个真实案例相比，你花在找Bug上面的时间，都不算长，因为谁知道你这一辈子能不能赚够400亿（哪怕是日元，现在折合人民币为：23.96亿元）。程序员的日常（图片来源于网络）　　事件发生在十年前，一家证券公司（瑞穗证券）因为乌龙指（手误）致使“以61万日元的价格，卖出1股J-Com的股票”错误的写成了“以每股1日元的价格，卖出61万股”。其中的变化不亚于任何一次“双十一大降价”。　　但这似乎和程序员还没有关系，问题在于，当乌龙指发现这个错误并试图改正时，发现了一个Bug：撤销指令无法执行！所以这个本来两分钟的“大甩卖”，最终成为为期一天的“撤店狂甩”。包含了Bug的cobol代码（图片来源于网络）　　于是，瑞穗证券损失了约270亿日元，而这次乌龙引起的市场震动，还不仅仅这一家，很多证券公司都受到牵连。而瑞穗证券也因为最后的现金交割让其所遭受的损失扩大到400亿日元！如此一来，瑞穗证券将全年营收都赔了个精光，也不得不取消了所有员工的年终奖……无论如何，这个本来能够避免的损失，因为一个Bug而成为事实，瑞穗证券咽不下这口气，在交涉无果后，于2006年一纸诉状将系统承包公司东证和系统开发商富士通告上了法庭。对战公庭（图片截自“复仇法庭”）　　经过近十年的厮杀，日本法院给出了判决：程序Bug并不能算是重大过失，由这部分导致的损失无需赔偿。但是，在瑞穗证券电话联络东证交易所后，东证未能履行中止异常交易的职责，属于重大过错方。另一方面，事情的起因是由于瑞穗证券的乌龙指，所以瑞穗证券也不能完全免责，东证承担70%，107亿日元。　　对于这样的结果，东证和瑞穗证券都不满意，并上诉到东京最高法院，但得到的结果却是维持原判。　　尘埃落定后，我们可以看到，这个Bug的制造者没有需要承担相应的责任。　　但请各位程序员注意：第一，这种事情谁都不希望发生，所以最好还是不要出现Bug；　　第二，日本法院的判决中强调“程序Bug并不能算是重大过失”，“Bug是否很容易被检测出来”也成为法庭判决的重要依据。　　综上，入行需谨慎，并不排除程序员需要为自己的Bug承担责任的可能性！
上一篇：下一篇：
快毕业了，没工作经验，
找份工作好难啊？
赶紧去人才芯片公司磨练吧!!价值400亿的Bug为什么会发生？
日本公司J-Com在首次公开上市的日子就爆炸式地损失了超过400亿日元的天价损失，虽然日元那面额画得跟冥币似的，400亿日元也还是相当值些银子滴(按照当时的汇率，约为人民币27亿元)。
事件的大致经过是由于一位操作员在离开盘还有几分钟的时候接到了一位客户“以61万日元的价格，卖出1股J-Com的股票”的委托，而田中君在接到委托后在交易终端上错误地输入了“以每股1日元的价格，卖出61万股”。
至此，大家可想而知，事件继续发展下去会是怎样的灾难。但是，幸运的是在2分钟后，田中君发现了这个错误，他立即试图通过交易软件撤销这笔卖单，而不幸的是，由于交易系统的bug，田中连续三次的撤单指令都被拒绝，而此时盘口交易已经开始，此刻市场内当然是一片打乱，而最后，当然便是以瑞穗证券遭受的超过400亿日元的天价损失收场。
事后，J-Com将交易软件的开发商----富士通告上法庭，而通过漫长的诉讼加上控辩双方找来资深程序员和工程师进行撕逼大战，最终因为对Bug检测程度的深浅没有一个明确的评判标准，所以富士通并不需要去赔偿J-Com的损失。
400亿的背后
事件到这里暂告一段落，虽然这次事件是由一个操作员的乌龙指引发的，本来此次事件可以有一个更好结果，但是由于多方面的因素，导致J-Com并没有挽回一丁点儿的损失，在唏嘘的背后，到底是什么吞走了这“400亿”巨款呢？
1.首先，在业内没有企业敢保证自己开发的应用不存在任何的Bug，因为Bug在理论上是测不完的，任何应用都可能存在或多或少的Bug，同时，在Bug出现之前，也没有人能够去准确地判断其可能带来的损失，它是不能被评估的。虽然不能将Bug完全排查，但是我们也应该去建立一个Bug检测是否充分的标准，旨在尽可能地去检索排查应用中可能存在的Bug，在最大程度上减少损失。
再加上整个应用开发的过程中，传统测试流程带来的高成本，低效率也让众多企业不愿意花过多的精力放在这上面，他们还是希望自己的应用快速上线，从而获得收益。
2.其次，从这次事件中可以发现，在法律层面，对于Bug是否是重大过失的这个判断标准并没有被明确化，纵使专家组进去控辩双方进行争论，对于法官来说依然是懵圈儿的，因为它本身就无依可循，无章可据。
因此，在这类事件发生后，根本没有人能够去做出一个明确的判断，而往往事件发生后就控辩双方就会被揉作一团，责任的划分便是模糊不清，最终提供应用的企业几乎不会去赔偿由于Bug而造成的损失，那么就是经历了伴随漫长的上诉过程，其实对最终结果并没有多少太大的影响。
3.由于这些空隙的存在，才会让众多企业有机可乘，钻这些空子。毕竟对于企业来说，盈利才是最主要的目的，而且就算因为自家应用的Bug给用户带来了损失，企业也可以很轻松地去规避一些惩罚，逃脱一些责任，这让许多企业更是肆无忌惮地忽视Bug的检测，从而遗留了许多隐患，这些无穷后患就可能造成下一个“400亿”损失。
而除了Bug检测标准的模糊化，企业本身对于用户负责任的态度也是非常欠缺的，其实具备这种负责真诚的创业态度，才是让企业走得更远的基础。
4.再往深了分析，致使这些发生的根源笔者觉得其实很简单，就是行业内没有一个对于Bug是否测试充分的标准，一旦这样的标准被建立起来并且作为一个最主要的责任判断依据，那么再次出现此类事件，下一个J-Com就很可能获得赔偿，并且在法律因此能够设置有一个明确的裁定标准之后，各开发企业也将不会继续肆无忌惮地去忽视应用中Bug 的探索检测，因为他们很可能为自己一时放纵而遗留的无穷后患买单。
同时，这种标准的建立也实质上是一种业内的规范与约束，在这种约束下，我们虽然不能保证Bug的完全消除，但是可以尽量地去规避Bug可能带来的损失，同时企业的责任感也会被慢慢建立。
5.说了那么多，那这种标准的建立应该如何进行？笔者不谈妄谈，因为这需要全行业的努力，但是，有一点必须要明确，这个标准的建立必须由一个公正中立的第三方机构进行，譬如说政府、行业协会，或者就是一个技术水平领先、测试经验丰富并且等到业内公认的第三方公司。
虽然对于产品质量的重视程度也在随着行业的不断成熟在不断增强，然而目前大多数企业都把重心放在产品的研发和运营上面，测试（或者说质量管控）的地位始终比较边缘，造成了移动互联网行业中没有一个专业的针对测试技术及人员的行业协会组织存在，更不用提政府这个层级规范和要求了。
任何一个行业，一套标准的建立往往是在第三方产配套产业随着行业的发展也不断成熟后才会出现，且需要整个行业进行配合与支持。目前移动互联网产业已经陆续出现了多家成规模成体系的第三方测试服务公司，譬如国内的TestBird，国外的Testdroid等等，建议这些公司完全可以牵头建立这套体系，利己也利于整个行业。从目前来看，条件也是成熟的，一则如前说述，第三方服务已经成熟，二则从2015年开始，移动互联网产品在经过百家争鸣后现在也愈发成熟并重视产品质量，三则第三方公司的技术实力和经验已经有相当体量的积累，譬如TestBird就曾在其2014年的手游白皮书中第一次明确定义测试问题的类型及名词解释，可能是限于当时的特殊情况，令人遗憾的没有更深入一步，确定“好产品”的标准。虽然如此，但有这种标准建立意识就是一个很好的指向，只是可惜整个行业响应不大。
其实，无论企业将测试视为多么微小的环节，它依然是整个行业链中的一环，若是希望整个行业能够发展得更成熟，那么一环一扣都应该施以足够的重视，何况Bug的测试是可能带来巨大损失的环节。
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
全网内部优惠券汇总，你买东西比别人都便宜
华丽折扣-9.9包邮商城
今日搜狐热点