ALAC(Act-like-a-customer)测试： ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

单元测试的基本方法

单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。

单元测试任务

单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。

模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：

1 输入的实际参数与形式参数的个数是否相同；

2 输入的实际参数与形式参数的属性是否匹配；

3 输入的实际参数与形式参数的量纲是否一致；

4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；

5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；

6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；

7 调用预定义函数时所用参数的个数、属性和次序是否正确；

8 是否存在与当前入口点无关的参数引用；

9 是否修改了只读型参数；

10 对全程变量的定义各模块是否一致；

11是否把某些约束作为参数传递。

如果模块内包括外部输入输出，还应该考虑下列因素：

1 文件属性是否正确；

2 OPEN/CLOSE语句是否正确；

3 格式说明与输入输出语句是否匹配；

4缓冲区大小与记录长度是否匹配；

5文件使用前是否已经打开；

6是否处理了文件尾；

7是否处理了输入/输出错误；

8输出信息中是否有文字性错误；

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

1 不合适或不相容的类型说明；

2变量无初值；

3变量初始化或省缺值有错；

4不正确的变量名（拼错或不正确地截断）；

5出现上溢、下溢和地址异常。

除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。

在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：

1 误解或用错了算符优先级；

2混合类型运算；

3变量初值错；

4精度不够；

5表达式符号错。

比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：

1不同数据类型的对象之间进行比较；

2错误地使用逻辑运算符或优先级；

3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；

4比较运算或变量出错；

5循环终止条件或不可能出现；

6迭代发散时不能退出；

7错误地修改了循环变量。

一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：

1输出的出错信息难以理解；

2记录的错误与实际遇到的错误不相符；

3在程序自定义的出错处理段运行之前，系统已介入；

4异常处理不当；

5错误陈述中未能提供足够的定位出错信息。

边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

单元测试过程

一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。

应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。

驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。

提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

综合测试的基本方法

时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。

某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。

1 自顶向下集成

自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。

自顶向下综合测试的具体步骤为：

1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；

2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；

3 每集成一个模块立即测试一遍；

4 只有每组测试完成后，才着手替换下一个桩模块；

5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。

从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。

自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。

2自底向上集成

自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。

自底向上综合测试的步骤分为：

1 把低层模块组织成实现某个子功能的模块群（cluster）;

2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；

3 对每个模块群进行测试；

4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。

ALAC

ALAC 即Apple lossless audio codec的缩写，是苹果公司开发的一种无损音频格式