从可测试的软件到自容错的软件

本文于2005年8月21日发表在搜狐博客

一直我为软件的集成、测试深受其苦，几十万行的软件尚且如此，一个更加庞大的系统又该如何。即使我们增强了单元测试的力度，同样不能解决有效集成的问题，换句话说就是，即使分系统测试通过，还是不能保证系统更好的集成。

以前我一直有个隐约的想法，软件系统也应该提供模拟仿真的功能，在仿真容器中运行之后，基本就可以可靠的运行于正式系统。在系统集成前，通过仿真环境就可以模拟集成时的情况，降低系统集成的成本。不过如何仿真，却是没有思路，想想就算了。

上周与朋友吃饭，朋友是《机电系统测试与诊断理论》方面的专家，谈起了飞船、卫星等系统的测试时间比较长，如果能够在设计中引入可测试性的设计，就可以在集成测试中比较容易的定位问题，大大减少测试的时间。朋友做过舰艇的故障检测，要是老一些的船没有相应接口，做起来就比较麻烦，如果能在系统的设计过程中预留测试接口，就顺利很多。

看来，可测试性的设计就是我想要的东西，平时我们也会做一些。例如一个事件管理器，addListener、removeListener、notify是对外接口，listenerSize就是一个测试性接口。对于软件系统来说，log只是个记录而已，是远远不够的。假如我在在系统启动时需要加载 5000 个资源，如果有一个BUG导致其中的一个资源加载失败，最好的方式就是在加载过程中提供若干测试接口，用来测试加载过程的状态，根据状态分析失败的原因，如果仅仅根据log进行分析，会是一个很痛苦的事情，如果故障的发生比较随机，就更加困难了。

初步的软件的可测试性设计和硬件、机械系统一样，需要在设计过程中，建立测试规范，定义测试接口，这些接口和对外的API一样，是系统的重要组成部分，有了可测试性的规范，仿真容器也就呼之欲出了，httpunit就是一个测试容器。两者结合，就可以认为经过测试的分系统很容易集成到上级系统中；集成的过程中也会很容易的检测到分系统的故障状态。

我想：如果有了可测试性的设计，系统即使在运行状态中，也可以对这些情况进行监控，利用这些中间状态信息，软件也能做到自我容错的功能。对于一个可靠性要求高的系统，容错是提高可靠性必不可少的方法。

不过朋友说，我们机电系统成本太高，需要这个，你们软件稍稍一改就好了，是不是真的需要呀？确实有道理，灵活是软件的优势，但是这种低成本的做法也多少伤害了软件的质量，例如交互式设计这个重要但是成本比较高的过程，就很少在我们的软件中体现