健壮性是衡量系统性能的一个重要指标。大家在使用或者开发的过程中对于系统的健壮性有那些看法或者做法。互相交流一下吧 <!--emo&:)--><img src='style_emoticons/default/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->

就一个系统而言，健壮性往往和安全性一起提到的。<br />而这两者是一个出色系统最重要的部分。（呵呵，偶以为这样的）<br />不论是开放式系统还是封闭式系统，程序的测试应该是最有效地一步，受到广泛和严格的审核是必须的，<br />程序员有时大部分是考虑自己的模块，而对于模块间互连后产生的错误考虑不足，而这些不能只指望系分来尽职尽责，需要考虑：就是尽量规范代码，仔细研究什么是安全健壮的代码。<br />有些时候，追求系统的速度，在编程时就会采用一些非常规的代码，而常常伴随的是晦涩的代码，但安全和健壮性有时却因为此而得不到足够保证。<br /><br />以上只是浅见，希望抛砖引玉

<!--QuoteBegin-sky-walker+2004-02-23 22:37:45--><div class='quotetop'>QUOTE(sky-walker @ 2004-02-23 22:37:45)</div><div class='quotemain'><!--QuoteEBegin--> 就一个系统而言，健壮性往往和安全性一起提到的。<br />而这两者是一个出色系统最重要的部分。（呵呵，偶以为这样的）<br />不论是开放式系统还是封闭式系统，程序的测试应该是最有效地一步，受到广泛和严格的审核是必须的，<br />程序员有时大部分是考虑自己的模块，而对于模块间互连后产生的错误考虑不足，而这些不能只指望系分来尽职尽责，需要考虑：就是尽量规范代码，仔细研究什么是安全健壮的代码。<br />有些时候，追求系统的速度，在编程时就会采用一些非常规的代码，而常常伴随的是晦涩的代码，但安全和健壮性有时却因为此而得不到足够保证。<br /><br />以上只是浅见，希望抛砖引玉 <!--QuoteEnd--></div><!--QuoteEEnd--><br />合格的程序员没多少<br /><br />只要系统能跑起来，就算万事打吉，哪会考虑那么多 <!--emo&:grin:--><img src='style_emoticons/default/grin.gif' border='0' style='vertical-align:middle' alt='grin.gif' /><!--endemo-->

首先，谢谢楼上两位的发言。 <!--emo&:rose:--><img src='style_emoticons/default/rose.gif' border='0' style='vertical-align:middle' alt='rose.gif' /><!--endemo-->  <!--emo&:rose:--><img src='style_emoticons/default/rose.gif' border='0' style='vertical-align:middle' alt='rose.gif' /><!--endemo--> <br />我说说哦的看法。<br /><br />系统的健壮性（robustness）也称为系统的坚固性或坚实性，这是衡量一个系统能否从各种出错条件下恢复能力的一种测度。引起出错的条件可以是来自系统内部，也可以是系统外部的。比如：一个健壮的系统可以容许数据输入的错误，也可以允许内部组成部件的故障。<br /><br />的确，现在一个系统的健壮性和安全性大多从操作系统、运行平台、开发工具、网络以及其他方式实现。<br />例如，用多层结构将不同功能封装在各个层次。<br />又例如，采用分散式而不是集中式<br />再有，通过数据库的备份计划及故障恢复机制，保证系统连续平稳运行。<br />还有，采用面向对象的设计方面增强软件的健壮性。<br />。。。。。。<br />诸如以上各种均为从大的方面来实现系统健壮性。从软件代码方面着手的很少。大多情况下，程序员比较倾向于追求执行效率牺牲了软件的健壮性。<br />程序员实现健壮性的一般做法是针对系统外部出错条件，比如考虑输入值，处理数据的输入错误。<br />但是对于系统内部出错条件关注较少。比如开发工具自身的缺陷。这些需要程序员自身素质的提高。<br /><br />以上是哦的个人看法 <!--emo&:blush:--><img src='style_emoticons/default/blush.gif' border='0' style='vertical-align:middle' alt='blush.gif' /><!--endemo--> 欢迎大家继续发表自己的看法

业务系统的健壮性一方面取决于产品的健壮性，另一方面也取决于应用系统的健壮性。所以，如果要看一个系统是否“健壮”，主要包括网络测试、安全系统测试、数据应用系统测试和业务系统测试，目的是使用户能够对自己的IT系统有一个全面的了解和认识，以提高对系统的监测能力，减少用户系统扩容时投资的盲目性。<br />现在，人们对信息的依赖程度越来越高，对信息系统的要求已经不仅仅满足于能用，而是需要高性能、高可靠和高可用的值得信赖的信息系统。在整个的信息系统中，网络结构、网络传输、网络交换、业务应用、数据交换、数据库运行、应用程序运行、安全措施、备份措施、管理措施、主机/服务器处理、客户端处理等等，这一系列的元素都是相互关联和相互影响的，这些元素之间的关系往往是比较复杂的，“牵一发而动全身”，每一项元素的性能下降或者受到安全威胁，都将对整个信息系统造成影响，尤其是对于那些处于关键地位的元素更是不允许性能下降和存在安全隐患。这样，必然导致信息系统需要进行全面的健壮性评估。<br />比如说，一项网络数据业务的正常运行，不仅需要高效的网络传输和交换，还需要主机、服务器的及时处理以及数据库系统的良好运转，也需要足够的安全保证。信息系统的健壮性测试是保证网络高性能、高可靠性、高可用性、高效率运转的基本手段。信息系统的健壮指数越大说明它的生命力就越强，它所能够承载的信息量就越大。一个健壮性指数高的信息系统是保证业务运行和应用的必要前提。

再给大家转一点资料：关于系统健壮性的评估<br /><br /><span style='color:blue'><b>评估目标</b></span><br /><br />　　提供全面的现有网络状态的信息；保护现有的资源，为投资决策提供科学依据；提出改善网络性能建议；提供降低风险、改善网络运行效率建议；提供全面的评估总结。<br /><br />　　<span style='color:blue'><b>评估原则</b></span><br /><br />　　<span style='color:purple'>整体性原则</span>：从评估内容、业界标准、应用需求分析和服务规范等多个角度保证评估测试的整体性和全面性。<br /><br />　　<span style='color:purple'>规范性原则</span>：严格遵循业界项目管理和服务质量标准和规范。<br /><br />　　<span style='color:purple'>有效性原则</span>：从成功经验、人员水平、企业信誉、工具、项目过程等多个方面保证整个过程和结果的有效性。<br /><br />　　<span style='color:purple'>最小影响原则</span>：在项目管理和工具技术方面，使评估对系统造成的影响降低到最低限度。<br /><br />　　<span style='color:purple'>保密性原则</span>：保证应用系统和业务系统数据的安全性，避免客户数据的泄露和系统受到侵害。<br /><br />　　<span style='color:blue'><b>评估内容</b></span><br /><br />　　<span style='color:purple'>按照资源划分</span>，评估内容包括对网络结构、网络传输、网络交换、业务应用、数据交换、数据库运行、应用程序运行、安全措施（包含设备软件和制度）、备份措施（包含设备软件和制度）、管理措施（包含设备软件、制度和人员）、主机/服务器处理能力、客户端处理能力等方面的评估。<br /><br />　　<span style='color:purple'>按照评估项目划分</span>，评估的内容包括协议分析、压力评估、流量评估、瓶颈分析、业务应用评估、漏洞评估、弱点评估等方面。

谢谢楼上&quot;MM&quot;啊，受教了哦

呵呵，楼上过奖了。 <!--emo&:blush:--><img src='style_emoticons/default/blush.gif' border='0' style='vertical-align:middle' alt='blush.gif' /><!--endemo--> <br /><br />三毛JJ的这个讨论非常有实际意义，而且是致关重要的。建议斑竹将此帖加精！ <!--emo&^_^--><img src='style_emoticons/default/happy.gif' border='0' style='vertical-align:middle' alt='happy.gif' /><!--endemo-->

<!--QuoteBegin-echoguo+2004-02-26 15:53:24--><div class='quotetop'>QUOTE(echoguo @ 2004-02-26 15:53:24)</div><div class='quotemain'><!--QuoteEBegin--> 我不是软件工程版的斑竹啊<br />还得请 CAROL JJ 帮忙啊 <!--emo&:blush:--><img src='style_emoticons/default/blush.gif' border='0' style='vertical-align:middle' alt='blush.gif' /><!--endemo--> <!--QuoteEnd--></div><!--QuoteEEnd--><br />这家伙，不要以为你穿了小三毛的衣服，哦就认不出你。 <!--emo&:,--><img src='style_emoticons/default/glare.gif' border='0' style='vertical-align:middle' alt='glare.gif' /><!--endemo--> <br />还有什么好东东，继续 <!--emo&:P--><img src='style_emoticons/default/tongue.gif' border='0' style='vertical-align:middle' alt='tongue.gif' /><!--endemo-->

偶来帖一些资料，吼吼，是shala的领导A说过的 <!--emo&:grin:--><img src='style_emoticons/default/grin.gif' border='0' style='vertical-align:middle' alt='grin.gif' /><!--endemo--> <br /><!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--><br />***********面向对象的设计法确保软件的健壮性***********<br />软件设计的质量在很大程度上受到系统封装关系的影响。模块间松耦合而模块内部又保持高度一致性是高质量设计软件的关键之一。所以，评定软件设计的水平的手段之一就是考察它的模块间的关系。对系统的可重用性和可维护性水平的客观评价是一个评价软件结构的重要组成部分。我在本文介绍的度量标准可以帮助你客观评定你的软件设计的质量。<br /><br /> <br />尽管度量标准可以对我们的软件设计质量起着指导和反馈的作用，但是你要牢记我在本文提出的度量标准并不是软件设计的唯一依据。设计质量分数的高低未必一定对应于真实软件设计质量的高低，但是不太可能出现那种设计水平很高，但是在我们这种度量标准下，分数却很低的情况。我们提出软件设计质量度量标准的目的在于帮助设计者正确评估他们自己的设计，更重要的是帮助你检测设计的水平是否达到预期目标。<br /><br />测试稳定性<br />稳定性指的是修改软件中某个模块而不影响其它模块的困难程度。让我们看看模块间的依赖关系是如何影响到稳定性的。<br /><br />一个模块在软件中重用的次数越多，那么就越依赖于它。模块的输入依赖性越强（较多的其它模块依赖本模块），则它的稳定性得分也就越高（即难以修改）。换句话来说，其它模块越依赖于本模块，那么修改本模块而不影响其它模块也就越困难。模块的输入依赖性和输出依赖性是评测模块稳定性和不稳定性的重要方面。模块的输出依赖性强、输入依赖性弱，则稳定性低（即容易修改），这是因为对变化不会扩展到很多其它方面。另一方面，模块的输入量越多，它就越难以修改，则越稳定。稳定性可以通过计算输入量和输出量来计算。<br /><br />输入耦合度代表依赖本模块的其它模块数，输出耦合度代表本模块所依赖的其它模块数。不稳定度可以通过输出耦合度与总的耦合度的比例来得到。计算公式如下：I = Ce/&#40;Ce + Ca&#41;<br /><br />I 代表该模块的不稳定度 <br />Ca代表该模块的输入耦合度，即输入依赖度 <br />Ce代表本模块的输出耦合度，即输出依赖度 <br />如果I的值接近于零，那么模块的输入依赖性就远远大于输出依赖性，模块也就越稳定。模块越稳定也就越难以修改，因为某个变化会衍生出许多新的变化，波及到依赖它的其它模块上了。对I值接近于一的模块来说，它的输出依赖性远远大于输入依赖性，模块很不稳定。由于受本模块影响的模块不多，所以不稳定的模块容易修改。看到这些，你也许会感到很困惑，“到底我应该让模块的稳定性高一些好，还是低一些？”<br /><br />由于组成一个软件的一整套模块中，有些模块有输入依赖性（被其它模块引用），而有些模块有输出依赖性（引用其它模块）。我们在设计模块不应该追求完全的稳定性或者不稳定性，而是具体考虑某个模块需要的是稳定性还是不稳定性并尽可能实现。输入依赖度比较强的模块必须拥有较高的抗可变性，展现较高程度上的稳定性。在面向对象的开发方法中，抽象性通过分离功能和功能的实现方法来提高稳定性。对Java来说，抽象类和界面（interface）显然就是抽象性的表现形式。因此，越需要稳定的模块应该有越高的抽象层次。与此对应，越不稳定的模块也就越具体。<br /><!--c2--></div><!--ec2-->

1对一个任务使用多种模型<br />　　收集需求时，要考虑开发用户案例模型、用户界面模型、域模型。设计软件时，要考虑创建一个类模型，一系列序列图，一些陈述图，一些合作图，最终是不变的物理模型。建模者如果仅仅只采用一种模型，那就可能开发出一个健壮性不强的软件，要么无法满足用户需要，要么不易改进。 <br />2 对于N层的应用软件系统，通常被划分成以下三个层次：数据库层、应用服务层和用户界面层。其中，应用服务层集中了系统的业务逻辑的处理，因此，可以说是应用软件系统中的核心部分。软件系统的健壮性、灵活性、可重用性、可升级性和可维护性，在很大程度上取决于应用服务层的设计。因此，如何构建一个良好架构的应用服务层，是应用软件开发者需要着重解决的问题。 <br /><br />找了一点资料 <!--emo&:grin:--><img src='style_emoticons/default/grin.gif' border='0' style='vertical-align:middle' alt='grin.gif' /><!--endemo-->