六、复杂初始化。有时候一些输入是相当复杂的，要完成这个初始化挺麻烦。这个时候通常可以找一下有没有一些代码是调用这个被测试函数的。如果有的话，我们是应该可以找到用于初始化的代码。假如没有的话，就需要另外去编写一些完成这些复杂初始化的代码。函数无论多复杂，它都是需要被别的函数调用的。那么这种复杂初始化的代码通常是已经存在的了。用现有的代码来完成这种初始化，只是其中的一种方法。这种方法是用于我们复杂的数据需要在被测试的代码当中真正的直接被读写，它就应该是一个需要实际进行初始化的数据，我们可以调用现有代码来完成初始化。

　　有些输入是相当复杂的，一个实际例子：

　　七、间接输入。前面讲过，有一些初始化是相当麻烦的，这些初始化，其中有一部分，甚至大部分就是间接输入。也就是说我们的这些输入并不是直接的被测试代码来读写的，而是要传递给底层函数。通常为了获得比较完整的测试覆盖，我们要让内部数据在调用底层函数之后，得到一个合适的值。为了得到这个合适的值，我们需要间接的设置外部输入的值。这需要一个推算的过程，这个工作量是相当高的。我们的解决思路是对这种间接输入不再给它初始化，而是把它设为内部的输入，直接的从内部设置我们需要的数据，这就比较简单。

　　下面的例子是一个间接输入的例子，就是说把间接输入转换为直接的内部输入。第二个参数是一个映射表。被测试函数并不直接去读取这个映射表的数据，而是调用了一个子函数去查询这个映射表里面的一些状态。为了让这个查询返回真，我们直接让这个子函数返回我们想要的值，这样就非常简单。如果用一般的初始化方法对这个函数进行初始化，可能就比较麻烦。这就是把间接输入直接转换为内部输入的一个例子。

　　八、白盒覆盖的完整性。一般来说要自动统计白盒覆盖并不是很难的，但是白盒覆盖有一个特点，越到后边就越难，仅仅只统计出这个覆盖率往往意义不大。也就是说如果统计出来之后，没法去提高这个覆盖率，那这个统计就没多大意义。我们的解决思路是基于现有用例，利用白盒统计找出遗漏用例，这个就是工具要实现的一个功能。

　　九、输入覆盖完整性。由于白盒覆盖是基于已编写的代码，对于设计和编码时未考虑和未处理的输入是无能为力的，这是它的局限性。如果我们要实现比较完整的输入覆盖，即使白盒覆盖做得非常好，也是没有保障的。我们提出的思路就是将数据分类集中，这样可以便于人工检查输入完整性，实现比较高的输入覆盖。

　　十、避免干扰思维。程序员进行单元测试，是可行的一种方式，也是最普遍的一种方式。但是不能让单元测试去干扰程序员的思维。因为程序员在编写代码的时候是需要非常专注的。如果在编写测试代码，解决测试中碰到的各种问题的时候要花很多时间，就会造成程序员开发思维的中断和干扰，这个是损失比较大的一件事情。我们提出来的解决思路是要由工具来完成其他工作，只有用例的输入输出由人工定义，因此，比较短的时间就能完成单元测试的工作，从而避免干扰思维。设定用例的输入和输出是一种设计工作，对编程对开发是非常有好处的。

　　这里我们讲到单元测试的十个难题，这些难题如果要靠手工的方式来解决是非常困难的。我们要使用工具才能解决这些难题。这些难题也是有一个层次的，有一些是必须要解决，否则测试就做不下去，有一些是涉及到效率效果的问题。如果我们要在大中项的项目中实施单元测试，工具应该能做到解耦合、补齐未定义符号、模拟底层代码的行为以及能提供便利可自编代码完成复杂初始化。如果要想高效率测试，工具应该还可以做到：自动生成驱动、将复杂的间接输入转换为简单的内部输入、高度自动化避免干扰思维。如果还要保证测试效果，工具还应该做到：将数据分类集中以保证输入覆盖率、协助找出遗漏用例以保证白盒覆盖率。

　　在这个讲座当中，我们完全没有涉及到具体的工具，只是讲技术和解决思路。有了这些具体的思路，我们就可以去寻找合适的工具。我们还有一个讲座是涉及到具体的工具的，这个讲座会使用工具演示的方式来具体介绍如何解决这些难题。（以上言论仅代表作者的个人观点，不代表51Testing观点）

版权声明：本文出自测啊的51Testing软件测试博客：http://www.51testing.com/?222098

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。