我看嵌入式工具市场现状与未来

gina

我看嵌入式工具市场现状与未来 [复制链接]

从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 的火星气象卫星失踪，据信这是由于简单的数据转换错误所导致的。人们发现卫星软件中，有些数据使用英制，它们应被转换成公制。这个卫星应当充当另一项任务中的火星极地着陆项目的通信转发器，那个任务也失败了，原
因不明。已组成一些检查小组试图找出导致错误未能被发现的操作步骤方面的失误。
      随着软件测试在庞大软件系统中发挥的作用日益重要，早在60年代软件危机初期，人们就认识到了软件复杂度高，开发周期长，可靠性差，开发和维护费用大等问题。其中可靠性差就是软件质量问题的集中表现，而软件质量差又是软件维护费用大的主要因素之一。近年来，随着计算机应用领域的迅速扩大，人们对软件质量提出了新的、更高的要求。在航空应用领域中，软件质量往往关系到人的生命安危。这类称为安全性第一的软件具有高质量要求、高复杂度、高开发代价的特征。其中，许多安全性第一的软件是实时和嵌入式系统。
      软件开发模式以V模型和瀑布模型为主，在这两种开发模型中，软件测试一般分为：单元测试，配置项测试和系统测试。单元测试是开
发单位必须要完成的最底层的测试，一般包括：代码规则检查（走查和审查）、静态分析和动态测试。配置项测试是指的对软件配置项
的功能、性能、冗余、安全等进行测试；系统测试是对整个系统包括外围设备的确认测试。
      下面介绍一些测试方法：（如有不对之处请大家多多指教，）

静态分析很重要
      Watts S. Humphrey的说法

•       很多软件工程师认为动态测试比静态测试更重要——并非如此
•       有经验的软件工程师平均每写1000行代码将会出现100个错误
•       80%的软件错误归咎于对于编写语言的错误使用,而这些错误往往不是功能测试能解决的
•       因此,软件工程师应该消除错误,找出根源,预防再次发生同样的问题

      静态分析的重要内容——代码规则检查

•       实施简单、方便
•       无需执行程序，与嵌入式环境无关
•       早期介入，代价小，见效快
•       有利于降低动态测试的难度
•       有利于养成良好的编程习惯
•       可以执行自定的规范

动态测试不可少
      动态测试是验证软件功能最直接、最有效的手段
      通过运行被测程序验证其功能、性能，检查代码的执行情况
      与静态分析相辅相成
      需要事先设计详细、完备的测试用例
      可用白盒、黑盒等方法
      工作量较大、较枯燥
      动态测试的主要内容
      功能、性能验证，是否符合需求定义
      代码覆盖。哪些代码执行了，哪些没有执行，其比例如何
白盒黑盒相辅成
      白盒测试与黑盒测试是软件测试最常用、最常规的两种技术
      白盒测试
      把测试对象看作一个透明的盒子，测试人员从其逻辑结构入手，设计和选择测试用例，对路径、控制结构、数据流等进行测试
      通过插装检查程序的状态，确定是否与预期的状态一致
      侧重于代码运行的过程
      静态分析也是一种白盒测试
      黑盒测试
      把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构，只依据其需求定义，检查程序运行的结果
      多用于功能测试和性能分析
      在程序的接口上进行
      需要设计“驱动”和“打桩”

单元集成两步走
      单元测试和集成测试是软件测试的两个阶段
      单元测试
      将被测软件分解为单元，逐个测试
      单元测试需要从程序的内部结构和功能出发设计测试用例。
      多个模块可以平行地独立进行单元测试
      可用白盒、黑盒等方法
      集成测试
      在单元测试的基础上，将所有模块按照设计要求组装起来测试
      主要测试内容
      接口间参数传递
      集成的功能实现
      模块间的影响
      先静后动，从小到大
      先静态，后动态
      从代码规则检查做起
      测试开展得越早，付出的代价就越小
      静态分析简单、方便，成本低、见效快
      静态分析为动态测试打下良好基础
      大大降低了测试的成本
      先单元，后集成
      单元测试是集成测试的基础
      单元测试得越好，集成测试的工作量就越小
      另外我想重点介绍一下静态规范检查工具！
      如果软件企业都能在代码编写的阶段都能遵循一定的代码规则，这对我们的软件产品的质量将回大有益处，首先，在同一个开发团队中使用代码规则，可以形成这个开发团队统一的开发风格，产品个性；其次，遵循一定的代码规则，可以提高模块的可移植性和可维护性，最后，代码规则检查也是提高代码质量最有效、最直接的手段。
      目前编码规则检查目前存在的问题是：
      1)代码规则检查需要付出很繁重的劳动——重新理解代码，国内一些软件工程发展到现在，已经有了专职的测试人员，即使非常专业的测试人员，理解别人写的代码也是一项很繁琐的工作。
      2)时间和资源的限制，我们说，任何一个企业都可以做出优秀的软件，前提是给他足够的时间和物质资源，可现实的软件开发的矛盾却是：在有限的时间内、利用有限的经费，来做高可靠性的软件。
      3)很多人不重视代码规则检查，包括很多软件企业的领导、项目负责人等，认为代码规则检查浪费人力和物力，恰恰相反，这种观点就把软件中存在的问题留到了最后，在软件维护过程中会付出昂贵的代价。经验表明，软件中的问题发现的越早，要克服这个问题付出的代价越小 。
      国内的军工行业（包括军队、航天、航空、船舶、兵器）目前也意识到在软件开发中实施代码规则检查的重要性，有些单位已经购置并且搭建了一些代码规则的统一检查平台，如航天三院、五院统购了QAC工具，并参照GJB5369定制了适合本系统的代码规则院标，推广到所下属各个研究所中。
      随着军工行业软件开发管理水平的提高，和GJB5000的推广和实施，推广和实施代码规则检查是刻不容缓的，是必然的趋势。

gina

软件测试杂谈

　　我想紧接着上一篇就嵌入式软件测试的现状谈一下，首先从中国的国情来说，当国外的研发人员为自己没有把软件缺陷降到最低而苦闷的时候，我们的研发人员则还是为了温饱而苦闷，为什么国内很多研发人员到35岁左右他们就想转行或投身于销售或转做管理，难道是因为他们已经做不了研发，因为公司没有给他们职业规划，他们找不到自己的晋升机会，因为到了这个年龄生活已经不是一个人的事情了，由此导致我们国内IT技术人员放弃多年的研发经验投身于别的产业，这难道不是技术人才的浪费吗？

      让我们再看看软件行业的的研发人员和软件测试人员的人员配置比例，据调查国外软件行业的比例是1：1或1：3，在国内的实际比例是10：1，就工资而言国内的测试人员的工资比研发人员的还低，所以测试人员和开发人员面临同样的问题就是技术熟练的时候转行。测试之所以产生是因为研发不能够把软件缺陷降到最低，所以才有了测试人员，他们的价值因为软件缺陷而存在。缺陷存在，测试存在，缺陷消失，测试也会消失，当然后者是永远不可能的！所以我们中国的软件质量的腾飞就全靠我们的研发人员和测试人员了！相信中国的软件企业也会对越来越对软件质量加以重视，给我们的研发测试人员给予努力的动力！

      我现在就从上一篇文章中我介绍过测试方法，里面有些概念我想在这里做了个解释方便没有做过测试的人了解，也给正在做测试做个参考选择，哪个阶段应该采用哪种测试。希望能对你们有有用的信息。

      黑盒测试 (Black box testing) ── 不考虑内部设计和代码，根据需求和功能进行测试。
      白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。
      部件测试 (Unit testing) ── 最小范围的测试，针对特定的函数和代码模块进行测试。因为需要了解程序的设计和代码的细节才能进行，所以部件测试一般是由程序员，而不是由测试人员来做。除非应用软件的结构设计良好，而且代码也写得清楚，否则部件测试并非易事。也许需要开发测试驱动模块或测试工具。
      递增的综合测试 (incremental integration testing) ── 不断进行的测试过程，每增加一个新的功能模块，都进行测试。这要求一个应用软件在最终完成之前，各功能模块要相对独立，或者已根据需要开发出测试驱动软件。这种测试可由程序员或测试人员进行。
      综合测试 (integration testing) ── 对应用软件的各个部件进行组合测试，来检查各功能模块在一起工作是否正常。“部件”可以是代码模块、独立的应用程序、也可以是网络中的客户/服务器应用软件。这种测试特别适用于客户/服务器环境和分布式系统。
      功能测试 (functional testing) ── 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。)
      系统测试 ── 针对全部需求说明进行黑盒测试，包括系统中所有的部件。
      端到端测试 (end-to-end testing) ── 类似于系统测试，但测试范围更“宏观”一些。模仿实际
      应用环境，对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、
      应用程序和系统之间的相互作用是否满足要求。
      健全测试 (sanity testing) ── 是一种典型的初始测试。判断一个新的软件版本的运行是否正常，是否值得对它作进一步的测试。例如，如果一个新的软件每 5 分钟就破坏系统、大大降低系统的运行速度、或者破坏数据库，那么这样的软件就算不上是“健全”的，不值得在目前状态下进行进一步的测试。
      回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。
      认同测试 (acceptance testing) ── 基于说明书的、由最终用户或顾客来进行的测试。或者由最
      终用户/顾客来进行一段有限时间的使用。
      负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
      压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。
      性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。
      可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。
      安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、部分、升级操作)。
      恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统的情况。
      安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
      兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。
      认同测试 (acceptance testing) ── 看顾客是否对软件满意。
      比较测试 (comparison testing) ── 与竞争产品进行比较，以找出弱点和优势。
      alpha测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
      beta测试 (beta testing) ── 当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

从我们公司从事嵌入式软件测试及软件测试的工具推广来的经验来看，为了更好的遵循一些标准和规则，使代码更具有具有可读性和可维护性，建议对于写 C 和 C++ 代码开发的人员可以参考一下建议：当然不太适合一切情况，仅供参考！
      1、减少或排除全局变量的使用。
      2、使用说明性的函数和方法名 —— 使用大、小写字符，避免用缩写，使用满足要求的说明文字来进行充分的描述 (使用超过 20 个字符也不致超行)。取名要与功能一致。
      3、使用说明性的变量名 —— 使用大、小写字符，避免用缩写，使用满足要求的说明文字来进行充分的描述 (使用超过 20 个字符也不致超行)。取名要与功能一致。
      4、函数和方法的大小要尽可能小 —— 最好不超过 100 行，少于 50 行最好。
      5、在函数代码前面的函数的说明文字应当清楚。
      6、书写代码应便于阅读。
      7、在水平方向和垂直方向都留出足够的空间
      8、每行代码字符数不超过 70 个
      9、每条语句占 1 行
      10、一个程序内的代码风格应一致 (在使用括弧、缩排、和命名方式等方面)
      11、注释内容宁多勿少，通常注释行的数量 (包括开始部分) 应当不少于代码行的数量
      12、不管应用程序多么小，都应有文档，包括程序功能的概述和流程图 (哪怕只有几行字，也比没有要好)。如果可能的话，最好有单独的流程图和详细的程序文档。
      13、尽最大可能使用错误处理过程，并对状况和错误进行记录。
      14、在使用 C++ 时，为了减少复杂程度和提高可维护性，应当避免类的继承的层数过多 (这取决于应用程序的大小和复杂程度)。除要尽量减少继承的层次以外，还应少用超负荷运算符 (minimize use of operator overloading)。使用 Java 语言可以消除多级继承和运算符超负荷。
      15、在使用 C++ 时，保持类的方法不要太大，对于每各类的方法，代码行不超过 50 行为最佳。
      16、在使用 C++ 时，应自由进行例外的处理 (make liberal use of exception handlers)

      软件测试是个大工程，需要开发人员和测试人员协调配合完成，如果开发人员在编程的时候能按照一定准则去编程，这对后面的单元，集成测试也是减少很多压力，当然每个编程人员的编程习惯不一样，所以会按照规范去做，会和自己多年的编程的风格有冲突，所以推动规范还是一件比较有挑战的工作。这也是很多企业遇到的问题。

      下面我就上一篇提到的QAC这个软件测试工具做个介绍；它是英国Programming Research公司的，PR公司是专业从事软件设计方法学和软件编程规范研究的公司，是MISRA的主要起草者，QA C/C++/Java分别是针对三种源代码语言的代码规则检查和静态分析工具，用于鉴别C/C++/Java语言使用过程中出现的问题，这些问题包括语言中比较危险、过于复杂、不可移植、难于维护的特性，或者是编码不符合特定的规则。而这些问题是不能靠编译器或开发工具识别的。为什么要做代码规则检查？是标准要求必须进行的软件质量保证过程。军标Z121、DO-178B标准、CMM/CMMI认证都要求强制进行代码规则检查。GJB5369更进一步规定了C语言编程规范。自动代码规则检查能在软件开发早期早期自动检测出软件错误和安全隐患，能够在软件开发的早期有效保证软件代码的质量；而且可以在同一个开发团队形成统一的代码风格，减少代码维护性和单元/集成测试时间，增加团队凝聚力和提高生产效率。

gina

下面简单衔接一下关于行业内的常见一些认证及标准做了个简要解释；

      1、SEI = “软件工程研究所 (Software Engineering Institute)”，设在卡内基梅隆大学，为改善软件开发过程，由美国国防部创建。
      2、CMM = “性能完善模型 (Capability Maturity Model)”，由 SEI 开发。它是一个分 5 级的、可以描述结构完善程度的模型，用它来说明所交付的软件的效能。它适用于大的机构，例如美国国防部的承包商。所以，它所涉及的许多质量控制过程适用于任何机构，如果合理地利用它，将会获益不浅。一个机构经过权威评审机构的评估，可以得到CMM 等级 (CMM ratings)。
      3、1 级──表现混乱，定期需要应急措施，需要经过很大努力才能完成项目。很少有适当的过程，成功不可重复。
      4、2 级──软件项目跟踪、需求管理、合理计划、以及结构管理过程适当，成功可以重复。
      5、3 级──标准软件开发和维护处理过程完整地在整个机构内贯彻。有一个软件工程处理组来坚实软件过程，开
      设培训课程来确保理解和一致性。
      6、4 级──对生产、处理和产品进行跟踪，项目的特性是可预见的，非常重视质量。
      7、5 级──重视持续地改善处理过程。新的处理过程和新技术的效果是可预见的，在需要时使用它们便可提高效率。
      (关于 CMM 等级的前景：1992-1996 年间，共有 533 个机构经过评估。其中 62% 的机构属于 1 级，23% 为 2 级，13% 为 3 级，2% 为 4 级，0.4% 是 5 级。中等大小的机构有 100 个工程师/维护人员；31% 的机构是美国国防部的承包商。在那些CMM 等级为 1 级的机构里，有问题的关键处理领域在于软件质量保障。)
      8、ISO = “国际标准化组织 (International Organisation for Standards)” ── ISO9001、9002 和9003是针对质量系统的标准，由外部的评估人员进行评价，适用于许多类型的生产和制造机构，而不仅仅适用于软件开发。其中最复杂的是 9001，它被广泛用于软件开发机构。9001 涵盖文档、设计、开发、生产、测试、安装、服务和其他过程。ISO 9000-3 (不是9003) 是 ISO 9001 用于软件开发机构时的指导方针。美国版的 ISO 9000 系列标准与国际版完全相同，被称为 ANSI/ASQ Q9000 系列。美国版可以直接从美国质量协会 (ASQ ── American Society for Quality) 或者 ANSI 购买。一个机构要想获得 ISO 9001 认证，需要有第三方的评价人员进行评估，所获得的认证的有效期为 3 年，届时需要进行再评估。注意：ISO 9000 并不是表明产品质量所必需的，它只是表示文档所规定的处理过程都被遵循。
      9、 IEEE = “电学和电子工程师协会 (Institute of Electrical and Electronics Engineers)” ── 除作其他事情以外，还制定了以下标准：
      10、IEEE/ANSI Standard 829 ── 软件测试文档标准
      11、IEEE/ANSI Standard 1008 ── 软件部件测试 (Unit Testing) 标准
      12、 IEEE/ANSI Standard 730 ── 软件质量保障计划以及其他一些标准。
      13、 ANSI = “美国国家标准协会 (American National Standards Institute)” ── 是美国主要的工业标准实体；与 IEEE 和 ASQ (American Society for Quality ── 美国质量协会) 协力，也出版了一些与软件有关的标准。
      14、除 CMM 或 ISO 9000 以外，其他的软件开发过程评估方法有：SPICE，Trillium，TickIT。和Bootstrap

      MISRA (The Motor Industry Software Reliability Association 汽车工业软件可靠性联会) 是位于英国的一个跨国汽车工业协会，其成员包括了大部分欧美汽车生产商。其核心使命是为汽车工业提供服务和协助，帮助厂方开发安全的、高可靠性的嵌入式软件。这个组织最出名的成果是所谓的MISRA C Coding Standard，这一标准中包括了127条C语言编码标准，通常认为，如果能够完全遵守这些标准，则你的C代码是易读、可靠、可移植和易于维护的。

      DO-178B标准：飞机分成二类：军用飞机与民用飞机。每个国家对军用飞机的研制都有自己的标准和质量监督体系；但对于民用飞机说，由于一个国家研制的飞机会飞到其它国家去，这就要求有一个能够被国际普遍认可的标准和质量体系来保证飞机的安全。具体地说，飞机通常需要通过四个认证以后才可真正投入运营：也即定型认证（Type Certificate）、生产认证（Production Certificate）、适航认证（Airworthiness Certificate）、运营认证（Operational Certificate）。这四个质量认证涉及的标准有很多，构成一整套标准体系，而DO-178B标准则是对机载软件进行适航认证时适用的标准，是整个民航标准体系的比较重要的一个标准。

      执行DO-178B标准质量认证的权威机构在不同的国家和地区不尽相同。在欧洲，该质量认证由EASA（European Aviation Safety Agency）来执行；在美国由FAA（Federal Aviation Administration）执行；在加拿大则由Transport Canada来执行。通常，被一个机构认证通过的飞机在一定条件下也会被另外一个机构默认通过。

      Def Stan 00-55, 1997年9月英国国防颁发了Def Stan 00-55“防务装备中与安全性有关的软件要求”，对如何保证装备安全性对软件提出具体要求。