新闻中心

EEPW首页 > 嵌入式系统 > 设计应用 > 高质量嵌入式系统开发的集成测试技术

高质量嵌入式系统开发的集成测试技术

作者:时间:2009-12-17来源:网络收藏

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

本文引用地址:http://www.eepw.com.cn/article/152221.htm

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

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

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

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

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

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

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

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

  集成测试的步骤

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

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

linux操作系统文章专题:linux操作系统详解(linux不再难懂)

上一页 1 2 下一页

评论


相关推荐

技术专区

关闭