|
- UID
- 1023166
- 性别
- 男
- 来自
- 燕山大学
|
从70年代末的简单控制发展到今天的高端应用，嵌入式系统已经变成一个复杂的高技术系统，要在短时间开发出所需功能的难度大大提升，但是市场竞争又要求产品能够快速面市同时必须确保产品的质量和性能，这里面工具就起着很重要的作用。这其中，对工具的仿真功能更很高的要求。如何帮助工程师完成系统设计，成功地实现让多种内核在同一个系统中的协同工作是嵌入式系统工具必须达到的目标。可以说，是嵌入式开发工具在帮助实现应用。当然，反过来，嵌入式应用的发展也在推动着工具的发展。
目 前应用市场最大、最快的变化就是有越来越多的工程师从4位和8位设计转向了32位设计。对于他们来说，是否有便利的工具帮助他们实现这种无缝转变将是非常 重要的。这就需要工具供应商提供具有这些工程师所熟悉的界面和接口的工具，此外，在32位开发中一般都会用到SDRAM，工具对多种闪存编程的支持也就变 得非常重要。在8位MCU市场上有很多不同供应商提供的产品，在32位市场中也有很多公司提供基于ARM的产品，工具是否能够支持这些来自不同供应商的产 品也很重要。例如旋极公司的TRACE-ICP支持AMD、ATMEL、 FREESCALE、 FUJISTU、 HYNIX、INFINEON、INTEL 、MACRONIX、MICRON、NEC、PHILIPS、SAMSUNG、SHARP、SST、ST、TOSHIBA、WINBOND…等供应商基于 ARM处理器的在线FLASH在线编程、TRACE-ICP支持操作系统调试如：ECOS、 Linux、 Nucleus、 OSE、 pSOS、 QNX、symbian、uclinux、 uC/OS-II、 VxWorks、 WinCE 等。
纵观开发工具领域，目 前越来越多的嵌入式系统软件供应商推出个性化的开发工具套件，但是它们来自不同的供应商，从而导致在通用性支持方面不够好，未来在这方面还需要工具提供商 的共同努力。除提供标准的编译器、编辑器、调试器，还提供增强的操作系统内核级调试手段和高级的系统分析工具，如内存泄漏检测、实时追踪代码的运行等。在 我们对众多客户了解其需求及期望值来看，嵌入式开发工具将向高度集成、编译优化、具有系统设计、可视化建模、仿真和验证功能方向发展！
目前有很多工程师在设计嵌入式系统的时候往往选择最底层的工具，把绝大部分的时间都花在了底层的细节，而往往忽视了创新性和系统级的把握。工程师无论是为了自身的发展还是为了所设计产品的竞争力，这两点其实都是至关重要的。
嵌入式系统的开发通常是硬件和软件同时进行的，其在开发过程中出现不良状况的原因有可能是硬件或是软件，有时甚至可能是两者同时发生故障。在这样的状况下，就要求从事硬件的技术人员要相当程度的懂得软件，从事软件的技术开发人员也要在一定程度上懂得硬件。
目 前该行业存在最终产品的寿命缩短的趋势，这就意味着每年都有必要开发新的产品。但是从初级阶段进行开发，需要花费大量的开发成本及开发时间。因此，有效地 归纳总结现有的开发成果，并有效地投入新开发中加以利用是十分重要的。例如，为了让源代码、电路图等可以直接投入利用，通俗易懂地进行注释是其中
的一种办法。
另外我想谈谈软件测试的质量和软件测试的一些策略！下面我来举几个例子来说明软件测试的其重要性！
1998 年 4 月，美国的一个重要的数据通讯网络出现了长达 24 小时的故障，使大部分美国的信用卡管理系统交易受到影响。受到影响
的还一些大银行、零售商、和政府的数据系统，最后查出是软件故障所致。
1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪，据信这是由于简单的数据转换错误所导致的。人们发现卫星软件中，有些数据使用英制，它们应被转换成公制。这个卫星应当充当另一项任务 中的火星极地着陆项目的通信转发器，那个任务也失败了，原
因不明。已组成一些检查小组试图找出导致错误未能被发现的操作步骤方面的失误。
下面是2002年的欧洲阿丽亚娜5火箭的第一次鉴定发射失败例子；
double d_bh; short s_bh;
sense_horizontal_velocity(&d_bh);
s_bh = d_bh; // OPERAND ERROR
随 着软件测试在庞大软件系统中发挥的作用日益重要，早在60年代软件危机初期，人们就认识到了软件复杂度高，开发周期长，可靠性差，开发和维护费用大等问 题。其中可靠性差就是软件质量问题的集中表现，而软件质量差又是软件维护费用大的主要因素之一。近年来，随着计算机应用领域的迅速扩大，人们对软件质量提 出了新的、更高的要求。在航空应用领域中，软件质量往往关系到人的生命安危。这类称为安全性第一的软件具有高质量要求、高复杂度、高开发代价的特征。其 中，许多安全性第一的软件是实时和嵌入式系统。
软件开发模式以V模型和瀑布模型为主，在这两种开发模型中，软件测试一般分为：单元测试，配置项测试和系统测试。单元测试是开
发单位必须要完成的最底层的测试，一般包括：代码规则检查（走查和审查）、静态分析和动态测试。配置项测试是指的对软件配置项
的功能、性能、冗余、安全等进行测试；系统测试是对整个系统包括外围设备的确认测试。
下面介绍一些测试方法：（如有不对之处请大家多多指教，）
静态分析很重要
Watts S. Humphrey的说法
很多软件工程师认为动态测试比静态测试更重要——并非如此有经验的软件工程师平均每写1000行代码将会出现100个错误80%的软件错误归咎于对于编写语言的错误使用,而这些错误往往不是功能测试能解决的因此,软件工程师应该消除错误,找出根源,预防再次发生同样的问题静态分析的重要内容——代码规则检查
实施简单、方便无需执行程序，与嵌入式环境无关早期介入，代价小，见效快有利于降低动态测试的难度有利于养成良好的编程习惯可以执行自定的规范动态测试不可少
动态测试是验证软件功能最直接、最有效的手段
通过运行被测程序验证其功能、性能，检查代码的执行情况
与静态分析相辅相成
需要事先设计详细、完备的测试用例
可用白盒、黑盒等方法
工作量较大、较枯燥
动态测试的主要内容
功能、性能验证，是否符合需求定义
代码覆盖。哪些代码执行了，哪些没有执行，其比例如何
白盒黑盒相辅成
白盒测试与黑盒测试是软件测试最常用、最常规的两种技术
白盒测试
把测试对象看作一个透明的盒子，测试人员从其逻辑结构入手，设计和选择测试用例，对路径、控制结构、数据流等进行测试
通过插装检查程序的状态，确定是否与预期的状态一致
侧重于代码运行的过程
静态分析也是一种白盒测试
黑盒测试
把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构，只依据其需求定义，检查程序运行的结果
多用于功能测试和性能分析
在程序的接口上进行
需要设计“驱动”和“打桩”
单元集成两步走
单元测试和集成测试是软件测试的两个阶段
单元测试
将被测软件分解为单元，逐个测试
单元测试需要从程序的内部结构和功能出发设计测试用例。
多个模块可以平行地独立进行单元测试
可用白盒、黑盒等方法
集成测试
在单元测试的基础上，将所有模块按照设计要求组装起来测试
主要测试内容
接口间参数传递
集成的功能实现
模块间的影响
先静后动，从小到大
先静态，后动态
从代码规则检查做起
测试开展得越早，付出的代价就越小
静态分析简单、方便，成本低、见效快
静态分析为动态测试打下良好基础
大大降低了测试的成本
先单元，后集成
单元测试是集成测试的基础
单元测试得越好，集成测试的工作量就越小
另外我想重点介绍一下静态规范检查工具！
如 果软件企业都能在代码编写的阶段都能遵循一定的代码规则，这对我们的软件产品的质量将回大有益处，首先，在同一个开发团队中使用代码规则，可以形成这个开 发团队统一的开发风格，产品个性；其次，遵循一定的代码规则，可以提高模块的可移植性和可维护性，最后，代码规则检查也是提高代码质量最有效、最直接的手 段。
目前编码规则检查目前存在的问题是：
1)代码规则检查需要付出很繁重的劳动——重新理解代码，国内一些软件工程发展到现在，已经有了专职的测试人员，即使非常专业的测试人员，理解别人写的代码也是一项很繁琐的工作。
2)时间和资源的限制，我们说，任何一个企业都可以做出优秀的软件，前提是给他足够的时间和物质资源，可现实的软件开发的矛盾却是：在有限的时间内、利用有限的经费，来做高可靠性的软件。
3)很多人不重视代码规则检查，包括很多软件企业的领导、项目负责人等，认为代码规则检查浪费人力和物力，恰恰相反，这种观点就把软件中存在的问题留到了最后，在软件维护过程中会付出昂贵的代价。经验表明，软件中的问题发现的越早，要克服这个问题付出的代价越小 。
国 内的军工行业（包括军队、航天、航空、船舶、兵器）目前也意识到在软件开发中实施代码规则检查的重要性，有些单位已经购置并且搭建了一些代码规则的统一检 查平台，如航天三院、五院统购了QAC工具，并参照GJB5369定制了适合本系统的代码规则院标，推广到所下属各个研究所中。
随着军工行业软件开发管理水平的提高，和GJB5000的推广和实施，推广和实施代码规则检查是刻不容缓的，是必然的趋势。
作者简介
|
|
