1、第4章 单元测试思维导图 基本单元必须具备一定的基本属性，有明确的规格定义，以及包含与其他部分接口的明确定义等，从软件工程的角度来说，具有功能的独立性、符合高内聚和低耦合的特性，并且能够清晰地与同一程序中的其他单元划分开来。对于结构化的编程语言而言，程序单元通常是指程序中定义的函数或子程序，单元测试就是指对函数或子程序所进行的测试。对于面向对象的编程语言而言，程序单元通常指特定的一个具体的类或相关的多个类，单元测试主要是指对类的测试。通常而言，单元测试是在软件开发过程中要进行的最低级别的测试活动，或者说是针对软件设计的最小单位即程序模块、函数、类或方法所进行的正确性检验的测试工作，其目的在于发
2、现每个单元内部可能存在的错误或缺陷。4.1 单元测试概述 在单元测试活动中，软件的独立单元是在与程序的其他部分相隔离的情况下进行测试，主要工作分为两个步骤：人工静态检查（静态测试）和动态执行跟踪（动态测试）。前者主要是保证代码算法的逻辑正确性（尽量通过人工检查发现代码的逻辑错误）、清晰性、规范性、一致性、算法高效性，并尽可能地发现程序中可能存在的错误或缺陷。后者就是通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误或缺陷。一般情况下应该由程序员完成单元测试工作，并且在提交产品代码的同时也提交测试 代码。当然，为了确保软件质量，测试部门可以对其测试工作做一定程度的抽样测试和审核
3、，必要时可以由测试团队专门进行单元测试。4.1 单元测试概述 单元测试的目标就是验证开发人员所编写的编码是否产生预期结果、是否符合设计的要求，最终确保单元符合需求。同时，代码的质量、可复用性、代码的可维护性及代码的可扩展性的检查也是单元测试的目标。符合需求的单元代码通常应该具备以下性质：正确性、清晰性、规范性、一致性、高效性、可复用性等。正确性：代码逻辑必须正确，能够实现预期的功能。清晰性：代码必须简明、易懂，注释准确没有歧义。规范性：代码必须符合企业或部门所定义的共同规范，包括命名规则，代码风格等。一致性：代码必须在命名上（如：相同功能的变量尽量采用相同的标识符）、风格上都保持统一。高效性：
4、代码不但要满足以上性质，而且需要尽可能减少代码的执行时间。可复用性：代码尽量做到可复用、标准化，便于以后重用。4.1 单元测试概述 由于一个模块、函数、类或类中的一个方法（Method）并不是一个能单独运行的独立程序，在进行测试时需要同时考虑该单元和外界的接口，因此要用到一些辅助模块来模拟与所测模块相连的其他模块。一般把这些辅助模块分为两种：(1)驱动模块（driver）：其作用相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果。驱动模块的作用为：接受测试输入 对输入进行判断 将输入传给被测单元，驱动被测单元执行 接受被测单元执行结果，并对结果进行判断 将
5、判断结果作为用例执行结果并输出测试报告4.2 单元测试环境及过程 单元测试环境(2)桩模块（stub）：其代替所测模块调用的子模块。桩模块可以进行少量的数据操作，不需要实现子模块的所有功能，但要根据需要来实现或代替子模块的一部分功能。桩模块是一次性模块，主要是为了配合调用它的父模块工作。通过开发驱动器或（和）桩，被测试模块和与它相关的驱动模块或（和）桩模块共同构 成了一个“测试环境”，如图所示。4.2 单元测试环境及过程 单元测试环境为了确保可以高质量地完成单元测试，在设计桩模块和驱动模块时最好多考虑一些环境因素，如开发环境及测试工具的集成、系统时钟、文件状态（假如，单元模块需要从外部读入数据
6、文件，文件的位置、格式等必须按照要求准备完毕）、单元加载地点、甚至外部设备，以及与实际环境相同的编译器、操作系统、计算机等。在面向对象的系统中，一般以类为测试单元，有时也会以类内方法作为单元。对于包 或子系统而言，可以设计一个测试模块类来做驱动模块，用于测试包中所有的待测试类。最好不要在每个类中用一个测试函数的方法来测试跟踪类中所有的方法。4.2 单元测试环境及过程 单元测试环境单元测试的主要过程如下：（1）详细设计说明书（规约）通过评审。（2）编制单元测试计划（测试经理）。（3）编制子系统单元测试计划（如果需要的话）（开发组）。（4）编写测试代码并开发单元测试用例（开发组）。（5）代码审查（
7、开发组或测试组）。（6）测试用例评审（开发组或测试组）。（7）测试执行（开发组）。（8）缺陷提交（开发组）。（9）缺陷跟踪（开发组或测试组）。（10）测试报告及评审（开发组或测试组）（未通过回到第（4）。4.2 单元测试环境及过程 单元测试过程做好单元测试，提高单元测试的质量，仅仅了解单元测试的技术还远远不够，选择合 适的单元测试策略也至关重要。单元测试的各个组件不是孤立的，是整个系统的组成部分，单元测试需要了解该单元组件在整个系统中的位置，它被哪些组件调用，该单元组件本身又调用哪些组件，最好的情况是在进行单元组件的测试时已经全面地了解了单元组件的层次及调用关系。传统结构化开发和面向对象开发的
8、单元测试的策略是不同的。4.3 单元测试策略 自顶向下的单元测试（1）以单元组件的层次及调用关系为依据，从最顶层开始，把被顶层调用的单元做成桩模块。（2）对第二层单元组件进行测试，如果第二层单元组件又被其上层调用，以上 层已测试的单元代码为依据开发驱动模块来测试第二层单元组件。同时，如果有被第二层单元组件调用的下一层单元组件，则还需依据其下一层单元组件开发桩，桩的数量可以有多个。（3）依此类推，直到全部单元组件测试结束。4.3 单元测试策略 传统结构化开发单元测试策略自顶向下的单元测试优点：因为单元测试是直接或间接地以单元组件的层次及调用关系为依据，所以可以在集成测试之前为系统提供早期的集成途
9、径。由于详细设计一般都是自顶向下进行设计的，这样自顶向下的单元测试策略在顺序上同详细设计一致，因此测试可以与详细设计和编码工作重叠或交叉进行。缺点：由于单元测试需要开发驱动器或（和）桩模块，随着单元测试的不断进行，测试过程也会变得越来越复杂，测试难度以及开发和维护的成本都不断增加；低层次单元组件的结构覆盖率也难以得到保证；由于需求变更或其他原因而必须更改任何一个单元组件时，就必须重新测试该单元下层调用的所有单元；低层单元测试依赖顶层测试，无法进行并行测试，使测试进度受到不同程度的影响，延长了测试周期。4.3 单元测试策略 传统结构化开发单元测试策略自底向上的单元测试（1）以单元组件的层次及调用
10、关系为依据，先对组件调用图上的最底层组件进行测试，模拟调用该组件的模块为驱动模块（器）。（2）对上一层单元组件进行单元测试，开发调用本层单元组件的驱动器，同时，要开发被本层单元组件调用的已经完成单元测试的下层单元组件的桩。驱动器的开发依据调用被测单元组件的代码，桩的开发依据被本层单元组件调用的已经完成单元测试的下层单元组件代码。（3）依此类推，直到全部单元组件测试结束。4.3 单元测试策略 传统结构化开发单元测试策略自底向上的单元测试优点：因为单元组件的层次越靠近下层，组件本身的调用或控制逻辑越少，最底层组件一般是完全处理实际业务的组件，首先进行底层单元组件的测试，无须太多依赖单元组件的层次和
11、调用结构，可以直接从功能设计中获取测试用例；可以为系统提供早期的集成途径；在详细设计文档中缺少结构细节时可以使用该测试策略。缺点：随着单元测试的不断进行，测试过程会变得越来越复杂，测试周期延长，测试和维护的成本增加；随着各个基本单元逐步加入，系统会变得异常庞大，因此测试人员不容易控制；越接近顶层的单元组件的测试，其结构覆盖率就越难以保证。另外，顶层测试易受底层组件变更的影响，任何一个组件修改之后，直接或间接调用该组件的所有单元都要重新测试。由 于只有在底层单元测试完毕之后才能够进行顶层单元的测试，所以并行性不好。另外，自底向上的单元测试也不能和详细设计、编码同步进行。4.3 单元测试策略 传统
12、结构化开发单元测试策略孤立测试步骤：无须考虑每个单元组件与其他组件之间的关系，分别为每个组件单独设计桩模块和驱动模块，逐一完成所有单元组件的测试。优点：该方法简单、容易操作，因此所需测试时间短，能够达到高覆盖率。因为一次测试只需要测试一个单元组件，其驱动模块比自底向上的驱动模块设计简单，而其桩模块的设计也比自顶向下策略中使用的桩模块简单。另外，各组件之间不存在依赖性，所以单元测试可以并行进行。如果在测试中增添人员，可以缩短项目开发时间。缺点：不能为集成测试提供早期的集成途径。设计的多个桩模块和驱动模块不依赖于单元组件 的层次及调用关系，增加了额外的测试成本。4.3 单元测试策略 传统结构化开发
13、单元测试策略一般类测试类的测试包含一系列的校验活动，其主要目的是校验类是否按照其规格说明正确实现 了。如果实现是正确的，那么所有类的实例也应该是正确的。通过执行测试用例或者走查都 可以有效地对类的代码进行测试。类的测试一般是由开发人员完成的，类的测试代码一般被看作是程序的一部分。这样可以降低测试成本，并且测试驱动也可以用来对所写代码进行调试。在进行类测试时，数据设计主要有下面原则：(1)程序是否能处理输入范围以外的数据。(2)程序是否有未考虑到的处理结果。(3)是否造成系统不可预知的错误。4.3 单元测试策略 面向对象开发单元测试策略一般类测试类测试可以采用黑盒测试和白盒测试的方法，可以考虑对
14、类的功能覆盖或达到某种要求 的代码覆盖指标。由于每个类均具有状态图，所有基于状态图的类测试是一种很有效的策略。为了能有效地测试所有的类，根据类的不同行为分成四种类型，并可以用 ADT（Abstract Data Type）图和状态图（State Transition Graph）来加以描述：1)非模态类（non-modale）非模态类不受它的状态的限制，也与方法（Method）调用的顺序无关。2)单模态类（uni-modale）单模态类与它的状态无关，但与调用方法的先后顺序有关。4.3 单元测试策略 面向对象开发单元测试策略一般类测试3)准模态类（quasi-modale）准模态类与它的状态有
15、关，但与它的方法的调用顺序无关。4)模态类（modale）模态类与它的状态以及它的方法的调用顺序都有关。基本测试原则：（1）所有的方法覆盖。（2）所有的状态（所有的节点）覆盖。（3）所有的状态转换（所有的边）覆盖。（4）所有的路径覆盖。4.3 单元测试策略 面向对象开发单元测试策略特殊类测试1)抽象类的测试在面向对象领域，抽象类主要用来进行类型隐藏。用它可以构造出一个固定的一组行为 的抽象描述，但是这组行为却能够有任意个可能的具体实现方式。这个抽象描述就是抽象类，而这一组任意个可能的具体实现则表现为所有可能的派生类。由于一个抽象类没有具体的实现，因此也就没法具体进行测试。但可以用已经测试过的
16、类作为它的具体实现，或创建一些简单、经济的，又能符合规约（specification）的桩（stubs）来具体实现。这样抽象类就能像一般的其他类一样使用不同的测试方法进行测试。4.3 单元测试策略 面向对象开发单元测试策略特殊类测试2)泛型类的测试泛型类封装了不针对任何特定数据类型的操作。泛型类常用于容器（collections）类，如链表、哈希表、栈、队列、树等。在泛型类型或泛型方法的定义中，类型参数仅仅只是一个占位符（placeholder），一般用一个大写字母来表示，如 T。在客户代码声明、实例化该类型的变量时，把 T 替换为客户代码所指定的数据类型。为了测试这些泛型类，必须在对象实例化
17、前必须赋予具体的参数，问题是采用什么样的参数。对于泛型类的测试，一般建议先用一个简单的、经典的类型参数，以便于一个泛型类能像其他一般的类一样测试。一般泛型类的测试驱动器也建议采用泛型类，这样，同一个测试驱动器可重复测试不同的参数类型。4.3 单元测试策略 面向对象开发单元测试策略类测试的建议执行被测类内的所有方法；检查所有的异常情况，包括引发每个输出的异常情况和对异常输入的处理情况；检查被测类是否能到达所有可到达的状态；每个方法都要在对象的每个状态内被调用（如在一个正确的状态，则具有正确的行为。如在一个非正确的状态，则调用应该被拒绝）；保证每个状态的转换是正确的；适度的加载测试、性能测试和错误
18、推测或怀疑测试（suspicion tests）；用划分等价类和检查边界值法检查所有的输入参数和输出值。4.3 单元测试策略 面向对象开发单元测试策略类测试的建议由于类的继承性的特点，在测试父类导出的子类时必须注意如下几点：做扁平化，即将父类的方法和属性加入子类中，子类测试完后删除。对于所有重新定义的方法必须设计新的测试用例并执行这些用例。对于所有导出的子类必须重新执行父类的所有测试用例，因为子类的上下环境不同，对这些不同环境需要分别设计测试用例进行测试。4.3 单元测试策略 面向对象开发单元测试策略(1)检查详细设计是否通过评审并验证其和代码逻辑的一致性，为代码审查和白盒测试用例设计服务。(
19、2)分析单元组件涉及的所有功能点和非功能的需求，为功能性和非功能性用例设计服务。(3)分析单元组件是否满足所有的边界条件，为经典的边界值方法设计用例服务。(4)对强制发生的一些错误情况进行分析，为意外情况设计补充用例服务。(5)分析被测单元组件接口。(6)分析模块内部的数据结构。(7)分析基路径覆盖，为基路径覆盖设计用例服务。(8)分析其他覆盖，为基本覆盖设计用例服务。(9)分析单元出错处理的正确性，为设计出错处理用例服务。4.4 单元测试的分析和用例设计 一般单元测试分析1类的方法随机组合分析如果一个类有多个操作(功能)，这些操作(功能)序列有多种排列，而这种不变化的操作 序列可随机产生，用
20、这种可随机排列的序列来检查不同类实例的生存史，就叫随机测试。2类层次划分的分析 这种测试可以减少用完全相同的方式检查类测试用例的数目。划分测试又可分为三种:基于状态的划分;基于属性的划分;基于类型的划分。3类行为模型的分析 状态转换图(STD)可以用来帮助导出类的动态行为的测试序列，以及这些类与之合作的 类的动态行为测试序列。4.4 单元测试的分析和用例设计 面向对象的单元测试分析一般先设计逻辑测试用例，再依据逻辑用例设计物理测试用例（物理测试用例就是在逻辑测试用例中填入相关测试数据）。在用静态测试技术进行测试时，一般不需要设计具体的用例，按照静态测试技术的要求完成相关工作即可。在用黑盒测试方
21、法设计单元测试用例时，依据分析的功能点，重点考虑测试用例至少覆盖所有最小的功能点一次。用例的设计至少应该考虑以下方面：测试程序单元的所有最小功能点是否覆盖。测试程序单元非功能性是否满足要求，如安全性、可靠性、强度（压力）测试（可选）。考虑可选的其他测试特性，如接口、边界、余量、强制性出错、人机交互界面测试等。4.4 单元测试的分析和用例设计 单元测试用例设计总而言之，要从不同的角度来设计单元测试的用例，如，以类为单元，就应该根据一般的测试用例分析（4.4.1 节）、面向对象的测试用例分析（4.4.2 节）、基于类方法及方法之间调用等覆盖的白盒测试分析（3.2 节）及单元功能点分析的结果来构成测试用例集，并进行评审。测试用例集中要标识测试的优先级、用例执行顺序、前提条件等等。当然，必要时还要补上非功能的测试用例。4.4 单元测试的分析和用例设计 单元测试用例设计
