从底层语言和算法角度分析程序为啥会崩溃

简单说就是读取到错误的数据。崩溃,其实就是把CPU当前程序运行位置的指针指向了一个错误的地址。该地址可能是一张图片的某一个像素,可能是某个excel中的一个数据,但傻乎乎、直肠子的CPU就是把这个数据当做一个指令读进来,并且执行。如果非常幸运,有那么一点概率可能出现这种情况,CPU还能凑活执行一两句,载入一个数据,做个加法或是做个跳转,但更大的概率是,可能载入的数据根本就不是一个合法的命令字,CPU直接报错。在编写嵌入式系统的代码时候,因为广大的地址空间都用不上,空白空间一般都会填写为 long jump to 0000 或者长跳转到其他初始化空间(不同的CPU启动代码所在的默认位置不同,有可能不是 0000)。这样操作,在一定概率上,跑飞了的程序还能回到初始状态执行,相当于一个软启动。更专业的做法,是看门狗程序。看门狗就是一个独立的子程序,设置某参数后,自行倒数,每隔一段时间必须重置这个计数器到设置过的参数。如果一段时间不能重置看门狗参数,则认为系统跑飞或死机,会重置系统为初始状态,也类似软启动。至于你说到的大型CAD。软件是一项复杂的系统工程,越是庞大、充满历史的程序越是难以维护。现有软件测试策略,是基于损失的。对于大型CAD软件来说,只要不损坏数据,死机带来的损失还是很小的,主要也就是用户体验,在行业专业应用类程序中,这类缺陷应该不是测试的优先目标。测试成本很高,投入一份成本也许能达到80%的覆盖率,投入十份才能达到90%,投入一百份才能达到95%。所以软件测试只针对会造成大量损失的高优先级关键模块或关键功能进行详尽测试,其他部分只能投入较少的资源来完成,完成质量也较差。


    推荐阅读