单元测试实践的主要问题与解决

1/40单元测试实践的主要问题与解决广州凯乐软件技术有限公司技术总监王彤本文是我在“第十届中国系统与软件过程改进年会广东会场”所作演讲的整理稿，主要分享单元测试的一些要点、单元测试实践的主要问题，以及如何来解决这些问题。一、单元测试概述1.1什么是单元测试单元测试，就是针对代码单元的独立测试。为什么需要单元测试呢？这是代码的基本特性决定了的。代码有一个基本特性，就是对数据分类处理。代码通常会有很多的判定。一个判定，就是一次分类。嵌套的判定，会使分类次数的翻倍。如果我们在写代码的时候，有一个分类漏掉了，就会产生一个Bug；如果一个分类，虽然写了代码，但是处理不正确，也会产生一个Bug。一个函数要没有错误，必须做到两点：1，对数据的分类必须完整；2，每一个分类的处理必须正确。做到了这两点，就可以说，代码的功能逻辑是正确的。2/40那么，如何检测代码的功能逻辑是否正确呢？调试，是临时的，且不完整的，例如，一个函数有十种输入，调试能覆盖五六种就不错了。而系统测试，并不针对某个具体的函数，不关注某个函数的功能逻辑是否正确。要检测某个函数的功能逻辑，就必须要依照分类列出数据，检测代码是否对每一个分类都做了处理，而且每一个分类的处理是否正确。——这就是单元测试。1.2单元测试的基本方法由上面的分析可以看出，单元测试的基本方法就是：依数据的分类列出输入，执行被测试程序，然后，判断输出是否符合预期。3/40单元测试能达到什么样的效果呢？那就是：无论别人怎么样，我总是对的！这里的“别人”，是指关联代码。“我”，是指当前正在编写或测试的代码。单元测试要做到的是，无论关联代码是否有错，都要保证我是对的。具体来说，我要考虑关联代码会产生什么样的数据，这些数据要如何分类处理，只要我的分类和处理是正确的，那么，无论别人怎么样，我总是对的。4/401.3单元测试的效益单元测试的效益可以说是立竿见影，并且会推动整个开发过程的改进。首先，单元测试可以保证代码的质量。因为只有单元测试，能够全面检测代码单元的功能逻辑，排除代码中大量的、细小的错误。其次，排错成本最小。如果在编码阶段同时进行单元测试，排错成本可以忽略不计。但若到了后期，排错成本可能会增长上百倍，要是产品已经到了用户手里，那造成的损失就更难说了。5/40第三，提升开发效率。单元测试可以让程序行为一目了然，也就是程序行为可视化。什么叫程序行为呢？就是什么输入下，会执行哪些代码，会产生什么输出。如下图，黑色的代码是当前输入下所执行代码。如果我们写几行代码，就可以看到程序的行为，相当于写文章时上下文可见，这可以促进我们的开发思维。如果我们的思维有了偏差，也可以及时发现。如果代码中有了错误，也6/40可以随时排除。那么，是不是整个项目的所有代码都做了单元测试，才能得到这些效益呢？不是的。80:20规则，在软件开发过程中也存在。也就是说，80%的代码错误，可能存在于20%的代码中；80%的编码、调试成本，可能会消耗在20%的代码上。这20%，就是算法密集度高的代码，也就是功能逻辑复杂的代码。这些代码可能只有20%，但是却可能包含了80%的错误，消耗了80%的编码、调试时间，即使只对这部分代码进行单元测试，在提升产品的质量和开发效率方面，也会产生立竿见影的效果。第四，自动回归。如果没有单元测试，系统测试发现了错误，当然要修改代码，而修改代码可能引入新的错误，又要进行全面的系统测试，这样就可能陷入循环，这通常也是项目延期的主要原因。如果有了单元测试，修改代码时可以通过回归测试马上检测是否引入了新的错误。所谓回归，就是回复到原来正确的状态。7/40正是回归测试，使单元测试对整个开发过程的改进都产生积极影响，使项目适应频繁变化的需求。单元测试是敏捷开发的基础和核心，反过来说，有了单元测试，开发过程会自动趋于敏捷。单元测试也降低了后期测试的压力。二、单元测试实践的主要问题8/40单元测试有个特点：测试简单独立的代码很容易，但要在实际工作中做好单元测试却很困难。根据我们的经验，企业在实施单元测试时，通常会面对四大问题——不愿做：程序员没有单元测试习惯。没时间：编写测试代码需要耗费大量的时间，项目的周期可能不允许。做不了：代码具有较高的耦合性，使单元测试难以进行。做不好：测试效果不能令人满意。我们通常会以覆盖率来衡量测试效果，但要实现高标准的测试覆盖很困难。三、解决思路和方法如何解决上述问题呢？接下来，谈谈一些思路和方法，使用的工具是VisualUnit。VisualUnit，简称VU，是可视化的C/C++单元测试工具。3.1如何解决“不愿做”和“没时间”对于“不愿做”，我们采用的对策是可视化，这个可视化，是指程序行为可视，后面我会用案例来演示；对于“没时间”，采用的对策是自动化，通过自动生成测试代码、自动打桩等功能，让测试的时间成本最小化。这两者结合起来，就是ETDD开发模式。那么，ETDD是什么呢？首先来介绍一下TDD，TDD就是测试驱动开发，这个大家可能听得比较多了。ETDD就是EasyTDD，即：易行版的TDD。ETDD具有以下一些特点：可视化，在开发过程中，程序行为可视。自动化，除了测试数据需要人工设定外，其他基本上都自动完成。现实化，不一定要测试所有代码，在开始阶段，可以只测试功能逻辑复杂的20%代码。下面，我用一个案例，讲解一下ETDD的过程：假如我要编写一个函数，它的功能是删除字符串左边的空格。先写好函数的框架，能通过编译就行。在编写代码前，程序员必须要做的一件事情，是想清楚代码的功能。如果我们想的时候，顺手把它记录下来，就可以让代码的功能更清晰、更明确。9/40我们现在来记录代码的功能。这里的记录，不是文字形式的宠统说明，而是数据形式的精确定义，也就是用输入和输出的方式来记录。首先，记录最基本的功能，也就是最基本、最常见的输入和输出。输入一个左边有空格的字符串，输出是删除左边空格后的字符串，返回值跟参数的输出是一样的。然后，记录详细的功能。例如，左边没有空格的，全是空格的，还有空字符串。10/40把每种输入的正确输出也记录一下。完成了这个工作后，代码的功能就完全定义下来了。现在，我们开始编写代码。我的编码思路是这样的：分为两步，第一步计算左边的空格数量；第二步，将非空格的字符向左移动，覆盖掉左边的空格。11/40以下几行代码，计算左边的空格，现在编译一下。CTRL+F7。如果编译通过，测试就会自动运行。我们可以看到，输入是什么，执行了哪些代码，产生了什么输出。这里，黑色的是当前输入下所执行的代码，未执行的话会显示为红色。这里全是黑色，表示当前输入下执行了全部代码。如果我们想看一下计算左边空格的结果对不对，这是内部的数据，要指定位置后才会打印出来。按ESC键回到开发环境。12/40用这种语法可以输出内部数据，适合于程序员开发过程中使用。复杂类型也可以用同样的语法输出。另一种输出内部数据的语法是，在左边的代码窗口，在要输出的位置点击一下，右键菜单选择“输出内部数据”，这样填一下就行了。这种方式不会修改产品代码，适合于测试员使用。13/40再次执行后，可以看到，左边的空格的数量是4，这是对的，那我们可以继续编写。新加的这几行代码完成字符串的移动。这样，代码基本上写完了，结果对不对呢？CTRL+F7编译一下。14/40结果是完全不对的。我们来分析一下，输入是这个，全部代码都是黑色，表示都执行到了，跟我设想的一样。问题在哪里呢？看一下计算左边空格的代码，经过计算后，指针偏移了，所以后面的计算，使用的是不正确的指针。15/40我们把指针先保存一下，第二次计算前再恢复回来。看看结果怎么样。现在，参数的输出是正确的了。但是，返回值还是不对，返回值应该跟参数一样。分析16/40一下，经过这里的计算后，指针再次偏移了，返回前没有恢复，所以，返回的是不正确的指针。返回前，再次把指针恢复。看看结果。17/40现在，结果是正确的了。看一下测试结果，还有一个异常。点击它，可以看到，是空指针产生了这个异常，我们的代码没有对空指针进行处理。在这里，可以很清晰的看到代码的执行状况。前面三行是黑色的，第四行开始都是红色的，表示代码只执行到第三行，也就是说，第三行产生了异常。18/40添加处理空指针的代码。现在，代码写完了，单元测试也同步完成了。19/40我们来回顾一下ETDD过程：跟传统开发模式相比，ETDD多付出的，是把以前仅在头脑里想的代码功能记录下来，从而精确地、完整地进行代码的功能设计。ETDD所得到的，是在编写代码的过程中，随时可以看到代码的行为，这可以让我们的编码过程变得轻松，而且也基本上不用调试，大家知道，调试，是最花费时间的。20/40另一方面，只要这里设定的数据是完整的，那么，我们的代码就没有问题。将来，如果需要修改代码，只要重新执行一下测试，就可以知道是不是破坏了原有的功能。小结：ETDD通过可视化来帮助程序员轻松地编写程序，单元测试不再是一个负担；ETDD通过自动化，使程序员只需要在考虑代码功能时顺手记录一下，其他工作都由工具完成。21/40ETDD提升了编码的效率，也省略大部分调试，从而大幅提升了生产力。3.2如何解决“做不了”上面我们只是用一个独立的函数来演示ETDD过程。在实际的工作中，代码之间通常是互相依赖的，这种依赖关系会造成测试难于进行，这就是“做不了”的问题。我们首先来分析一下。“做不了”主要是指可测性问题。可测性问题的核心是内部输入。在解释内部输入前，我们先来看一下一般的输入：外部输入。外部输入是指在被测代码的外部可以设定的输入，包括参数、成员变量、全局变量。外部输入一般可以直接设定。单元测试的核心难点在于内部输入，什么是内部输入呢？像下面这个例子，这两个数据，都是在被测试代码的内部，通过调用关联代码来取得，也就是内部取得的数据。对于内部取得的数据，代码要如何处理呢？跟参数一样，也是分类处理。因此，测试时也要分类检测，这就是内部输入。22/40内部输入有六种情形，我们利用工具都可以处理。解决内部输入的主要方法有打桩、模拟对象、底层模拟。先来介绍打桩。桩就是代替真实代码的一些代码。桩的功能主要有隔离、补齐和控制。可以通过编写桩代码，来解决内部输入问题。这是桩的控制功能。23/40用打桩来解决内部输入，有一些问题：一是编写桩代码增加了工作量；二是内部输入和外部输入分离，难于管理；三是只能解决部分内部输入问题。例如，要在一个用例中多次调用同一关联函数，要求每次输出不同，桩代码就很难做到。解决内部输入的另一个方法是模拟对象，这个比较复杂，另外，对于C和C++也不太适用。我们可以采用底层模拟来解决内部输入问题。24/40底层模拟有三个特点：一是内部输入与外部输入一起管理；二是不需要考虑关联代码的状态，无所关联代码是否存在，是否隔离，都可以直接使用；三是不需要编写代码。下面我也用一个案例来讲解一下底层模拟。这个示例，是一个空调控制程序。代码的功能，是首先取得环境的温度，然后与预设的目标温度比较，计算出温度差，温度每差一度，制冷器运行60秒。首先，我们设定外部数据。假设，预设的目标温度是25度，是这个全局变量，设为25。返回值为1，表示操作成功。假设环境温度是28度，那么，制冷器应该运行180秒，这里填180。然后执行测试。25/40由于环境温度还没有设定，测试进行不下去。环境温度由这个函数来取得。即使这个函数可以正常工作，取到的环境温度也不可能满足我们的测试需求。我们可以用底层模拟来解决。首先，我们要让这个取温度的函数返回1，表示取温度成功。双击函数名。26/40模拟值填1。然后，设定环境的温度。双击这个表示环境温度的参数。27/40模拟值填28。再看测试结果。现在测试就可以正常进行了。这个参数的输出是180，跟我们预期的一样。内部输入这里，显示了两个内部输入。28/40这是我们设定的内部输入，和外部输入可以一起管理。我们也可以把它移到表格中。在表格中，我们增加一个用例，把温度设为30，直接设定就是了。29/40这是环境温度为30度时的测试结果，制冷器的运行时间为300。上面演示的是简单类型的底层模拟