现在嵌入式技术也已经非常的成熟，那么，软件测试工程师如何测试嵌入式软件呢?达内南宁软件测试培训部老师将从以下三点来讲述。

　　第一、当两个或更多独立线程同时访问同一资源时，就出现了竞争条件。竞争条件的影响多种多样，取决于具体的情况。清单1解释了一个潜在的竞争条件。函数Update_Sensor()通过调用get_raw()来读取传感器的原始数据。在处理过程中，该数据被乘上一个定标因子，并加上一个偏移量。处理是在该数据的一个临时副本上进行的，然后，该临时副本被写入共享变量。

　　如果在数据写入之前，使用shared_sensor的另一个线程或ISR先占(preempt)了这个线程，它将得到原来的传感器读数。使用临时副本可以防止先占线程读取只经过部分处理的数据。不过，如果这些代码在一个数据总线不足32位的处理器上运行，就会存在竞争条件。

　　消除竞争条件通常很简单，但找出隐藏在代码中的竞争条件则需要仔细的分析。

　　对于由一个循环程序和不同ISR组成的简单系统，分析竞争条件很简单，只需检查每个ISR并识别它引用的所有共享变量。共享变量通常是这些系统中的全局数据，一旦这些共享变量被找出来之后，就可以检查它们在代码中的各次使用情况。每次访问都必须按需要进行保护，以避免潜在的冲突。 对于使用了优先级不同的多个线程的更为复杂的系统，其分析也非常相似。上述规则仍然适用于ISR使用的所有数据。此外，还必须识别出每个线程使用的共享数据。首先从系统中优先级最高的线程开始，找出它与任何优先级较低的线程共享的所有数据，然后按照上述四条规则进行保护。对于软件使用的其它每个优先级，再重复这一过程。

　　第二、多线程系统通常使用某种类型的操作系统，它能够提供多种保护选择。可以使用互斥或信号量，或者锁定调度器。有时也可使用其它进程间通信(IPC)基本技术：通过向消息队列发送消息(而非修改共享变量)来表示数据已经改变。在许多情况下，最好由单一线程来管理共享资源，它负责处理所有的读写请求，并在内部防止访问冲突。

　　在复杂的代码中辨认潜在的竞争条件可能是一项乏味而又耗时的工作。相应的辅助工具从用来识别全局数据访问的简单脚本到先进的动态分析程序如Polyspace Verifier。虽然比较困难，但详尽的代码分析是识别这类错误的唯一途径。测试不大可能能够建立重复触发竞争条件所需的精确时序序列。

　　在共享资源的系统中，防止访问冲突极为重要，但这有可能导致另一个问题：死锁。当通过"锁定"一个资源来防止任何其它线程访问这个资源，以避免竞争条件时，必须对设计进行评估，确保绝对不会发生死锁。死锁测试通常没有什么效果，因为只有某种特定顺序的资源锁定才可能产生死锁，而一般的测试不大可能导致这种顺序。

　　第三、在一些类型的系统中，预先确定每一个共享资源并建立分配图是不实际或不可能的。此时可以增加一些额外的代码，以便在系统运行时检测出潜在的死锁。许多不同的算法都致力于优化这个检测过程，但本质上它们几乎都动态地建立某种资源分配图。只要有线程请求、分配或释放资源，分配图就会被修改和检测，以确定是否存在表明潜在死锁的循环路径。

　　检测到某个死锁之后，唯一的克服方法是强迫线程释放关键的资源。通常，这意味着中断正保持着所需资源的线程。对于某些应用，这种方法可能是无法接受的。另一个有趣的解决方案是在运行时收集资源分配情况并进行事后分析处理，以确定在程序运行过程中是否有死锁情况发生。尽管这种方法并不能防止在运行时发生死锁，但它确实有助于在死锁出现后发现问题并进行修复。

　　通过以上三点，软件测试工程师会很快掌握嵌入式软件测试的3个技巧，成为嵌入式测试行业中的高手。