那天黄历上写着：初四，立春，东风解冻。在这么个万物复苏的日子，我朋友圈里的IT攻城狮们却都在热转一篇标题很惊悚的文章《程序bug导致了天大的损失，要枪毙程序猿吗？》。啊咧？枪毙？！吓死宝宝了！！作为一个先是立志修摩托，后来想要写小说，结果现在天天对付bug的程序猿，立刻想要卷铺盖回家种地。等等，貌似我家并没有地…看在也没别的手艺养家糊口的份上，还是点开看了一眼。起码先知道什么样的bug会被枪毙，以后才好避开这些项目啊…软件bug有这么难发现吗？浏览完了帖子，再迅速扫描完各路大神的评论，发现抛开文中介绍的又一个导致严重后果的软件bug不谈，哎？我为什么要说又，大家其实还是在争论老问题：程序太容易有bug了！如果系统运行中bug被触发导致严重的影响，这个锅程序员该不该背？好吧，本文我们不去讨论到底谁来背锅，这个问题我说了不算。我们感兴趣的是，为什么我朋友圈里这些从业十多年，在各大知名单位顶着各类总，各类专家头衔的老IT男们会这么担心这件事。软件bug有这么难发现吗？如果真的凭人力难以发现，有没有什么方法帮助我们去发现或者避免它？事实上所有的软硬件相关企业或单位都一定会有一支专业的队伍专注于在系统上线或发布前去检查其中潜在的问题。最常用的手段自然就是测试。各位同学做程设实验作业交代码之前我相信一定也会自己先跑一些用例来测试自己的代码看看对不对，不然助教检查时跑不起来就没分了不是吗？而软硬件企业是要靠这些程序来工作或者盈利的。那么他们在这上面投入的成本用脚趾头想都知道一定很大了。我们来考虑下面这个喜闻乐见的场景，当你正在跟室友开黑LOL的时候，忽然死机了，当下是不是砸机器的心都有？如果这样的场景多来几次，说不定任性的你下一秒就转而去Dota了。企业采用的测试手段企业采用的测试手段和大家的方法其实类似，说白了就是跑各种用例尽力覆盖更多的可能，然后去比对运行情况和预期是否一致，或者进一步对代码达到一定的覆盖率。然而，注意到没有，这个过程能不能发现问题和你运行的用例密切相关。虽然相关领域有着大量的研究去自动生成高效的测试用例尽可能覆盖更多的行为，但是对于复杂系统，当它的潜在输入可能非常巨大的时候，你是不是能恰好触发要命的那一个用例这就保不齐了。举一个所有软工课几乎都会提到的案例，欧洲Ariane5运载火箭因为一行强制转换代码失败，导致火箭上天37秒后变成了一个巨型烟花秀。你要是说他们发射前没好好测试，你信么？反正我是不信的。手机死机了可以重启，LOL出错了你可以换Dota，然而飞机飞在天上的时候怎么重启呢？导弹打出去了怎么收回来更换呢？所以在安全攸关领域，随着程序问题越来越多，后果越来越重，逐渐开始要求在常规测试之外加上一个更严格的检测手段来确保没有问题。这个方法就是形式化证明。一套公理系统所谓“形式化”说的简单一点就是将你所要做的事情用严格的无二义性的数学语言描述出来。而“证明”，各位一路数理化读上来的同学都很熟悉。不外乎就是根据已知条件，依据某某公理，可以一步步推导出某某结论。这样的公理系统在计算机领域一样存在，比如大名鼎鼎的霍尔逻辑（HoareLogic）。霍尔逻辑的核心是霍尔三元组（HoareTriple），其将一段代码的执行描述成｛P｝C｛Q｝的形式，其中P和Q是原子命题，P称为前置条件，Q称为后置条件，而C是代码命令。这个三元组解读为如果在执行C语句前P成立，则执行C后Q一定成立，比如{P}skip{P}。针对各种代码执行情况，比如赋值，组合，条件判断等，图灵奖获得者TonyHoare爵士给出了一套公理系统。而基于这套公理系统，理论上程序员们就可以从你的main函数的第一条初始化命令开始一步一步展开证明，去保证你的代码执行过程中每一步都满足你的预期。比如，你可以为一些关键语句设置一个称之为不变式（invariant）的断言（assertion），然后通过霍尔逻辑去证明执行到这一点时该不变式没有被违反。类似的方法，也就是软件形式化证明的第一个方向——定理证明（TheoremProving）。这种方法一经提出，便得到了整个计算机行业的重点
哪里治疗白癜风北京哪家医院治疗白癜风最专业
转载请注明：http://www.zjiaren.com/yjly/1635.html
