扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
嵌入式软件自动测试技术研究
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口嵌入式软件三大潜在问题及其测试技术
10:28:19&&&来源:eefocus &&
本文将介绍如何避免那些隐蔽然而常见的错误，并介绍的几个技巧帮助工程师发现软件中隐藏的错误。大部分项目依靠结合代码检查、结构测试和来识别软件缺陷。尽管这些传统技术非常重要，而且能发现大多数软件问题，但它们无法检查出当今复杂系统中的许多共性错误。结构测试或白盒测试能有效地发现代码中的逻辑、控制流、计算和数据错误。这项测试要求对软件的内部工作能够一览无遗(因此称为"白盒"或"玻璃盒")，以便了解软件结构的详细情况。它检查每个条件表达式、数学操作、输入和输出。由于需要测试的细节众多，结构测试每次检查一个软件单元，通常为一个函数或类。代码审查也使用与实现缺陷和潜在问题查找同样复杂的技术。与白盒测试一样，审查通常针对软件的各个单元进行，因为一个有效的审查过程要求的是集中而详尽的检查。与审查和白盒测试不同，功能测试或黑盒测试假设对软件的实现一无所知，它测试由受控输入所驱动的输出。功能测试由测试人员或开发人员所编写的测试过程组成，它们规定了一组特定程序输入对应的预期程序输出。测试运行之后，测试人员将实际输出与预期输出进行比较，查找问题。黑盒测试可以有效地找出未能实现的需求、接口问题、性能问题和程序最常用功能中的错误。虽然将这些技术结合起来可以找出隐藏在一个特定软件程序中的大部分错误，但它们也有局限。代码审查和白盒测试每次只针对一小部分代码，忽视了系统的其它部分。黑盒测试通常将系统作为一个整体来处理，忽视了实现的细节。一些重要的问题只有在集中考察它们在整个系统内相互作用时的细节才能被发现；传统的方法无法可靠地找出这些问题。必须整体地检查软件系统，查找具体问题的特定原因。由于详尽彻底地分析程序中的每个细节和它与代码中所有其它部分之间的相互作用通常是不大可能的，因此分析应该针对程序中已经知道可能导致问题的特定方面。本文将探讨其中三个潜在的问题领域：* 堆栈溢出* 竞争条件* 死锁读者可在网上阅读本文的第二部分，它将探讨下列问题：* 时序问题* 可重入条件在采用多任务实时设计技术的系统中，以上所有问题都相当普遍。堆栈溢出处理器使用堆栈来存储临时变量、向被调函数传递参数、保存线程“状态”，等等。如果系统不使用虚拟内存(换句话说，它不能将内存页面转移到磁盘上以释放内存空间供其它用途)，堆栈将固定为产品出厂时的大小。如果由于某种原因堆栈越出了编程人员所分配的数量范围，程序将变得不确定。这种不稳定可能导致系统发生严重故障。因此，确保系统在最坏情况下能够分配到足够的堆栈至关重要。确保永不发生的唯一途径就是分析代码，确定程序在各种可能情况下的最大堆栈用量，然后检查是否分配了足够的堆栈。测试不大可能触发特定的瞬时输入组合进而导致系统出现最坏情况。堆栈深度分析的概念比较简单：1. 为每个独立的线程建立一棵调用树。2. 确定调用树中每个函数的堆栈用量。3. 检查每棵调用树，确定从树根到外部“树叶”的哪条调用路径需要使用的堆栈最多。4. 将每个独立线程调用树的最大堆栈用量相加。5. 确定每个中断优先级内各中断服务程序(ISR)的最大堆栈用量并计算其总和。但是，如果ISR本身没有堆栈而使用被中断线程的堆栈，则应将ISR使用的最大堆栈数加到各线程堆栈之上。6. 对于每个优先级，加上中断发生时用来保存处理器状态的堆栈数。7.如果使用RTOS，则加上RTOS自身内部用途需要的最大堆栈数(与应用代码引发的系统调用不同，后者已包含在步骤2中)。除此之外，还有两个重要事项需要考虑。首先，仅仅从高级语言源代码建立的调用树很可能并不完善。大部分编译器采用运行时库(run-time library)来优化常用计算任务，如大值整数的乘除、浮点运算等，这些调用只在编译器产生的汇编语言中才可见。运行时库函数本身可能使用大量的堆栈空间，在分析时必须将它们包括进去。如果使用的是C++语言，则以下所有类型的函数(方法)也都必须包含到调用树内：结构器、析构器、重载运算符、复制结构器和转换函数。所有的函数指针也都必须进行解析，并且将它们调用的函数包含进分析之中。
编辑：什么鱼
本文引用地址：
本周热门资源推荐
EEWORLD独家对嵌入式系统软件可靠性设计的一些看法
版权声明：本文是本人（陈明计）工作成果，版权归广州致远电子有限公司所有。本文原来是准备公开发表的，但因为种种原因，没有发表。因为版权不属于本人，因此禁止转载。
自从40多年前嵌入式系统诞生以来，随着技术的发展和需求的变化，嵌入式系统软件就在嵌入式系统中越来越重要。现在，甚至一些嵌入式系统硬件一模一样，仅仅是软件不同，就是不一样的产品（如交换机和路由器）。
嵌入式系统应用领域千差万别、他们对嵌入式系统的要求和侧重点不尽相同，（如工业控制特别强调可靠性），但基本要求嵌入式系统功能强大、性能稳定、工作可靠。但这3点不是相辅相成的，而是互相之间有矛盾的。
嵌入式系统的功能、稳定性、可靠应与嵌入式系统的硬件、软件都有关系。本文仅讨论版嵌入式系统软件的可靠性设计问题，因此假设嵌入式系统的硬件是稳定可靠的。尽管一些应用可以在不可靠的硬件上通过软件设计获得可靠的产品（如U盘，NAND&FLASH是一个不可靠的存储介质，但通过软件设计，可以得到可靠的存储设备。硬盘更是如此。），但这不在本文的讨论范围之内。
1.2&可靠性与稳定性之间的关系
1.2.1&定律1：越简单的东西越容易做得可靠
相对锤子来说，机械手表足够复杂。如果让一个锤子和一个机械手表都从10层楼高处掉到普通水泥地面，哪个损坏的可能性更大？当然，如果花费大的代价，如使用最好的材料，并增减减震系统，机械手表甚至可以做到锤子摔坏了而手表不坏。不相信？飞行员从几万米高空掉下来不受伤的比比皆是（当然有降落伞啦）。
图1.1&&那个坏了？
从上述说明可知，简单的东西很容易做得高可靠，但复杂的东西要做高可靠花费的代价就高多了。这是普遍原则，对于嵌入式软件也适用。既然如此，哪为什么人们还要做复杂的东西呢？这就涉及第二定律了。
记得大学刚入学时有军训，最后一项是打靶。本班奉命在打靶的前一天下午擦拭打靶用得半自动步枪，具体型号记不得了，但肯定是中国建国后早期生产的。在擦拭前教官给我们讲注意事项，其中有一句是这样的：“一个人擦一把枪，不要把零件搞混，否则装不上的。”也就是说，同样型号的两把枪，同一个零件不能互换！只是因为建国初期的枪都是使用简单的工具制造的，零件的尺寸、质量都不稳定，而一把枪上一些零件间的公差要求较小，只好用人工的方法筛选能够互相配合的零件组装成成品。这样，由于产品的零件的不稳定，造成了同一个型号的产品的零件互不通用。再看一些现在的枪支，不同型号的枪支60%零件可以互换是很正常的，这有设计的原因，同时也要归功于制造工具足够精密复杂，足以制造尺寸质量足够稳定的零件。
图1.2&&安装到哪里？
嵌入式系统软件也是这样。我们的代码越写越大，越写越复杂，很大程度不就是让软件在各种情况下都能够稳定运行吗？
一般普通的锤子必须有一个锤柄和一个锤体，锤柄最简单估计是圆柱体了，锤体也一样。似乎最简单的锤子就是由两个圆柱体组成了，笔者想象不出更简单的锤子。而要把锤子做复杂一些很容易，方法很多，例如在锤子上铸龙雕凤。
图1.3&&礼品锤？
也就是说，在相同的功能与稳定性的前提下，每个系统有一个最小的复杂度。锤子的功能是敲打东西，仅仅是这个功能的话，仅需要一个垂体即可，但那样容易伤到人的手（稳定性不好），所以需要一个锤柄。嵌入式系统软件也是如此。
1.1.1&结论
由上面3条定律可知，系统的稳定和可靠之间有一定的矛盾：提高稳定性容易实现的方式是降低系统的复杂度，这又往往降低了系统的稳定系。同样，提高系统的稳定性又容易降低系统的可靠性。要稳定和可靠都高就需要花费比较大的代价。
1.1&功能与可靠性、稳定性之间的关系
由功能与可靠性、稳定性之间不是孤立的，是互相联系互相制约的，下面详细分析。
1.1.1&定律1：功能的增加是依靠复杂度的增加而增加的
大家知道，普通的锤子只能锤东西，现在需要增加拔钉子的功能，锤体的一端需要改变形状，很显然更难制造了（复杂度增加了）。锤子功能增加了，可是也更难使用也更容易损毁了（锤子拿反了，用拔钉子的一面锤东西）。
图1.4&&普通锤子与多功能锤子
由小节可知，复杂度增加了，要保证同样的可靠性就需要花费更多的代价。显然功能和可靠性也是一对矛盾。
图1.5&&不是这样钉钉子的
1.1.1&定律2：功能的增加可能造成单个功能的复杂度的减少
大家可以找一个目前市场上可以买到的最好的拍照手机，和一个普通的数码相机，比较它们的拍照效果。可以肯定，数码相机的效果更好。原因是拍照手机由于种种限制，不很把其集成的数码相机功能做得与普通数码相机一样复杂（镜头不够精密、闪光灯只能用LED或低挡的氖灯、感光元件也只能用简单的），当然稳定性要差一些了。对于嵌入式软件也是如此，受限于存储空间的大小、人机接口等，嵌入式软件的往往只能简化各个功能代码才能把它们集成在一起。
图1.6&&不比不知道
由小节可知，复杂度降低了，要保证同样的稳定性是就需要花费更多的代价，根据小节，保证同样的稳定性甚至是不可能完成的任务。显然功能和稳定性也是一对矛盾。
1.1.1&结论
由上面2条定律可知，系统的功能和系统的稳定、可靠之间有一定的矛盾。要功能多又要稳定可靠就需要花费比较大的代价。
1.1&增加嵌入式系统软件的可靠性和稳定性的有效方法
1.1.1&优化系统框架设计可以提高系统的稳定系和可靠性
在一定的稳定性和可靠性的基础上，一个系统有一个理论上最小的最小复杂度，但在实际上要达到这个最小复杂度是不可能的。在实际工作中，往往如在锤子上雕花一样，增加了复杂度，不但不会提高系统的稳定性，如果做得不好，反而会降低系统的稳定性。系统的复杂度的增加，要保持原有的可靠性更困难，对提高系统可靠性没有任何帮助。
想要花费比较小的代价提高系统的稳定性和可靠性，比较好的办法就是减少系统不必要的复杂度。而对系统复杂度影响最大的就是系统框架，一个好的系统框架能够抑制系统复杂度的不必要的增加，并且在系统功能变化时对已存在的功能模块的影响降到最低。这样，提高系统的稳定性和可靠性所花费的代价就较低，间接提高了系统的稳定性和可靠性。
图1.7&&还是三角形稳定
1.1.1&稳定可靠来源于严格的测试
人永远不能完全了解世界，因此设计系统时不可能把所有的情况都考虑到。因此，稳定可靠不是嘴说出来的，也不能仅够通过分析系统设计而来确定。
提高稳定性的第二步来自严格的测试，包括先期的设计人员自己测试和中后期的第三方测试。在测试中发现了问题就必须修改设计并重新测试。如此反复，直到在一定的时间内测试不出问题。
1.1.2&稳定可靠来有赖于时间的检验
产品经过严格的内部测试和小批量试产并提供给友好顾客使用后（外部测试），终于大批量上市了。但即使这样，世界级的大公司也会出现产品大规模召回的现象，为什么？
前面说过，人永远不能完全了解世界，因此再严格的测试也不肯能模拟出实际使用过程中的所有情况。这样，用户使用的环境与方法与测试的环境与方法不一致时，产品潜在的不稳定点或不可靠点被暴露出来。如果这些不稳定点或不可靠点是致命的，产品必须被召回。如果不是致命的，也需要改进设计，提高系统的稳定性和可靠性。如此反复。如果系统大量和长时间的使用而不需要改进，说明是稳定可靠的。
图1.8&&千年已过……
1.1.1&因为专业所以稳定可靠
在古代，如果您与专业打铁匠做铁锤，谁的产量和质量稳定可靠呢？显然是打铁匠。为是么？因为您是业余的而打铁匠是专业的。
为是么专业会导致稳定可靠？
最重要的原因是他们已经在这个领域花费了很多代价提高系统的稳定和可靠性（否则就不专业了），他们与非专业的已经不在一条起跑线上，非专业的想在短期内超过专业的是不可能的。
其次，是他们对本领域内的情况非常了解，制定的测试方法与实际情况符合度很高，增加了稳定性和可靠性。
第三，是他们可以利用已经经过时间检验的系统作为新系统的基础，甚至直接使用老系统，不可控的复杂度增加有限，只要花费较小的代价就可以保证系统的稳定性和可靠性。
1.1&结论：专业分工合作是提高嵌入式系统软件的最快最省方法
随着技术的发展和社会的进步，现在用户要求嵌入式系统功能强大、性能稳定、工作可靠。一个系统功能强大、稳定的系统有的比较高的复杂度，但不是所有的复杂度都对系统的可靠性有大的负面影响。一个经过时间检验的可靠模块对系统可靠性的负面影响很小。
但一个强大的系统往往涉及多方面的知识，很多往往还不是自己的专业范围内，自己研发要做到可靠要花费的代价太大，甚至超过收益。此时，寻找专业的合作伙伴提供稳定可靠的模块集成到自己的系统中，自己只做自己专业内的部分，这样，复杂度的各个部分对可靠性的负面影响都较少，同时整体复杂度也容易控制，产品可以较快的上市。
嵌入式系统软件更加适合这种模式。这是因为软件是一种容易复制的东西，复制品的可靠性、稳定性和复杂度都不会改变。专业公司的软件模块一般已经被多个公司在完全不同的环境使用，其功能、稳定性、可靠性都经过严格的检验，不会对自己的系统带来大的负面影响。多个公司使用也分担软件研发的费用，直接使用成本较低。同时，专业公司对自己所属的领域非常了解，他们可以协助用户开发，更进一步降低用户成本。
所以说专业分工合作是提高嵌入式系统软件的最快最省方法。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。