| 第 73 贴【 2004 － 8 － 2 】：可测试性技术的产生
可测试性的概念最早产生于航空电子领域。较早的航空电子设备的测试过程通常采用以分析输入 / 输出端口为主的 “ 黑箱 ” 方式进行。随着电子设备功能和结构日益复杂，可靠性、维修性要求日益增高， “ 黑箱 ” 方法已越来越难以满足需求。为此，要求测试人员以更积极的方式介入测试过程，不仅要承担传统测试中激励生成者和响应分析者的角色，而且要成为整个测试过程的主导者和设计者，通过改善被测试对象的设计使其更便于测试，即提高被测对象的可测试性。这种可测试性的思想和概念最早由 F.Liour 等人于 1976 年提出。随后，美国国防部相继颁布了 MIL-STD-471A 通告 II—— 《设备或系统的机内测试、外部测试、故障隔离和可测试性特性要求的验证及评价》、 MIL-STD-470A—— 《系统及设备维修性管理大纲》、 MIL-STD-2165—— 《电子系统及设备的可测试性大纲》等一系列与可测试性相关的标准规范。其中， MIL-STD-2165 可测试性大纲将可测试性作为与可靠性及维修性等同的设计要求，并规定可测试性分析、设计及验证的要求及实施方法，该标准的颁布标志着可测试性作为一门独立学科的确立。
可测试性概念提出后，相继用于电子产品诊断电路设计及研究等各个领域。可测试性技术不仅对维修性设计特性产生重大的影响，而且影响到系统的效能及全寿命周期费用。
第 74 贴【 2004 － 8 － 3 】：可测试性的内涵
1 、可测试性描述了测试信息获取的难易程度
可测试性包括两方面的含义：一方面，便于对软件的内部状态进行控制，即所谓的可控性；另一方面，能够对软件的内部状态进行观测，即可观测性。实际上，可控性和可观测性所描述的就是对软件进行测试时信息获取的难易程度。传统的 “ 黑箱 ” 功能测试方法的根本缺陷就在于它难以获取有效表征被测对象内部状态的信息。
2 、可测试性是软件本身的一种设计特性
同可靠性（ reliability ）一样，可测试性也是软件本身所固有的一种设计特性。软件的可测试性并不是可测试性设计所赋予的，软件一旦设计生产出，本身就具备了一定的可测试性。正如可靠性可以通过 MTBF 等可靠性指标度量一样，可测试性也可以通过可控性、可观测性指标来度量。要改善软件的可测试性指标，必须在软件设计阶段就进行良好的可测试性设计。
3 、可测试性技术的最终目标是提高软件的质量和可靠性，降低全寿命周期费用
降低软件的费用，追求软件的高质量是工业界的永恒主题。目前，单纯合格与否的传统质量标准已转变为综合了性能指标、可靠性及可用性（ availability ）指标要求的 “ 完整质量 ” 概念，而传统的仅考虑软件设计和生产费用的产品费用则被 “ 全寿命周期费用 ” 的概念所替代。全寿命周期费用包括软件整个生命周期中从概念形成到报废处理全过程的费用。
可测试性技术的应用可以极大地提高软件的 “ 完整质量 ” ，降低其全寿命周期费用。一方面，在软件设计阶段，可以对软件设计原型进行虚拟测试，验证设计方案，排除可能的设计缺陷；在生产阶段，可以对软件进行全面的测试，排除软件的潜在故障，从而降低使用过程中的故障率，提高其质量和可靠性；另一方面，可测试性技术可以缩短软件研制、试验和评价的周期，降低软件的研制费用，提高软件的可用性指标，减少软件的维护和保障费用，从而降低软件的全寿命周期费用
第 75 贴【 2004 － 8 － 4 】：可测试性度量
要提高产品的可测试性，首先要对产品的可测试性水平进行描述，也就是进行可测试性度量。可测试性度量方法需满足精确性和简单性两个要求。所谓精确性是指可测试性度量方法能准确地预计产品测试程序生成的困难，并且定位到产品的某一部分，从而便于对产品设计进行更改。而简单性要求则是指度量可测试性的计算量应小于测试程序生成的计算量，否则，可测试性度量方法就会失去实际的应用意义。
第 76 贴【 2004 － 8 － 5 】：可测试性机制的设计与优化
可测试性机制的设计与优化
可测试性设计的过程就是将某种能方便测试进行的可测试性机制引入到软件中，提供获取被测对象内部测试信息的渠道。显然，合理、有效的设计可测试性机制是成功提高软件可测试性水平的基础。可测试性机制的引入可以提高系统的可测试性指标，降低软件的全寿命周期费用，但同时也会在一定程度上提高软件的成本。因此，综合权衡可测试性机制的性能和费用，进行可测试性机制的优化设计是可测试性技术能否成功应用的另一个重要因素。
第 77 贴【 2004 － 8 － 6 】：测试信息的处理与故障诊断
为了实现提高软件质量和可靠性，降低系统全寿命周期费用的目标，要求可测试性技术能够方便、快捷地获取有关被测软件状态的信息，确定软件工作正常与否、性能是否良好、是否存在故障以及存在何种故障，以便于采取调整设计、排除故障、更换备件等后续行为。
在对复杂的对象进行测试时，难点往往不在于如何获取测试信息，而在于如何对所获取的大量信息进行处理。例如：对于一个具有 N 个测点的数字电路而言，所能获取的测试信息的总量为 N*2N 位，随着 N 的增大，测试信息总量呈指数增长。显然，能否对所获取的测试信息进行有效处理并对可能存在的故障进行精确诊断，是可测试性技术成功应用的关键。
第 78 贴【 2004 － 8 － 9 】：特定目标可测试性设计
第一代可测试设计技术：特定目标可测试性设计
第一代可测试性设计技术以外部测试和特定目标可测试性设计方法为基础。特定目标可测试性设计是指：针对特定功能和结构进行可测试性预计，判断其是否符合可测试性要求，若不满足，通过改善设计方案来提高其可测试性，直至满足要求。特定目标可测试性设计主要采用外部测试方法，测试向量的输入和测试响应的输出均通过被测设备的输入 / 输出端口进行操作，对被测对象内部节点的控制和观测则采用以在线（ in-line ）测试技术。其主要缺点如下：
(1) 设计同系统的具体功能和结构紧密相关，对较复杂的系统进行设计的难度大、周期长；
(2) 难以实现并行测试；
(3) 需要专用测试接口和测试工具，成本高；
(4) 随着系统的复杂，采用监控测试方法的适用范围日益减小。
目前，特定目标可测试性设计已逐渐被其他的可测试性技术所代替。尽管如此，对于复杂程度较低的而言，特定目标可测试性设计方法仍然是一种不可或缺的方法。
第 79 贴【 2004 － 8 － 10 】：基于扫描设计的结构化设计
第一代可测试设计技术：基于扫描设计的结构化设计
我们知道，要完成某种系统功能可以采用不同的结构实现。传统的设计思想是尽量选用较为紧凑和简化的结构。然而，由于可测试性同系统的的结构密切相关，上述方法在设计中没有充分考虑结构对系统可测试性的影响，所设计出的系统的可测试性往往较差，将极大地增加可测试性改善设计的难度，这正是特定目标可测试性设计方法的根本缺陷。
结构化可测试性设计是一种新的可测试性设计策略，其主要思想是：从可测试性的观点出发，对结构结构提出一定的设计规则，使得所设计的产品更容易测试。结构化可测试性设计通常采用扫描设计的方法进行，有多种具体的实施方法，包括：扫描设计、扫描通路、扫描置位，等等。它依然存在如下的缺点：
(1) 可测试性设计的过程仍较复杂，设计周期较长，成本较高；
(2) 主要采用外部测试的方法，自动化程度不够，成本仍然较高；
(3) 不同的产品设计厂家采用不同的设计方法，相互之间不兼容，产品的维修性较差。
第 80 贴【 2004 － 8 － 11 】：基于边界扫描机制的标准化设计
第三代可测试性设计技术：基于边界扫描机制的标准化设计
鉴于结构化可测试性设计方法的一些缺点，有必要开发一种更为简单的、标准化的可测试性设计方法。为此，从 1986 ～ 1988 年，以欧洲和北美会员为主的联合测试行动组织（ JTAG ： joint test action group ）率先开展了边界扫描技术的研究，提出了一系列边界扫描标准草案。 1990 年， IEEE 组织和 JTAG 组织共同推出了 IEEE 1149.1 边界扫描标准［ 18,19 ］。
IEEE 1149.1 定义了一种标准的边界扫描结构及其测试接口，其主要思想是：通过在内部逻辑之间，即边界上增加边界扫描单元，实现对状态的串行设定和读取，从而提供芯片级、板级、系统级的标准测试框架。边界扫描机制可以实现下列目标：
(1) 测试不同单元之间的连接；
(2) 测试单元的功能；
(3) 应用边界扫描寄存器完成其他测试功能，如伪随机测试、特征分析、静态测试等；
边界扫描机制提供了一种完整的、标准化的可测试性设计方法。自从边界扫描标准出现以来，市场上支持边界扫描机制及设计开发软件与日俱增，其应用越来越广泛。需要指出的是，边界扫描机制适用于集成度比较高的单元，对于集成度较低的而言，采用结构化可测试性设计方法有可能会得到更为优化的设计结
第 81 贴【 2004 － 8 － 12 】：新的可测试性设计思想
随着科技与经济的发展，为提高产品的质量和竞争力，传统的纵向设计流程必然让位于 “ 并行工程 ” 设计。在并行工程设计环境下，可测试性技术的内涵与设计策略得到了拓展与丰富。在并行工程设计环境下，测试不仅包括了传统意义上的制造阶段以质量保证为目的的测试和使用阶段以诊断维修为目的的测试，而且还包含了产品设计实现阶段以设计验证为目的的测试，以及产品的概念设计和体系结构设计中的可测试性设计过程。并行工程设计环境下可测试性设计策略主要包括：系统可测试性的分级建模与描述策略、可测试性的递阶设计策略以及基于虚拟测试技术的可测试性设计验证策略。
第 82 贴【 2004 － 8 － 13 】：新的可测试性机制体系结构
90 年代中期推出的递阶集成 BIT （ HIBIT ： hierarchical and integrated BIT ）是一种新型的系统级可测试性设计策略，它又被称为第四代的测试性设计技术。所谓 HIBIT 设计是指所设计的可测试性机制具备同系统一样的递阶层次结构，即具备包括系统级、子系统级（ LRU ）、电路板级、多芯片模块级（ MCM ）和芯片级的层次结构，不同层次的可测试性机制之间通过测试总线相连，实质上， HIBIT 技术是边界扫描技术的一种延伸，在 HIBIT 中，板级测试利用 IEEE 1149.1 边界扫描标准进行，而设备级、系统级的测试则通过 IEEE 1149.5 MTM 总线进行。
采用分级递阶与集成可测试性机制便于进行 “ 并行工程 ” 的设计与开发，其主要优点是：便于测试性需求指标的分级分配；便于实现测试复用；便于实现并行分布式的测试进程，提高测试速度。实际上， HIBIT 的最大特点就是引入了 “ 并行过程 ” 的设计思想，在 HIBIT 中采用了并行设计、可复用设计以及虚拟原型设计等并行工程设计方法，这是可测试性设计思想的一次飞跃。
第 83 贴【 2004 － 8 － 14 】：新的测试信息处理技术与故障诊断方法的应用
可测试性应用的关键在于对测试信息进行有效处理，而现有的测试信息处理方法存在故障诊断能力差、虚警率高等问题。为此，有必要将神经网络、专家系统等智能理论引入可测试性技术中，研究新型的测试信息处理技术与故障诊断方法，这是可测试性技术的未来研究重点之一。智能测试信息处理方法主要体现在三个方面：在测试信息的获取阶段，应用数据层信息融合的方法，对通过不同测试手段获取的测试信息进行证实与融合，提高测试信息获取的质量；在信息处理阶段，综合应用数据压缩方法、基于状态模型方法、谱分析以及神经网络方法等，提取准确表征被测对象故障状态的特征信息；在诊断决策阶段，应用马尔可夫模型、神经网络、专家系统等方法，并综合被测对象的环境信息及历史信息进行智能决策，尽可能地消除测试过程中存在的虚警问题，对故障进行精确定位。
第 84 贴【 2004 － 8 － 16 】：协议测试
协议测试已经成为计算机网络和分布式系统协议工程学中最活跃的领域之一。近年来，协议一致性测试技术得到了很好的发展和完善，与此同时，互操作测试和性能测试逐渐成为新的研究热点。
协议测试包括四种测试：
1) 一致性测试（ Conformance ）：检测所实现的系统与协议规范符合程度；
2) 性能测试（ Performance ）：检测协议实体或系统的性能指标（数据传输率、联接时间，执行速度、吞吐量、并发度等）；
3) 互操作性测试（ Interoperability ）：检测同一协议不同实现版本之间、或同一类协议（如电子邮件协议 X.400 和 SMTP ）不同实现版本之间互通能力和互连操作能力
4) 坚固性测试（ Robustness ）：检测协议实体或系统在各种恶劣环境下运行的能力 ( 信道被切断、通信技术掉电、注入干扰报文等 ) 。
第 85 贴【 2004 － 8 － 17 】：可接受测试
用户可接受性测试（ User Acceptance Testing ）有时也叫验收测试。在通过了内部系统测试及软件配置审查之后，就可以开始该项测试了。验收测试是以用户为主的测试。软件开发人员和 QA （质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。验收测试实际上是对整个测试计划进行一种 “ 走读（ Walkthrough ） ” 。
用户可接受测试具有下列特点：
1 、必须要有用户参与，且以用户为主；
2 、可接受测试在不同的组织之间，随目标的不同及工作量的不同而不同；
3 、在软件开发过程当中，可接受测试是最容易变化的一个测试；
4 、用户可接受测试只有按照既定的目标进行的时候才能有真正的效果；
5 、很少有组织能够真正理解如何处理测试中人的方面问题，他们同时还缺乏必要的培训来进行计划和执行一个有效的可接受性测试
第 86 贴【 2004 － 8 － 19 】：标杆测试
系统指标能够描述该产品的基本特性的性能，该指标也可以称为性能指标。系统指标在系统设计初期就会提出来，但是最终产品详细指标如何必须通过严格的测试才可以得到。要根据系统稳定性测试模型，结合系统运行的实际情况对系统进行指标测试或标杆测试（ Benchmark Testing ）。
系统标杆测试的基本概念可以分为两部分：
? 在系统基本配置或最优化配置条件下，通过测试工具等模拟系统环境和提供单一或标准负荷模型，从而得到系统各种表征特性的指标，进一步可以验证系统需求和设计规格中的指标是否达到；
? 在多任务并接近实际网上运行等复杂条件下，由于受 CPU ，内存，存储器，通道，网络，系统配置等资源的影响而测试出系统性能在各方面潜在的低效和限制，比如系统瓶颈，系统指标上限。
第 86 贴【 2004 － 8 － 21 】：在线帮助测试
用户在使用系统时候，如果出现问题，首先求助的就是在线帮助。一个糟糕的在线帮助会很大的打击用户对系统的信心。因此一个好的系统，必须要有完备的帮助体系，包括用户操作手册，实时在线帮助等。在线帮助的测试（ Online Help Testing ）主要用于验证系统的实时在线帮助的可用性和正确性。
在实际操作过程中，在线帮助测试可以和文档测试（或资料测试）一起进行。在进行在线帮助测试的时候，测试人员需要关注下面这些问题：
1 、帮助文件的索引是否正确？
2 、帮助文件的内容是否正确？
3 、在系统运行过程中帮助能否被正常的激活？
4 、在系统不同的位置激活的帮助内容与当前操作内容是否相关联？
5 、帮助是否足够详细并能解决需要被解决的问题？
第 87 贴【 2004 － 8 － 23 】：软件可靠性
软件可靠性（ Software Reliability ）可以定义为：在规定环境，规定时间内（自然单元或时间单元），一个系统或其功能无故障运行的可能性。
其中：
规定的环境包括硬件环境和软件环境。软件环境包括允许的操作系统、应用程序、编译系统、数据库系统等；硬件环境包括 CPU 、内存、 I/O 等。
规定的时间一般分为执行时间、日历时间和时钟时间。其中执行时间（ Executing Time ）是指执行一个程序所用的实际时间和中央处理器时间，或者是程序处于执行过程中的一段时间；日历时间（ Calendar time ）指的是编年时间，包括计算机可能未运行的时间；时钟时间（ Clock time ）是指从程序执行开始到程序执行完毕所经历的钟表时间。
自然单元除时间外，跟软件产品处理数目相关的单元如运行、电话呼叫、 API 调用等都可以看作是一个自然单元。
第 88 贴【 2004 － 8 － 24 】：软件可靠性的层次
从用户角度来看，软件可靠性可以分四个层次来看：
第一个层面：软件不出现故障；
第二个层面：软件即使出现故障，也仅对性能有部分影响，而设备的功能不受损失；
第三个层面：软件出现故障并造成部分功能受损失，但是能够很快恢复业务；
第四个层面：软件出现较大故障，并造成大部分功能受损、业务中断或瘫痪，但能够尽快恢复业务（无论是手工恢复还是自动恢复）；
对应于不同的可靠性层次，要求系统有相应的层次设计要求和维护要求，例如：
对于第一个层面：要求系统能够按照充分的规范来进行设计，加强各种异常处理能力和环境适应能力等；
对于第二个层面：要求系统有较高的容错能力，使用冗余技术和备份技术等；
对于第三个层面：要求系统有很好的可测试性，能迅速隔离问题和定位问题等；
对于第四个层面：要求系统有较高的可维护性等
第 89 贴【 2004 － 8 － 25 】：软件的失效
失效是指功能部件执行其规定功能的能力丧失。
从失效本身的类型来分，又可以分为：
1 、独立失效（ Independent Failure ）：指不是由于另一个产品失效而引起的失效；
2 、从属失效（ Dependent Failure ）：由于另一产品失效而引起的失效。
3 、系统性失效（ Systematic ? Failure ）：由某一固有因素引起，以特定形式出现的失效。它只能通过修改设计、制造工艺、操作程序或其它关联因素来消除。注：无改进措施的修复性维修通常不能消除其失效原因。系统性失效可以通过模拟失效原因来诱发。
4 、偶然失效（ Random Failure ）：产品由于偶然因素引起的失效。只能通过概率或统计方法来预测。
5 、单点失效（ Single-point Failure ）：引起产品失效的，且没有冗余或替代的工作程序作为补救的局部失效。
6 、间歇故障（ Intermittent Failure ）：产品发生故障后，不经修理而在有限时间内自行恢复功能的故障。
7 、渐变失效（ Gradual ? Failure ）：通过事前的检测或监测可以预测到的失效，它是由于产品的规定性能随寿命单位数增加而逐渐变化引起的。对电子产品也称漂移失效 (Drift Failure) 。
8 、致命性失效（ Critical Failure ）：使产品不能完成规定任务的或可能导致人或物重大损失的失效或失效组合。
9 、灾难性失效（ Catastrophic Failure ）：导致人员伤亡或系统毁坏的失效。
10 、非关联失效（ Non-relevant ? Failure ）：已经证实是未按规定的条件使用而引起的失效。或已经证实仅属某项将不采用的设计所引起的失效。
11 、非责任失效（ Non-chargeable Failure ）：非关联失效或事先已经规定不属某组织机构责任范围内的关联失效。
第 90 贴【 2004 － 8 － 26 】：可靠性指标分配
可靠性指标分配是指把系统的可靠性指标分配给系统、子系统、模块、元器件（或函数）。其主要目的是使各级设计人员明确其可靠性设计要求，并研究实现这些要求的可能性及方法。它也是可靠性试验和评估的依据。
对于电子设备，可靠性可以从整机一直分配到各个元器件。可靠性分配的目的就是使各级设计人员明确其可靠性设计要求，根据要求估计所需的人力、时间和资源，并研究实现这个要求的可能性及方法。然而对于软件来说，可靠性分配却有很大的不同，因为把可靠性分解到每一行源代码是没有意义的。对于一个系统，软件可靠性可以作为一个整体来进行考虑，它和硬件可靠性一起组成了整个系统的可靠性。它们直接的关系可以用下面公式表示：
1/MTBF （系） = 1/MTBF （硬） + 1/MTBF （软）
在硬件方面，可靠性分配的时候需要考虑各器件的组合方式（并联还是串联），同时还要考虑各种加权因子（例如重要性因子、复杂因子、环境因子、标准化因子、维修性因子和元器件质量因子）。一般来说，重要的单元应分配较高的可靠性，复杂度高的单元应分配较低的可靠性，处于恶劣环境下的单元应分配较低的可靠性，技术上不成熟的单元应分配较低的可靠性。
总之，对可靠性指标的分配必须做到合理协调、技术上可行、经济上合算。分配的可靠性指标，必须进行可靠性分析，如果分配给分系统的可靠性指标为当前技术水平和条件所限，而无法实现者，必须修改方案，重新分配，直到满足要求为止。
第 91 贴【 2004 － 8 － 27 】： FMEA
故障模式影响分析（ FMEA ）就是在产品设计过程中，通过对产品各组成单元潜在的各种故障模式及其对产品功能的影响进行分析，并把每一个潜在故障模式按它的严酷程度予以分类，提出可以采取的预防改进措施，以提高产品可靠性的一种设计分析方法【 178 】。尽管预计每一个失效模式是不现实的，但是开发组应当尽可能广泛的制定潜在故障模式列表。
通过 FMEA 可以达到如下目的：
能帮助设计者和决策者从各种方案中选择满足可靠性要求的最佳方案；
保证所有元器件的各种故障模式及影响都经过周密考虑；
能找出对系统故障有重大影响的元器件和故障模式，并分析其影响程度；
有助于在设计审议中对有关措施（如冗余措施）、检测设备等作出客观的评价；
能为进一步定量分析提供基础；
能为进一步更改产品设计提供资料；
在设计阶段评价来自客户或其他参与者的需求，避免引入潜在的故障；
在设计阶段跟踪和管理潜在的风险；
保证任何可能产生的失效不会伤害产品或过程的顾客；
提高客户满意度；
为测试和开发提供关注点
第 92 贴【 2004 － 8 － 30 】：故障树分析树
故障树分析（ FTA ）在产品设计过程中，通过对可能造成产品故障的各种因素（包括硬件、软件、环境、人为因素等）进行分析，画出逻辑框图（即故障树），从而确定产品故障原因的各种可能组合方式的一种可靠性分析技术。是用于分析大型复杂系统可靠性、安全性以及故障诊断的一个有力工具。
该方法存在两个问题：
1 、不能表示实时问题；
2 、不能表示系统状态或操作模式；
在使用 FTA 时，需要注意以下问题：
1 、输入的可能性很小；
2 、被动的组件；
3 、对故障树进行定量分析（尽管可以对 FTA 进行量化，但 FTA 不是一个量化分析方法）；
4 、把故障树代替任何别的分析方法；
5 、小心使用布尔表达式；
6 、独立的失效模式与非独立的失效模式对应起来；
7 、确保顶部的事件具有高优先级
第 93 贴【 2004 － 8 － 31 】：事件分析树
事件树分析（ ETA ）可以在 FTA 分析之后开始，它通过分析系统中的一个初始事件，然后考虑这个事件所有可能出现的后续事件，尤其是那些可能导致事故的事件。 ETA 的起始点是那些扰乱正常系统操作的事件，接着它跟踪事件的传递，确定后继系统组件的失效，计算它们失效的可能性及可能的组合（与 / 或）。
ETA 的缺点是：
1 、一个事件的所有可能的后继考虑起来是有困难的；
2 、对于一个复杂的系统，事件树将变得非常复杂，这是因为正常和不正常的所有操作都会显示在事件树中 .
| 
