框架模块设计经验总结

下半年准备做OEA 的 B/S 版本，比较复杂，需要从架构设计开始认真入手。正好今天到了部门反思的时间，今天先把原来的一些设计经验总结一下，以方便将来回顾。

直入主题，这篇日志主要用于总结一些框架级别的模块设计经验。

总述

一个大型的框架，必然由多个较独立的子系统/子模块构成。这些子模块如何交互，之间的接口如何定义，这是框架的架构设计的问题。而今天我主要要总结一下，针对其中的某一个子模块，应该如何进行设计。（例如，在 OEA 中有这些相对独立的模块：分布式框架、实体框架、界面生成框架、命令框架、产品线框架、分布式缓存框架、报表模块……）

我在对一个模块进行设计时，大致经过以下流程：预设计阶段、逻辑设计阶段、设计评审、设计调整阶段、设计实现阶段、模块整合阶段。在一次单独的设计中，并不是必须要经过以上每一个阶段。例如，当模块比较简单时，就不需要设计评审、设计调整等阶段了。以下我逐一描述。

预设计阶段

设计开始之前，我们需要为设计做很多工作。其主要的目标是收集并整理模块的需求，力求结构化地描述需求。这些需求主要包括：场景需求、质量属性要求、环境约束。这个过程对于之后的设计过程相当重要，原因也很明显，不再赘述。

场景需求包括：框架用户对模块的功能性需求、70%场景、20%场景、10%场景、API 需求。

质量属性：参考ISO 9126。这里要分析出关键质量属性。

环境约束：技术约束、系统环境等。比较常见的是对原有系统的兼容性。

根据模块的复杂度不同，这个阶段的时间长短可能会有很大区别。例如，界面生成框架在 OEA 框架中是核心模块，在它的 2.0 版本的设计之前，我们平时会不断地收集前一版本的缺点及不足，做整理并使这些杂乱的需求结构化，这个工作“非正式”地做了一年，这些时间都可以算是在预设计阶段中。

最后的交付物自然是：《模块需求规格说明书》。当然，文档这东西，主要用于沟通、传授。可以看情况而定，不一定有这个必要。但是，如果后面有正式的评审会议，这个文档最好还是准备一个正式的。

逻辑设计阶段

关键点：场景驱动设计、质量属性验证设计、环境约束验证设计。前者做加法，后两者做减法。

设计师的经验越丰富，在这个阶段成功的机会也就越大。要满足一套关键质量属性，如果你之前没有遇到过类似问题的话，可能你觉得你的设计能实现，但是最后的事实往往不一定正确。而且设计不象数学那么严格，更象是艺术，艺术靠什么，灵感！所以这个阶段中，不同的设计师很可能会有不同的设计稿。（当然，如果这个模块比较简单的话，很可能设计就不会有什么区别了，毕竟，现有的软件设计的模式是很多的。）

逻辑设计的方法主要还是画图。其中主要还是依据一些通用设计的原则进行设计。

画什么？主要是 UML 中的两类图：静态结构图（包图、类图）；动态结构图（序列图）。

顺带说一句，很多设计人员可能会坐在电脑旁边直接拿 EA 等工具画图。但是我个人比较喜欢的方式是：

先用纸笔来画一些手稿。
这个方式主要是比较方便，任何地点都可以画，例如开一些不重要的会议的时候，就可以随手画画。而且最后看着许多有用的手稿，感觉还是很有成就感的，跟画家似的～哈哈。

随时想、随时画：
我觉得，一些复杂的设计不是简简单单就能想出来的，特别是我觉得自己的智商只是处于常人智商的范围中，要想出一些卓越的设计，不可能只是坐在办公室的那一点点时间。（我记得我曾在梦中想出了一些醒着的时候想不出来的东西……）

汇总成正式设计稿。

交付物：UML 图！这是必须的！

这个阶段中，主要考虑质量属性及关键需求。

要提升该阶段的能力，个人再次推荐几本著名的书籍：《Pattern of Enterprise Application Architecture》，《Microsoft Application Architecture Guide》，《Enterprise Solution Patterns Using Microsoft .NET》。

设计评审

召开设计评审会议的原因：

人无完人，个人的想法很可能有问题。

听取更有经验的人的指点。

团队协作、团队沟通。

听取模块使用者的建议。

所以，如果不是十万火急，都建议召开评审会议！

我主持过的评审会议，曾经出现了许多的问题，大家可以看看我当时的反思：《反思 - 组内设计评审会议》，不要出现和我一样的错误。

设计调整阶段

没啥，看评审会议的结论。要么做些小的调整，要么大改动，甚至重新设计。如果改动较大，别忘了最后再召开一次评审会议。

设计实现阶段

这个阶段包含了设计的代码验证阶段。

可能由于公司的组织结构不同，这个阶段并不一定由设计师自己去完成。但是我建议不要完全由他人完成，设计就象是自己的孩子一样，辛苦辛苦把他生下来，你让别人来把它抚养大，不觉得奇怪吗？如果你觉得你要设计的东西太多，没时间完成，我觉得你还是少做一些，做好一些会更好。

建议实战能力弱甚至没有实战能力的设计人员不要再做设计了，先好好在底层磨炼磨炼吧。设计师从程序员成长而来，架构师从设计师成长而来，这才是务实的做法！

这个阶段考验的是设计人员的代码实现能力，团队协作能力。代码的实现能力往往真正能看出一个人的设计能力。软件设计原则大家都会说，但是，要真正把这些原则应用到代码实现中，却需要时间的不断磨炼。如果开发组里能有几个为技术痴迷的人，那是最好不过的了。

实现相对于设计稿，可以有一些更多的灵活性，并不一定要100%符合设计稿，这是因为代码实现本身就是一种微观的设计。但是必须要求80%以上是要符合设计稿的。如果实现过程中，不得已有过多的部分不符合当初的设计稿。请：召开讨论会议！重新画图描述当前设计！总结反思！

值得一说的是，实现阶段需要着重对使用场景进行 721 分析，设计良好的 API 以应对这些场景，并配以相应的单元检测。关于框架设计中的场景驱动设计，大家可以看这篇文章推荐的书籍：《Framework Design Guidelines 2nd Edition》。

模块整合阶段

其实这个阶段中的工作在上一阶段中需要准备好，也就是说，在进行编码时，需要不断考虑所设计的代码能否在大的环境中运行。所设计的接口是否能和当前系统正确的衔接上。如果之前的代码没有考虑足够，在这一整合阶段中，可能会发生一些集成的问题。不过这种情况我遇到的比较少，这里就不展开了。

这阶段完成后，最好能配上集成测试。（不过我目前都没有做过。）

演进模块的考虑点

在整个框架的架构设计完成之后，其中所涉及到的模块分两类：一类是在架构设计时已经考虑到并明确定义的模块；另一类是架构初始设计时并没有考虑到，但是随着系统逐渐演进，发现必须被添加进来的模块，我简称其为“演进模块”。两种模块的设计有许多相同之处，相对而言，设计演进模块时，相对要需要考虑更多的东西。

针对演进模块，在预设计阶段，约束中需要重点写明历史系统对当前模块的兼容性约束。在设计阶段，需要分析当前系统，从中找到突破口。

兼容性是很麻烦的一种约束，为了满足这种约束，常常会使简单的设计变得复杂。最后的代码也很可能写得不符合规范。在以后的新版本中，如果做出不再兼容这些历史代码的决定时，这些兼容性设计需要被删除。

设计失败的常见原因

预设计阶段工作做得不充足。
未收集场景、早早地进入了逻辑设计阶段、甚至直接开始编码，导致最终设计了不需要的部分，或者根本满足不了需求。

过份自信，未召开评审会议。

设计经验不足。（逻辑设计要求经验、灵感）
提升方案：多把现有系统画出来。架构模式、设计模式都熟了吗？平时有没有花非工作的时间多设计些东西？书看太少了？

编码能力不强。（代码实现要求实战家。）
提升方案：天天写些无聊的代码？非工作时间有多少花在代码上？书看太多了？

逻辑设计、代码实现分两波人做。

项目经理领导力

演讲者：田俊国

领导力和领导
二者并没有直接关系。很多名为领导的人，常常被下属牵着鼻子跑。

达成共识、目标共享
一个搬梯子的故事形象地解释了和下属共享目标的重要性。

要做冰山下的沟通
一座冰山，只有很少的一部分是露在水面上的。如果只做表面的沟通，往往不是最直接的，也不能很好地达到沟通的目的。

做一个高自尊的人

气球原理
要当领导，至少你的气球要能包容你下属的气球。

做好教练

势利权形情
类似于金木水火土、仁义理智信。

软件企业常见问题和系统性解决方案

演讲者：林锐





需求的本质

演讲者：徐锋





架构重构

作者：温昱





个人小结

觉得比较有收获的是下午的这两场。

第一场讲的是需求方面的内容。一直以来都对需求不感冒，但是这是我第一次听需求方面的演讲也听得这么有意思。需求的探索过程可以融入到生活中的一点一滴。问题层面的描述和解决方案式的描述需要被区分开来，这样才能更好地深入挖掘需求。需求分析人员和客户交流的时候，要对需求有更大的领导力，你必须在此领域有较深的认识。对业务的认识程度，决定了是谁领导谁。

人活着是为了造福社会，给他人带来价值。那么，要带来更大的价值，我们需要从更深的层次上了解目标受众的需求，这样才有可能发挥我们的能力，做出更大更有意义的贡献。这也是我觉得这次演讲对我最大的意义，以后在思考各种目标的时候，都可以用区分“问题/解决方案”的模式来获取更深层次的目标。

后面是温昱老师讲的架构重构。其实这次去参加CCSE2010最期望听到的就是他的演讲。之前看过他的《软件架构设计》，觉得写得很务实、很有指导性，国内少有这种高质量的书籍。而这次讲的架构重构虽然不全是新的观点，不过正好和我现在所做的工作比较吻合，所以也听得我津津有味。按照温老师的说法，重构必须细分：架构重构、模块重构、代码重构。我到现在的公司一年多了，虽然没有做到架构层级的重构，但是一半左右的时间都是在做重构，做代码重构、做模块重构。虽然重构需要要考虑很多问题，要担负更多的责任、更大的压力，但是我还做得比较开心。一来，在现在项目组中，原来的架构师忙着做其它的工作，而其它同事暂时也没有我熟悉系统的结构，所以如果要重构，必然是我的责任。二来，这和我的性格有关，我一直都有“代码强迫症”，想着还有优化的空间，想着如果现在不重构以后同事们做起任务来会更痛苦，哪怕别人再怎么看，再怎么说，我都会坚持下去……前几天看了一篇文章：《重构者的20种死法》，写得还是很有道理的，不过对于这些问题，我也可能笑笑了，很多事情，如果你要做的话，就得承担它的困难。

以后要真是有“设计重构师”的职位，倒是可以去试试……

最后，再说说职业规划。看着台上的前辈们如此厉害，十年磨一剑确实不虚。中午吃饭的时候，我问朋友：“古代的大侠，许多都是在深山修炼多年后，才能在江湖中扬名。如果给你十年时间，你会挑哪个方向修炼？十年后，你如果达到台上这些牛人的水平，你觉得怎么样？”

其实，这个问题我是想问问自己。虽然我一直以来都对技术充满热情，现在自己也觉得技术还不错，但是如果真叫我以后都朝技术方向修炼的话，我开始忧郁了。因为我喜欢技术，不代表我喜欢一辈子做技术，哪怕是架构师。晚上回家，和女友聊了很多，聊职业规划、聊兴趣、聊人生，最终我推出的一些结论，让女友觉得非常可惜，因为她一直都认为我是一块做技术的料。

有些事情如果我不做，当我年迈回首的时候，一定会为自己而后悔……

技术讨论总结：客户化、缓存

最近，GIX4项目需要开展客户化工作。同时，下一期sprint中，客户还要求大幅度提升产品的性能。针对所存在的问题，开发人员决定开一系列的技术讨论会。
我总结了目前遇到的和可能遇到的问题：
客户化：
实体类客户化
各客户对同一产品表现出的需求，要求实体类在一定程序上各不相同。这就需要领域模型做到可以客户化。
界面客户化
需求不同，界面自然也需要客户化。这是一般性需求。
性能：
实体类优化
目前系统使用的是基于CSLA对象模型的实体类。由于使用了CSLA托管属性，性能比较差。同时，由于一个聚合类往往通过多个多层的实体类聚合而成，调试时却都是在调试CSLA的基类，基类中为所有实体类使用同一种模式进行架构，而用递归和继承来实体类间结构，使得代码难于调试，经常让人晕头转向。
缓存的植入
要提升现在分布式系统的性能，最直接最易用的方法就是对一些常用而不常变的对象进行缓存，减少网络传输，减少数据库访问次数。

20100826
今天和周哥、杜强、智哥一起讨论了系统的客户化方案。时间持续了大概2个小时，内容不多，收获也不多，但是觉得很重要。主要有以下两点：
第一、更加清晰了GIX4（包括OpenExpressApp）的思想、架构和RoadMap。
我想，产品GIX4架构思想可以这么解释：特定于建筑领域的产品线架构方法。

产品不同于项目，它是为整个建筑行业开发的，需要考虑其通用性，同时也必须能够满足各企业的定制化需求。整个产品线开发中，包含了三类客户，按照721的原则划分，这三类客户是：
一类用户：70%；这些客户的功能需求完全符合整个行业的习惯，他们代表了行业的一般性情况。这些需求肯定要被包含在产品中。
二类用户：20%；这些客户一般分为几种类别；同一类客户的需求往往相同，同不类客户的需求往往不同；这些需求一样要被包含在产品中，产品需要一定的策略来给各类用户进行定制。
个性用户：10%；这些客户的功能需求往往源自其自身的习惯，往往不能被其它同行所采用。这类需求将不会被包含在产品中，但是作为一个有平台性质的产品，应该具备为这些用户定制功能的扩展能力。

软件架构采用领域驱动，所以主干代码中的领域模型需要代表行业的整体需求。同时，也要能表达二类用户的情况，这可能需要多个小分支模型。个性用户的需求需要在主干模型的基础上扩展。（在类设计上主要使用继承，而建模环境将会在不远的将来支持，同样也需要支持模型扩展。）

第二、设计时，应该尽量避免二义性。
关于设计的讨论，是在讨论一个具体的问题引起的小插曲，问题如下：
在原来的产品设计中，有这样的聚合关系：Project->Contract->Budget；但是现在需要同时支持：Project->Budget。而这两个需求本身就是从两家不相干的客户提出，它们不能同时存在。
我一开始主张BudgetParent->Budget的聚合，然后Project和Contract都继承自BudgetParent。提出这个方案的原因在于，我从客户的需求开始倒推领域需求，我觉得在客户的浅意识里，Budget之上是有某一个东西有进行组织（BudgetParent）。但是后来知道，这个推论是片面的，行业内并没有这样的认知。所以从领域角度讲，这个设计并不成立。
对于我提出的方案，周哥提出尽量不要带有二义性的设计。如果只可能是Project和Contract，在没有必要的情况下，不需要再引入一个“BudgetParent”类或接口。这样不但会增加程序的复杂度，更重要的是它会让程序变得含糊，看程序的人并不能从类的设计上一眼看出领域需求。后来一想，确实如此，没有必要的话，还是使用具体类再加有实在意义；不要因为程序的考虑，而使得领域复杂化。
后来的结论是：需要再次和领域专家确认后，才能知道到底一个Budget会不会可能同时被Project和Contract进行组织。如果是，则Budget类本身应该拥有Project和Contract的引用。如果不是，则可能需要设计两个不同的Budget子类来实现。确实，不管最后是选用哪一种，都能清晰地表达出Budget、Project、Contract之间的关系。:)

《架构师》反思：系统可靠性

最近系统学习了一个系统可靠性及其相关知识，今天在这总结一下。

首先，什么是系统的可靠性呢？系统的可靠性是指在规定的时间内及规定的环境下完成规定功能的能力，也就是系统的无故障运行概率。

我会从以下几个方面来归纳主要内容：

1. 故障模型

2. 可靠性模型

3. 可靠性指标

4. 可靠性设计

故障模型

系统故障是指硬件或者软件的错误状态，一般引进故障的原因是这些：部件的失效、环境的物理干扰、操作错误或不正确的设计。

按照时间的长短，故障可以分为：永久性、间歇性、瞬时性。

故障的级别有：逻辑级故障、数据结构级故障、软件故障和差错故障、系统级故障。

可靠性模型

与故障模型想对应的，就是系统的可靠性模型。常用的有以下三种：时间模型、故障植入模型和数据模型。

这三种模型暂时还没有看懂（晕）。

可靠性指标

可靠性指标，主要有以下几个：

平均无故障时间（MTTF-Mean Time To Failure）

它表示一个系统平均情况下，正常运行的时间。

与它相关的指标是“失效率”U，关系： U = 1 / MTTF。

平均故障修复时间（MTTR-Mean Time To Fix/Repire）

平均每次修复所需要的时间

平均故障间隔时间（MTBF-Mean Time Between Failure）

一看就知道，MTBF = MTTF + MTTR。

在实际情况下，一般MTTR都会比较小，所以我们近似地认为MTBF = MTTF。

MTTF是用来说明一个软件系统能够正常运行的时间的指标。它越大，说明该系统越可靠。计算方法很简单，

可靠性计算

一个系统的可靠性计算往往不能直接得出。这是因为计算机系统是一个复杂的系统，影响其可靠性的因素也非常复杂。所以我们需要为其建立适当的数据模型，把大系统划分为若干子系统，然后再根据一定原则进行组合计算。

这种计算方法，可以简化分析的过程。

对于系统的划分，我们可以把它分为：串联系统、并联系统、模冗余系统、混联系统。（其中模冗余系统是M个并联的子系统中，需要有N个以上的子系统能正常工作，整个系统才能正常工作。这种系统，常在并联后加上一个表决器。）

计算这些系统可靠性时，我们需要计算出每个子系统的失效率，然后根据概率的加法原则（串联系统）和乘法原则（并联系统）进行综合运算，最后得出整个系统的可靠性。

可靠性设计

本小节是整单的重点。

提高系统可靠性的方法，主要是两种：避错和容错。避错主要是指提前做一些措施，避免系统在运行中出现错误。而容错则是指系统在运行中部分组件出现错误，仍然不失效，可以继续运行；或者当数据、文件损坏或丢失后，系统可以自动将这些数据恢复到以前的状态，使系统能够继续正常运行。

测试就是最常用的一种避错技术。而容错则一般使用冗余来实现。

冗余技术

冗余技术是容错的主要手段。主是通过对资源的冗余，包括硬件、软件、信息、时间等，可以使系统的容错性得到较大的提高。

结构冗余

这里又分静态冗余和动态冗余。

静态冗余一般是指增加同样功能的部件，同时运行，最后由表决器对结果进行表决，以多数结果作为系统的最终结果。

动态冗余则是做一些多重的设备储备，当系统检测到某一部件失效时，启用相应的新部件代替它进行工作。这里有检测、切换和恢复的过程，所以称之为动态冗余。这些多余的设备储备，可与主模块一起工作，也可以不工作，分别称为热备份和冷备份。冷备份缺点是当主模块失效时，备份系统可能无法及时衔接上，因为备份机无法获取到原来机器上所有的数据。

其实，我们还可以结合以上两种冗余的优缺点，使用混合冗余的方式，对系统进行结构性冗余设计。

信息冗余

添加一些额外的信息用于保证其正确性。例如：纠错码。

时间冗余

类似结构冗余，不过这里是在同一设备上执行重复计算。

故障恢复策略

如果故障已经发生，则需要一定的方法来恢复故障。一般有两种恢复策略：向前和向后。

向前恢复是指不停止当前的计算，而把系统从不连贯的状态恢复为连贯的正确状态，需要有错误的详细说明。例如我们可以在系统发生故障时，把异常信息都捕获到并存储起来备案，然后尽量让系统继续执行。这也是平常最常用的策略。

后向恢复是把系统恢复到之前的一个状态，然后继续执行。这种方法比较简单，但是却造成程序运行的不连贯性，不适应一些高要求系统，如实时系统。

软件容错

主要有以下几种方式：

恢复块方法

这种方法是一种动态的故障屏蔽技术，采用的是后向恢复策略。它提供相同功能的主模块和多个备用模块，当主功能计算完成后需要进行验证测试，如果测试没有通过，则会使用备用模块进行计算，如果还是没有通过，则继续使用下一个备用模块。

设计时应该保证实现主块和备用块之间的独立性，使其不会相互影响。

N版本程序设计

此法是一种静态故障屏蔽技术，采用前向恢复策略。

采用多个相同功能的N份程序同时运行，使用表决器进行最后结果的表决。

重点在于：

N版本的程序设计应该使用不同的方法，如不同的设计语言、不同的开发环境和工具。

同时，由于N个程序同时运行，最后同时表决，所以需要解决多个程序间的并发性。

防卫式程序设计

此法的基本思想是在程序中包含错误检测代码。一旦错误发生，程序能撤销错误状态，恢复到一个已知和正确状态中去。包括错误检测、破坏估计和错误恢复三个方面。

这种方式主要是以软件的形式来容错，也就是说软件自身有较强的容错性，较为常用。

集群

集群是由两个以上的节点机（一般是服务器）构成的一种松散耦合的计算节点集合，为用户提供网络服务或应用程序（包括数据库、Web服务和文件服务等）的单一客户视图，同时提供接近容错机的故障恢复能力。

一说到集群，一般会想到使用它来为应用程序提供一种可扩展的高性能设计。但是集群同时还可以为应用程序提供较高的容错能力。以下是集群的分类：

高性能计算科学集群、负载均衡集群、高可用性集群

在实际应用中，这三种基本类型经常会混合使用。

硬件配置

（1）镜像服务器双机

使用两台单独的服务器做镜像服务器，之间使用镜像软件通过网络同步数据。镜像服务器的性能比单一服务器的性能要低，适用对集群系统要求不高的用户，

特点：简单、价格最低廉、可靠性较低、占用网络资源、性能较低。

（2）双机和磁盘阵列柜

此方式同样使用双服务器，同时后端的数据存储使用磁盘阵列柜。阵列柜为双机提供逻辑盘阵访问，并不随意扩展新的物理磁盘。

此方式不需要进行数据的同步，所以性能较镜像服务器要高出很多。但是可能会导致“单点错”，即系统中某一部件或某个应用程序发生故障时，导致所有系统全部宕机。如磁盘阵列如果出错，可能会导致存储的数据全部丢失。

特点：性能较高、可能导致单点错误。

（3）光纤通道双机双控集群系统

使用光纤来组建通道进行连接。允许镜像配置。

特点：扩展性强、费用较高。

随着硬件和网络操作系统的发展。集群技术将会在系统可用性、高可靠性和系统冗余方面逐步提高。

（如以后的集群可以依靠集群文件系统实现对系统中所有文件、设备和网络资源的全局访问，并且生成一个完整的系统映像。）

论文阅读总结

可靠性工程

原文链接： http://wenku.baidu.com/view/98b021225901020207409c76.html

该文从工程学的角度来说明了可靠性工程如何开展，并举例说明如何在软件开发过程中应用可靠性工程。

概念及发展

简单的定义：基于软件产品的可靠性进行预测、建模、估计、度量及管理。

其目标是提高软件系统的可靠性。为达到这个目的，我们需要明白失效产生的原因。

核心问题：如何开发出高可靠性的软件；另一问题：如何评估已有系统的可靠性。

在软件开发中的应用

可靠性工程贯穿于软件开发生命周期的各个阶段。

项目开发计划及需求分析阶段

本阶段中，主要是要明确可靠性需求，建立系统的可靠指标。一般情况下，可靠性工作可如下安排：

1）确定功能概图

功能概图主要描述系统中各功能及其使用环境和被使用的概率。

2）对失效进行定义和分类

3）确实用户的可靠性需求

4）平衡性研究

5）建立可靠性指标

软件设计和功能实现阶段

该阶段主要工作：

1）在模块间分配可靠性指标

分解系统为多模块，各模块间分配指标，使得最后计算出的总指标满足需求。

2）按可靠性指标进行设计

有关可靠性设计的内容，参见在上文中内容。

3）根据功能概图集中资源配置

4）控制错误的引入和传播

软件审查（代码审核）、软件测试（单元测试和集成测试）。

5）测试现成软件的可靠性

系统测试和现场试运行阶段

该阶段是保证可靠性的最后阶段。主要工作：

1）确实操作概图

操作概图主要描述系统最后可以使用的各操作（命令）及其使用环境和被使用的概率。

2）可靠性增强测试

系统测试、交付测试。

按照操作概图中的概率执行测试用例，模仿用户的应用方式测试。

3）根据测试来证明是否已经达到可靠性指标

收集失效数据，规划室额外的测试。

4）现场可靠性评估

分析数据，分析差异原因。

维护阶段

主要工作：

1）规划交付使用后的人员需求。

2）监视现场可靠性，并做出适当的调整。

3）监视并维护新功能引起的失效。

4）分析软件交付后失效的产生原因，指导工程改进，降低引入类似错误的可能性。

成功案例

文中以一交换机的研发做为例子，说明可靠性工程的应用，给产品带来了惊人的好处：

问题数下降、维护费用下降、测试件间隔缩短、引入新产品的间隔缩短、客户满意度提升。

原因如下：

⑴把可靠性作为确定是否发行的标准，可避免用户在使用中反映过多问题和进行相应的维护工作。

⑵采用“操作概图驱动”的测试方法，提高了测试效率；20%的操作覆盖了95%的应用，20%的错误导致了95%的实效；先测试20%的使用最频繁的操作可以加速可靠性的提高。

结束语

国内外还未能有系统化的可靠性工程学理论。我们需要不断结合实践进行研究和总结，为使可靠性工作成为有计划、有组织和有目标的研究工作而努力。

高可靠性测试

原文链接： http://tech.it168.com/a2008/0829/202/000000202483.shtml

该文以作者参与的CraftGS系统为例，讲述了如何在系统中应用测试技术保证软件的高可靠性，这些技术包括：软件验证、软件确认、软件测试管理。

综述

高可靠性软件泛指一类软件：该类软件运行过程中若出现故障会引发重大灾难性事故或经济损失。通常航天型号软件、银行系统软件、医疗行业软件、通讯行业软件等均属此范畴。

作者的CraftGS系统就是可靠性要求较高的一个软件系统，其中各子系统的可靠性指标都在0.95以上。

方案：软件验证技术 + 软件确认技术 + 软件测试管理。





验证技术主要是人工完成，方法有：面对面质询、文档抽查、非正式会议、同行评审等等。

软件确认技术则主要着眼于排除程序代码中的错误。目前支持很好的自动化。

工程质量的把控，主要依靠测试管理，分为：“软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理”四大部分。

软件验证技术

主要包含以下方面：

需求规格说明验证

保证用户的所有需求（功能、业务、非功能、约束）都已经被分配到软件需求规格说明的各需求项中。

设计规格说明验证

主要是逐步检查概要设计和详细是否全部分配了之前的分析成果。其中，还要进行数据库设计的验证。

代码验证

包括：代码规范审查、代码审查和代码静态分析。

交付验证

在测试完成后，系统交付客户前，需要进行交付验证和测试。交付验证包括安装验证和使用验证两部分，以确保软件和用户手册匹配。

软件确认技术

其实这里是测试技术。有：

单元测试（白盒）

建构桩模块和驱动模块以驱动被测单元（函数、类、模块）运行，使用设计好的测试用例对各单元进行测试。

集成测试（灰盒）

验证各模块组装后的软件是否能达到概要设计规格说明中模块的设计目标；各模块内部是否存在冲突，保模块能否正常工作。一般采用自底向上按集成度由小到大进行集成测试。

系统测试（黑盒）

检测系统是否满足软件需求规格说明中的各需求项，包括：业务需求、功能需求、非功能需求（质量属性）及约束。虽然不涉及代码，但是由于需求项涉及的领域较广，所以测试方法多而杂，如：

功能测试、执行路径测试、可靠性测试、压力测试、可恢复性测试、可移植性测试……等。

这些测试的特点：在一定环境条件下（如：模拟现场或极端条件），设计并运行各种测试用例，根据测试结果数据，评估软件系统是否符合软件需求项的各类要求。

交付测试

交付测试的主要参与者是目标客户，客户参与越多越好。主要进行：安装测试、可用性测试、alpha测试、beta测试等。

软件测试管理

软件测试团队组织管理

是否能组建一个合适的测试团队，直接影响到测试工作的进展和质量。作者的CraftGS系统中的测试团队，有资深测试专家、测试人员、兼职人员（同行评审）、测试新手。

软件测试计划管理

其实就是安排好测试的流程。

主要有：软件测试策划、软件测试技术剪裁、测试进度管理、成本管理。

软件缺陷（错误）跟踪管理

跟踪一个错误的全生命周期，确保每一个错误都能及时纠正及不引入新的错误。当测试人员提交错误后，需要督促开发团队及时修正，并在修正完成后进行回归测试。一般使用BUG管理系统即可。

软件测试件管理

努力建设好测试团队的财富库并对测试团队成员进行技能培训以帮助他们能使用好这个财富库。

测试件（Testware）是指测试工作形成的产品，包括：实践中积累的经验教训、测试技巧、测试工具、规格文档及一些通用脚本。

测试件管理工作主要是：建设与培训。

结语

目前对高可靠性软件如何实话软件测试技术仍是一个颇不成熟的领域，缺少一种体系化的方法。