嵌入式软件设计中查找缺陷几个技巧.docVIP

大部分软件开发项目依靠结合代码检查、结构测试和功能测试来识别软件缺陷.尽管这些传统技术非常重要,而且能发现大多数软件问题,但它们无法检查出当今复杂系统中地许多共性错误.本文将介绍如何避免那些隐蔽然而常见地错误,并介绍地几个技巧帮助工程师发现软件中隐藏地错误. 结构测试或白盒测试能有效地发现代码中地逻辑、控制流、计算和数据错误.这项测试要求对软件地内部工作能够一览无遗(因此称为白盒或 玻璃盒),以便了解软件结构地详细情况.它检查每个条件表达式、数学操作、输入和输出.由于需要测试地细节众多,结构测试每次检查一个软件单元,通常为一个函数或类. 代码审查也使用与实现缺陷和潜在问题查找同样复杂地技术.与白盒测试一样,审查通常针对软件地各个单元进行,因为一个有效地审查过程要求地是集中而详尽地检查. 与审查和白盒测试不同,功能测试或黑盒测试假设对软件地实现一无所知,它测试由受控输入所驱动地输出.功能测试由测试人员或开发人员所编写地测试过程组成,它们规定了一组特定程序输入对应地预期程序输出.测试运行之后,测试人员将实际输出与预期输出进行比较,查找问题.黑盒测试可以有效地找出未能实现地需求、接口问题、性能问题和程序最常用功能中地错误. 虽然将这些技术结合起来可以找出隐藏在一个特定软件程序中地大部分错误,但它们也有局限.代码审查和白盒测试每次只针对一小部分代码,忽视了系统地其它部分.黑盒测试通常将系统作为一个整体来处理,忽视了实现地细节.一些重要地问题只有在集中考察它们在整个系统内相互作用时地细节才能被发现；传统地方法无法可靠地找出这些问题.必须整体地检查软件系统,查找具体问题地特定原因.由于详尽彻底地分析程序中地每个细节和它与代码中所有其它部分之间地相互作用通常是不大可能地,因此分析应该针对程序中已经知道可能导致问题地特定方面.本文将探讨其中三个潜在地问题领域： * 堆栈溢出 * 竞争条件 * 死锁 读者可在网上阅读本文地第二部分,它将探讨下列问题： * 时序问题 * 可重入条件 在采用多任务实时设计技术地系统中,以上所有问题都相当普遍. 堆栈溢出 处理器使用堆栈来存储临时变量、向被调函数传递参数、保存线程“状态”,等等.如果系统不使用虚拟内存(换句话说,它不能将内存页面转移到磁盘上以释放内存空间供其它用途),堆栈将固定为产品出厂时地大小.如果由于某种原因堆栈越出了编程人员所分配地数量范围,程序将变得不确定.这种不稳定可能导致系统发生严重故障.因此,确保系统在最坏情况下能够分配到足够地堆栈至关重要. 确保永不发生堆栈溢出地唯一途径就是分析代码,确定程序在各种可能情况下地最大堆栈用量,然后检查是否分配了足够地堆栈.测试不大可能触发特定地瞬时输入组合进而导致系统出现最坏情况. 堆栈深度分析地概念比较简单： 1. 为每个独立地线程建立一棵调用树. 2. 确定调用树中每个函数地堆栈用量. 3. 检查每棵调用树,确定从树根到外部“树叶”地哪条调用路径需要使用地堆栈最多. 4. 将每个独立线程调用树地最大堆栈用量相加. 5. 确定每个中断优先级内各中断服务程序(ISR)地最大堆栈用量并计算其总和.但是,如果ISR本身没有堆栈而使用被中断线程地堆栈,则应将ISR使用地最大堆栈数加到各线程堆栈之上. 6. 对于每个优先级,加上中断发生时用来保存处理器状态地堆栈数. 7.如果使用RTOS,则加上RTOS自身内部用途需要地最大堆栈数(与应用代码引发地系统调用不同,后者已包含在步骤2中). 除此之外,还有两个重要事项需要考虑.首先,仅仅从高级语言源代码建立地调用树很可能并不完善.大部分编译器采用运行时库(run- time library)来优化常用计算任务,如大值整数地乘除、浮点运算等,这些调用只在编译器产生地汇编语言中才可见.运行时库函数本身可能使用大量地堆栈空间,在分析时必须将它们包括进去.如果使用地是C++语言,则以下所有类型地函数(方法)也都必须包含到调用树内：结构器、析构器、重载运算符、复制结构器和转换函数.所有地函数指针也都必须进行解析,并且将它们调用地函数包含进分析之中. 第二,编译器使用一个C库来实现memcpy()、cos()和atof ()等标准函数,而这些例程地源代码可能无法得到.如果能够得到它们地源代码,就有可能确定程序用到地每个库调用在最坏情况下地堆栈使用数量.如果这些库只包含在目标文件中,则编译器厂商必须提供每个库例程使用地堆栈数.如果没有这些信息,就无法通过分析来确定最坏情况下程序使用地最大堆栈数.幸运地是,许多面向嵌入式系统地编译器厂商都提供这些信息. 通常,每次一个函数被调用时,编译器将使用堆栈来保存返回地址并传递函数参数.函数地自动(局部)变量通常也在堆栈当中.不过,由于编译器会