在嵌入式培训过程中，嵌入式系统开发很多人认为这是一个很难学好的IT行业。嵌入式系统开发包括主要有三大部分：硬件、底层软件和应用软件，硬件和底层软件结合比较紧密，底层软件和应用软件又交互影响，嵌入式的硬件和软件结合是比较紧密的。所以，在学习嵌入式过程中会出现一定的不理解，那么在嵌入式培训与学习过程中的难点是什么呢? 达内讲师为你攻破。

1.事件顺序。当处理事件时，提交下列问题会非常有成效：事件可以此有所不同的顺序抵达吗？假如我们没接管到此事件会怎么样？假如此事件相继爆发两次会怎么样？只不过一般绝不会爆发，但是系统（或是相互作用装置）其他部分的bug也许会造成事件爆发呢。

2.时间过早：这是第一点“事件顺序”的一个特例，但是它的确会引发一些问题，所以我将它单一拿出来解释。比如，假如消息于安装与启动程序完工以前便遭提早接管，那麽也许便会有很多怪异的行为爆发。另一个例子：相连于遭放进空闲列表以前便遭标示作为down。于检修这类问题时，我们常常假设于闲暇列表之中的时候相连遭设立作为down（但是当时为什么绝不将它放在列表里面呢？）。这是我们思维的缺乏，没考量到有时事情会提早爆发。

3.悄无声息的故障：一些最为容易追踪的bug有部分是改由那些静静失利并且拓展因而绝不是抛出正确的代码所造成的。比如，没检查代码反而回到正确的系统初始化（例如bind）。亦如：解析代码于它碰到错误元素的时候只不过回到因而并非抛出错误。于正确状态之中不断了一段时间的调用，会使调试变得越来越容易。最为糟糕只要侦测到故障便回到错误。

4.If：有若干条件的if语句，if &＃40;a 或是 b&＃41; ，尤其是当有链接的时候， if &＃40;x&＃41; else if &＃40;y&＃41;，均予我引起了很多bug。即便if语句于概念之上非常直观，但是当有多个条件要追踪的时候依然非常难错误。这些天，我尝试并重写代码使之越来越直观，以此防止处置简单的if语句。

5.Else：有一些bug是由于没准确考量到假如条件作为false时会爆发什么因而引发的。基本上于所有的情况之下，均应当有一个else部分来应对于每一条if语句。除此之外，假如你于if语句的分支之中设立变量，那麽也许你于另一个分支之中亦要设立。和此种情况有关的是标示遭设立的情况。仅插入用作设立的标记的条件不难，不过非常难忘了添加如果标示应当再度移除时的条件。留下来一个我们设立的标志也许会造成后接连不断的bug。

6.变化假设：许多一起最为容易防治的bug是由于变化了假设所导致的。比如，于起时，也许每天仅有一个客户事件。遂很多代码是于这样的假设之下写下的。不过后来，设计师变化了，容许每天有多个客户事件了。爆发这种情况时，非常容易变化全新设计师冲击到的所有情况。看到有关变化的所有显式依赖关系不难，容易的是要看到所有隐性局限在旧有的设计的情况。比如，也许会有赚取给定某一天所有客户事件的代码。其中的隐含假设是结论集我们绝不会少于客户的数量。

7.日志记录：可视化程序做什么至关重要，尤其是如果逻辑非常简单的时候。保证补足充足余的（但是你们甚余）日志记录，这样你便可解释为什么程序要这么做。假如一切正常，那亦没关系，但是假如有问题爆发，你会非常遗憾自己添加了这些日志。

测试

作为一个开发人员，直到要测试了我便会去处理功能。大约，这意味着每一行全新的或是改变了的代码行大约已遭执行过一次。除此之外，单元测试与功能测试均非常不俗，但是也够。全新的功能亦必需进行测试，并且于类似在产品的环境之中探索。只这样，我便能说我完成了一个功能。上面是我经历过的bug所教会我的有关测试的一些关键的经验教训：

1.零与null：假如合理的话，确保常常使用零和null来测试。对字符串，这意味着要测试长度为零的字符串及字符串作为null两种情况。亦如：测试TCP连接的断开，要于发送数据予它发送以前。绝不使用这些组合方法测试是导致bug出现的首位原因。

2.添加与删除：一般，全新的功能包括能够添加全新的配置到系统之中——例如，一个用于手机号码转换的全新的配置文件。测试它能否添加全新的配置文件是非常大自然的。不过，我发现我们非常难忘记去测试删除配置文件是绝不是同样ok。

3.错误处理：处理错误的代码常常是无法测试的。应该有能检查错误处理代码的自动测试，但是有时候这是绝不可能的。我有时候会使用的一招是临时性修改代码，使得错误处理代码运行起来。要做到这一点最为直观的方法是反转if语句——例如，自if error_count > 0改成error_count == 0。另一个例子是拼错数据库列名，进而导致期望的错误处理代码运行。

4.随机输入：一般，揭露bug测试的一种测试方法是使用概率输入。例如，H.323协议的ASN.1解码使用二进制数据操作。透过发送随机字节去解码，我们发现了解码器之中的几个bug。另一个例子是使用测试呼叫来生成脚本，此时呼叫持续时间，接听延迟，第一方挂断等等均是概率生成的。这些测试脚本会暴露许多bug，尤其是一同发生的事件会产生并拢干扰。

5.检查绝不应该发生的动作：一般测试包括检查期望动作是绝不是发生了。但是我们非常难忽视相反的情况——忘记检查绝不应该发生的动作是绝不是确实没发生。

6.拥有工具：我创建了自己的大工具，以此使得测试更为直观。例如，如果我使用VoIP SIP协议工作时，我写了一个能够使用正是我想要的标题与值回复的大脚本。这个工具使得测试很多边界情况变得难起来。另一个例子是可以进行API调用的一个命令行工具。透过启动渐渐添加所需大功能，我得到了一些十分常用的工具。自己写工具的好处是，我得到的正是我想要的。

于测试之中发现所有的bug，那必然是绝不可能的。有一个案例之中，我越来越改了数字相关性的处理，数字改由两个部分组成：路改由地址后缀（一般是绝不变的），及从000到999动态分配的数字。问题在于如果找到相关性时，动态分配的数字的第一个数字会于呈现于表格中以前遭到误删。也就是说637变成了37。这意味着，至100以前它均是可以工作的，所以，后面100个电话是稳定的，不过接下来的900个均是失败。因此，如果我于再次启动以前能够测试超过100次（事实是我没有），的话我于测试时便绝不会发现这个问题。

调试

1.讨论。帮助我最为余的调试技术是和同事讨论问题。一般情况之下，只不过与同事说明问题，便会让我意识到问题的症结。除此之外，即便他们绝不是非常熟悉有问题的代码，他们亦常常能提出一些好点子。和同事讨论于处理最为容易的bug时尤其精确。

2.紧密关注。一般，假如调试问题花了非常短时间，常常是由于我做了正确的假设。例如，我认为问题发生于某一方法中，但是事实反而是它而且始终没到达那个方法。或是，遭抛出的非常绝不是我以为的那个。或是，我认为软件的全新版本上将要运行，但是实际上是一个旧有版本。所以，某种要核实细节，因而绝不是假设。人们越来越难看到自己希望看到的东西，因而绝不是事实。

3.最近的变化。如果曾可以稳定工作的东西停止工作，那麽这一般是由于最近改变的东西所导致的。于一个案例之中，最近的改变仅是日志记录，不过日志之中的错误反而导致了一个越来越小的问题。借以越来越难找到这种回归，承认有所不同的提交会导致有所不同的变化，及明确说明这些变更会有所裨益。

4.相信用户。有时候，如果用户报告问题的时候，我的本能反应是，“这是绝不可能的。某种是他们做错了什么事”。但是我学会了不必使用这种方式去回应。越来越余的时间，事实常常证明，他们所报告的确实是具体发生的情况。所以，这些天，我开始接受他们所报告的内容的表明价值。或许，我依然会细心检查一切是否遭准确地设置等等。我见过很多这样的情况，让我明白，由于绝不恰当的配置或是意料以外的用法因而导致不可思议的事情的发生，因而我默认的假设是，他们是准确的，程序是正确的。

5.测试修复。假如bug修复已经准备就绪，那便必需进行测试。最先于修复后运行代码，并且观察该bug。接着应用修复并且重复测试案例。至此为止错误行为应消失。遵循这些步骤可以确保它的确是一个bug，并此次修复确实可以解决这个问题。直观因而有适当。