满足高质量嵌入式系统开发集成测试技术集成测试是用以构造结构系统技术同时还可进行测试以发现接口方面故障UML模型和面向对象软件之间往往存在着很多复杂交互性它妨碍了集成测试将UML分析建模构建方法与相应集成和测试策略相结合可以使高质量嵌入式系统开发更容易 Gregory Eakman
首席顾问
Pathfinder Solutions
[email protected] 探测故障最佳时机是在开发过程早期如果使用统建模语言(UML)甚至在分析和设计期间就可以发现故障然而软件集成和测试十分困难嵌入式系统更困难由于输入和输出少系统可操作性和可见性都很有限反常系统状态尤其难以测试在确定系统在某状态下行为前必须使系统进入该状态 本文提出将测试仪器(instrumentation)代码注入UML模型实现中观点目是提升系统可控性、可观察性和易测性测试仪器可应用在开发和目标环境中并可在模型级进行交互式系统调试在批处理模式下测试仪器是数据采集、化和测试自动化基础本文旨在：简要介绍基于模型软件工程以及这些模型实现；概述基于模型软件集成测试方法；确定模型系统内重要运行时间数据和执行关键点；阐述在运行时间采集和操作模型数据几种方案；使测试仪器能自动进行测试 软件故障是指中指令或计算软件故障执行将导致软件状态出错当传到输出并作为个异常结果呈现在系统外时故障就会发生可控性是指套测试系统强迫被测遵循个特定执行路径能力也有可能沿这条路径执行出错可观察性是指这套测试系统发现状态继而指出故障所在能力 系统内部状态对于确定测试正确性至关重要系统输出是由系统状态及其输入决定状态不同系统即便输入相同输出也会不同系统最终状态也必须作为评估测试正确性部分予以考虑不正确内部状态最终会传到系统输出并导致系统复杂性也使得预测系统正确输出变得愈加困难 状态+输入--->最终状态+输出 在“黑匣子”测试方法中只有系统外部输入和输出可知需要用个特殊测试激励序列将传给输出以便区分和正确所需特殊序列越长可测性就越小与“黑匣子”相似嵌入式系统可控性和可观察性也较低评估最终系统内部状态结果能缩短检测误差所需特殊输入序列从而产生更小、更易处理测试案例测试仪器力求同时提高软件可控性和可观察性以获得更具可测性 在应用代码中使用测试支持仪器技术是种“玻璃匣”测试方法在开发系统UML模型时开发者必须了解系统将要完成任务基于测试仪器隔离策略可以将UML模型知识运用于集成测试系统操作和状态在分析级比在编码级更具可见性后者受到实现细节影响 仅从外部输入设置测试系统状态需要特定外部激励序列异常状态下系统操作是很多嵌入式应用中验证关键但生成这些状态并不简单本文所描述技术可利用测试手段大大提高可控性和可观察性 集成测试步骤 集成测试可分成两个重要阶段即动态验证和目标集成动态验证是在开发环境下运行UML模型其目在于确定模型正确性目标集成涉及到在目标环境中集成软件和硬件动态验证和目标集成两者都是在分析级上进行均使用同样工具即测试支持仪器 要尽可能多地进行动态验证测试其原因有很多：硬件可用性、硬件/软件分离、更短调试周期以及工具使用如果在动态验证运行测试后可以确信模型没有问题目标集成调试就可以集中在系统组件之间接口上或特定平台问题上 a. 用UML建立嵌入式系统模型 将UML模型有效地用于嵌入式应用软件工程要求开发进程能确保：模型是严格而完整；在不影响模型情况下优化所生成系统实现；系统整体结构由进程通过多个版本及要求升级来维持 为达到这些目标基于模型软件工程采用种转换方法重点讨论采用这种转换方法在代码中添加测试支持但该技术也可应用于手工实现UML模型这种转换方法特点将在下文介绍 b. 分析模型 分析是针对问题本身为其建立与实现无关模型方案过程有效分析模型是严密而完整而且与实现方法无关UML是由OMG定义种标准符号主要用于表达分析建模分析过程可以产生： 域(do)模型：这是种UML类图它将系统分解成独立主题区域称为域这些域由包和从属箭头显示桥表示其中后者是域之间需求流(flow of requirement)可以对域进行分析或者用其它方法开发如人工编写代码、继承代码、从其它源生成、从某个库导入等等域服务是组成域接口方法由于域为某个问题区定义了完整规范所以可以独立对其测试然后再与其它域结合以便进步测试
信息模型：对于每个要分析域来说UML类图可用于定义组成该域结构类()类之间互相关联还可继承其它类
情境(scenario)模型：UML序列表或UML协作图捕获某个特定域主要情境用于表现域服务(操作)、类服务(方法)、类事件消息及该域引用域外