软件自动化测试实例分析(2)

　　测试用例管理

　　1. OO-Test提供了在国内外市场上最全面的测试覆盖分析能力，去满足不同的测试覆盖需求：

　　●类的测试覆盖

　　●函数的测试覆盖

　　●块的覆盖

　　●循环边界的覆盖

　　●分支的覆盖

　　●段的覆盖

　　●条件(判定)的覆盖

　　●段--条件的覆盖

　　2.TCA能确定每一个测试用例作用的范围，通过给出的测试用例就能确定被测试的类，或函数，或段。这种功能对于评估测试用例的效率，和对于修改以后指定的类或函数或段的再测试是非常有用的。

　　3.此外，TCA能从初始测试用例中自动地抽取最小测试用例集，并对基于类的、函数的、分支的、块的、段的覆盖等等各自分别进行划分。它可以对系统级的再测试节省大量的时间和费用。

　　训练新成员

　　1. 提供全面的静态和动态系统分析的能力，能抽取各种信息及自动生成系统文档，并且可以使被抽取的信息让新成员联机访问，大大的节省了设计人员和工程师的时间。

　　2.通过提供最新的和精确的各种系统概貌图和流程图(包括数据结构、类继承图、函数调用图和程序树)，全局数据分析的详细报告，详细的程序逻辑图和源代码的控制流程图，帮助他们了解系统和深入地理解代码。

　　3.使用的GUI接口,使开发组的新成员容易自我训练;具有一个从顶层到详细的代码系统动态的和图形化的表达能力;具有链接不同层次的结构图和流程图在一起的能力。

　　4.提供基于函数分析和流程图化的能力与基于类分析和流程图化的能力，使得一个面向对象的系统很容易被透彻地了解。

　　单元测试的考虑单元测试是要检验程序最小单位(模块)有无错误，它是在编码完成后，首先要施行的测试工作。一般由编码人员自己来完成，因而通常把单元测试看成是编码步骤的附属品。单元测试大多从程序的内部结构出发设计测试用例，即采用白盒测试方法，多个程序模块可以并行地独立开展测试工作。

　　单元测试是针对每个程序模块，解决5个方面的问题：模块接口、局部数据结构、边界条件、独立的路径和错误处理。

　　1.模块接口:

　　对模块接口的测试，是检查进出程序单元的数据流是否正确。对模块接口数据流的测试必须在任何其他测试之前进行，因为如果不能确保数据正确地输入和输出的话，所有的测试都是没有意义的。

　　2.局部数据结构:

　　在模块工作过程中，必须测试其内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。

　　3.独立的路径:

　　在单元测试中，最主要的测试是针对路径的测试。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。

　　4.边界条件:

　　软件常常在边界地区发生问题。

　　5. 错误处理:

　　测试出错处理的要点是模块在工作中发生了错误，其中的出错处理设施是否有效。

　　单元测试的过程

　　单元测试常常和代码编写同步进行，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计。 在对每个模块进行单元测试时，不能完全忽视它们和周围模块的相互联系。为模拟这一联系，在进行单元测试时，需设置若干辅助测试模块。辅助模块有两种，一种是驱动模块(driver)，用以模拟被测模块的上级模块。驱动模块在单元测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。另一种是桩模块(stub)，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口。

　　驱动器和桩都是额外的开销，这两种模块虽然在单元测试中必须编写，但却不作为最终的软件产品提供用户。如果驱动器和桩很简单的话，那么开销相对较低，然后，使用“简单”的模块是不可能进行足够的单元测试的，模块间接口的全面检验要推迟到集成测试时进行。

原文转自：http://www.uml.org.cn/Test/test121901.htm