CN104915287A

CN104915287A - 单元测试方法及系统

Info

Publication number: CN104915287A
Application number: CN201410087921.6A
Authority: CN
Inventors: 姜智华; 李皞; 贾鹏
Original assignee: Fuji Xerox Industry Development China Co Ltd
Current assignee: Fuji film industry development (Shanghai) Co.,Ltd.
Priority date: 2014-03-11
Filing date: 2014-03-11
Publication date: 2015-09-16
Anticipated expiration: 2034-03-11
Also published as: CN104915287B

Abstract

本发明提供了一种用于单元测试的方法，包括：向被测文件中的每个单元注入用于测试目的控制代码；定义测试逻辑，测试逻辑包括控制逻辑和验证逻辑，其中控制逻辑被登记在注册表中；执行被测文件测试，执行包括执行被测单元的原始逻辑和被测单元的所调用单元的控制逻辑，其中，控制逻辑由控制代码从注册表中读取和实现；以及基于验证逻辑执行对被测单元的预期逻辑的验证。

Description

单元测试方法及系统

技术领域

本发明涉及软件测试，尤其涉及一种单元测试方法及系统。

背景技术

单元测试是指对软件程序中的最小可测试单元进行检查和验证，以检验程序逻辑的正确性，由此确保所编写程序的代码的行为是否与编程者期望的一致。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的一独立单元将在与程序的其他部分相隔离的情况下进行测试。

对于面向对象的编程语言（例如，C++）来说，因为其所提供的抽象功能相对比较具体，可以比较简单地通过一定的替换技术，将被测单元和其他目标隔离开来，即除了被测单元本身的逻辑保持不变，其他对象均可以是出于测试目的而构造的伪对象，从而达到解除被测单元和其他对象之间耦合的目的，例如JMock。

但是，对于许多较为底层的面向过程的编程语言（例如，C语言），或者一些基于解释器解释执行的脚本语言（例如，Bash Script），在对它们所需要实现的逻辑功能编写单元测试用例的时候，缺乏简单有效的方法来解除被测单元与其它部分之间的耦合，使得编写单元测试用例的人员无法专注于被测逻辑的验证，而在解除耦合的方法上花费了大量不必要的精力。

现有技术的解决方案主要有以下特点和缺陷。

现有技术多采用二进制插桩的方式进行测试控制代码的植入，或者依赖于对于编译后的二进制文件的分析，例如，CN200510126499.1、CN200710117969.7、CN200710121236.0、CN200710129959.5、CN201110380418.6；或者依赖特定编程语言的特定技术来实现其核心功能，例如CN02146712.9、CN200510040422.2。

此类测试方案的问题在于仅能针对特定的CPU体系结构来实现，具有一定的局限性，针对不同CPU体系结构，实现难度大，并且繁琐；又或者仅能针对某一特定的编程语言、或者具有类似特性的语言来实现，如果程序语言不具备类似特性，那么就很难实现。而且，对于解释器解释执行的脚本语言，如果解释器的技术没有公开，此类测试技术也会变得一筹莫展。

现有技术常通过分析源代码、自动插入代码修改其分支路径的执行，以覆盖所有程序的执行分支。为了控制程序的分支执行，代码的自动插入修改了被测单元的原有分支执行逻辑。例如，CN02146712.9、CN200510126499.1、CN201110338915.X、CN200710177534.1。

此类测试手段修改了被测函数的原有逻辑。具体而言，在被测单元原逻辑中的代码插入，其逻辑一致性无法得到保证——即原函数逻辑和修改后的逻辑是否一致，已经无从论证了。因此就算测试通过，只能说明被测程序单元中各条指令的可执行性，但是其逻辑正确性，特别是在多线程、存在竞争的环境中，无从验证。

现有技术多采用和被测文件不一样的编程语言来定义测试脚本，例如，CN02146712.9、CN200510126499.1、CN200710176970.7。此类技术的问题在于开发人员的学习成本增加，无法利用现有编辑工具。

现有技术也不足以应对大规模单元测试的需求。对于大规模的单元测试用例的撰写，依然需要手工编写大量桩函数来控制测试行为；或者因为技术原因，就算编写了桩函数，在不修改代码的情况下，也无法进行插桩操作。

而且，在实际工程实践中，代码重构后如何保证程序的功能依然正确，也是非常重要的一个课题。目前流行的开发方法中，对测试驱动开发（Test-DrivenDevelopment，TDD）的需求也越来越高。但是某些现有技术的单元测试手段并不支持代码重构后的回归测试，或者测试驱动开发。

例如，一些现有技术将已经完成的程序作为输入，以生成执行其中每条语句的测试用例。这类单元测试仅测试程序语句的可执行性，对程序逻辑上的正确性不做验证。因此，不支持重构程序以后的回归测试，以及测试驱动开发的模式，例如CN201110338915.X、CN200710177534.1。

可见，现有技术的单元测试方案在针对面向过程编程测试的通用性上存在局限，在程序逻辑正确性的测试上存在不足，无力应对测试需求量大，测试覆盖率要求高的测试，而且无法用于代码重构后进行的回归测试、或者需要进行测试驱动开发场合的单元测试。因此，本发明亟需一种改进的单元测试方案。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

根据本发明的一方面，提供了一种用于单元测试的方法，包括：向被测文件中的每个单元注入用于测试目的的控制代码；定义测试逻辑，测试逻辑包括控制逻辑和验证逻辑，其中控制逻辑被登记在注册表中；执行被测文件测试，执行包括执行被测单元的原始逻辑和被测单元的所调用单元的控制逻辑，其中，控制逻辑由控制代码从注册表中读取和实现；以及基于验证逻辑执行对被测单元的预期逻辑的验证。

在一实例中，单元包括函数、方法、过程中的任意一者。

在一实例中，控制代码用于在测试执行中按需将每个单元被调用时的执行信息首先记录在注册表中，并对该单元被调用时的行为进行控制。

在一实例中，验证逻辑也被登记在注册表中，其中控制代码在测试执行中根据注册表中的验证逻辑在注册表中记录每个单元被调用时的执行信息。

在一实例中，按需向注册表中记录每个单元被调用时的执行信息包括：记录该单元的本次调用；和/或记录该单元被调用时的参数。

在一实例中，执行验证包括：从注册表中读取执行信息；以及基于执行信息和验证逻辑执行验证。

在一实例中，对被测单元的预期逻辑的验证包括以下至少一者：验证被测单元的所调用单元是否按照预期的调用顺序被执行；验证被测单元的所调用单元每次被调用时的参数是否为预期值；以及验证被测单元是否返回预定值。

在一实例中，对每个单元被调用时的行为进行控制至少包括：单元替换判断，包括：判断该单元是否需要被替换为替换单元，若是，则将参数代入替换单元执行以返回执行结果，结束该单元的调用，以及若否，则进入参数修改判断；参数修改判断，包括：判断是否需要修改该单元的参数，若是，则将该单元的参数修改为指定值，并进入指定值返回判断，以及若否，则进入指定值返回判断；指定值返回判断，包括：判断是否需要为该单元返回指定值，若是，则直接返回指定值，结束该单元的调用，若否，则执行该单元的原始逻辑。

在一实例中，控制逻辑用于根据测试目的在测试执行中对每个单元被调用时的行为进行设置，以及验证逻辑用于声明需要记录以待验证的信息。

在一实例中，对每个单元被调用时的行为的设置包括以下至少一者：用替换单元来替代该单元的执行；将该单元的参数修改为指定值；以及为该单元强制返回指定值。

在一实例中，需要记录以待验证的信息包括以下至少一者：需要记录其调用顺序的单元；以及在单元被调用时需要记录其值的参数。

在一实例中，注入控制代码包括：对被测文件执行词法分析和语法分析以生成抽象语法树；对作为抽象语法树上的每个单元的节点注入控制代码；以及将注入了控制代码的抽象语法树转换回被测文件。

在一实例中，控制代码是由被测文件语言编写的统一格式的指令。

在一实例中，测试逻辑由测试脚本定义，测试脚本由设置脚本、验证脚本和被测文件语言所支持的其他语句构成，其中，设置脚本在注册表中登记控制逻辑，以及验证脚本在注册表中登记验证逻辑。

在一实例中，测试脚本由被测文件语言所编写。

根据本发明的另一方面，提供了一种用于单元测试的系统，包括：注入器，注入器用于向被测文件中的每个单元注入用于测试目的的控制代码；测试逻辑设置模块，测试逻辑设置模块用于定义测试逻辑，测试逻辑包括控制逻辑和验证逻辑，其中控制逻辑被登记在注册表中；测试执行模块，测试执行模块用于执行被测文件测试，执行包括执行被测单元的原始逻辑和被测单元的所调用单元的控制逻辑，其中，控制逻辑由控制代码从注册表中读取和实现；以及验证模块，验证模块基于验证逻辑执行对被测单元的预期逻辑的验证。

在一实例中，单元包括函数、方法、过程中的任意一者。

在一实例中，向注册表中按需记录每个单元被调用时的执行信息包括：记录该单元的本次调用；和/或记录该单元被调用时的参数。

在一实例中，验证模块还用于：从注册表中读取执行信息；以及基于执行信息和验证逻辑执行验证。

在一实例中，验证模块对被测单元的预期逻辑的验证包括以下至少一者：验证被测单元的所调用单元是否按照预期的调用顺序被执行；验证被测单元的所调用单元每次被调用时的参数是否为预期值；以及验证被测单元是否返回预定值。

在一实例中，注入器还用于对被测文件执行词法分析和语法分析以生成抽象语法树；对作为抽象语法树上的每个单元的节点注入控制代码；以及将注入了控制代码的抽象语法树转换回被测文件。

在一实例中，注入器包括以下至少一者：开源编译器的前端和/或通用词法/语法分析器。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1是示出了根据本发明的一方面的单元测试框架的示意图；

图2是示出了根据本发明的一方面的控制代码注入过程的序列图；

图3是示出了根据本发明的一方面的在注入了控制代码后单个单元被调用时的执行流程图；

图4是示出了根据本发明的一方面的测试逻辑设置过程的序列图；

图5是示出了根据本发明的一方面的测试执行过程的序列图；

图6是示出了根据本发明的一方面的验证过程的序列图；

图7是示出了根据本发明的一方面的单元测试方法的流程图；以及

图8是示出了根据本发明的一方面的单元测试系统的框图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1是示出了根据本发明的一方面的单元测试框架100的示意图。如图1所示，单元测试框架100可包括注入器101和注册表103。注入器101可向被测文件110中的每个单元注入用于测试目的的控制代码102，并保持其余的源代码逻辑不变。注册表103是可用被测文件对应的编程语言实现的全局存在的记录媒介，通过对注册表103的读取和写入可以实现单元测试框架100的各组件之间的相互。

控制代码102可用于在测试执行中将每个单元被调用时的执行信息首先记录在注册表103中，并对该单元被调用时的行为进行控制。这里的术语“单元”可以是被测文件中任何具有参数和/或返回值的一系列指令的集合，取决于不同的编程语言环境，单元可以是函数、方法、过程、例程等等。

控制代码102可以是由被测文件语言编写的统一格式的指令。被测文件110由众多的单元构成，这些单元中的每个单元在被测文件110的测试中可以有不同的角色。例如，某一单元可能是被测文件110中当前正在测试的被测单元，也可能是被测单元调用的单元。这里的“统一格式”是指对被测文件110中的所有单元都进行控制代码102的注入。当在测试执行中，任一单元作为被调用单元被当前的被测单元调用时，该单元中注入的控制代码102就会起作用，即在注册表103中记录该单元被调用的执行信息，然后对该单元的行为进行控制。

例如，在测试中，若某一单元是当前被测单元的所调用单元，则控制代码102就会按照测试需要记录下该单元被调用的执行信息，包括但不限于：记录该单元的本次调用，和/或记录该单元的调用参数。在后续验证阶段，可针对被测单元的预期逻辑对所记录的这些执行信息进行验证。

随后，控制代码102还会对该单元被调用的行为进行控制，例如，可包括但不限于：单元替换判断、参数修改判断和指定值返回判断。在单元替换判断中，判断该单元是否需要被替换为替换单元，若是，则将参数代入该替换单元执行以返回执行结果，并结束该单元的调用；在参数修改判断中，判断是否需要修改该单元的参数，若是，则将该单元的参数修改为指定值并进入指定值返回判断，若否，则进入指定值返回判断；在指定值返回判断中，判断是否需要为该单元返回指定值，若是，则直接返回指定值并结束该单元的调用，若否，则执行该单元的原始逻辑。如本领域技术领域所熟知的，这里的替换单元是指为测试目的专门编写的伪单元，例如在C语言编程环境中，该替换单元即为桩函数。

单元测试框架100还可包括测试脚本104，测试脚本104可由设置脚本105、验证脚本106和被测语言所支持的其他语句构成。测试脚本104可用于定义测试逻辑以用于测试被测文件中的各个单元。具体地，测试逻辑可包括控制逻辑和验证逻辑，其中设置脚本105可向注册表103中登记控制逻辑，以及验证脚本106可向注册表103中登记验证逻辑。

设置脚本105登记在注册表103中的控制逻辑可用于根据测试目的在测试执行中对每个单元被调用时的行为进行设置，使其满足被测单元的测试需要。在一实例中，在测试执行中，若某一单元被被测单元所调用，则对该被调用的单元的行为的设置可包括以下至少一者：用替换单元来替代该单元的执行，将该单元的参数修改为指定值，以及为该单元强制返回指定值。

控制逻辑的执行是借助于被测文件110的每个单元中所注入的控制代码102来实现的。具体地，在一单元被调用时，该单元中所注入的控制代码102就会从注册表103中读取预先登记的控制逻辑并实现该控制逻辑，从而达到修改、控制该单元被调用时的行为的目的。

以上述控制代码102对单元调用执行的控制行为的实例为例，某一单元在被被测单元调用时，其行为受到控制代码102的控制，以使得执行例如单元替换判断，即判断是否需要被替换为替换单元，并且，控制代码102会读取注册表103中的控制逻辑，若控制逻辑设置了用替换单元来替代该单元的执行这一行为，则进行替换单元替换，从而实现为了测试目的所设置的替换单元替换这一行为。再例如，单元在被被测单元调用时，其行为受到控制代码102的控制，以使得执行参数修改判断，即判断是否需要修改该单元的参数，此时控制代码102会读取注册表103中的控制逻辑，若控制逻辑设置了修改该单元的参数这一行为，则进行参数修改，从而实现为了测试目的所设置的参数修改这一行为。再例如，单元在被被测单元调用时，其行为受到控制代码102的控制，以使得执行指定值返回判断，即判断是否需要为该单元直接返回指定值，此时控制代码102还会读取注册表103中的控制逻辑，若控制逻辑设置了返回指定值这一行为，则为该单元直接返回指定值，从而实现为了测试目的所设置的返回指定值这一行为。

被测文件110中注入的控制代码102以及设置脚本105所登记的控制逻辑可以让测试人员在不修改被测文件的前提下，按照测试需要临时修改单元（例如函数）的行为，从而直观有效地解除单元间的耦合，让测试有针对性地仅对被测单元进行。测试完成后，设置脚本105便不再产生作用，被测文件中不会存在无关的测试代码。

验证脚本106登记在注册表103中的验证逻辑可用于声明需要记录以待验证的信息，这些信息可包括但不限于，需要记录其调用顺序的单元，和/或在单元被调用时需要记录其值的参数。这些信息是测试人员用于验证被测单元的预期逻辑的基准，它们被保持在注册表103中，待到执行测试以及验证时，这些信息将作为验证依据被动态提取，以对如上所述的在测试执行中所记录的实际执行信息进行验证。例如，在被测文件执行后，可从注册表103中读取执行信息，并基于该执行信息和验证逻辑来执行验证。

在一实例中，测试人员希望验证的预期逻辑可包括但不限于，验证被测单元的所调用单元是否按照预期的调用顺序被执行，验证被测单元的所调用单元每次被调用时的参数是否为预期值，以及验证被测单元是否返回预定值。

上文列举了控制代码对单元被调用时的行为控制和执行信息的记录、控制逻辑对被调用单元的行为设置、以及验证信息所声明的需要记录以待验证的信息，然而本领域技术人员容易知道，根据不同的测试目的和需要，可以定义其他的控制行为、设置行为、执行信息、以及待验证信息。

在本发明的方案中，可由设置脚本105在软件程序执行前（甚至包括在编写完成前），向注册表103中登记测试用的控制逻辑，并由控制代码102在软件程序执行时读取和实现；另外可由验证脚本106在软件程序执行前（甚至包括在编写完成前），向注册表103中登记测试用的验证逻辑，并在软件程序执行时由控制代码102向注册表103中写入对应的执行信息，供软件程序执行后由验证脚本106读取并验证。通过本发明，可以根据测试人员的测试需要，通过控制代码102和控制逻辑来临时修改单元的行为，有效地解除单元间的耦合，并结合符合测试需要的验证逻辑，让测试有效地针对被测单元进行。

图2是示出了根据本发明的一方面的控制代码注入过程的序列图200。如图2所示，测试/集成环境210可调用注入器220。注入器220可对被测文件执行词法分析和语法分析以生成抽象语法树，然后对作为该抽象语法树上的每个单元的节点注入控制代码。例如，在单元为函数（或方法、过程）的情况下，注入器220可对抽象语法树上每个类型为函数（或方法、过程）的节点，注入所需要的控制代码。注入完成后，再将注入了控制代码的抽象语法树重新转换为被测文件。这样一来，被测文件中的每个测试对象单元就能够按照测试目的的需要来控制执行。

由于抽象语法树的生成仅仅需要进行语法分析和词法分析，因此注入器220可以利用开源的编译器的前端，也可以利用自动的语法、词法分析器生成工具，比如Lex/Yacc等来实现。

根据本发明的一方面，利用了词法分析和语法分析这两种特有的、和程序的编译器所采用的方案相同的技术手段，对计算机程序进行“源到源”的转换，因此只要编译器具备正确的执行功能，那么控制代码的插入也就是正常的。相比于现有技术中一些针对目标文件插入二进制代码的控制代码插入，难度小很多，而针对不同体系结构也不需要动脑筋插入不同的二进制代码，这一切都是由编译器自动完成的。换言之，本发明的方案是在源文件语法级别进行的控制，因此如果支持某一种语言，那么真正意义上的“完整支持”所有这一语言已经支持的CPU体系架构。

同时，对于任何还不支持的语言，对其实现新的支持，仅需要采用开源编译器的现有代码，或者采用类似Lex/Yacc这种通用的词法/语法分析器，就可以较现有技术容易得多地实现控制代码的注入。同时可靠性和正确性是这一新语言的编译器所保证的，出错的概率很低。实践中，采用Clang这一开源的编译器的前端，就简单实现了针对C语言的控制代码的插入功能。同时，这对像Bash Script这类脚本语言，本发明的方案从理论上不存在实现的障碍。

图3是示出了根据本发明的一方面的在注入了控制代码后单个单元被调用时的执行流程图300。被测文件由各个单元组成，对于被测文件中的每个单元而言，该单元可能被其他单元所调用，也可能调用其他单元。在执行被测文件的测试过程中，某一单元的角色可能会改变，例如该单元可能是当前正在测试的被测单元的角色，也可能是被测单元所调用的单元的角色。

如前文所述，本发明的控制代码是统一格式的指令，可以实现统一定义的控制目的。即，对于被测文件中的每个单元都注入统一的控制指令。在测试的执行过程中，当某个单元作为被调用单元被当前的被测单元调用时，该单元中注入的控制代码就会起作用，即在注册表中记录该单元被调用的执行信息，然后对该单元的行为进行控制。然而，当该单元是被测单元的角色并且调用了其他单元时，则注入到该单元的所调用单元中的控制代码就会对该单元的所调用单元的行为进行控制。图3中正是示出了在测试过程中当某一单元被当前被测单元所调用时，该单元受控制代码的控制所执行的流程。

步骤301，单元被调用。在测试执行中，该单元被被测单元所调用。

步骤302，在注册表中记录执行信息。在该步骤中，在注册表中记录下该单元被调用的执行信息，以在后续的验证阶段依据验证逻辑进行验证。在一实例中，记录执行信息可包括但不限于记录该单元的本次调用，和/或记录该单元调用的参数。

步骤303，判断该单元是否需要被替换为替换单元，若是，则进入步骤304，否则进入步骤305。

步骤304，将参数代入替换单元执行以返回执行结果，进入步骤310。

步骤305，判断是否需要修改该单元的参数，若是，则进入步骤306，否则进入步骤307。

步骤306，将该单元的参数修改为指定值，并进入步骤307。

步骤307，判断是否需要为该单元返回指定值，若是，则进入步骤308，否则进入步骤309。

步骤308，直接为该单元返回指定值，进入步骤310。

步骤309，执行该单元的原始逻辑。即，该单元的调用实际并未被修改，从而执行自身原始的逻辑。

步骤310，结束该单元调用。

以下用一个简单的C语言函数举例：

其中，外部函数bar首先通过语法分析被识别，自动替换为桩函数

在注入器对其进行测试控制语句的注入后，代码变为：

以下是针对以上流程的BashScript语言实施例：

其中，函数bar()被注入器注入后，代码变为：

图4是示出了根据本发明的一方面的测试逻辑设置过程的序列图400。如图4所示，测试/集成环境410可调用测试脚本420以定义所需要的测试逻辑。测试脚本420是测试逻辑的体现，可由设置脚本105、验证脚本106和被测语言所支持的其他语句构成。测试逻辑是在软件程序完成之前或之后，按照需要实现或者已经实现的逻辑功能，一并结合测试目的、测试强度等需要，综合归纳出的。

相应地，测试逻辑可包括控制逻辑，验证逻辑可由设置脚本420登记在注册表450中。控制逻辑可用于根据测试目的在测试执行中对每个单元被调用时的行为进行设置。在一实例中，根据测试需要，对每个单元被调用时的行为的设置可包括但不限于，用替换单元来替代该单元的执行，将该单元的参数修改为指定值，以及为该单元强制返回指定值。这些行为均由设置脚本430在测试逻辑设置阶段写入注册表中，以供程序执行阶段由注入器注入的控制代码读取并实现。

另外，测试逻辑还可包括验证逻辑，验证脚本440可用原生语句的方式提供验证逻辑。在一实例中，在测试逻辑设置阶段，出于性能的考虑，验证脚本440可在注册表450中登记验证逻辑，以声明哪些信息是需要被记录的，以供验证时使用。相应地，控制代码在测试执行中可根据注册表中的验证逻辑向注册表中记录必要的执行信息。在一实例中，根据测试需要，可能需要记录以待验证的信息可包括但不限于，需要记录其调用顺序的单元，以及在单元被调用时需要记录其值的参数。这些信息均被保存在注册表450中，待执行测试以及验证时，这些信息将作为测试依据被动态提取调用。

如上文所述，本发明的测试逻辑可以在软件程序完成之后、也可以在软件程序完成之前就定义。换言之，本发明的测试逻辑可以是测试人员通过通读被测单元后，总结归纳出的；也可以是事先设计的，程序还未完成，就可以写出的测试用例，因此可应用于回归测试和测试驱动开发。

而且，本发明中采用了与被测文件相同的编程语言来定义测试脚本，因此现有编辑器依然可以对测试脚本进行语法检测，高亮和提示，极大提高开发效率。同时本方案可以和同语言的其他测试框架无缝集成，类似JMock对应于JUnit,由其他测试框架负责测试脚本的执行和测试结果数据的收集，而本方案则专注于具体测试逻辑本身的控制。

图5是示出了根据本发明的一方面的测试执行过程的序列图500。如图所示，测试/集成环境510可按原有的顺序被执行。当执行到被测文件520时，被测文件520中的当前被测单元的原有逻辑（被测逻辑）被执行。另外，该被测单元可能调用了其他单元（称之为被调用单元），此时，在先前控制代码注入阶段注入到该被调用单元中的控制代码530也被执行。具体地，该控制代码530可使得首先向注册表540中记录该被调用单元的执行信息，随后可从注册表540中读取并执行控制逻辑。在本发明中，通过注入的控制代码530，使得能够交替地执行被测单元的原始逻辑和该被测单元所调用单元的控制逻辑。而且，通过注入的控制代码530，被测单元的所调用单元的执行信息被记录在注册表540中，从而可在后续验证阶段进行验证。

图6是示出了根据本发明的一方面的验证过程的序列图600。如图6所示，在验证阶段，测试/集成环境610可调用测试脚本620，后者可执行验证逻辑。具体地，验证脚本630可从注册表640中读取执行信息，并依据验证逻辑和读取的执行信息来执行验证。

在软件开发过程中，特别是在需要进行回归测试或者由测试驱动开发的场合，需要使用单元测试来保证程序预期逻辑的正确性。例如，对于被测单元而言，希望验证的预期逻辑可包括但不限于，被测单元的所调用单元是否按照预期的调用顺序被执行，被测单元的所调用单元每次被调用时的参数是否为预期值，以及被测单元是否返回了预定值，等等。通过本发明的方案，能够很好地对软件程序的逻辑进行验证。

例如，如果需要验证一函数被被测函数进行调用的调用顺序，那么需要被验证的该函数由验证脚本630在定义验证逻辑时登记在注册表640中。测试执行阶段，在每次该函数被调用时，如果控制代码通过读取注册表640，发现此函数被登记，则向注册表640中记录这一调用的执行信息。在程序执行后，注册表640中就按照时间的先后，保留了所登记的函数依次被调用的顺序。验证脚本630进行验证时，可将这一顺序作为执行信息从注册表640中读出，从而和需要验证的顺序进行比对，实现验证。

图7是示出了根据本发明的一方面的单元测试方法的流程图700。如图7所示，流程图700包括以下步骤：

步骤702，向被测文件中的每个单元注入用于测试目的的控制代码。这里，单元可包括但不限于函数、方法、过程中的任意一者。

在一实例中，注入该控制代码可包括对被测文件执行词法分析和语法分析以生成抽象语法树，对作为该抽象语法树上的每个单元的节点注入控制代码，以及将注入了控制代码的抽象语法树转换回被测文件。该控制代码可以是由被测文件语言编写的统一格式的指令。

在一实例中，控制代码可用于在测试执行中按需将每个单元被调用时的执行信息首先记录在所述注册表中，并对该单元被调用时的行为进行控制。向注册表中记录每个单元被调用时的执行信息可包括但不限于记录该单元的本次调用，和/或记录该单元的参数。

在一实例中，对每个单元被调用时的行为进行控制可包括但不限于：单元替换判断、参数修改判断和指定值返回判断。在单元替换判断中，判断该单元是否需要被替换为替换单元，若是，则将参数代入替换单元执行以返回执行结果，并结束该单元的调用；在参数修改判断中，判断是否需要修改该单元的参数，若是，则将该单元的参数修改为指定值并进入指定值返回判断，若否，则进入指定值返回判断；在指定值返回判断中，判断是否需要为该单元返回指定值，若是，则直接返回指定值并结束该单元的调用，若否，则执行该单元的原始逻辑。

步骤704，定义测试逻辑，该测试逻辑可包括控制逻辑和验证逻辑，其中所述控制逻辑被登记在注册表中。该控制逻辑可用于根据测试目的在测试执行中对每个单元被调用时的行为进行设置，以及该验证逻辑可用于声明需要记录以待验证的信息。

在一实例中，对每个单元被调用时的行为的设置可包括但不限于，用替换单元来替代该单元的执行，将该单元的参数修改为指定值，以及为该单元强制返回指定值。

在一实例中，该需要记录以待验证的信息可包括但不限于，需要记录其调用顺序的单元，以及在单元被调用时需要记录其值的参数。

在一实例中，该测试逻辑由测试脚本定义，测试脚本可由设置脚本、验证脚本和被测语言所支持的其他语句构成，其中，设置脚本在注册表中登记控制逻辑，以及验证脚本在注册表中登记验证逻辑。

步骤706，执行被测文件测试，该执行可包括执行被测单元的原始逻辑和该被测单元的所调用单元的控制逻辑，其中，该控制逻辑由控制代码从注册表中读取和实现。

步骤708，基于验证逻辑执行对被测单元的预期逻辑的验证。

在一实例中，执行验证可包括从注册表中读取执行信息，以及基于该执行信息和验证逻辑执行验证。

在一实例中，对被测单元的预期逻辑的验证可包括但不限于，验证该被测单元的所调用单元是否按照预期的调用顺序被执行，验证该被测单元的所调用单元每次被调用时的参数是否为预期值，以及验证该被测单元是否返回预定值。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

图8是示出了根据本发明的一方面的单元测试系统800的框图。如图8所示，单元测试系统800可包括注入器802。注入器802可用于向被测文件中的每个单元注入用于测试目的的控制代码。单元测试系统800还可包括测试逻辑设置模块804，测试逻辑设置模块804用于定义测试逻辑，该测试逻辑包括控制逻辑和验证逻辑，其中，其中该控制逻辑被登记在注册表中。单元测试系统800还可包括测试执行模块806，测试执行模块806可用于执行被测文件测试，该执行包括执行被测单元的原始逻辑和被测单元的所调用单元的控制逻辑，其中，控制逻辑由控制代码从注册表中读取和实现。单元测试系统800还可包括验证模块808，验证模块808可基于验证逻辑执行对被测单元的预期逻辑的验证。

上文描述了本发明的单元测试方法和系统的原理，下文将结合一些具体实例给出一些测试用例的例子，这些例子中的测试脚本均以斜体伪代码表示：

示例1：

本例需要被测试的函数foo的期望逻辑为：根据bar()的执行结果，如果为0，则返回“成功”，否则返回“失败”

测试脚本如下：

函数bar()需要返回指定值，值的序列为{0，1}；

执行foo()，验证其结果为“成功”；

执行foo()，验证其结果为“失败”；

执行测试脚本后，首先由设置脚本向注册表中写入函数bar()被控制的逻辑：第一次被调用时，返回0，第二次被调用时，返回1。

然后，函数foo()被执行，并调用到函数bar()。此时，注入进bar()的控制代码读取注册表中的控制逻辑，获知bar()需要返回0这一指定值，于是将其返回。由此foo()返回“成功”，这一值由验证逻辑得以验证。

当函数foo()又一次被执行，并调用到函数bar()时，控制代码读取到的bar()的控制逻辑是返回1这一指定值，于是将其返回。由此foo()返回“失败”，这一值也由验证脚本得以验证。

示例2：

本例需要被测试的函数foo（）的预期逻辑为:如果参数input为0，那么函数bar()应该被调用，并且参数为“成功”，否则函数bar()不应该被调用

测试脚本如下：

预期：函数bar()被调用，并且参数是”成功”；

执行foo(0)；

验证函数的调用情况是否满足预期；

预期：函数bar()不应该被调用（调用次数为0）；

执行foo(1)；

验证函数的调用情况是否满足预期；

执行测试脚本后，首先由验证脚本将验证逻辑写入注册表——函数bar()将被调用，并且其参数是“成功”。

函数foo()被执行，并且其参数为0，满足其中if分支的判断条件。此时bar()被调用，并由注入在bar()中的控制代码向注册表中记录这一执行信息——bar被调用了，其参数是“成功”。

foo()执行后，验证脚本读取这一执行信息，并和之前写入的验证逻辑进行对比，判断bar()被调用的次数满足预期，并且其参数也和预期的一致。

然后，验证脚本再一次被执行，这次写入注册表的验证逻辑为：函数bar不会被调用。

函数foo()再次被执行，并且其参数为1，不满足其中if分支的判断条件，所以不调用函数bar()。因此控制代码不会向注册表中记录bar()的执行信息。

foo()执行后，验证脚本读取本次执行信息，并和之前写入的验证逻辑进行对比。因为注册表中没有bar()的执行信息，由此得到bar()没有被调用这一验证结果。

示例3：

本例需要被测试的函数foo（）的预期逻辑为:尝试调用两次函数bar()，并且判断由其参数传回的调用结果，如果第一次就成功，则返回“成功”；如果第一次失败，但是第二次成功，则返回“成功但是有警告”；如果两次都失败，则返回“失败”。

测试脚本如下：

函数bar()需要修改第一个参数,值的序列为{0,1,0,1,1},并直接返回;

预期函数bar()被调用一次;

执行foo(),验证其结果为”成功”；

验证函数的调用情况是否满足预期;

预期函数bar()被调用两次;

执行foo(),验证其结果为”成功但是有警告”;

验证函数的调用情况是否满足预期;

预期函数bar()被调用两次;

执行foo(),验证其结果为”失败”;

验证函数的调用情况是否满足预期;

执行测试脚本后，首先由设置脚本向注册表中写入函数bar()被控制的逻辑：每次被调用时，依次将第一个参数修改为0，1，0，1，1。同时，不执行bar()的原有逻辑，直接返回。这是为了防止参数被修改后被bar()的原有逻辑再次修改。

然后，验证脚本向注册表写入验证逻辑：函数bar()将被调用一次。

函数foo()被执行，调用到函数bar()时，其中注入的控制逻辑向注册表中记录这次调用。然后读取bar()的控制逻辑，判断出本次调用时，需要将第一个参数修改为0，由此修改参数result的值为0。同时，控制代码还从注册表中获知bar()需要直接返回，于是直接结束bar()的调用。其后的函数foo()的逻辑判断出result的值为0，由此返回“成功”。这一结果由验证脚本得以验证。

同时，验证脚本读取注册表中bar()的执行信息，从而验证其被执行了一次。

接下来，验证脚本向注册表写入验证逻辑：函数bar()将被调用两次。

函数foo()被执行。当调用到函数bar()时，控制代码会按照最先设置的控制逻辑，将result的值修改为1。由此，foo()的第一个else条件分支被执行，bar()再次被调用。此时，按照注册表中的控制逻辑，控制指令修改result为0并结束bar()的调用。foo()的逻辑按照这一结果，返回“成功但是有警告”,并得到验证脚本的验证。

验证脚本此时注册表中bar()的执行信息，会得到以上两次调用，和预期的结果相符。

验证脚本第三次向注册表写入验证逻辑：函数bar()将被调用两次。

函数foo()被执行。本次执行，bar()中的控制代码会按照注册表中的控制逻辑，将result依次修改为1、1。因此，foo()的第二个else分支会被执行，返回“失败”。这一结果也得到验证脚本的验证。

最后，验证脚本再次读取注册表，获知函数bar()在本次执行中，被调用了两次，符合预期。

示例4：

本例需要被测试的函数foo（）的逻辑为：在1～1000这一区间内，判断函数bar()的行为:如果bar()的返回值均是其参数的平方，则返回“正确”，否则返回“错误”。

执行测试脚本后，首先由设置脚本向注册表中写入函数bar()被控制的逻辑：当bar()被执行时，用桩函数bar1()来替代。函数bar1()的逻辑为：在1～1000这个参数区间内，返回参数的平方，对于其他参数，则返回0。

函数foo()被执行，由其逻辑，由1开始，逐次调用函数bar()并传入本次参数。注入在bar()的控制代码通过读取注册表中的控制逻辑，将对bar()的调用替代为对bar1()的调用，从而返回bar1()的执行结果，并由foo()执行判断。因为bar1()在1～1000内均返回参数的平方，因此foo()返回“正确”，并由验证脚本得以验证。

然后，由设置脚本再次向注册表中写入bar()被控制逻辑：当bar被执行时，用桩函数bar2来替代。bar2()的逻辑为：如果参数为789，则返回0，否则返回参数的平方。

函数foo再次被执行。本次执行，对bar()的调用会被注入的控制代码替代为对bar2()的调用。当执行到i=789并传入bar2()时，bar2()会返回0，从而致使foo()返回“错误”。这一结果也将得到验证脚本的验证。

本发明方案的实施仅和计算机语言的语法有关，而与CPU的体系结构以及编译器/解释器的执行原理等均无关，可以更大范围地应用于嵌入式等需要支持不同CPU体系结构的开发过程中的单元测试之上。同时，针对基于解释器解释执行的脚本语言，在解释器原理没有公开，或者解释器没有提供相应的单元测试手段时，本发明也使得对其进行单元测试成为可能。

而且，本发明不局限于特定的编程语言，除了一个独立的注入器，其他模块可由大部分的编程语言实现。利用本发明的规则，可以对单元的参数进行设置和预期，同时记录单元的调用顺序，从而大幅减少现有测试过程中需要人为增改被测程序（比如编写特定桩函数）的需要。实践中，在针对一个70000行C语言文件所进行的全覆盖单元测试工程中，对于其中的1300个函数和其所调用到的函数，实际需要人为定义桩函数来进行测试的情况只有20个左右（约1.5%）。同时，本方案的实施是通过注入器对被测文件中的每个单元进行控制代码的注入，同时通过全局的注册表调度这些控制代码的执行。因此也支持定义在同一C文件内部的单元（例如，函数）的插桩。

另外，本发明通过原生的程序语言实现的测试脚本，又最大限度地减小了测试工具的学习成本，并且最大程度地增加了现有工具的利用率。让大规模的基于程序逻辑验证的单元测试成为可能，可以广泛应用于需要回归测试以及测试驱动开发的场合。

本领域技术人员将可理解，信息和信号可使用各种不同技术和技艺中的任何技术和技艺来表示。例如，以上描述通篇引述的数据、指令、命令、信息、信号、位（比特）、码元、和码片可由电压、电流、电磁波、磁场或磁粒子、光场或光学粒子、或其任何组合来表示。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

软件应当被宽泛地解释成意味着指令、指令集、代码、代码段、程序代码、程序、子程序、软件模块、应用、软件应用、软件包、例程、子例程、对象、可执行件、执行的线程、规程、函数等，无论其是用软件、固件、中间件、微代码、硬件描述语言、还是其它术语来述及皆是如此。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims

1.一种用于单元测试的方法，包括：

向被测文件中的每个单元注入用于测试目的的控制代码；

定义测试逻辑，所述测试逻辑包括控制逻辑和验证逻辑，其中所述控制逻辑被登记在注册表中；

执行被测文件测试，所述执行包括执行被测单元的原始逻辑和所述被测单元的所调用单元的所述控制逻辑，其中，所述控制逻辑由所述控制代码从所述注册表中读取和实现；以及

基于所述验证逻辑执行对所述被测单元的预期逻辑的验证。

2.如权利要求1所述的方法，其特征在于，所述单元包括函数、方法、过程中的任意一者。

3.如权利要求1所述的方法，其特征在于，所述控制代码用于在测试执行中按需将每个单元被调用时的执行信息首先记录在所述注册表中，并对该单元被调用时的行为进行控制。

4.如权利要求3所述的方法，其特征在于，所述验证逻辑也被登记在所述注册表中，其中所述控制代码在测试执行中根据所述注册表中的验证逻辑在所述注册表中记录每个单元被调用时的执行信息。

5.如权利要求3所述的方法，其特征在于，按需向所述注册表中记录每个单元被调用时的执行信息包括：

记录该单元的本次调用；和/或

记录该单元被调用时的参数。

6.如权利要求3所述的方法，其特征在于，所述执行验证包括：

从所述注册表中读取所述执行信息；以及

基于所述执行信息和所述验证逻辑执行所述验证。

7.如权利要求1所述的方法，其特征在于，对所述被测单元的预期逻辑的验证包括以下至少一者：

验证所述被测单元的所调用单元是否按照预期的调用顺序被执行；

验证所述被测单元的所调用单元每次被调用时的参数是否为预期值；以及

验证所述被测单元是否返回预定值。

8.如权利要求3所述的方法，其特征在于，对每个单元被调用时的行为进行控制至少包括：

单元替换判断，包括：

判断该单元是否需要被替换为替换单元；

若是，则将参数代入所述替换单元执行以返回执行结果，结束该单元的调用；以及

若否，则进入参数修改判断，

参数修改判断，包括：

判断是否需要修改该单元的参数；

若是，则将该单元的参数修改为指定值，并进入指定值返回判断；以及

若否，则进入指定值返回判断，

指定值返回判断，包括：

判断是否需要为该单元返回指定值；

若是，则直接返回指定值，结束该单元的调用，

若否，则执行该单元的原始逻辑。

9.如权利要求1所述的方法，其特征在于，所述控制逻辑用于根据测试目的在测试执行中对每个单元被调用时的行为进行设置，以及所述验证逻辑用于声明需要记录以待验证的信息。

10.如权利要求9所述的方法，其特征在于，对每个单元被调用时的行为的设置包括以下至少一者：

用替换单元来替代该单元的执行；

将该单元的参数修改为指定值；以及

为该单元强制返回指定值。

11.如权利要求9所述的方法，其特征在于，所述需要记录以待验证的信息包括以下至少一者：

需要记录其调用顺序的单元；以及

在单元被调用时需要记录其值的参数。

12.如权利要求1所述的方法，其特征在于，注入所述控制代码包括：

对所述被测文件执行词法分析和语法分析以生成抽象语法树；

对作为所述抽象语法树上的每个单元的节点注入所述控制代码；以及

将注入了控制代码的抽象语法树转换回被测文件。

13.如权利要求1所述的方法，其特征在于，所述控制代码是由被测文件语言编写的统一格式的指令。

14.如权利要求1所述的方法，其特征在于，所述测试逻辑由所述测试脚本定义，所述测试脚本由设置脚本、验证脚本和被测文件语言所支持的其他语句构成，其中，所述设置脚本在所述注册表中登记所述控制逻辑，以及所述验证脚本在所述注册表中登记所述验证逻辑。

15.如权利要求14所述的方法，其特征在于，所述测试脚本由被测文件语言所编写。

16.一种用于单元测试的系统，包括：

注入器，所述注入器用于向被测文件中的每个单元注入用于测试目的的控制代码；

测试逻辑设置模块，所述测试逻辑设置模块用于定义测试逻辑，所述测试逻辑包括控制逻辑和验证逻辑，其中所述控制逻辑被登记在注册表中；

测试执行模块，所述测试执行模块用于执行被测文件测试，所述执行包括执行被测单元的原始逻辑和所述被测单元的所调用单元的所述控制逻辑，其中，所述控制逻辑由所述控制代码从所述注册表中读取和实现；以及

验证模块，所述验证模块基于所述验证逻辑执行对所述被测单元的预期逻辑的验证。

17.如权利要求16所述的系统，其特征在于，所述单元包括函数、方法、过程中的任意一者。

18.如权利要求16所述的系统，其特征在于，所述控制代码用于在测试执行中按需将每个单元被调用时的执行信息首先记录在所述注册表中，并对该单元被调用时的行为进行控制。

19.如权利要求18所述的系统，其特征在于，所述验证逻辑也被登记在所述注册表中，其中所述控制代码在测试执行中根据所述注册表中的验证逻辑在所述注册表中记录每个单元被调用时的执行信息。

20.如权利要求18所述的系统，其特征在于，向所述注册表中按需记录每个单元被调用时的执行信息包括：

记录该单元的本次调用；和/或

记录该单元被调用时的参数。

21.如权利要求18所述的系统，其特征在于，所述验证模块还用于：

从所述注册表中读取所述执行信息；以及

基于所述执行信息和所述验证逻辑执行所述验证。

22.如权利要求16所述的系统，其特征在于，所述验证模块对所述被测单元的预期逻辑的验证包括以下至少一者：

验证所述被测单元是否返回预定值。

23.如权利要求18所述的系统，其特征在于，对每个单元被调用时的行为进行控制至少包括：

单元替换判断，包括：

判断该单元是否需要被替换为替换单元；

若否，则进入参数修改判断，

参数修改判断，包括：

判断是否需要修改该单元的参数；

若否，则进入指定值返回判断，

指定值返回判断，包括：

判断是否需要为该单元返回指定值；

若是，则直接返回指定值，结束该单元的调用，

若否，则执行该单元的原始逻辑。

24.如权利要求16所述的系统，其特征在于，所述控制逻辑用于根据测试目的在测试执行中对每个单元被调用时的行为进行设置，以及所述验证逻辑用于声明需要记录以待验证的信息。

25.如权利要求24所述的系统，其特征在于，对每个单元被调用时的行为的设置包括以下至少一者：

用替换单元来替代该单元的执行；

将该单元的参数修改为指定值；以及

为该单元强制返回指定值。

26.如权利要求24所述的系统，其特征在于，所述需要记录以待验证的信息包括以下至少一者：

需要记录其调用顺序的单元；以及

在单元被调用时需要记录其值的参数。

27.如权利要求16所述的系统，其特征在于，所述注入器还用于：

将注入了控制代码的抽象语法树转换回被测文件。

28.如权利要求27所述的系统，其特征在于，所述注入器包括以下至少一者：开源编译器的前端和/或通用词法/语法分析器。

29.如权利要求16所述的系统，其特征在于，所述控制代码是由被测文件语言编写的统一格式的指令。