CN109308260B - 一种自动生成单元测试代码的方法及终端 - Google Patents

Abstract

本发明公开了一种自动生成单元测试代码的方法及终端，通过接收针对待测单元的指定的输入输出，分析所述的输入输出得到所有可能存在的分支，再分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩，基于所有分支，生成单元测试代码，可以实现自动生成单元测试代码，减少繁琐重复的工作，在后期的维护中也可以使用，节约时间，提高了工作效率。

Description

一种自动生成单元测试代码的方法及终端

技术领域

本发明涉及软件测试技术领域，尤其是涉及一种自动生成单元测试代码的方法及终端。

背景技术

单元测试是开发者编写一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件或场景下某个特定函数的行为。单元测试是代码的功能和健壮性最基本、最重要的手段，是整个软件工程中非常重要的一个环节。

但是写单元测试繁琐又费时，若一个方法里有一个由3个条件构成的判断语句，那么要实现它完全的分支覆盖(所谓分支覆盖，指的是单元测试的代码要跑遍所有的分支)，开发人员需要写2³＝8个测试用例，一段程序的分支越多，要实现分支覆盖所写的测试用例将以指数形式增加，由于绝大部分的代码是相同的，仅输入参数有所不同，测试用例也将是大同小异的，并没有技术含量，且单元测试的代码并非是一劳永逸的，随着软件代码的变更，单元测试的代码也要随之更新，即要不断地去维护这些单元测试代码，这将花费更多的时间。

除了时间成本之外，单元测试还需要学习成本，一个测试人员要想熟练地掌握写单元测试代码的技巧是需要进行***的学习的。测试人员指定某些条件，期望某个方法或函数在这些条件的共同作用下得到特定的结果，而一个方法或者函数有可能对其它方法函数有依赖，但是在单元测试的时候***只会运行被测试的那一个代码块，其它的任何方法或者函数是不会执行的，这就需要测试人员去模拟这些被依赖的方法或者函数，让它们在没有被执行的情况下仍然能返回指定的值，这种行为，在单元测试中被称为打桩(mock)，能不能打桩，打桩是否正确，决定了单元测试的效果。

总而言之，单元测试是非常重要的，但在传统的单元测试框架下，它又是程序员们不愿去写的，单元测试需要测试人员学习第三方测试框架，写大量的重复代码并不断地进行维护，还需要测试人员掌握打桩的技术，费时又费力。

发明内容

本发明所要解决的技术问题是：提供一种自动生成单元测试代码的方法及终端，能够实现自动生成单元测试代码，减少繁琐重复的工作，节约时间，提高效率。

为了解决上述技术问题，本发明采用的一种技术方案为：

一种自动生成单元测试代码的方法，包括步骤：

S1、接收针对待测单元的指定的输入输出；

S2、分析所述的输入输出，得到所有可能存在的分支；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；

S4、基于所有分支，生成单元测试代码。

为了解决上述技术问题，本发明采用的另一种技术方案为：

一种自动生成单元测试代码的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、接收针对待测单元的指定的输入输出；

S2、分析所述的输入输出，得到所有可能存在的分支；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；

S4、基于所有分支，生成单元测试代码。

本发明的有益效果在于：通过接收针对待测单元指定的输入输出，分析所述的输入输出得到所有可能存在的分支，再分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩，基于所有分支，生成单元测试代码，可以实现自动生成单元测试代码，减少繁琐重复的工作，在后期的维护中也可以使用，节约时间，提高了工作效率。

附图说明

图1为发明实施例的一种自动生成单元测试代码的方法的流程图；

图2为本发明实施例的一种自动生成单元测试代码的终端结构示意图；

标号说明：

1、自动生成单元测试代码的终端；2、存储器；3、处理器。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

本发明最关键的构思在于:接收针对待测单元的指定的输入输出后加以分析得到所有可能存在的分支；分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；基于所有分支，生成单元测试代码，实现单元测试代码的自动生成。

请参照图1，一种自动生成单元测试代码的方法，包括步骤：

S1、接收针对待测单元的指定的输入输出；

S2、分析所述的输入输出，得到所有可能存在的分支；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；

S4、基于所有分支，生成单元测试代码。

从上述描述可知，本发明的有益效果在于：通过接收针对待测单元的指定的输入输出，分析所述的输入输出得到所有可能存在的分支，再分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩，基于所有分支，生成单元测试代码，可以实现自动生成单元测试代码，减少繁琐重复的工作，在后期的维护中也可以使用，节约时间，提高了工作效率。

进一步的，步骤S3中所述判断是否需要打桩包括：遍历所有输出结果字符串，对所述字符串依次进行语义分析；判断该字符串是一个确定的值还是一个方法的返回值，如果是确定的值则不需要打桩，如果是一个方法的返回值，则需要打桩。

由上述描述可知，对输出结果字符串进行语义分析来自动判断是否需要打桩，减轻了相关人员的工作量，提高了测试效率。

进一步的，步骤S3所述打桩包括：

S31、通过继承的方式，得到被依赖方法所在类的一个子类；

S32、重写所述被依赖的方法，使所述一个子类的被依赖方法返回指定值。

由上述描述可知，通过自动在继承的子类中重写被依赖的方法来返回指定值，提高了打桩的效率，方便了测试的进一步实施。

进一步的，所述步骤S31中之后所述得到被依赖方法所在类的一个子类之前还包括：判断所述被依赖方法所在的类是否是一个无法被继承重写的final的类或final方法，若是，则修改所述被依赖方法所在的类的字节码，将所述被依赖方法所在的类变成非final的类或方法。

由上述描述可知，通过自动判断所述被依赖方法所在的类是否是一个无法被继承重写的final的类或final方法，若是则可以自动将其修改为非final的类或方法，提高了打桩的效率，为相关人员减轻许多繁琐的工作，节约了时间。

进一步的，所述步骤S1还包括：判断是否需要修改输入，若是，则接收针对待测单元的指定的修改后的输入。

由上述描述可知，当待测单元变更时只需修改指定输入，不需要重写用于测试的代码，就可以重新生成所有的测试用例代码，方便快捷，免去了人们许多繁琐重复的工作，提高了工作效率。

请参照图2，一种自动生成单元测试代码的终端1，包括存储器2、处理器3及存储在存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现以下步骤：

S1、接收针对待测单元的指定的输入输出；

S2、分析所述的输入输出，得到所有可能存在的分支；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；

S4、基于所有分支，生成单元测试代码。

从上述描述可知，本发明的有益效果在于：通过接收针对待测单元的指定的输入输出，分析所述的输入输出得到所有可能存在的分支，再分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩，基于所有分支，生成单元测试代码，可以实现自动生成单元测试代码，减少繁琐重复的工作，节约时间，提高了工作效率。

进一步的，步骤S3中所述判断是否需要打桩包括：遍历所有输出结果字符串，对所述字符串依次进行语义分析；判断该字符串是一个确定的值还是一个方法的返回值，如果是确定的值则不需要打桩，如果是一个方法的返回值，则需要打桩。

由上述描述可知，对输出结果字符串进行语义分析来自动判断是否需要打桩，减轻了相关人员的工作量，提高了测试效率。

进一步的，步骤S3所述打桩包括：

S31、通过继承的方式，得到被依赖方法所在类的一个子类；

S32、重写所述被依赖的方法，使所述一个子类的被依赖方法返回指定值。

由上述描述可知，通过自动在继承的子类中重写被依赖的方法来返回指定值，提高了打桩的效率，方便了测试的进一步实施。

进一步的，所述步骤S31中之后所述得到被依赖方法所在类的一个子类之前还包括：判断所述被依赖方法所在的类是否是一个无法被继承重写的final的类或final方法，若是，则修改所述被依赖方法所在的类的字节码，将所述被依赖方法所在的类变成非final的类或方法。

由上述描述可知，通过自动判断所述被依赖方法所在的类是否是一个无法被继承重写的final的类或final方法，若是则可以自动将其修改为非final的类或方法，提高了打桩的效率，为相关人员减轻许多繁琐的工作，节约了时间。

进一步的，所述步骤S1还包括：判断是否需要修改输入，若是，则接收针对待测单元的指定的修改后的输入。

由上述描述可知，当待测单元变更时只需修改指定输入，不需要重写用于测试的代码，就可以重新生成所有的测试用例代码，方便快捷，免去了人们许多繁琐重复的工作，提高了工作效率。

实施例一

请参照图1，一种自动生成单元测试的方法，包括步骤：

S1、接收针对待测单元的指定的输入输出；

其中，所述的输入指的是代码中if语句的条件，所述的输出是指条件满足时或不满足时的结果，如果所述待测单元的源码发生了变更，比如由三个参数变成四个参数，在传统做法下需要重新写16个测试用例，而本发明只需要修改输入的条件，即可自动重新生成测试用例；

S2、分析所述的输入输出，得到所有可能存在的分支；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；

具体的，通过遍历所有输出结果字符串，对所述字符串依次进行语义分析；判断该字符串是一个确定的值还是一个方法的返回值，如果是确定的值则不需要打桩，如果是一个方法的返回值，则需要打桩；

打桩时，先判断所述被依赖方法所在的类是否是一个无法被继承重写的final的类或final方法，若是，则修改所述被依赖方法所在的类的字节码，将所述被依赖方法所在的类变成非final的类或方法；

接着通过继承的方式，得到被依赖方法所在类的一个子类；重写所述被依赖的方法，使所述一个子类的被依赖方法返回指定值；

S4、基于所有分支，生成单元测试代码。

具体的，通过将确定值或打桩返回的指定值写入符合输入条件的测试用例，为每一个分支生成测试用例代码，从而完成单元测试。

实施例二

将实施例一所述的方法应用于具体的例子，在java的测试中：

首先，***提供以下几个方法用于输入参数：

a).设置条件的方法，(以下简称if方法)，这个方法用于接收开发者提供的条件语句，假设有这样一个语句：return a>0？1:0，其条件就是“a>0”；

b).设置条件满足时的返回值的方法(以下简称then方法)，这个方法用于接收开发者提供的if方法里给的条件得到满足时的值，以上述语句为例，就是“1”；

c).设置条件不满足时的返回值的方法(以下简称else方法)，这个方法用于接收开发者提供的if方法里给的条件未得到满足时的值，以上述语句为例，就是“0”；

d).设置指定条件下某个方法被执行次数的方法(以下简称verify方法)，这个方法用于接收开发者提供的if方法里给的条件满足或者不满足时，某个语句执行的次数，因为在java里，一个方法有可能没有返回值，那么测试这样的方法的时候就需要通过确认某个方法是否被执行来进行，这个方法输入的语句被称为确认语句；

e).输出用例方法，以下简称build方法，开发者可通过此方法得到所有的测试用例的代码；

接着***通过以下步骤实现单元测试代码的自动生成：

S1、接收针对待测单元的指定的输入输出，具体为：

(1)***接收开发者调用if方法，设置的输入条件；

(2)开发者调用then方法，同样以字符串的形式把待测方法在满足步骤(1)中所指定的条件下得到的结果提供给***；

(3)开发者调用verify方法(如果有需要的话)，同样以字符串的形式把待测方法在满足步骤2里所指定的条件下需要执行的方法与次数提供给***；

(4)开发者调用else方法(如果需要的话)，同样以字符串的形式把待测方法在不满足步骤2里所指定的条件下得到的结果提供给***；

(5)开发者调用verify方法(如果有需要的话)，同样以字符串的形式把待测方法在不满足步骤2里所指定的条件下需要执行的方法与次数提供给***；

(6)开发者所有的输入都将被暂存在内存里；

(7)开发者重复(2)-(6)步骤，直到把待测方法所有可能存在的输入输出都指定完成；

其中，当待测试的单元输入条件需要变化时，则接收针对待测单元的指定的修改后的输入，修改if方法的条件；

S2、分析所述的输入输出，得到所有可能存在的分支，具体为：

(1)接收开发者发送的执行build方法的指令；

(2)***接收到开发者发出的build指令后，会遍历所有的输入条件字符串，依次进行语义分析，判断该方法的输入有几个条件，这些条件是以何种形式进行组合的，这些条件的组合将有多少个分支，进而决定生成多少个测试用例，比如某个条件是“a>0&&b>0”，那么***经过分析，发现这个条件是由两个条件组成的复合条件，于是将会生成4个测试用例；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩：

具体的，***遍历所有输出结果字符串，依次进行语义分析，判断该字符串是一个确定的值还是一个方法的返回值，如果是确定的值则会上述符合条件的测试用例写入这个值，如果是一个方法的返回值则会对这个方法进行打桩。即在被测代码运行之前，***会通过修改类的字节码的方式，将上述被依赖方法的返回值进行修改，把被依赖方法的返回值修改为预先指定的一个随机值。这样，当运行测试用例的时候，这个被依赖的方法就会返回好已经指定的值，并且被依赖方法的实际代码逻辑将不会被运行，保证了被测方法的纯洁性；

S4、基于所有分支，生成单元测试代码，具体为：

针对每一个分支，生成对应的测试用例代码，***输出上述所有分支的测试用例的代码到工程目录下的src/test/java/被测类相同路径的目录，所有测试用例代码即构成了针对所述单元的测试；

最后，开发人员进入该目录，运行单元测试用例即实现对所述单元的测试。

通过以上步骤，开发人员即可在极少量输入的情况下——实际上只要把源码进行复制、粘贴，就可以得到被测方法全分支覆盖的若干完整的测试用例代码，节省大量的时间。而且开发人员几乎不需要学习新的内容：本方案只有少数几个方法，与任何一个第三方单元测试框架相比，都可以忽略不计。在后期的维护中，同样的方法可以得到新的测试用例代码，而不必费心去查找原有的用例里有哪些地方需要修改，同样可以节省大量的时间。

实施例三

将实施例二所述的方法应用于具体的例子，在java的测试中：

假设开发人员要对下面这段代码写单元测试用例：

public class Foo{

public int getValue(int value1,int value2,int value3){

if(value1>0||value2>0||value3>0){

return MathTools.next(value1,value2,value3)；

}

return 0；

}

}

这段代码的核心只有三行，其结果是：当输入的三个参数都为自然数的时候，返回另一个类的某个方法的返回值(MathTools.next)，否则就返回0；为保证全分支覆盖将要写8个测试用例，加上后期维护需要花费大量时间，在使用本发明方案的情况下，其过程如下：

S1、接收针对待测单元的指定的输入输出，具体为：

(1)首先，开发者调用if方法，输入条件“value1>0||value2>0||value3>0”，即源代码里作为if语句条件的字符串；

(2)***接收输入，将条件“value1>0||value2>0||value3>0”存入数组；

(3)接着开发者调用then方法，设置“MathTools.next(value1,value2,value3)”，它同样是源码里的字符串，***接收满足上述条件时的输出结果；

(4)开发者调用verify(“MathTools.next(value1,value2,value3)”，1)方法，设置在条件“value1>0||value2>0||value3>0”得到满足的情况下，“MathTools.next(value1,value2,value3)”这个方法被执行了一次。

(5)开发者调用else方法，设置“0”，***接收不满足上述条件时的输出结果；

(6)开发者调用verify(“MathTools.next(value1,value2,value3)”，0)方法，设置在条件“value1>0||value2>0||value3>0”未得到满足的情况下，“MathTools.next(value1,value2,value3)”这个方法不会被执行；

S2、分析所述的输入输出，得到所有可能存在的分支，具体为：

(1)开发者调用build方法，通知构造测试用例代码；

(2)***在收到build指令后，开始分析内存里的数据，首先是条件语句，在本实施例中只有一个条件语句，即“value1>0||value2>0||value3>0”，这是一个复合条件，将会被拆成三个条件，分别是：value1>0,value2>0,vlaue3>0，三个条件将会有8种组合，因此***将会生成8个测试用例；

(3)***继续分析条件语句，判断只有value1<＝0且value2<＝0且value3<＝0的情况下，该条件语句得不到满足，其它7种组合都能满足这个条件，于是将会在生成的8个测试用例里，令满足条件的7个用例的返回值是“MathTools.next(value1,value2,value3)”，不满足条件的用例的返回值是0；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩，具体为：

(1)***分析输出语句，当前方法有两个输出，一个是“0”，另一个是字符串“MathTools.next(value1,value2,value3)”，***判断“0”是一个整数值，直接给出；但是MathTools.next(value1,value2,value3)是另一个类的某个方法的返回值，需要进行打桩，以继承的方式在子类中重写被依赖方法，给出一个返回值；

(2)***分析确认语句，发现在条件满足的情况下，方法“MathTools.next(value1,value2,value3)”会被执行1次，否则执行0次，即不被执行；

S4、基于所有分支，生成单元测试代码，具体为：

(1)所有输入、输出语句分析完毕后，***根据每个测试用例的输入条件进行赋值，即给出一个满足或者不满足条件的随机值，生成赋值代码；根据是否需要打桩，进行打桩；生成调用被测方法的代码；生成判断输出的代码；生成确认语句代码；最后将上述代码合并，输出成一个完整的测试用例代码到指定的目录；

(2)上述被测方法最终将会生成以下8个测试用例，这些用例都是直接可以运行并检测结果的，代码如下：

测试用例一：

测试用例二：

测试用例三：

测试用例四：

测试用例五：

测试用例六：

测试用例七：

测试用例八：

如果上述被测方法的源码发生了变更，比如由三个参数变成四个参数，那么在传统做法下的开发人员需要重新写16个测试用例，而使用本***的开发人员只需要修改一下if方法的参数，把新的条件语句传入，再执行build方法，即可重新生成测试用例；

上面的示例代码里的@Prepare{MathTools.class}、MockUtils.mockStatic(MathTools.class)、MockUtils.when(......).thenReturn(...)、MockUtils.verify等都是第三方框架的内容，在传统实施测试时需要相关人员进行学习，而在本发明中不需要学习如何去打桩，甚至不需要知道什么叫打桩，只需要告诉本***要做什么，其它所有的事情都将由***完成，简单地说，在本实施例中，开发人员可以仅用4行代码，完成几十上百行的单元测试代码。

实施例四

一种自动生成单元测试代码的终端1，包括存储器2、处理器3及存储在存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例一中的各个步骤。

综上所述，本发明提供的一种自动生成单元测试代码的方法及终端，通过接收针对待测单元的指定的输入输出，分析所述的输入输出得到所有可能存在的分支，再分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩，基于所有分支，生成单元测试代码，可以实现自动生成单元测试代码，减少繁琐重复的工作，在后期的维护中也可以使用，节约时间，提高了工作效率，其间能够通过语义分析自动来判断是否需要打桩以及自动打桩，提高了打桩的效率，进一步提高了测试效率，测试不同的待测单元时只需修改输入即可重新生成单元测试代码，简单方便，易于操作，带来了极大的便利。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (8)

1.一种自动生成单元测试代码的方法，其特征在于，包括步骤：

S1、接收针对待测单元的指定的输入输出，所述的输入指的是代码中if语句的条件，所述的输出指的是条件满足或不满足时的结果；

S2、分析所述的输入输出，得到所有可能存在的分支，具体为：

遍历所有的输入条件字符串，依次进行语义分析，判断该方法的输入有几个条件，这些条件是以何种形式进行组合的，这些条件的组合将有多少个分支，进而决定生成多少个测试用例；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；

所述步骤S3中所述判断是否需要打桩包括：

遍历所有输出结果字符串，对所述字符串依次进行语义分析；

判断该字符串是一个确定的值还是一个方法的返回值，如果是确定的值则不需要打桩，如果是一个方法的返回值，则需要打桩；

S4、基于所有分支，生成单元测试代码，具体为：

通过将确定的值或打桩返回的指定值写入符合输入条件的测试用例，为每一个分支生成测试用例代码，从而完成单元测试。

2.根据权利要求1所述的自动生成单元测试代码的方法，其特征在于，所述步骤S3所述打桩包括：

S31、通过继承的方式，得到被依赖方法所在类的一个子类；

S32、重写所述被依赖的方法，使所述一个子类的被依赖方法返回指定值。

3.根据权利要求2所述的自动生成单元测试代码的方法，其特征在于，所述步骤S31之前还包括：

判断所述被依赖方法所在的类是否是一个无法被继承重写的final的类或final方法，若是，则修改所述被依赖方法所在的类的字节码，将所述被依赖方法所在的类变成非final的类或方法。

4.根据权利要求1所述的自动生成单元测试代码的方法，其特征在于，所述步骤S1还包括：

判断是否需要修改输入，若是，则接收针对待测单元的指定的修改后的输入。

5.一种自动生成单元测试代码的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：

S1、接收针对待测单元的指定的输入输出，所述的输入指的是代码中if语句的条件，所述的输出指的是条件满足或不满足时的结果；

S2、分析所述的输入输出，得到所有可能存在的分支，具体为：

遍历所有的输入条件字符串，依次进行语义分析，判断该方法的输入有几个条件，这些条件是以何种形式进行组合的，这些条件的组合将有多少个分支，进而决定生成多少个测试用例；

S3、分析每一个分支的输入输出，判断是否需要打桩，如果需要则打桩；

所述步骤S3中所述判断是否需要打桩包括：

遍历所有输出结果字符串，对所述字符串依次进行语义分析；

判断该字符串是一个确定的值还是一个方法的返回值，如果是确定的值则不需要打桩，如果是一个方法的返回值，则需要打桩；

S4、基于所有分支，生成单元测试代码，具体为：

通过将确定的值或打桩返回的指定值写入符合输入条件的测试用例，为每一个分支生成测试用例代码，从而完成单元测试。

6.根据权利要求5所述的自动生成单元测试代码的终端，其特征在于，所述步骤S3所述打桩包括：

S31、通过继承的方式，得到被依赖方法所在类的一个子类；

S32、重写所述被依赖的方法，使所述一个子类的被依赖方法返回指定值。

7.根据权利要求6所述的自动生成单元测试代码的终端，其特征在于，所述步骤S31中之后所述得到被依赖方法所在类的一个子类之前还包括：

判断所述被依赖方法所在的类是否是一个无法被继承重写的final的类或final方法，若是，则修改所述被依赖方法所在的类的字节码，将所述被依赖方法所在的类变成非final的类或方法。

8.根据权利要求5所述的自动生成单元测试代码的终端，其特征在于，所述步骤S1还包括：

判断是否需要修改输入，若是，则接收针对待测单元的指定的修改后的输入。

Images