单元测试

本文是我在“第十届中国系统与软件过程改进年会广东会场”所作演讲的整理稿，主要分享单元测试的一些要点、单元测试实践的主要问题，以及如何来解决这些问题。 一、     单元测试概述 1.1 什么是单元测试    单元测试，就是针对代码单元的独立测试。为什么需要单元测试呢？这是代码的基本特性决定了的。代码有一个基本特性，就是对数据分类处理。    代码通常会有很多的判定。一个判定，就是一次分类。嵌套的判

1.3 单元测试的效益    单元测试的效益可以说是立竿见影，并且会推动整个开发过程的改进。    首先，单元测试可以保证代码的质量。因为只有单元测试，能够全面检测代码单元的功能逻辑，排除代码中大量的、细小的错误。        其次，排错成本最小。如果在编码阶段同时进行单元测试，排错成本可以忽略不计。但若到了后期，排错成本可能会增长上百倍，要是产品已经到了用户手里，那造成的损失就更难说了。

二、  单元测试实践的主要问题    单元测试有个特点：测试简单独立的代码很容易，但要在实际工作中做好单元测试却很困难。    根据我们的经验，企业在实施单元测试时，通常会面对四大问题——        不愿做：程序员没有单元测试习惯。        没时间：编写测试代码需要耗费大量的时间，项目的周期可能不允许。        做不了：代码具有较高的耦合性，使单元测试难以进行。        做不

（承上篇）    新加的这几行代码完成字符串的移动。这样，代码基本上写完了，结果对不对呢？CTRL+F7编译一下。        结果是完全不对的。我们来分析一下，输入是这个，全部代码都是黑色，表示都执行到了，跟我设想的一样。问题在哪里呢？    看一下计算左边空格的代码，经过计算后，指针偏移了，所以后面的计算，使用的是不正确的指针。        我们把指针先保存一下，第二次计算前再恢复回来。看

（承上篇）3.2  如何解决“做不了”    上面我们只是用一个独立的函数来演示ETDD过程。在实际的工作中，代码之间通常是互相依赖的，这种依赖关系会造成测试难于进行，这就是“做不了”的问题。    我们首先来分析一下。“做不了”主要是指可测性问题。可测性问题的核心是内部输入。在解释内部输入前，我们先来看一下一般的输入：外部输入。    外部输入是指在被测代码的外部可以设定的输入，包括参数、成员变

（承上篇）    首先，我们要让这个取温度的函数返回1，表示取温度成功。双击函数名。        模拟值填1。        然后，设定环境的温度。双击这个表示环境温度的参数。        模拟值填28。        再看测试结果。现在测试就可以正常进行了。这个参数的输出是180，跟我们预期的一样。内部输入这里，显示了两个内部输入。        这是我们设定的内部输入，和外部输入可以一起管

（承上篇）    这个底层函数返回的是一个对象指针，如何模拟呢？双击函数名，打开底层模拟器。        首先，在前置代码中定义对象并初始化。然后，在模拟值中填写这个对象的地址。        这是模拟的结果。        复杂对象的数据一样可以移到表格中，这时，要移到表格中的不是对象本身，而是对象中包含的数据。例如，要把data.ui移到表格中，双击它的值“1234”就行了。

（承上篇）3.3  如何解决“做不好”    现在来看做不好的问题。做不好的主要原因，是高标准的测试覆盖难以实现。    为什么要关注测试覆盖呢？因为未覆盖的单位，通常对应未测试的数据分类，也就是说，可以用覆盖率来检查测试的完整性，衡量测试效果。    应该在完成功能测试的基础上，统计覆盖率，找出遗漏用例来完成白盒覆盖，而不是功能测试做一遍，白盒覆盖又做一遍。    下面，我用一个案例来演示讲解覆

各位新老朋友：    2012第十六届中国国际软件博览会（简称“软博会”）将于5月31日—6月2日在北京举行。届时凯乐软件将参展本次盛会，并在会上举办主题为《单元测试实践的主要问题与解决》的专题讲座，诚邀您光临参观和交流！    展会地点：北京展览馆（北京市西城区西直门外大街135号）     我司展台：12号展馆•广州展区    讲座地点：12号展馆•广州展区    讲座时间：6月2日上午9:3