可以进行单元测试么_软件测试策略之单元测试

单元测试侧重于软件设计的最小单元(软件构件或模块)的验证工作。利用构件级设计描述作为指南，测试重要的控制路径以发现模块内的错误。测试的相对复杂度和这类测试发现的错误受到单元测试约束范围的限制。单元测试侧重于构件的内部处理逻辑和数据结构。这种类型的测试可以对多个构件并行执行。

单元测试问题。图中对单元测试进行了概要描述。测试模块的接口是为了保证被测程序单元的信息能够正常地流入和流出；检查局部数据结构以确保临时存储的数据在算法的整个执行过程中能维持其完整性；执行控制结构中的所有独立路径(基本路径)以确保模块中的所有语句至少执行一次；测试边界条件确保模块在到达边界值的极限或受限处理的情形下仍能正确执行。最后，要对所有的错误处理路径进行测试。

单元测试·

对穿越模块接口的数据流的测试要在任何其他测试开始之前进行。若数据不能正确地输入/输出,则其他测试都是没有意义的。另外，应当测试局部数据结构，可能的话，在单元测试期间确定对全局数据的局部影响。

在单元测试期间，选择测试的执行路径是最基本的任务。设计测试用例是为了发现因错误计算、不正确的比较或不适当的控制流而引起的错误。

边界测试是最重要的单元测试任务之一。软件通常在边界处出错，也就是说，错误行为往往出现在处理n维数组的第n个元素，或者i次循环的第i次调用，或者遇到允许出现的最大、最小数值时。使用刚好小于、等于或大于最大值和最小值的数据结构、控制流和数值作为测试用例就很有可能发现错误。

好的设计要求能够预置出错条件并设置异常处理路径，以便当错误确实出现时重新确定路径或彻底中断处理。Yourdon称这种方法为防错法( antibugging)。遗憾的是，存在的一种趋势是在软件中引入异常处理，然而却从未对其进行测试。如果已经实现了错误处理路径,就一定要对其进行测试。

在评估异常处理时，应能测试下述的潜在错误：(1)错误描述难以理解；(2)记录的错误与真正遇到的错误不一致；( 3)在异常处理之前，错误条件就引起了操作系统的干预；(4)异常条件处理不正确；(5)错误描述没有提供足够的信息，对确定错误产生原因没有帮助。

单元测试过程。单元测试通常被认为是编码阶段的附属工作。可以在编码开始之前或源代码生成之后进行单元测试的设计。设计信息的评审可以指导建立测试用例，发现前面所讨论的各类错误,每个测试用例都应与一组预期结果联系在一起。

由于构件并不是独立的程序，因此，必须为每个测试单元开发驱动程序和桩程序。单元测试环境如图所示。在大多数应用中，驱动程序只是一个“主程序”，它接收测试用例数据，将这些数据传递给(将要测试的)构件，并打印相关结果。桩程序的作用是替换那些从属于被测构件(或被其调用)的模块。桩程序或“伪程序”使用从属模块的接口，可能做少量的数据操作,提供入口的验证,并将控制返回到被测模块。

单元测试环境

驱动程序和桩程序都意味着测试开销。也就是说，两者都必须编写代码(通常并没有使用正式的设计)，但并不与最终的软件产品一起交付。若驱动程序和桩程序保持简单，实际开销就会比较低。遗憾的是，在只使用“简单”的驱动程序和桩程序的情况下，许多构件是不能完成充分的单元测试的，因此，完整的测试可以延迟到集成测试这一步(这里也要使用驱动程序和桩程序)。