探测故障的最佳时机是在开发过程的早期。如果使用统一建模语言(UML)，甚至在分析和设计期间就可以发现故障。

       然而，软件的集成和测试十分困难，嵌入式系统更困难，由于输入和输出少，系统的可操作性和可见性都很有限。反常的系统状态尤其难以测试，因为在确定系统在某一状态下的行为前，必须使系统进入该状态。

　　本文提出将测试仪器(instrumentation)代码注入UML模型实现中的观点，目的是提升系统的可控性、可观察性和易测性。测试仪器可应用在开发和目标环境中，并可在模型级进行交互式系统调试。在批处理模式下，测试仪器是数据采集、初始化和测试自动化的基础。本文旨在：简要介绍基于模型的软件工程以及这些模型的实现；概述基于模型的软件的集成测试方法；确定模型系统内重要的运行时间数据和执行关键点；阐述在运行时间采集和操作模型数据的几种方案；使测试仪器能自动进行测试。

　　软件故障是指程序中的错误指令或计算，软件故障的执行将导致软件状态出错。当错误传到输出，并作为一个异常结果呈现在系统外时，故障就会发生。程序的可控性是指一套测试系统强迫被测程序遵循一个特定执行路径的能力，也有可能沿这条路径的执行出错。程序的可观察性是指这套测试系统发现错误状态继而指出故障所在的能力。

　　系统的内部状态对于确定测试的正确性至关重要。系统的输出是由系统的初始状态及其输入决定的。初始状态不同的系统，即便输入相同，输出也会不同。系统的最终状态也必须作为评估测试正确性的一部分予以考虑，因为不正确的内部状态最终会传到系统的输出，并导致错误。系统的复杂性也使得预测系统的正确输出变得愈加困难。

　　初始状态+输入--->最终状态+输出

　　在“黑匣子”测试方法中，只有系统的外部输入和输出可知。需要用一个特殊的测试激励序列将错误传给输出，以便区分错误和正确的程序。所需的特殊序列越长，程序的可测性就越小。与“黑匣子”相似，嵌入式系统的可控性和可观察性也较低。评估最终系统内部状态的结果能缩短检测误差所需的特殊输入序列，从而产生更小、更易处理的测试案例。测试仪器力求同时提高软件程序的可控性和可观察性，以获得更具可测性的程序。

　　在应用代码中使用测试支持仪器的技术是一种“玻璃匣”测试方法。在开发系统的UML模型时，开发者必须了解系统将要完成的任务。基于测试仪器的错误隔离策略可以将UML模型的知识运用于集成测试。系统的操作和状态在分析级比在编码级更具可见性，因为后者受到实现细节的影响。

　　仅从外部输入设置测试的初始系统状态需要特定的外部激励序列。异常状态下的系统操作是很多嵌入式应用中验证的关键，但生成这些初始状态并不简单。本文所描述的技术可利用测试手段，大大提高可控性和可观察性。

　　集成测试的步骤

　　集成测试可分成两个重要阶段，即动态验证和目标集成。动态验证是在开发环境下运行UML模型，其目的在于确定模型的正确性。目标集成涉及到在目标环境中集成软件和硬件。动态验证和目标集成两者都是在分析级上进行的，均使用同样的工具，即测试支持仪器。

　　要尽可能多地进行动态验证测试，其原因有很多：硬件的可用性、硬件/软件的分离、更短的调试周期，以及工具的使用。如果在动态验证的运行测试后，可以确信模型没有问题，目标集成的调试就可以集中在系统组件之间的接口上，或特定平台问题上。